Лучшие практики для написания программного обеспечения для международного потребления (i18n)

Question

Я ищу мнения экспертов, которые написали программное обеспечение, используемое на международном уровне. Я хотел бы понять лучшие практики, которые люди применяли на каждом уровне логического смягчения (Data (rdbms), Business (middleware), User Interface).

Спасибо за любую помощь, которую вы можете оказать.

Answer 1

Данные

• Когда вы переходите к UTF-8, будьте готовы к тому, что символы будут занимать до 3 байтов каждый (в случае китайского языка), что означает, что VARCHAR (20) теперь должен быть VARCHAR (60).
• Если у вас действительно нет веских причин для этого, ради бога, не храните ваши переводы пользовательского интерфейса в БД.

Бизнес

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

UI

Не

string foo = "Page " + currentPage + " of " + totalPages;

У

string foo = string.Format("Page {0} of {1}", currentPage, totalPages);

Почему? Порядок слов имеет значение.

<value>Page {0} of {1}</value>
 <value>{1}ページ中の第{0}ページ</value>

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

Answer 2

Убедитесь, что в элементах управления пользовательского интерфейса достаточно свободного места. Текст имеет тенденцию становиться намного длиннее при переводе с английского на что-то вроде французского или немецкого.

Хотя он в какой-то степени ориентирован на Windows i18n, обратите внимание на блог Майкла Каплана . Он очень хорошо разбирается в этой области и опубликовал множество постов в блогах, содержащих полезные материалы.

Answer 3

Вы можете написать книгу на эту тему.

На всех слоях не делайте предположений относительно:

• ширина текста
• направленность текста
• токенизация естественного языка
• валюта (формат, десятичная точность, налогообложение и т. Д.)
• грамматика и орфография
• алфавитов
• Системы счисления и форматирования
• порядок сортировки
• даты, время, часовые пояса и календари
• социальные соглашения или культурные ссылки (значки, флаги и т. Д.)
• поиск
• капитализация
• адрес
• собственные имена (имя / фамилия и т. Д.)
• номера телефонов
• законодательные / нормативные требования
• использование номеров социального страхования или других местных соглашений

Я уверен, что только царапаю поверхность.

Answer 4

Для локализации не жестко кодируйте строки пользовательского интерфейса. Используйте что-то вроде gettext.

Answer 5

Юникод (или wchar, или любой другой его эквивалент в <языке выбора>) везде. Не храните этикетки в базе данных. Будьте готовы позволить тексту и элементам управления идти «неправильным путем», то есть справа налево.

Answer 6

Если вы используете .Net, система файлов ресурсов (.resx) очень гибкая.

Найдите использование ResourceManager.GetString ("имя строки", CultureInfo).

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

Также, рассматривая использование в других локалях, потратьте некоторое время на анализ входных и выходных данных; Турецкая проблема является хорошим примером того, как разные входы могут вызвать проблемы.