Локализация сайта для многобайтовых языков

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

  • Если я использую экстернализацию строк, строки для японского или корейского языка должны быть в форме Unicode в файле локали (т.е. 台北 вместо 台北 как строковое значение)?
  • Имеет ли смысл хранить локализацию в БД (т.е. MySQL) и получать соответствующие значения с помощью функции локализации в PHP?

Ваш вклад высоко ценится.

С наилучшими пожеланиями

Источник

3 ответа

Решение

Я сомневаюсь, что экстернализация строк будет вашей самой большой проблемой. Но позвольте мне дать вам несколько советов.

Струнная экстернализация

Конечно, вам нужно отделить переводимые строки от кода. Я бы рекомендовал хранить перевод в виде простого текста, файла в кодировке UTF-8, содержащего пары ключ-значение:

some.key=some translation

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

Определение языка

Веб-браузеры так приятно отправлять заголовок AcceptLanguage каждый раз, когда они отправляют запрос. Что вам нужно сделать, это прочитать содержимое этого заголовка и проверить, поддерживаете ли вы какой-либо из языков, перечисленных пользователем. Если это так, прочитайте файл ресурса (как определено выше) и верните строки для данного языка, в противном случае верните язык по умолчанию. Пример кода ниже даст вам наиболее желаемый язык (который не обязательно тот, который вы поддерживаете):

<?php
$locale = Locale::acceptFromHttp($_SERVER['HTTP_ACCEPT_LANGUAGE']);
echo $locale;
?>

Это все еще не самая большая из ваших проблем.

Стили и таблицы стилей

Настоящая проблема с многоязычными веб-сайтами или веб-приложениями - это стили. Люди склонны вставлять определения стиля в линию, что, по меньшей мере, проблематично. Кроме того, дизайнеры склонны считать, что Arial - лучший шрифт для всей вселенной, поэтому акцент всегда должен идти жирным шрифтом. Единственная проблема заключается в том, что шрифт может быть нечитаемым при некоторых обстоятельствах.
Должен признать, я не знаю, почему это происходит, но в большинстве случаев веб-браузеры склонны игнорировать жирный атрибут для азиатских сценариев (что хорошо), но иногда это не так, и это может стать серьезной проблемой для конечных пользователей, если ваше определение шрифта сказать font-family:Arial; font-size:10px;,

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

Изображения, содержащие локализуемый текст, также могут вызывать головную боль, вам нужно будет либо экстернализовать такие тексты (и записать их, как любой другой элемент HTML), либо подготовить многоязычную структуру ресурсов (т.е. поместить все изображения в каталоги, названные в честь кода языка ("en", "ja", "ko")).

Однако настоящей проблемой являются жестко закодированные теги форматирования, такие как <b>, <i>, <u>, <strong>и т.д. Никто не должен использовать их в настоящее время, вместо этого следует использовать классы стилей, но обычная практика отличается. Вам, вероятно, придется заменить их классами стилей; каждый элемент может иметь более одного класса стилей, что, к моему удивлению, не является общеизвестным (например, <p class="main boldText">).

Хорошо, после того как ваши стили выведены на экран, вы, вероятно, будете вынуждены реализовать какой-то механизм локализации CSS. Это нужно в свете того, что я написал выше. Самый простой способ сделать это - создать структуру каталогов, аналогичную той, которую я упоминал ранее - "en" для базовых английских CSS-файлов, "ja" для японского и "ko" для корейского, так что каждый язык будет иметь свой отдельный набор CSS-файлов. Это похоже на скины пользовательского интерфейса, только в этом случае пользователь не сможет выбрать скин, вы решите, какой CSS будет их представлять - вы все равно обнаружите язык.

Что касается встроенных определений стиля (<p style="whatever">), после определения механизма CSS L10n, вы можете переопределить любой стиль, принудительно назначив его !important ключевое слово. То есть, если кто-то в своем неправильном уме не поместит это ключевое слово в определение стиля в строке.

сцеплений

Ну, это твоя самая большая проблема. Даже люди, которые понимают необходимость экстернализации строк, имеют тенденцию объединять строки следующим образом:

$result = $label + ": " + $product;
$message = "$your_basket_is + $basket_status + ".";

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

Что вам, вероятно, нужно сделать, это удалить такие объединения или использовать некоторые средства форматирования сообщений. Пример PHP (взятый прямо с веб-страницы, на которую я ссылаюсь) будет:

<?php
$fmt = new MessageFormatter("en_US", "{0,number,integer} monkeys on {1,number,integer} trees make {2,number} monkeys per tree");
echo $fmt->format(array(4560, 123, 4560/123));
$fmt = new MessageFormatter("de", "{0,number,integer} Affen auf {1,number,integer} Bäumen sind {2,number} Affen pro Baum");
echo $fmt->format(array(4560, 123, 4560/123));
?>

Как вы можете видеть в этом примере, числа также отформатированы для большого стиля локали. Это приводит нас к:

Форматирование с учетом локали

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

Резюме

Я только что представил вам краткое введение в многоязычный дизайн веб-сайта с акцентом на целевые рынки Японии и Кореи. Если в какой-то момент вам также потребуется поддержка упрощенного китайского языка, вероятно, потребуется поддержка кодировки GB18030. Это было бы очень сложно...

Источник

0.02 $ от кого-то, кто имеет некоторый опыт работы с i18n...

  1. Держите ваши переводы в удобочитаемой форме, так как они, скорее всего, будут переводчиками, а не программистами, управляющими этими ресурсами.
  2. Если этот текст (как вы говорите жестко) не подвержен частым изменениям, вы можете сохранить эти ресурсы в виде файлов, которые вы читаете во время выполнения.
  3. Если этот текст подвержен частым изменениям, вы можете изучить другие альтернативы хранения ресурсов, такие как базы данных или хранилища значений ключей в памяти.

В зависимости от ваших требований, вы можете рассмотреть сочетание вышеперечисленного.

Но я настоятельно рекомендую вам не смешивать код (сущности символов HTML) с вашими ресурсами перевода. Большинство переводчиков не поймут, что они имеют в виду, и могут сломать их, когда переводят. С другой стороны, программист может не понимать, как правильно вставить код или форматирование в ресурсы перевода, если он на самом деле не понимает этот язык.

tl;dr 
  - use UTF-8
  - don't mix any code/formatting into the translations themselves
  - how you store the translations depends upon your requirements
Источник
  • Вы не хотите хранить весь свой текст как HTML-объекты. Это сведет тебя с ума. Единственная причина сделать это, если вам нужно подать документ в кодировке ASCII и не можете встраивать символы напрямую. Но в наше время нет причин для этого; служите вашему документу как UTF-8 и пишите и храните свое содержимое в UTF-8 и покончите с этим.
  • Хранить переводы в базе данных или нет, зависит от многих факторов, включая производительность, кэширование, необходимость поиска текста, должен ли текст редактироваться непрограммистами и т. Д. Обычно перевод.mo/.po файлы с gettext хороший путь, если не доказано обратное.
Источник
Другие вопросы по тегам