Лучшие практики для написания программного обеспечения для международного потребления (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).

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

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