Marking translatable strings

[François Pinard]

aahz at netcom.com (Aahz Maruch) writes:

> Y'know, it might help those of us with an interest in I18N but little
> actual experience if you posted some resources that gave information
> about what the heck a "PO file" is and how one is suposed to generate
> and access it in other languages.

Oh!  Sorry.

A PO file is just a holder for original untranslated messages accompanied by
their translated equivalent, given a precise language and textual domain.
A textual domain corresponds to a package, more or less.  Some bigger
packages, like Gnome, use many textual domains, but this is rather unusual.

A PO file having only empty strings for translated equivalent is called a
POT file, of PO template.  The usual course of action is producing a POT
file for a given package by automatic means, and making it available to
national teams.  Each team might decide to produce a PO file out of the
POT file for its own language.  Usually, PO files are returned to package
maintainers for inclusion in the distribution (often, but not necessarily,
using the Translation Project as a kind of broker, for a few reasons).

PO files have a rather precise format.  There is a header entry (technically,
the translation of the empty string) which holds administrative information,
and the Translation Project enforces it rather strictly.  This is all
documented within the `gettext' manual.  I made an HTML copy available as:

   http://www.iro.umontreal.ca/contrib/po/HTML/gettext.html

What I'm trying to do is to set up whatever necessary so I can write
internationalised Python scripts, in such a way that it fits well in
the above setup.  The reasons are rather egotistic, as I like writing
scripts in English so I can share them with my friends all over, so I can
make good use of their feedback, while still using French on my screen.
But of course, it benefits everybody that scripts be internationalised.

> Personally, if you want to accomplish anything useful in the 1.6
> timeframe, I think you'll be best off creating some sort of I18N module
> or package [...]

I get that a few already exist for Python (:-), and there is not much to
do in that area.  I'll explore this more deeply in a few weeks.  For now,
I'm just exploring how to fit the holes so we have all the needed pieces.
Consolidation should follow soon.

> This does ignore the big problem of doc strings, but IMO doc strings
> should be used more by programmers than end-users -- I *don't* like them
> for printing output.

Following the advice of others, I already found that doc strings at the
module level make a nice device for implementing --help options, while
providing summary documentation right in the modules.  Doc strings are
really human readable text, and might be well worth translating.  However,
for a well-doc-stringed package, they may be fairly numerous, and as you say,
more oriented towards the programmers than end users.  They would also cause
a significant burden on translators.  This is quite debatable.  For GNU
Emacs, say, we have tens of thousands of strings, including doc strings,
in this makes Emacs message translation pretty daunting.  As it is already
difficult for a few other reasons, I'm not holding my breath on this one.

Python code might be more manageable, and a nice testbed for such problems.
Mailman is a sizeable package, and for the little I've seen of it, seems
to cover many interesting and new aspects.  So, more it goes, more I'm
looking forward for Mailman internationalisation :-).

> In any event, I don't think you can solve this problem in the pre-2.0
> timeframe, though it's certainly worth laying the groundwork now.

I'm not especially looking for synchronicity with Python releases, and
moreover, not everybody will switch to 2.0 at once.  I now rather think
we can do a great deal without any need to modify Python, and we should
dive now, to acquire experience, data, measurements, and better ideas!

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard