Danilo Segan wrote:Yes, I'm aware of that, and that is the "perfect" solution. Still, it seems to be sometimes impractical (as in the mentioned card game with thousands of combinations). In cases like that, and where programmer is "uneducated" about translation, this kind of feature would help get correct translations for at least 20 languages (a wild estimate would be for 50+), and that cannot be all bad, right?
The usual practice among english-speaking programmers is to "compose"
strings out of smaller parts.
You need to educate the programmer to use entire sentences. You can
refer them to the gettext documentation, section "Preparing Translatable
Strings". http://www.gnu.org/manual/gettext/html_chapter/gettext_3.html#SEC15
Also, I agree that this will "encourage" (actually, let them live with) bad strings, so that's the only negative side of the approach. If we're to educate, I don't see what's wrong with educating about The Good Ways, and still having a feature that would really help translators now (it could even be slightly "hidden" so programmers don't even know about it, if they didn't read all the details of documentation :-)).
Serbian is one of those, and the proposed mechanism would not solve those problems, I agree. Yet, I never claimed for it to be the ultimate solution for all translator needs, just for some (same as plural-forms tackles one particular problem, and doesn't go any further).The reason is that in most languages sentences are not composed by juxtaposition, as in English: - For Serbian, you have given examples. - In many languages, a verb's form is spelled differently depending on the gender of the subject.
Still, I come quite rarely across strings that would be wrong because of the gender, and it's my *impression* (so, take it with a [big] grain of salt) that the declination problems are more common. So, I just wanted to know experiences from other languages, and how would the "solution" work for them (and all of that in terms of current programs and current translations).
Just a nitpick: no change would be required to "original" string, so it would be "%s is empty".- In Latin, the combiner "and" comes as a suffix "-que". - Etc. etc.
The translation for "Workspace %d" would look like: msgid "Workspace %d" msgstr<0> "der Workspace %d" msgstr<1> "das Workspace %d" msgstr<2> "dem Workspace %d" msgstr<3> "den Workspace %d"
So, the title of "Workspace 5" would be "der Workspace 5", while the
menu which allows switching to that workspace would read "Switch to den
Workspace 5".
There are more bits of context that influence a translation than just a declination. For example, the beginning of a sentence is special. To pursue your example, an English programmer would be tempted to write
"%<0>s is empty."
which would have the German translationYes, quite so. As I already mentioned, there're far too many cases that any simple mechanism like the proposed one can handle. I never claimed for it to solve all problems. In fact, German could handle this using some "tricks". Eg. if they don't know enough context to know if this would come in the middle or at the start of sentence, they could use 8 (4 for middle sentence, 4 for start of sentence) number of declinations, and they would translate a particular example as eg.
"%<0>s ist leer."
and result in the final string
"der Workspace %d is leer."
which is wrong because, in German, all sentences must start with a capital letter.
"%<4>s ist leer."
(if they've put uppercased forms second, so 4th [zero based counting] would be nominative that should be used at the start of sentences). Still, there are more problems: if string composed this way was used on both the start of sentence and in the middle, this mechanism is not sufficient.
So actually, this mechanism is not really related to declinations but rather to different word forms. Declinations are sort of "inspiration".
Still, problems of implementation seem to be bigger than problems of "usefulness", at least to me. And to stress one more time, this is not a feature to be used by programmers in future, it's a feature to solve some problems translators are having.
Cheers, Danilo
-- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
