NSLocalizedString
iDevKeno
Membre
Bonsoir,
Je développe actuellement une application qui devra être disponible en 3 langues.
J'utilise actuellement NSLocalizedString pour gérer cet aspect, sans problème.
J'arrive à un moment où je pose la question suivante :
Jusqu'où peut-on utiliser NSLocalizedString pour stocker les différentes valeurs ?
Mon application contiendra environ une quarantaine d'article (texte) différents. Pour les 3 langues, cela représente + d'une centaine d'article. A savoir qu'un article varie entre 150 mots et 500 mots. Est-ce raisonnable de tout stocker dans Localized.string ?
J'ai pensé à utiliser une petite base sqlite3 avec une table contenant les langues et une autre contenant les articles et chargé au lancement de l'application les bonnes valeurs selon un test.
Je tiens à préciser que l'application ne permet pas d'ajouter de nouveaux articles.
Merci d'avance, en espérant avoir été assez clair.
Je développe actuellement une application qui devra être disponible en 3 langues.
J'utilise actuellement NSLocalizedString pour gérer cet aspect, sans problème.
J'arrive à un moment où je pose la question suivante :
Jusqu'où peut-on utiliser NSLocalizedString pour stocker les différentes valeurs ?
Mon application contiendra environ une quarantaine d'article (texte) différents. Pour les 3 langues, cela représente + d'une centaine d'article. A savoir qu'un article varie entre 150 mots et 500 mots. Est-ce raisonnable de tout stocker dans Localized.string ?
J'ai pensé à utiliser une petite base sqlite3 avec une table contenant les langues et une autre contenant les articles et chargé au lancement de l'application les bonnes valeurs selon un test.
Je tiens à préciser que l'application ne permet pas d'ajouter de nouveaux articles.
Merci d'avance, en espérant avoir été assez clair.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je te conseille d'utiliser la table Localisable.strings (et donc NSLocalizedString) uniquement pour ton interface (titre des boutons, etc), et de séparer le texte associé à tes articles autre part, pour ne pas tout mélanger, en effet c'est une bonne idée.
A partir de là , plusieurs solutions s'offrent à toi :
L'idée est donc de créer un fichier "Articles.plist", un PLIST contenant un NSArray à la racine, chaque élément du NSArray étant un de tes articles. Donc soit directement un NSArray de NSStrings, si tes articles ce n'est QUE du texte, soit un NSArray de NSDictionary, te permettant de stocker plusieurs éléments associés à un article (titre, texte, date, ... une clé par élément dans ton NSDictionary)
Une fois que tu as un joli PLIST contenant le tableau de tous tes articles, il te suffit de le charger avec [NSArray arrayWithContentsOfFile:plistPath], où plistPath est le chemin vers le PLIST récupéré via [[NSBundle mainBundle] pathForResource:@Articles ofType:"plist"].
Or la magie de cette méthode de NSBundle fait que si le fichier est localisé, il va aller chercher le bon fichier en fonction de la langue. Tout comme NSLocalizedString le fait.
Au final tout comme tu as 3 versions de Localisable.strings, une par langue, tu auras donc 3 versions de ton Articles.plist, une par langue. Chaque PLIST aura exactement la même structure, les mêmes articles... mais chacun dans la bonne langue. Et au final toi tu charges le bon PLIST (enfin iOS va choisir automatiquement le bon pour toi quand tu lui demandes le path) et récupère un NSArray d'articles que tu peux manipuler à ta guise.
En plus cette solution est bien plus flexible que de mettre tes articles dans un fichier ".strings" (Localizable.strings ou un autre), car tu récupères directement un tableau (NSArray) de tes articles. SI tu veux changer leur ordre ça se fait facilement dans le PLIST, si tu veux en rajouter c'est pareil, facilement éditable, etc...
Je me permet de relancer mon sujet. Suite à la proposition d'AliGator (encore merci) que j'ai implémenté, je rencontre un problème liée de nouveau à la localisation.
J'ai donc crée un Property List contenant un Array de NSDictionnary contenant divers champs lié à l'article que je reconstruisait par code et que j'affichais à l'aide d'une UIWebView.
J'ai localisé le Plist et tout fonctionne correctement (les titres changent avec la langue) etc..
Mon problème survient sur le PDF.
Jusque là , je stockais mes articles au format texte et reconstruisait l'article avant d'afficher.
J'ai changé de méthode : j'ai transformé mes articles texte/image en PDF.
Mes articles sont au format PDF et en 3 langues, j'ai donc essayé d'implémenté une version localisé de celui-ci.
A partir de là plus rien ne fonctionne. Dès que j'ai localisé un PDF, impossible de trouver l'article : mon uiwebView reste blanc.
J'ai affiché (NSLog) le chemin dans le bundle de mon Plist qui lui est correct (localized).lproj/fichier.plist. Par contre, lorsque j'affiche le chemin du PDF à charger, il regarde dans le répertoire racine (AppLocalized/monPdf.pdf) au lieu de regarder dans le dossier de la langue, du coup il ne le trouve pas.
J'aurai voulu savoir si c'était normal ? Est-il impossible de localisé un fichier PDF où ai-je loupé une étape ?
Merci d'avance
iDevKeno
Version éditée
Je te conseille de faire un clean du projet et de supprimer et réinstaller l'application pour être sûr que la version non localisée du ficherait bien été retirée du bundle.
Suite à ta réponse, j'ai regardé mon code et j'ai trouvé l'erreur.
Pour le chargement du Property List, j'utilise bien
Tandis que pour les PDF, j'utilisais
J'ai remplacé par pathForResource, et ça fonctionne.
Merci beaucoup, et encore désolé du dérangement pour si peu