Josep Puigdemont wrote:
On Fri, 2003-12-05 at 01:48, Noriko Mizumoto wrote:
>Please let me remind the steps for software translation.
>- Declair the po file_name which you are going to start at this ML, so
>that other translators would not touch.
Do we have to do that? This could be a mess if I miss a message for some
reason, and lot of traffic in which most of the members of the list will
no be interested.
For the moment it's advisable until better procedures have been employed
by your language team.
Moreover Fedora's Translation Project web page states:
"The place to discuss the translation of software is fedora-devel-list.
The place to discuss the translation of documentation is
Is this the right list to post such notes about software translation?
Couldn't we create a i18n specific list?
And wouldn't it be better to create language translation teams so each
team can organize themselves and make sure no double efforts are made?
Yes. The mailing lists for each language is a much better option. We
have requested them to be set up. Once done, I will update the webpage
> "eg, I will start the file, translate/anaconda/anaconda-po/ja.po.
>Pls let me know if someone already is working on."
>- Commit the file. $cvs commit -m '<your message>' file_name.po
>- Advise your completion at this ML.
>You have to checkout just before starting translation, the files have
>been kept updating.
>Please commit the file frequently even if you still are working on it,
>especially for larger file.
>(eg, cvs commit -m 'translating...' file_name.po)
>Because engineer may touch the file and commit while you are working,
>and then you will have conflict.
I am no expert but, aren't there tools to do this? like intltool‐merge,
What Noriko meant was that if you were working on some large file that
need days even weeks work, it's better to commit it regularly rather
than do it when finished because the po files may be auto updated during
this period thus causing conflict when you try to commit later. Although
there are ways to fix conflict situations it's still better to be avoid.
fedora-docs-list mailing list