third_party_gettext/Admin/plans

Things we plan to do. Comments welcome.

- Documentation: Distinguish more clearly between gettext/xgettext,
  the Translation Project for GNU packages, and the PO mode.

- Look at Christian Robottom Reis's manual:
  http://www.async.com.br/~kiko/gettext.html

- KBabel:
  http://i18n.kde.org/translation-howto/gui-specialized-apps.html
  http://i18n.kde.org/tools/kbabel/

- Tool to help people to correct msgid strings:
  1. Program to move msgstr contents to msgid contents,
  2. Program to update the translations accordingly, much like msgmerge.

- Mention Qt linguist (part of Qt 3)

- Easier delivery of PO directory for maintainer! Add a target for incoming
  PO files

- Qt 3.0 compatibility:
  - .ts, .qph catalogs, example: http://dooble.svn.sourceforge.net/viewvc/dooble/trunk/browser/translations/
  - .qm binary catalogs

- Add logging to libintl, in order to catch each of these problems:
>         - if the directory that was argument to bindtextdomain is usable
>         - what catalogs are installed there
>         - if the language , that is requested by LC_ALL or some other
>                 variable is really there ...
>         - if program tries to translate some message, it doesn't really know 
>                 if it really get translated ... And if requested more than 
>                 one language , you have no way to realize into what
>                 language, it had been really translated !!!!!!!

- msgdiff
  People recommend the 'poediff' program from Pology:
  http://pology.nedohodnik.net
  which supports merging the diff back to the PO

- automake integration: Add to "make dist" an invocation of
  "intltool-update --maintain", parametrized through a few variables that
  specify
    - where to look for i18n files,
    - which file types are to be considered by i18n,
    - which files are explicitly not i18n (e.g. generated files like
      src/po-gram-gen.c)

- Generating sr@latin PO file automatically from sr.po.

- XLIFF support

- object-oriented locale datatype, similar to giulia/glocale

- automatic download at installation time of PO files that have been
  provided by the translators after the official release.

- Conversion of compendia from/to TMX format.

- Support some of the conversions found in the translate-toolkit package, see
    http://translate.sourceforge.net/wiki/nonpo

- xgettext should have a simpler way to specify the --flags.

- man page pgettext.3

- po-mode.el: Editing of msgstr[i] plural forms, and setting of formula.

- The recode-* programs and msggrep should ignore the accelerator char
  transparently.
  a word is divided by shortcut symbol (like "Raści_ahni") that will be
  converted incorrectly (like "Расьці_агні", not "Расьц_ягні")

- PO spell checker. People recommend:
  - 'pospell' - qui ne gère apparemment pas les accents
  - gettext-lint / POFileSpell - qui fonctionne mais le contexte est
    trop court
  - une version mise à jour de
    http://lists.debian.org/debian-l10n-french/2000/04/msg00058.html
    (qui date de 2000 quand même - voir en fin de message) - pas mal,
    mais pas moyen de sauvegarder ni même de s'arrêter avant la fin du
    .po
  - pofilter
  - acheck

- An alternative converter for Java .properties files.
  E.g.
    error.socket.connect=Cannot connect socket
    error.database.connect=Cannot connect to database {0}
  ->
    msgctxt "error.socket.connect"
    msgid "Cannot connect socket"
    msgstr ""
    msgctxt "error.database.connect"
    msgid "Cannot connect to database {0}"
    msgstr ""

- For people who use a 15 MB large compendium:
  Add an msgmerge option --cache-compendium, which stores (during the
  first run) or reuses (during subsequent runs) an mmapable file that
  represents the index of the compendium file. Should be located in
  /var/tmp/, in a filename that is a hash of the realpath of the compendium.

- Translating via an intermediate language (see thread 2006-09-28):
  > For my language alone, there are many possible translators who would  
  > work much better from Chinese or Russian to Vietnamese than from  
  > English. It's simply a matter of which languages you have had the  
  > opportunity to learn.

  Now _that_ is an interesting idea!

  Gettext can already nearly do this, too, if you write three small scripts/
  programs to
    - convert an English-based .pot file into a Russian-based .pot file,
    - convert an English->Vietnamese PO file to a Russian->Vietnamese PO file,
      (to be used when such a translator starts her work),
    - convert an Russian->Vietnamese PO file back to an English->Vietnamese PO file
      (to be used when a translator is done with her work).
  And then the translator has these additional conversions steps all the time.

  It would be better, for the future, that the translator has only one
  additional step to perform: When she gets a new PO file, she converts it
  to a mixed English/Russian->Vietnamese PO file. Such a mixed
  English/Russian->Vietnamese PO file would
    1) permit the translator to peek into the English original when something is
       unclear,
    2) also work when not some of the Russian translations are missing or fuzzy,
    3) get rid of the "convert back" step, since msgfmt could directly grok
       the mixed English/Russian->Vietnamese PO file.

  The syntax for a mixed PO file could like this:

  msgid "Hello, world!"
  msgid[ru] "Здравствуй, мир!"
  msgstr "Chào thế giới !"

- filter-sr-latin should transform the resulting output to NFC form.
  Needed because the input may contain decomposed Cyrillic accented letters.

- In x-c.c, support C++0x escape sequences, see
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm

- Use libunistring as hard dependency.

- Texinfo document translation, through TexinfoXML.

- A way to hook xgettext to call external scanner written in the
  target programming language.  This would be particularly useful for
  scripting languages which need run-time information to extract
  strings.  Some programming languages already provide their own
  scanners: pygettext in Python, rgettext in Ruby.

- Make xgettext XML handling extensible through user ITS files
  https://lists.gnu.org/archive/html/bug-gettext/2014-06/msg00026.html

- 3-way merge tool for PO files
  msg3way was proposed by Panos Christeas
  https://lists.gnu.org/archive/html/bug-gnu-utils/2010-11/msg00051.html