Коды языков для упрощенного китайского и традиционного китайского?

79

На нашем сайте мы создаем многоязычные дочерние сайты.

Я хочу использовать двухбуквенные коды языков. Испанский и французский - это легко. Они получат такие URL-адреса:

mydomain.com/es
mydomain.com/fr

но я столкнулся с проблемой с традиционным и упрощенным китайским языком. Существуют ли стандарты для использования двухбуквенных кодов этих языков?

mydomain.com/zh
mydomain.com/?
Джеф Перро
источник
2
Вы говорите, что испанский и французский - это просто, но в базе данных CLDR перечислены 26 и 47 вариантов для каждой страны соответственно! Это просто зависит от того, насколько ресурсы, которые вы предоставляете, зависят от различий.
Патанджали

Ответы:

174

@dkarp дает отличный общий ответ. Я добавлю некоторые дополнительные особенности китайского языка:

Есть несколько стран, где китайский язык является основным письменным языком. Основное различие между ними заключается в том, используют ли они упрощенные или традиционные символы, но есть также незначительные региональные различия (в словарном запасе и т. Д.). Стандартный способ отличить их - использовать код страны, например, zh_CNдля материкового Китая, zh_SGдля Сингапура, zh_TWдля Тайваня или zh_HKдля Гонконга.

Материковый Китай и Сингапур используют упрощенные символы, а остальные используют традиционные символы. Поскольку Китай и Тайвань являются двумя странами с наибольшим населением, просто zh_CNи zh_TWчасто используются для различения упрощенных и традиционных символьных версий веб-сайтов.

Однако более технически правильным, но не часто используемым на практике , было бы использование zh_HANSдля (общих) упрощенных китайских иероглифов и zh_HANTдля традиционных китайских иероглифов, за исключением редких случаев, когда имеет смысл различать разные страны.

Тодд Оуэн
источник
11
Это отличный ответ - хорошо написанный и, вероятно, не то, о чем большинство людей знает. И он проводит красивую грань между тем, что более технически правильным ( zh_HANS), и тем, что на самом деле существует в общем использовании ( zh_CN). Вы можете выполнить поиск в Google по двум терминам - разница примерно 7 к 1 в пользу zh_CN, что, честно говоря, меньше, чем я ожидал.
dkarp
11
На самом деле разница в URL-адресах настолько велика, как я ожидал. inurl:zh_CNдает 4,3 млн просмотров; inurl:zh_HANSдает 20К. Тем не менее, действительно информативный ответ.
dkarp 04
2
Разница между HANS и HANT гораздо менее полезна, чем CN и TW, поскольку разница больше, чем в символах, но зависит от региона. Например, подпрограмма переводится как 子程序 в материковом Китае и как 子 程式 на Тайване. В этом примере символы на упрощенном и традиционном китайском совпадают, но перевод все равно должен быть другим.
Yongwei Wu 08
34

Для этого действительно существует стандартное представление. Поскольку люди сталкиваются с той же проблемой, с которой вы сталкиваетесь, - на том же языке, но с разными диалектами или символами, - они расширили двухбуквенный код языка на двухбуквенный код региона. Таким образом, у вас может быть универсальная французская страница по адресу mydomain.com/fr, но интернационализация для франко-канадских читателей может оставить вас с mydomain.com/fr_CA(Канада) и mydomain.com/fr_FR(Франция). Некоторые платформы используют тире вместо подчеркивания для разделения кода языка и региона (отсюда fr-CAи fr-FR).

Стандартный языковой стандарт для упрощенного китайского - zh_CN. Стандартный язык для традиционного китайского - zh_TW.

Я не решаюсь указать вам на настоящие документы стандартов BCP 47 , так как они, ммм, немного тяжелы по деталям и немного светят для удобочитаемости. Просто используйте стандартные идентификаторы локали, подобные тем, которые используются в Java , и все будет в порядке.

Дкарп
источник
2

Язык зависит от того, где на нем говорят (угу!), Поэтому коды языка и локали отражают эту реальность. zh- это базовый языковой код, но, поскольку существует две его основных формы, есть zh_Hansи zh_Hant, но они по-прежнему являются только языковыми кодами, а не локали.

Зависит от местоположения

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

На самом деле, реальность такова, что во многих странах часто требуется что-то более конкретное, чем код страны, но это, вероятно, в геометрической прогрессии увеличит сложность и обслуживание баз данных, таких как CLDR, а также инфраструктуры поддержки для ввода в него, например, извлечения IP для извлечения деталей , не является общедоступным или недостаточно точным.

Фиксированный текст

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

Чем больше набор ресурсов, тем более вероятно, что потребуется языковой код, основанный на локали [в данном контексте, просто атрибут языка, а не истинный языковой стандарт, поэтому вы можете называть его как хотите!], Но, по крайней мере, вы делать это нужно только при необходимости.

Ценности на лету

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

Инструменты языка браузера

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

Критерии

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

  • Фиксированные струны? Только язык.
  • Форматирование на лету? Локаль.
  • Проверка орфографии в среде просмотра? Локаль.
  • Целые страницы / дочерний сайт? Только язык, в противном случае - локаль (как вариант языка), если требуется существенно другое содержание.

Таблица для минимизации накладных расходов на обслуживание

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

Патанджали
источник
Я думаю, что если ваш язык программирования (например, Java) или среда сопоставления языков могут поддерживать формат типа zh-hans_CN, тогда сделайте это. Если это не так, то наличие Country подразумевает «сценарий», например, предполагается, что Hans для zh_CN, zh_SG, а Hant - для zh_TW, zh_HK. Так что часть сценария можно оставить. Если ваша система вообще не поддерживает сопоставление стран, например en / fr / de / es для большинства языков .... тогда она может иметь формат типа zh_hans / zh_hant, по крайней мере, для определенных языков (например, Drupal в основном Таким образом, я разрешаю своим мобильным приложениям отправлять эту информацию, чтобы она соответствовала моему API Drupal CMS)
armyofda12mnkeys