RE: stock internationalizations?

[Felix Bellaby <felix pooh u-net com>]

Jeff Garzik writes:
 > Wanted to throw an idea I had out there for comment.  GNOME, from a
 > programmer's perspective, adds a lot in terms of conveneience.  Why not
 > continue with that trend, and provide stock strings representing common
 > concepts that need to be conveyed to a user.
 > 
 > These stock strings could form a least-common-denominator set of
 > responses that could be used by programmers in dialogs and other user
 > interaction.
 > 
 > The great advantage of stock internationalization IMHO is that once a
 > program uses S.I., it is automatically translated into a new language
 > when the S.I. lib is translated into a new language.

The gettext package used for i18n in gnome already makes these kinds
of facilities partially available to gnome programmers. 

gettext allows the creation of a collection of domains, each of which 
stores a set of messages. Most apps use a single domain and most 
domains relate to a single app.

In addition, the gnome libraries have their own domains and all 
apps using these libraries effectively share the translations of the
messages that those libraries generate. 

However, there are also examples of apps in gnome that share a single
domain (e.g. the apps in gnome-games). When a translation for a
message is defined for one of these apps then it automatically becomes
available to all the others. What is more unusual is to have 
apps or libs that use multiple domains, some specific and some
general (though gettext does support this to some extent).

The gettext package was designed under the assumption that shared
domains are fairly pointless and difficult to implement, use and 
maintain. The gettext info pages offer arguments to support this 
position.

gettext indexes messages using the American english translations of
those messages (the "C locale" texts). This indexing method is very
programmer and translator friendly. However, it starts to become
ambiguous when the domains are widely shared because identical 
C locale texts may have different meanings in different contexts 
and need different translations in other languages.

Stock i18n libraries are very likely to contain ambiguous messages 
because messages that can be shared are likely to be inspecific.
This means that stock i18n libraries have to indexed in less 
intuitive ways that break the gettext model.

Because gnome has adopted gettext, stock i18n libraries are unlikely 
to become very important in gnome. The gettext bods argue that 
this is not a problem. I think they may well be right.

However, I can see a case for including stock translations of some
of the strings that appear in things like menus. I assume that gnome
wants to translate "File" and "Help" menu items into the same names
in every app. Perhaps a function that provides stock translations
directly analogous to the stock pixmaps should be put into 
libgnomeui ? 

Felix