Я собираюсь работать над проектом, в котором достаточно большое веб-приложение должно настраиваться для обработки нескольких языков. Вещь работает с созданным вручную PHP-кодом, но это довольно чисто.
Мне было интересно, что было бы лучшим способом сделать это?
Сделав что-то самостоятельно, пытаясь соответствовать реальной архитектуре.
Переписывая значительную часть его, используя фреймворк (например, Symfony), который будет управлять i18n для меня?
Для варианта 1, где я должен хранить данные i18n? * .po, xliff, чистый DB?
Я подумал об альтернативе: использование Symfony только для перевода, но установка контроллера для загрузки веб-сайта, как он есть. Быстро, но грязно. С другой стороны, это позволяет нам сделать следующую модификацию, медленно двигаясь до полной Symfony: этот веб-сайт действительно является хорошим кандидатом для этого.
Но, возможно, есть отдельные автономные механизмы перевода, которые будут работать лучше, чем вся веб-инфраструктура. Это немного похоже на использование базыки, чтобы убить муху …
Существует несколько способов решения этой проблемы. Ни один из них «лучший способ», и все они с проблемами в краткосрочной или долгосрочной перспективе. Самое первое, что можно сказать, это то, что многоязычные сайты нелегкие, переводчики и прекрасные люди, но с трудом работать, и большинство программистов рассматривают проблему как техническую. Существует также другое измерение, выходящее за рамки этого ответа, относительно того, выполняете ли вы перевод или локализуете. Это включает в себя изучение культурной атмосферы целевой аудитории, а затем адаптацию языка, стиля, макета, цвета, шрифта и т. Д. К этой культуре. Наконец, не используйте MT, машинный перевод, для чего-либо серьезного или если он должен быть точным, и при приобретении переводчиков убедитесь, что они переводят с иностранного языка на их родной язык, что означает, что они понимают все нюансы целевого языка.
Правильно. Решения. Исходя из того, что вы не хотите переписывать сайт, просто клонируйте свой сайт и переведите копии на целевой язык. Предполагая, что база кода стабильна, вы можете использовать VCS для управления любыми изменениями кода. Вы можете настроить отдельные части сайта так, чтобы они соответствовали целевому языку, например, французский текст в среднем на 30% больше, чем эквивалентный текст на английском языке, поэтому использование одного сайта для доставки означает, что вы можете (иметь) проблемы с форматированием и должны различный css-файл в и в зависимости от языка. Это может показаться неуклюжим способом сделать это, но как долго будут существовать сайты? Накладные расходы на управление этим способом могут быть меньше, чем другие варианты.
Второй путь без перестройки. Замените весь контент на текущем сайте тегами и затем поместите другой язык в файлы или таблицы db, обнюхайте нужный язык пользователей (у вас есть зарегистрированные пользователи, которые могут сделать предпочтение или вы хотите получить тег языка браузера, или это будет URL dot-com dot-fr, dot-de, который сделает выбор), а затем замените теги на целевой язык. Затем вам нужно решить проблемы с размерами и проблемы с изображениями отдельно. Это решение действует, когда такие платформы, как Symfony и Zend, реализуют l10n.
Затем вы можете перестроить с помощью фреймворка или с помощью gettext и, возможно, иметь более чистое решение, но помните, что фреймворки были разработаны для решения других проблем, а не для перевода, а компонент перевода пришел в рамки как частичное решение, а не полное.
Большой проблемой со всеми решениями является постоянное обслуживание. Потому что не только у вас есть база кода, но и несколько языковых баз для поддержки. Если вы все в одном решении не будете действительно умны и эффективны, то текущая задача будет сложной.
Работа с файлами языков.
Это для небольших сайтов.
Если все больше, замените файлы на БД. 🙂
Важно отметить, что перед переводом необходимо выполнить два этапа:
Подробнее об этом в Википедии .
Шаг 1 потребует от вас учета того, что некоторые языки написаны справа налево (RTL) и неевропейские символы, такие как японский или китайский. Если вы не планируете обрабатывать эти языки и символы, это может быть проще.
Для такого типа ситуаций я бы предпочел иметь языковой файл (на самом деле столько языковых файлов, сколько языков, которые я планирую поддерживать, называя их как langcode.php как в en.php или fr.php ) с ассоциативным массивом, содержащим все тексты используется на сайте. Процедура будет следующей:
$lang['sectionname'][] $lang['sectionname']['textname'] Lang.php , который получил бы параметр lang при создании экземпляра, но имел бы значение по умолчанию в случае, если lang не получен (этот метод загружает langcode.php зависимости от параметра или значения по умолчанию в зависимости от вашего предпочтительного языка) setPage() , который получит страницу / раздел, который вы будете отображать show() , который получит текст, который будет отображаться ( show() будет вызываться столько раз, сколько тексты отображаются на данной странице … show() является своего рода оболочкой для echo $lang['mypage']['mytext'] ) Таким образом, вы можете иметь столько языков, сколько хотите, очень просто. У вас может даже быть администратор языка, где вы открываете страницу базового языка (вы на самом деле просто читаете рекурсивно массивы и отображаете их в текстовых областях), а затем можете «Сохранить как …» на каком-то другом языке.
Я использую подобный подход на своем сайте . Это только одна страница, но я создал многостраничные сайты с этой идеей.
Если у вас есть контент, предоставленный пользователем, или довольно сложная CMS, это будет другая история. Вы можете искать i18n-дружественные рамки (Drupal приходит на ум).
Вы можете посмотреть Zend_Translate , это довольно полное, хорошо документированное и общее качество кода. Он также позволяет использовать унифицированный API для gettext, csv, db, ini-файла, массива или того, что вы в конечном итоге сохраняете в своих переведенных строках.
Также посмотрите / посмотрите эту тему: Какие хорошие инструменты / фреймворки для i18n php codebase? , Это похоже на ваш вопрос.
Если это многобайтовая поддержка символов, возможно, стоит проверить многобайтовые строковые функции в PHP:
http://uk.php.net/manual/en/book.mbstring.php
Они лучше справятся с многобайтовыми символами.
Я использую параметр hl и gettext, комбинируя переводы движений уже с собственным .po, который создает новые переводы и языки, когда двигатель или пример django / gae добавляются:
{% get_current_language as LANGUAGE_CODE %}{{ LANGUAGE_CODE }}{% get_available_languages as LANGUAGES %}{% for LANGUAGE in LANGUAGES %}{% ifnotequal LANGUAGE_CODE LANGUAGE.0 %}{{ LANGUAGE.0 }}{% endifnotequal %}{% endfor %}
Таким образом, сохранение дубликатов и полное использование переводов уже там приводит к тому, что отсутствующие, например, арабские месячные имена появляются непосредственно либо при добавлении команды двигателя или приложения