Re[6]: gnome-control-center problem
- From: Wang Jian <lark linux net cn>
- To: Christian Rose <menthos menthos com>
- Cc: Gnome I18N List <gnome-i18n gnome org>
- Subject: Re[6]: gnome-control-center problem
- Date: Fri, 8 Mar 2002 10:53:37 +0800
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]