管理多语言数据的好UI设计是什么?

我们之前的内部CMS使用了一个编辑们似乎喜欢的相当简单的模型:在每个输入字段上,一排薄薄的切换按钮(JS驱动)选择了当前正在编辑的语言:

[EN-US] [FR-FR] [SW-SE] [RU-RU] [ZH-CN]
 _____________________________________
| textbox                             |
|_____________________________________|

它们的行为有点像单选按钮,例如选择一个会取消选择所有其他按钮,文本框会立即翻转以反映该值。这些按钮足够小,可以在输入字段上方放置约16个,然后才开始变得笨重。

我还建议在页面顶部设置一个“主开关”,可以同时切换所有控件。

为了跟进@mikehall上面的回答,我会做这样的草图:

Localization Data Entry http://redbitbluebit.com/images/language.png

当然,我的翻译是编造的;-)

我们有一个旧的MFC应用程序可以做到这一点。它有一个用于名称的文本框,该名称将是您在对话框的当前语言(当前用户设置并查看应用程序的语言)中管理的对象的名称。然后,下面有一个列表视图,您可以在其中添加您支持的每种语言的其余名称。

有一件事可能会改变你的方法,那就是你支持的每种语言都需要一个名称。如果是这样,您可以在列表视图中为每种语言预填充一行。如果没有,那么他们可以根据需要添加带有名称的行。

我为每个内容条目存储一个“区域设置”id(例如,产品1,区域设置1;产品1,地区设置2等…)

一个地区与一种语言(英语、法语、日语……)和一个地区(美国、加拿大、日本……)相关联

这样,您可以将“美国英语”和“美国西班牙语”与墨西哥的西班牙语分开存储。

本地化通常不仅基于语言,还基于内容。例如,可能有一些产品在某些国家不可用。

在内容管理方面,我通常通过cookie设置区域设置(即用户可以选择“更改区域设置”,更改区域设置,然后继续编辑/创建内容)。我这样做的原因是,除了内容加载之外,通常不会让同一个内容输入人员输入多种语言(而那些输入了多种语言的人应该手动切换,否则他们会感到困惑:“现在,我又在用哪种语言?”)

这些只是一些快速的提示——请发表评论,我将根据我过去的工作(包括个人网站以及百视达和艾利丹尼森等公司)提出建议。..

另一个建议是使用串行UI。在添加产品UI的情况下,您将有一个标题/描述字段列表,每种支持的语言都有一组。

这可能看起来过于简单,浪费了屏幕空间,但我认为这是必要的,原因有几个:

2. 与最后一点相关,串行UI允许快速扫描语言UI。这不仅仅是为了确保所有内容都已填写,也是为了让用户快速比较输入。添加产品示例本质上是一个用于输入简短翻译的UI,因此能够在相关语言之间进行比较非常有用。通过将相似的语言组合在一起,您可以使这一点更加有用。

串行接口可以简单地通过一个循环来呈现,该循环迭代您当前支持的任何语言。