[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:39:11
Message-ID: 4300D33F.2010909 () lichota ! net
[Download RAW message or body]

Nicolas Goutte wrote:
>>> class. This would result in the cleanest solution, but breaking *all*
>>> current i18n code and programming habits:
>>>
>>> QString msg = i18n("Blah, blah, %1").arg(somearg).t();
>>>
>>> where method t() would stand for "it's assembled, translate it".
>>>
>>> So, if we don't want to break all i18n code and programming habits, than
>>> perhaps solution with inheritance is not that different from the
>>> non-inherited with implicit cast to QString.
>> I think transition to KDE4 would be perfect moment for breaking
>> compatibility, so we should do it once, but properly, even if it means
>> breaking and fixing a lot of code.
> 
>> 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 :)
> 
> Sorry I do not like it. It changes much the way of developing. Developers 
> already forget i18n(), they will be even more disoriented if there is a 
> "magic" function to call.

I think interface functions for widgets should be changed to accept 
_only_ KI18n reference (no default construction from QString or char*), 
thus forcing developers to always use i18n() - otherwise it won't 
compile. Then they won't be able to make non-translatable programs, at 
least not without major effort.

>> 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 :)
>> In method arg(int) we can even check if translation supports plurals and
>> spit some warning if it does not.
> 
> That would mean that everybody needs scripting. That does not really to be 
> wanted.

Current plurals handling code is just such scripting. And if you are 
worried about running program without any translations file, then "%1 
files" is bearable. If not, one can use "%1 file(s)" which should do the 
trick for English language in most cases. No more problems with special 
i18n() call - less problems for everybody.

>> The only problem would be for English team to provide plurals for
>> English texts, but I have already been speaking for some time in favor
>> of making English translated language :)
> 
> That really seem redundant.

It is not a goal in itself, just a by-product. BTW. There is already 
some translation happening for English variants (for example 
color->colour in British English). And I think it has some advantages:
- English proofreaders can fix spelling mistakes without affecting all 
translations.
- If English proofreades think providing special translation for example 
for plural for "0" occurrences (For example "No matching files found"), 
they will be able to do it.

Regards

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