Obtention de noms de pays à partir de NSLocale et optimisation
AliGator
Membre, Modérateur
En même temps, pourquoi ne pas utiliser NSLocale pour lister tous les pays (la liste étant intégrée au système) et dans la bonne langue, plutôt que de les dupliquer dans le Localizable.strings ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Parce que depuis la nuit des temps j'ai :
- une liste de pays avec leurs propres ID dans une base
- gérés en relation et liés à d'autres tables
- et que cette liste est compatible avec ma liste sur le serveur dans un système multi-plateformes
Donc je me vois mal avoir la liste pour Cocoa et une liste différente pour Rails par exemple.
Après, y'a p-e moyen de mettre un code iso dans ma table et de m'en servir comme clé de traduction dans chaque système.
OK, je pars là -dessus.
Pour Cocoa, je pars sur un NSDictionary fabriqué de code isos + traduction à aller interroger depuis l'ISO correspondant dans ma table countries.
Pour Rails, j'ai trouvé 2 gems qui font le job:
https://github.com/alexrabarts/iso_country_codes
https://github.com/onomojo/i18n-country-translations
Le plus long sera d'intégrer les codes iso dans ma base sqlite (client) et mysql (serveur).
C'est pas plus intéressant de fabriquer un dico lors du lancement de l'app ?
Puis d'aller chercher le pays dans mes modèles partout où j'en ai besoin par le biais de ce dico:
?
Ceci dit, pour moi NSLocale c'est déjà un dictionnaire. J'imagine sans trop de soucis que l'implémentation sous-jacente d'Apple pour "[NSLocale displayNameForKey:value:]" soit simplement un dictionnaire stocké dans un fichier PLIST localisé, contenant toutes les clés et valeurs nécessaires... et donc au final c'est sans doute déjà un NSDictionary. Avec sans doute derrière un NSCache de ce dictionnaire pour éviter d'avoir à le relire du disque à chaque fois.
Enfin ce n'est qu'une supposition de ma part, mais si c'est ça, du coup je ne pense pas que tu vas donc gagner beaucoup entre construire un dico au lancement, ou demander à NSLocale à chaque fois. Et franchement, je suis plutôt dans l'optique de faire au plus simple (faire une méthode "+countryNameFromISOCode:" qui fait directement appel à NSLocale) et ne partir sur la solution de créer un dictionnaire intermédiaire au lancement que si les performances sont vraiment problématiques et que Instruments a clairement identifié que c'était là que le bât blessait.
A voir si l'appel à ce code dans le cas d'une boucle prend du temps...
Contre ça actuellement: