La notation «<Nom de l'objet>: <quantité>» est-elle acceptable dans la localisation la plus courante?
Cette question a été initialement posée dans la linguistique SE (ce qui n'est pas un bon endroit pour poser ce genre de choses).
La question complète suit
Je suis la directive de localisation de logiciels, qui stipule que tout texte construit doit être construit par la chaîne de format, et non en collant des morceaux ensemble.
Par exemple: pour obtenir la chaîne
Oranges: 50, utilisation'${OBJECT_NAME}: ${QUANTITY}'chaîne, pas variablesobject_name + ': ' + quantity. Il s'agit ici de donner à la personne qui traduira le texte le contrôle total de l'ordre des éléments dans la chaîne.Maintenant, mon collègue insiste sur le fait que dans ce cas particulier avec
<Object name>: <quantity>notation il est OK d'aller de l'avant et de coller les chaînes ensemble.Je soupçonne fortement que ce n'est pas le cas.
S'il vous plaît, aidez-moi avec des exemples de langues populaires où cette notation serait un mauvais style ou pire. (Populaire signifie que nous avons au moins une chance de localiser le logiciel dans cette langue. Cela étant dit, les exemples de langues exotiques sont également les bienvenus.)
Exemple simple: langues de droite à gauche (arabe, hébreu ...) où ils écriraient:
17 : Apples
Vous avez donc deux options. L'option 1 fonctionnera toujours, et l'option 2 fonctionnera généralement - ne fonctionne que si toutes les langues suivent la convention anglaise.
Il se peut que l'option 2 fonctionne, mais vous pourriez tout aussi facilement trouver des langues ou des situations sur la ligne où ce n'est pas une bonne idée. Alors pourquoi choisir l'option 2? Que gagnez-vous à ne pas utiliser les directives de localisation? Je ne soupçonne pas grand-chose.
Vous devez penser "quelle est la meilleure façon de le faire" plutôt que "avec quoi puis-je m'en tirer ne pas faire correctement".
Si vous avez le choix, optez toujours pour ce qui fonctionnera toujours
Le commentaire d'André est juste. Il existe une interaction entre la quantité et la forme nominale. Et comme Nicolas le fait remarquer à juste titre, la chaîne de séparation attendue n'est pas la même dans toutes les langues.
En anglais, il existe des formes singulières et plurielles: orange et oranges, parfois recouvertes d'orange (s). Même cela pourrait être difficile à appliquer par programme, en raison de cas comme les pinceaux. Voir An Algorithmic Approach to English Pluralization pour un exemple de la façon dont la pluralisation programmatique pourrait être abordée en anglais .
Toutes les langues ne suivent pas les mêmes règles, et vous pourriez donc avoir des formes différentes selon que le nom serait considéré comme faisant l'objet ou l'objet d'une phrase, et peut-être même par cas grammatical.
On ne peut pas se fier aux hypothèses sur le fonctionnement des autres langues. Par exemple, en anglais et dans de nombreuses autres langues, les pluriels sont soit singuliers soit pluriels (deux ou plus). En arabe, il existe des formes pour le singulier, le double et le pluriel (trois ou plus).
Sans voir les informations in situ , il serait difficile de suggérer une solution viable pour toutes les langues. À tout le moins, je pense que vous devriez stocker les formes 1x, 2x et 3 + x du nom, la chaîne de séparation préférée et le nombre. Et ne supposez pas que si vous réorganisez l'ordre (par exemple, "3 oranges" par rapport à "Oranges: 3"), les chaînes localisées ne doivent pas également changer. Vous devez travailler avec un expert en localisation d'interface utilisateur très tôt pour vous assurer que cette partie de votre solution est conçue correctement. Le codage des caractères, la direction du flux de texte et l'expansion du texte devront également être pris en compte.
vous pourriez utiliser le pluriel dans tous les cas et en anglais, je suppose que c'était juste "Number of Files: 1" par exemple et être compréhensible. Mais globalement, le pluriel par rapport au singulier pourrait être plus problématique, et il peut également y avoir des écarts de montants différents dans certaines langues (russe?) Autres que le singulier ou le pluriel.
Certaines technologies et frameworks tels que celui utilisé par l'approche L20n de Mozilla permettent au traducteur de faire des ajustements. Par exemple:
http://blog.mozilla.org/l10n/2012/03/29/l20n-examples-for-localizers/
Pour les langues Bi-Di, la technologie de rendu de l'interface utilisateur devrait faire le travail RTL (de droite à gauche), vous n'avez pas besoin de retourner manuellement l'écran. Pour des chaînes complètes, autorisez le traducteur à déplacer les jetons.
La solution optimale consiste toujours à écrire des chaînes complètes. Ce n'est pas toujours possible ou souhaitable à partir d'un problème de stockage ou de performances avec s/w (et les jetons sont des pratiques de développement établies), vous devrez donc peut-être a) rechercher des modèles et du code communs pour ceux-ci et/ou b) permettre aux traducteurs de contrôler l'ordre ou les écarts lors de la localisation.