Re: difficulties with Gnome Translation

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

On 27 Apr 2002, Christian Rose wrote:

>
> > - Template files that are available through http have inconsistent file names,
> > they are names : modulename.cvstag.pot .. and the cvs tag could be HEAD or
> > any Tag, knowing that each module got it's own tag.. while all KDE modules
> > are taged with the same tag name each release ..
>
> Most Gnome modules are very much independant software with their own
> maintainers, their own development, and their own release plans. That
> said, there are guidelines for how branches should be named, but I fail
> to understand how it should be possible for all modules to use the same
> branch schemes since it's different software and most of them are in
> different phases of development.

But a large number of them are trying to be a part of the official GNOME
(I think those on "unstable" for GNOME 2). All these should TRY to use
the same branches (as is partially done for GNOME 1.4).

>
>
> > - Translated PO files are inconsistent places in the module tree, checking in
> > changes is not an easy job.
>
> How is this? I'm not aware of any module that doesn't use
> module_name/po/ for storing po files, except gnome-i18n but that's a
> very special case anyway.

and GIMP.

>
>
> > Please do not understand that I am to compare between KDE and Gnome, I truly
> > like the Gnome way, and highly appreciate everyones efforts in making this
> > great environment.. but I wanted to express the difficulties we faced moving
> > from KDE Traslation to Gnome Translation ..
>
> No, I think we all appreciate the input. I am at least. :) It's
> interesting to get reports about the KDE translation process. We
> discussed the KDE process with a KDE developer (sorry, don't remember
> the name) at GUADEC2 but the differences in the process compared to the
> GNOME one are big I think (more on that later). So I think this may be
> the cause why it's difficult to adapt the benefits from one system to
> the other.
>
> KDE has a vastly different translation process (this is all from my
> understanding of it). They group translations from modules into larger
> "metamodules" with huge pot files that the translators translate. These
> ones are typically at least updated before each major KDE release. This
> gives translators less headache in knowing on how to deal with cvs
> branches, but it removes some of the fine-level granularity in deciding
> on what to translate (if metamodule A includes important messages in the
> software B but also uninteresting ones in C and D it may be difficult to
> organize the work after importance). This is at least from my
> understanding of it after the discussions with the KDE developer.
>
> On the other hand, GNOME lets each application store its own
> translations and lets the application always release often and
> independently with its own latest translations, and the GNOME-level
> cross-organization of translation is provided by the different
> translation status reports that lists what module version belongs in
> which GNOME release. This gives more work with cvs branches but gives
> more control to the translator, that can choose more freely on what to
> translate and when.

In KDE CVS, there is a module kde-i18n. Each team has its own
subdirectory, e.g. "sk". There is also a "templates" subdirectory, where
are stored all POTs from the whole CVS by their relative placement (module
name / directory in the module ), e.g. kdebase/kcontrol.pot.

The translated files are stored in the same structure but in the team's
directory. For example, Slovak translation of KControl is in
kde-i18n/sk/messages/kdebase/kcontrol.po
(don't care about "messages" ATM). This makes it easy to create a packages
for a given team, but it makes pretty hard to make a release of an
application with all its translations (KDE releases the whole suite, GNOME
CVS is more fragmented as I've pointed out already).

Then, there is a file desktop.po, which contains all the translatable
parts of .desktop files. In GNOME, we've got intltools to get this into PO
itself. The .desktop files are regularly updated at KDE CVS.

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! In fact, GNOME 2 is heading in the same direction via all those
libgnome... libbonobo... etc. But in GNOME, the consistency is pretty hard
to get, since the number of libraries is very large.

In summary, KDE centralized approach makes it easy for translator to get
the work done. All other parts are scripts and a few great, hard working
guys. You can translate each app on its own, provided you have already
translated kdelibs.po.

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

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.

The DocBook/PO conversion makes the difference. I've translated over 50
application manuals in KDE myself this way, since I can use the PO tools
(translation memory etc). Are those doctools in GNOME CVS about the same
process?

If you have any questions, please ask. But I think, GNOME can reach
similar ease for translators and retain the current fragmented
development approach.

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.

Stanislav

>
> As I said, this is all my understanding of it, feel free to correct the
> errors in what I described.
> >From this point of view, I prefer the current GNOME model, simply
> because I as a translator don't have infinite time resources and want
> better control of what I choose to translate, and I think the GNOME
> model gives this.
> An example of this would be xscreensaver -- most of the messages in the
> xscreensaver module are names and descriptions of various screensavers,
> and I don't consider them to be important to translate, at least not
> compared to many other UI messages that are more visible. I thus would
> hate if the xscreensaver module got bundled together with other modules
> in a larger meta-module -- suddenly the untranslated screensaver
> messages would consume time that are better needed for more important
> messages.
>
>
> > and with all my respect to
> > everyones effort, it seems that KDE did a great job i18n wise and that lead
> > to have around 50 languages shiped with the latest KDE 3 release..
>
> If I count the locales listed on the current GNOME unstable status
> pages, I get the number 61 if I counted correctly.
>
>
> > The KDE team realised that the ones that are doing Translation work are
> > translators, not developers, and facilitated the translation job for
> > them..
>
> I understand that simplification of the process is needed, but I'd hate
> if more fine-grained control of translation priorites was sacrified in
> the process. In that sense, I think the current GNOME model is
> beneficial for translators in that it gives translators the possibility
> to prioritize their work themselves. Not that it cannot be improved, it
> can, but I'm not convinced that the KDE scheme is a total win for
> translators.
>
>
> Christian
>
> _______________________________________________
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>

-----------------------------------------------------------
Stanislav Visnovsky
Faculty of Mathematics and Physics
Charles University, Prague