代码之家 › 专栏 › 技术社区 › Grundlefleck anujkk

有没有处理可本地化助记法的模式/算法?

mnemonics user-interface localization language-agnostic

1

Grundlefleck anujkk · 技术社区 · 15 年前

我在一个web应用程序产品上工作,它允许助记符(即字符'c'下面的下划线,允许键盘组合和按键c触发“关闭”按钮)。

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

所以我想知道,有没有什么好的策略可以达到接近理想的解决方案?

编辑:为了澄清,

我说的不是键盘加速键,比如ctrl+s代表save,它隐藏在菜单中。助记符只用于在屏幕上显示的动作,例如在按钮标签下。不是隐藏的键盘快捷键,在本地化时会发生变化(反正没有,我们是在Web浏览器中运行的,所以唯一的加速器是那些正在使用的浏览器的一部分)。
试图在设计时选择助记符的问题是,负责开发ui的人员不知道本地化,因为这可能在几个月后完成。此外,使用嵌套和模块化形式的问题意味着,即使没有本地化,仍然可能存在冲突。

我反复讨论过的一些想法包括建立一个全局助记符注册中心,表单可以根据它的本地化标签来申请某种助记符,然后注册中心会计算出哪个是可用字符的最佳使用。不知怎的,它必须保持这种状态——这样在应用程序使用过程中,同一个表单不会以不同的助记符集出现,它甚至可能是静态的并持久化的。

当然,如果我想做这样的事情,它将适合一个更普遍的算法-我只是不知道哪一个!:-)

3 回复 | 直到 15 年前

1

2

Glorfindel Doug L. 5 年前

我试着在过去的一个项目上做类似的事情,结果放弃了。这件事太复杂了,不可能在任何合理的时间内完成。

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

我不知道是否可以称之为“最佳实践”,但请考虑一下Microsoft Internet Explorer在日语中的功能。注意菜单和工具栏上熟悉的f、e、v、a和d助记符。我想,在适当的情况下,表单上的按钮等也遵循同样的约定。

_{(来源:

sidenet.ddo.jp

)}

(我从一个 google image search 是的。如果过期了,你可以找到其他的照片日元 -本地化IE非常容易。)

2

1

JasonTrue 15 年前

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

我应该指出,这次选择不本地化加速器是一个相当近期的趋势;在2000年左右以前,在一些产品中本地化快捷键仍然很常见(例如,在德国和瑞典的产品中,ctrl-f代表“fett”,而不是“bold”)。但钟摆却朝着相反的方向摆动,也许是梅和类似特征的结果。

一些本地化工具可以帮助您实现这一点;我将此功能视为一个从未使用过的称为可视本地化的产品的要点。我不确定自动赋值有多有用,因为在没有特定产品的领域知识的情况下,自动确定哪一个字符是最好的记忆表示是一个相当困难的问题。

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

对于常规菜单项或键盘命令序列,除非您具有完全烘焙的“键盘到命令映射”自定义功能,否则可能会更混乱,而不是更有用。

3

0

JoshBerke 15 年前

我看到的问题是,在运行时,当您部署一个具有新表单的版本,并将close从alt-c更改为ctrl-c时,会发生什么情况。或者当您在两个不同的页面上有两个操作,但它们都是close时,你要确保close始终是alt-c,更糟的是如果算法是基于不确定的东西,并且可以随着时间的推移而改变,而不需要部署。

看起来你可能会花更多的时间尝试为设计时应该决定的东西构建一个算法。