Я сомневаюсь, что экстернализация строк будет вашей самой большой проблемой.Но позвольте мне дать вам несколько советов.
Экстернализация строки
Конечно, вам нужно отделить переводимые строки от кода.Я бы порекомендовал хранить перевод в виде обычного текста, файла в кодировке UTF-8, содержащего пары ключ-значение:
some.key=some translation
Конечно, вам потребуется написать вспомогательный скрипт для решения этой проблемы во время выполнения.Скрипт должен был бы определять язык конечного пользователя.
Определение языка
Веб-браузеры настолько хороши, что отправляют заголовок AcceptLanguage каждый раз, когда отправляют запрос.Что вам нужно сделать, это прочитать содержимое этого заголовка и проверить, поддерживаете ли вы какой-либо из языков, перечисленных пользователем.Если это так, прочитайте файл ресурса (как определено выше) и верните строки для данного языка, в противном случае верните язык по умолчанию.Приведенный ниже пример кода даст вам наиболее желаемый язык (который не обязательно тот, который вы поддерживаете):
<?php
$locale = Locale::acceptFromHttp($_SERVER['HTTP_ACCEPT_LANGUAGE']);
echo $locale;
?>
Это все еще не самая большая из ваших проблем.
Стили и таблицы стилей
Настоящая проблема с многоязычными веб-сайтами или веб-приложениями заключается в стилях.Люди склонны вставлять определения стиля в линию, что, по меньшей мере, проблематично.Кроме того, дизайнеры склонны считать, что Arial - лучший шрифт для всей вселенной, так как выделение всегда должно идти с жирным шрифтом .Единственная проблема в том, что шрифт может быть нечитаемым при некоторых обстоятельствах.
Должен признать, я не знаю, почему это происходит, но в большинстве случаев веб-браузеры склонны игнорировать атрибут bold для азиатских сценариев (что хорошо), но иногда они не , и это может стать серьезной проблемой для конечных пользователей, если ваше определение шрифта скажет 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. Это было бы очень сложно ...