Многоязычный сайт php twig — как лучше реализовать?

Question

[Григорий]

Добрый вечер!
Делаю многоязычный сайт.
Основа backend реализован на php + шаблонизатор twig

Как лучше реализовать мультиязычность?
Вариант использовать i18n twig extension - коллега говорит что gettext на основе которого не очень хороший вариант по ряду неких причин)
Вариант использовать подключаемые словари в зависимости от языка - и преобразовывать их в twig массив
Может ещё какие варианты кто подскажет?)

Comments

[lUser L]

Можете посмотреть как сделано в опенкарте, довольно удобно

[Григорий]

Эмиль 🔥, а как там сделано?)

Answer 1

[ThunderCat]

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

$translate = ['welcome'=>['ru'=>"Приветики",'jp'=>"Komichiwa"]...];

Как достать значения по ключу думаю не надо разжевывать?..

Comments

[Григорий]

По поводу таблицы или отдельного файла вопросов нет)
Интересно понять именно как обрабатывать лучше всего это используя php + twig, ну или просто php

[ThunderCat]

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

Answer 2

[Artem Mamaev]

Я всегда держу в файлах ini ключи для слов.
У меня есть папка lang_pack
В ней имеются подкаталоги de,ru,en,uk и тд.
В каждой из этих папок имеются файлы .ini в которых есть ключи для слов
title=Мой сайт
link_index=Главная страница
И так далее.
Кстати, я делаю для каждого модуля отдельный такой файл.
А на самом сайте использую что-то подобное.

<?php
echo "<a href='/'>".$main->lang('link_index','head_menu.ini')."</a>";
?>

Comments

[ThunderCat]

Кстати, я делаю для каждого модуля отдельный такой файл.

И если у вас 40 модулей и в каждом будет слово "жеппа", вы 40 раз будете копировать это значение в 40 файлов?

[Григорий]

ThunderCat, разве не лучше словари хранить в каждом отдельном файле
Чисто гипотетически вероятность 40 языков крайне мала
2-3 максимум
А если 40 словарей в одном файле, или даже таблице это будет затруднительно и тяжело обрабатывать, мне кажется)

[Ипатьев]

а при чем здесь Twig, я извиняюсь?
здесь я вижу какой-то адов винегрет из РНР и HTML

[Григорий]

Ипатьев, подробнее можно что за винегрет?

При чём тут TWIG:

Вариант использовать i18n twig extension - коллега говорит что gettext на основе которого не очень хороший вариант по ряду неких причин)

[Ипатьев]

ThunderCat, в реальности можно конечно завести отдельный словарь для часто встречающихся слов, но никто обычно этим не заморачивается. Слишком муторно все время менять домен. Плюс в зависимости от контекста, слово жеппа может переводиться как dork, ass, bum, buttocks, bottom и так далее
налетев на другую трактовку один раз, быстро избавляешься от идеи иметь только один перевод для каждого слова.

[Ипатьев]

Григорий, А по-вашему вот это вот echo "<a href='/'>". как-то по-другому называется?

[Сергей delphinpro]

ThunderCat, Зря иронизируете )
В ларавел такой же подход – словари можно разбивать на разные файлы.
И вот прямо сейчас у меня в разных контекстах слово simple переводится по разному: Простой и Легкая форма

[Ипатьев]

и ещё раз. какое отношение этот винегрет имеет к Twig?
в приведённой выше цитате автор говорит от отказе от одного определенного расширения.
но нигде не говорит о том что собирается поменять нормальный шаблонизатор на ваш,извиняюсь, говнокод.

[Григорий]

Ипатьев, переводу будут подвержены только ui-элементы - больше ничего
Остальное в зависимости от локации это текст из базы в зависимости от языка

Вопрос собственно в том как лучше реализовать используя связку php + twig
Twig потому как все он шаблонизатор и весь ui выводится через него (не считая js подгрузок всяких - но это совсем другая история)

Вопрос в том какой способ выбрать для интернационализации сайта, мне просто хотелось бы услышать варианты) Наводки, направление для реализации) Не более

[Ипатьев]

Григорий, я извиняюсь, это вы кому сейчас написали?

[Григорий]

Ипатьев, Вам)

[Ипатьев]

Григорий, но я ещё за час до того написал "варианты) Наводки, направление для реализации)"

[ThunderCat]

Ипатьев,

Плюс в зависимости от контекста, слово жеппа может переводиться как dork, ass, bum, buttocks, bottom и так далее

Собсно именно в этом и есть суть кастомных переводов, именно это я и имел в виду говоря что готовые словари не подходят для качественного перевода и на каждый разный перевод должен быть свой ключ, типа ass=>жеппа, bum=> попец,...

[ThunderCat]

Сергей delphinpro,

И вот прямо сейчас у меня в разных контекстах слово simple переводится по разному: Простой и Легкая форма

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

Григорий, Речь шла не количестве языков, а о количестве модулей, которых на сайте много, и в которых будет куча дублей, которые при изменении 1 перевода нужно будет поменять в 40 местах...

[Сергей delphinpro]

ThunderCat, возможно я вас не так понял.
Сам принцип множества словарей удобен. Можно группировать переводы по каким-то критериям. Соглашусь, что группировка по модулям не очень хороший выбор.
Опять же, если говорить о ларавел, то там ключ уникален в пределах файла, а в приложении вызывается с префиксом имени файла. __('common.simple') __('medical.simple'). Не нужно выдумывать ключи simple1, simple_for_med и т.п.

Answer 3

[Ипатьев]

Если говорить про Twig, а не просто вспоминать былые денёчки, как в пятом классе на коленке переводил мамкин сайт для бижутерии, то для переводов в нем используется фильтр.

То есть берется готовый или делается кастомный фильтр. Который и занимается поиском соответствия для переводимой фразы. Которая выводится, как {{ message|trans }}

Вот пример реализации такого фильтра в Симфони

Если же говорить про переводы вообще, то хранить как угодно, но при деплое писать в массив в пхп файл. Который лежит себе спокойно в опкеше, и подключается тем самым фильтром.