term.[a]bug and friends are hard to translate




14 years ago
10 years ago


(Reporter: david, Unassigned)





14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910

I'm working on the german translation of Bugzilla and while I'm nearing the end
(for 2.18rc2 that is), I'm still getting annoyed bei the problem presented
through those variables. I can't say how it is for other languages (although I
know many have similar problems) but in german the problem is:
terms.abug can mean "ein Fehler", "eines Fehlers", "der Fehler" or "des Fehlers"
or terms.bug may be "Fehler" as well as "Fehlers" - always depending on the
surrounding sentence. If it's used as in [% terms.bug %]report, translating
get's even harder sometimes. So in the end, I've got occurences of "[% terms.bug
%]", "[% terms.bug %]s" or even no variable at all if it's making no sense at
all. In the end, the nice idea behind those variables is completely dead - if
someone changes their translation, lot's of sentences won't make sense anymore.
A different translation then "Fehler" may get something else then an additional
"s" at the same point so [% terms.bug %]s is completely wrong for that translation.
For that reason, I'd like to question wheter they're really usefull with regards
to supporting i18n.

Reproducible: Always
Steps to Reproduce:
In my opinion, the variables are of more use for customization than for
translation. You can easily turn "bug" into "issue" with them, but I think you
need a different set of variables for, say, German, as you noted.

So I'd say when translating, your most productive way to go is to set up a
variables.none.html that fits the language.

For German, you can easily have the set of variables get out of hand for the
reasons you stated: if you want full customazibility to be able to turn "Fehler"
into "Anliegen" or "Punkt" editing variables.none.tmpl only, you'd need quite a lot:

terms.fehler:              "Fehler"       <=> "Anliegen"     <=> "Punkt"
terms.fehler_nomPlur:      "Fehler"       <=> "Anliegen"     <=> "Punkte"
terms.einenfehler_accSing: "einen Fehler" <=> "ein Anliegen" <=> "einen Punkt"
terms.derfehler_genPlur:   "der Fehler"   <=> "der Anliegen" <=> "der Punkte"

...and that's just starting. I can see no way that is simpler but equally
comprehensive, so <unsolicited>I recommend not using variables at all when
translating to German</unsolicited>.

Comment 2

14 years ago
Yes, that's more or less what's done in the current translation. The variables
are still there in most cases but if someone changes their translation in
variable.none.tmpl then only a tiny part of the actual work is done. It's sad to
loose some flexibility through translating but such variables will work only in
a few languages like english with a rather simple grammar. 

Unless someone else comes up with a better idea, I'll probably phase them out as
the translations need to be changed to adapt to newer version of the templates.
Ever confirmed: true
Obviously we'd like all translations to have a similar system, but It's fine to
phase them out in your translation if it's not practical. I understand some
languages would have such a large collection of different variables that it's
not practical.



13 years ago
QA Contact: mattyt-bugzilla → default-qa


12 years ago
Assignee: myk → ui

Comment 4

10 years ago
See also bug 407752
You need to log in before you can comment on or make changes to this bug.