diff I18N_PROGRESS.txt @ 2343:52ed57de26db

still incomplete, but much more verbose
author Alexander Smishlajev <a1s@users.sourceforge.net>
date Wed, 19 May 2004 20:27:55 +0000
parents 29f4f349a1f5
children 75049c2f7cfc
line wrap: on
line diff
--- a/I18N_PROGRESS.txt	Wed May 19 17:24:52 2004 +0000
+++ b/I18N_PROGRESS.txt	Wed May 19 20:27:55 2004 +0000
@@ -2,36 +2,104 @@
 Roundup Internationalization Notes
 ==================================
 
-:Version: $Revision: 1.7 $
+:Version: $Revision: 1.8 $
+
+Overview
+--------
+
+How stuff works:
 
-FIXME: add introduction - what's l10n, i18n, po, mo, pot, gettext...
+1. Strings that may require translation (messages in human language)
+   are marked in the source code.  This step is discussed in
+   `Marking Strings for Translation`_ section.
+
+2. These strings are all extracted into Message Template File
+   ``locale/roundup.pot`` (POT file).  See `Extracting Translatable
+   Messages`_ below.
 
-Used Tools
-----------
+3. Language teams use POT file to make Message Files for national
+   languages (PO files).  All PO files for Roundup are kept in
+   the ``locale`` directory.  Names of these files are target
+   locale names, usually just 2-letter language codes.  `Translating
+   Messages`_ section of this document gives useful hints for
+   message translators.
 
-We use ``xpot`` utility from Francois Pinard free `PO utilities`_
-to build message template file.  ``pygettext`` utility included
-with Python distribution is not used because it has several limitations:
+4. Translated Message Files are compiled into binary form (MO files)
+   and stored in ``locale`` directory (but not kept in the `Roundup
+   CVS`_ repository, as they may be easily made from PO files).
+   See `Compiling Message Catalogs`_ section.
+
+5. Roundup installer creates runtime locale structure on the file
+   system, putting MO files in their appropriate places.
 
- - no way to mark strings translated elsewhere
- - does not detect translation done by an object method
- - source references put in the comments are not recognized
-   by translation software.
+6. Runtime internationalization (I18N) services use these MO files
+   to translate program messages into language selected by current
+   Roundup user.  Roundup command line interface uses locale name
+   set in OS environment variable ``LANGUAGE``, ``LC_ALL``,
+   ``LC_MESSAGES``, or ``LANG`` (in that order).  Roundup Web User
+   Interface uses language selected by currentluy authenticated user.
+
+Additional details may be found in `GNU gettext`_ and Python `gettext
+module`_ documentation.
+
+`Roundup source distribution`_ includes POT and PO files for message
+translators, and also pre-built MO files to facilitate installations
+from source.  `Roundup binary distribution`_ includes MO files only.
+
+.. _GNU gettext:
 
-Message translation can be done with `emacs`_ "po mode" provided
-by `PO utilities`_.  (als: i didn't try that personally.)
+GNU gettext package
+-------------------
+
+This document is full of references to `GNU`_ `gettext package`_.
+GNU gettext is a "must have" for nearly all steps of internationalizing
+any program, and it's manual is definetely a recommended reading
+for people involved in I18N.
 
-Another tool for message translation (als: one that i use) is `poEdit`_
-by Vaclav Slavik.
+There are GNU gettext ports to all major OS platforms.
+Windows binaries are available from ``GNU mirror sites``.
 
-.. _PO utilities: http://po-utils.progiciels-bpi.ca/
-.. _emacs: http://www.gnu.org/software/emacs/
-.. _poEdit: http://poedit.sourceforge.net/
+Roundup does not use GNU gettext at runtime, but it's tools
+are used for `extracting translatable messages`_, `compiling
+message catalogs`_ and, optionally, for `translating messages`_.
+
+Note that ``gettext`` package in some OS distributions (e.g.
+`FreeBSD`_) means just runtime libraries.  Development tools
+are usually distributed in separate package named ``gettext-devel``.
 
 Marking Strings for Translation
 -------------------------------
 
 Strings that need translation must be marked in the source code.
+Following sections of this chapter explain how this is done in
+different cases.
+
+Current status of the string marks in Roundup core files is shown
+in `I18 Status`_ section at the end of this document.
+
+If translatable string is used as a format string, it is recommended
+to always use named format specifiers::
+
+  _('Index of %(classname)s') % locals()
+
+This helps translators to better understand the context of the
+message and, in Python, remove format specifier altogether (which
+is sometimes useful, especially in singular cases of `Plural Forms`_).
+When there is more than one format specifier in the translatable
+format string, named format specifiers *must* be used almost always,
+because translation may require different order of items.
+
+It is better to *not* mark for translation strings that are not
+locale-dependent, as this makes it more difficult to keep track
+of translation completeness.  For example: following string in
+``index()`` method of the request handler in ``roundup_server``
+script::
+
+  </ol></body></html>
+
+has no human readable parts at all, and needs no translations.
+These strings are left untranslated in PO files, and are reported
+as such by PO status checkers (e.g. ``msgfmt --statistics``).
 
 Command Line Interfaces
 ~~~~~~~~~~~~~~~~~~~~~~~
@@ -47,20 +115,18 @@
 to use Roundup message catalogs.  This is normally done by including
 the following line in the module imports::
 
-  from i18n import _
+  from i18n import _, ngettext
 
 Simple translations are automatically marked by calls to builtin
 message translation function ``_()``::
 
   print _("This message is translated")
 
-*(not tested)* Translations for messages whose grammatical depends
-on a number must be done by ``ngettext()`` function::
+Translations for messages whose grammatical depends on a number
+must be done by ``ngettext()`` function::
 
   print ngettext("Nuked %i file", "Nuked %i files", number_of_files_nuked)
 
-*Discussion:* make ``i18n._()`` with the same interface as in ``config._()``?
-
 User Interfaces
 ~~~~~~~~~~~~~~~
 
@@ -69,17 +135,19 @@
 This includes Mail Gateway and Web User Interfaces, where translation
 depends on the language of current Roundup User.  These translations
 will be done by the tracker configuration object.  Translatable strings
-will be automatically marked by calls to the ``_()`` method of that
-object::
+will be automatically marked by calls to the ``_()`` and ``ngettext()``
+methods of that object::
 
   self.config._("This message is translated")
-  self.config._("Nuked %i file", "Nuked %i files", number_of_files_nuked)
+  self.config.ngettext("Nuked %i file", "Nuked %i files",
+      number_of_files_nuked)
 
 Deferred Translations
 ~~~~~~~~~~~~~~~~~~~~~
 
 Sometimes translatable strings appear in the source code in untranslated
-form and must be translated elsewhere.  Example::
+form [#note_admin.py]_ and must be translated elsewhere.
+Example::
 
   for meal in ("spam", "egg", "beacon"):
       print _(meal)
@@ -97,23 +165,39 @@
       multiline string"""
   )
 
-Building Message Catalog Template
----------------------------------
+.. [#note_admin.py] In current Roundup sources, this feature is
+   extensively used in the ``admin`` module using method docstrings
+   as help messages.
+
+Extracting Translatable Messages
+--------------------------------
 
-Message catalog template ``roundup.pot`` is kept in `Roundup CVS`_
-and distributed with `Roundup Source`_.  If you wish to rebuild
-the template yourself, you will need ``xpot`` utility by Francois
-Pinard, included in `PO utilities`_ distribution.
+The most common tool for message extraction is ``xgettext`` utility
+from `GNU gettext package`_.  Unfortunately, this utility has no means
+of `Deferred Translations`_ in Python sources.
+There is ``xpot`` tool from Francois Pinard free `PO utilities`_
+that allows to mark strings for `deferred translations`_, but
+it does not handle `plural forms`_.
+Roundup overcomes these limitations by using both of these utilities.
+This means that you need both `GNU gettext`_ tools and `PO utilities`_
+to build the Message Template File yourself.
 
-To rebuild the template file, just run ``gmake`` (or ``make``, if you
-are on a `GNU`_ system like `linux`_ or `cygwin`_) in the 'locale'
-directory.
+Latest Message Template File is kept in `Roundup CVS`_ and distributed
+with `Roundup Source`_.
+If you wish to rebuild the template yourself, make sure that you have
+both ``xpot`` and ``xgettext`` installed and just run ``gmake`` (or
+``make``, if you are on a `GNU`_ system like `linux`_ or `cygwin`_)
+in the ``locale`` directory.
 
-.. Roundup CVS: http://sourceforge.net/cvs/?group_id=31577
-.. Roundup Source: http://sourceforge.net/project/showfiles.php?group_id=31577
-.. GNU: http://www.gnu.org/
-.. linux: http://www.linux.org/
-.. cygwin: http://www.cygwin.com/
+Translating Messages
+--------------------
+
+FIXME!
+
+Compiling Message Catalogs
+--------------------------
+
+FIXME!
 
 I18 Status
 ----------
@@ -200,3 +284,24 @@
 test/test_templating.py
 test/unittest.py
 
+.. External hyperlink targets
+
+.. _cygwin: http://www.cygwin.com/
+.. _emacs: http://www.gnu.org/software/emacs/
+.. _gettext package: http://www.gnu.org/software/gettext/
+.. _gettext module: http://docs.python.org/lib/module-gettext.html
+.. _GNU: http://www.gnu.org/
+.. _GNU mirror sites: http://www.gnu.org/prep/ftp.html
+.. _FreeBSD: http://www.freebsd.org/
+.. _linux: http://www.linux.org/
+.. _Plural Forms:
+    http://www.gnu.org/software/gettext/manual/html_node/gettext_150.html
+.. _po filetype plugin:
+    http://vim.sourceforge.net/scripts/script.php?script_id=695
+.. _PO utilities: http://po-utils.progiciels-bpi.ca/
+.. _poEdit: http://poedit.sourceforge.net/
+.. _Roundup CVS: http://sourceforge.net/cvs/?group_id=31577
+.. _Roundup Source:
+.. _Roundup source distribution:
+.. _Roundup binary distribution:
+    http://sourceforge.net/project/showfiles.php?group_id=31577

Roundup Issue Tracker: http://roundup-tracker.org/