You can create a table with three columns: target language code , source string, translated string. The index in the table will be in the first two columns, but I would not bind this table to other tables with foreign keys. You will need to add a connection (possibly a left connection with an account for missing transfers) for each of the conditions that need to be translated in each request that you run. However, this will make all your queries very hairy and possibly kill productivity.
Another thing you need to know about is actually translating the terms and maintaining an updated translation table. This is very inconvenient to do directly against the database and is often done by non-technical people.
Typically, when you localize an application, you use something like gettext . The idea behind this toolkit is to parse the source code to extract the strings for translation, and then create translation files from them. Since this package has existed for a long time, on its basis there are many different utilities that help with the translation task, one of which is Poedit , a beautiful graphical editor for translating strings into different languages. It may be easier to generate a unique list of terms, because they appear in the database in the gettext format, which can parse and translate in the application code. Thus, you can translate hard-coded strings in the application and database values using the same technique.
gooli source share