Re: Mistakes in doc translations
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 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. 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. Now, before committing and pushing, i just do a (French Team= fr) git log fr.po As we are very few commiters in the team, this way i see who else has made changes to the po file... Bruno 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. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Mistakes in doc translations
On Thu, 2012-04-19 at 13:34 +0200, Chusslove Illich wrote: 4) Due to workflow, we don't have a baseline commit to reference. [...] (4) is a serious problem. git is really smart, and has a number of merge strategies that I can only describe as magic. But they don't work if you bypass version control. For this I have no practical idea how to solve. Other than locking workflow being the norm, translators are frequently pointed to web-based solutions instead of version control (so that they don't get scared off by the process). Then, it is not unusual for regular translators not to have commit access, which would extremely odd for regular programmers (or documenters, right?). The beauty of git is that everybody can commit, even if they can't push their changes to git.gnome.org. We start docs people off using git very early. We have them commit their changes as normal and send git patches to somebody with an account on gnome.org. I know learning version control first is a hurdle (and git especially so), but I also think it's a valuable skill that will save you time and again going forward. And with distributed version control, we're no longer tied to who has an account where to get those benefits. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-disk-utility] Created branch gnome-3-4
The branch 'gnome-3-4' was created pointing to: 741775d... Post-release version bump to 3.4.2 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'gnome-disk-utility.master'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'gnome-disk-utility.master': + Connected to another seat + Location Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. http://git.gnome.org/browse/gnome-disk-utility/log/?h=master ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Mistakes in doc translations
On Sat, Apr 21, 2012 at 1:40 PM, Shaun McCance sha...@gnome.org wrote: On Thu, 2012-04-19 at 13:34 +0200, Chusslove Illich wrote: 4) Due to workflow, we don't have a baseline commit to reference. [...] (4) is a serious problem. git is really smart, and has a number of merge strategies that I can only describe as magic. But they don't work if you bypass version control. For this I have no practical idea how to solve. Other than locking workflow being the norm, translators are frequently pointed to web-based solutions instead of version control (so that they don't get scared off by the process). Then, it is not unusual for regular translators not to have commit access, which would extremely odd for regular programmers (or documenters, right?). The beauty of git is that everybody can commit, even if they can't push their changes to git.gnome.org. We start docs people off using git very early. We have them commit their changes as normal and send git patches to somebody with an account on gnome.org. I know learning version control first is a hurdle (and git especially so), but I also think it's a valuable skill that will save you time and again going forward. And with distributed version control, we're no longer tied to who has an account where to get those benefits. I would suggest that going to Pootle is a good step short of moving to a git workflow and far more friendly to locaiizers. I run a substantial Pootle instance, not quite as Gnome, perhaps, but still hosting tens of thousands of words and strings on over 100 languages. cjl cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n