Localization

In order to display information in the UI, user-readable information must be localized.

Typical examples are package summary and descriptions. Patch and product information are other examples.

The UI shouldn't need to care about this stuff. It should just retrieve the (localized) string and be able to display it.

Strings are coded in UTF-8

How to store the localized strings inside the classes

The problem is that there are usually many localizations.

Basically, there are two approaches:

store all localized strings in memory

(bad idea, if there are many or big ones.)

load localizations on demand

Both of them have highlights and lowlights. Even if we decide for the later one (which is better choice), we need to read at least one translation. Do (or will) we have the current locale somewhere inside the library accessible for the source manager?

Point of decision!

ApplicationContext

So we install a global ApplicationContext structure which contains basic settings like a default locale.

Mehods returnig locale specific data should then be implemented as

string label();          // return data for locale in appContext
string label( locale );  // return data for specific locale

As rule of thumb, I'd vote for:

string label( locale )

reading the data on demand and returning them. No store in memory.

string label()

calling label( localeFromAppContext ) to get the data. Optionally stores them and furtheron returned then until localeFromAppContext changes.

If we do it like this, we can provide a small helper class, which realizes the (optional) caching to be done by string label().

The helper class has to be templated by the type of value (string, list<string>, ...). On construction it needs a pointer to the real string label( locale ) method that actually retrieves the data.
And a flag whether to cache or not.

class X
{
private:
Helper<string> labelHelper,

X()
: labelHelper( &'string label( locale )' )

string label()           { return labelHelper.getData(); }
string label( locale )   { read data from disk, or ....}

Something like this, or each class implements it's own strategy.

I can draft the helper. Until it's ready:
string label( locale ) has to be implemented anyway.
string label() should simply call label( "en" ).

Would be interesting to see how slow permanent rereading actually is. Maybe caching doesn't pay at all ;) Anyway, using a helper it will be easy to switch be behavior of individual attributes without changing anything in the class. And it offers the option to completely turn of caching at runtime, if memory gets low for example.

Implementation considerations

back

Last edit in Trac '11/24/05 18:49:06' by 'kkaempf'

Libzypp/Design/Localization

Localization

How to store the localized strings inside the classes

ApplicationContext