Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Vincent Munier (Jnesis) : Multilingual Applicat...

Vincent Munier (Jnesis) : Multilingual Applications with Ext JS 5: Overview of native and alternatives solutions

Internationalization has become a common issue for developers, especially for those in touch with software publishing or in globalized organizations. Ext JS has been offering solutions to this concern for a long time, some are native and well known, others are more innovative ( additional files, dynamic file loading , web service ...). This session aims to present a complete overview of the solutions offered to Ext JS developers, the pros, the cons and how to implement them.

Lee Boonstra

June 03, 2015
Tweet

More Decks by Lee Boonstra

Other Decks in Technology

Transcript

  1. Planning •  Quelques définitions •  Quelques réflexions •  Périmètre de

    la présentation •  Structure d'une application •  Les profils
  2. Planning •  Quelques définitions •  Quelques réflexions •  Périmètre de

    la présentation •  Structure d'une application •  Les profils •  Conclusion
  3. Planning •  Quelques définitions •  Quelques réflexions •  Périmètre de

    la présentation •  Structure d'une application •  Les profils •  Conclusion •  Questions
  4. Quelques définitions Le framework Ext JS est livré avec des

    fichiers de localisation dans plus de 40 langues :
  5. Quelques réflexions Différences entre les langues •  Sens de lecture

    •  Alphabet •  Ponctuation •  Formatage des dates •  Logique culturelle •  Logique légale
  6. Quelques réflexions Internationalisation •  Réflexion poussée du fonctionnel en amont

    de la réalisation •  Socle applicatif le plus universel possible •  Dans le pire des cas, peut aboutir à une refonte
  7. Périmètre de la présentation Internationalisation •  N'est pas réduite à

    des considérations techniques •  Mélange de : ü  Besoins fonctionnels ü  Besoins métiers ü  Contraintes technique ü  Contraintes de temps (!)
  8. Périmètre de la présentation Part du principe que : • 

    L'application a été correctement pensée fonctionnellement pour l'internationalisation •  Présente des solutions concrètes selon le profil « utilisateur »
  9. Les profils 3 exemples de profil •  Le développeur • 

    Le traducteur •  Le chef de projet métier 1 profil = 1 vision !
  10. Le développeur : solution simple Un constat : un développeur

    est fainéant ! •  1er réflexe : 1 copier / coller par langue •  Override vs singleton
  11. Le développeur : solution simple Les points positifs : • 

    Extrême simplicité de mise en place •  Aucune complexité architecturale •  Traduction concentrée dans un seul fichier par langue •  Pas de mutualisation de ressources
  12. Le développeur : solution simple Les points négatifs : x

    applications distinctes ! •  Maintenance du code dupliquée •  x senchaCMD •  x urls par langue, donc x point d'accès à l'application •  Ajout / modification d'une clé = x sencha CMD •  Pas de mutualisation de ressources •  X déploiement par langue
  13. Le développeur : solution modérée Un développeur est fainéant ,

    mais pas paresseux. 1 seule maintenance de source = 1 seul travail ! » Modification de l'app.json (recommandé) : propriété builds avec définition des locales
  14. Le développeur : solution modérée Les points positifs : • 

    Solution native : conf par fichiers de paramétrage •  1 seul code source à maintenir •  1 seul build = 1 seule SenchaCMD •  Traduction concentrée dans un seul fichier par langue •  Pas de mutualisation de ressources
  15. Le développeur : solution modérée Les points négatifs : • 

    x urls par langue, donc x points d'accès à l'application •  Ajout / modification d'une clé = 1 sencha CMD •  1 application par langue, 1 apps.js par langue •  Pas de mutualisation de ressources •  X déploiement par langue
  16. Le développeur : solution complexe Un développeur est fainéant ,

    mais parfois motivé. •  1 seule url = 1 seul accès •  1 seule url = 1 seul déploiement » Modification de l'app.json : intégration des manifests ü  Propriété builds pour les locales ü  Propriété bootstrap pour les manifests en dev ü  Propriété output pour le déploiement
  17. Le développeur : solution complexe Les points positifs : • 

    1 seule url : possibilité de changement par paramètre •  Natif : conf avancée par fichier de paramétrage •  1 seul code source à maintenir •  1 seul build = 1 seule SenchaCMD •  Traduction concentrée dans un seul fichier par langue •  Pas de mutualisation de ressources •  1 seul déploiement
  18. Le développeur : solution complexe Les points négatifs : • 

    Ajout / modification d'une clé = 1 sencha CMD •  1 seul index.html, mais 1 apps.js par langue •  Pas de mutualisation de ressources •  Changement de langue = rechargement
  19. Le traducteur : solution simple Les contraintes : •  Compréhension

    de la fonctionnalité •  Compréhension du métier Grille != fence != grid •  Accès à l'application •  Accès aux fichiers de traduction !
  20. Le traducteur: solution simple Les points positifs : •  Pas

    de configuration spécifique •  Ajout / modification d'une clé = prise en compte après rechargement •  1 seule url : possibilité de changement par paramètre •  1 seule source, 1 seule application buildée •  Mutualisation de ressources
  21. Le traducteur : solution simple Les points négatifs : • 

    Nécessite du code js spécifique : loadscript •  Les fichiers de localisation sont peu lisibles •  Mutualisation de ressources •  Changement de langue = rechargement •  Méthode du singleton plus difficile à mettre en place que l'override dut au chargement asynchrone
  22. Le traducteur : solution complexe Dans l'idéal : •  Traduction

    par un outil tiers •  Outils tiers intégré ou non à l'applicatif •  Exemple d'intégration totale : Exo + ExtJs 5 Voir la SenchaCon de San Fransisco •  Utilisation d'un ws ou d'un loadScript
  23. Le traducteur: solution complexe Les points positifs : •  Traduction

    possible par un outils tiers ! •  Pas de configuration spécifique •  Ajout / modification d'une clé = prise en compte après rechargement •  1 seule url : changement par paramètre (locale) •  1 seule source, 1 seule application buildée •  Mutualisation de ressources
  24. Le traducteur: solution complexe Les points négatifs : •  Nécessite

    encore plus du code js spécifique •  Mutualisation de ressources •  Changement de langue = rechargement •  Attention aux performances ! •  Méthode du singleton plus difficile à mettre en place que l'override dut au chargement asynchrone
  25. Le chef de projet: solution complexe Concentre les objectifs de

    ses collègues •  Besoin de personnalisation •  Rechargement à chaud
  26. Le chef de projet: solution complexe Les points positifs :

    •  Concentre tous les points positifs précédents •  Changement de langue = rechargement à chaud
  27. Le chef de projet: solution complexe Les points négatifs :

    •  Beaucoup de code js spécifique •  Override obligatoire des composants natifs •  Mutualisation de ressources •  Mécanique imbriquée poussé et complexe, donc : Attention aux performances !
  28. Conclusion •  A chaque solution, ses points positifs et négatifs

    •  Mesurer le pour et le contre •  Les besoins ne sont pas les mêmes selon le profil •  Et surtout : Bien choisir sa solution, avant tout démarrage !