Existe-t-il des modèles/algorithmes pour traiter les mnémoniques localisables?

Question

Je travaille sur un produit d'application web qui permet des mnémoniques (c'est-à-dire un trait de soulignement sous le caractère 'C', pour permettre une combinaison de clavier et la touche C pour déclencher le bouton 'Fermer'). Les formulaires sont créés par différents développeurs et peuvent chacun définir des mnémoniques statiques pour les boutons.

Les formulaires peuvent être imbriqués, donc il n'est pas nécessairement connu au moment du design les mnémoniques exactes qui seront nécessaires pour une page.

Il peut y avoir au plus un mnémonique utilisant n'importe quel caractère sur une page contenant plusieurs formes.

Et voici le kicker, les formulaires doivent pouvoir être localisés dans n'importe quelle langue, ce qui signifie que le 'C' pour fermer peut ne pas apparaître dans le mot ... [insert language] utilisé pour "Close". La solution idéale serait un algorithme dans lequel les développeurs n'auraient pas à spécifier manuellement un mnémonique, mais à la place ils seraient élaborés au moment de l'exécution, ils seraient localisés, ils seraient à la fois pratiques et cohérents (J'ai dit la solution idéale ;-D).

Alors je me demandais, y at-il de bonnes stratégies pour réaliser quelque chose près de la solution idéale?

---

EDIT: Pour clarifier,

• Je ne parle pas de raccourcis clavier tels que Ctrl + S pour sauvegarder, ce qui est caché dans un menu. Les mnémoniques ne sont utilisés que pour les actions qui sont présentées à l'écran, sous les étiquettes de boutons par exemple. Les raccourcis clavier non cachés qui changeraient de localisation (il n'y en a pas de toute façon, nous fonctionnons dans un navigateur web, donc les seuls raccourcis sont ceux qui font partie de n'importe quel navigateur utilisé). Le problème avec la tentative de choisir les mnémoniques au moment de la conception est que les personnes responsables du développement de l'interface utilisateur ne sont pas au courant de la localisation, comme cela pourrait être fait des mois plus tard. En outre, le problème de l'utilisation de formes imbriquées et modulaires signifie que même sans la localisation, il peut encore y avoir conflit.

Certaines des idées que je l'ai frappée INCLURE autour d'avoir un registre mnémonique global qui formulaires peuvent utiliser pour demander un certain mnémotechnique, basé sur l'étiquette localisée, le registre calculerait alors quelle était la meilleure utilisation des caractères disponibles . D'une façon ou d'une autre il devrait maintenir l'état de cela - de sorte que la même forme n'apparaisse pas avec des ensembles mnémoniques différents au cours de l'utilisation d'application, elle pourrait même être faite statiquement et persistée. Sûrement, si je cherchais à faire quelque chose comme ça, je trouverais un algorithme plus général - je n'ai aucune idée de laquelle! :-)

Answer 1

Le problème que je vois avec ceci est lors de l'exécution, est ce qui se passe quand vous déployez une version qui a de nouveaux formulaires, et change Close d'alt-c à ctrl-c. Ou lorsque vous avez deux actions sur deux pages différentes mais qu'elles sont toutes deux proches, vous voulez vous assurer que la fermeture est toujours alt-c. Pire encore, si l'algorithme était basé sur quelque chose de non déterministe et pourrait changer au fil du temps sans déploiement.

Il semble que vous pourriez passer plus de temps à essayer de construire un algorithme pour quelque chose qui devrait être décidé lors de la conception.

Answer 2

Ceci est vraiment un problème de conception, pas un problème algorithmique. Il s'avère que la plupart des applications ne localisent pas les accélérateurs de clavier, y compris la plupart des Microsoft, bien qu'il y ait quelques exceptions dans certains marchés. Tous les raccourcis clavier ne sont pas des mnémoniques. vraiment, seulement quelques uns des plus communs sont. Je dois noter que cette élection pour ne pas localiser les accélérateurs est une tendance plutôt récente; avant 2000 environ, il était encore assez courant de localiser des raccourcis dans certains produits (par exemple ctrl-F pour "Fett" au lieu de "bold" dans les produits allemands et suédois). Mais le pendule a basculé dans la direction opposée, peut-être en raison de MUI et des caractéristiques similaires.

Quelques outils de localisation vous aideront à ce sujet; J'ai vu cette fonctionnalité comme un point sur un produit que je n'ai jamais utilisé appelé Visual Localiser. Je ne suis pas sûr de l'utilité de l'assignation automatique, car c'est un problème assez difficile de décider automatiquement quel caractère est la meilleure représentation mnémotechnique, sans connaissance du domaine d'un produit particulier.

Généralement, il est logique de localiser les caractères mnémoniques soulignés dans les boîtes de dialogue, et peut-être dans les menus. La plupart des entreprises de services de localisation sont familiarisées avec ce processus, et certaines ont des outils pour détecter les doublons dans les ressources de génération avant de restituer le paquet de ressources localisé. Vous voudrez peut-être investir dans la localisation ou la construction d'un outil qui peut effectuer cette vérification en double à l'exécution, et exécuter l'outil dans le cadre des critères d'acceptation.

Pour les éléments de menu normaux ou les séquences de commandes au clavier, il peut être plus déroutant qu'utile, sauf si vous avez un clavier entièrement cuit pour commander la fonction de personnalisation de mappage.

Answer 3

J'ai essayé de faire quelque chose de similaire sur un projet passé, et je l'ai abandonné. C'était trop compliqué à faire dans un laps de temps raisonnable. L'un des défis est que certaines langues n'ont pas une seule "lettre" affichable qui correspond à une seule touche du clavier. Un autre défi, en anglais, était que les normes d'utilisabilité exigeaient que les lettres mnémoniques soient cohérentes avec celles des boutons/menus similaires dans d'autres applications. Cela peut être difficile si vous choisissez dynamiquement les lettres.

Je ne sais pas si cela pourrait être appelé «meilleure pratique», mais considérez ce que fait Microsoft Internet Explorer en japonais. Notez les mnémoniques familières F, E, V, A et D dans le menu et la barre d'outils. J'imagine qu'il suit la même convention, le cas échéant, pour les boutons sur les formulaires et autres.

screenshot of IE6 with Japanese menus http://sidenet.ddo.jp/winetips/files/wine-ie6-01.png

(j'accroché que d'une capture d'écran google image search. Si elle rassit, vous pouvez trouver d'autres photos de jp -localized IE assez facilement.)