Hi,
As many of you mentioned before that the total number of entries varied a great deal across all locales. The reason was the po files were not kept consistent against corresponding pot files. I'm trying to find a solution to maintain the consistency. Here are some options:
a. Let each package maintainer perform "msgmerge" whenever pot file is updated
b. I set up a cron job to "msgmerge" all locales and all packages (nightly or weekly)
c. Each locale coordinator to ensure all packages in that locale is consistent and up to date
d. Each translator to perform "msgmerge" prior translation
Personally I prefer option b, because I can ensure all updates will be performed. The downside of it is the possible file conflicts. However, if we agree upon a specific time to perform this update, and we all try to avoid this time to commit works, most conflicts can be avoided.
Please let me know which option you prefer.
Thanks, Sarah
On Thu, 2005-02-17 at 13:12 +1000, Sarah Wang wrote:
a. Let each package maintainer perform "msgmerge" whenever pot file is updated
This is doable, I just think it causes pain for translators due to CVS conflicts.
b. I set up a cron job to "msgmerge" all locales and all packages (nightly or weekly)
This causes lots of noise for developers trying to actually watch CVS commits. And in cases where things haven't changed, it's kind of counter-productive because gettext isn't all that smart about noticing that things haven't really changed.
c. Each locale coordinator to ensure all packages in that locale is consistent and up to date
d. Each translator to perform "msgmerge" prior translation
c/d seem like the best from a perspective of minimizing changes and conflicts.
Personally I prefer option b, because I can ensure all updates will be performed. The downside of it is the possible file conflicts. However, if we agree upon a specific time to perform this update, and we all try to avoid this time to commit works, most conflicts can be avoided.
It's not a matter of avoiding the time to commit works, you have to avoid _working_ on things then. And if you have something underway that's not committed, you have to do silly tricks with copying your work, cvs updating and then re-msgmerge'ing.
My $0.02.
Jeremy
On Thu, 2005-02-17 at 13:42, Jeremy Katz wrote:
On Thu, 2005-02-17 at 13:12 +1000, Sarah Wang wrote:
a. Let each package maintainer perform "msgmerge" whenever pot file is updated
This is doable, I just think it causes pain for translators due to CVS conflicts.
If this is doable and all pkg maintainers are disciplined enough, I certainly think it's the best solution.
b. I set up a cron job to "msgmerge" all locales and all packages (nightly or weekly)
This causes lots of noise for developers trying to actually watch CVS commits. And in cases where things haven't changed, it's kind of counter-productive because gettext isn't all that smart about noticing that things haven't really changed.
Point taken.
c. Each locale coordinator to ensure all packages in that locale is consistent and up to date
d. Each translator to perform "msgmerge" prior translation
c/d seem like the best from a perspective of minimizing changes and conflicts.
It won't work for those locales don't have a maintainer/coordinator, or in case the translators are not very Technical but have good languages skills. We still want people to join the project and work on the latest files.
Personally I prefer option b, because I can ensure all updates will be performed. The downside of it is the possible file conflicts. However, if we agree upon a specific time to perform this update, and we all try to avoid this time to commit works, most conflicts can be avoided.
It's not a matter of avoiding the time to commit works, you have to avoid _working_ on things then. And if you have something underway that's not committed, you have to do silly tricks with copying your work, cvs updating and then re-msgmerge'ing.
Sure, dealing with conflicts are always quite painful ;) I don't enjoy it either. I'm happy to adopt the option that is most effective and least intrusive.
Sarah
Hi Sarah.
On Thu, Feb 17, 2005 at 01:12:35PM +1000, Sarah Wang wrote:
Hi,
As many of you mentioned before that the total number of entries varied
Are you talking about statistics webpage? If so, then what about fixing the statistics generator to perform msgmerge while generating reports? That practice is common with many other translation projects, for example GNOME's GTP at http://l10n-status.gnome.org/
a great deal across all locales. The reason was the po files were not kept consistent against corresponding pot files. I'm trying to find a solution to maintain the consistency. Here are some options:
d. Each translator to perform "msgmerge" prior translation
e. Download current po file from the webpage.
Options d and e together should be sufficient. Translators already knows tools like intltool-update or msgmerge. If that is not a case then they could download current (and updated) po file from the web.
Regards.
On Thu, 2005-02-17 at 15:38, Marcel Telka wrote:
Hi Sarah.
On Thu, Feb 17, 2005 at 01:12:35PM +1000, Sarah Wang wrote:
Hi,
As many of you mentioned before that the total number of entries varied
Are you talking about statistics webpage? If so, then what about fixing the statistics generator to perform msgmerge while generating reports? That practice is common with many other translation projects, for example GNOME's GTP at http://l10n-status.gnome.org/
Yes, I'm referring to the status page. It pulls information from cvs every 15 minutes. It might put too much load on the system to perform msgmerge at the same time.
a great deal across all locales. The reason was the po files were not kept consistent against corresponding pot files. I'm trying to find a solution to maintain the consistency. Here are some options:
d. Each translator to perform "msgmerge" prior translation
e. Download current po file from the webpage.
Options d and e together should be sufficient. Translators already knows tools like intltool-update or msgmerge. If that is not a case then they could download current (and updated) po file from the web.
Here is another option extending option d:
have auto pre-commit check, compare .po file with .pot file, if .po is not most up to date, commit will fail (perhaps allow it during grace period but give warnings). If the translator doesn't know how to do msgmerge, he/she can get help from the coordinator.
Would this option be better?
Sarah
On Thu, 2005-02-17 at 16:28 +1000, Sarah Wang wrote:
d. Each translator to perform "msgmerge" prior translation
e. Download current po file from the webpage.
Options d and e together should be sufficient. Translators already knows tools like intltool-update or msgmerge. If that is not a case then they could download current (and updated) po file from the web.
Here is another option extending option d:
have auto pre-commit check, compare .po file with .pot file, if .po is not most up to date, commit will fail (perhaps allow it during grace period but give warnings). If the translator doesn't know how to do msgmerge, he/she can get help from the coordinator.
Would this option be better?
I think that is a good option. But that only catches out of date files when you commit.
Perhaps doing a blanket update at various points during the dev process would be good. Such as weekly after a message freeze.
It would be nice to have some script or something on the stats page that specifies which PO files are out of date.
Hi,
If this msgmerge is coordinator job, then it is possible that this coordinator looks at webpage and will see that everything is ok and do not do any msgmerge.
And if someone uses poEditor under Windows, it is quite painfull process to open every file to merge.
Is it possible to add one button on the statistics page and only coordinator has access on it?. Pressing on it will merge all files under own locale. She/he can do it when ever a person wants it.
Or this "Entries" are taken from .pot files instead of .po files; others from .po files.
Allan Sims allsi@eau.ee
On Thu, Feb 17, 2005 at 04:28:53PM +1000, Sarah Wang wrote:
On Thu, 2005-02-17 at 15:38, Marcel Telka wrote:
Hi Sarah.
On Thu, Feb 17, 2005 at 01:12:35PM +1000, Sarah Wang wrote:
Hi,
As many of you mentioned before that the total number of entries varied
Are you talking about statistics webpage? If so, then what about fixing the statistics generator to perform msgmerge while generating reports? That practice is common with many other translation projects, for example GNOME's GTP at http://l10n-status.gnome.org/
Yes, I'm referring to the status page. It pulls information from cvs every 15 minutes. It might put too much load on the system to perform msgmerge at the same time.
We really need the status page updates every 15 minutes? GNOME does this only several times a day (two, three? I don't know exactly).
a great deal across all locales. The reason was the po files were not kept consistent against corresponding pot files. I'm trying to find a solution to maintain the consistency. Here are some options:
d. Each translator to perform "msgmerge" prior translation
e. Download current po file from the webpage.
Options d and e together should be sufficient. Translators already knows tools like intltool-update or msgmerge. If that is not a case then they could download current (and updated) po file from the web.
Here is another option extending option d:
have auto pre-commit check, compare .po file with .pot file, if .po is not most up to date, commit will fail (perhaps allow it during grace period but give warnings). If the translator doesn't know how to do msgmerge, he/she can get help from the coordinator.
Would this option be better?
I'm pretty happy with gnome style of the translation process, so I don't require such pre-commit check.
IMHO, any barrier between translator and CVS repository could be contraproductive. For example, I personally don't like the translation taking via webpage. One exception could be precommit check using `msgfmt -c file.po`.
Regards.
Em Quinta, 17 de Fevereiro de 2005 03:12, Sarah Wang escreveu:
b. I set up a cron job to "msgmerge" all locales and all packages (nightly or weekly)
That's the way it works in KDE (nightly, late in GMT night); I've been KDE's pt_PT coordinator for many, many years and I never had any problems with it.
About not filling the CVS commit list with garbage, in KDE we have the a special CVS_SILENT commit tag so that messages are not sent. So the msgmerge commit is be ran with something like: cvs commit -m "CVS_SILENT automatic msgmerge" Or you could ignore messages from a certain user, the msgmerge robot.
Anyway: without the automatic msgmerge you might as well remove the status page, it's useless.
Pedro Morais
Before we agree and implement anything, here is the script I use to do the updates. If you are the coordinator of a locale, you may find it helpful.
Usage: automerge.sh <locale>
You need to mv anaconda-help/help/ and system-config-date/timezone/ to its parent directory to produce a nice flat directory structure, and of course "cvs up" before running this script.
Sarah
Hello!
Dne četrtek 17 februar 2005 04:12 je Sarah Wang napisal(a):
a. Let each package maintainer perform "msgmerge" whenever pot file is updated
AFAIK this is the best way. Make could check if a pot file is newer than any of the the .po files and do msgmerge :).
-
Allan Sims -
dwayne＠translate.org.za -
Jeremy Katz -
Marcel Telka -
Pedro Morais -
Rok Papež -
Sarah Wang