Nous créons des sous-sites multilingues sur notre site web.
Je voudrais utiliser les codes de langue à 2 lettres. L'espagnol et le français sont faciles. Ils auront des URLs comme :
mydomain.com/es
mydomain.com/frmais je rencontre un problème avec le chinois traditionnel et le chinois simplifié. Existe-t-il des normes concernant les codes à deux lettres à utiliser pour ces langues ?
mydomain.com/zh
mydomain.com/?@dkarp donne une excellente réponse générale. J'ajouterai quelques spécificités supplémentaires concernant le chinois :
Il existe plusieurs pays où le chinois est la principale langue écrite. La principale différence entre eux est qu'ils utilisent des caractères simplifiés ou traditionnels, mais il existe également des différences régionales mineures (en termes de vocabulaire, etc.). La manière standard de les distinguer serait d'utiliser un code de pays, par ex. zh_CN pour la Chine continentale, zh_SG pour Singapour, zh_TW pour Taïwan, ou zh_HK pour Hong Kong.
La Chine continentale et Singapour utilisent tous deux des caractères simplifiés, tandis que les autres utilisent des caractères traditionnels. Étant donné que la Chine et Taïwan sont les deux pays les plus peuplés, il n'y a pas de différence entre les deux. zh_CN y zh_TW sont souvent utilisés pour distinguer les versions en caractères simplifiés et traditionnels d'un site web.
Plus techniquement correct mais peu utilisé dans la pratique. Cependant, il faudrait utiliser zh_HANS pour les caractères chinois simplifiés (génériques), et zh_HANT pour les caractères chinois traditionnels, sauf dans de rares cas où il est utile de distinguer différents pays.
C'est une excellente réponse - bien écrite et probablement pas quelque chose que la plupart des gens connaissent. Et elle trace une belle ligne entre ce qui est plus techniquement correct ( zh_HANS ) et ce qui existe réellement en usage général ( zh_CN ). Vous pouvez faire une recherche sur Google pour les deux termes - la différence est d'environ 7 contre 1 en faveur de zh_CN ce qui est honnêtement moins que ce à quoi je m'attendais.
En fait, la différence dans les URLs est aussi importante que je le pensais. inurl:zh_CN donne 4,3 millions de visites ; inurl:zh_HANS donne 20K. Quand même, une réponse très instructive.
La différence entre HANS et HANT est beaucoup moins utile que celle entre CN et TW, car la différence ne porte pas sur les caractères, mais sur l'usage spécifique à la région. Par exemple sous-routine est traduit comme en Chine continentale, mais comme à Taïwan. Dans cet exemple, les caractères sont les mêmes en chinois simplifié et en chinois traditionnel, mais la traduction doit quand même être différente.
Il existe en effet une représentation standard pour cela. Comme les gens ont rencontré exactement le même problème que vous (même langue, mais différents dialectes ou caractères), ils ont étendu le code de langue à deux lettres à un code de région à deux lettres. Ainsi, vous pourriez avoir une page française universelle à mydomain.com/fr mais l'internationalisation pour les lecteurs canadiens-français pourrait vous laisser avec un mydomain.com/fr_CA (Canada) et mydomain.com/fr_FR (France). Certaines plateformes utilisent un tiret au lieu d'un trait de soulignement pour séparer les codes de langue et de région (donc fr-CA y fr-FR ).
La locale standard pour le chinois simplifié est zh_CN . La locale standard pour le chinois traditionnel est zh_TW .
J'hésite à vous diriger vers l'actuel BCP 47 les documents de normes, car ils sont un peu lourds sur le plan des détails et un peu légers sur le plan de la lisibilité. Il suffit d'utiliser des identifiants locaux standard, comme ceux qui sont utilisés par Java et tout ira bien.
Je vais juste laisser ça ici.
CODE
LANG
FORMULAIRE
RÉGION
zh
Chinois
-
-
zh_Hans
Chinois
Han simplifié
-
zh_Hans_CN
Chinois
Han simplifié
Chine
zh_Hans_HK
Chinois
Han simplifié
Hong Kong RAS Chine
zh_Hans_MO
Chinois
Han simplifié
Macao SAR Chine
zh_Hans_SG
Chinois
Han simplifié
Singapour
zh_Hant
Chinois
Han Traditionnel
-
zh_Hant_HK
Chinois
Han Traditionnel
Hong Kong RAS Chine
zh_Hant_MO
Chinois
Han Traditionnel
Macao SAR Chine
zh_Hant_TW
Chinois
Han Traditionnel
Taiwan
La langue dépend de l'endroit où elle est parlée (doh !), les codes de langue et de lieu reflètent donc cette réalité. zh est le code de base du langage, mais parce qu'il en existe deux formes principales, il y a zh_Hans y zh_Hant mais il ne s'agit toujours que de codes de langue, et non de localités.
Site spécifique
Pour spécifier complètement la langue utilisée dans un particulier le code du pays doit toujours être suffixé, ce qui permet de faire zh_Hans_HK y zh_Hant_HK pour le chinois simplifié et le chinois traditionnel, respectivement, tous deux tels que parlés à Hong Kong.
En fait, la réalité est que quelque chose de plus spécifique que le code pays est souvent requis dans de nombreux pays, mais cela risque d'augmenter de façon exponentielle la complexité et la maintenance de bases de données comme la CLDR, sans compter que l'infrastructure de soutien pour l'alimenter, comme l'extraction des détails de l'IP à la localisation, n'est généralement pas disponible ou suffisamment précise.
Texte fixe
Maintenant, si le code sert uniquement à spécifier quel ensemble de chaînes fixes utiliser dans l'interface utilisateur, ou même des ensembles de pages entières sur un site, un suffixe de pays n'est pas vraiment nécessaire, à moins qu'il n'y ait plus de quelques endroits où la langue varie de manière suffisamment significative (informations basées sur l'emplacement) pour prendre la peine de créer un ensemble de ressources séparé.
Plus l'ensemble des ressources est important, plus il est probable qu'un code de langue basé sur la locale (dans ce contexte, il s'agit simplement d'un attribut de langue, plutôt que d'une véritable locale, que vous pouvez appeler comme vous voulez) sera nécessaire, mais au moins vous ne devez le faire que lorsque c'est nécessaire.
Valeurs à la volée
Cependant, si vous souhaitez formater à la volée des valeurs variables particulières, comme les dates, les heures, les devises et les nombres, les paramètres locaux deviennent importants, car tous les outils qui prennent en charge cette fonctionnalité (comme ceux basés sur les données Unicode CLDR) les attendent. La locale pour ces éléments doit être un réglage séparé au code pour lequel un langage d'interface utilisateur généré en interne est paramétré, à moins que vous ne souhaitiez créer un ensemble de ressources pour l'option chaque locale connue, et les maintenir ad nauseum !
Outils de langage du navigateur
Notez que lorsque vous spécifiez la locale d'une page Web qui peut être modifiée, comme dans les zones de saisie, et que la vérification orthographique dans les attributs ou les css a été activée pour le champ, les outils linguistiques du navigateur vérifieront l'orthographe du champ en fonction de cette locale.
Critères
Vous devez être clair sur ce que l'ensemble de ressources fournit, alors réfléchissez :
Feuille de calcul pour minimiser les frais d'entretien
J'utilise une feuille de calcul pour contenir les chaînes de l'interface utilisateur où chaque code de langue a un code parent, de sorte que la cellule pour sa version d'une chaîne a une formule qui obtient sa chaîne du parent. Pour créer une chaîne personnalisée pour cette langue et cette chaîne, je remplace simplement la formule de la cellule par le texte exact. Cela minimise la quantité de ressources à gérer. À la fin, j'exécute une macro qui génère un fichier de ressources complet pour chaque langue.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
2 votes
Vous dites que l'espagnol et le français sont faciles, mais la base de données du CLDR recense respectivement 26 et 47 variantes spécifiques à chaque pays ! Tout dépend simplement de la mesure dans laquelle les ressources que vous fournissez dépendent de ces différences.