mingw/gettext/Admin/plans - kiwivm - Git at Google

 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
	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