[Gforge-devel] Switched to gettext

Roland Mas lolando at debian.org
Tue Mar 13 16:26:20 EDT 2007


  Hi all,

I've just sent a rather large commit on the trunk, converting Gforge's
internationalisation system from the home-made one to the standard
gettext infrastructure.  The goals are multiple:

  First, by using a standard system, we can hope to attract more help
from translators, who'll be able to use their standard tools for
editing the *.po files (either Poedit, or Kbabel, or Pootle, or
Emacs's po-mode, or whatever).

  Then, we should be able to get rid of the problem of missing
strings: the code doesn't contain (possibly misspelled) references to
strings stored in another file, it contains the strings themselves.
So, in the worst case, we get a non-translated string, but we should
be done with empty/missing strings.  Also, gettext tools are able to
detect missing and obsolete strings, so it should be far easier to
detect such problems.  And we should be rid of the problem of *.tab
files that contain spaces instead of tabs.

  Finally, gettext does provide functions and features to deal with
various l18n problems, such as the variety of plural forms depending
on the language.  I seem to remember we have some special cases in the
code to handle "1 foobar" vs. "2 foobars", but I can't find them right
now -- they could theoretically be coalesced into one call to a single
function, and the translation files should be able to specify which
form to use depending on n.

  In more concrete terms, here's how to do i18n from now on:

- Don't use $Language->getText() anymore.  It's still there, but let's
  consider it deprecated.

- Instead, if you want to display a translatable string, just use
  _("the string") (the _() function is a shorter alias for gettext(),
  and is provided by PHP).

- Periodically, or when new strings have been added, run
  ../tools/update-gettext-files.sh; it'll regenerate the message
  catalog in translations/gforge.pot, and update the translation files
  in translations/xx.po (where xx is the language code, possibly xx_XX
  for variants such as Brazilian Portuguese or traditional/simplified
  Chinese).  These *.po files are the ones the translators should work
  on.

- When the translators have done their job, and sent updated *.po
  files, run ../tools/make-mo.sh, which will regenerate the
  locales/xx/LC_MESSAGES/gforge.mo files.  These files should be
  installed into /usr/share/locale/xx/LC_MESSAGS/gforge.mo, so that
  gettext finds them (if that path is liable to change -- although I
  doubt it, it seems pretty standard across Linux distros --
  BaseLanguage.class should be updated accordingly).

- A few complex calls to $Language->getText() haven't been converted
  to gettext yet.  That's the main reason I left the current
  infrastructure operational as a backup.  I'm considering adding a
  warning to getText(), so the string it actually returns is what's in
  the *.tab file plus a marker making it visible.

- Also, a few strings were missing from Base.tab.  They have been
  converted to stuff like this example, taken from CVSPlugin.class:
  _('MISSINGTEXT:plugin_scmcvs/documentation:TEXTMISSING').  These
  strings should be easy to grep for, and ugly enough when displayed
  to motivate us all to fix them :-)

  Plugins hosted in the gforge.org SVN trunk are internationalised the
same as the rest of the core code.  For external plugins, the
procedure will be slightly more complex.  Since they can't depend on
their strings being present in the main catalog, they'll need to use
another "domain".  In other words, they won't be able to simply use
_("foo bar"), but they'll have to use the longer
dgettext("gforge-plugin-foobar", "foo bar") instead; also, they'll
need to provide gforge-plugin-foobar.mo files and declare that gettext
domain around the initialisation time of the plugin.  I guess I'll try
and code that on an "external" plugin.

  I've built Debian packages out of this current state, and they do
seem to work as expected.  The remaining work is to finish the
transition by working on the difficult cases.

  Hope you'll like it!

Roland.
-- 
Roland Mas

If you spit in the air, it lands in your face.
  -- Tevye, in Fiddler on the roof


More information about the Gforge-devel mailing list