Op donderdag 13-09-2007 om 12:34 uur [tijdzone +0530], schreef
Ankitkumar Rameshchandra Patel:
Dimitris Glezos લખ્યું:
> Στις 12-09-2007, ημέρα Τετ, και ώρα 18:14 -0300, ο/η Domingo Becker
> > Is it possible to have a cron job to merge POT changes into PO files ?
> I think it is possible, and in fact even someone from us could do it
> every now and then, right?
> If we get to build something that can be run from one person and get it
> to become a bit mature and work right, then a cron could run it too, and
> Infra will be more willing to try it out than writing it from
> scratch. :)
1. Why can't we run the existing automerge script running on
Well we could keep that one up and running, just for the modules on
i18n.r.c, but for the others that have moved this could become a bit
problematic, we would need to have a script for each VCS. The automerge
script works great for CVS, if it could be ported to git, hg, svn, ...
it would be a start. Although that would make us responsible for keeping
it working, keeping the weight off Infra
> On the other hand, this might not be optimal for a number of
> throws a big weight on Infra to maintain it, for example, and it should
> work across VCSs with the ability to commit. From this point of view, it
> sounds like something Transifex could do: Transifex is a translator-side
> tool (in contrast to a maintainer or administrator-side tool) *with*
> access to a lot of VCSs. It would be trivial to ask transifex "which
> modules need merging?" and have it do a for loop and commit since most
> of the code is there. Anyone willing to write a patch? :)
2. I could give a try, definitely take a longer time for me as out of
touch now. OR someone who's expert in programming can jump in...
Looks like a very logical thing to do. OTOH this would include some
extra work for translators before they can get started doing any real
translation: check with Transifex *if* the PO is up to date, if not run
the sync, get the file, translate, commit, ...
> Also, to give another dimension to the issue: an even more
> (and logical) approach would be to do it right from the start (the
> PO/POT creation): urge more developers to use intltool, and for those
> modules that intlool can't be used (for a variety of reasons), the
> person/script that updates the POT should update the POs as well.
3. You are right. That's the best option. Developers/Package
maintainers are not doing it for some reason i don't know.
+1, scratch out the middle-man
> My 2 cents.
I think the preference order for these solutions should be 3, 1,
2...What do you say?
Yeah, fair enough
Bart <couf(a)fedoraproject.org> <couf(a)skynet.be>
key fingerprint: 6AAB 544D 3432 D013 776D 3602 ADB6 6B2A D93F 0F93