Как лучше всего реализовать мультиязычность?

Question

[phpus]

Мне понравился единственные вариант, когда создаются файлы, для определенного языка.
Получается ссылка по типу donem.com/en/new?id1

Может есть варианты по лучше ? И где по подробнее можно почитать про этот метод ?
Написать не сложно, но не хотелось натыкаться на камни,о которые все известно.

Плюсы:
Хороший url, понятный, поисковикам понравится, пользователем тоже.
Маленькая нагрузка.
Большая скорость.
Вероятность сбоя почти 0.00000000000000000001)

Минусов я не нашел.
Разве что файловая система и реализация консольного наполнения (создания нового яз. пакета)
Но это больше придирки, нюансы, чем реальные недостатки..

К увы реализация на js+php не существует или я не там искал...
Подобный подход будет сложнее, но более производительнее.

Comments

[Евгений Елчев]

Уточните вопрос, где вы делаете мультиязычность, какой инструмент, вы используете? Какую архитектуру имеет ваше приложение (сайт/портал)? Что вы подразумеваете под "файлами для определенного языка"?

[phpus]

rsi: cms, что-то среднее между сайтом и порталом. От 1000 страниц)
файлы.
nav_ru.php
nav_en.php
Но думаю написать с подходом ООП.
Тогда просто создаем абстрактный класс нав, а дальше классы ru, en итд.
По мне, этот вариант самый оптимальный, изменять и дополнять, удалять не так сложно.
Сложно вносить изменения, придется писать собственный класс для консоли.

[Евгений Елчев]

phpus: cms? вы ее сами пишите с нуля? без фреймфорка? Для чего спрашиваю, у многих продуктов уже есть решения для мультиязычности.

[phpus]

rsi: Почему пишу, написал =) Это как новая возможность или типо того, не суть. Без фреймворка, вырос из них. Дело в том, что в большинстве фреймов старые варианты, кстати и с роутарами похожая ситуация, но получше. С приходом php 5.5 появились новые возможности, которые не используют. Реально, не одной статьи с подобной реализацией, а ведь идея не плохая.

[phpus]

А подводный камень, дописывать роутер, к счастью для меня это 2-3 строчки кода.
Надо подумать еще.

Answer 1

[index0h]

1. Просто php файлы:
+ С ними, таки да, просто работать
- В случае, когда переводов реально много - будете вызалить по памяти
- Правки обязан вносить прогер

2. PO -> MO файлы:
+ Есть куча тулзовин для работы с ними
+ Работает с php довольно таки быстро и памяти кушает не так много
- Обязательная перегенирация MO
- В случае, если переводы делает 3-е лицо, мерджить бывает - не самое приятное занятие

3. БД:
+ Переводы может делать вообще левый человек, не вторгаясь в процесс
- Повышенные требования к миграциям
- Обязательное разделение на части и кэширование

З.Ы. Оригинальный язык для переводов НЕ рекомендую делать нейтивным. Лучше использовать специфические строки в стиле: '{moduleName}:{controllerName}:{actionName}:{blockName}:frase'. В противном случае есть вероятность склейки переводов и может возникнуть ситуация:

В блоке удаления заменили текстовку "ОК" на "Удалить", и магически не постижимым образом на странице регистрации под формой ввода появится одноименная клавиша.

Comments

[phpus]

Конец верно подмечен, но это новичкам =)
Я думаю что лучше хранить в файлах чисто системные, типо навигации..
Для статей или прочего контента, лучше подключить базу =)
Так и поступлю. А кэш, дело тонкое, главное спроектировать правильно, дальше проблем не будет.

Остался просто вопрос, в ссылке хранить яз. переменную или в сессии.
У сессии свои + и недостатки, да и url.

Думаю что лучше использовать (GET).

Answer 2

[Евгений Елчев]

Вырасти из фреймворков это на самом деле странно слышать, но дело ваше. Странно тогда почему вы задаете такие вопросы.

donem.com/en/new?id1
это ваш маршрут "en" идентификатор языка. Определите хранилище для переводов. Это может быть база, это могут быть файлы. У WP как ни странно отличная реализация на данный счет, они хранят переводы в .po файлах, которые даже такие моменты как 1 слон (elephant), 2 слона (elephants), 5 слонов (elephants) учитывают. Напишите один класс, который на основе идентификатора языка и оригинального слова будет выводить перевод. У вашей CMS же есть жизненный цикл, шаблоны? Вот вызывайте этот класс переводов в момент компиляции шаблона. А выглядеть это будет как то так - t("elephant"), а там внутри уже найдется соответствие исходной строки и перевода.

Если вам не только интерфейс, но и содержимое (например статьи) переводить хочется, то определите структуру в базе (вы же в базе материалы храните?) которая бы позволяла одни те же данные хранить на разных языках и пусть ваш класс переводов отдает шаблонам данные на нужном языке на основе идентификатора языка.

Comments

[phpus]

Можно, но это не то. Спасибо!

Answer 3

[Ilya Bobkov]

Как-то так.

/*
----------------------
 МУЛЬТИЯЗЫЧНОСТЬ
----------------------
*/
if ( $_GET["func"] == "GetString" )
{	
  if ( isset($_GET["lang"]) && isset($_GET["string"]) )
  {
     $array = parse_ini_file( $_GET["lang"].".ini" );
     echo $array[ $_GET["string"] ];
  }
  else echo "параметры отсутсвуют!";
}
?>

языковые строки лежат в ini файле в формате:
string = value

Comments

[phpus]

Как простое решение, для маленьких проектов. А так, ни,ни.