[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:54:23
Message-ID: 200405161454.23068.nicolasg () snafu ! de
[Download RAW message or body]
On Sunday 16 May 2004 14:14, Nicolas Goutte wrote:
> 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.
I have the idea of using a catalogue list per language instead of a central
catalogue list.
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.)
- 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.)
- 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.
The speed increase would especially be there when a third language is given
but that the second language is nearly completely translated. This could be
the case for example if a Canadian would like to start a French Canadian
translation while keeping French and British English as fallbacks. As French
is nearly complete, searching the British English would be seldom. (With a
common catalogue list, British English would nearly be always searched.)
>
Have a nice day!
> > (...)
> >
> > > Kind regards,
> > >
> > > Heiko Evermann
> > > (Low Saxon translation team)
[prev in list] [next in list] [prev in thread] [next in thread]