Re: Re[6]: gnome-control-center problem


El vie, 08-03-2002 a las 03:53, Wang Jian escribió:
> 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.

You don't need a checkout every time, only when you see something like
the gnome-control-center problem. Those changes are not done all days.


> 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

They look funny ;-) (I don't understand your language).

Well, if you want latest .po files, status pages give you them (as KDE
does). We have to reactivate the GNOME 1.4 stats, I know.

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

Because it will cause that we will had a really big cvs repository. you
can had a .po file with the same strings but if someone changes code,
the .po file changes (the comments) and this could fill's
hard disk with data that it's not useful.

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

Have you read the cvs-commits-list? sometimes the number of commits
inside a modules is so high that you will be all day refreshing the
.pot/.po files and we disable the status pages because the high load of
widget (a really good machine, dual PIII with 512Mb RAM).

The idea I have in my mind (thanks for some suggestions from Owen) is
that we will refresh only the modules that had been modified since last
rebuild. This way, perhaps we could update the status pages two times in
one day.
> >> "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.

It's the same as status pages does. The KDE's .po files are packaged one
time in a day (I think) so it's the same we have at
but you can choose which files you want instead of dowload a big tar.gz

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

The, download only the .po files.


> -- 
>   lark
> _______________________________________________
> gnome-i18n mailing list
Carlos Perelló Marín
Valencia - Spain

This is a digitally signed message part

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