Localized Defaults Values dans un modèle Core Data

berfisberfis Membre
janvier 2014 modifié dans API AppKit #1

Bonjour...


 


J'aurais juré l'avoir fait " si seulement je pouvais me souvenir comment j'avais procédé...


 


J'aimerais traduire les valeurs par défaut dans mon modèle Core Data. Pas les noms d'entités, ni les propriétés (je me demande à  quoi ça pourrait servir de traduire les éléments d'un modèle qui est de toute façon abstrait) mais uniquement la valeur par défaut de certaines propriétés.


 


Si mon entité Client possède l'attribut name qui a comme valeur par défaut "No name", j'aimerais juste une version française de cette valeur, comme "Pas de nom".


 


Je me souviens vaguement que j'avais défini un fichier localisé .strings, nommé d'après mon modèle: si celui-ci s'appelait myDocument.xcdatamodel, il fallait l'appeler myDocumentModel.strings.


 


Mais à  partir de là , je suis perdu:


Où avais-je mis ce fichier .strings ?


Comment est-ce que j'accédais à  "No name" = "Pas de nom";


 


Je suis sûr d'une chose, je n'avais pas sous-classé d'entité, ni d'entityDescription, rien. ça marchait, c'est sûr. Mais j'ai beau googler, je ne trouve rien.


 


ça vous dit quelque chose?


Réponses



  •  


    Je me souviens vaguement que j'avais défini un fichier localisé .strings, nommé d'après mon modèle: si celui-ci s'appelait myDocument.xcdatamodel, il fallait l'appeler myDocumentModel.strings.




     


    Il me semble que ce fichier est utilisé pour localiser les noms d'entités et des propriétés et c'est tout.

  • Oui, c'est tout ce que j'ai pu trouver, et encore une fois je n'en vois absolument pas l'intérêt, vu que l'utilisateur n'a pas accès au modèle. Mais la-dessus, il y a des tonnes d'infos...


    Mais la partie interface, c'est justement le reste: à  quoi bon la possibilité de définir des strings par défaut si on ne peut pas les localiser?
  • Oui, à  part surcharger awakeFromInsert je ne vois pas d'autres solutions.


  • Oui, c'est ce que j'ai fini par faire en désespoir de cause, en utilisant des localized strings ordinaires. Du coup, j'ai ôté mes valeurs par défaut, devenues inutiles, du modèle Core Data. Et bon, gonfler l'application de 2K par langue, ce n'est pas un gros sacrifice.


     


    Mais je continue à  penser que Core Data souffre de lacunes, pour un kit qui a pourtant bien des avantages... Du coup, je comprends presque l'usage de "super-kits" comme MagicalRecords...


     


    Bah, de toute façon je programme "comme un porc" (je ne sais plus qui a utilisé cette expression) en truffant mon code de [setValue for Key] donc mon avis vaut ce qu'il vaut.  <_<




  • Oui, c'est tout ce que j'ai pu trouver, et encore une fois je n'en vois absolument pas l'intérêt, vu que l'utilisateur n'a pas accès au modèle.




     


    L'intérêt, si je me souviens bien, c'est pour les mécanismes de validations intégrés à  core data : les messages s'affichent alors avec le nom localisé de l'entité et de l'attribut.


     




    Mais je continue à  penser que Core Data souffre de lacunes, pour un kit qui a pourtant bien des avantages... Du coup, je comprends presque l'usage de "super-kits" comme MagicalRecords...


     




     


    Mouais...

  • J'ai dit presque.


Connectez-vous ou Inscrivez-vous pour répondre.