germansr wrote
I would like to suggest the following option of dynamic content localization for discussion.
1.Add "Locale" column to core tables
2.Modify The SqlHelper.ExecuteNonQuery() methods which are used to access and modify database so to pass the locale value to stored procedures by default
3.Modify stored procedures targeting multilingual content
4.Add second language selector to the skin that will set value of "editlanguage" cookie to the selected locale and redirect to current page then to obtain content of the module in edit or settings mode in selected language.
Germans, you asked for feedback on your proposal. I already did a sum up in Peter's thread in this forum about advantages and disadvantages of various solutions. I see the following appliying to your suggerstions:
pro: no additional tables needed - on the first view. But as we do not need to translate numeric values and some strings as names, several tables have to be split up into base table and localizable table.This applies for all core module tables with localizable data as well as all according tables of custom modules.
con: how to determine base language? if you have a portal with contributions by users in various languages, you need to have to determine the original language, date of translation, in order to check, which might be outdated, and so on.
There are other open questions: how to realize a central interface to a translation service? For a big web site with huge ML content translation cost will be a major criteria. Therefore an efficient interface to translation services is needed (as long as automated translation is not sufficient). The interface needs to determine, wh texts are untranslated or updates and need (partial) retranslation. Admins and Authors must have an option to determine, which translations are needed.
With these picture in mind, content localization gets more complex than your solution maight be able to handle.
Sebastian