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

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Krzysztof Lichota <krzysiek () lichota ! net>
Date:       2005-08-15 17:48:02
Message-ID: 4300D552.4030208 () lichota ! net
[Download RAW message or body]

Chusslove Illich wrote:
>> [: Krzysztof Lichota :]
>> I think KI18n is not QString, because it does not allow changing
>> contents. It is a translation container.
> 
> Actually, I could imagine situations where it does call for changing.
> 
> 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.

I don't understand that example. How would one know how to change 
translated text, for example in Chinese? It is rather that widget is 
changed based on (const) translated string?

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

I think it is very rare case and should rather be solved by putting 
comment that translation cannot contain whitespaces.

>> So it should not derive from QString. but implement some subset of its
>> methods (for example arg(), length()) but excluding others, for example
>> those risky from translation point of view (I think operator "+" falls
>> into this category, as it seems concatenation of translations might
>> break some languages).
> 
> I never tought in this direction, to also try to inforce more correctness 
> from programmers side in dealing with i18n. There might lay a good point.
> 
> (In this way of thinking, I think both length() and local8Bit(), two 
> primary troublemakers for now, shouldn't be there, as they should be 
> applied only to translated strings.)

Right :)

> 
>> Solution with t() is OK for me. It gives additional consistency checking
>> of translations, as it should be called only on "completely translated"
>> (i.e. having all arguments) string. I volunteer to fix it in code if
>> this is necessary :)
> 
> It seems to me a dounting task (120.000 messages in KDE SVN) even if 
> automatic to some extent, and a lot of pissed programmers later on. Also, 
> is it perhaps that programmers who don't know that sentences shouldn't be 
> split, are also likely to just put a t() blindly when compiler complains?

Right, again :)
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.


>> In method arg(int) we can even check if translation supports plurals and
>> spit some warning if it does not.
> 
> Sure, could do, though I don't know if it would be that usefull, as 
> translators who don't know they should use plurals, are also likely not to 
> monitor shell output of their translated app... Also, I could imagine that 
> sometimes the wording is such that plural is not really needed (happened 
> to me a few times).

There is some interface for debugging KDE apps, maybe it could be dumped 
to some special file. Coordinator might check such file to find problems 
with translations.

Regards

	Krzysztof Lichota (Polish team)
[prev in list] [next in list] [prev in thread] [next in thread]