Re: avoid 'fixes' in translations

[F Wolff <friedel translate org za>]

I wanted to leave this thread alone, but this just begged for a
response, so here you go...


On Do, 2012-02-09 at 10:55 +0100, Kenneth Nielsen wrote:
> 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.

Translation _is_ interpretation. Just reading the English already
requires interpretation. Of course we seek for equivalence in the
translation, but the level where the equivalence is sought, might differ
between circumstances. This is the old "metaphrase" vs. "paraphrase"
issue in translation. Let me give a (hopefully) unarguable case:

The author makes a spelling mistake. You interpret it as if it was
spelled correctly, and don't bother to duplicate the mistake in the
translation. Of course we also report the bug so that it can get fixed
in the English.

If we can agree that this is the correct thing to do, we already have to
admin that _some_ level of interpretation is in order. Let's now combine
this with the fact that we know a lot of GNOME developers are not native
speakers of English, and the fact that there is very little in terms of
a style guide for GNOME English. Furthermore the source texts are not
always reviewed, so we have to expect some less than ideal variety in
the English source text. Do we need to find a way to lower our quality
to that of less than ideal English source texts?


> 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.

I agree. If we look at the original bug report posted by Ryan, we'll see
that the bug reporter didn't get any kind of response for a long time.
Reported on 2010-03-12, first response on 2011-12-13. That is something
like four GNOME releases. I don't want to argue this specific case. My
point is that string bugs don't always get a lot of attention from
developers - they are busy as we are, so a translator might be forced to
leave something untranslated, or use our judgement of what the best is
for our users. We are already trusted with way more than translating MB
and MiB correctly, anyway.

If a translator spots an inconsistency (even as simple as "can not" vs.
"cannot") and want to improve on it, I don't see why that is a problem.
An excellent translation will strive to be even better for its target
audience than the source text, even if it might not reach that goal all
the time when the source text is good.

We have to admit that our en_US versions are probably the least cared
for language. I guess for most other languages, there is a stricter
process of what goes in and what style and terms are used.


> 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.

While I agree, I don't think it is possible to translate and not
add/subtract something. For example: English uses "you" and "your"
everywhere. Many languages have a choice between formal and informal way
of translating this. Some languages might need to choose between
singular and plural forms of address. Others have to choose between
forms of address that have to do with status. It might not be possible
to translate it without altering the original meaning in some way, at
least. Similarly I might translate some English term with a term that is
slightly ambiguous, but I hope that readers will infer things correctly
from context (just as this is done in other places in the English).

Of course we try to limit this, but we can't pretend that we aren't
forced to do this anyway.


> 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.

We could maybe look into this. However, I think we have more important
things to sort out, like actually reviewing the source texts more
carefully, and getting a list of preferred GNOME terms with their
definitions posted so that developers know what to use, and translators
can standardise the same set for their language.

Friedel

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