原文链接：Jeremy.Katz - QLocale: It’s about time (and dates, and languages, and …)

一个应用，多个区域设置（locale）

Qt的目标之一是使事情变得容易，或者至少把程序从一个操作系统迁移到另一个变得更容易一些。从Windows到Linux桌面？可以。从Macintosh OS X到Symbian？好的。

但是如果从挪威到德国呢？从澳大利亚到美国呢？有什么原因让这一变化不能自动完成呢？虽然这其中有很多事情需要了解，但是QLocale类已经努力地对其中很多事情进行了封装。

我在这里写这篇博客的原因是QLocale有一些缺点。当然这不是新闻，最近一些使用案例的出现更加突出了这一问题。这些案例通常是通过指向其它区域设置（locale）数据的指针体现的。一个例子是MeeGo Touch的MLocale类。另一个是Symbian的本地化API。如果能在所有支持Qt的平台上提供这些特性中的一部分，当然是很好的事情。

问题的分析

这里我们是QLocale中所缺少的东西的一个简短列表，没有特定顺序。

• 货币
• 排序规则
• Writing script
• Numeral script
• 日历
• Work week days
• 星期的第一天
• 24小时时间格式
• 时区
• 电话号码格式
• 语言的当地名称

另外，我们还被要求混合区域设置（locale）。具体说明：我现在正在挪威用美国英语规则进行书写，但是我正在查找最近的杂货店的地址，我想使用千米做距离单位。Qt中内置的区域设置（locale）数据库中并没有这样一个对一些事情使用en_US，而对其它事情使用*_NO的区域设置（locale）。MeeGo Touch把区域设置（locale）划分为几个类别。这个划分带来了一个问题：它使得让一个区域设置（locale）（例如是en_US）来处理一些特定的数据（例如日期）成为可能，那么Qt需不需要包含一个对这一操作的逆过程的能力？如果我知道现在是“January 1, 2011”，那么知道这个日期格式是en_US格式很重要么？

另一个被带出来的问题是Qt内置的区域设置（locale）数据是否有价值。它们是否有用？或者Qt是否应该依赖于操作系统提供的区域设置（locale）数据？也许应该在一定意义上对字符集和修饰语（codeset and modifiers）进行支持？

我可以看到这两种策略的优点或者原因，但是我想知道您认为哪个更有价值。

解决方案的计划

这里我想留给您的想法是：您需要Qt的区域设置（locale）提供哪些支持？在这里讨论对于上述特性的批准或者拒绝都是受欢迎的。另外如果我遗漏了什么，请告诉我。

译者注：请用英文在这里参与讨论。