[Gnumed-devel] problems handling i18n

[Karsten Hilbert]

Several times now I have come across the following i18n
problem:

To make a concise GUI one wants to use short phrases that get
their precise meaning from the context of the widget. This
will amount to one or two words in many cases. However, those
words may be used in other widgets, hence in another context,
hence with a different meaning. It is certainly possible to
translate them context-sensitive. But gettext uses the plain
string as the key to retrieve the translation ! Hence it is
not possible to provide context-sensitive and thus varying
translations for the same phrase !

The only solution I know is to place those ambigous strings
into dictionaries being accessed by string keys. Those
stringed keys can in turn be translated by gettext and used as
the key to the real, context-sensitive translation.

Consider the term "relationship". We might use it to label a
field for selecting the family relationship of two people. We
don't want to label that field "family relationship" because
a) that takes up to much space and b) the "family" part is
redundant in the context of the widget. On the other hand,
"relationship" might be used in a widget linking two diagnoses
of a patient denoting whether there's an inner "medical
relationship" between them. Of course, the GUI will again only
display "relationship". (Maybe this is not a particularly good
example but it demonstrates the point.)

ambig_str_defs = {
    '_familial_relationship' = 'relationship',
    '_medical_relationship' = 'relationship'
}

def xlate_ambig_str(aUniqueString):
    xlated = _(aUniqueString)
    if xlated != aUniqueString:
        return xlated
    try:
        return ambig_str_defs[aUniqueString]
    except KeyError:
        return aUniqueString

and then

print xlate_ambig_str('_familial_relationship') in the
appropriate place.

I do not consider this a particulary nice and tasteful
solution. Part of the problem, BTW, stems from the fact that
gettext customarily uses the actual keys as fallback for the
default translation. I wonder if things could be made to work
if an english translation file is provided explicitely. I will
write to them about this.

Any thoughts/comments ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346