›

Rétro-compatibilité

tabliertablier Membre
mars 2013 modifié dans Objective-C, Swift, C, C++ #1
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:
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 ;
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".

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 */

Réponses

  • SystemSystem
    #2
    Il me semble que la dernière version d'Xcode indique une erreur de compilation ainsi que la ligne en question du Localizable.
  • tabliertablier Membre
    mars 2013 modifié #3
    Oui, mais je ne suis pas dans Xcode, je suis dans mon programme "Localise". Je fais de la vérification de .strings et de traductions.

    et ou sont définies ces clefs?
  • jpimbertjpimbert Membre
    #4
    Ce sont des trucs que les développeurs Apple diffusent sur opensource.apple.com.

    Ce n'est pas explicitement documenté, à  ma connaissance. Il faut farfouiller dans le code source pour trouver ces trucs la.
  • AliGatorAliGator Membre, Modérateur
    #5
    Normalement quand Xcode compile ton projet, pour les fichiers ".strings" il passe la compilation du .strings (qui en fait n'est rien d'autre qu'un PLIST au format ASCII) en PLIST binaire.

    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.
  • tabliertablier Membre
    mars 2013 modifié #6
    Je ne connais pas plutil, je vais aller voir ça et faire quelques essais.

    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.
Connectez-vous ou Inscrivez-vous pour répondre.