Re: difficulties with Gnome Translation

[Christian Rose <menthos menthos com>]

lör 2002-04-27 klockan 21.54 skrev Isam Bayazidi:
> > > - 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.
> 
> Well in KDE we put all the PO files for our language in one place in the CVS 
> tree .. that is in the kde-i18n/ar/messages .. that really ease the life of 
> the traslation team maintainer .. all I have to do to check the files in is 
> to do a 'cvs commit' while I am in the kde-i18n/ar .. while with Gnome 
> approch, I have to either commit each file in seperate

I don't understand why this is a problem. When I update translations, I
do it one by one, so I commit them one by one too.


> or to have a tree structure that is semilar to the Gnome CVS tree structure,
> that would sparce the PO files :-)

I actually have both. :)
I have a directory tree with the code locally that resembles how it's
stored in cvs (that I normally use and that I update from cvs) and also
a "flat" directory with symbolic links to all Gnome translations. I use
the second one for easy generation of the translation memory and for
presenting on the web (http://www.menthos.com/po/gnome/). But that's all
I use it for. And adding symlinks is easy.


> take note that we have our own CVS .. and we commit our changes to
> the Gnome CVS priodly ..

That may be part of why you experience the GNOME setup and the syncing
with it as troublesome, I think. To someone that doesn't have to sync
the contents with a local cvs with an entirely different layout the
process is a bit easier, I presume.


> > > 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.
> 
> Well the languages that got translated enough to be shiped is 50+ languages .. 

Ok.


> while I doubt that this number of langauges will be with Gnome .. I think 
> that the translation in Gnome is taken care by developers :-) developers like 
> it the best way and that is not the easy way :-) I think that it can be 
> simplified ..

It of course depends on how you define "developer". If the definition is
that it's someone who has learnt to use cvs branches effectively, then I
think "yes". But yes, it can be simplified.


> Think about what I have to do every commit to Gnome:
> 1) grab the latest POT files by wget

You don't have to do that. Just grab the latest ar.po from the status
pages. They are already merged.


> 2) msgmerge with our current PO files

The status pages takes care of that.


> 3) check them in to the different module/po one by one ..

As translations are usually worked upon one by one by a single
translator or independantly by several translators, they are usually
never completed at the same time. So I don't see why you have to commit
them by the same time, just commit them one by one as they are finished.


> I can not use the module.ar.po ( that I can get my wget too) which is the 
> translation file for the module in Arabic becuase it will be outdated as all 
> the translation occure in our CVS rather than Gnome CVS ..

Isn't then the problem really that you do your work in your local cvs,
with a totally different structure and procedure, instead of the Gnome
one? Most of the problems you report seems to be based in this setup,
and I don't really think that it is "general problems" with the Gnome
translation procedure.


> now the latest POT for each module have different names each time .. 
> module.HEAD.pot today could be module.NEW_TAG.pot tomorrow ..

I can see that this will be a problem if you try to fetch pot files over
http. But you can get the module information and filename information
from gnome-i18n/status/translation-status.xml in cvs and based on that I
think it would be rather straightforward to make your script know the
filename of the file to fetch.


> I guess that 
> discluding the TAG from the file name would be better, as it will be known 
> that the "status" will always include the latest, without the need to 
> refering to which tag it is from ..

That's true, but I think the branch name in the file name helps avoid
mistakes when later committing files, so that the translation does not
get into the wrong branch by accident.


> but again I am not from this world (Gnome World) so I may not know the reasons 
> why things are this way .. but I am trying to overcome these difficulties ..

Discussion is the first step. :-)


Christian