2008-10-01 1 views
20

Я собираюсь работать над проектом, в котором достаточно большое веб-приложение должно настраиваться для обработки нескольких языков. Вещь работает с созданным вручную PHP-кодом, но это довольно чисто.Как бы вы преобразовали ранее существовавшее веб-приложение в многоязычный?

Мне было интересно, что было бы лучшим способом сделать это?

  1. Создание чего-то самостоятельно, пытаясь соответствовать реальной архитектуре.

  2. Переписывая значительную часть его, используя фреймворк (например, Symfony), который будет управлять i18n для меня?

Для варианта 1, где я должен хранить данные i18n? * .po, xliff, чистый DB?

Я думал об альтернативе: используя Symfony только для перевода, но устанавливая контроллер для загрузки веб-сайта, как он есть. Быстро, но грязно. С другой стороны, это позволяет нам сделать следующую модификацию, медленно двигаясь до полной Symfony: этот веб-сайт действительно является хорошим кандидатом для этого.

Но, возможно, есть отдельные автономные механизмы перевода, которые лучше всего работали бы над всей веб-картой. Это немного похоже на использование базыки, чтобы убить муху ...

ответ

10

Существует несколько способов решения этой проблемы. Ни один из них «лучший способ», и все они с проблемами в краткосрочной или долгосрочной перспективе. Самое первое, что можно сказать, это то, что многоязычные сайты нелегкие, переводчики и прекрасные люди, но с трудом работать, и большинство программистов рассматривают проблему как техническую. Существует также другое измерение, выходящее за рамки этого ответа, относительно того, выполняете ли вы перевод или локализуете. Это включает в себя изучение культурной атмосферы целевой аудитории, а затем адаптацию языка, стиля, макета, цвета, шрифта и т. Д. К этой культуре. Наконец, не используйте MT, машинный перевод, для чего-либо серьезного или если он должен быть точным, и при приобретении переводчиков убедитесь, что они переводят с иностранного языка на их родной язык, что означает, что они понимают все нюансы целевого языка.

Право. Решения. Исходя из того, что вы не хотите переписывать сайт, просто клонируйте свой сайт и переведите копии на целевой язык. Предполагая, что база кода стабильна, вы можете использовать VCS для управления любыми изменениями кода. Вы можете настроить отдельные части сайта так, чтобы они соответствовали целевому языку, например, французский текст в среднем на 30% больше, чем эквивалентный текст на английском языке, поэтому использование одного сайта для доставки означает, что вы можете (иметь) проблемы с форматированием и должны различный css-файл в и в зависимости от языка. Это может показаться неуклюжим способом сделать это, но как долго будут существовать сайты? Накладные расходы на управление этим способом могут быть меньше, чем другие варианты.

Второй путь без перестройки. Замените весь контент на текущем сайте тегами и затем поместите другой язык в файлы или таблицы db, обнюхайте нужный язык пользователей (у вас есть зарегистрированные пользователи, которые могут сделать предпочтение или вы хотите получить тег языка браузера, или это будет URL dot-com dot-fr, dot-de, который сделает выбор), а затем замените теги на целевой язык. Затем вам нужно решить проблемы с размерами и проблемы с изображениями отдельно. Это решение действует, когда такие платформы, как Symfony и Zend, реализуют l10n.

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

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

12

Работа с файлами языков.

  1. Заменить каждую строку текста с помощью переменной
  2. Создать один файл языка для каждого языка и в нем определяют каждую переменную с их соответствующим текстом. (french.inc, dutch.inc ...)
  3. Включите правильный файл на каждой странице.

Это для небольших сайтов.

Если все больше, замените файлы на БД. :)

+0

Я думаю, что это очень изящное решение, не знаю, почему у него всего 3 голоса. – 2013-04-07 01:18:41

+0

Этот ответ должен быть сверху, так как он одновременно: простой и эффективный. – Ahmad 2016-01-06 10:20:17

+1

Элегантный? Просто? О нет. @Veynom абсолютно прав, говоря, что он предназначен для небольших сайтов. Когда вы открываете свой код и видите переменные вместо текстовых строк на английском (или ваш первый язык), это становится все более громоздким для поддержания. – 2016-03-22 23:29:12

2

Вы можете посмотреть Zend_Translate, это довольно полное, хорошо документированное и общее качество кода отлично. Он также позволяет использовать унифицированный API для gettext, csv, db, ini-файла, массива или того, что вы в конечном итоге сохраняете в своих переведенных строках.

Также посмотрите/посмотрите эту тему: What are good tools/frameworks for i18n of a php codebase?. Это похоже на ваш вопрос.

1

Если это многобайтовая поддержка символов, то это может быть стоит проверить мультибайтные строковые функции в PHP:

http://uk.php.net/manual/en/book.mbstring.php

Они будут лучше обрабатывать многобайтовые символы.

-2

Я использую параметр hl и gettext, объединяющий переводы движений уже там с собственными.ро, что делает новые переводы и языки появляются, когда двигатель или мой Джанго/GAE example добавляет:

{% 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 %} 

Так держать от дублей и полностью используя переводы там уже позволяет далее здесь недостающие например, арабские названия месяцев появляться либо непосредственно, когда двигатель команда добавляет или app

3

Важно заметить, что существует два шага до перевода:

  1. Интернационализация: то есть, что позволяет ваш сайт, чтобы работать с нескольких языков
  2. Локализации: это включает в себя перевод ваших текстов (полученные на стадии 1) на каждый язык, который вы планируете поддерживать

See more on this in Wikipedia.

Шаг 1 потребует, чтобы вы учли тот факт, что некоторые языки написаны справа налево (RTL) и неевропейские символы, такие как японский или китайский.Если вы не планируете обрабатывать эти языки и символы, это может быть проще.

Для такой ситуации я предпочел бы иметь языковой файл (на самом деле, как многие языковые файлы в качестве языков, которые я планирую поддерживать, называя каждый, как langcode.php как в en.php или fr.php) с ассоциативным массивом, содержащим все тексты, используемые в сайт. Процедура будет идти следующим образом:

  1. Сканирование вашего сайта для каждого отдельного текста, который должен быть локализован
  2. Для каждой страницы/раздела Я хотел бы создать $lang['sectionname'][] массив
  3. Для каждого текста я хотел бы создать $lang['sectionname']['textname'] запись
  4. Я хотел бы создать Lang.php класс, который получает параметр lang при конкретизации, но будет иметь значение по умолчанию в случае, если нет lang получен (этот метод загружает langcode.php в зависимости от параметра или по умолчанию в зависимости от вашего прив заблуждался язык)
  5. Класса будет иметь setPage() метод, который будет получать/раздел страницы вы будете отображающим
  6. Класс будет иметь show() метод, который получает текст, который будет отображаться (show() будет называться так много раз, поскольку тексты представлены на данной странице ... show() быть своего рода оберткой для echo $lang['mypage']['mytext'])

Таким образом, вы можете иметь столько языков, сколько вы хотите в очень простой способ. У вас может даже быть администратор языка, где вы открываете страницу базового языка (вы на самом деле просто читаете рекурсивно массивы и отображаете их в текстовых областях), а затем можете «Сохранить как ...» на каком-то другом языке.

Я использую аналогичный подход в my site. Это только одна страница, но я сделал multi-page sites с этой идеей.

Если у вас есть пользовательский контент или довольно сложная CMS, это будет другая история. Вы можете искать i18n-дружественные рамки (Drupal приходит на ум).