[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-11 13:17:06
Message-ID: 200508111517.09626.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: 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.

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

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

> 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?

> BTW. Have you noticed that we could get rid of special handling of
> plurals by programmers (which they seem to forget to use)?
> Programmers could use i18n("%1 files").arg(numFiles) and the rest would
> be translators task :)

You bet :) There is even such example in that document of mine. And not 
only that programmers forget, but sometimes there is quite a long text 
needing plural forms, having to be written several times, just because two 
words in it depend on the number.

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

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

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

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