ну підхід в моїй фірмі особливо не відрізняється від підходів @ICE і @Fike. Він більш уніфікований, так як ця система однаково застосовується у всіх продуктах компанії від власної cms на php і порталів asp.net до десктоп і мобільних додатків на delphi.
- Мова системи зберігається в сесії
Є певний xml-файл, в якому оголошуються мови системи, зберігаються переклади всіх фраз, які потрібно переводити, інформація для версійності тощо. Приблизно в такому форматі, наприклад, оголошуються мови:
Сам переклад в такому форматі:
Завдяки файлу досягається будь-яку кількість підтримуваних локалізацій і всі переклади зберігаються в одному місці.
- Для заповнення файлу фразами написаний модуль, який пробігає по всьому вихідного коду і додає в xml. Фрази позначаються особливим чином. Ми беремо в символи подвійного відсотка: %% якась фраза %%. При запуску будь-якої сторінки спочатку запускається парсер, всі фрази в %% %% замінює на потрібну мову і користувачеві вже віддається траніца на його мові.
- Для заповнення файлу перекладами написана десктопна програма, зручна для штатних перекладачів. Вони вже продуктивно працюють з xml-файлом, відв'язані від бд (можуть працювати вдома, можемо просто переклад віддати на аутсорс) і їм діла немає, для чого потрібен цей переклад. При виході нової версії перекладу на сервері замінюється xml-файл, ніяких змін коду не потрібно в принципі.
- Статті ж або тексти великого розміру зберігаємо в бд з різними полями для мов, або мов виносимо в окрему таблицю - якщо не впевнені, що кількість мов залишиться постійним. Тут вже в принципі нічого страшного і немає