Бросается в глаза, что безопасность сосёт. Надеюсь впоследствии исправите.



Обычно заводится массив с языковыми переменными, а по всему движку используется вывод переменных из этого массива.
У Вас же есть структура уже. Где надо заголовок сайта, пишете <?=$lang['title']?>

У меня немного другой опыт.
Удобно для автозамены языка везде по сайту делать переменные текстовыми на английском языке через функцию:
[PHP]function __($string){
global $lang;
if(!empty($lang['def'][$string])) {
return $lang['def'][$string];
} else {
return $string; }
}
[/PHP]
А переменные инклюдятся из такого массива:
[PHP]$lang['def']['Images resizing'] = 'Памер малюнкаў';
$lang['def']['Width single image in gallery (pixels)'] = 'Шырыня адзіночнай карцінкі ў галерэі (кропак) ';
$lang['def']['Automatic resizing image (lightbox effect)'] = 'Аўтаматычнае змяненне памеру карцінкі (эфект lightbox) ';
$lang['def'][' and comments (add by [img] tag)'] = ' і каментары (дадаваць з дапамогай тэга[img])';
$lang['def']['Width image in articles and comments (pixels)'] = 'Шырыня карцінкі ў артыкулах і каментарах (кропак)';[/PHP]

В самом же движке мы пишем так:
[PHP]<?=__('Width image in articles and comments (pixels)')?>: <input name="width" value="150">[/PHP]

Den1xxx, вывод Notice'ов конечно можно отключить но они от этого не перестанут быть таковыми. Сравнение огромных строк являющихся ключами в хеше это вообще треш. Кстати, какую смысловую нагрузку несет "def" - больше кнопок на клавиатуре тыкать в процессе написания кода?

DEF - default в данном случае

Не советую писать def в Вашем движке, я копипастнул с ReloadCMS, там просто это исторически сложилось.
Т.к. есть ещё 2 массива лангов — там переводы есть всегда на всех локалях и их наличие не проверяется (время и дата).


Согласен, я нигде и не советовал их отключать. Мало того, у меня они включены по умолчанию при разработке, т.к. я считаю что их не должно быть по-хорошему вообще, и всячески устраняю.


Почему треш? Проверка — существует ли значение в массиве происходит достаточно быстро и не жрёт много памяти.
Весь массив текущего языка занимает обычно до 70кб, но на странице используется порядка 2х десяток строк локализации.
А вот попытка вывести НЕСУЩЕСТВУЮЩЕЕ значение из массива (без проверки его наличия) генерирует варнинг, при подавлении которого ресурсы расходуются во много раз больше.
Бывает, что при разработке долго не обновляется локаль, например, греческого языка. Или там ещё вот эсперанто тоже есть — только 2 любителя этой экзотики мне попалось за всё время, один из них и перевёл. При отсутствии в текущей локали перевода с английского будет просто фраза на английском.

Вообще в ReloadCMS подход хоть и простой, но тоже не совсем правильный. Там массив локали подхватывается и для залогиненных, и не для залогиненных пользователей, просто из папки текущего языка, сейчас языков 13.
Правило сейчас такое: написал новый модуль — ложишь его перевод отдельным файлом в ланги.
При деинсталляции ланги сотрутся вместе с модулем.

По-хорошему надо бы разделить — для гостей, для зарегистрированных, и для админа. Т.к. по-хорошему
локаль админки может занимать до 70% всей локали, но тогда появляются другие, ещё злейшие, вопросы:
1. То, что сейчас просто — усложнится, и сильно, ибо в системе 3 способа назначать права (суперадмин, уровень доступа(целое число), права управление конкретным модулем — например статьями или модерация форума).
2. Будут дубли переводов.
3. Разделить, то что сейчас в куче, достаточно сложно.
Потому пока оставлено так, потому что не придумано лучшего решения.

А 70кб могло бы сократиться до 2кб, для гостей хотя бы.

Я подумывал сделать отдельно ланги для зареганных и для незареганных, но пока не решился.

Фразы без контекста вообще я считаю нужно сразу переводить при изменении 1 раз, а если делать это налету то это ненужный бесполезный оверхед и лишнее усложнение шаблонов.

Вообще-то 1 раз не получится перевести — на сайте могут быть пользователи с разными языками, и движок показывает им забитые в шаблон фразы на их родном языке.
Если в админке стоит галочка на «Пытаться определить язык пользователя».

Den1xxx, Что это не получится? Переводы вероятно не сферические кони в вакууме составляют, так что вы всегда знаете % перевода на конкретный язык. При изменении базового шаблона формируете аналогичные языковые шаблоны для которых есть переводы, лексемы которые не переведены остаются на базовом языке. При добавлении перевода формируете комплект шаблонов для конкретного языка.
Контекстные переводы(например которые в разных числовых формах меняют корень слова) остаются вычислимыми и как правило уже имеют гораздо более сложную логику, для того же русского - их вообще лучше обрабатываться в коде.

1 раз - это не на один язык конечно же, это значит непосредственно при изменении шаблона или перевода, а не при каждом запросе посетителя сайта!

Arks, я ничего не понял из того что написали. Можно на примере показать, для такого тупого, как я?

Den1xxx, не могу, пример будет очень большим и потребует очень много времени. Напишу текстом, если хотите обсудить подробности кода то лучше в ЛС.

Концепт очень простой:
1. есть мультиязычный сайт
2. есть мультиязычные шаблоны + разработческий комплект шаблонов(который служит основой мультиязычным комплектам шаблонов)
3. есть админка.
4. в админке есть переводы - они структурируют специальные куски кода разработческого комплекта шаблонов и позволяют эти куски переводить на разные языки(не важно где хранятся переводы - gettext .po/.mo, БД, сразу в файлах или конфигах и т.п.).
5. переводы в админке редактируют переводчики
6. при редактировании переводов создаются/обновляются конкретные комплекты мультиязычных шаблонов.
7. юзер при входе на сайт или выборе языка использует конкретный комплект мультиязычных шаблонов соответствующий выбранному языку.

По сути остается только добиться того чтобы сервисные задачи(поиск новых/изменившихся лексем в разработческом комплекте шаблонов) выполнялся прозрачно для пользователя и админов-переводчиков, если забыть про такие вещи как cron и деплой.
Вместо того чтобы мучать процессор при разборе шаблона и поиска его переводов - мы кладем немножко побольше готовых переведенных файлов на диск. От "немножко побольше файлов на диск" - еще никто не умирал.