Pourquoi les ressources de chaîne sont-elles généralement conservées à l'extérieur du code et non à l'intérieur du code?

18

Généralement, sur de nombreuses plates-formes, j'écris mes ressources de chaîne dans un fichier .resx ou .xml, puis je les utilise en utilisant une approche dépendante de la plate-forme.

Autrement dit, sur iOS, je les obtiens via NSBundle.MainBundleet en utilisantContext.Resources sur Android.

Quels sont les avantages de cette approche, et pourquoi ne pas l'avoir directement accessible dans le code, par exemple:

  1. Dans un projet multiplateforme, n'importe quelle plateforme peut y accéder directement, sans intégration.

  2. Il n'y a pas de soucis lors de la construction pour savoir si les ressources ont bien été construites.

  3. Le codeur peut utiliser des fonctionnalités telles que la gestion multilingue

Pour faire court: quelle est la raison pour laquelle les ressources de chaîne sont structurées de cette façon?

[Éditer]

Disons que mon fichier fait partie d'un projet "core" partagé entre d'autres projets. (Pensez à une structure de fichiers de projet multiplateforme PCL.)

Et supposons que mon fichier soit totalement similaire à un fichier .resx / .xml, ressemblant à ceci (je ne suis pas un pro en xml, désolé!): Paramètres Paramètres

Donc, il s'agit essentiellement d'un xml personnalisé, où vous pointez sur la clé / langue pour obtenir la chaîne appropriée.

Le fichier ferait partie de l'application, tout comme vous ajoutez n'importe quel fichier accessible dans une application, et le système pour accéder aux ressources de chaîne, codées à l'aide de PCL. Cela ajouterait-il des frais généraux aux applications?

cross-platform resources internationalization Léon Pelletier
la source
doublon possible de l' internationalisation: à quoi penser?
moucher
6
Non, mes préoccupations ne concernent pas l'internationalisation, mais plutôt l'architecture et la multiplateforme, désolé.
Léon Pelletier
1
Cette question peut être généralisée à n'importe quel type de ressource, vraiment, même avec une facilité de localisation / internationalisation mise à part. Quels sont les avantages de garder toute sorte de ressource séparée du code? Pourquoi les images ou les fichiers audio ne sont-ils généralement pas codés dans la source sous forme de chaînes binaires? (Les URI de données existent bien sûr, mais ne sont généralement pas pratiques pour les fichiers volumineux). D'autres ont déjà fourni de très bonnes réponses, mais je voulais simplement souligner que les chaînes lisibles par l'utilisateur ne sont pas le seul type de ressource qui tire un avantage de son externalisation.
JAB

Réponses:

38

Localisation et internationalisation,

Garder les chaînes externes leur permet de changer (lire: traduit) sans avoir besoin de recompiler (juste un nouveau lien au maximum, et simplement déposer dans un nouveau dossier au mieux).

monstre à cliquet
la source
Cette reconnexion vs recompilation est une bonne raison, merci.
Léon Pelletier
2
Toujours la seule personne à avoir compris la question.
Léon Pelletier
3
@ratchetfreak c'est une mauvaise forme d'accepter trop tôt (dans les heures qui comptent certainement.) Ne donne pas le temps aux autres réponses de bouillonner. C'est simple, précis et précis ... mais quelqu'un pourrait apporter une réponse plus complète et plus détaillée demain (ou le mois prochain d'ailleurs).
WernerCD
3
Extra: Il peut être correct pour un traducteur de modifier un fichier XML, mais ne les laissez jamais
jouer du
Maintenant, la question est: "Cette réponse s'applique-t-elle toujours aux langues interprétées?". Je demande parce qu'il n'y aurait pas de reconnexion ou de recompilation.
Thomas Eding
10

Si vous avez un fichier qui contient uniquement les ressources de chaîne, vous pouvez donner le fichier de ressources à une agence de traduction ou quelque chose comme ça et obtenir une traduction. Je suppose que vous pouvez imaginer à quel point cela pourrait devenir difficile si vous deviez donner beaucoup de fichiers de code à un profane pour faire une traduction (en plus de ne pas vouloir donner votre code à qui que ce soit).

Flo
la source
2
Eh bien, il n'y a pas de différence entre un fichier inclus dans le projet et un fichier de ressources. Le problème n'est pas là.
Léon Pelletier
Je parle d'inclure les ressources directement dans le code, puis de tout gérer dans le programme, il est donc plus convivial pour PCL / multiplateforme.
Léon Pelletier
2
si vous avez un fichier "code" avec toutes vos ressources de chaîne (définition de dictionnaire ou quelque chose comme ça) et rien d'autre dedans .. eh bien, c'est essentiellement un fichier de ressources (mais un pour une seule plate-forme, comme par exemple. android ne le fera pas prendre n'importe quel code objectif-c). S'il contient un autre code ou s'il est réparti sur plusieurs fichiers, il est plus difficile d'obtenir une traduction externe. Dans une vue multiplateforme, un format texte comme xml a l'avantage que vous pouvez lire et utiliser sur n'importe quelle langue / plate-forme (mais vous devrez peut-être y mettre du travail)
Flo
7

En plus de l'internationalisation / localisation, la séparation de chaînes de texte comme celle-ci permet également à un relecteur de soumettre des corrections d'orthographe / grammaire / ponctuation qui sont isolées messages.${LOCALE}, sans avoir à toucher à un véritable fichier de code source. Vous pouvez avoir un black-out sur les modifications de code, mais acceptez ces corrections de texte. Si vous acceptez des modifications simultanées à la fois du code et des messages, les conserver séparés facilite la fusion des correctifs, à condition que les modifications de code ne redéfinissent aucun message qui existait lors de la vérification du correcteur messages.en_US.

De plus, selon la façon dont il est implémenté, il peut même ne pas être nécessaire de relier l'application. Le code peut simplement saisir la ligne 138 de messages.${LOCALE}pour un message particulier, le numéro de ligne étant déterminé au moment de l'exécution.

Monty Harder
la source
0

C'est juste la façon dont votre langue / plateforme a décidé d'implémenter la localisation des chaînes. Toutes les approches de localisation nécessitent une sorte de fichiers de ressources externes pour obtenir les traductions. Le principal problème est la façon dont vous maintenez ces ressources.

Il semble que vous ayez besoin de gérer ces fichiers de ressources manuellement , ce qui peut représenter un lourd fardeau. Cela complique également le partage de chaînes répétées. Et devoir le faire lorsque vous expédiez actuellement une seule langue est encore plus un fardeau.

Une alternative courante est l' approche GNU Gettext qui consiste simplement à baliser les chaînes traduisibles dans le code source et à extraire automatiquement ces chaînes dans des fichiers PO standard qui fonctionnent bien entre plusieurs plateformes et plusieurs langues. Du point de vue du développeur, il bat la maintenance manuelle des fichiers de ressources XML tous les jours.

René Saarsoo
la source