这对我来说是一个难以总结的问题所以我们可能需要稍微编辑一下。
大约四年前，我们不得不为我们在墨西哥的客户翻译我们的asp.net应用程序。可扩展性和可扩展性在当时并不是那么令人担忧（哦，是的，我只是说那些可怕的话）因为我们只有美国和墨西哥的客户。
我们不是使用资源文件，而是使用某种类型的服务器控件（例如asp.net标签）替换应用程序中的每一段静态文本。我们将每个英语单词存储在SQL数据库中。我们已经添加了将英文文本翻译成另一种语言的功能，还可以添加文化覆盖。例如， hello 可以用一种语言翻译成¡hola！，并在不同的文化中被覆盖为¡bueno！。企业可以完全控制这些翻译，因为它们将为他们构建管理实用程序来控制所有内容。当我们检测到用户拥有除en-us之外的浏览器文化时，翻译就会启动。每个表单都来自一个基本表单，它遍历每个服务器控件并执行转换（转换数据作为数据表存储在文化的应用程序变量中）。我仍然对控制迭代的速度感到惊讶。
企业对翻译的工作方式非常满意。除了我上面提到的静态内容之外，企业现在也想要翻译某些数据。系统说明是他们想要的翻译的一个很好的例子。示例“已发信函#XXXX 给客户” - 企业希望根据其浏览器文化翻译“发送给客户的信函”文本。
我已经在SO上阅读了其他一些关于本地化的帖子，但是他们没有解决我的问题。如何翻译动态生成的短语？我可以很容易地阅读英文文本并翻译“已发送”，“信函”，“到”和“客户”，但我保证它对最终用户来说看起来很愚蠢，因为它是一个短语。如果我们用英语存储短语而不是动态文本，系统生成的音符的动态部分会搞砸我们对短语执行的任何查找。
有人以为我有......我们没有系统生成的笔记类型表。我想我们可以创建一个具有动态数据占位符的文件，而翻译引擎会忽略占位符标记。这种方法的问题是我们的SQL服务器数据库是一个旧的pick数据库的复制，我们并不真正知道所有类型的系统生成的短语（它们深入pic代码库，子程序，控制文件等）。注释，计票器和付款拒绝等原因都以不同方式存储。试图将这些数据标准化已经证明是困难的。返回并识别和更改生成消息的每个选择程序将是一项巨大的努力。
This question非常接近;但我不仅仅处理系统生成的状态消息，而是处理无数短语和短语类型而没有中央生成机制。
有什么想法吗？
答案 0 :(得分：1)
如果您没有针对特定短语的翻译，并且稍后会将翻译存储起来，我认为您可以尝试使用foisting the job off onto Google之类的内容。
为以后存储翻译提供了用于构建消息目录的数据收集点和粗略（如果有时laughably wonky）动态构建的初始翻译集。开始此过程后，跟踪已审核的翻译以及每个翻译的频率。然后可以审查和改进频繁命中的机器翻译。
答案 1 :(得分：1)
缺乏“瓶颈” - 你认为（缺少的）“中央发电机制” - 是这种情况下的架构问题。理想情况下，重新架构以实现这样的瓶颈（因此您可以继续使用您的一般方法与文化适当的消息再现数据库，只需使用“占位符”，例如您的示例中的#XXXX）将是最好的。
如果这是不可行的，您可以将“瓶颈”放在管道的另一端 - 当即将发出消息时。此时或几点，您需要尝试匹配即将发出的（英语）字符串与一系列精心设计的正则表达式（“占位符”通常类似于(.*?) ...）和从而识别DB查找的适当密钥。是的，仍然是很多工作，但至少它应该是可行的，没有你提到的旧翻译选择代码的问题。
答案 2 :(得分：1)
我们使用您提出的插入点技术。
“已发信＃{0：字母数字}给客户{1：客户全名}”
可能是（反过来猪拉丁语，比如说）：
“Ustomercay {1：客户全名} asway entsay etterlay＃{0：Letter Num}”
请注意，这会处理特定目标语言反转插入顺序等的情况。它不会处理第一，第二等细微差别，必须使用应用程序逻辑/更多短语来处理：
“这是你的{0：第一，第二，第三}警告”
答案 3 :(得分：0)
动态机器翻译不适合您实际期望人们付钱的产品。唯一的方法是使用包含插入点的静态模板（正如Cade Roux在他的回答中所证明的那样）。
没有彻底重构您的代码以使其可行。另一种方法是不对这些短语做任何事情（这就是你现在正在做的事情，而且它正在运作，对吧？）。通常没有翻译比令人尴尬的糟糕翻译更好。