Comment organiser les ressources de chaîne de localisation?

Nous développons une grande application, composée de nombreux petits packages. Chaque package possède son propre ensemble de fichiers de ressources pour la localisation.

Quelle est la meilleure approche pour organiser et nommer les chaînes de localisation?

Voici mes pensées jusqu'à présent:

Gestion des doublons

Le même texte (par exemple, "Code postal") peut apparaître plusieurs fois dans un package donné. L'instinct de programmation (DRY) me dit de créer une ressource de chaîne unique partagée par toutes les occurrences .

Là encore, un traducteur peut vouloir choisir une traduction longue ("Postleitzahl") à certains endroits et une plus courte ("PLZ") à des endroits avec moins d'espace. Ou nous pouvons décider d'ajouter un deux-points à certaines occurrences ("Code postal:"), mais pas à d'autres. Ou nous pouvons exiger une capitalisation différente ("code postal") à certains endroits. Tous ces arguments pointent vers la création d' une ressource par utilisation, même si leur contenu est identique .

Appellation

Si nous visons à éliminer les doublons, il est logique de nommer les ressources par contenu , peut-être en faisant allusion au type d'utilisation via le préfixe. Nous pouvons donc avoir labelOK= "OK" , messageFileTooLarge= "Le fichier dépasse la taille maximale du fichier." et labelZipCode= "Code postal" .

La dénomination par contenu présente l'avantage de gérer naturellement les arguments de format: la ressource messageFileHas_0_MBWhileMaximumIs_1_MBprend clairement deux arguments de formatage, la taille réelle du fichier et la taille maximale du fichier.

Cependant, si nous autorisons les doublons, la dénomination en fonction du contenu n'a aucun sens. Afin d'obtenir des noms de ressources uniques, nous devons en quelque sorte inclure le lieu d'utilisation dans le nom de la ressource. Cela fonctionne pour les contrôles graphiques, bien que les identifiants aient tendance à être un peu longs: fileSelectionConfirmationButtonText= "OK" , customerDetailsTableColumnZipCode= "Zip Code" . Cependant, pour les fichiers de code non visuels, cela devient plus difficile. Comment nommez-vous une utilisation spécifique d'une chaîne si vous ne savez pas où elle sera finalement affichée? Par fichier de code et nom de fonction? Cela me semble plutôt maladroit et cassant.

Dans l'ensemble, je penche pour autoriser les doublons, mais j'ai du mal à trouver un schéma de nommage cohérent qui prend en charge cela.

Edit: Cette question a deux aspects: comment organiser les ressources (DRY vs doublons) et comment les nommer . Jusqu'à présent, les réponses se sont concentrées sur le premier aspect. J'apprécierais quelques commentaires concernant les conventions de dénomination!

J'accepterais la duplication chaque fois que vous ne pouvez pas être absolument sûr que la signification est exactement la même dans tous les cas où une certaine chaîne est utilisée.

Même si deux étiquettes contiennent toujours la même chaîne en anglais (ou dans votre langue maternelle), elles ne seront pas nécessairement les mêmes dans toutes les langues. Accepter la duplication peut vous donner (ou plutôt les traducteurs) la flexibilité nécessaire pour gérer de telles situations.

A titre d'exemple: considérons une étiquette "Condition", qui - selon le contexte - pourrait être traduite en "Zustand" ou "Bedingung" en allemand (parmi beaucoup d'autres traductions possibles).

Acceptez certains doublons.

Vous pouvez éviter certaines traductions multiples en créant des contrôles supplémentaires. Par exemple, un CancelButtonet un OKButtonqui contiennent déjà leur texte, et maintenant Annuler / Abbrechen OK / OK doivent être traduits une seule fois. Mais c'est presque un cas particulier.

C'est ainsi que nous le gérons dans mon entreprise:

Convention de dénomination: nous nommons les étiquettes en les préfixant avec leur classe / section / formulaire / etc. Par exemple loadFile_loadButton, loadFile_fileNameLabel, loadFile_cancelsont toutes les étiquettes appartenant à une charge de dialogue Fichier. Bien que cette convention de dénomination soulignée ne soit pas la plus courante, nous la privilégions par rapport aux conventions plus standard car elle améliore la lisibilité et la "groupabilité": notez à quel point il est facile de voir à quel élément les étiquettes appartiennent et ce que chaque étiquette représente, par rapport aux étiquettes nommé loadFileLoadButton, loadFileNameLabelet loadFileCancel. Vous pensez peut-être que la différence n'est pas si grande, mais lorsque vous avez des milliers d'étiquettes, l'effet composé en vaut la peine.

Commentaires d'en-tête: en plus de préfixer les noms d'étiquette, nous ajoutons également des commentaires «en-tête» aux fichiers de ressources pour définir clairement les groupes d'étiquettes. De cette façon, quelqu'un qui souhaite modifier ou ajouter des étiquettes spécifiques liées à une classe / section / formulaire / etc peut trouver toutes les étiquettes liées à cet élément particulier en un seul endroit, sous un en-tête, et peut facilement ajouter ou modifier des étiquettes facilement sachant qu'ils ne casseront pas les traductions pour d'autres éléments (à mon humble avis, c'est aussi un point très fort sur la raison pour laquelle vous devez autoriser la duplication).

Des doublons "justifiés" sont souhaitables: Comme mentionné ci-dessus, ces pratiques conduiront définitivement à des doublons d'étiquettes, mais nous ne voyons aucun problème à cela (plus sur la façon de gérer cela dans les outils du métier).

Comme d'autres l'ont souligné, une étiquette dans une langue peut être traduite de deux manières différentes ou plus dans d'autres langues selon les contextes où elles sont présentées. Si vous "unifiez" les étiquettes, le traducteur aura beaucoup de mal à trouver une seule étiquette qui s'adapte à tous les contextes où elle se trouve. Donc, comme nous le voyons, autoriser les doublons "justifiés" aide à améliorer la qualité de la localisation, tant qu'ils ne se réfèrent pas à la même chose dans le même contexte (c'est le sens de "justifié").

Outils du métier: afin d'être aussi efficace que possible lors de vos traductions, vous pouvez créer votre propre outil qui recherche des étiquettes similaires qui existent dans vos bundles, et proposer leurs traductions comme valeurs par défaut pour les nouvelles étiquettes, ou vous pouvez même utiliser des services existants comme celui-ci , qui fournissent des outils comme celui que je viens de mentionner, ce qui rend la traduction de nouvelles étiquettes un jeu d'enfant (d'autant plus si elles sont répétées plusieurs fois, car l'outil vous offrira plusieurs options de traduction par défaut pour les nouvelles étiquettes ).

Pour résumer: la duplication justifiée et le regroupement des étiquettes de manière contextuelle aident vraiment les traducteurs à faire leur travail. Temps fort. Pensez-y: avoir du contexte aide grandement le traducteur à sélectionner la traduction appropriée. Et autoriser les doublons "justifiés" élimine le conflit d'avoir à sélectionner une traduction qui correspond mal à certains contextes (mais qui est de toute façon la meilleure solution).

J'espère que ça aide!

Lorsque j'ai fait cela dans le passé, nous avons emprunté la route du fichier de ressources contenant des phrases complètes. Si la même phrase exacte était utilisée à plusieurs reprises, mais si ce n'était que des mots individuels à l'intérieur d'une phrase, ces mots seraient dupliqués.

Nous étions liés à un cadre où le fichier de ressources contenait juste une liste de phrases en anglais suivies de la traduction (avec quelques données d'indexation à la fin pour une recherche rapide).

Pour les petites invites ou boutons de données, comme un nom de champ "Code postal" ou un bouton "OK", il stockerait la chaîne "Code postal" suivie de la traduction et l'utiliserait partout où cette chaîne complète était requise. Mais (sauf si nous avons rompu manuellement une chaîne) ne l'utiliserait pas pour le "code postal" apparaissant dans une phrase.

En utilisant votre exemple de code postal, si vous essayez de le traduire seul et de le remplacer dans toutes les phrases qui l'utilisent, vous obtiendrez une très mauvaise traduction.

Par exemple, «Code postal doit être entré» peut nécessiter la traduction de l'équivalent littéral de «Code postal entré doit être» dans une autre langue. Si vous coupez une phrase, vous n'obtenez pas cette inversion de mots requise dans une autre langue.

C'est pourquoi certaines traductions mal faites en anglais semblent si ridicules, la personne qui le fait a simplement traduit les mots individuels, pas la phrase entière.

Nous avons toujours trouvé préférable de traduire des phrases dans leur ensemble, sans les décomposer. Nous avions des espaces réservés pour les données qui devaient être insérées (par exemple, "Numéro de pièce @ 1 est redondant") et le traducteur pouvait déplacer l'espace réservé à la position souhaitée pour une bonne traduction.

Cependant, nous avons constaté qu'autoriser des lieux qui utilisaient exactement la même phrase, ou la même invite de données ou la même étiquette de bouton, etc., était bien pour partager des traductions. Cela n'a jamais posé de problème et a fait gagner du temps / de l'argent au traducteur.

Votre réflexion sur la dénomination est bonne.

Objectifs

• Définissez une étiquette commune (c'est-à-dire le nom de la variable) pour le texte localisé.
• L'étiquette doit être «de la taille d'un esprit». C'est ... aussi court que pratique tout en étant sans ambiguïté.
• Les étiquettes doivent suivre un format cohérent afin de maximiser la prévisibilité et le rappel.

la mise en oeuvre

• Réduisez la charge cognitive grâce à l'utilisation cohérente d'abréviations bien connues (c.-à-d. Msg = message, lbl = label, btn = button, ...)
• Les outils présentent les variables / étiquettes dans des listes alphabétiques, la recherche humaine est donc préférable lorsque les étiquettes associées se regroupent. Rendez les noms hiérarchiques du plus général au plus spécifique. (c'est-à-dire msgFileMissing, msgFileSaved, msgFileDeleted).
• L'anglais est une langue ordonnée verb-nom. Beaucoup (la plupart?) D'autres langues sont des noms-verbes. Le nom-verbe fonctionne mieux pour le regroupement hiérarchique.