Рекомендации по интернационализации веб-приложений?

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

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

Ответ 1

Интернационализация трудна, вот несколько вещей, которые я узнал из работы с двумя веб-сайтами, которые были на более чем 20 разных языках:

Используйте UTF-8 везде. Без исключений. HTML, серверный язык (особенно обратите внимание на PHP), базу данных и т.д.
Нет изображений на изображениях, если вы не хотите работать с тобой. Используйте CSS, чтобы поместить текст поверх изображений, если это необходимо.
Отдельная конфигурация от локализации. Таким образом, локализаторы могут переводить текст, и вы можете иметь дело с различными конфигурациями для каждого языка (функции, макет и т.д.). Вы не хотите, чтобы локализаторы имели возможность взаимодействовать с вашим приложением.
Убедитесь, что ваши макеты могут иметь дело с текстом, который в 2-3 раза длиннее английского. А также на 50% меньше, чем английский (японцы и китайцы часто короче).
Некоторые языки требуют больших размеров шрифта (японский, китайский)
Цвета также зависят от локали. Красный и зеленый не означает то же самое везде!
Добавить имя класса, являющееся именем локали, в тег тела ваших документов. Таким образом, вы можете легко указать конкретный макет локали в своем файле CSS.
Следите за заменой переменных. Не разделяйте строки. Оставьте их целыми как это: "У вас есть X новых сообщений" и замените "X" на #.
Различные языки имеют различную плюрализацию. 0, 1, 2-4, 5-7, 7-бесконечность. Трудно иметь дело.
Контекст сложный. Иногда локализаторы должны знать, где/как используется строка, чтобы правильно ее перевести.

Ресурсы

Ответ 2

В моей компании все наши строки хранятся в файлах *.properties. Наши инструменты сборки создают копию тестовых имен файлов свойств, которые заменяют строку следующим образом:

Click here

с чем-то вроде этого:

[~~ Çļïčк н∑ѓё ~~ ﾀｳ ~~]

Теперь, когда мы устанавливаем язык для "теста" в наших файлах конфигурации, эти файлы свойств используются. (И, конечно же, мы не отправляем файлы тестовых языков).

Это позволяет нам:

Убедитесь, что символы Unicode отображаются правильно, включая японский/китайский/корейский.
Убедитесь, что макет правильно рассчитан для языков с более длинными словами (в немецком языке, в частности, есть более длинные слова в среднем, чем английский).
Поместите любые жестко закодированные строки (так как они будут на английском языке).

Что касается фактического перевода, то это делают профессиональные переводчики, а не разработчики.

Ответ 3

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

Мои советы:

подумайте о том, как вы показываете международную версию страницы
Использование геолокации может работать для многих пользователей, но, как показывают мои примеры, многие не будут
почему бы не использовать заголовок Accept-Language для определения того, какой язык будет обслуживать
если пользователь обращается к странице через поисковую систему, то не перенаправляет их где-то еще, например. на домашнюю страницу на другом языке.
Это крайне раздражает изменение языка и перезагрузка другой страницы - либо обслуживать одну страницу, либо предупреждать пользователя о том, что текущий контент недоступен на другом языке, прежде чем перенаправить их.
Английский язык является очень распространенным, поэтому, возможно, по умолчанию это
Но убедитесь, что опция изменения языка понятна в графическом интерфейсе (мне нравится, что делают Карты Google, как показано в сообщении).

Все, что я вижу в Интернете, - это компании, которые неправильно внедряют интернализацию. Как правильно это понимать с точки зрения пользователя, действительно сложно.

Ответ 4

У меня есть несколько приложений, которые являются "двуязычными", Я использовал файлы ресурсов в ASP.NET1.1

Существует также что-то, называемое инструментом String Resource Tool В основном вы помещаете все свои строки в файл .RES для обоих языков, а затем определяете, какой файл следует читать на основе культуры, или кто-то щелкнул ссылку для языка

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