我相信我们中的一些人已经在一个项目中工作，该项目不仅需要用不同的语言来支持UI，而且还必须支持数据。例如，例如能够提供和存储我在这里写的翻译。

更重要的是，我还相信我们当中有些人会触发一些时间触发的事件(例如，当会员资格到期时)，在这些事件中应考虑用户位置，例如根据正确的时区计算午夜。

最后，还需要根据某些语言支持从右到左的用户界面，并在读取提交的数据文件(例如，解析文本和excel数据)时使用不同的编码

目前，我将所有实体的所有翻译存储在一个表中(不那么实用，因为在执行sql查询以查找问题时很难找到自己)，主要是在附属程序集上设置UI翻译，但都不支持时区，也不是从右到左的设计。

我们在应对这些挑战时有何经验？

[编辑]

我认为大多数人认为这种水平的多元文化需求就像建立一个大型项目一样。事实上，如果我们想了解在线调查，其中：

• 答案只会收集到午夜
• 问卷的定义和部分答案来自文本文件(任何语言)以及翻译
• 问题和回答选项必须以几种语言显示，具体取决于访问者
• 还必须以几种不同的语言显示和生成报告

正如人们所看到的，我们不必为了达到这种要求而在应用程序中走得太远。

[Edit2]

刚发现我的问题是重复的

在项目中

第一个答案(通过投票订购时)是如此全面，我必须至少有一天将它的一部分付诸实施。

解决方案

慢点

仔细考虑所有事情，然后再认真考虑一下我们在做什么。请记住，添加的数量越多(如从右到左)，质量检查周期就会越长。

困扰主要问题是在代码端广泛使用接口，或者将一种数据源通过翻译器传递给需要支持的任何一种语言，或者将每种语言的数据源分开。

时间问题可以由接口处理，因为大概我们会希望事情以相同的方式运行，但实现细节有所不同。在很大程度上，将界面调整为支持不同的语言时，可以将类似的思考过程应用于界面的创建。当我们了解它时，皮肤就是这样，其中要皮肤的内容是界面，外观是实现。

做用户需要的。例如，大多数程序员都懂英语，因此没有翻译本网站上的帖子的感觉。如果许多用户需要翻译，请添加具有语言ID的新表格列，并添加另一列以将翻译后的行链接到其原始行。如果目标听觉包含来自中东的用户，请实施从右到左。如果时间精度对一个小时以下至关重要，则将时区列添加到用户表中，依此类推。

如果我们使用的是* NIX，请使用gettext。我使用的大多数语言都提供了一定程度的支持。例如，PHP是相当不错的。

要非常非常谨慎。从我们对要实施的i18n功能的评论中，我想知道我们是否超出预期范围。

请注意，老大哥(例如eBay，amazon.com，yahoo，bbc)网络应用程序实际上以他们要支持的每种语言提供了单独的应用程序。这些Web应用程序中的每一个都消耗一组公共的核心服务。如果两个甚至会说同一种语言的不同国家(例如英国和美国)的业务需求差异如此之大，以至于我们确实需要为每个国家/地区使用单独的应用程序，也不要感到惊讶。

另一方面，我们可能需要成为下一个amazon.com。用一种语言(而不是多种语言)交付成功的Web应用程序很困难。如果这对Web应用程序的业务需求有意义，那么我们不应该害怕一个用户群体(例如，说亚洲语言的用户)。

我将描述我的项目中所做的事情(这不是我的原始体系结构，但无论如何我还是很喜欢)

提供翻译支持

需要翻译的文本分为三类：

• 错误文本：类似在应用程序业务层中深处发生的错误
• UI文本：在用户界面中显示的文本(标签，按钮，网格标题，菜单)
• 用户定义的文本：需要根据最终用户的偏好进行翻译的文本(即-用户在调查中创建问题，他也可以创建该调查的翻译版本)

对于每个不同的类别，用于提供翻译服务的架构是不同的，因此我们具有：

• 错误文本：具有访问资源文件的静态功能的库
• UI文本：链接到视图引擎的" Helper"类，提供来自远程程序集的翻译
• 用户定义的文本：数据库中的一个表，该表提供翻译(根据翻译后的实体的typeID和对象ID)，并通过1 x N关系链接到该实体

但是，我还没有攻击其他明显的问题，例如处理时区，不同的布局和图片翻译(如果确实需要的话)。有谁以不同的方式解决了这个问题？

有没有人解决过其他i18n问题？