我已经了解了国际化/本地化应用程序的最佳做法，以便最大数量的用户可以使用它 - 从地理位置，语言和语言环境的角度来看。我的问题是 - 如果我想让来自世界各地的开发人员轻松使用我的 API ，我需要遵循哪些（其他？）最佳做法？< / p>
我意识到这个问题非常广泛 - 所以我将尝试缩小范围：我特别感兴趣为上述REST API创建REST API和Java客户端库。
我想到的一些事情是：
除了这些措施之外，还有其他方面让我感到困惑。
我是否应该真正命名我的课程以反映他们所依据的技术概念？例如，许多设计模式对于精通英语的人来说可能有意义，但对于具有不同教学语言的开发人员来说，他们可能很难掌握。那么，为了简单起见，我应该使用更简单的语言将DelegationInterceptor重命名为某些内容吗？我想知道这种简化是否会产生任何（合法的）后果？
很多时候，开发人员理解事物的最简单方法是看一个与他们每天看到的相似的示例（甚至框架名称） - 这就是为什么Pizzeria或Token Rings会很酷的原因作为我的API的示例用法。另一方面，在大多数开发API的开发人员来自的国家/地区可能都听不到这些相同的概念。我应该制作通用的例子吗？但是，有什么好处是枯燥乏味的“通用”例子？
如果有人能指出我那些能够很好地迎合来自不同语言环境和文化的开发人员 - 不一定是在REST或Java领域 - 那么任何人都会做的事情，那就太棒了。
答案 0 :(得分：2)
我的3美分：i18n最佳实践并不局限于地理，语言和语言环境等方面。我甚至认为，i18n最有趣的方面是了解和理解不同的文化，并充分发挥它们的作用。
很快回答你的问题：有一本关于API设计的书，由Krzysztof Cwalina编写（好名字，不是吗？）和Brad Abrams叫Framework Design Guidelines。还有some presentation on slideshare 无论如何，我读了这本书，我觉得它很棒，至少可以开眼界。
答案越长......你指的是编程可用性。我还没有真正看过详细介绍的主题（但是），但你可以找到很多关于编程语言的可用性的文章（即these slides）。这似乎是一门非常新的学科，而且相当困难（它是两种不同意义上的心理学，语言学，语法，编译器背后的理论，算法，......，以及更多） 。最重要的当然是人为因素，尤其是产生错误的固有能力 非常有趣的话题:)）
详细了解您的问题：
无法创建L10n API，因为本地化是一个使软件适应本地市场需求的过程。您要创建的是 i18n相关 API。
我不必知道为什么它必须是REST API，但为了100％诚实，我担心您可能想要创建一些超级梦幻般的API，实际上对< / strong> i18n最佳做法。首先要做的事情是：如果您希望它被许多开发人员使用，它应该像ICU一样是常规API。也许它的某些部分可以作为RESTful API公开，但我不确定 为什么 你想要这样做。
正如我已经提到的，有一种叫做ICU的东西，特别是ICU4J。我知道这个API非常复杂，对开发人员不太友好，但它有一个非常重要的优点：它确实存在。它是由i18n专家创建的，所以 真的 遵循最佳实践。由于事物的本质，某些部分本身就很复杂 - 如果你想正确地实施文化支持，它们就必须存在。遗憾。
顺便说一句：我可能错了，但是你说的是REST API，它在我脑海中响起了铃声。我相信你会想到客户端的i18n支持，不是吗？在这种情况下，我必须提出一个问题：Globalize和/或Dojo出了什么问题以及为什么你认为在服务器端执行所有操作是更好的选择？
好的，使用Dojo我可以自己回答这个问题：大小和响应能力。
完成您的观点：＆＃34;为开发人员提供一种方法来本地化字符串（显而易见）＆＃34;。这不是那么明显。也就是说，它并不像你想象的那么容易。如果您想要做到这一点，您必须确保理解这些术语：资源模型，资源组织，区域设置后备，消息格式，机器翻译和翻译记忆。
相信我，在这里犯错很容易。一方面，我怀疑任何人都可以创建一个API来阻止普通程序员懒惰和硬编码字符串，我怀疑它会发生。另一方面，您友好的API（如果您可以实现这一点）可以轻松地允许重复使用翻译（如果它不考虑常见的事情，例如＆＃34; OK＆＃34;，＆＃34;那么这就是i18n缺陷。取消＆＃34;等）。此外，您需要考虑格式化功能，以便（几乎）不可能引入连接（非常常见的i18n缺陷，阻止正确的翻译），同时很容易处理多个复数形式（仍然认为您知道最佳实践...？）。
适当的组织和有效的抽象模型可能有助于实现TM和MT（即重用旧翻译并最大限度地降低新翻译的成本）。但这很难，而且很少有人能够正确地做到这一点（甚至有一些框架，比如Play，例如实现严重的误解，即只有单个翻译文件）。
＆＃34;为开发人员提供一种方法来自定义特定于语言环境的工件（测量，货币，距离，重量等单位）＆＃34;。很好的主意。但请确保您也包含格式。我的意思是数字格式各不相同，单位不同，单位名称和符号（即使是相同的单位）也有所不同，但单位放置可能会有所不同。
其中一些工件已经在ICU和CLDR中，但对于其他工件，您实际上需要获得模式和项目本身的有效翻译。
根据我的经验，可能很难首先收集翻译，但有效的翻译......
＆＃34;国际化API文档＆＃34;。我猜：你的意思是 Localize ，在这种情况下可能等于 Translate 。
说实话，我不认为翻译某些API或框架的文档非常重要。专业程序员必须掌握一些英语，至少能够理解技术文档并编写可通过的代码（就变量名称和注释而言） - 它是 非常不专业 不要将英语用于此类物品。
＆＃34;正确与简单＆＃34;。我不确定你提到的是什么样的正确性。就英语语法而言，我绝对赞成简单而非语言正确性 在对i18n的有效支持方面，已经有很多不正确的库，请不要提供另一个。正如我之前所写的，有些东西本来就很复杂，它们可以正确完成（这将导致复杂的API）或根本不应该完成。为文化支持带来简单但仅部分正确的解决方案将导致大量缺陷（我会诅咒你）以及需要找到更复杂的解决方法。这不值得努力。
＆＃34;文化中立＆＃34;。我推荐，请阅读这本书。它很快就涵盖了这一点（实际上没有必要更深入） 我怀疑你是否应该为政治正确而努力，只要避免一些事情，你确定我会伤害别人的感受（不要对别人做你不想做的事情）。那就是它。
编辑：还有两件事。
在您的API上实际执行可用性测试可能是个好主意（就像您对用户界面所做的那样）。如果感觉自然而直观，那么你做得很好。通过这样做，您还将了解人们可能希望如何使用您的库，也就是您将发现其他用例。
创建编程库可能要比实际创建程序困难得多。在库/ API的情况下，你经常需要打破（或至少似乎是）刻在石头上的真相，即创造一些违反常见的OOP / OOD原则，但易于使用的东西。您还需要提供更多重载（有许多不同的用例，请注意）。如果你想支持java.util.Date，Calendar，java.sql.Date，java.sql.Time，java.sql.Timestamp，XMLGregorianCalendar，{就像在Java中格式化日期/时间这样简单的东西真的会让你头疼。 {3}}和Joda Time。
另一方面，我不确定通过REST API发送格式化的日期/时间是否真的是i18n的最佳实践......