[RFC] I18N specification draft

[Martin Pool]

> Please take a look on my draft:
> http://bazaar-vcs.org/DraftSpecs/I18nSupport

That looks great.

I don't know much about the translation side of it but I have some
thoughts on the code changes.  I've cc'd Carlos, one of the authors of
Rosetta, and maybe he can check your approach too from that aspect.

> help for commands

.. and for other help topics too.

> One BIG issue for bzrlib -- it's usage docstring as help for commands.

I have no objection to changing this.  We have already changed most if
not all exception classes.

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

> 4. Setup wrappers for stdout and stderr before emit localized messages to avoid UnicodeEncodeError when output of bzr is redirected

I imagine this refers to overriding the encoding if it's set to ascii
but the user's language can't be represented in ascii?  How will we
know what encoding to use?

> 5. Explicitly constructs error messages for errors based on standard Python's exceptions IOError, OSError. This task will require to reimplement all error messages that bzrlib handles in our codebase, because we need to have them in POT for translations, and because we need fine-grained control over constructing resulting localized error message

Can you please explain more about this point?  I thought that the
messages for python exceptions and os errors were already localized in
non-english locales?

To me the largest code issue not addressed by this is what to do with
the test suite.  Some ui-oriented tests want to assert about the
strings and need to be run in a known locale.  On the other hand we
probably want to test that the behaviour of most of the
non-user-facing parts are consistent regardless of the locale, or to
test them in any given locale.  The best course may be to first run
everything in a english utf-8 locale, then add some ui tests that
specifically work in other languages, then switch some non-ui-based
tests back to running in the environment's default locale.

In fact there is a recent bug about test isolation from locales.

  https://bugs.launchpad.net/bzr/+bug/111377

so we need to do this even now.

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

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?

Aside from that, it looks good and I'd be happy to proceed along these lines.

-- 
Martin