[PyQt] i18n

[Kovid Goyal]

On Wednesday 11 February 2009 14:58:16 Giovanni Bajo wrote:
> On mer, 2009-02-11 at 12:32 -0800, Kovid Goyal wrote:
> > On Wednesday 11 February 2009 12:05:13 you wrote:
> > > On 2/11/2009 8:14 PM, Kovid Goyal wrote:
> > > You'll be hard-pressed to find a Windows translation program better
> > > than Linguist. Do you have any suggestion? Did you personally evaluate
> > > Linguist and are aware of its features?
> > >
> > > (OK, Linguist can now import .po files too, but then I don't see the
> > > point of using an external translation package).
> >
> > The critical thing in open source projects is to make it as easy as
> > possible for volunteers to contribute translations. Launchpad allows you
> > to have a simple web based interface where they can contribute translated
> > strings easily. Plus it suggests translations for frequently used strings
> > across its entire database of available translations.
>
> Sure, but "open-source" doesn't say it all. I appreciate Launchpad very
> much, but in a business environment translations are carried on by
> professionals, so it's less important to manage 200 volunteers
> translating a couple of sentence each one at random times.
>

The OP was asking (as far as I can tell) about an open source project. And 
have you looked at lokalize recently?

> I'm not saying that your suggestion of using gettext is totally wrong:
> it's surely an option to consider. But there are advantages in the Qt
> translation toolchain too.
>
> > > Plus I'm not sure gettext has the advanced plural support (does it?).
> >
> > http://www.gnu.org/software/automake/manual/gettext/Plural-forms.html
>
> Thanks for the pointer.
>
> > > > This has the additional advantage of not tying in your translation
> > > > infrastructure to a graphical toolkit.
> > >
> > > Given how simple is to batch-substitute tr() to _() (so simple that
> > > you're even suggesting it yourself), I don't really see a point here.
> > > Converting the whole application to another toolkit would probably be
> > > much harder in the first place.
> >
> > What if your application has many parts, only some of which need a
> > graphical toolkit.
>
> Yes, this can be an issue. It's less problematic in C++, where you'd die
> for using QtCore everywhere you're allowed too anyway and thus have the
> translation functions available, but Python doesn't need it (mostly).
>
> I usually put workarounds in place to be able to use Qt's translation in
> the Qt-agnostic packages within a Qt-based application, but I agree that
> it is somewhat a problem.
>
> > What if you want to write different GUIs for different contexts?
>
> Different GUI with the same texts and thus reusing the same translation?
> Do you happen to know a single open source project that does this?

Two different GUIs wont share all strings, but they will have lots of strings 
in common. It would be silly to have the same strings being translated in two 
translation frameworks. And for an example look at calibre, which has both a 
GUI and a CLI and all strings are translated using gettext (a number of 
strings are common to both the GUI and the CLI).

Kovid.

-- 
_____________________________________

Kovid Goyal  MC 452-48
California Institute of Technology
1200 E California Blvd
Pasadena, CA 91125

cell  : +01 626 390 8699
office: +01 626 395 6595 (449 Lauritsen)
email : kovid at theory.caltech.edu
web   : http://www.kovidgoyal.net
_____________________________________