[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2005-08-17 3:02:17
Message-ID: 200508170502.20698.caslav.ilic () gmx ! net
[Download RAW message or body]


>> [: 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 
the same problem of splitted sentences. So there was a proposition that 
translators could "communicate" the correct ordering (text-widget 
sequence), through special placeholders. Here is an example from one of my 
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 
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 
translated string, so that perhaps it is not something to be left as a 
translator comment.

I am currently trying to asses effects of Nicolas' proposal (of having non 
inherited KI18n class, but with implicit conversion to QString and few 
methods), so I am running some statistics on the code. In basic KDE 
modules (no extragear), I found following string-modifying methods applied 
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, 
there are two other problems that I see.

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

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

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]