Re: difficulties with Gnome Translation

[Christian Rose <menthos menthos com>]

mån 2002-04-29 klockan 11.17 skrev Stanislav Visnovsky:
> > > 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?

Not that I know of, but I'm no expert on that.


> > > 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?

It was decided that for a lot of reasons multiple libraries that can be
independantly released and maintained if needed are better for this and
other reasons, than single monolithic libraries. And bonobo is a core
GNOME library and should thus be listed in the core GNOME 2.0
translation status (or a development platform status). Anything in that
list should be considered essential to translate IMHO.


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

I haven't experienced that problem.


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

I think GNOME chose the manual way instead of some magic automatic thing
because sometimes a po file can be broken, but that shouldn't stop an
important release, so it is good to have an easy way to remove the po
from the build instead of having to remove it from cvs or the tarball
(since it's easier to fix for someone later if it's still present in cvs
or tarballs).


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

I think it was Stephan we asked at GUADEC2. :-)


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

"Supported" does mean a thing. It means that this is a language that has
good support in GNOME. And if we simply don't ship languages that
haven't reached that status yet, it's hard to improve that situation for
those languages, because it's hard to test and get an idea of what to
improve if the translations are removed, IMHO.


Christian