Я сомневаюсь, что экстернализация строк будет вашей самой большой проблемой. Но позвольте дать вам совет.
Экстернализация строк
Конечно, вам нужно будет отделить переводимые строки от кода. Я бы рекомендовал хранить перевод в виде простого текста, файла в кодировке 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), либо подготовить многоязычную структуру ресурсов (т.е. поместить все изображения в каталоги, названные в соответствии с кодом языка (" ан", "я", "ко")).
Настоящей проблемой, однако, являются жестко запрограммированные теги форматирования, такие как <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. Это было бы очень сложно...
14.05.2011
