How to do l10n for dynamic strings in KDE4 ?

[Nicolas Goutte]

On Saturday 04 March 2006 14:14, Christian Esken wrote:
> Am Samstag, 4. März 2006 13:12 schrieb Nicolas Goutte:
> > On Saturday 04 March 2006 12:53, Christian Esken wrote:
> > > Hello,
> > >
> > > I am currently working on adding more l10n to KMix. l10n is there in
> > > most places, but there is on challenge left, namely dynamic string
> > > translation. For example:
> > >
> > > QString controlName = i18n( mixercontrol->getName() );   // When using
> > > the ALSA-backend, control names come straight from the kernel
> > >
> > > While many control names are well-known (like Master, Surround, CD or
> > > PCM), there are a LOT of non-standard names. New controlo names show up
> > > with each new sound card or ALSA driver version. How could such a l10n
> > > task be accomplished?
> >
> > There is no choice but to have pre-determined translations. There is not
> > something like automatic translations (what I suppose you mean by
> > "dynamic").
>
> I knew somhow it could get misunderstood. No, actuallly I dindn't mean
> Babelfish lookup. ;-) I meant doing i18n() on a dynamic looked up string
> instead of a const char*, like:
>

> i18n( mixercontrol->getName() );        /* vs */        i18n("CD Audio");

Basically that is not a problem. The program (named xgettext) that extracts 
the strings knows the difference between a 
string literal (e.g. "something" ) and something else (e.g. a variable).

>
> > > My current idea is to ship KMix with a set of standard names (e.g. as a
> > > lot of I18_NOOP() in an otherwise unused file). The non-standard names
> > > would come from an XML file, that can also ship extra translations,
> > > like "name_de" below:
> > >
> > > <control id="Optical/Coaxial_SPDIF_Input:0" controls="*" tab="Sound
> > > Routing" name_de="Optischer/Coaxialer Digital-Eingang"  />
> >
> > If you have translations in a XML file, I would use them in priority. If
> > the string is not translated, then pass it to i18n() and use what is
> > returned by the call (...which might be untranslated).
>
> Yes, this is exactly what I tried to describe above. So I'll qo this way,
> placing well-known names in a file that only serves the translation process
> (which means: it doesn't need to get compiled in).

Not exactly. As you have XML files, you do not need an extra file in SVN. You 
simply let Scripty extract the file on the fly. That is where extractrc (if 
the text is in XML elements) and extractattr (if the text is in attributes) 
are used.

As I suppose that you mean for KDE4, you could look at Kate's:
trunk/KDE/kdelibs/kate/Messages.sh
(that is an example of extractattr)

An example for extractrc is in Kivio:
trunk/koffice/kivio/Makefile.am
in the "messages" target.
(I mean the EXTRACTRC with the --tag-group=none )


>
> > However if the XML is KDE-secific then it should remain untranslated but
> > the strings should be extracted (currently manually by extractrc). In
> > that cae you always have to call i18n().
>
> The XML files are KMix specific themes, so they could qualify as
> KDE-specific. They define which conotrols to show in which order, on which
> Tab and in which style (DropDownList, Switches, Radio-Button, Slider, ...).
> Anyhow, this doesn't need an answer now. I'll keep on coding with the stuff
> I have now, and come back to that in a couple of months.

Good.

>
> > Also if you have plenty of generic names, which a high potential conflict
> > risk with existing messages, please consider use a content for all these
> > strings. For example,  "Master" for sound might not be a "Master" for
> > something else non-sound (i.e. in Elnglish the name might be the same,
> > but not in all translations).
>
> Yes, I already have thought on that, like prefixing everything with
> "x-MixDevice:" or similar.

No, need of an x-

You simply give ask for a context in the parameters of extractrc or 
extractattr. (Remember that this information is for the translator, so avoid 
developr-"slang" like prefixing x- and using grouped-together words.)

>
>
> Thanks for the feedback Nicolas. Now I am confident, that the path I going
> is rather fine.

Yes, it looks without problems.

>
>    Christian

Have a nice day!