Des astuces à la localization
Bonjour à tous,
c'est un sujet sûrement déjà évoqué, mais dont je n'arrive pas à retrouver la trace via la recherche.
Je me pose des questions quant aux principes de localizations d'applications.
Pour l'instant je suis parti sur un fichier que j'ai toujours appelé "DEFINES.h".. il y est bourré de #define en tout genre, (notamment pour les clés de préférences).
J'hésite cependant à y placer aussi la localization. Comme par exemple:
Seulement, à la longue j'ai peur que ça devienne assez monstrueux.
Il semblerait qu'Apple utilise une autre technique qui serait de directement placer NSLocalizedString() un peu partout dans son code comme par exemple
Ainsi le localizable.strings donnerait:
Quelle solution utiliseriez-vous?
c'est un sujet sûrement déjà évoqué, mais dont je n'arrive pas à retrouver la trace via la recherche.
Je me pose des questions quant aux principes de localizations d'applications.
Pour l'instant je suis parti sur un fichier que j'ai toujours appelé "DEFINES.h".. il y est bourré de #define en tout genre, (notamment pour les clés de préférences).
J'hésite cependant à y placer aussi la localization. Comme par exemple:
<br />#define ALERT_QTSTREAMINGERROR_TITLE NSLocalizedString(@"Streaming Error", @"Alert title for a possible streaming error from QuickTime");<br />
Seulement, à la longue j'ai peur que ça devienne assez monstrueux.
Il semblerait qu'Apple utilise une autre technique qui serait de directement placer NSLocalizedString() un peu partout dans son code comme par exemple
<br />[myButton setTitle:NSLocalizedString(@"MYBUTTON_SOMETHING_TITLE", @"Description..")];<br />
Ainsi le localizable.strings donnerait:
/* Description.. */
"MYBUTTON_SOMETHING_TITLE" = "Traduction ici";
Quelle solution utiliseriez-vous?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
En gros, et par langue de localisation 1 dossier "laLangue.lproj" qui contient: des fichiers nib et/ou des fichier .strings. dans la langue "laLangue"
Au chargement de l'application le fichier nib chargé est celui de la langue actuelle indiquée dans les préférences système. Pour les phrases hors nib il existe les méthodes du genre "NSLocalizedStringFromTable(..)" qui vont chercher dans les bons fichiers .strings.
Eventuellement tu télécharges mon vieux tutoriel "Cacao" dans lequel il y a un exemple Français + Anglais. Sinon tu cherches des exemples sur le web il devrait y en avoir.
Et à la fin, il reste un vrai problème: Il faut traduire correctement les phrases dans une langue étrangère, sans faire de contre-sens ou d'erreur. Et ça ce n'est pas de la tarte!!
NB: Tu trouveras la vieille version de Localise en faisant une recherche avec "Utilitaire de localisation"
Mon seul soucis c'est de savoir comment procéder à la mise en place dans le code. Je sais très bien créer un Localizable.strings, le localizer en différentes langues. Le seul "problème" auquel je me heurte c'est à l'utilisation de NSLocalizedString().
Comme je l'ai expliqué à mon premier post, je me demande quelle solution serait la mieux. Faudrait-il utiliser des #define ou directement mettre NSLocalizedString(@SOMETHING,@description) à chaque fois que j'en ai besoin.
Exemple concret, j'ai des boutons sur différentes interfaces qui auront probablement le même titre "Download".
La question est, faut-il que je rajoute #define LOC_BUTTON_ACTION_DOWNLOAD NSLocalizedString(@Download, @Title for the download button) dans mon "DEFINES.h" et donc par la suite de retrouver "Download" = "Download"; dans le localizable.strings.
Ainsi, il me suffirait de faire [myButton setTitle:LOC_BUTTON_ACTION_DOWNLOAD];.
L'autre solution consisterait à faire [myButton setTitle:NSLocalizedString(@DOWNLOAD_ACTION_TITLE, @Description here)]; et cette fois le Localizable.strings aurait "DOWNLOAD_ACTION_TITLE" = @Download;
Je sais pas si c'est clair...
Comme ça j'utilise NSLocalizedString mais avec une version courte T(x) sans mettre les guillemets ni les descriptions etc, plus concis.
Je dirais qu'il n'y a pas de méthode universellement reconnue.
Pour ma part, je sépare les phrases en deux types: celles à localiser et les autres. Ce qui me donne deux fichiers .strings nommés avecLoc.strings et sansLoc.strings. Puis j'écris dans une catégorie de NSApplication, deux méthodes appelées avecLoc et sansLoc. exemple de sansLoc: A noter que sansLoc.strings est sans localisation.
L'appel se fait alors de la même manière dans tout les objets: [NSApp sansLoc:@maclef], ou [NSApp avecLoc:@autreclef]
Je n'utilise les #define que si l'appel est fait un grand nombre de fois.
#define noLoc(A) [NSApp sansLoc:A]
#define wzLoc(A) [NSApp avecLoc:A]
et si l'appel fait toujours référence à la même clef j'utilise un #define spécifique:
#define laHauteur [NSApp avecLoc:@laHauteur]
Probablement que cette méthode ne convient pas à tout le monde et elle est probablement inadaptée pour certain projet.
(ça se fait tout seul à partir du moment où vous incluez mon fichier AutoXibL10n.m dans le projet, donc aucune ligne à rajouter dans votre code c'est top
ça évite effectivement de réécrire NSLocalizedString.... à chaque fois.. Je vais opter pour ça je pense
Merci à vous
Ah bein oui...
Comme j'aime pas multiplier les XIB pour la localisation, je mets des outlets même sur les intitulés de champs de labels pour pouvoir utiliser NSLocalizedString. Mais ça fait + de code, mais moins de Xibs...
Sinon, je mets directement le texte en anglais dans le NSLocalizedString : la vraie clé c'est le texte en anglais. Je n'ai pas besoin de traduire mes strings dans les fichiers anglais... Et si il y a un oubli de strings dans un .strings, au pire, c'est le texte en anglais qui s'affiche, et pas le nom de la clé... qui peut ne vouloir rien dire ?
ça m'arrive aussi, mais c'est parfois un peu longuet!!
ça parait intéressant. si je comprends bien, une seule série de nib/xib et les phrases sont prises dans les fichiers .strings. Est-ce que ça marche également si on change la langue par défaut et que l'on relance l'application sans fermer-réouvrir la session?
J'avais également contacté Guillaume Cerquant qui avais commencé le même principe pour mettre en commun nos idées, et faire un truc propre, et qui marche aussi avec les objets Cocoa/OSX et pas que CocoaTouch/iOS... mais on a juste pas eu le temps de le faire
Mais oui le principe c'est qu'on met la chaà®ne que l'on veut dans le XIB (dans les texts des labels, dans les titres des boutons, tout ça) et quand le XIB est chargé, il passe automatiquement tous ces textes à la moulinette NSLocalizedString (comme si on avait fait un IBOutlet monLabel vers un UILabel, et qu'on faisait par code [tt]monLabel.text = NSLocalizedString(monLabel.text,@";");[/tt] sauf que là on a pas besoin d'avoir des IBOutlets pour tous les éléments)
Y'a un seul petit problème à ce jour avec ce code c'est qu'il n'est pas exécuté dans le simulateur iPhone/iPad (je sais pas pourquoi, la méthode awakeFromNib qui fait tout le boulot magique toute seule, elle n'est pas appelée dans le contexte du simulateur, étrange) donc dans le simu on voit les textes non traduits, mais sur le device aucun souci ça marche direct tout seul...
Bref c'est encore en tests (même si je l'utilise en prod dans l'appli qu'on fait) mais du coup on a gagné du temps pour la i18n !
Très bonne idée, je vais m'en inspirer !
Je fais la même chose, je trouve ça plus clair.
Je faisais ça sur mon premier projet, mais ce n'est pas très propre et surtout source de bugs quand tu travailles sur les versions suivantes qui nécessitent des modifications de textes...