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