А з 00 років ні чого кардинально не змінилося. Якщо прочитати каменти, то стає очевидним, що частина народ винаходить велосипед в своїх проекту і виходить у них в результаті gettext. Загалом робили-робили, а модуль i18n вийшов gettext.
Я б рекомендував так. gettext використовувати для рідко змінюється інформації. Меню, різні написи робити через нього. При цьому отримуємо ряд плюсів:
1) Формат існуючий багато років і працює на величезній безлічі платформ. А це означає, що він зрозумілий буде будь-якого хто знає про нього, навіть якщо людина не знайомий з тією мовою на якому пишеться система. Тобто всі переваги стандартів. З велосипедами ж доводиться ще разбіратся як воно працює.
2) Кешування. gettext активно кешіться в ОЗУ.
3) Велика кількість софта для перекладачів.
4) Підтримка множин. Не у всіх велосипедах про це думають в тому вигляді, як це зроблено в gettext-е.
5) Підтримка gettext в шаблонних двигунах.
6) З gettext-му можна працювати не тільки з PHP. Актуально на гетерогенних проектах.
Ну а контентну частину рекомендую винести на рівень БД. Особисто я використовую для кожної мови окрему таблицю. Плюс в порівнянні з зберігання в окремому стовпці - відсутність ALTER-ів при додавання / видалення мови.
мені подобається варіант коли
$ Lang [ 'mTitle'] = 'Головна';
$ Lang [ 'mAbout'] = 'Про нас';
Спочатку викликається мова оригіналу, а потім поточну мову, якщо він відрізняється від оригіналу. Таким чином, якщо переведення і не буде, то можна отримати хоч щось.
Хоча в php успішно використовують gettext (наприклад в phpmyadmine), але його складніше ввести. Потрібні утиліти, яких більш ніж достатньо для різних систем.
Я прихильник строкових констант, тобто конструкцій виду i18n :: get ( 'Hello% s!', $ username), або скорочено l ( 'Hello% s', $ username). Але я використовую неймспейси для рядків, а не глобальне сховище. Реалізується дуже просто (відкрили, прочитали, додали, зберегли), і зручно що новий рядок автоматично додається в неймспейс і зберігається.
Особисто для себе, в будь-якому i18n вважаю важливим можливість експорту та імпорту локалізацій (раніше використовував CSV, але через проблеми з UTF переходжу на PO), підтримка словотворення для різних мов (1 яблуко, 2 яблука, 6 яблук), кешування і прискорену (через мета конструкцію) локалізацію view файлів.
На жаль, все це частина фреймворка, але за запитом можу вислати файли з поясненнями.