[RFC] I18N specification draft

[Carlos Perelló Marín]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again,

Alexander Belchenko escribió:
> Martin Pool ?8H5B:

[...]

> 
>>> Internationalization of bzrlib should be transparent for others clients.
>> Meaning that bzrlib will use whatever locale is globally set without
>> any special action by the client program?
> 
> No. Function _() is not defined by default. So when client import bzrlib
> it should itself install some _() function, otherwise when it reach
> string _('Foo') bzrlib raise NameError exception.
> 
> I think we can solve it very easily:
> 
> 1) Drop backward compatibility with older bzrlib versions without i18n,
> and nag all clients of bzrlib install _() themself before import bzrlib
> 
> Or:
> 
> 2) Add simple check at the top of bzrlib/__init__.py:
> 
> if getattr(__builtins__, "_", None) is None:
>     setattr(__builtins__, "_", lambda x: x)
> 
> Or something similar with try-except block.


- From other python applications in Ubuntu, in concrete gnome-app-install,
I see that they do something different:

import gettext
from gettext import gettext as _

Then, the initialisation keeps using gettext package's functions so I
guess that's much simple than your proposal.

Other than that, please, read my comments in my previous email about how
to use gettext for libraries.

[...]

> 
>> Another code area to consider is the smart server.  We want errors
>> that originate on the server to be displayed in the right language.
>> That seems to imply either the client tells the server what language
>> it wants, or we always pass language-neutral messages (eg exception
>> names plus parameters, or template strings plus parameters.)
> 
> Smart server should send english messages, and client will convert
> it to localized form simply by calling _() function:
> 
> locale_msg = _(english_message_from_server)
> 
> There is some tricks described in python documentation with redefining
> of _() function locally to have access to original english string
> instead of translated one. It's easily doable. Actually I use such trick
> in my bzr-config utility, because I use some strings for 2 purposes:
> 
> * english veriant used as dict keys,
> * localized variant used in GUI
> 

That's tricky, this means you need to maintain the strings in sync
between bzr and the smart server. I think both are in the same source
tree, so that should be easy, except for the case when you use different
versions of bzr and the smart server... Anyway, in worse case, that
would only mean that some messages would still be in English.

>> I've heard in the past some systems have trouble with programs
>> changing locales while they run, will this be a problem for us in
>> testing?
> 
> I think we should run our tests without importing gettext at all,
> ao we should skip this problem at all.

Well, as the spec suggest, you just need to set the LC_* and LANGUAGES
vars pointing to C and that should be enough, no need to do code changes
for testing.

> 
>> Aside from that, it looks good and I'd be happy to proceed along these
>> lines.
> 
> OK. My first plan is to create minimal infrastructure to produce
> PO template, and then set template in Rosetta. Because initial import
> takes very long time we could even import bzr.pot with 2-3 messages
> and then update it regularly (update is much faster operation).

As said in previous email, it shouldn't take so long now.

Cheers.

> 
> [µ]

- --
Carlos Perelló Marín
Ubuntu => http://www.ubuntu.com
mailto:carlos.perello at canonical.com
http://carlos.pemas.net
Alicante - Spain
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGsHAZEuPMamD5V9cRAqVFAJ9VIXBROgnV27zQu+CRE2drI5d5ygCcDRVs
/OojdigCLyDO4mYVRMJMUw0=
=F2yz
-----END PGP SIGNATURE-----