--===============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 I wonder is how I make sure those terms are not
> translated.


I'm doing a fair bit of translating, so I do have in mind some policies=20
about this.

> 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=
ed=20
=2D- different teams may have different opinions.

=46rom my point of view, there are two limits for this, a hard and a soft=20
one.

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=
=20
Latin1 translations in some places, or URL's within message.

A soft limit would be not to translate that which the computer, rather than=
=20
just human, must understand. Ie. things which must appear verbatim in some=
=20
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=
=20
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=
=20
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)")
.arg(...

(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=
=20
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=
=20
needed, programmer should not use the (comment, text) call. Instead, there=
=20
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)")
.arg(...

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=
=20
is only one place it can go. The following would be a i18n blunder:

// Translators: None stands for no action.
i18n("None")
=2E..
// Translators: None stands for no key.
i18n("None")

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
inspection.

So, from my point of view, just chunk the translator-directed info into the=
=20
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

=2D-=20
Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8=
=D1=9B)

--nextPart1550669.Ox6hWTY6RP
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBD6Q7pMSGXgigGr3ERAq9DAJ93H1+tcU1juC2q6zLEYg hXGCd20gCgoTir
FaGxojlBHa7Kx5Ofshpxm6A=
=CzCw
-----END PGP SIGNATURE-----

--nextPart1550669.Ox6hWTY6RP--

--===============1854614192==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


--===============1854614192==--