Лучшие практики для интернационализации веб-приложений?

Question

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

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

Answer 1

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

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

Ресурсы:

• http://interglacial.com/~sburke/tpj/as_html/tpj13.html
• http://www.ryandoherty.net/2008/05/26/quick-tips-for-localizing-web-apps/
• http://ed.agadak.net/2007/12/one-potato-two-potato-three-potato-four

Answer 2

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

Click here

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

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

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

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

1. Убедитесь, что символы Юникода отображаются правильно, включая японский / китайский / корейский.
2. Убедитесь, что компоновка масштабируется соответствующим образом для языков с более длинными словами (в частности, в немецком языке в среднем более длинные слова, чем в английском).
3. Найдите все жестко закодированные строки (как они будут на простом английском языке).

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

Answer 3

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

Мои советы будут:

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

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

Answer 4

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

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

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