Lorsque l’on propose son application dans plusieurs langues, comme c’est mon cas pour PortraiMatic, la traduction (terme que je préfère au vilain anglicisme “localisation”) est plus complexe que ce qu’Apple laisse entendre. En gros, trois aspects doivent être gérés:

• Ne pas utiliser de chaînes de caractères ”en dur”.
• Il faut les écrire dans un fichier .strings et les charger avec une fonction ou méthode adéquate (NSLocalizedString() ou -NSBundle localizedStringForKey:value:table).
• Adapter la saisie et la présentation des nombres, monnaies et dates (NSNumberFormatters et compagnie)
• Traduire les fenêtres, vues et boites de dialogue, habituellement contenus dans des .xib.

Comme nous allons le voir, ce dernier aspect est délicat.

Solution 1: Traduire les XIB à la mano

Apple propose un concept simple: le bundle de l’application contient un dossier par langue (french.lproj, english.lproj, deutsch.lproj, etc.) qui contient les éléments d’interface utilisateur spécifiques à cette langue. Pour traduire un XIB anglais en français, il suffit donc de copier le .xib de english.lproj dans french.lproj et de le traduire. Cette manière fonctionne bien… la première fois.

Imaginons que vous vouliez ajouter une case à cocher dans votre logiciel:

• vous ajoutez la case dans le xib anglais
• vous créez ses connexions (outlets, actions et bindings)
• et vous refaites le même boulot pour le xib français !

En dehors des risques d’erreur sur les connexions, qui ne peuvent être détectées qu’à l’exécution, c’est un travail rébarbatif, à tel point qu’il vaut mieux repartir des xib anglais et tout retraduire. C’est ce que je faisais jusqu’à récemment.

Un autre problème est que si vous voulez faire traduire le logiciel, vous ne pouvez pas demander au traducteur d’utiliser Interface Builder pour modifier le xib lui-même. Non seulement, c’est compliqué, mais il risque de casser quelque chose. Vous devez lui fournir un simple fichier texte, ce qui nous amène à la…

Solution 2: Extraire les chaînes

C’est la solution que j’utilise actuellement pour PortraiMatic. Je me suis inspiré de la technique exposée par Philippe Casgrain:

1) un outil en ligne de commande, ibtool, extrait les chaînes de caractères du xib anglais et les écrit dans un fichier .strings.

ibtool --export-strings-file English/MainMenu.strings ../English.lproj/MainMenu.xib

Voici un extrait du fichier .strings produit:

/* Class = "NSMenuItem"; title = "About PortraiMatic"; ObjectID = "58"; */ "58.title" = "About PortraiMatic"; /* Class = "NSMenu"; title = "File"; ObjectID = "81"; */ "81.title" = "File";

2) le traducteur traduit le fichier .strings

/* Class = "NSMenuItem"; title = "About PortraiMatic"; ObjectID = "58"; */ "58.title" = "À propos de PortraiMatic"; /* Class = "NSMenu"; title = "File"; ObjectID = "81"; */ "81.title" = "Fichier";

3) ibtool recompose le xib français en remplaçant les chaînes traduites:

ibtool --import-strings-file French/MainMenu.strings --write ../French.lproj/MainMenu.xib ../English.lproj/MainMenu.xib

Philippe Casgrain propose d’extraire les chaînes à chaque build (en ajoutant une ”Script Build Phase” à la ”Target” sous XCode). C’est une bonne idée car votre logiciel de gestion de version va vous alerter d’une modification des fichiers .strings, qu’il faudra renvoyer au traducteur.

Par contre, il suggère aussi de recomposer les XIB traduits à chaque build: je ne le fais pas, car le build s’en trouve allongé, alors que ça n’agit que quand le fichier .strings vient d’être traduit.

Cette technique a l’avantage d’être simple à mettre en œuvre, mais pose encore deux problèmes:

• les objets de l’IHM ne sont pas redimensionnés; or on sait que l’Anglais est souvent plus concis que le Français ou l’Allemand. Il faut donc prévoir de la marge dans les dimensions lors de l’élaboration des XIB anglais. Ce n’est pas toujours esthétique: il reste deux ou trois boutons que je redimensionne à chaque livraison.
• les XIB sont volumineux, et l’application prend de l’embonpoint à chaque langue ajoutée. C’est particulièrement pénalisant pour une appli iPhone.

Solution 3: Traduire au chargement du NIB

Cette solution a été exposée par Axel Péju, l’auteur de Squirrel (et accessoirement gagnant d’un Apple Design Awards pour la version Mac), lors de sa présentation au dernier Cocoa Heads parisien. L’idée est simple: il suffit de mettre toutes les chaînes de caractères qui apparaissent à l’écran dans des fichiers .strings. Quand on charge un NIB, on remplace alors le texte de chaque objet par le code.Pour redimensionner les objets, on appelle leur méthode -sizeToFit pour que leur taille s’adapte au texte affiché.

Cette technique résout tous les problèmes exposés précedemment: il n’y a plus qu’un seul XIB, et les chaînes peuvent être fournies directement aux traducteurs. Elle possède aussi un avantage: le traducteur peut essayer lui-même l’application traduite: il n’a qu’à glisser les fichiers .strings traduits dans le dossier .lproj qui correspond à sa langue.

Ceci dit, le travail est important, puisqu’un objet contrôleur doit posséder des outlets vers tous les objets qui affichent du texte, même si ce sont de simple libellés, et faire les appels correspondant.

Solution 4: Traduire (automatiquement) au chargement du NIB

Voici une solution à laquelle j’avais pensé; Guillaume Cerquant m’a dit qu’il l’utilisait. L’idée est que chaque élément d’IHM du XIB à traduire a son titre qui commence par un astérisque (par exemple). Lors du chargement du XIB, on parcourt la hiérarchie des vues en entier: si le titre de la vue commence par “*”, on va chercher le titre dans un fichier .strings et on remplace le titre. Il me semble que cette technique est un bon compromis: à la fois assez légère à mettre en œuvre, tout en conservant les qualités de la solution 3.