Интернационализация в ваших проектах

Это было уже давно, так что это не является исчерпывающим.

набор символов

Unicode-это здорово, но вы не можете уйти, игнорируя другие наборы символов. Набор символов по умолчанию для Windows XP (английский) - Cp1252. В интернете вы не знаете, что браузер отправит вам (хотя, надеюсь, ваш контейнер будет обрабатывать большую часть этого). И не удивляйтесь, если обнаружите ошибки в любой используемой вами реализации. Наборы символов могут иметь интересные взаимодействия с именами файлов, когда они перемещаются между машинами.

переведенная строка

Переводчики-это, вообще говоря, не кодеры. Если вы отправите исходный файл переводчику, он его сломает. Строки должны быть извлечены в файлы ресурсов (например, файлы свойств в Java или resource DLLs в Visual C++). Переводчикам должны быть предоставлены файлы, которые трудно взломать, и инструменты, которые не позволяют им их сломать.

Переводчики не знают, откуда берутся строки в продукте. Трудно перевести строку без контекста. Если вы не дадите указания, качество перевода пострадает.

Если говорить о контексте, то вы можете увидеть, что одна и та же строка "foo" появляется несколько раз, и думаете, что было бы более эффективно, если бы все экземпляры в UI указывали на один и тот же ресурс. Это плохая идея. В некоторых языках слова могут быть очень чувствительны к контексту.

Перевод строк стоит денег. Если вы выпускаете новую версию продукта, имеет смысл восстановить старые версии. Есть инструменты для восстановления строк из старых файлов ресурсов.

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

Переводчики должны иметь возможность изменять горячие клавиши. Ctrl + P -это печать на английском языке; немцы используют Ctrl + D .

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

Даты, Время, Календари, Валюта, Форматы Чисел, Часовые Пояса

Все они могут варьироваться от страны к стране. Запятая может использоваться для обозначения десятичных знаков. Время может быть в 24-часовой записи. Не все пользуются Григорианским календарем. Вы тоже должны быть недвусмысленны. Если вы заботитесь о том, чтобы отображать даты как MM/DD/YYYY для USA и DD/MM/YYYY для UK на вашем веб-сайте, даты будут неоднозначными, если пользователь не знает, что вы это сделали.

Особенно Валюта

Функции Locale, представленные в библиотеках классов, дадут вам символ местной валюты, но вы не можете просто вставить символ фунта (фунта стерлингов) или евро перед значением, которое дает цену в долларах.

пользовательский интерфейс

Макет должен быть динамичным. Мало того, что строки, вероятно, удвоятся в длину при переводе, весь UI может потребоваться перевернуть (иврит; арабский), чтобы элементы управления работали справа налево. И это до того, как мы доберемся до Азии.

Тестирование Перед Переводом

• Используйте статический анализ кода для поиска проблем. Как минимум, используйте инструменты, встроенные в ваш IDE. (Пользователи Eclipse могут перейти в окно > настройки > Java > компилятор > ошибки / предупреждения и проверить наличие неэкстранализированных строк.)
• Испытание дымом путем моделирования перевода. Нетрудно разобрать файл ресурсов и заменить строки псевдопереводимой версией, которая удваивает длину и вставляет фанковые символы. Вам не нужно говорить на иностранном языке, чтобы использовать иностранную операционную систему. Современные системы должны позволить вам войти в систему как иностранному пользователю с переведенными строками и иностранными locale. Если вы знакомы с вашим OS, вы можете понять, что делает то, что не зная ни одного слова языка.
• Карты клавиатуры и ссылки на набор символов очень полезны.
• Виртуализация была бы здесь очень полезна.

Нетехнические вопросы

Иногда вы должны быть чувствительны к культурным различиям (это может привести к оскорблению или непониманию). Ошибка, которую вы часто видите, - это использование флагов в качестве визуального сигнала при выборе языка или географии веб-сайта. Если вы не хотите, чтобы ваше программное обеспечение объявляло стороны в глобальной политике, это плохая идея. Если бы Вы были французом и предложили вариант для английского языка с флагом Святого Георгия (флаг Англии - Красный крест на белом поле), это может привести к путанице для многих носителей английского языка-предположим, что аналогичные проблемы возникнут с иностранными языками и странами. Иконы должны быть проверены на предмет их культурной значимости. Что означает большой палец вверх или зеленая галочка? Язык должен быть относительно нейтральным - обращение к пользователям определенным образом может быть приемлемым в одном регионе, но считаться грубым в другом.

Ресурсы

C++ и Java программисты могут найти полезным сайт ICU: http://www.icu-project.org/

Некоторые забавные вещи:

1. Имея приложение PHP и MySQL, которое хорошо работает с немецким и французским языками, но теперь нуждается в поддержке русского и китайского языков. Я думаю, что я перенесу это на .net, так как поддержка PHP Unicode, по моему мнению, не очень хороша. Конечно, жонглирование с utf8_de / encode или mbstring-функциями-это весело. Почти так же весело, как если бы Фредди Крюгер приходил к тебе ночью...

2. Понимая, что некоторые языки являются LOT более многословными, чем другие. Немецкий язык является LOT более подробным, чем обычно английский, и видеть, как немецкая версия разрушает пользовательский интерфейс, потому что слишком мало места было выделено, было не весело. Некоторые продукты получили некоторую известность за их творческие способы обойти это, с Oblivion's " Schw.Tr.d.Le.En.W."быть запоминающимся :-)

3. Играешь с форматами дат, уууу! Да, на самом деле в мире есть люди, которые используют форматы дат, когда день проходит в середине. Оооочень весело пытаться выяснить, что же такое 07/02/2008 должно означать, просто потому, что некоторые пользователи могут поверить, что это может быть 2 июля... Но опять же, вы, ребята из пруда, можете верить в то же самое о пользователях, которые ставят месяц в середине :-P, особенно потому, что в английском языке 2 июля звучит намного лучше, чем 2 июля, что не обязательно относится к другим языкам (т. е. в немецком вы никогда не скажете Juli 2, но всегда Zweiter Juli). Я использую 2008-02-07, когда это возможно. Понятно, что это означает 7 февраля, и он сортирует правильно, но dd/mm против mm/dd может быть действительно сложной проблемой.

4. Еще одна забавная штука, числовые форматы ! 10.000,50 против 10,000.50 и 10 000,50 и 10'000,50... Это мой самый большой кошмар прямо сейчас, когда мне приходится поддерживать мультикультурную среду, но не иметь никакого способа достоверно знать, какой формат чисел будет использовать пользователь.

5. Официально или неофициально. В некоторых языках существует два способа обращения к людям: формальный и более неформальный. В английском языке вы просто говорите "You", но в немецком вам нужно выбрать между формальным "Sie" и неформальным "Du", то же самое для французского Tu/Vous. обычно безопасно выбрать формальный путь, но это легко упускается из виду.

6. Календари. В Европе первый день недели-понедельник, тогда как в США-это воскресенье. Виджеты календаря хороши. Показывать Европейскому пользователю календарь с воскресеньем слева и субботой справа не очень приятно, это их смущает.

Я работал над проектом для моего предыдущего работодателя, который использовал .NET, и там был встроенный формат .resx, который мы использовали. У нас в основном был файл, который имел все переводы в файле .resx, а затем несколько файлов с разными переводами. Следствием этого является то, что вы должны очень тщательно следить за тем, чтобы все строки, видимые в приложении, хранились в .resx, и каждый раз, когда один из них изменяется, вы должны обновить все языки, которые вы поддерживаете.

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

Еще одна заметка, очень строго избегайте прямого сцепления видимых строк, таких как

String message = "The " + item + " is on sale!";

Вместо этого вы должны использовать что-то вроде

String message = String.Format("The {0} is on sale!", item);

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

Сегодня утром я как раз слушал подкаст от Скотта Ханселмана , где он говорит об интернационализации, особенно о действительно сложных вещах, таких как Turkish (с четырьмя i) и тайский язык. Кроме того, у Джеффа Этвуда была должность :

Помимо всех предыдущих советов, Помните, что i18n-это не просто изменение слов для их эквивалента на других языках, особенно для нелатинских языков алфавитов (корейский, арабский), которые пишутся справа налево, поэтому весь UI должен будет соответствовать, например

• пункт 1
• пункт 2
• пункт 3

должен был бы быть

арабский текст 1 -

арабский текст 2 -

арабский текст 3 -

(обратный список пуль, похоже, не работает :P)

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

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

Одна из самых забавных вещей, чтобы обнаружить: курсив и полужирный текст makrup не работает с символами CJK (Chinese/Japanese/Korean). Они просто становятся нечитаемыми. (OK, я тоже не мог их прочитать раньше, но особенно жирный шрифт просто создает чернильные кляксы)

Я думаю, что все, кто работает в области интернационализации, должны быть знакомы с общим хранилищем данных Locale, которое сейчас является подпроектом Unicode:

Общий Репозиторий Данных Locale

Эти люди упорно трудятся, чтобы создать стандартный ресурс для всех видов вопросов i18n: валюта, географические названия, тонны вещей. Любой проект, который поддерживает свои собственные основные локальные данные, учитывая, что этот проект существует, является довольно сумасшедшим, IMHO.

Я предлагаю использовать что-то вроде 99translations.com для поддержания ваших переводов . В противном случае вы не сможете сказать, какие из ваших переводов актуальны на каждом языке.

Еще одной проблемой будет принятие входных данных от ваших пользователей. Во многих случаях это облегчается обработкой входных данных, предоставляемой операционной системой, такой как IME в Windows, которая работает прозрачно с обычными текстовыми виджетами, но эта возможность не будет доступна для всех возможных потребностей.

Один сайт, который я использую, имеет метод перевода, который владелец называет "wiki + machine translation". Это сайт, основанный на сообществе, поэтому он явно отличается от потребностей компаний.

http://blog.bookmooch.com/2007/09/23/how-bookmooch-does-its-translations/

Одна вещь, о которой еще никто не упоминал, - это строки с некоторой предупреждающей частью, как в "The unit will arive in 5 days" или "On Monday something happens.", где 5 и понедельник будут меняться в зависимости от состояния. Это не очень хорошая идея, чтобы разделить их на две части и объединить их. При наличии только одной изменяющейся части и хорошей документации вам это может сойти с рук, а при наличии двух изменяющихся частей появится некий язык, который предпочтет изменить их порядок.