Какие есть нормальные методы по созданию многоязычного сайта?

Question

[евГений Карлоний]

Для себя видел два варианта создания переключения языка:
1) Создаю 2 файла состоящие из таких данных

рус
прив = Здравствуй мир
сайт = Мой сайт

eng
прив = Hello World
сайт = my site

В зависимости от выбранного языка скачиваю файл в массив и подставляю в нужных местах содержимое прив и сайт.

2) создаю базу вида:

имя | рус | eng
прив | Здравствуй мир | Hello World
сайт | Мой сайт | my site

В зависимости от выбранного языка скачиваю в массив и подставляю в нужных местах содержимое прив и сайт.
может есть более правильные варианты? или какой метод из этих эффективнее?

Answer 1

[Saboteur]

В большинстве случаев, первый вариант лучше.

1. Поддерживать языковые файлы - проще, чем sql (проще и свободнее синтаксис)
2. Проще расширять в случае дополнительных языков - главное заранее продумать именование языковых файлов, чтобы переход на язык автоматически подгружал нужный файл, типа include lang_$lang.php

Хранить все в базе имеет смысл только из-за организационных/security решений (например дать доступ к базе безопаснее, чем к файловой системе, и тогда все хранить в базе)

Answer 2

[Dimonchik]

первый общепринятый

en={}
en['hw'] = 'Hello, Microsoft Word!'
en['title'] = 'This is my multilangual site'

ru={}
ru['hw'] = 'Привет, Ворд'

#templates/ru.html
title = ru['title'] if 'title' in ru else en['title']

та же особенность у редактора - сразу видно состояние перевода на конкретный язык

единственные вариации: хранение в разных языковых файлах/модулей массивов с одинаковыми именами, лбо в одном с именами языков, обычно хранят в разных, т.к. а) не нужно включать ненужное; б) языки - это не только слова, но и форматирование (оцените длину немецких слов), и таким же образом хранят параметры div ов и проч

Answer 3

[Philipp]

Есть несколько стандартов для локализации (i10n) и интернационализации (i18n).

Довольно неплохой разбор разных правил сделан здесь
guides.rubyonrails.org/i18n.html
https://www.npmjs.com/package/i18n
https://docs.angularjs.org/guide/i18n
php.net/intl

Везде несколько разный подход, но в целом все сводится к созданию карты и условностей.
Лично я бы хранил данные для перевода в 2х местах.
Первое место - самый быстрый способ хранения для вашего ЯП/фреймворка. Этот вариант для продакшена и нагрузки.
Второе место - база, для редактирования. После редактирования автоматическая генерация файлов для первого варианта.
Механизм перевода должен быть реализован так, что если в режиме разработки/тестирования встречается незнакомый перевод, он сохраняется в базу. В дальнейшем это приводится в нормальный вид профессиональным переводчиком, для которого должен быть создан соответствующий интерфейс.

Answer 4

[d-stream]

Потом начнется второй виток:

"на сайте 3 пользователя" <> "на сайте 5 пользователей"
супротив
"online 5 users" == "online 3 users"

Comments

[Saboteur]

языковые файлы это обычно подключаемые .php файлы, поэтому можно и функции добавить, типа
"на сайте"+$online+"пользовател"+generate_number_suffix($online);

[d-stream]

Saboteur: Ага, потом числительные прописью в разных родах и т.п. - это как раз и есть второй виток понимания, что в разных языках построение фраз разное. Потом третий уровень...

[евГений Карлоний]

d-stream: и какой выход по вашему? даже на одном языке нужно доп обработку писать на окончания

[d-stream]

евГений Карлоний: Да, даже на одном языке есть куча нюансов, в связке нескольких языков - их вырастет на порядок. Ну и напрашиваются разные пути:

1. Разные сайты/разделы - иногда даже с разной версткой (к примеру то же написание справа налево для арабских языков) - с учетом менталитета и традиций основной аудитории конкретного языка (вплоть до отдельных UK и US English)
2. Построение словарика Эллочки Людоедовой и навешивание на него реализации склонений-спряжений и прочей country-specific
3. Перекорячивание текста в некий "пиджин" - максимально упрощенный язык и построение фраз для минимизации коллизий
4. Нечто в стиле автоперевода как на ali -)) или как переводы комментов на трипадвизоре

[Saboteur]

d-stream: Тем не менее, в языковых .php файлах можно все эти понимания реализовать, а в базе данных - вообще все переделывать )

[d-stream]

Saboteur: Безусловно. Только надо отметить, что это очень нетривиальная задача и разруливание каждого пласта влечет за собой следующий, еще более специфический.

Как иллюстрация - тупая сумма прописью для десятка языков. Вроде мелочь, но реализация получается достаточно колбасообразной, а когда появляется необходимость присобачить к юридическо-нотариальным требованиям число-месяц и год прописью - оказывается, что для года - отельная колбаса со своей кривизной -))