3.7. Backend I18N for non-dynamic ("fixed") strings in the backend.

3.7.4. How to make the frontend use translated strings

All the backend infrastructure is in place now so we can make frontends aware of translated strings. The first step is to make frontends use the v_i18n_* views instead of the tables. If we fail to do that everything will still work. We just won't get translations :-)

The second step is to make sure the current user has a language selected in i18n_curr_lang. Use something like

insert into i18n_curr_lang(lang) values ('de_DE');
		

This will default to the CURRENT_USER. The actual value need not conform to anything in particular. It can be "Klingon" for that matter. Make sure then to have "Klingon" translations available in i18n_translations.

This i18n technique does not take care of strings that are inserted into the database dynamically (at runtime). It only makes sense for strings that are inserted once. Such strings are often used for enumerations.

All this crap isn't necessary anymore once PostgreSQL supports native internationalization of 'fixed' strings.