Les stratégies de localisation d'une application Flex

Les stratégies de localisation d'une application Flex Adobe eSeminar - 27/06/08 David Deraedt Centre Regart.net

Introduction
Comment adapter une application Flex à différents langages, régions et cultures ? NB: Ici, on ne parlera pas de la traduction du code source Distinction localisation / internationalisation
Internationalisation = i18n (Internationalization) = partie logicielle
Localisation = régionalisation = L10n (localization) = traduction / adaptation
(Globalization = g11n = internationalisation + régionalisation)

Introduction
Il ne s'agit pas de que traduire du texte ! - Système de mesures (poids, taille, volume, surface, ...) - Premier jour de la semaine - Fuseaux horaires - Formatage pour les dates - Devise (caractère et placement devant ou derrière la somme) - Images (drapeau) et couleurs - Points encore plus spécifiques => programmation - etc...

Introduction
Concernant le texte, au delà de la traduction, il y a d'autres enjeux : - Encodage - Alphabets - Sens d'écriture (gauche-droite, vertical) - Différences d'orthographes selon les régions => Grande complexité si on veut aller loin

Introduction
Nouvelle distinction entre deux types de données à adapter :
Données "métier"
Données d'interface (titres, boîtes de dialogue, boutons, icônes, ...)

Données métiers
Comme tout ce qui concerne la partie métier = côté serveur. Exemple: Application qui traite de livres : les titres et résumé des différents livres dans différentes langues vont être stockés en base, et accédés côté serveur. Plusieurs stratégies possibles :
Variable de session qui stocke la langue grâce à une méthode : exemple "setLanguage(pLg);"
Paramètre pour chaque méthode du service : exemple "getBooks (pLg) ;"
Objets transmis (VOs/ DTOs) contiennent toutes les traductions

Données de l'interface
Plusieurs cas de figure :
i18n statique : on compile pour une ou plusieurs langues (paramètre de compilation)
i18n dynamique : les fichiers de localisation sont chargés dynamiquement
Dans la majorité des cas, les données de traductions sont chargées dynamiquement :
Moins lourd (on ne charge que ce dont on a besoin)
Plus souple : on peut changer les données sans avoir à recompiler toute l'application.

Du point de vue de l'utilisateur, 2 cas de figure :
La langue est déterminée au lancement et définitive
=> Nécessité de recharger l'application (page web) pour changer de langue.
La langue peut être modifiée à l'exécution (ex: combobox)
=> Plus souple, mais peut être complexe car:
Il va falloir tout "databinder"
Il va falloir aussi mettre à jour toutes les données métiers (compliqué si l'objet ne contient pas toutes les traductions)
Pas indispensable

Parfois, la langue désirée est passée en paramètre dans l'URL http://www.website.com/page.html?lg="en_US" http://www.website.com/page.html#lg="en_US" Pour récupérer cette variable :
Flashvars
var lg:String = application.parameters.lg ;
BrowserManager
var params:Object = URLUtil.stringToObject(bm.fragment); var lg:String =params.lg;

Quelles stratégies ?
Comment implémenter l'i18n de notre application?
On utilise le mécanisme prévu par Adobe : Resource Bundles
On crée son propre mécanisme

Les Resource Bundles
Ce sont des fichiers ".properties" compilés :
Simple fichiers textes
Format UTF8
Couple Clef / valeur
#locale/en_US/app.properties message=Hello, world! message-size=30 #locale/es_MX/app.properties message=¡Hola, mundo! message-size=40

Syntaxe
Couple Clef / valeur séparé par "=", ":" ou espace
Commentaires commencent par # ou !
Si plus d'une ligne, on utilise le caractère backslash "" à la fin de la ligne précédente
#locale/en_US/app.properties message=Hello, world! message-size=30 #locale/es_MX/app.properties message=¡Hola, mundo! message-size=40

A retenir :
On peut les utiliser pour autre chose que de la L10n (ex config). Pas forcément conseillé.
Doivent être compilés par Flex (transformés en classe AS3 qui étendent ResourceBundle à la compilation)
=> Pas très souple si on a pas de système d'intégration continue !

On va soit les compiler
dans l'application (i18n statique)
séparément (i18n dynamique)
Distinction deux familles de domaines de L10n :
Framework Flex
Application elle-même
Attention : L'une ne va pas sans l'autre : si on ajoute une langue pour notre application, le framework doit être traduit dans cette langue !

Framework Resource Bundles
flex_builder_install/sdks/3.0.0/frameworks/locale/en_US/ => fichiers SWC Par défaut, il existe 2 langues : anglais US et japonais (Cf paramètres de compil par défaut du projet) Rappel syntaxe : [langue]_[region] : exemple en_US Les fichiers properties correspondants se trouvent dans : flex_builder_install/sdks/3.0.0/frameworks/projects/framework/bundles/en_US/src

Pour ajouter une langue : utilitaire "copylocale" flex_builder_install/sdks/3.0.0/bin Utilisation : copylocale en_US fr_FR Certains ont déjà fait le travail pour nous !
Adobe : http://opensource.adobe.com/wiki/display/flexsdk/Submitting+a+Patch
Projet BabelFlex (Tontons Flexeurs) : http://ttfx.org/Tontons_Flexeurs/BabelFlex.html
Problème : les fichiers de datavisualisation ne sont pas traduits, pour eux c'est plus compliqué. cf http://philflash.inway.fr/flex/copylocale/index.html

Pour aller vite, inutile de devoir tout traduire : avoir un répertoire du nom de la langue qui nous intéresse, avec les bons SWC suffit ! On peut donc maintenant localiser notre application...

Application Resource Bundles
Convention : placer fichiers .properties dans répertoire : src/locale/[langue]_[region]/fichier.properties On en créera un par "domaine de traduction" et par langue. Exemple : src/locale/fr_FR/trads.properties src/locale/en_US/trads.properties src/locale/es_ES/trads.properties On peut aussi créer des projets de bibliothèques pour créer des SWC de Resource Bundles.

Compiler les Bundles avec l'application
C'est la méthode d'i18n statique : 1. Ajouter un chemin de compilation vers le bundle Properties -> AS Build Path -> Source Path -> New Folder -> src/locale/{locale} 2. Changer le paramètre de langue de compilation : Properties -> Compiler -> -locale=[langue]_[region] ... ou dans flex-config.xml : <locale> <locale-element>en_US</locale-element> <locale-element>es_ES</locale-element> </locale>

Compiler les Bundles avec l'application
A noter :
Pour se débarrasser du warning, on peut ajouter un paramètre: -allow-source-path-overlap=true
On ajouter plusieurs langues à la suite : locale=en_US, locale=fr_FR pour en compiler plusieurs à la fois.
Par défaut, c'est la première qui sera utilisée, ou celle précisée par le flashvars : localeChain=es_ES

Compiler les Bundles séparément
Problèmes d'une i18n "statique" (avec l'application) :
Alourdit la taille de l'application
Impossible d'ajouter ou modifier les fichiers properties sans recompiler toute l'application
Depuis Flex 3, il est possible de charger ces fichiers dynamiquement, une fois compilés (cf StyleManager et feuilles de style CSS).

Tous les fichiers properties d'une langue sont compilés en un seul SWF. Pour compiler les fichiers, on utilise une ligne de commande : mxmlc -locale=fr_FR -source-path=locale/{locale} -include-resource-bundles=MonFichier, collections,containers,controls,core,effects,skins,styles -output fr_FR_ResourceModule.swf

Pour connaître les fichiers à compiler, on utilise un paramètre à la compilation d'une application : mxmlc -locale= -resource-bundle-list=leFichier.txt MonApp.mxml La liste des bundles nécessaires est alors écrite dans leFichier.txt Note : Sous OSX, il faut donner un chemin absolu !

Pour charger un bundle : ResourceManager.loadResourceModule(rb.swf, true); Le 2ème paramètre précise si l'application doit être mise à jour automatiquement. Pour précharger les resource modules, on a une flashvars : <param name='flashVars' value='resourceModuleURLs=es_ES_ResourceModule.swf &localeChain=es_ES'/>

Utiliser les Resource Bundles
Comment utiliser les données dans notre application? En MXML, 2 solutions : syntaxe "@" et AS3. <mx:Label x="10" y="10" text="@Resource(key='zip', bundle='RegistrationForm')"/> Le paramètre "bundle" peut être facultatif si le fichier properties a le même nom que la classe (déconseillé). Limite : pas de DataBinding => on préférera utiliser la méthode par AS.

En AS3 : Metadata ResourceBundle devant la classe : [ResourceBundle("MyBundle")] public class MyClass {} ... puis, dans le code : var text:String = ResourceManager.getInstance().getString( 'RegistrationForm','personname') ;

Mais tous les UIComponents ont une propriété resourceManager vers ce Singleton : En MXML : DataBinding => syntaxe AS3 : <mx:Metadata> [ResourceBundle("RegistrationForm")] </mx:Metadata> ... et ensuite : <mx:Label x="10" y="65" text="{resourceManager.getString('RegistrationForm', 'personname')}"/>

Changer de langue à l'exécution
On utilise la propriété localeChain du resourceManager private function changeLanguage(pLg:String):void { resourceManager.localeChain=[pLg]; } Tableau (Array) car on peut passer plusieurs langues simultanément (cascade): si un élément n'est pas dans la première, on va le chercher dans la deuxième, etc...

Charger d'autres types de données
Charger autre chose que des chaînes : resourceManager.getNumber("myResources", "PRICE"); resourceManager.getInt("myResources", "AGE"); resourceManager.getUint("myResources", "COLOR"); resourceManager.getBoolean("myResources", "SENIOR"); Il existe aussi getClass(), getString(), getObject(), et getStringArray() .

Charger d'autres types de données
Par exemple, pour une image (imaginer un drapeau), on utilisera : resourceManager.getClass("flag"); Dans le resourceBundle, on aurait : flag=Embed("images/flag_fr.gif") Pour une classe, on utilise la directive ClassReference : SORTER=ClassReference("sortingClasses.en_US.Sorter")

Stratégies alternatives
On peut vouloir stocker ces données côté serveur d'application et/ou BDD :
Le serveur a un service spécial de traduction en plus des données métiers
Rarement utilisé, mauvais mélange des genre, pas forcément utile
On préférera le format texte, généralement, en XML. Avantages :
On peut s'appuyer sur des standards de traduction, comme le XLIFF (OASIS)
Pas besoin de compiler les ressources

Comment procéder ? Deux solutions :
Créer un mécanisme de toutes pièces
S'appuyer sur les resourceBundles/ ResourceManager

package com. dehats . localize { import flash. events . IEventDispatcher ; [ Event ( name = "change" )] public interface ILocalizer extends IEventDispatcher { function get language () : String ; function set language ( pLang: String ) : void ; function get langXML () : XML function set langXML ( pXML: XML ) : void [ Bindable ( "change" )] function getString ( pKey: String ) : String ; } }

<mx:Panel title= "{loc.getString('prodTitle')}" xmlns:mx= "http://www.adobe.com/2006/mxml" layout= "absolute" width = "400" height = "300" > <mx:Script> <! [ CDATA [ import com. dehats . localize . * ; [ Bindable ] public var loc:ILocalizer ; ]] > </mx:Script> <mx: Button x= "10" y= "10" label= "{loc.getString('saveBtn')}" /> </mx:Panel>

S'appuyer sur les resources Bundles de Flex : 2 étapes 1. Créer sa propre classe ResourceBundle public class MyResourceBundle extends ResourceBundle { override protected function getContent():Object { // C'est ici qu'on implémentera la logique // d'accès aux données var properties:Object = {}; properties["my_key"] = "My value"; return properties; } }

2. L'ajouter au resourceManager var moreResources: MyResourceBundle = new MyResourceBundle("fr_FR", "moreResources"); // Ajout dynamique de contenu moreResources.content["CANCEL"] = "Annuler"; resourceManager.addResourceBundle(moreResources); resourceManager.update();

Le cas d'une application AIR
Pas d'intéret particulier à charger dynamiquement les bundles : on va les compiler statiquement avec l'application. Avec AIR 1.1, l'interface d'installation et les boîtes de dialogue ont été traduites en Japonais, Français, Allemand, Chinois (traditionnel et simplifié), Italien, Espagnol, Coréen, Portugais et Russe.

Conclusion
Depuis Flex3, l'utilisation des RB côté application est satisfaisant : pas besoin de réinventer la roue
Le workflow est complexe : préférer un système d'intégration continue, voire des tâches ANT
La lisibilité du code MXML et AS3 n'est pas excellente, surtout dans l'interface : préférer des clefs courtes et précises
Si beaucoup de langues, attention à ne pas trop vouloir précharger - mieux vaut charger les bundles au fur et à mesure

Questions / réponses
David Deraedt - Flex My Day http://www.dehats.com Centre de formation Regart.net http://www.regart.net Remerciements Lovely Charts http://www.lovelycharts.com

http://www.dehats.com	339
http://www.slideshare.net	11
http://74.125.155.132	1

Les stratégies de localisation d'une application Flex

by david deraedt

Accessibility

Upload Details

Usage Rights

3 Embeds 351

Statistics

Les stratégies de localisation d’une application Flex Presentation Transcript