> [: Kenneth Nielsen :]
> 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.
I cannot say I disagree with what you said, but I likely disagree with what
you (and Ryan) actually meant :) In the general claim, and especially in the
instance that triggered the general claim.
When properly analyzed, "translation" is seen to be a fluid term. In order
to underline this, to be able to discuss it without preconceptions, in some
literature they call the process "recreation" instead. It depends on many
things what method will be used to "recreate" the textual content from the
source language into the target language.
For software user interfaces and documentation, the only hard rule should be
not to change the fact through translation; the fact which was established
by the author of the text in the source language. If the fact was wrongly
established by the first author of the text, than all of your points for
changing this fact through translation apply (can change immediatelly before
release, make bug report, add translator comment, etc.) But if the stated
fact in the source language is true and that fact is preserved in the target
language, everything else is free game. How it will be handled, depends on
the linguistical, cultural, and whatever other context of the target
language and target environment.
(I will give one example when this "free game" should very much be
exercised, but I observed many times it's not: the "please add context --
verb or noun?" request. This is a bad context request. What the translator
needs to know is what the text means and in what place it is used, and not
what grammar form is employed. The translator should pick the appropriate
grammar form for the target language, for that meaning and that place of use
of the text. In my language, for example, we will frequently use a noun
where in English a verb was used; hence it is not directly relevent to me if
it is a noun or verb in English.)
Coming to the actual trigger. Various standards are one thing; specific
projects' policies are another thing; the fact is that in *English* software
user interfaces, the acronym MB and pronunciation /megabyte/ is still
frequently (if not predominantly) used to denominate 2^20 bytes, alongside
the acronym MiB and pronunciation /mebibyte/ for this, and SI MB-/megabyte/
for 10^6 bytes. The only obligation upon the translator is to find out what
the original text meant by MB; when that is established, there is no longer
any constraint on how to represent it in the target language. In particular,
it is wholy possible that a small language-environment will be a lot
snappier at rooting out the misuse of SI prefixes, then the vast English
will be. In short, in my opinion, the translator is wholy in the line by
translating an MB that represents 2^20 bytes as MiB.
Now comes the practical problem: what if the original text switches not MB
to MiB in the text, but MB to 10^6 bytes in the meaning, thus not fuzzying
any PO messages? The answer is very simple. The "blame" rests only on the
programmer, because he did something that no efficent translation workflow
can handle: the meaning -- the fact -- was changed while the text was not.
This is a breach of Gettext-based translation conventions. The breach would
have been avoided had the programmer done exactly what the bug reporter
requested. Given the known ambiguity of MB in English, *every* use of MB
(and other units of the sort) should be accompanied by a disambiguation
context (C_("MB = 10^6", ...)). If at one point the meaning is changed, the
text does not change but the context does, making the message fuzzy and
stating the new meaning.
A possible practical issue with this solution: "what, we should add context
to every message with a byte amount??". In short, yes. If there is a lot of
messages with byte amounts, centralize formatting of byte amounts. So that
instead of *printf(_("... %.2f MB ..."), nbytes*1e-6) one can write
*printf(_("... %s ..."), bytes_to_mb(nbytes). This is a win for everyone:
programmers make sure they remain consistent with the policy, and can switch
it later on; translators get to translate only a few byte-unit messages,
properly equipped with contexts; users may even be allowed to choose whether
they want to see byte amounts in SI MB or MiB.
--
Chusslove Illich (Часлав Илић)
Attachment:
signature.asc
Description: This is a digitally signed message part.