bpo-10536: Enhancements to gettext docs (GH-10324)

Author: matrixise

Doc/library/gettext.rst

@@ -13,7 +13,7 @@
 
 The :mod:`gettext` module provides internationalization (I18N) and localization
 (L10N) services for your Python modules and applications. It supports both the
-GNU ``gettext`` message catalog API and a higher level, class-based API that may
+GNU :program:`gettext` message catalog API and a higher level, class-based API that may
 be more appropriate for Python files.  The interface described below allows you
 to write your module and application messages in one natural language, and
 provide a catalog of translated messages for running under different natural
@@ -38,7 +38,7 @@ class-based API instead.
 
    Bind the *domain* to the locale directory *localedir*.  More concretely,
    :mod:`gettext` will look for binary :file:`.mo` files for the given domain using
-   the path (on Unix): :file:`localedir/language/LC_MESSAGES/domain.mo`, where
+   the path (on Unix): :file:`{localedir}/{language}/LC_MESSAGES/{domain}.mo`, where
    *languages* is searched for in the environment variables :envvar:`LANGUAGE`,
    :envvar:`LC_ALL`, :envvar:`LC_MESSAGES`, and :envvar:`LANG` respectively.
 
@@ -138,17 +138,16 @@ Class-based API
 The class-based API of the :mod:`gettext` module gives you more flexibility and
 greater convenience than the GNU :program:`gettext` API.  It is the recommended
 way of localizing your Python applications and modules.  :mod:`!gettext` defines
-a "translations" class which implements the parsing of GNU :file:`.mo` format
-files, and has methods for returning strings. Instances of this "translations"
-class can also install themselves in the built-in namespace as the function
-:func:`_`.
+a :class:`GNUTranslations` class which implements the parsing of GNU :file:`.mo` format
+files, and has methods for returning strings. Instances of this class can also
+install themselves in the built-in namespace as the function :func:`_`.
 
 
 .. function:: find(domain, localedir=None, languages=None, all=False)
 
    This function implements the standard :file:`.mo` file search algorithm.  It
    takes a *domain*, identical to what :func:`textdomain` takes.  Optional
-   *localedir* is as in :func:`bindtextdomain`  Optional *languages* is a list of
+   *localedir* is as in :func:`bindtextdomain`. Optional *languages* is a list of
    strings, where each string is a language code.
 
    If *localedir* is not given, then the default system locale directory is used.
@@ -172,10 +171,10 @@ class can also install themselves in the built-in namespace as the function
 
 .. function:: translation(domain, localedir=None, languages=None, class_=None, fallback=False, codeset=None)
 
-   Return a :class:`Translations` instance based on the *domain*, *localedir*,
+   Return a :class:`*Translations` instance based on the *domain*, *localedir*,
    and *languages*, which are first passed to :func:`find` to get a list of the
    associated :file:`.mo` file paths.  Instances with identical :file:`.mo` file
-   names are cached.  The actual class instantiated is either *class_* if
+   names are cached.  The actual class instantiated is *class_* if
    provided, otherwise :class:`GNUTranslations`.  The class's constructor must
    take a single :term:`file object` argument.  If provided, *codeset* will change
    the charset used to encode translated strings in the
@@ -241,7 +240,7 @@ are the methods of :class:`!NullTranslations`:
 
    .. method:: _parse(fp)
 
-      No-op'd in the base class, this method takes file object *fp*, and reads
+      No-op in the base class, this method takes file object *fp*, and reads
       the data from the file, initializing its message catalog.  If you have an
       unsupported message catalog file format, you should override this method
       to parse your format.
@@ -285,7 +284,8 @@ are the methods of :class:`!NullTranslations`:
 
    .. method:: info()
 
-      Return the "protected" :attr:`_info` variable.
+      Return the "protected" :attr:`_info` variable, a dictionary containing
+      the metadata found in the message catalog file.
 
 
    .. method:: charset()
@@ -340,15 +340,15 @@ The :mod:`gettext` module provides one additional class derived from
 :meth:`_parse` to enable reading GNU :program:`gettext` format :file:`.mo` files
 in both big-endian and little-endian format.
 
-:class:`GNUTranslations` parses optional meta-data out of the translation
-catalog.  It is convention with GNU :program:`gettext` to include meta-data as
-the translation for the empty string.  This meta-data is in :rfc:`822`\ -style
+:class:`GNUTranslations` parses optional metadata out of the translation
+catalog. It is convention with GNU :program:`gettext` to include metadata as
+the translation for the empty string. This metadata is in :rfc:`822`\ -style
 ``key: value`` pairs, and should contain the ``Project-Id-Version`` key.  If the
 key ``Content-Type`` is found, then the ``charset`` property is used to
 initialize the "protected" :attr:`_charset` instance variable, defaulting to
 ``None`` if not found.  If the charset encoding is specified, then all message
 ids and message strings read from the catalog are converted to Unicode using
-this encoding, else ASCII encoding is assumed.
+this encoding, else ASCII is assumed.
 
 Since message ids are read as Unicode strings too, all :meth:`*gettext` methods
 will assume message ids as Unicode strings, not byte strings.
@@ -452,7 +452,7 @@ take the following steps:
 
 #. run a suite of tools over your marked files to generate raw messages catalogs
 
-#. create language specific translations of the message catalogs
+#. create language-specific translations of the message catalogs
 
 #. use the :mod:`gettext` module so that message strings are properly translated
 
@@ -462,9 +462,8 @@ it in ``_('...')`` --- that is, a call to the function :func:`_`.  For example::
 
    filename = 'mylog.txt'
    message = _('writing a log message')
-   fp = open(filename, 'w')
-   fp.write(message)
-   fp.close()
+   with open(filename, 'w') as fp:
+       fp.write(message)
 
 In this example, the string ``'writing a log message'`` is marked as a candidate
 for translation, while the strings ``'mylog.txt'`` and ``'w'`` are not.
@@ -515,7 +514,7 @@ Localizing your module
 ^^^^^^^^^^^^^^^^^^^^^^
 
 If you are localizing your module, you must take care not to make global
-changes, e.g. to the built-in namespace.  You should not use the GNU ``gettext``
+changes, e.g. to the built-in namespace. You should not use the GNU :program:`gettext`
 API but instead the class-based API.
 
 Let's say your module is called "spam" and the module's various natural language
@@ -669,8 +668,9 @@ implementations, and valuable experience to the creation of this module:
 .. [#] The default locale directory is system dependent; for example, on RedHat Linux
    it is :file:`/usr/share/locale`, but on Solaris it is :file:`/usr/lib/locale`.
    The :mod:`gettext` module does not try to support these system dependent
-   defaults; instead its default is :file:`sys.prefix/share/locale`. For this
-   reason, it is always best to call :func:`bindtextdomain` with an explicit
-   absolute path at the start of your application.
+   defaults; instead its default is :file:`{sys.prefix}/share/locale` (see
+   :data:`sys.prefix`). For this reason, it is always best to call
+   :func:`bindtextdomain` with an explicit absolute path at the start of your
+   application.
 
 .. [#] See the footnote for :func:`bindtextdomain` above.

Misc/NEWS.d/next/Documentation/2018-11-04-22-03-56.bpo-10536.a0IsfE.rst

@@ -0,0 +1 @@
+Enhance the gettext docs. Patch by Éric Araujo