1

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

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

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

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

编辑：澄清一下，

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

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

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

4

3 回答 3

2

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

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

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

带有日文菜单的 IE6 屏幕截图
（来源：sidenet.ddo.jp）

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

于 2009-04-09T15:34:16.417 回答
1

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

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

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

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

对于常规菜单项或键盘命令序列，它可能比有用更令人困惑，除非您有一个完整的键盘到命令映射自定义功能。

于 2009-04-08T18:47:16.440 回答
0

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

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

于 2009-04-08T18:23:09.773 回答