From kde-i18n-doc Mon May 17 13:18:04 2004 From: Nicolas Goutte Date: Mon, 17 May 2004 13:18:04 +0000 To: kde-i18n-doc Subject: Re: Language fall-back: proposal for a solution Message-Id: <200405171518.04817.nicolasg () snafu ! de> X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=108480001418699 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!