Le lundi 16 avril 2012 à 18:34 -0400, Shaun McCance a écrit : > On Mon, 2012-04-16 at 23:04 +0200, Bruno Brouard wrote: > > Le lundi 16 avril 2012 à 22:14 +0200, Andre Klapper a écrit : > > > On Mon, 2012-04-16 at 21:01 +0200, Bruno Brouard wrote: > > > > I am sorry, i don't understand what you mean. Is it possible to have an > > > > example? > > > > > > To put it into other words: > > > Shaun fixed something in Git, and the translators OVERWROTE the fix with > > > his/her next commit to Git. > > > > > Thank you again, I am not stupid :-) > > > > But Shaun speak specifically of "markup mistakes" and said > > "I don't know what everybody's workflow is, but probably some > > translators treat > > what's on their machine as canonical, and copy it over without ever > > trying to merge." > > I don't understand this previous sentence. > > > > Can HE give a concrete example of the error (that maybe i am doing)? > > > > As the message is intended to all commiters, i think it is better to be > > clearer, even if it > > is necessary to name someone. If i am doing mistake, i want to learn my > > mistake. > > I am just a human. > > I have corrected markup errors in the French translations. See my > commits here: > > http://git.gnome.org/browse/gnome-user-docs/log/gnome-help/fr/fr.po > > But the errors are always new errors. As an example of my corrections > being overwritten, look at the Slovenian translations. Here's a commit > I made about two weeks ago: > > http://git.gnome.org/browse/gnome-user-docs/commit/gnome-help/sl/sl.po?id=34f54c24c2d69d94fdf4124436c84b2d977045e0 >
Markup mistakes are very hard to identify visually even on your link. I have a script that check that "open markup" correspond to "close markup" but it is not sufficient! I will have a look at https://launchpad.net/pyg3t tools but if anybody had a tuto or a script that works, I am interested. > And here's the commit I made today: > > http://git.gnome.org/browse/gnome-user-docs/commit/gnome-help/sl/sl.po?id=4f68f59f5da11f193cc4eaa91c34c4c9f6e045b7 > > This is the workflow that usually leads to these kinds of problems: > > 1) Get the file from git and copy it to some folder somewhere. > 2) Edit the file. > 3) Update your git repository, or clone it fresh. > 4) Copy the file from some folder into the repository and commit. > Thank you for your very clear answer. This is exactly my workflow. I follow this guideline : http://live.gnome.org/TranslationProject/GitHowTo Questions ? - If we push the po file on Damned Lies, get back the merged file and push it to git, will it solve the problem? - Is there a git command to use before commiting or pushing to solve the problem? (it should be written in the guideline) . > Using this workflow, you will never get merges of other people's work. > If anybody else edits the files you edit, you will always overwrite > whatever they do. > > And I realize many translators are used to basically owning their own > po files and not having to worry about other people editing them. But > module maintainers have to be able to fix syntax errors. And until we > get better tool support (like the kinds of checks you all already have > for format strings), we'll continue to see these mistakes. > Translators, proofreaders and commiters do hopefully not have to be in computer science domain. I am not a programmer and not used to git. If i have to read the git manual before committing, it would be very discouraging. Bruno > -- > Shaun > >
_______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
