Upon startup the client autoconfigures the language used in the database.
The following things influence its decision:
The language is taken from the system locale in the environment variables checked for the GUI language by gmI18N.py.
If there's no i18n_curr_lang table in the database the client assumes that no translations are wanted and tries to work without it. Same if other errors prevent normal operations - a warning is logged and things continue.
If the language given in the database doesn't match the system locale the user is asked whether to update the database setting to that.
If the user chooses "No" when asked whether the database locale should be changed to match the system locale this decision will be remembered in the config file (usually ~/.gnumed/gnumed.conf) until either the system locale is changed or the option removed from the config file. This option can also be edited from within GnuMed courtesy of the ConfigRegistry plugin.
One can influence the system locale setting in per-instance wrapper scripts if so desired.
The database language setting is only updated if translations are actually available for the target language. Two levels of truncation of the system locale are used to find matching translations:
1) full locale: 'de_DE@euro'
2) no dialect: 'de_DE'
3) no country: 'de'
This allows for a missing Austrian translation to fall back to a general German (de_AT -> de) one, for example.