Рекомендации по интернационализации веб-приложений?
Интернационализация веб-приложений всегда кажется сложной задачей. Независимо от того, сколько вы планируете заранее для подключаемых языков, всегда возникают проблемы с кодировкой, фанкой-фразировкой, которая не соответствует вашим шаблонам и другим проблемам.
Я думаю, было бы полезно получить вкладку 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 для обоих языков, а затем определяете, какой файл следует читать на основе культуры, или кто-то щелкнул ссылку для языка
Самый большой результат - убедиться, что переводы выполнены правильно.