1. I18N et L10N dans AngularJS
1. Que sont i18n et l10n?
L'internationalisation, appelée I18N, est une norme pour le développement de produits d'une manière qu'ils peuvent simplement localiser la langue et la culture du produit. La localisation, appelée L10N, est une norme qui permet aux applications et aux textes de s'adapter à des marchés culturels ou linguistiques spéciaux. Pour les développeurs d'applications, l'internationalisation d'un programme signifie que toutes les chaînes et autres domaines doivent être extraites du programme où ils sont plus spéciaux (tels que les formats de date et de devise). La localisation d'un programme signifie fournir une traduction et une localisation de format de blocs extraits de i18n.
2. Quels niveaux de I18N et L10n sont actuellement pris en charge par Angular?
Actuellement, Angular fournit une prise en charge I18N et L10N pour les filtres DateTime, Number et Currency.
De plus, Angular soutient la localisation diversifiée par le biais de la directive Ngpluralize (http://docs.angularjs.org/api/ng.directive:ngpluralize).
Tous les contrôles localisables reposent sur l'ensemble de règles de fonctionnement de paramètre paramètres gérés via le service des paramètres régionaux.
Pour permettre aux lecteurs de voir des exemples réels, le responsable a préparé quelques exemples de pages Web pour montrer comment utiliser les filtres angulaires pour collecter des variables via les règles régionales. Nous pouvons trouver des exemples correspondants dans github (https://github.com/angular/angular.js/tree/master/i18n/e2e) ou en i18n / e2e dans le package de développement angulaire.
3. Qu'est-ce qu'un identifiant régional?
Le lieu est une région géographique, politique et culturelle spécifique. L'ID des paramètres régionaux le plus couramment utilisé se compose de deux parties: le code linguistique et le code de pays. Par exemple, EN-US, EN-AU et ZH-CN sont tous des ID locaux valides, tous contenant des codes linguistiques et des codes de pays. Étant donné que le codage du pays spécifié dans l'ID local est facultatif, les ID locaux tels que EN, ZH et SK sont tous valides. Consultez le site Web ICU (http://userguide.icu-project.org/locale), où il y a plus d'informations sur l'ID des paramètres régionaux.
4. LOCALES ANGULAIRES
Angular sépare l'ensemble des règles pour les nombres, les formats de date et d'heure dans différents fichiers, chaque fichier a une zone unique. Nous pouvons trouver la liste des paramètres locaux actuellement pris en charge ici (https://github.com/angular/angular.js/tree/master/i18n/locale)
2. Personnaliser les règles des paramètres régionaux en angulaire
Il existe deux façons de personnaliser les paramètres régionaux en Angular:
1. Ensembles de règles préalables
Nous pouvons implémenter le fichier local attendu en connectant le fichier spécifique aux paramètres régionaux à angular.js ou angular.min.js.
Par exemple, dans * Nix, nous pouvons créer un fichier angular.js contenant les règles de localisation régionale allemandes via la commande suivante:
chat angular.js i18n / angular-locale_de-ge.js> angular_de-ge.js
Lorsque l'application utilise le script Angular_de-ge.js au lieu du script général Angular.js, Angular commence automatiquement les règles de localisation préconfigurées (préconfigurées) en Allemagne.
2. Inclure la page du script JS JS à index.html
Nous pouvons également inclure des fichiers JS dans la zone spécifiée dans la page. Par exemple, si un client a besoin d'un fichier régional allemand, nous pouvons fournir une page comme ce qui suit:
<html ng -pp> <adref> ... <script src = "angular.js"> </ script> <script src = "i18n / angular-locale_de-ge.js"> </ script> ... </ head> ... </ html>
Les deux méthodes ci-dessus nous obligent à fournir différentes pages index.html ou fichiers JS dans chaque région pour la localisation. Nous devons également configurer notre serveur pour fournir les fichiers régionaux corrects et souhaités.
Cependant, la deuxième méthode (y compris les fichiers locaux dans la page) sera plus lente car un script supplémentaire est nécessaire pour charger. (-_- !!!).
3. Trap ("Gotchas")
1. Pièche de symboles de la devise
Le filtre de devise d'Angular nous permet d'utiliser le symbole de devise par défaut à partir du service régional, et nous pouvons également fournir des symboles de devise personnalisés. Si notre application n'est utilisée que dans un domaine, nous pouvons compter sur (définir) le symbole de devise par défaut. Cependant, si nous nous attendons à ce que les utilisateurs d'autres régions utilisent également notre application, nous devons fournir nos symboles de devise personnalisés pour garantir que l'utilisateur comprend la valeur réelle.
Par exemple, si nous voulons lier le filtre de devise pour afficher le solde du compte de RMB 1 000: {{1 000 | devise}}, et notre application utilise actuellement les paramètres régionaux en-américains, alors "1 000,00 $" sera affiché. Cependant, si les utilisateurs de certaines autres régions (tels que la Chine continentale) visitent notre application, le navigateur de l'utilisateur spécifiera le réglage de la région sur "Chine continentale", et le solde sera affiché comme "￥ 1000.00" (un taux de change très triste, ...).
Dans cet exemple, lorsque nous devons définir le filtre, nous devons réécrire le symbole de devise par défaut en fournissant des symboles de devise en tant que paramètres sur le filtre de devise (http://docs.angularjs.org/api/ng.filter: incurrence), le paramètre tel que: usd $. De cette façon, Angular ignorera tout changement dans les paramètres régionaux et continuera à afficher le solde comme "1000,00 USD".
2. Tiège de longueur de traduction
N'oubliez pas que lors de la traduction des chaînes et des formats d'événements, la longueur peut varier considérablement. Par exemple, "3 juin 1977" devient "3 de Junio de 1977" lorsqu'il est traduit en espagnol. Bien sûr, il peut y avoir des situations plus extrêmes. Par conséquent, lorsque nous internationalisons l'application, nous devons mettre en place des règles CSS correspondantes et effectuer des tests complets pour garantir que les composants de l'interface utilisateur ne s'effondrent pas (variantes).
3. Fuseau horaire
N'oubliez pas que le filtre DateTime d'Angular utilise le fuseau horaire défini par le navigateur. Par conséquent, la même application affichera différentes informations de temps en fonction des paramètres de fuseau horaire de l'ordinateur exécutant l'application, plutôt que du fuseau horaire spécifié par le développeur en JavaScript ou angulaire.