RFC - Storing translated values in a PropertyBag

[Martin Baulig <martin home-of-linux org>]

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.

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.

   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.

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.

Comments are very welcome.

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)