Re[6]: gnome-control-center problem



Hello Christian,

Friday, March 08, 2002, 8:48:51 AM, you wrote:

CR> I think someone already explained that this is something that has to do
CR> with cvs includes.
CR> If you get an error with missing files no matter how many times you cvs
CR> update, you should try deleting the module and cvs checkout it again.
CR> Chances are that files are missing because of cvs weirdness, but a fresh
CR> checkout will almost always solve this kind of problems.
CR> If the file is missing also on a fresh checkout, only then you can be
CR> sure that it's probably a bug.

I think you are some way right, but not for anyone. I often work on
gnome translation at home, with 56k modem. So fresh checkout takes
long. But I will do as you suggest in the future, even if it is
painful.

>> Second, when intltool 0.17 addresses the glade2 new format file issue,
>> why no one metion the IMPORTANCE to apply it, because otherwise POT
>> will not correct?

CR> Simply because you should ALWAYS use the latest intltool relase if you
CR> translate gnome, due to the nature of intltool and the problem it tries
CR> to solve.

CR> Intltool extracts all translatable messages from all kinds of different
CR> source formats, not just plain C code and the other stuff gettext itself
CR> manages to extract from. So when new formats are created and used in
CR> gnome code, intltool has to be updated to cope with them and do the
CR> right thing with them. And so it usually is. Thus, in order to be able
CR> to translate all of the bleeding edge gnome code, you always have to use
CR> the latest intltool release.

CR> Kenneth even sends announcements of new intltool releases also to this
CR> list, so that you don't have to be subscribed to gnome-announce to get
CR> announcements of new intltool releases.

I saw the announcement. I didn't pay much attention because I didn't
know the importance. But I DO now.


CR> If you don't like to care about intltool releases, then just use the po
CR> files from the status page(s). The status pages and the statistics and
CR> po files on them are always generated with the latest intltool release
CR> (thanks to Carlos).

I know I can use that status page, but I maintain our zh_CN team's own
status page, which include gnome 1.x and gnome 2.0 modules and some
modules outside of GNOME CVS. See

http://i18n.linux.net.cn/gnome/status.php

>> Last, translator should not be forced to tweak with intltool, gettext,
>> msgmerge, and upgrade now and then. Why not create a system like KDE's
>> kde-i18n module ?
>> 
>> I am not rant to some specific one. I just mean, why not make the
>> status page a cvs module? translator translates po, that is all, no
>> more, no less.

CR> Granted, I don't know the exact details of the kde-i18n model, but I
CR> think you can already get most of the benefits of this by using the
CR> gnome-i18n status pages and the po files on them. There you have all the
CR> po files in one central place, it's updated daily, and you don't have to
CR> care about intltool and gettext if you don't want to.

I mean, why not commit pot/po files in the status page into a CVS
module?

CR> There are benefits of using the more direct way of po files in the
CR> application modules too. It's more direct and easier to find
CR> gettext-related bugs in the code, and it's immediate: If a developer
CR> says "application release in two days" there is no need to wait for the
CR> daily update of the po file and waste time; you can cvs checkout the
CR> application module and run intltool-update immediately, and contribute
CR> an updated translation in less than two minutes.

This can be solved by using trigger files. When developer commits
trigger file, a script can be run in CVS just on this module, and
update the POT/PO files immediately.

>> "make the status page a cvs module", that is, create a module, which
>> only contains pot and po. pot is updated when neccessary, and po is
>> merged with new pot when necessary. status page generation will be
>> very simple (anyway, the current stauge page system should have done
>> these thing already. a little step ahead is enough).

CR> Yes, I'm not sure what you are suggesting that isn't already provided by
CR> the status pages.

By checkout a module, i.e 'gnome-i18n', all up to
date templates and translation is there. A script in the module can
help him know what the status is and whether he should update.

>> See the difference only from data size
>> 
>> gw:~$ du -s gnome
>> 618411  gnome
>> gw:~$ du -s kde/kde-i18n
>> 36282   kde/kde-i18n

CR> What do you keep in these directories?


gnome/ contains all modules I checkout for gnome translation. Everyday
I run cvs update in gnome/, and that takes 20+ minutes.

kde/kde-i18n/ contains only template & translation for docs and POT/PO.
I run cvs update in kde/kde-i18n/templates/ and kde/kde-i18n/zh_CN/,
that takes less than 2 minutes.


-- 
  lark




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]