country names translations

[Nicolas Goutte]

On Thursday 16 March 2006 01:20, Andriy Rysin wrote:
> Nicolas Goutte wrote:
> > On Wednesday 15 March 2006 22:00, Andriy Rysin wrote:
>
> ...
>
> >> Nicolas Goutte wrote:
> >>> // Get translation
> >>> translation = i18n( layoutName );
> >>> if ( translation == layoutName )
> >>> {
> >>>  // Not translated? Try harder with a country name:
> >>>  translation = i18n( layoutName.prepend("Name=") ).remove("Name=");
> >>> }
> >>
> >> that's ugly, slow and non-reliable
> >
> > Well, we are in the middle of KDE 3.5.x, we have tocome up with
> > compatible solutions, not with the most elegant ones. (Elegancy is for
> > KDE4.)
>
> That I would agree, but I also have a limit for uglyness level I can
> agree to :)

And I would like to have a limit of the chaos level in l10n. :-(

>
> >> how about the case if translation==layoutName in realLife ???
> >
> > There would not be a translation of the "country" name.
>
> how about (en) Tuvalu == (es) Tuvalu ?? (I bet there's quite few of those)

Where do you see a problem?

Tuvalu is not a language name, so the first i18n() call will return "Tuvalu". 
As it is identical, "Name=Tuvalu" is tried and the translation returned 
(probably "Name=Tuvalu" again). So at the end, you have "Tuvalu" as 
translated string.

And I suppose that language names are more often translated than country 
names, so the i18n call sequence is in the less critical direction. 

>
> >> in best case we impact performance, in worst we pick up wrong
> >> translation
> >
> > If you have an additional PO file, it would pick the "wrong" translation
> > too.
>
> Only if we don't have translation at all.  In case with workaround you
> suggest we override "primary" translation with "backup" version from
> dekstop.po which may confuse the translator

>
> >>>> I'd rather create new *.po file with country names extracted from
> >>>> kdebase_deskto.po and then insertCatalog() it leaving all i18n code as
> >>>> it is now.
> >>>
> >>> The translators would not welcome again a PO file with country names.
> >>> (There
> >>
> >> this will not be PO file for translation, this will be smth. like
> >> geo_common.po generated from kdebase_dekstop.po by removing "Name=" ...
> >> (for 3.5) or separate file for common things (like geographies) in KDE4.
> >
> > And how do you want to generate it in KDE 3.5.2? In the release script?
> > And who will control the result?
>
> there's Makefile in l10n, and there's rules in Makefile :)
> though I am not really aware of resulting problems... so if it's too
> hard, we may have to live with untranslated layouts in 3.5.x for xorg >=
> 6.9.0

The kde-i18n package resulting from the l10n module is released with PO and 
GMO files. So the creation cannot be done when the Makefile will be run, as 
it would mean that the user has msgfmt to create the GMO file out of the 
newly generated PO file.

>
> > As for KDE4, the problem is another and has to be solved in the general
> > problem of duplicate country and language name translation.
> >
> >
> > ...
> >
> >>>> It'll be cleaner and faster solution.
> >>>
> >>> I do not think so.
> >>
> >> arguments?
> >
> > A new PO file is not cleaner and not faster (except perhaps at runtime).
>
> and isn't the runtime is the one which matters most? :)

As far as I understand, we are talking about xkxb the application to set the 
keyboard settings. So I do not think that it is a speed critical function.

Have a nice day!