[PATCH 0 of 5] i18n patches

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> On Sat, 2009-01-10 at 01:26 +0100, Martin Geisler wrote:
>
>> * Patch 2 ensures that the output is encoded in the user's local
>>   encoding (as given by HGENCODING, LANG, LC_ALL, ...).
>
> This one puzzles me. Shouldn't we instead be choosing a locale file
> based on LANG and LC_CTYPE? It seems that if this were the right thing
> to do, gettext would be doing it for us as everything using it would
> need it.

Right, I could have explained it better: Gettext provides three methods:

* gettext  -> returns 8-bit string in catalog's encoding
* lgettext -> returns 8-bit string in system's encoding (Python 2.4 only)
* ugettext -> returns Unicode string

We want an 8-bit string encoded in util._encoding and util._encoding is
based on HGENCODING and locale.getpreferredencoding() as appropriate.
Since lgettext is not there in Python 2.3 I made it myself.

>> * Patch 3 adds new targets to the Makefile for updating the hg.pot (PO
>>   template) file and to generate xx.mo files. I've added these files
>>   to the .hgignore file.
>
> Is there any reason I'd ever run update-mo directly rather than just
> 'make'? If not, then we needn't add help for it.

Maybe the translators would like to run it?

But then maybe not: they might find it easier to use whatever .po -> .mo
translator they have and then copy the result to the appropriate
directory under locale. So we could remove the help for my sake.

>> * Patch 4 adds a rough Danish translation.
>
> Looks like this lives in po/, which seems like an unfortunate directory
> name. Can we come up with something better?

I think this is the common name for translations, but I agree that it is
silly :-) We could calls it 'translations' (long but clear) or 'i18n'
(nice and short).

>> * Patch 5 adds a test case. One *must* run 'make update-mo' after
>>   applying this patch, otherwise the test case will fail. The problem
>>   is that run-tests.py use the setup.py script to install, and that
>>   script does not know anything about generating the .mo files.
>
> Oh, look, an answer to my question. Yeah, we want run-tests.py to just
> work. So we can either hack setup.py or run-tests.py

It would be easiest to change run-tests.py, but more correct to change
setup.py so that 'python setup.py install' could still give a complete
install.

The update-pot target calls pygettext.py, a program which ships with the
Python source. The Debian package installs it as pygettext, but I cannot
find it on a RedHat install at my university.

Would it be okay if we include pygettext.py and msgfmt.py directly with
Mercurial? They seem very stable with no change in 2 and 4 years:

  http://svn.python.org/view/python/trunk/Tools/i18n/

That would make it easier for the translators who needs to generate the
hg.pot file. Alternatively we could put the hg.pot file under version
control like I have seen in most projects. The a translator just need to
copy hg.pot to xx.po and start translating. Translating xx.po -> xx.mo
is easy, but extracting the Python docstring is not.

>>   I could go in and hack run-tests.py and make it run the Makefile.
>>   That would add 'make' and 'msgfmt' to the required_tools in
>>   run-tests.py, maybe making it even harder to port the tests.
>> 
>>   I could also skip the test if no translation is found.
>
> Probably. It's not really important that we test a particular
> translation, just that _() works.

Yes. The current test also makes sure that Gettext transcodes the text
properly: the da.po file is in Latin1, but the test asks and tests for
UTF-8 output.

> Let's figure out the directory name issue, then get patches 1, 3, and
> 4 in. Then we can figure out what the right answers for 2 and 5 are,
> ok?

Definitely. I think we have a good answer for 2, but 5 is more up for
discussion.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090110/3cc678ee/attachment.pgp