Re: Mistakes in doc translations

2012-04-21 Thread Bruno Brouard
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

2012-04-21 Thread Shaun McCance
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

2012-04-21 Thread David Zeuthen
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'

2012-04-21 Thread GNOME Status Pages
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

2012-04-21 Thread Chris Leonard
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