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

【问题标题】：Are there any patterns/algorithms for dealing with localisable mnemonics?是否有任何模式/算法来处理可本地化的助记符？
【发布时间】：2009-04-08 18:17:18
【问题描述】：

我正在开发一个允许助记符的网络应用程序产品（即字符“C”下方的下划线，以允许键盘组合和键 C 触发“关闭”按钮）。

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

所以我想知道，有没有什么好的策略可以在接近理想解决方案的任何地方实现目标？

编辑：澄清一下，

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

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

当然，如果我想做类似的事情，它会适合更通用的算法——我只是不知道是哪一个！ :-)

【问题讨论】：

【解决方案1】：

我尝试在过去的项目中做类似的事情，然后放弃了。这太复杂了，无法在任何合理的时间内完成。

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

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

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

（我从google image search 中截取了那个截图。如果它过时了，你可以很容易地找到 jp 本地化 IE 的其他图片。）

【讨论】：

【解决方案2】：

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

我应该指出，这次不将加速器本地化的选举是一个相当近期的趋势。在 2000 年左右之前，在某些产品中本地化快捷方式仍然很常见（例如，在德语和瑞典产品中用 ctrl-F 表示“Fett”而不是“bold”）。但钟摆却朝相反的方向摆动，这可能是 MUI 和类似功能的结果。

一些本地化工具将在这方面为您提供帮助；我将此功能视为我从未使用过的产品 Visual Localize 的要点。我不确定自动分配有多大用处，因为在没有特定产品的领域知识的情况下，自动决定哪个字符是最好的助记符是一个相当困难的问题。

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

对于常规菜单项或键盘命令序列，它可能更令人困惑而不是有用，除非您拥有完全成熟的键盘到命令映射自定义功能。

【讨论】：

【解决方案3】：

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

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

【讨论】：