Bazaar

Code review comment for lp:~songofacandy/bzr/i18n

i18n
Merge into bzr.dev

Revision history for this message

Alexander Belchenko (bialix) wrote on 2011-05-06:

David Planella пишет:
> I've been asked to provide some feedback and answer any questions, so I'll focus on those rather than reviewing the actual code.
>
> Here are a couple of things that caught my eye:
>
> Standard i18n Tools Integration
> -------------------------------
>
> It strikes me that you seem to rewrite much of the functionality provided by gettext and other tools already.
> Is there a reason why you are not using something like intltool

What's intltool? That's one: https://launchpad.net/intltool ?
Is it work on Windows? Mac?

> and python-distutils-extra (e.g. using the build_i18n command from p-d-e instead of writing extras/build_mo.py),
> which are used by most OSS Python projects implementing i18n support? Is it because of platform compatibility issues?

What is restrictions of the build_i18n? Can it be extended/customized?

> Why do you use the gettext() call directly instead of the more usual _()?

Because _ has special meaning in PDB. Why does it matter?

> Why is extras/bzrgettext needed?
> The file is very well documented, but I'm not sure I can follow
> why standard gettext cannot be used.

What is standard gettext? xgettext? This one is unable to extract
docstrings without wrapping them into gettext() calls.

> May I ask you to ellaborate on this?
>
> The same with bzrlib/utextwrap.py, what's its purpose?

This is one is required to deal with multibyte characters. Some
(Japanese) unicode characters are actually require 2 positions on the
screen, so if you need to wrap long string using the width of the
terminal then you need to take care of multibyte characters, because
len(string) != len(visible characters).

> Note that I'm not arguing that you are doing anything wrong,
> I'm just wondering if we could make use of more standard practices
> in the internationalization world.

Can you provide some guidelines or hints/tips then?

> Integration with Launchpad
> --------------------------
>
> It just makes sense to have bzr use all the Launchpad integration
> features regarding translations.
> For this, at the code level the only thing that is needed is to:
>
> * Have a tool in the build system that can extract translatable strings from the code and merge them into a bzr.pot template file
> * Have the right source tree layout:
>
> po/bzr.pot
> po/jp.po
> po/de.po
> po/pt_BR.po
> ...
>
> Where translations are in the same directory as the .pot file and are named with iso 639 2-letter or 3-letter codes, with an optional country code name.
>
> The rest can be done at the Launchpad project level and it's up to the bzr project admins:
>
> * Set up the translation focus and permissions: my recommendation would be Restricted or Structured, assigned to the Launchpad Translators group
> * Set up automatic translation imports, so that on every commit of the bzr.pot file translations are exposed in Launchpad
> * Set up automatic exports, so that translations can be exported to a branch of your choice automatically (currently daily). My recommendation would be to use the same branch for imports and exports, so that the manual intervention in managing translations is reduced to 0 in this aspect.

Can you tell us how Launchpad shows the translatable strings in its UI:
do they shown in the same order as they are present in PO file, or
Launchpad could sort/shuffle them as it thinks appropriate?

What's about translating really long texts, say 10 or more lines? What
will be the best strategy? Split them into hunks or keep as one block?
Will our hunks be shown in the LP following each other or this is not
guaranteed?

--
All the dude wanted was his rug back

David Planella пишет:
> I've been asked to provide some feedback and answer any questions, so I'll focus on those rather than reviewing the actual code.
> 
> Here are a couple of things that caught my eye:
> 
> Standard i18n Tools Integration
> -------------------------------
> 
> It strikes me that you seem to rewrite much of the functionality provided by gettext and other tools already. 
 > Is there a reason why you are not using something like intltool

What's intltool? That's one: https://launchpad.net/intltool ?
Is it work on Windows? Mac?

> and python-distutils-extra (e.g. using the build_i18n command from p-d-e instead of writing extras/build_mo.py), 
> which are used by most OSS Python projects implementing i18n support? Is it because of platform compatibility issues?

What is restrictions of the build_i18n? Can it be extended/customized?

> Why do you use the gettext() call directly instead of the more usual _()?

Because _ has special meaning in PDB. Why does it matter?

> Why is extras/bzrgettext needed? 
 > The file is very well documented, but I'm not sure I can follow
 > why standard gettext cannot be used.

What is standard gettext? xgettext? This one is unable to extract 
docstrings without wrapping them into gettext() calls.

> May I ask you to ellaborate on this?
> 
> The same with bzrlib/utextwrap.py, what's its purpose?

This is one is required to deal with multibyte characters. Some 
(Japanese) unicode characters are actually require 2 positions on the 
screen, so if you need to wrap long string using the width of the 
terminal then you need to take care of multibyte characters, because 
len(string) != len(visible characters).

> Note that I'm not arguing that you are doing anything wrong, 
 > I'm just wondering if we could make use of more standard practices
 > in the internationalization world.

Can you provide some guidelines or hints/tips then?

> Integration with Launchpad
> --------------------------
> 
> It just makes sense to have bzr use all the Launchpad integration 
 > features regarding translations.
 > For this, at the code level the only thing that is needed is to:
> 
> * Have a tool in the build system that can extract translatable strings from the code and merge them into a bzr.pot template file
> * Have the right source tree layout:
> 
> po/bzr.pot
> po/jp.po
> po/de.po
> po/pt_BR.po
> ...
> 
> Where translations are in the same directory as the .pot file and are named with iso 639 2-letter or 3-letter codes, with an optional country code name.
> 
> The rest can be done at the Launchpad project level and it's up to the bzr project admins:
> 
> * Set up the translation focus and permissions: my recommendation would be Restricted or Structured, assigned to the Launchpad Translators group
> * Set up automatic translation imports, so that on every commit of the bzr.pot file translations are exposed in Launchpad
> * Set up automatic exports, so that translations can be exported to a branch of your choice automatically (currently daily). My recommendation would be to use the same branch for imports and exports, so that the manual intervention in managing translations is reduced to 0 in this aspect.

Can you tell us how Launchpad shows the translatable strings in its UI: 
do they shown in the same order as they are present in PO file, or 
Launchpad could sort/shuffle them as it thinks appropriate?

What's about translating really long texts, say 10 or more lines? What 
will be the best strategy? Split them into hunks or keep as one block? 
Will our hunks be shown in the LP following each other or this is not 
guaranteed?

-- 
All the dude wanted was his rug back

« Back to merge proposal