[Merge] lp:~songofacandy/bzr/i18n into lp:bzr

[Alexander Belchenko]

Vincent Ladeuil пишет:
> (forwarding to the list instead while keeping Daniel in CC so the
> discussion occurs in a more appropriate place).
>>>>>> Alexander Belchenko  writes:
> 
> <snip/>
> 
>     > What's intltool? That's one: https://launchpad.net/intltool ?
>     > Is it work on Windows? Mac?
> 
> Does it have to ?

The more important question is: does bzr project need this tool? 
According to its description it can help to extract strings from:

  o Extract translatable strings from various source files (.xml.in,	
    .glade, .desktop.in, .server.in, .oaf.in).
	
  o Collect the extracted strings together with messages from traditional
    source files (.c, .h) in po/$(PACKAGE).pot.
	
  o Merge back the translations from .po files into .xml, .desktop and
    .oaf files.  This merge step will happen at build resp. installation
    time.

See http://bazaar.launchpad.net/~intltool/intltool/trunk/view/head:/README

AFAIK, none of those are applicable to bzr command-line client. Am I 
wrong here?

> May be we can provide the resources needed by the installers without
> requiring the toolchain to run on all supported platforms ?

What's about developers who want to test/fix/improve i18n stuff?

> <snip/>
> 
>     > Because _ has special meaning in PDB. Why does it matter?
> 
> Given all the comments received on this topic I've started to wonder if
> we shouldn't revisit it.
> 
> We *did* encounter issues when we first started to use gettext for
> bzr-gtk and at this time gettext was exporting '_' in a way that was
> causing troubles. I can't remember the details right now but roughly the
> issue was that using '_' as a no-name variable anywhere was overriding
> gettext '_' definition so the next use of '_' (in a totally different
> scope) was suddenly broken.
> 
> But is still the case for recent versions of gettext and python ?

Why it should be changed? If you look closely on documentation for 
gettext module you will never see description of _() function, because 
it's just handy alias which can be installed into global namespace with
gettext.install()

http://docs.python.org/library/gettext.html?highlight=gettext#gettext.install

But I suppose this tradition comes from C gettext usage where _() is 
just handy macros which is converted to proper call of gettext() 
function at *compile* time.

Python does not have compile time in the same way as C/C++ has. And this 
is very bad, because it happens in runtime. Don't think that wrapping 
every line into _() won't have negative effects, as we know the best way 
to achieve good performance in Python is to avoid doing work, not doing 
unneeded work. And on each module import we have to pay for each 
unneeded _() call. I see this as very major pitfall of python gettext.

> If using '_' for l10n is the most common practice in python projects we
> may want to adopt it (if only because some tools may work better in this
> case (wild guess)).

Standard xgettext happily extract strings wrapped into either _() or 
gettext().


-- 
All the dude wanted was his rug back