是否有任何模式/算法来处理可本地化的助记符？

Question

我在一个Web应用程序产品上工作，该产品允许助记符（即字符'C'下面的下划线，允许键盘组合，键C触发“关闭”按钮）。

• 表单由不同的开发人员创建，他们可以静态设置按钮的助记符。
• 表单可以嵌套，因此在设计时不一定知道一页所需的准确助记符。
• 使用包含多种表单的页面上的任何字符最多只能有一个助记符。
• 这里是踢球者，表格必须能够被本地化为任何语言，这意味着关闭的'C'可能甚至不会出现在用于“关闭”的... [插入语言]单词中。

理想的解决方案是某些算法，其中开发人员不必手动指定助记符，而是在运行时解决它们，它们将被本地化，并且它们既方便又一致（我说过理想的解决方案; -D）。

所以我想知道，在理想的解决方案附近有什么好的策略可以实现吗？

---

编辑：澄清，

• 我不是在谈论键盘加速器，例如用于保存的Ctrl + S，它隐藏在菜单上。助记符仅用于屏幕上显示的操作，例如按钮标签下。没有隐藏的键盘快捷键会在本地化时发生变化（无论如何都没有，我们在网络浏览器中运行，因此唯一的加速器是那些使用哪种浏览器的加速器。）
• 在设计时尝试选择助记符的问题在于负责开发UI的人员不知道本地化，因为它可能在几个月后完成。此外，使用嵌套和模块化表单的问题意味着即使没有本地化，仍然可能存在冲突。

我所遇到的一些想法包括有一个全局助记符注册表，表单可以用来根据它的本地化标签申请某个助记符，然后注册表会计算哪个是可用字符的最佳用法。不知何故，它必须保持其状态 - 这样在应用程序使用过程中，相同的形式不会出现不同的助记符集，甚至可能静态地进行并持久化。

当然，如果我想做类似的事情，它会适合更通用的算法 - 我根本不知道哪一个！ ： - ）

Answer 1

我试图在过去的项目上做类似的事情，并放弃它。在任何合理的时间内完成它太复杂了。

其中一个挑战是某些语言没有可映射到键盘上单个键的单个可显示“字母”。另一个挑战是英语，可用性标准要求助记符与其他应用程序中类似按钮/菜单中的助记符一致。如果您动态选择字母，这可能会很困难。

我不知道它是否可以被称为“最佳实践”，但请考虑Microsoft Internet Explorer在日语中的作用。请注意菜单和工具栏上熟悉的F，E，V，A和D助记符。我认为它在适当的情况下遵循相同的约定，用于表格上的按钮等。

_{（来源：sidenet.ddo.jp）}

（我从google image search获取了截图。如果它变得陈旧，你可以很容易地找到 jp -localized IE的其他图片。）

Answer 2

这实际上是一个设计问题，而不是算法问题。事实证明，大多数应用程序都没有本地化键盘加速器，包括大多数微软的加速器，尽管某些市场有一些例外。并非每个键盘快捷键都是助记符;实际上，只有少数最常见的是。

我应该注意到，这次选举不是为了加速器的本地化，这是一个相当新的趋势;在2000年左右之前，在某些产品中本地化快捷方式仍然很常见（例如，在德国和瑞典产品中，“Fett”而不是“粗体”的ctrl-F）。但钟摆在相反的方向摆动，可能是由于MUI和类似特征的结果。

一些本地化工具可以帮助您解决此问题;我将这个功能看作是我从未使用过的名为Visual Localize的产品的要点。我不确定自动分配是多么有用，因为如果没有特定产品的领域知识，自动决定哪个字符是最好的助记符表示是一个相当难的问题。

通常，只在对话框中定位带下划线的助记符字符才有意义，也可能在菜单中。大多数本地化服务公司都熟悉这个过程，有些工具可以在返回本地化资源包之前检测任何构建时资源中的重复项。实际上，您可能希望投资查找或构建可在运行时执行此重复检查的工具，并将该工具作为验收标准的一部分运行。

对于常规菜单项或键盘命令序列，除非您有一个完全烘焙的键盘来命令映射自定义功能，否则它可能会比帮助更令人困惑。

Answer 3

我在执行此操作时看到的问题是在运行时，当您部署具有新表单的版本时会发生什么，并且从alt-c更改为ctrl-c。或者当您在两个不同的页面上有两个操作但它们都很接近时，您需要确保关闭始终为alt-c。更糟糕的是，如果算法是基于非确定性的，并且可能会在没有部署的情况下随时间发生变化。

您似乎可能会花更多时间尝试为应该在设计时决定的事情构建算法。