Re: avoid 'fixes' in translations



On 30-01-2012 17:51, Ryan Lortie wrote:
hi translators,

This is my opinion on a topic that I don't know a lot about.  I think
I'm right, but I'd like feedback.

I recently noticed this bug:

   https://bugzilla.gnome.org/show_bug.cgi?id=612698

While I agree with the fact that it is wrong to have "MB" meaning
anything other than "1 million bytes", I disagree with the idea that
translation is an appropriate means by which to fix this problem.

I also noticed a similar problem in the Canadian English translations at
one point -- lots of silly things like "can not" being changed to
"cannot".

Translation should attempt to best-preserve what was said by the person
who said it -- not what they might have said if they had a different
opinion on a topic (like the way in which units should be used).  It
doesn't matter if this opinion is wrong -- that should be filed as a bug
and fixed in the source strings.  Doing this in translations only fixes
the problem for a small subset of the users.

There's also another problem with this approach.  Taking the "MB"/"MiB"
example: if an application were incorrectly using "MB" to mean "1048576
bytes" then a translator may feel justified in translating it to "MiB".
Meanwhile, a bug could be filed against that application to change their
incorrect usage of "MB".  When that app makes the change, "MB" now means
1000000.  The translation, however, will still be converting "MB" to
"MiB", so we have a situation where "MiB" means 1000000 bytes, which is
just totally insane.  This is not theoretical -- this very case occurred
in GLib for quite some languages and the bug report I linked to above is
discussing doing it in file-roller where I notice that the Spanish and
Norwegian Nynorsk translations have already done the same.

TL;DR: If you disagree with how something is written in the English
string, please file a bug against the relevant component.  Never use
translation as a way to 'fix' bugs or change something that you disagree
with.

Cheers

Hallo Ryan

I just want to say that I wholeheartedly agree with you in this matter. And actually, without being condescending, I don't really think that it is a matter of an opinion, but simply the only way that it makes sense. Authors _author_, translators _translate_ not _interpret_. I often make comments along the lines you mention above when proofreading the translations.

The absolutely only case that I can think of where it can be allowable has to do with timing. If: 1) It is immediately before release (i.e. a fix in code cannot possible trickle out even assuming the developers see the bug report right away)
2) A bug report _IS_ formed to have it fixed in the right place
3) A translator comment is made to make sure that the information about the "fix" is not lost 3) The fix in the original string, made by the developers, will without a doubt make the string fuzzy, so the translators will need to revisit the string (and their comment) again when it is fixed.

If all those conditions are meet, then it _can_ make sense.


On another note. I have also had quite a few discussions concerning "the level" of the language, where sometimes translators has __added__ explanation because they thought the original string was to difficult (high level) for "ordinary users" to understand, which is my opinion is really bad. Also in those cases, the authors decide on the level, if translators thinks it is wrong, report it, don't try and fix it.


It would be nice if there was a GNOME guideline on this. We should have a look to see if there actually is on the website, and otherwise suggest adding one.

Regards Kenneth


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]