Adding a column per table per lang would make the database enormous and would make the translation work way harder.

I think what we need it a script that:

extract all the fields that we have a reason to translate (only the field real name of the trackers I guess) and to append them into the potfile, by brute force.

gettext will know how to translated these when we will pass them the relevant strings extracted from the database.
(apparently, the reference to a line number in the po file does not matter, just the string).

So this is actually doable, and using only gettext.

That would be a greate translation improvement :)

Sorry I dreamt.

Yes, sort of. For examples, just see this page: On top of the page, there are some select boxes, which indicate certain states of this bug report (e.g. Severity, Priority, Resolution, Status).

All these select boxes make perfectly sense to be translated, but the content comes from the SQL-Database and is therefore not recognizable by gettext.

Another option of resolving this bug (instead of duplicating all tables for every language/locale) would be to add another column to the existing tables, named locale (or something along these lines). It would then be possible to select the matching entry (e.g. by adding "locale='de_DE'" to the WHERE-clause). If no such translation exists, the function should revert to the default language and return the entry for e.g. locale='en_US' or maybe even locale='C'.

The HTML select boxes on the site are generated through an SQL query. The returned result contains the id and the text of an item.

This way, only texts from the database are inserted into the select boxes, bypassing gettext.

I think that the severity of this bug is ordinary (or even trivial), but the solution seems to be a major pain in the ass.