Je suis confronté à un problème avec les étiquettes i18n.

Mon application lit quelques étiquettes i18n sur le frontend js en utilisant la fonction Granite.I18n.get (''). Le dictionnaire entier est téléchargé sous «/libs/cq/i18n/dict.{+locale}.json» comme indiqué dans «/etc/clientlibs/foundation/shared/source/init.js».

Maintenant, le dictionnaire en renvoie uniquement les étiquettes personnalisées et est de petite taille. Mais dans d'autres langages comme fr, le fichier de dictionnaire est une agrégation de tous les dictionnaires / libs et est très énorme. J'ai remarqué cela dans quelques autres sites également.

tennantco.com

en dictionnaire - 118 Ko

dictionnaire français - 1,4 Mo

Timewarnercable.com

en dictionnaire - 1,1 Ko

dictionnaire français - 1,2 Mo

Thermofisher

en dictionnaire - 3 Ko

dictionnaire français - 695 Ko

Notre problème avec cela est que le coût de la mise en cache de ce fichier lourd à CDN augmente et que l'on tente de trouver un moyen de réduire le coût du CDN.

Je comprends que les étiquettes sont la clé elle-même. Mais l'ExportServlet est capable de filtrer le dictionnaire personnalisé de rendu uniquement pour en. Nos dictionnaires sont similaires aux dictionnaires otb sous / libs. Alors comment se fait-il qu'ExportServlet traite les étiquettes otb sous une exportation?

Ce bogue est-il commun à tous les produits CMS ou spécifique à Adobe? Vous avez également besoin d'une solution ou d'une solution de contournement pour obtenir un dictionnaire personnalisé uniquement pour les autres langues.

2
Saravana Prakash 26 juil. 2017 à 17:41

2 réponses

Meilleure réponse

J'ai fini par écrire une implémentation personnalisée car je n'ai pas eu beaucoup d'aide de la part des billets Adobe sur ce problème.

  • Le dictionnaire OTB json est rendu par ResourceBundleExportServlet
  • J'ai créé un servlet Sling personnalisé qui préparera et retournera json similaire à ResourceBundleExportServlet
  • Modification de /etc/clientlibs/granite/utils/source/I18n.js pour appeler le servlet personnalisé plutôt que le servlet otb.
  • Le servlet personnalisé est codé pour renvoyer uniquement un dictionnaire de données spécifique et non tous les dictionnaires.

Cela a résolu mon problème. Bien que je ne sois pas convaincu comme solution appropriée. Il faut un autre moyen de rendre cela propre.

1
Saravana Prakash 14 sept. 2017 à 16:34

Nous avons été confrontés à la même exigence de récupérer les valeurs I18n côté client en utilisant la bibliothèque Granite.i18n. C'est ce que j'ai fait.

  1. Création d'un servlet personnalisé qui renvoie une réponse JSON similaire à
    ResourceBundleExportServlet.
  2. Chargé le bundle en utilisant le nom de base et le paramètre de locale - ResourceBundle resourceBundle = req.getResourceBundle (basename,
    pageLocale);
  3. Ajout de sling: basename = "basename_constant" 'dans le fichier xml i18n spécifique à la langue qui réside dans le dossier / apps / project-name / i18n. Dans mon cas, je mets la valeur de locale elle-même ex: "zh_cn".

4.Dans le paramètre de fichier javascript clientlibs Granite.I18n.setUrlPrefix ("/ bin / custom / i18n / dict."); à récupérer de
URL du servlet personnalisé. Cela ne nécessite pas de modification de OOTB I18n.js

2
Sudheer Sundalam 22 mai 2018 à 21:05