Compiler en spécifiant la langue

Adobe nous donne la possibilité de spécifier la langue à la compilation d'une application, pas terrible. Ca veut dire que si on veut l'application dans une autre langue, il faut recompiler.

import mx.resources.ResourceBundle;
 
[ResourceBundle("truc")] 
private var ma_ressource_truc:ResourceBundle;

trace(ma_ressource_truc.getString("une_cle"));

Compiler avec plusieurs langues

Ca c'est la mauvaise idée quand on veut faire une application multilangue. Ca a été suggéré par Jeff Taper dans son article Internationalizing Flex 2 Apps Pt 2 (en fait, je ne sais pas qui c'est :) ).

Je pense que je n'ai pas besoin d'expliquer pourquoi c'est pas bien, c'est presque du bon sens. D'ailleurs, j'ai même vu des exemples sur l'utilisation des namespace pour changer de langue. Il ne faut pas utiliser ça pour la traduction d'une application.

Charger dynamiquement une langue

Si c'est pas super d'inclure la langue à la compilation, alors on se tourne vers le chargement dynamique de la langue.

Par exemple, on peut charger des fichiers XML, des fichiers JSON ou autres. Bref, il faut se programmer son petit gestionnaire de langue avec le chargement, le parsage et tout. Ce qui ne doit pas être très long d'ailleurs.

Compiler un swf pour une langue

Une idée qui m'est venue, c'est d'utiliser les ResourceBundle de Adobe mais juste pour un swf qu'on va charger ensuite.

Je compile donc mon fichier de langue comme ça :

package
{
import flash.display.Sprite;
import mx.resources.ResourceBundle;
 
public class Locale extends Sprite
{
	[ResourceBundle("common")] 
	private var rb_common:ResourceBundle;
	[ResourceBundle("error")] 
	private var rb_error:ResourceBundle;
 
	/**
	 * Constructeur
	 */
	public function Locale() 
	{
		
	}
	
	/**
	 * Récupération de la valeur d'une clé dans un bundle
	 * 
	 * @param pBundle Le nom du bundle
	 * @param pKey La clé
	 * @return La valeur
	 */
	public function getString(pBundle:String, pKey:String):String
	{
		var rb:ResourceBundle = this["rb_"+pBundle];
		return rb.getString(pKey);
	}
}
}

J'obtiens un swf qui va inclure les contenus des fichiers common.properties et error.properties dans le dossier de langue (je zappe la procédure de création d'un swf).

Et dans mon application, je fais ça :

import flash.display.Loader;
import flash.net.URLRequest;
import flash.events.*;
 
private var loader:Loader;
 
private function init():void {
	// Chargement du fichier swf qu'on a créé pour contenir toutes les traductions d'une langue
	var urlRequest:URLRequest = new URLRequest("locale/fr_FR.swf");
	loader = new Loader();
	loader.contentLoaderInfo.addEventListener(Event.COMPLETE, completeHandler);
	loader.load(urlRequest);
}
 
private function completeHandler(e:Event):void {
	// Une fois chargé, on instancie la class Locale
	var domain:ApplicationDomain = loader.contentLoaderInfo.applicationDomain;
	var localeClass:Object = domain.getDefinition("Locale");
	var locale:Object = new localeClass();
	
	// Voilà un petit test pour vérifier que ça marche
	trace(locale.getString("common", "hello"));
}

Vous avez remarqué l'utilisation de Object comme type d'instance. Il est possible d'implémenter une interface dans Locale, puis de typer l'instance avec l'interface, pour avoir du typage à la compilation. Je ne l'ai pas fait ici pour faire plus court.

Conclusion

Je ne sais pas ce qu'il y a derrière le chargement des .properties ni des performances par rapport à un chargement perso de fichier texte. En tout cas, ça m'évite de faire une deserialisation.

Je vais utiliser ce dernier système pour l'instant, si quelqu'un a une autre solution ... :) .

PS: Les icones de l'illustration du billet ont été créées par Maurice Svay.