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

List:       kde-i18n-doc
Subject:    Re: Language fall-back: proposal for a solution
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2004-05-17 13:18:04
Message-ID: 200405171518.04817.nicolasg () snafu ! de
[Download RAW message or body]

On Sunday 16 May 2004 18:24, Heiko Evermann wrote:
> Hi Nicolas,
>
> >I have the idea of using a catalogue list per language instead of a
> > central catalogue list.
>
> Well, we already have a catalog list in KLocale. The question is how to
> fill the list.

Yes, but just one! If you load that list with catalogue of different languages 
you do not know anymore which catalogue is which language (at least if you do 
not want to change the class KCatalogue.)

>
> >This is a few advantages:
> >- you can search a translation language per language, so you always know
> > which language is currently used and you can apply special treatements
> > specific to that language (for example plurals.)
>
> I did not quite understand that. What do You mean?

> I think we should only have one language list in kcontrol and just
> evaulate that list.

When you have one single catalogue list in KLocale, you do not know to which 
language the catalogue belongs. (Of course may be an alternate solution is to 
store the language in KCatalogue, but then the code change would not be 
limited to KLocale.)

>
> >- it tries harder to find a string (for example a string would be in an
> >application and in kdelibs, translated fully in German but only in kdelibs
> >for Low Saxon, having one common catalogue list would return the German
> >translation, with a separate list, it would be the Low Saxon one.)
>

> application.po should have precedence over kdelibs even across languages.

Not sure about that. There are duplicate entries accross catlaogues. So may be 
an entry is already translated in kdelibs (for example colour names) which is 
not in the application or other catalogues (for example colors in koffice.po)

(Good, I know that this example is currently a little bad as these colours are 
one time with context and one time without, but that could be corrected.)

> Your approach seems to propose that we should search all nds files
> first.

Yes, indeed.

(...)
>
> >- a language is searched completely before trying the next one. This
> >especially keep time low for well translated languages, as most of the
> > time you would need to search in only one language.
>
> In well-translated languages the whole problem does not exist. In that
> case it would not even make sense to pick more than one language in
> kcontrol. Remember: there the user does not pick which languages to
> install, but only which ones to display. In a well-translated language
> the second choice will not have any effect, as you always get strings in
> your favorite language.

Your idea was about little-translated languages, but those languages evolves
but perhaps the fallback language will still have more applications 
translated, for example because the fallback language has a bigger I18N team.

Also the KControl list is for all applications, for partially translated 
application as well as for not translated applications. So the user will try 
to have a list that work for the applications that he is using. That might 
include more than one major language (for example British English as last 
fallback.)

Also the Norwegian team has asked for long for such a feature and as far as I 
can see their 2 languages are quite evolved.

> Another reason why speed should not be the problem is that usually
> strings get looked up in dialog initialization etc. that is in
> interactive parts of the program. I think it would still be quick
> enough. It does not disturb a well-written program in computation
> intensive parts. In that case a program would not use i18n() inside a
> loop. e.g. kstars translates quite a lot of data, but it caches the
> translations anyway.

It is always small steps that make a software slow or fast. Be careful that 
this is also part of an application loading time.

And especially as it is in the interactive part of the software, it should not 
have a long startup time (for example complex dialogs like KOffice's stylist 
dialogs.)

>
> A valid point from one of your mails is handling of plural forms. I will
> have to look a bit closer at the code.
>
> Kind regards,
>
> Heiko Evermann

Have a nice day!

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