GNOME.org
 

Re: avoid 'fixes' in translations

On 09-02-2012 13:37, F Wolff wrote:


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




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.
Ahh come on. This is a matter of definition. Yes, if you define reading as interpretation, then yes. But quite frankly I think it is a little artificial and at least I hope we can agree that very different levels of "interpretation" is required for reading, translating and changing the strings because you think the author is wrong.
What I am talking about is not changing the meaning of strings because you think the author is wrong and don't guess at/interpret the meaning of a string because you don't understand it. 

In both those cases the correct way of action has to be via bug reports.


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.


Yes yes, see above.


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?
No off course not and that was not what I was talking about. But let me give you an example of what I am talking about. My book in introductory programming says that UI strings should 1) Be kept in a formal tone and 2) Avoid talking down to its users and 3) To a large extent avoid humor, because the meaning of the humor might not make it across the widgets. 

So if I as a translator run into strings like:
"You are about to delete all of your work, which would be really stupid, are you sure you want to continue?" 

or

"Off'ing those for you while we speak ;)"

or
"Since GParted is a weapon of mass destruction only root may run it" (real example)
Then do I just assume that he is a bad programmer and "correct" those strings into proper UI strings? 


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 by using our judgment you mean any of the cases I mentioned above, then no I would always just leave it untranslated, or translated it close to the original until I got a reply to the bug report. 


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.
Again, I wasn't talking about minor grammatical errors or language variation. 


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.
No no of course, it is not possible to translate without changing _something_. But here I am talking about e.g. explaining certain terms that was not explained in the original (e.g. a programming term in a manual). This is a case where the author has made a conscious choice about what level of expertise and knowledge his document is aimed at, and changing that would be mis-using that trust you were talking about before. 


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.
So if we were to put something in a "translations best practices" document, then what do you think it should say should be the goal. What we try to do, or what we sometimes compromise at? 


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.
I'm not sure agree that these are more important. But at least the first one would be nice, but also require a lot more work. The second part about word lists is a little bit more debated, at least in my languages team. 

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