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

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

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

mydomain.com/es
mydomain.com/fr

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

mydomain.com/zh
mydomain.com/?
57
chinese-locale cjk internationalization utf-8

3 ответов

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

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

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

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

117

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

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

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

26

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

в определенном месте

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

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

исправлено текст

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

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

"на лету" значения

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

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

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

критерии

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

  • фиксированных строк? Только язык.
  • форматирование "на лету"? Место действия.
  • проверка орфографии в среде просмотра? Место действия.
  • целые страницы / дочерний сайт? Только язык, иначе locale (как вариант языка), если значительно отличается от контента требуемый.

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

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

0