Re: Mistakes in doc translations

2012-04-17 Thread bruno
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


Re: Mistakes in doc translations

2012-04-17 Thread Daniel Mustieles García
Bruno,

Following the workflow under DL will solve this kind of problems,
since you don't have to deal directly with Git. Also, DL merges you
translations with the main POT file, dinamically generated from the
source code, so if a developer adds new strings to a module, PO file
will be updated with these changes in DL, but not in Git.

In the other hand, there are two ways to check syntax in a PO file:
Gtranslator checks variables automatically (if the original strings
says %d files but you translate %i files it will show a warning
message); also, using gtxml you will be able to check your markup
syntax with a simple command: gtxml -c filename.po (-c option
highlights error in red).

We are working to get gtxml working in Gtranslator, but it isn't still
completed. We will notice it when it be commited

Best regards

El día 17 de abril de 2012 09:25, bruno anno...@gmail.com escribió:
 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

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Mistakes in doc translations

2012-04-17 Thread Chusslove Illich
 [: bruno :]
 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.

Source version control (with Git or any other tool) is here only
circumstantial to the actual issue, which has nothing to do with
programming. And this issue can be described with the following question:
can two people work on the same PO file at the same time, and if yes, how? I
consider this question as still being open.

If the answer is no, then authors should not touch PO files. They should
only disable PO files when invalid (whatever that means in the particular
context) and notify the translator in charge. For both of these actions,
means as automatic as possible should be sought. (And on translators' side,
locking mechanisms, either technical or organizational, should be
established.)

If the answer is yes, then the the how must be answered. It is not
sufficient to relegate how to standard version control procedures,
treating PO files as any other source file. Technically, because a PO file
is not pure source file, but half-derived half-source, and has only weak
line-level semantics; together this precludes line-level diffing, which is
the core of version control procedures. Organizationally, because true
source files are typically small and rarely under immediate interest of more
than one author, whereas many translators can meaningfully modify a given PO
file (unless it covers a topic which requires a specialized translator);
this makes PO file conflicts much more likely.

-- 
Chusslove Illich (Часлав Илић)


signature.asc
Description: This is a digitally signed message part.
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Mistakes in doc translations

2012-04-17 Thread F Wolff
Op Ma, 2012-04-16 om 18:34 -0400 skryf Shaun McCance:
 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.

The workflow I use is to rather download the file afresh from Damned
Lies, since I don't always know if I have the right versions of
intltool, etc. on my system. I trust the files from Damned Lies to be
based on a correctly extracted POT file, and to contain the latest from
version control.

For a maintainer I think it might be useful to contact translators who
might have submitted something like this to ensure that our skills
improve over time.

Virtaal and pofilter would have been able to detect these and other
errors, so I want to encourage translators to use it. They seem to
complain about a few cases that might be ok (mostly reordering of tags),
but it helps a lot to find issues that can affect the functionality and
quality of the translated version. I see that it doesn't give a detailed
error of the tag or property that is wrong, so maybe we can work on
identifying such cases to improve it for a next version, but it already
saves a lot of time, I believe.

Shaun, pofilter flags a few remaining issues after your edits. I guess
as long as it builds, it isn't catastrophe, but I thought you might be
interested. (Or maybe I don't know how much freedom we actually have to
alter the tags when translating. :-)

Keep well
Friedel



-- 
Recently on my blog:
http://translate.org.za/blogs/friedel/en/content/survey-about-usability-virtaal

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Mistakes in doc translations

2012-04-17 Thread Matej Urban
Hello,

following this debate I noticed Slovenian translation being used as an example.
In our local copy, that gets updated directly from POT file, these
errors do NOT exist! in the gnome-help file.

I have no idea how this happens, but I do remember correcting them before.
We always update local copy of the file with published POT and we have
only ONE local copy of the file.

I will again check for this and similar errors.

M!


On Tue, Apr 17, 2012 at 12:34 AM, Shaun McCance sha...@gnome.org wrote:
 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.

 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
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Mistakes in doc translations

2012-04-17 Thread Shaun McCance
On Tue, 2012-04-17 at 13:07 +0200, Matej Urban wrote:
 Hello,
 
 following this debate I noticed Slovenian translation being used as an 
 example.
 In our local copy, that gets updated directly from POT file, these
 errors do NOT exist! in the gnome-help file.
 
 I have no idea how this happens, but I do remember correcting them before.
 We always update local copy of the file with published POT and we have
 only ONE local copy of the file.

The problem isn't about updating with the POT file. The problem is
about not merging with the PO file from git.gnome.org. You say you
have one local copy of the PO file. Is that file sitting in a git
checkout, such that doing git pull will merge changes? That's the
correct way to use version control.

--
Shaun


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


libsoup now has translations

2012-04-17 Thread Dan Winship
In git master, libsoup now has translations. (Only like 3 strings at the
moment, but there will be more as the release cycle progresses.)

-- Dan
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Mistakes in doc translations

2012-04-17 Thread Shaun McCance
On Tue, 2012-04-17 at 10:43 +0200, Chusslove Illich wrote:
  [: bruno :]
  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.
 
 Source version control (with Git or any other tool) is here only
 circumstantial to the actual issue, which has nothing to do with
 programming. And this issue can be described with the following question:
 can two people work on the same PO file at the same time, and if yes, how? I
 consider this question as still being open.

The answer is plainly yes, if you use version control correctly. PO
files might have some characteristics that make some things harder,
but they're not so special that they're outside the realm of git.

 If the answer is yes, then the the how must be answered. It is not
 sufficient to relegate how to standard version control procedures,
 treating PO files as any other source file. Technically, because a PO file
 is not pure source file, but half-derived half-source,

This is true. If you and another person both do a msgmerge with a
new POT file, you're going to get conflicts. It sucks. But I assure
you, everybody else in GNOME deals with conflicts too. It's a fact
of life.

  and has only weak
 line-level semantics; together this precludes line-level diffing, which is
 the core of version control procedures.

PO files are more line-oriented than XML files. Will you get diff
noise from rewraps? Sure. But we all manage.

  Organizationally, because true
 source files are typically small and rarely under immediate interest of more
 than one author, whereas many translators can meaningfully modify a given PO
 file (unless it covers a topic which requires a specialized translator);
 this makes PO file conflicts much more likely.

About a dozen people regularly commit to the same Mallard page files
in gnome-user-docs. Not a single one of the files belongs to only one
person. I regularly commit to files written by someone else. It does
work, as long as you use version control correctly.

--
Shaun


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


String additions to 'gtk+.master'

2012-04-17 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 'gtk+.master':

+ Animated
+ Set if the value can be animated

Note that this doesn't directly indicate a string freeze break, but it
might be worth investigating.
http://git.gnome.org/browse/gtk+/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-17 Thread Matej Urban
NO, :) I pull, update and push.
M!

On Tue, Apr 17, 2012 at 3:58 PM, Shaun McCance sha...@gnome.org wrote:
 On Tue, 2012-04-17 at 13:07 +0200, Matej Urban wrote:
 Hello,

 following this debate I noticed Slovenian translation being used as an 
 example.
 In our local copy, that gets updated directly from POT file, these
 errors do NOT exist! in the gnome-help file.

 I have no idea how this happens, but I do remember correcting them before.
 We always update local copy of the file with published POT and we have
 only ONE local copy of the file.

 The problem isn't about updating with the POT file. The problem is
 about not merging with the PO file from git.gnome.org. You say you
 have one local copy of the PO file. Is that file sitting in a git
 checkout, such that doing git pull will merge changes? That's the
 correct way to use version control.

 --
 Shaun


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n