Re: difficulties with Gnome Translation

[Stanislav Visnovsky <visnovsky nenya ms mff cuni cz>]

On 27 Apr 2002, Christian Rose wrote:

> > The kdelibs.po file contains all messages from KDElibs. These will show in
> > the application as when the app uses standard KDE library. This is how KDE
> > gets the consistent translation. The most used texts are stored in
> > kdelibs!
>
> This is also how it's done in GNOME -- developers can choose from the
> "stock" menus for example (in that case they will be translated
> centrally) or use their own (in that case it will be localized in the
> application).

Are there any "janitors" to look for unnecessary app-specific menus?

>
>
> > In fact, GNOME 2 is heading in the same direction via all those
> > libgnome... libbonobo...
>
> This was also the situation before, but maybe it's more apparent in
> GNOME 2.

I'm aware of GNOME 1 situation :-)). The problem with GNOME 2 is that
it introduces a lot of library names based on technologies, typical
example is "bonobo". How can a translator find out, that "bonobo"-related
libraries are used in most of GNOME 2 apps?

In GNOME 1 it was all about gtk+ and gnome-libs, wasn't it?

>
>
> > etc. But in GNOME, the consistency is pretty hard
> > to get, since the number of libraries is very large.
>
> Perhaps... in any case, the use of translation memories should help
> consistency.

Partially. You need a glossary as well. And the best glossary are those
implemented in the libraries. Otherwise it makes a lot of work to find out
and fix the problems.

>
> > In GNOME, the translator needs to know CVS a bit better, needs to update
> > ChangeLogs, configure.in (!!), typically POTFILES.in etc. Then, there is
> > that gnome-i18n (but that's another story).
>
> How is the handlling of configure.in done in KDE? Is it scripts or does
> someone else have to add it manually? In this case, I prefer manually
> editing myself, because then I know that the current CVS version and all
> subsequent releases *will* use my translation, and not depend on someone
> else remembering to enable it.

IMHO, KDE contains it's own catalog handling (I'm not an kdecore expert,
ask Stephan Kulow for details). The application simply does something like
setCatalog("myapp"). The kdelibs will try to lookup the correct .MO file.
It means, you don't need the information about the catalog at the compile
time (but that's true for all GNU gettext apps, right?).

So it's about the makefiles. You need to dig into the automake/autoconf
stuff of kde-i18n module, but I think it installs all PO files it can find
at the automake/autoconf/configure run at the right places.  The PO files
are not named by language, but by the application-specific way (typically
by the name of the app). The language info is in the path of the PO file
location.

>
>
> > Now back to that "messages" subdirectory. KDE uses poxml application to
> > convert DocBook documentation into PO-files and vice versa. Again,
> > there are automatic scripts to create the translated documentation and
> > put it into correct place in CVS.
>
> This looks very interesting. I think we discussed this with the KDE
> developer but if I remember correctly there was some technical reason
> that the KDE solution to this couldn't automatically be used by GNOME.
>

I think it was about Qt again. But the source itself uses Qt for streams
only. You need to ask Stephan, he's the maintainer and author, but we
should not reinvent the wheel.

>
> > BTW, in KDE the languages MUST reach a defined level of completeness to be
> > distributed = 100% of kdelibs.po, desktop.po and 80% (or 100%?) of
> > all POT files in kdebase. There is 71 teams listed at
> > http://i18n.kde.org/teams/index.php.
>
> This sounds similar to the GNOME rules -- I think we have decided in the
> past that to be "supported" a translation must reach 75% status. Sadly,
> i18n.gnome.org seems to be non-functional, so I cannot check for sure.

But "supported" does not mean anything. Even non-supported languages will
get into the distribution.

Stanislav