i18n of bzr

[Alexander Belchenko]

Alexander Belchenko пишет:
> Ian Clatworthy пишет:
>> INADA Naoki wrote:
>>
>>> Translation of html docs is already started.
>>> But I think translation of "bzr help xxx" may helps many people too.
>>
>> FWIW, the Bazaar User Reference is completely built from the help
>> topics. So translating the help topics is a stepping stone to
>> translating that bigger document.
>>
>> As well as the docs, the trickier bit is translating the error, warning
>> and information messages. It would be good if the feedback the commands
>> presented inside QSubprocess dialogs was translated. We need to do that
>> in a way that doesn't impact performance so always loading "gettext"
>> probably won't get landed. We could add a global bzr option though, e.g.
>> something like --lang or --i18n, so that better I18N support could
>> optionally be enabled.
> 
> No. There is 3 major problems around i18n problem from my experience 
> with QBzr.
> 
> 1) The worst thing here is Python itself. This language due of his 
> runtime nature to execute everything is worst possible choice for i18n 
> of applications.
> 
> There is a lot of strings that should be marked for translations, e.g. 
> with no-op function _N(), but every _N() call anyway will sum up and 
> slow-down python imports and therefore startup time of bzr.
> 
> Actual translation should be done right before self.outf.write() or 
> trace.note() calls. It won't affect performance too much.
> 
> 2) There is "wrong" design decision in bzr itself to put help for 
> commands in the class docstrings. This decision today is main 
> show-stopper for localizing these helps. Docstrings should be converted 
> to plain strings first, i.e. major API break of commands required. This 
> is a lot of work.
> Furthermore it affects most of existing plugins.
> 
> 3) Testing? I think any special testing for i18n can be omitted. If 
> existing tests check english texts -- they should continue to do so. But 
> special tests for ensure i18n works will be nightmare.

On the bright side: many help topics today live in bzrlib/help_topics/en 
directory and ready to be translated without serious changes in bzr 
core. So, the simplest way right now might be: convert all other 
standalone topics to plain texts, put them into bzrlib/help_topics/en, 
and add some simple support to help subsystem to allow switch between 
language directories. There is no need even to learn gettext, because 
it's a plain text files. Just encode them in utf-8 always.

As I remember some core devs don't like putting help topics in the plain 
files, but precedent is done already and I think this resistance can be 
surmount.