Base Localization
iLandes
Membre
Bonjour à tous,
Je suis en train de tenter de localiser mes petites applications que j'ai créé en grande partie avec votre aide. J'ai effectué des recherches sur le forum et décidé d'utiliser Base Localization.
La solution semble efficace et assez facile à mettre en oe“uvre. Mais une question me vient à l'esprit. Est-on obliger de traduire suivantes :
/* Class = "NSMenuItem"; title = "Show All"; ObjectID = "150"; */
"150.title" = "Show All";
/* Class = "NSMenuItem"; title = "Stop Speaking"; ObjectID = "195"; */
"195.title" = "Stop Speaking";
/* Class = "NSMenuItem"; title = "Start Speaking"; ObjectID = "196"; */
"196.title" = "Start Speaking";
/* Class = "NSMenuItem"; title = "Copy"; ObjectID = "197"; */
"197.title" = "Copy";
/* Class = "NSMenuItem"; title = "Select All"; ObjectID = "198"; */
"198.title" = "Select All";
/* Class = "NSMenuItem"; title = "Cut"; ObjectID = "199"; */
"199.title" = "Cut";
/* Class = "NSMenuItem"; title = "Delete"; ObjectID = "202"; */
"202.title" = "Delete";
/* Class = "NSMenuItem"; title = "Paste"; ObjectID = "203"; */
"203.title" = "Paste";
/* Class = "NSMenu"; title = "Edit"; ObjectID = "205"; */
"205.title" = "Edit";
/* Class = "NSMenuItem"; title = "Undo"; ObjectID = "207"; */
"207.title" = "Undo";
Il me semble que ces chaines de caractères doivent déjà être localisée ici ou là et qu'il n'est pas judicieux de les redéfinir soit même.
Quelqu'un à -t-il une idée pour que je puisse aller plus vite et ne traduire que les quelques mots spécifiques à mon application.
D'avance merci de vos réponse
Cordialement
Seb
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Pour ta question, même si ce sont des textes standard, il n'y a rien d'automatique à ma connaissance.
Il doit pourtant exister des constantes quelques part avec tout ce vocable : Fichier, Edition, Copier, Coller, etc.
- Les fichiers strings sont illisibles avec cette méthode : les noms des clés sont les ObjectIDs des objets d'un XIB. Va donner ça ensuite à un traducteur, il va être super content pour comprendre à quoi correspond la chaà®ne "205.title" dans ton appli concrètement. A la limite là nous on voit dans le commentaire que ça parle de "NSMenu" on finit par se douter qu'il s'agit d'un article de menu, mais le traducteur lui son boulot c'est traduire pas développer et NSMenu ça lui dit rien et c'est normal. Et puis y'a des cas bien plus complexes quand le commentaire est loin d'être explicite et est beaucoup plus obscure que ça.
- Base Localization t'impose un fichier .strings par fichier XIB. Si tu utilises Storyboard et n'a qu'un seul gros storyboard dans toute ton app, tu vas t'en sortir car tu auras alors qu'un seul .strings. Mais ce cas là est assez rare, surtout pour des applications conséquentes, en général on a un voire plusieurs Storyboards et plusieurs XIBs à gauche à droite. Or si un terme générique à ton application (par exemple les termes "Plat", "Recette", "Ingrédients"... si tu fais une application de cuisine) revient à plusieurs endroits dans différents XIBs/Storyboards, tu vas être obligé de répéter sa traduction dans chaque fichier .strings !
Et j'en passe, mais ce sont mes principales raisons qui me font ne pas trouver Base Localization très pratique.Il faut l'avouer, certes Apple a un peu progressé sur ce sujet par rapport au cas d'avant où il n'y avait même pas Base Localization et que chaque XIB était dupliqué pour chaque langue, mais ils ont encore des progrès à faire pour rendre cela plus générique et facile.
C'est pour cela que pour toutes mes applications iOS, j'utilise (et nombreux sont ceux qui l'utilisent aussi, tous les projets de ma boite entre autres) OHAutoNIBi18n qui permet de traduire à la volée tous les éléments d'un XIB ou d'un Storyboard (sans avoir à ajouter d'IBOutlet sur chaque élément pour le traduire : ça se fait automatiquement à la volée), tout en te permettant de choisir le nom des clés (plutôt que "205.title" tu peux choisir par exemple "menu.edit.title" qui est plus explicite), et surtout tout en te permettant de tout regrouper dans un seul fichier .strings, donc même si tu as des termes comme "Plat" ou "Ingrédient" utilisés un peu partout dans plusieurs XIB tu n'as à les traduire qu'une seule fois.
Mon composant OHAutoNIBi18n n'est pour l'instant compatible que iOS. Mais il serait très simple de le rendre compatible OSX (j'ai juste jamais pris le temps car ça fait une éternité que j'ai pas développé d'appli OSX) en adaptant toutes les méthodes qui pointent sur des UIButton et UILabel vers leurs équivalents NSButton/NSTextField/... sous OSX. Il me semble même que Céroce avait déjà fait ce genre de transposition de son côté pour donner naissance au petit frère de OHAutoNIBi18n pour OSX ?
Il existe différents outils, certains gratuits et d'autres non (j'en ai fait un dont la version 4 est béta).
Le principe de ces outils est:
1- Extraction des textes
2- traduction soit à la main, soit en utilisant des dictionnaires de phrases (et non de mots).
3- fabrication des nouveaux xib en utilisant les xib d'origines et les textes traduits.
L'outil d'apple est AppleGlot. J'ai trouvé que c'était une usine à gaz peu pratique.
Sur l'AppStore il existe différentes applications dont iLocalize (fait par un Suisse. Non, non pas un petit).
Ma version béta de Localise est ici. Attention, l'aide n'est pas à jour, j'ai ajouté 3 fonctions non décrites et à partir de 10.7 l'extraction des textes dans les nib compilés ne marche pratiquement pas! (pas essayé sous 10.9!!)
Exact, j'avais écrit CePolyglotte.
Malheureusement, je ne l'ai pas mis à jour depuis longtemps (il suscite peu d'intérêt) et il manque la gestion de certains contrôles.
Le fonctionnement est assez différent de celui d'OHAutoNIbi18n, parce que:
1) je n'avais pas regardé comment Ali avait fait
2) certaines API n'exist(ai)ent pas sous OS X. Par exemple, il me semble qu'il n'était pas possible d'accéder aux objets du nib sans tirer des outlets.
3) sur OS X, il est intéressant d'avoir un fichier .string par xib, parce que les xib sont bien plus touffus.