Comme d'habitude, cela dépend.
Généralement, vous ne disposez que d'un fichier en anglais contenant des messages en anglais international. Dans ce cas, vous ne conserverez pas de fichiers séparés pour chaque version, mais vous retomberez en anglais international (ayant une demande pour en-US, en-CA, etc vous servirez des messages de en.json) . A en juger par votre surnom, vous savez probablement qu'il est parfois préférable de conserver des messages séparés pour certaines cultures spécifiques pour lesquelles les messages anglo-américains (typiquement utilisés comme anglais international) pourraient être simplement beaucoup trop directs.
S'il y a une demande pour la version locale séparée (c.-à-en-IN), vous servir des messages à partir du fichier spécifique (c.-à-en-IN.json), mais revenir à en pour chaque autre langue (en-GB , en-AU, etc.).
Le recours aux ressources (terme utilisé par les spécialistes pour ce que j'ai décrit plus haut) pourrait être très douloureux à mettre en œuvre. Bien sûr, d'habitude vous revenez à la langue de base (et pour tout en-XX), mais il y a quelques cas de coin que vous devez savoir: portugais/portugais brésilien, norvégien et chinois. En cas de portugais vous devez utiliser pt-BR (à savoir pt-BR.json) et pour les demandes de pt ou pt-XX revenir à pt-BR, comme est maintenant le standard portugais brésilien. De toute évidence, il pourrait être facilement fait en créant simplement un fichier pt.json et laisser tout tomber à pt.
Ce n'est pas le cas ni pour le norvégien ni pour le chinois.
Il existe deux versions de langue norvégienne:
- Norvégien nynorsk (locale nn-NO)
- norvégien bokmål (locale nb-NO)
Il est également ce que l'on appelle un langage de macro (locale no).
Sauf si vous maintenez deux versions distinctes de norvégien (ce qui est peu probable), vous devez utiliser un fichier de ressources (c'est-à-dire no.json < - semble drôle, n'est-ce pas?) Et revenir à pour toute demande de nn-NO, nb-NO, nb, nn et non-non (je crois tout simplement pas seront couverts).
Le chinois est encore plus compliqué. Vous avez peut-être entendu parler de chinois simplifié (paramètres régionaux zh-Hans) et chinois traditionnel (zh-Hant). Si vous avez besoin de localiser en chinois, il judicieux de maintenir deux fichiers distincts chinois (c.-à-zh-Hans.json et zh-Hant.json) et retomber toute demande comme suit:
- zh, zh-CN etzh-SG-zh-Hans
- zh-HG, zh-MO et zh-TW-zh-Hant
J'espère que cela vous donnera une meilleure compréhension. Il vaut la peine de considérer les futurs plans de localisation pour implémenter le mécanisme de repli des ressources aussi simple que possible (mais pas plus simple). Si vous avez besoin de prendre en charge des langues comme l'anglais, le français, l'italien, l'allemand et l'espagnol, il est inutile de mettre en œuvre des règles complexes - vérifiez simplement si xx-XX.json existe et servez-le s'il le fait, sinon vérifiez s'il existe xx.json ...) ou revenir à la langue d'application par défaut (en.json, je suppose?).