Re: RFC - Storing translated values in a PropertyBag

[Dietmar Maurer <dietmar ximian com>]

Martin Baulig wrote:

> Hi guys,
>
> AFAIK we still don't have any official policy on how to deal
> with translated strings in a PropertyBag.
>
> After moving my ditem moniker into bonobo-config and playing
> around with it a bit, I think Ican now come with a good proposal
> for it :-)
>
> First, of all, we have a new type in Bonobo_Config.idl which is
> already used by the ditem code:
>
> =====[in module Bonobo::Config ]=====
>
>         struct LocalizedString {
>                 string locale;
>                 string text;
>         };
>
>         typedef sequence<string> StringList;
>
>         typedef sequence<LocalizedString> LocalizedStringList;
>
> =====
>
> All we need to do is to make the monikers handle this type in a special
> way. I don't know how GConf handles translations, so here's how it should
> work with the xmldb moniker.
>
> Currently, we have (created by xml-i18n-merge) something like this:
>
> ====
>   <section path="bonobo-config-test">
>     <entry name="test-string" type="string">
>       <value>a string</value>
>       <value xml:lang="de">ein string</value>
>       <value xml:lang="es">una cadena</value>
>     </entry>
>   </section>
> ====
>
> My proposal contains of two parts (the ditem moniker already implements
> some of this, but see bonobo-config/doc/ditem-design.txt for details):
>
> My proposal - PART I:
> =====================
>
> a) getValue ("/bonobo-config-test/test-string") returns the untranslated
>    string as CORBA::string. I think this is what it already does.

No, currently it returns the string which matches the current locale.

> b) getKeys ("/bonobo-config-test/test-string") returns a list of all the
>    languages ("de", "es", "sv").
>
> c) getValue ("/bonobo-config-test/test-string[de]") returns the german
>    translation as Bonobo::Config::LocalizedString.

it is easier to parse the string if it looks like:

getValue ("[de]/bonobo-config-test/test-string")

>
>
>    Optionally, this can do a lookup in the language list (so if the
>    xmldb file contains "de_DE" and you ask for "de", it'll first check
>    for "de" and then for "de_DE" etc.) - and we can also allow multiple,
>    comma separated locales in the square brackets.

>
> d) getValues ("/bonobo-config-test/test-string") returns all the
>    translations as Bonobo::Config::LocalizedStringList.
>
> e) getType ("/bonobo-config-test/test-string") returns TC_CORBA_string.
>
> f) setValue ("/bonobo-config-test/test-string") writes
>
>      - the untranslated string if the argument is CORBA::string.
>
>      - a specific translation if the argument is
>        Bonobo::Config::LocalizedString
>
>      - all the translations if the argument is
>        Bonobo::Config::LocalizedStringList
>
> For GConf (FIXME: I don't know how GConf handles translated strings), we
> should try to implement this natively - I don't know enough about GConf,
> but it seems to have a list type and a pair type, so it should be possible
> to map Bonobo::Config::LocalizedString to a pair of strings and
> Bonobo::Config::LocalizedStringList to a sequence of pairs of strings.
>
> This have the advantage that you can still access these config items in a
> GConf-only application.
>
> To summarize:
>
> * Bonobo::Config::LocalizedString(list) is stored natively in the
>   backend, not as a CORBA any.
>
> * The format of the xmldb file won't change - it works transparently
>   on top of the already existing string type.
>
> * This is fully backwards compatible, you don't need to change your
>   code and you also don't need to change the type of your config data -
>   it'll operate on the untranslated string as it does at the moment.
>
> * It adds a way to read/write the translated string(s) if the backend
>   supports it.

sounds good.

> My proposal - PART I:
> =====================
>
> Sometimes it's desirable to operate on all the translations, for
> instance if you want to store the contents of a .desktop file in a
> CORBA struct Bonobo::Desktop::Entry.
>
> To do this, we add a new entry type "localized-string" to the xmldb
> format
>
> ====
>   <section path="bonobo-config-test">
>     <entry name="test-string" type="localized-string">
>       <value>a string</value>
>       <value xml:lang="de">ein string</value>
>       <value xml:lang="es">una cadena</value>
>     </entry>
>   </section>
> ====
>
> The difference to PART I is:
>
> a) getValue ("/bonobo-config-test/test-string") returns all the translations
>    as Bonobo::Config::LocalizedStringList.
>
> b) returns the empty list.
>
> c) raises an exception.
>
> d) does the same than a).
>
> e) getType ("/bonobo-config-test/test-string") returns
>    TC_Bonobo_Config_LocalizedStringList.
>
> f) setValue ("/bonobo-config-test/test-string") requires the argument
>    to be Bonobo::Config::LocalizedStringList.
>
> For GConf, this'll store the sequence as a CORBA any.
>
> To summarize:
>
> * You explicitly use Bonobo::Config::LocalizedStringList as your
>   config item's type.
>
> * It also behaves this way, so the backend doesn't need to provide any
>   special support for this.
>
> * For the xmldb backend, we add a special entry type "localized-string"
>   which is very similar to "string" and use it to store the value.
>
>   This isn't really necessary, but it makes it easier to edit the file
>   with xml-i18n-tools.
>
> * This is also backwards compatible - if you store the CORBA sequence
>   Bonobo::Config::LocalizedStringList, it'll behave like expected.
>
> Btw. the scope of this proposal are configuration keys, not structure
> fields - so if you have a Bonobo::Config::LocalizedString(List) in a
> CORBA struct, it'll be stored like any other struct member.

I think the first proposal is easier for programmers.

- Dietmar