How to do l10n for dynamic strings in KDE4 ?

[Christian Esken]

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");



> > 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).


> 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.


> 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.


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

   Christian

-- 
Is Unix ready for the Desktop? See http://www.kde.org