Как правильно локализовать номера?

Какие предостережения я должен знать при локализации чисел в моем приложении?

Пример: в бразильском португальском (pt-BR) мы разделяем тысячи точками и десятичными запятыми. В американском английском (en-US) это наоборот. В pt-BR мы представляем цифры, разделенные тысячами, так же, как en-US. Но читая сегодня об индийском английском (en-IN), я наткнулся на этот драгоценный камень:

Индийская система нумерации является предпочтительной для группировки цифр. Когда они написаны словами или произнесены, числа меньше 100 000/100 000 выражаются так же, как и в стандартном английском. Номера, включая и превышающие 100 000/100 000, выражены в подмножестве индийской системы нумерации.

https://en.wikipedia.org/wiki/Indian_English#Numbering_system

Что значит:

1000000 units in pt-BR are formatted 1.000.000
1000000 units in en-US are formatted 1,000,000
1000000 units in en-IN are formatted 10,00,000

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

Какие еще предостережения следует знать при локализации номеров в моем приложении? Особенно, если я показываю номера для нелатинских наборов символов?

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

Например, экосистема C # имеет пространство имен System.Globalization , которое позволяет вам указать, что Cultureвы хотите:

Console.WriteLine(myMoneyValue.ToString("C", "en-US"));

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

Здесь уже есть несколько отличных ответов, но они не упомянули одну вещь, которую, я думаю, важно не забыть: убедитесь, что где бы ни происходило форматирование чисел, ясно (или можно контролировать), для чего используется вывод:

• когда это для пользовательского интерфейса, должно применяться локализованное форматирование

• когда число будет записано в файл, или отправлено по сети, или в другой форме, где число необходимо в машиночитаемой форме, убедитесь, что оно не отформатировано в соответствии с текущей культурой, но в соответствии с фиксированной настройкой (например, в среде .NET используйте InvariantCulture).

В противном случае вы получите проблемы, когда числа пишутся или отправляются с использованием культуры A, а считываются или принимаются с использованием культуры B.

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

Приложение: эта проблема может стать действительно неприятной в ситуациях, когда заранее неясно, будет ли число обрабатываться машиной или человеком (или обоими) позже. Например, как часть выходного файла журнала. В таких случаях, вероятно, лучше придерживаться «нейтрального» стандарта, заключающегося в отсутствии разделителя, кроме точки в качестве десятичного разделителя.

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

• Не пытайтесь автоматизировать локализацию. Это не всегда работает. Вам трудно определить проблемы и разочарование для ваших пользователей.

• Будьте последовательны: не смешивайте разные языки и соглашения о форматировании, например, десятичные разделители в бразильском стиле в английском тексте.

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

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

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

Возьмите типичный ярлык типа «Вы выбрали n предметов». Это читается неправильно, если выбран только один элемент. Уродливое, но прагматичное решение - написать «Вы выбрали n элементов». Но если вы хотите сделать это правильно, вам нужно два разных текста в зависимости от n. Если вы попытаетесь сделать это в нескольких локалях, это быстро станет действительно сложным, поскольку разные языки имеют разную грамматику. Некоторые языки имеют разные спряжения для одного, двух и нескольких предметов и так далее. По этой причине знающие люди всегда будут жаловаться на то, что существующие рамки локализации недостаточны.

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

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

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

http://site.icu-project.org

http://cldr.unicode.org

Обновить

Инструмент опроса CLDR предоставляет доступ ко всем шаблонам. Это покажет вам, как форматировать число на определенном языке и регионе. Например, португальский (Португалия):

http://st.unicode.org/cldr-apps/v#/pt_PT/Number_Formatting_Patterns/

И если вы действительно хотите проверить все данные (и, возможно, использовать их), вы можете загрузить CLDR в формате JSON с GitHub:

https://github.com/unicode-cldr/cldr-json#cldr-json

Более подробная информация о загрузках здесь:

http://cldr.unicode.org/index/downloads

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

Пока это то, что мы должны знать при локализации номеров:

Для людей :

• Разделители тысяч не всегда разделяются тысячами. См. Индийский случай в вопросе;
• Тысячи и десятичные знаки изменяют культуру к культуре. Например, в немецком языке тысячи разделяются пробелами, а в английском это комманы, а в португальском - точки;
• У нас нет информации, если есть существенная разница между языками слева направо и справа налево;
• Предоставьте конкретный набор поддерживаемых локализаций и сделайте его понятным для ваших пользователей;
• Позвольте вашим пользователям изменить локализацию по умолчанию на одну из поддерживаемых локализаций, и они будут счастливы и отправят вам благодарные пирожные, потому что вы великодушный бог. :);

Для компьютеров :

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

Для разработчиков :

• (как предложено @hyde ниже): использовать существующую библиотеку для локализации;
• Если вы можете, используйте встроенные тестеры и укажите тестовые примеры локализации / интернационализации, в противном случае доверяйте библиотеке;
• Помните, что локализация - это проблема, в основном решаемая. У каждого основного языка есть библиотека, родная или внешняя, которая может локализовать числа, даты и время;