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.

Transcript

2. Application Multilingue avec ExtJS 5 Tour d'horizon des solutions natives et alternatives
3. Vincent Munier Manager Technique
4. Pourquoi cette présentation ?
5. Le Planning
6. Planning •  Quelques définitions
7. Planning •  Quelques définitions •  Quelques réflexions
8. Planning •  Quelques définitions •  Quelques réflexions •  Périmètre de la présentation
9. Planning •  Quelques définitions •  Quelques réflexions •  Périmètre de la présentation •  Structure d'une application
10. Planning •  Quelques définitions •  Quelques réflexions •  Périmètre de la présentation •  Structure d'une application •  Les profils
11. Planning •  Quelques définitions •  Quelques réflexions •  Périmètre de la présentation •  Structure d'une application •  Les profils •  Conclusion
12. Planning •  Quelques définitions •  Quelques réflexions •  Périmètre de la présentation •  Structure d'une application •  Les profils •  Conclusion •  Questions
13. Quelques définitions
14. Quelques définitions •  i18n : internationalisation •  L10n : régionalisation
15. Quelques définitions i18n : internationalization •  Internationalization = Internationalisation •  Capacité d'une application à être traduisible
16. Quelques définitions L10n : localization •  Localization = régionalisation •  Traduction de l'application
17. Quelques définitions L10n + i18n
18. Quelques définitions Le framework Ext JS est livré avec des fichiers de localisation dans plus de 40 langues :
19. Quelques réflexions
20. Quelques réflexions Différences entre les langues •  Sens de lecture •  Alphabet •  Ponctuation •  Formatage des dates •  Logique culturelle •  Logique légale
21. 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
22. Périmètre de la présentation
23. 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 (!)
24. 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 »
25. Structure d'une application Rappel
26. Structure d'une application : rappel
27. Les profils
28. Les profils 3 exemples de profil •  Le développeur •  Le traducteur •  Le chef de projet métier 1 profil = 1 vision !
29. Le développeur : solution simple Un constat : un développeur est fainéant ! •  1er réflexe : 1 copier / coller par langue •  Override vs singleton
30. Le développeur : solution simple
31. 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
32. 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
33. 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
34. Le développeur : solution modérée
35. 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
36. 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
37. 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
38. Le développeur : solution complexe
39. 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
40. 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
41. Problème ! !=
42. 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 !
43. Le traducteur: solution simple
44. 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
45. 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
46. 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
47. Le traducteur : solution complexe
48. 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
49. 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
50. Le chef de projet: solution complexe Concentre les objectifs de ses collègues •  Besoin de personnalisation •  Rechargement à chaud
51. Le chef de projet: solution complexe
52. Le chef de projet: solution complexe Les points positifs : •  Concentre tous les points positifs précédents •  Changement de langue = rechargement à chaud
53. 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 !
54. Pour finir
55. 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 !
56. Conclusion Le bon choix = travail simplifié pour tous !
57. Questions
58. Merci de votre attention ! Vincent MUNIER www.jnesis.com