This is a discussion on Re: i18n(): communicating with translators - KDE ; --===============1854614192== Content-Type: multipart/signed; boundary="nextPart1550669.Ox6hWTY6RP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1550669.Ox6hWTY6RP Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > [: Frans Englich :] > In some i18n strings in my projects, there are terms which should not be= =20 > translated. What ...
> [: Frans Englich :]
> In some i18n strings in my projects, there are terms which should not be=
> translated. What I wonder is how I make sure those terms are not
I'm doing a fair bit of translating, so I do have in mind some policies=20
> Here's an example:
> i18n("In a division or multiplication involving "
> "xdt:yearMonthDuration or xdt:dayTimeDuration, "
> "the right operand cannot be NaN(not-a-number)")
> "xdt:yearMonthDuration", "xdt:dayTimeDuration", and "NaN" are not
> supposed to be translated. What are the solutions?
(A short discourse)
=46or one, it may be tricky to decide what should and shouldn't be translat=
=2D- different teams may have different opinions.
=46rom my point of view, there are two limits for this, a hard and a soft=20
A hard limit is that one should not translate that which will break the=20
intended functionality of the app. Example would be some requests for pure=
Latin1 translations in some places, or URL's within message.
A soft limit would be not to translate that which the computer, rather than=
just human, must understand. Ie. things which must appear verbatim in some=
script or so. (I guess that xdt:... thingies and NaN from your example=20
fall into this category.)
But, when something is *not* within this two categories, one should not=20
even think of enforcing it being not translated.
> * Break them out with %1, %2, %3, and arg().
=46or the hard limit described above, I would say this is the preferred way=
of doing it. Than the translator cannot possibly cripple the application.
=46or the soft limit, I am not so sure, but I would still use it. However...
> * Perhaps with i18n(const char *comment, const char *text)?
I think this should be there in *addition* to placeholders, to explain what=
they are. Translator may need to know this, as rest of the sentence=20
structure can depend on it.
In this example, I would use:
i18n("%1 and %2 are variable names, and %3 is a constant value of NaN",
"In a division or multiplication involving %1 or %2, "
"the right operand cannot be %3 (not-a-number)")
(I intentionally left out xdt:... names, as they are superfluous, and the=20
message might be used for another set of variables too).
> I think the Doxygen is unclear. Is that function intended for passing
> notes onto the translator("Hi translator, don't translate the words foo
> and bar"), or does it have a technical role at lookup time?
This is a bit of an open question. The primary role is indeed technical, to=
disambiguate short entries possibly needing different translations, eg:
i18n("No action", "None");
i18n("No key", "None");
(The search key in translation catalog is comment+text)
=46rom Gettext maintainers' point of view, when this disambiguation is not=
needed, programmer should not use the (comment, text) call. Instead, there=
is a possibility that the message extractor can also extract the comment=20
just preceding the call, and that should be used:
// Translators: %1 and %2 are variable names,
// and %3 is a constant value of NaN
i18n("In a division or multiplication involving %1 or %2, "
"the right operand cannot be %3 (not-a-number)")
However, KDE so far hasn't used this, everything is put into the call=20
itself, contrary to Gettext maintainers' view (I don't know even if=20
extraction system is set to support it). I personally like this situation.
Programmer should not be forced to decide if something goes into the call=20
or into the comment. Keep it simple: if it is for translator's eyes, there=
is only one place it can go. The following would be a i18n blunder:
// Translators: None stands for no action.
// Translators: None stands for no key.
Then, if some message was found after some time to be quite ambiguous=20
English, the programmer might decide to give it a comment:
// Translators: The foo in here refers to baz, not bar!
i18n("foo bar baz")
But how would the translators be informed to check the entry again? If,=20
instead, programmer does this:
i18n("The foo in here refers to baz, not bar!",
"foo bar baz")
than all teams will get a new fuzzy message, automatically requesting=20
So, from my point of view, just chunk the translator-directed info into the=
call, and don't think too much. Overall, such comments are sorely lacking=20
at present. It is unlikely that, anytime soon, translators will complain=20
to any programmer for too much chatter
Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8=
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
-----END PGP SIGNATURE-----
Content-Type: text/plain; charset="us-ascii"
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<