Re: [Translation-i18n] Proposal for declinations in gettext
- From: Danilo Segan <dsegan gmx net>
- To: linux-utf8 nl linux org
- Cc: translation iro umontreal ca, gnome-i18n gnome org,translation-i18n lists sourceforge net
- Subject: Re: [Translation-i18n] Proposal for declinations in gettext
- Date: Fri, 13 Jun 2003 23:00:34 +0200
Veronica Loell wrote:
>Are you talking about machine translation here? From my perspective as a computational linguist this is not something that should be part of gettext, rather in the tools that use gettext or the tools you use to work with gettext material.
>
>
Nope, I'm talking about manual translation. The current problem, as I
see it, is that words and expressions take on different forms in
different contexts.
The usual practice among english-speaking programmers is to "compose"
strings out of smaller parts.
It's therefore usual to have:
msgid "Workspace %d"
msgstr "radna površina %d"
msgid "Desktop %d"
msgstr "desktop %d"
# Here is %s replaced with the translation of "Workspace %d" or "Desktop
%d" or ... (something user generated)
msgid "Switch to %s"
msgstr "Premesti na %s"
In at least Serbian language, the words "radna površina" would need to
change form to "radnu površinu" (it can easily be deduced by translator,
based on the "switch *to*", what actually causes the word to change). In
German, it might need to change from "der Workspace" to "den Workspace"
(I'm not completely certain on the articles here, correct me if I'm wrong).
The current "solution" for these and similar problems are to put the
work on programmers, and force them to create "complete" strings, so
instead of the former three, one would have four strings:
msgid "Workspace %d"
msgid "Desktop %d"
msgid "Switch to workspace %d"
msgid "Switch to desktop %d"
Please don't mind my ignorance of German, in trying to explain the concept.
German has 4 declinations (nominative, genitive, dative, accusative,
right?). In case of "switch to", I believe "accusative" should be used.
So, the German translation for "Switch to %s" would be
msgstr "Switch to %<3>s"
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".
>Correct me if I'm wrong, but the "autotranslation" in gettext merge? is only for complete clauses, not for individual words, yes? So this should not be an issue for gettext. For your translation memory and your translation tools that you use to work with gettext, now that is where this thought and effort should go in. I would like very much to see some serious translation tools getting generated in the free software community, but that is a separate issue.
>
>
I guess you misunderstood me. The translator provides all the forms one
word takes, if it's a finite number (no matter how large, but finite).
It's along the same lines as Plural-forms feature of gettext, just for
the different purpose, and entirely controlled by translator: (s)he uses
it when appropriate, with no interference of programmer (who, in case of
plural-forms, had to insert ngettext calls instead of gettext).
>Just a note, for Swedish, one would have to deal with compound words, for Finnish and other agglutinating languages you would have to deal with the agglutination etc. etc..
>
>
Could you perhaps give a complete example, and why the proposed
mechanism couldn't handle it? I certainly have no experience in many
languages, but if this would prove useable for at least 20 languages,
I'd find it quite desireable in such a widespread package as gettext. I
guess I can count in so far at least Serbian, Russian, Ukrainian,
Croatian, Slovenian, German, Macedonian, Bulgarian, Belarus, Polish,
Czech, Slovak, Lithuanian, ... If this wouldn't work for any of these,
please inform me; if it *would* work for any language that is not in
this list, than inform me even faster :-)
Such feature would not get in the way to anyone who doesn't use it, but
it would solve at least some problems. I guess that should be a reason
enough, though if anything better can be imagined, I'd love to hear it.
Cheers,
Danilo
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]