i18n of bzr

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