Если у вас есть приложение, локализованное в pt-br и pt-pt, какой язык вы должны выбрать, если система сообщает только код "pt"?

Если у вас есть приложение, локализованное в pt-br и pt-pt, какой язык вы должны выбрать, если система сообщает только код pt (общий португальский)?

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

Вопрос применим также к большему числу случаев, включая:

Q1: Как определить преобладающие языки для заданного метаязыка?

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

Q2: если система сообщила об упрощенном китайском (PRC) (zh-cn) в качестве предпочтительного языка пользователя, и у меня есть перевод только для английского и традиционного китайского языка (en,zh-tw) что я должен выбрать из двух вариантов: en или zh-tw?

Ответы

Ответ 1

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

Угадать недостающие части

Это все сложные области и даже (потенциально) политически заряженные.

Но за очень немногими исключениями правило заключается в выборе "исходной страны" языка. Исключения в основном основаны на численности населения. Таким образом, fr-FR для fr, es-ES и т.д. Некоторые исключения: pt-BR вместо pt-PT, en-US вместо en-GB.

Также принято (и требуется по китайским стандартам), что zh сопоставляется с zh-CN.

Возможно, вам также придется посмотреть на страну, чтобы определить script, или наоборот. Например, az = > az-AZ, но az-Arab = > az-Arab-IR, az_IR = > az_Arab_IR

Соответствие 'want' vs. 'have'

Это включает в себя сопоставление списка желаний и списка языков. Работа со списками затрудняет работу. И результат также должен быть отсортирован разумным способом, если это возможно. (например, если want = [ fr ro ] и have = [ en fr_CA fr_FR ro_RO ], то вы, вероятно, захотите [ fr_FR fr_CA ro_RO ] в качестве результата.

Не должно быть соответствия между языком с разными скриптами. Поэтому zh-TW не должен отступать к zh-CN, а mn-Mong не должен отступать от mn-Cyrl. Трудные области: sr-Cyrl не должен отвлекаться на sr-Latn в теории, но это может быть понято пользователями. ro-Cyrl может вернуться к ro-Latn, но не наоборот.

Некоторые ссылки

RFC 4647 имеет дело с отступлением языка (но в этом случае он не очень полезен, поскольку он следует правилу "вырезать справа" ).
ICU 4.2 и более новый (проект в 4.0, я думаю) имеет uloc_addLikelySubtags (и uloc_minimizeSubtags) в uloc.h. Это реализует http://www.unicode.org/reports/tr35/#Likely_Subtags
Также в ICU uloc.h есть uloc_acceptLanguageFromHTTP и uloc_acceptLanguage, которые имеют дело с want vs have. Но они бесполезны, поскольку они принимают UEnumeration * в качестве входных данных, и нет никакого открытого API для создания UEnumeration.
Существует некоторая работа по согласованию языков, выходящей за рамки простого RFC 4647. См. http://cldr.unicode.org/development/design-proposals/languagedistance
Согласование локалей в ActionScript на http://code.google.com/p/as3localelib/
API-интерфейсы в новом пространстве имен Flash Player 10.1 flash.globalization выполняют как угадывание тегов, так и соответствие языков (http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/flash/globalization/package-detail.html). Он работает на TR-35 и может смотреть за пределы @и рассматривать операцию. Например, если have = [ ja [email protected]=radical [email protected]=japanese ] и want = [ [email protected]=japanese;collation=radical ], то наилучшее соответствие зависит от требуемой операции. Для форматирования даты ja @calendar = japanese - лучшее совпадение, но для сортировки вы хотите ja @collation = радикальный

Ответ 2

Ожидаете ли вы большего числа пользователей в Португалии или Бразилии? Выберите соответственно.

Для вашего общего решения вы узнаете, прочитав Ethnologue.