Rétro-compatibilité
tablier
Membre
Il y a quelques temps déjà , un adhérent se plaignait que les traducteurs vérolaient les fichiers .strings et qu'il n'y avait rien pour vérifier leur syntaxe. A l'époque, j'avais trouvé ce qui suit:
Je ne sais plus ou j'ai trouvé les clefs kCFPropertyListOldStyleParsingError et NSDebugDescription. J'ai essayé cette méthode sous 10.5, 10.6, 10.7 et 10.8. Elle marche sous toutes les versions d'OSx! Donc, que dire de la rétro-compatibilité, surtout lorsque les documentations ne citent plus les clefs en question. Ou bien est-ce plutôt quelque chose que les développeurs Apple se gardent sans le dire.
Pour ceux qui voudraient essayer, sachez que l'erreur est souvent trouvée à la ligne qui la suit, et deux ou trois erreurs qui se suivent peuvent être ignorées. Cela tient aux régles de syntaxe des fichiers .strings qui sont peu contraignantes. Exp:
"un" = "deux-un"
"trois" = "boaf" ; /* l'erreur est trouvée sur cette ligne */
"un" = "deux-un ;
trois = boaf" ; /* aucune erreur n'est trouvée */
qui retourne nil si aucune erreur n'est trouvée et retourne l'erreur trouvée dans les autre cas: exp: "Missing ';' on line 218".NSError *bing = nil ;
NSData *essaye = [NSData dataWithContentsOfFile:fichier options:NSDataReadingUncached error:&bing] ;
[NSPropertyListSerialization propertyListWithData:essaye options:NSPropertyListImmutable format:NULL error:&bing] ;
if (bing!=nil)
return [[bing [/color][color=#401f7d]userInfo[/color][color=#000000 objectForKey:@kCFPropertyListOldStyleParsingError] userInfo] objectForKey:@NSDebugDescription] ;
return nil ;
Je ne sais plus ou j'ai trouvé les clefs kCFPropertyListOldStyleParsingError et NSDebugDescription. J'ai essayé cette méthode sous 10.5, 10.6, 10.7 et 10.8. Elle marche sous toutes les versions d'OSx! Donc, que dire de la rétro-compatibilité, surtout lorsque les documentations ne citent plus les clefs en question. Ou bien est-ce plutôt quelque chose que les développeurs Apple se gardent sans le dire.
Pour ceux qui voudraient essayer, sachez que l'erreur est souvent trouvée à la ligne qui la suit, et deux ou trois erreurs qui se suivent peuvent être ignorées. Cela tient aux régles de syntaxe des fichiers .strings qui sont peu contraignantes. Exp:
"un" = "deux-un"
"trois" = "boaf" ; /* l'erreur est trouvée sur cette ligne */
"un" = "deux-un ;
trois = boaf" ; /* aucune erreur n'est trouvée */
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
et ou sont définies ces clefs?
Ce n'est pas explicitement documenté, à ma connaissance. Il faut farfouiller dans le code source pour trouver ces trucs la.
Voir les "Build Rules" que tu as dans un projet Xcode quelconque par défaut, la Build Rule associé aux fichiers ".strings".
Du coup, pour valider si un fichier ".strings" est correct, normalement quand tu le convertis en PLIST Binaire (soit via du code en Objective-C avec NSPropertyListSerialization & co, soit via l'outil en ligne de commande "plutil") l'erreur avec la ligne correspondante doit remonter tout pareil qu'elle remonte dans Xcode.
Je suis sous 10.6 avec Xcode 3.2.6. qui ne remonte aucune erreur sur les .strings buggués.
J'intègre quand même la fonction dans Localise, et avec la comparaisons de .strings de différentes langues je ne devrais pas rater d'erreur.
Quand aux clefs kCFPropertyListOldStyleParsingError et NSDebugDescription elles existent et marchent même si elles ne sont pas documentées. Alors, que demande le peuple!
Je viens de tester les clefs "Officielles". La seule erreur que j'obtiens (pour la même erreur) est:
missing semicolon in dictionary sans numéro de ligne.
Et mon premier essais avec plutil montre que les erreurs, il s'en tamponne le coquillard avec une patte d'escargot.