From kde-i18n-doc  Wed Aug 17 03:02:17 2005
From: Chusslove Illich <caslav.ilic () gmx ! net>
Date: Wed, 17 Aug 2005 03:02:17 +0000
To: kde-i18n-doc
Subject: Re: KGeography needs your help
Message-Id: <200508170502.20698.caslav.ilic () gmx ! net>
X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=112424797108368
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1263337.HMRIsxX6mN"

--nextPart1263337.HMRIsxX6mN
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>> [: Chusslove Illich :]
>> Remember that problem with text intermixed with widgets, where there
>> was a proposal that translator can determine the ordering of widgets
>> with special syntax. Then the translated string would have to be
>> changed.
>
> [: Krzysztof Lichota :]
> I don't understand that example. How would one know how to change
> translated text, for example in Chinese?

The problem was that if text is intermixed with widgets, it boils down to=20
the same problem of splitted sentences. So there was a proposition that=20
translators could "communicate" the correct ordering (text-widget=20
sequence), through special placeholders. Here is an example from one of my=
=20
previous messages:

> [: Chusslove Illich :]
> For solving the splitting problem, back than Reinhold Kainhofer
> proposed something like this: Programmer supplies a msgid with
> placeholders of the form
>
> "&Repeat on [nthweekday] [weekday] in [month]"
>
> and translator does this
>
> "&Wiederholt am [nthweekday] [weekday] im [month]"
>
> Afterwards, the program parses the translated string to get the
> ordering of text and widgets correct. [...]

(Key point is that translator leaves these special [...] thingies exactly=20
as they are, only possibly changing their ordering.)

>> [: Chusslove Illich :]
>> Or, sometimes some characters shouldn't be present in translated string
>> (like whitespace), so programmer may decide to fix that automatically
>> (like putting underscore instead).
>
> [: Krzysztof Lichota :]
> I think it is very rare case and should rather be solved by putting
> comment that translation cannot contain whitespaces.

It seems to me that programmer is pretty worried if he is operating on=20
translated string, so that perhaps it is not something to be left as a=20
translator comment.

I am currently trying to asses effects of Nicolas' proposal (of having non=
=20
inherited KI18n class, but with implicit conversion to QString and few=20
methods), so I am running some statistics on the code. In basic KDE=20
modules (no extragear), I found following string-modifying methods applied=
=20
directly to i18n call (with number of appearances):

replace      9
append       5
upper        2
prepend      1

(There might be more, those not operating on i18n calls directly.)

> [: Krzysztof Lichota :]
> I am now thinking rather about making widgets accept only KI18n
> reference, so that developer must wrap each message in i18n(). This
> would not affect current (correct) code.

Uh-oh, now we are talking about some angry people :) Aside from that one,=20
there are two other problems that I see.

=46irst is conceptual. Can we really, without ambiguity, decide what=20
parameter is to be KI18n and what not? I wouldn't bet...

Second is technical. At some places naked strings wrapped in I18N_NOOP=20
macros are used, so that translation really happens later (like in startup=
=20
phase, for about data, before translation layer has been initialized).=20
Then, rather than KDE widgets at places Qt widgets are used.

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

--nextPart1263337.HMRIsxX6mN
Content-Type: application/pgp-signature

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

iD8DBQBDAqi8MSGXgigGr3ERAqnqAJ9UdLp+wtKUEodGBifjB5ciL5fNPgCeKVxY
SaJf8B5Bb4w0wUfq75BGF54=
=C54n
-----END PGP SIGNATURE-----

--nextPart1263337.HMRIsxX6mN--