small typo fixes in the docs

songzxDev · Mar 17, 2018 · fc44408 · fc44408
1 parent 8303e23
commit fc44408
Show file tree

Hide file tree

Showing 16 changed files with 51 additions and 43 deletions.
diff --git a/docs/features.rst b/docs/features.rst
@@ -57,7 +57,7 @@ their amount with the correct currency symbol. They also offer the special amoun
 Django-SHOP directly plugs into django-CMS
 ==========================================
 
-Product detail pages may use all templatetags from djangoCMS, such as the ``{% placeholder ... %}``,
+Product detail pages may use all templatetags from **django-CMS**, such as the ``{% placeholder ... %}``,
 the ``{% static_placeholder ... %}``, or other CMS tags.
 
 **Django-SHOP** does not presuppose categories to organize product list views. Instead django-CMS

diff --git a/docs/howto/customize-snippets.rst b/docs/howto/customize-snippets.rst
@@ -4,7 +4,7 @@
 Add Customized HTML Snippets
 ============================
 
-When working in *Structure Mode* as provided by **djangoCMS**, while editing the DOM tree inside a
+When working in *Structure Mode* as provided by **django-CMS**, while editing the DOM tree inside a
 placeholder, we might want to add a HTML snippet which is not part of the **Cascade** ecosystem.
 Instead of creating an additional Django template, it often is much easier to just add a  customized
 plugin. This plugin then is available when editing a placeholder in *Structure Mode*.

diff --git a/docs/reference/addresses.rst b/docs/reference/addresses.rst
@@ -105,7 +105,7 @@ The Default Address Model
 The simplest way is to materialize the required address classes, is to use them from our default
 and convenience models: :class:`shop.models.defaults.address.ShippingAddress` and
 :class:`shop.models.defaults.address.BillingAddress`. Before using them, we check if they
-fulfill your requirements. Otherwise we create our own address models inheriting from
+fulfill our requirements. Otherwise we create our own address models inheriting from
 :class:`shop.models.address.BaseAddress`.
 
 

diff --git a/docs/reference/cart-icon.rst b/docs/reference/cart-icon.rst
@@ -32,16 +32,16 @@ such as::
         <ng-pluralize count="caption.num_items" when="{'1': '{% trans "1 Item" context "cart icon" %}', 'other': '{% trans "{} Items" context "cart icon" %}'}"></ng-pluralize>
     </script>
 
-Whenever this AngularJS directive receives an event of type ``shopUpdateCarticonCaption``, then it
+Whenever this AngularJS directive receives an event of type ``shop.carticon.caption``, then it
 updates the cart icon's caption with the current state of the cart. The emitter of such an event
 typically is the cart editor or an add-to-cart directive. If this function has already computed
 the new caption data, it may send it to the cart item, such as:
 
 .. code-block:: javascript
 
-    $scope.$emit('shopUpdateCarticonCaption', caption_data);
+    $scope.$emit('shop.carticon.caption', caption_data);
 
-otherwise if it emits the signal without object, the AngularJS directive ``shopCarticonCaption``
+otherwise, if it emits the signal without object, the AngularJS directive ``shopCarticonCaption``
 will fetch the updated caption data from the server. The latter invokes an additional HTTP request
 but is useful, if the caption shall for instance contain the cart's total, since this has to be
 computed on the server anyway.
diff --git a/docs/reference/cascade-plugins.rst b/docs/reference/cascade-plugins.rst
@@ -4,16 +4,16 @@
 Cascade Plugins
 ===============
 
-**DjangoSHOP** extends the eco-system of **djangoCMS** plugins, djangocms-cascade_, by additional
-shop-specific plugins. This allows us to create a whole shopping site, which consists of many
-different elements, without having to craft templates by hand – with one exception: The product
-detail views.
+**Django-SHOP** extends the used eco-system arround **django-CMS** plugins, djangocms-cascade_,
+by additional shop-specific plugins. This allows us to create a whole shopping site, which consists
+of many different elements, without having to craft templates by hand – with one exception: The
+product detail views.
 
 Therefore all we have to focus on, is a default page template with one big placeholder. This
 placeholder then is subdivided into containers, rows, columns and other elements of the **Cascade**
 plugin collection.
 
-This however requires a completely different approach, from the designer point of view. The way web
+This however requires a completely different approach, from a designer's point of view. The way web
 design has been done a few years ago, starting with the screenshot of a finished page, must be
 rethought. This has been discussed in length by many web-designers, especially by Brad Frost in his
 excellent book on `Atomic Web Design`_. He propagates to reverse the design process and start with
@@ -23,7 +23,7 @@ themselves aggregate to Organisms.
 Some designers nowadays build those components directly in HTML and CSS or SASS, instead of drawing
 their screens using programs such as InDesign or PhotoShop (which by the way never was intended for
 this kind of work). It also exempts having the programmer to convert those screens into HTML and CSS
-– a time consuming and never satisfying job.
+– a time consuming and unsatisfying job.
 
 According to Frost, the next bigger component after the Organism is the template. This is where
 **djangocms-cascade** jumps in. Each of the Cascade plugins is shipped with its own default
@@ -88,7 +88,7 @@ A nice aspect of this approach is, that ...
   form validation controllers: That one in Javascript used on the client as well as the final one,
   validating the form on the server.
 * if our forms are made out of models, all of the above works as well.
-* we can arrange each of those form components using the **Structure** editor from **djangoCMS**
+* we can arrange each of those form components using the **Structure** editor from **django-CMS**
   toolbar. This is much faster, than by crafting templates manually.
 
 As we can see from this approach, **django-SHOP**  places great value on the principles of a

diff --git a/docs/reference/catalog.rst b/docs/reference/catalog.rst
@@ -8,7 +8,7 @@ The catalog presumably is that part, where customers of our e-commerce site spen
 Often it even makes sense, to start the :ref:`reference/catalog-list` on the main landing page.
 
 In this documentation we presume that categories of products are built up using specially tagged
-CMS pages in combination with a `djangoCMS apphook`_. This works perfectly well for most
+CMS pages in combination with a `django-CMS apphook`_. This works perfectly well for most
 implementation, but some sites may require categories implemented independently of the CMS.
 
 Using an external **django-SHOP** plugin for managing categories is a very conceivable solution,
@@ -41,7 +41,7 @@ But first we must :ref:`reference/create-CatalogListApp`.
 Create the ``CatalogListApp``
 -----------------------------
 
-To retrieve a list of product models, the Catalog List View requires a `djangoCMS apphook`_. This
+To retrieve a list of product models, the Catalog List View requires a `django-CMS apphook`_. This
 ``CatalogListApp`` must be added into a file named ``cms_apps.py`` and located in the root folder
 of the merchant's project:
 
@@ -168,11 +168,11 @@ Use CMS Placeholders on Detail View
 -----------------------------------
 
 If we require CMS functionality for each product's detail page, its quite simple to achieve. To the
-class implementing our product model, add a `djangoCMS Placeholder field`_ named ``placeholder``.
+class implementing our product model, add a `django-CMS Placeholder field`_ named ``placeholder``.
 Then add the templatetag ``{% render_placeholder product.placeholder %}`` to the template
 implementing the detail view of our product. This placeholder then shall be used to add arbitrary
 content to the product's detail page. This for instance can be an additional text paragraphs,
-some images, a carousel or whatever is available from the **djangoCMS** plugin system.
+some images, a carousel or whatever is available from the **django-CMS** plugin system.
 
 
 Route requests on Detail View
@@ -315,8 +315,8 @@ above.
 .. note:: Due to the way keys are handled in many caching systems, the ``InvalidateProductCacheMixin``
 	only makes sense if used in combination with the redis_cache_ backend.
 
-.. _djangoCMS apphook: http://docs.django-cms.org/en/stable/how_to/apphooks.html
-.. _djangoCMS Placeholder field: http://django-cms.readthedocs.org/en/stable/how_to/placeholders.html
+.. _django-CMS apphook: http://docs.django-cms.org/en/stable/how_to/apphooks.html
+.. _django-CMS Placeholder field: http://django-cms.readthedocs.org/en/stable/how_to/placeholders.html
 .. _serializer fields: http://www.django-rest-framework.org/api-guide/fields/
 .. _templatetags from the easythumbnail: https://easy-thumbnails.readthedocs.org/en/stable/usage/#templates
 .. _redis_cache: http://django-redis-cache.readthedocs.org/en/stable/
diff --git a/docs/reference/configuration.rst b/docs/reference/configuration.rst
@@ -89,6 +89,18 @@ By using the configuration setting:
 we my specify our own money rendering format, where ``{symbol}`` is €, $, £, etc. and ``{currency}``
 is EUR, USD, GBP, etc.
 
+Unless amounts never reach a thousand, it is advised to activate a separator for better readability.
+
+.. code-block:: python
+
+	USE_THOUSAND_SEPARATOR = True
+
+Outside of the US, it generally is a good idea to activate localization for numeric types.
+
+.. code-block:: python
+
+	USE_L10N = True
+
 
 Cart Modifiers
 --------------
@@ -169,7 +181,7 @@ This is a configuration known to work. Special and optional apps are discussed b
 * ``polymorphic`` only required, if the site requires more than one type of product model.
   It presumes that django-polymorphic_ is installed.
 * ``djangocms_text_ckeditor`` optionally adds a WYSIWYG HTML editor which integrates well with
-  **djangoCMS**.
+  **django-CMS**.
 * ``django_select2`` optionally adds a select field to Django's admin, with integrated
   autocompletion. Very useful for addings links to products manually. It presumes that
   django-select2_ is installed.

diff --git a/docs/reference/customer-model.rst b/docs/reference/customer-model.rst
@@ -15,17 +15,17 @@ right on from the beginning of their session.
 
 But when running an e-commerce site, this use-pattern has serious drawbacks. Normally, a visitor
 starts to look for interesting products, hopefully adding a few of them to their cart. Then on the
-way to the checkout, they decide whether to create a user account, use an existing one or continue
+way to checkout, they decide whether to create a user account, use an existing one or continue
 as guest. Here's where things get complicated.
 
 First of all, for non-authenticated site visitors, the cart does not belong to anybody. But each
 cart must be associated with *its* current site visitor, hence the generic anonymous user object
 is not appropriate for this purpose. Unfortunately the Django framework does not offer an explicit
-but anonymous user object based on the assigned session-Id.
+but anonymous user object based on the assigned ``Session-Id``.
 
 Secondly, at the latest when the cart is converted into an order, but the visitor wants to continue
 as guest (thus remaining anonymous), that order object *must* refer to an user object in the
-database. These kind of users would be regarded as fakes: Unable to log in, reset their password,
+database. These kind of users would be regarded as *fakes*: Unable to log in, reset their password,
 etc. The only information which must be stored for such a faked user, is their email address
 otherwise they couldn't be informed, whenever the state of their order changes.
 

diff --git a/docs/reference/docker.rst b/docs/reference/docker.rst
@@ -2,7 +2,7 @@
 Deployment using Docker
 =======================
 
-By using Docker_ in combination with docker-compose_, the deployment of a **django-SHOP**
+By using Docker_ in combination with docker-compose, the deployment of a **django-SHOP**
 installation becomes really simple. We make use of this in the demos, but these examples
 are intended to run on a local docker machine, hence there we use the internal web server
 provided by uWSGI_. In a productive environment, we usually use a web server to dispatch
@@ -417,7 +417,6 @@ invoking:
 	$ docker container logs my_shop_webapp_1
 
 .. _Docker: https://docs.docker.com/get-started/
-.. _docker-compose: https://docs.docker.com/compose/overview/
 .. _uWSGI: http://uwsgi.readthedocs.org/
 .. _Let's Encrypt: https://letsencrypt.org/
 .. _NGiNX: https://www.nginx.com/
diff --git a/docs/reference/money-types.rst b/docs/reference/money-types.rst
@@ -4,8 +4,8 @@
 Money Types
 ===========
 
-Until **django-SHOP** version 0.2, amounts relating to money were kept inside a ``Decimal`` type
-and stored in the database model using a ``DecimalField``. In shop installations with only one
+In earlier versions of **django-SHOP**, amounts relating to money were kept inside a ``Decimal``
+type and stored in the database model using a ``DecimalField``. In shop installations with only one
 available currency, this wasn't a major issue, because the currency symbol could be hard-coded
 anywhere on the site.
 
@@ -15,7 +15,7 @@ it is very common to make mistakes by mixing different currencies. It also is co
 incorrect conversions that generate wrong results. Python doesn't allow developers to associate a
 specific decimal value with a unit.
 
-Starting with version 0.9, **django-SHOP** now is shipped with a special factory class:
+Starting with version 0.9, **django-SHOP** is shipped with a special factory class:
 
 
 MoneyMaker
@@ -31,7 +31,7 @@ Not a Number
 ------------
 
 In special occurrences we'd rather want to specify "no amount" rather than an amount of 0.00 (zero).
-This can be useful for free samples, or when an item is currently not available. The Decimal type
+This can be useful for free samples, or when an item currently is not available. The Decimal type
 denotes a kind of special value a ``NaN`` – for "Not a Number". Our Money type also knows about
 this special value, and when rendered, ``€ –`` or ``$ –```` is printed out.
 
@@ -55,12 +55,12 @@ Create a Money type
 	>>> print(Money('1.55') + Money('8'))
 	€ 9.55
 
-	>>> print Money
+	>>> print(Money)
 	<class 'shop.money.money_maker.MoneyInEUR'>
 
 	>>> Yen = MoneyMaker('JPY')
 	>>> print(Yen('1234.5678'))
-	¥ 1235
+	¥ 1,235
 
 	>>> print(Money('100') + Yen('1000'))
 	ValueError: Can not add/substract money in different currencies.
@@ -74,8 +74,8 @@ using one of the official ISO-4217 currency codes.
 Alternatively, we can create our own Money type, for instance ``Yen``.
 
 
-Formating Money
----------------
+Formatting Money
+----------------
 
 When the amount of a money type is printed or forced to text using ``str(price)``, it is prefixed
 by the currency symbol. This is fine, when working with only a few currencies. However, some symbols
@@ -96,9 +96,7 @@ formatting string.
 Localizing Money
 ================
 
-Since the Money class doesn't know anything about our current locale setting, amounts always are
-printed unlocalized. To localize a Money type, use ``django.utils.numberformat.format(someamount)``.
-This function will return the amount, localized according to the current HTTP request.
+Depending on our current locale setting, amounts are printed using a localized format.
 
 
 Money Database Fields

diff --git a/docs/reference/order.rst b/docs/reference/order.rst
@@ -491,8 +491,6 @@ template named ``<myshop>/admin/orderitem-product-extra.html`` is used as fallba
 is provided, then the content of these extra fields is not rendered.
 
 
-
-
 Re-adding an Order to the Cart
 ==============================
 

diff --git a/docs/reference/shipping-providers.rst b/docs/reference/shipping-providers.rst
@@ -8,3 +8,4 @@ Unless you use the merchant management systems for delivery, **django-SHOP** pro
 add shipping providers. Shipping providers require that the Delivery model is available, otherwise
 there is no way to keep track which items have been shipped with a delivery.
 
+Version 0.13 has a complete and working implementation for a shipping provider.
diff --git a/docs/reference/special-cms-pages.rst b/docs/reference/special-cms-pages.rst
@@ -6,7 +6,7 @@ Special CMS Pages
 
 Besides the Catalog-, Cart- and Checkout Views, some pages must be accessed from already prepared
 templates, which are shipped with this framework. These templates use the templatetag
-``{% page_url %}`` shipped by djangoCMS with some hard coded IDs. Unless we want to rewrite those
+``{% page_url %}`` shipped by **django-CMS** with some hard coded IDs. Unless we want to rewrite those
 templates, we must provide a few special CMS pages, where we specify those page IDs.
 
 

diff --git a/docs/reference/worker.rst b/docs/reference/worker.rst
@@ -4,9 +4,9 @@
 Working off Asynchronous Jobs
 =============================
 
-A merchant implementation running **django-SHOP**, usually runs a few asynchronous jobs, such as
+A merchant implementation serving **django-SHOP**, usually runs a few asynchronous jobs, such as
 cleaning stale entries, sending e-mail and building the search index. In Django, there are many
-ways to handle this, usually by integration `Celery into Django`_. However, a Celery setup is
+ways to handle this, usually by integrating `Celery into Django`_. However, a Celery setup is
 unnecessarily complicated and usually not required. Instead we can handle all of our asynchronous
 jobs using a short Python script, referred to as "The Worker" in the documentation. This
 stand-alone program runs in the same environment as our Django app.

diff --git a/docs/tutorial/catalog-views.rst b/docs/tutorial/catalog-views.rst
@@ -208,7 +208,7 @@ Connect the Serializers with the View classes
 
 Now that we declared the serializers for the product's list- and detail view, the final step is to
 access them through a CMS page. Remember, since we've chosen to use CMS pages as categories, we had
-to set a special **djangoCMS** apphook_:
+to set a special **django-CMS** apphook_:
 
 .. code-block:: python
     :caption: myshop/cms_apps.py

diff --git a/docs/tutorial/polymorphic-product.rst b/docs/tutorial/polymorphic-product.rst
@@ -121,7 +121,7 @@ Model for a generic Commodity
 
 For demo purposes, this polymorphic example adds another kind of Product model, a generic Commodity.
 Here instead of adding every possible attribute of our product to the model, we try to remain as
-generic as possible, and instead use a ``PlaceholderField`` as provided by **djangoCMS**.
+generic as possible, and instead use a ``PlaceholderField`` as provided by **django-CMS**.
 
 .. code-block:: python
     :caption: myshop/models/commodity.py
Original file line number	Diff line number	Diff line change
Expand Up		@@ -491,8 +491,6 @@ template named ``<myshop>/admin/orderitem-product-extra.html`` is used as fallba
		is provided, then the content of these extra fields is not rendered.




		Re-adding an Order to the Cart
		==============================

Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -8,3 +8,4 @@ Unless you use the merchant management systems for delivery, django-SHOP pro
		add shipping providers. Shipping providers require that the Delivery model is available, otherwise
		there is no way to keep track which items have been shipped with a delivery.

		Version 0.13 has a complete and working implementation for a shipping provider.