On a vu, dans l'article précédent, comment faire pour binder des ressources directement dans les vues WinRT (et ne pas être obligé de localiser notre application en utilisant le binding via Uid ou passer par du code-behind). Le principe consiste à passer par un Converter qui, pour une clef de ressource et un nom de fichier, va récupérer une ressource localisée via la classe ResourceLoader.

L'utilisation de ce converter est plutôt appréciable mais atteint vite ses limites lorsque l'on travaille sur une application possédant beaucoup de ressources. Le désavantage de ce converter est qu'il faut renseigner la clef de ressource sous forme d'une chaîne de caractères ce qui implique de n'avoir ni l'autocompletion ni la vérification à la compilation (ce qui est très dommageable en terme de confort d'utilisation et de productivité).

La solution idéale serait de reproduire le fonctionnement classique utilisé pour les fichiers resx (en ASP.NET, Windows Phone, etc.), c'est à dire un Custom Tool (PublicResxFileCodeGenerator) chargé de générer une classe par fichier resx qui expose les ressources via la classe ResourceManager. Comme le développement et le déploiement d'un Custom Tool est assez pénible, j'ai préféré créer un template T4.

(lire plus…)

[Update : Une nouvelle solution plus élégante (et avec autocompletion et vérification à la compilation) a été mise en place. Pour plus d'informations : http://sebastienollivier.fr/blog/winrt/localiser-une-application-winrt-xaml-en-utilisant-le-binding-aux-ressources-2/]

Avec la mise en place des stores (Windows Phone, Windows 8, iOS, Android, etc.) et la possibilité de publier une application dans le monde entier, la localisation des applications est devenue fondamentale.

Pour localiser une application Windows Phone, on peut binder directement des ressources aux propriétés des contrôles des vues. Cela donne un contrôle déclaré comme ci-après, pour afficher la ressource localisée ApplicationTitle du fichier de ressources CommonResources :

<TextBlock Text="{Binding CommonResources.ApplicationTitle, 
                       Source={StaticResource LocalizedStrings}}" />

Pour plus d'informations sur la manière de localiser une application Windows Phone : http://blogs.msdn.com/b/pierreca/archive/2010/09/21/internationalisez-votre-application-windows-phone-7.aspx

Malheureusement avec WinRT, on ne peut pas binder des ressources aux contrôles des vues. A la place, on peut soit utiliser la technique des Uid, soit utiliser la classe ResourceLoader pour récupérer la ressource localisée et l'appliquer manuellement.

Pour plus d'informations sur la manière de localiser une application WinRT de manière "classique" : http://win8dev.fr/comment-localizer-votre-application/

Bien que cela fonctionne, les deux techniques me semblent moins efficaces que ce qu'on a à disposition sur Windows Phone. Passer par les Uid nécessite de définir un Uid à chaque contrôle, crée un couplage fort entre l'Uid du contrôle et la clef de la ressource (si on change l'Uid du contrôle, la clef de ressource doit changer et inversement) et ne permet pas de partager les fichiers de ressources entre plateformes (par exemple, même fichier de ressources pour les versions Windows Phone et Windows 8 d'une application). La technique du ResourceLoader oblige à écrire du code-behind, ce qu'on cherche généralement à éviter en utilisant le pattern MVVM.

J'ai donc pris le temps de mettre en place une solution alternative, permettant d'avoir un mécanisme plus ou moins semblable à celui de Windows Phone, c'est à dire faire du binding de ressources directement dans les vues. Le principe est ici de passer par un Converter qui, pour un fichier de ressource et une clef, va renvoyer la ressource localisée.

(lire plus…)