[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-16 12:14:44
Message-ID: 200405161414.44312.nicolasg () snafu ! de
[Download RAW message or body]

On Sunday 16 May 2004 14:08, Nicolas Goutte wrote:
> On Sunday 16 May 2004 00:15, Heiko Evermann wrote:
> > Hi Nicolas
> >
> > >>Well, at the moment a KDE application already loads 3 catalogs:
> > >>* appname.po
> > >>* kdelibs.po
> > >>* kio.po
> > >
> > >No, you seem to have misunderstood me.
> > >
> > >You load neither 2 appname.po, nor 2 kdelibs.po nor 2 kio.po
> >
> > OK, let's go into the details (sorry for mixing up po-files and mo-files)
> > KLocale::initCatalogue
> > loads kdelibs.mo and kio.mo with these two lines
> > <code>
> >   // always include kdelibs's mo files
> >   d->catalogues.append( KCatalogue( SYSTEM_MESSAGES ) );
> >   d->catalogues.append( KCatalogue( "kio" ) );
> > </code>
> >
> > So internally the KLocale-object holds more than one mo-file. It always
> > holds appname.mo, kdelibs.mo and kio.mo. When starting to translate
> > programs, I quickly found out that not all messages are in appname.mo. I
> > then searched through the po-files, where the msgstrs were and learned
> > about kdelibs.mo and kio.mo.
> >
> > A program can even add more catalogues via
> > KLocale::insertCatalogue(...), and quite a number of programs do that.
> >
> > So we have: you load appname.po, kdelibs.po and kio.po.
> >
> > Internally a nice method called KLocale::catalogueFileName is used to
> > search for the mo-file in question with
> > <code>
> >   QString path = QString::fromLatin1("%1/LC_MESSAGES/%2.mo")
> >     .arg( language )
> >     .arg( catalog.name() );
> > </code>
> >
> > This method is called with the standard language, that can be reached
> > via the "language()"-function. But KLocale also knows about a list of
> > languages that the user knows about in the variable
> > "  QStringList languageList;".
> >
> > What I want to do is change the implemenation of
> > KLocale::insertCatalogue. Instead of only instantiating one
> > KCatalog-object with the default language, I want to instantiate one
> > KCatalog-object for every language in the language list, in the order of
> > preference given by the user. This would load files where %1 in
> > ("%1/LC_MESSAGES/%2.mo") is filled with nds, de, ... (iterate through
> > all languages), so that all the mo-files for the selected languages get
> > loaded. (This would not be all 70+ translations, but only those that the
> > user selected in kcontrol.)
>
> I think that I understand more what you have meant.
>
> The key of our problem is the member function:
>
> void KLocale::initCatalogue( KCatalogue & catalog )
> {
>   catalog.setFileName( catalogueFileName( language(), catalog ) );
> }
>
> as it is the one who sets the file name of the catalogue.
>
> So indeed, unlike what I had understood of those classes, KCatalogue can be
> used unchanged and the changes can probably be localized only in KLocale.
>
> And as KLocale::initCatalogue is a private non-virtual member function, you
> have even the luck to be able to remove it altogether.

Oops, there is probably one problem remaining: the plurals.

For Low Saxon versus German, it probably does not matter, as it is probably 
the same plural scheme, but for Sorbian, it probably does, as Sorbian is a 
Slavik language.


>
>
> (...)
>
> > Kind regards,
> >
> > Heiko Evermann
> > (Low Saxon translation team)

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