我知道，当您提前知道您的产品将在这些特定国家/地区使用时，那么人们应该采用资源捆绑方法。但是，当我们目前不知道我们的产品将来可能会在多少个国家推出时，那为什么不去使用像Google提供的翻译api呢？假设我们计划在一个新的国家/地区推出我们的产品，那么在资源捆绑方法中，您必须在文本文件中为每个标签进行条目。但是使用这种翻译方法，我们可以在服务器启动时通过翻译 API 来制作文件，这样我们就可以节省符文翻译时间。尽管到目前为止我还没有看到任何项目这样做。对此有什么想法吗？
I know when you know in advance your product will be used in these specific countries, then people should go for resource bundle approach. But when we are not for in how many countries our product may be launched in future at present, then why not go for translation api like provided by Google? Say if we plan to launch our product in a new country, then in resource bundle approach you have to make the entries for each label in text file. But with this translation approach, we can do make the files through translation apis at the start of server so that we can save rune time translation. Though I have not seen any project doing this as of now. Any thoughts on this?
发布评论
评论（3）
翻译 API 虽然很有用，但无法为您提供应用程序中的上下文，而资源包中的“人工生成”内容则可以。
Translation APIs, though useful, are unable to provide you with context in the application where as 'human generated' content in resourcebundles can.
不使用 Google Transliteration API 的一个很好的理由是它已被弃用。在我看来，在新项目中使用已弃用的 API 并不是一个特别明智的举动。
One good reason not to use the Google Transliteration API is that it has been deprecated. Using a deprecated API in a new project doesn't strike me as a particularly wise move.
不使用自动翻译的一个主要原因是质量 - 您不想只“翻译”您的应用程序，您真的想“本地化”它。
即使你只是想翻译它，你也希望结果有一定的意义，这需要上下文 - 否则，你最终会得到带有奇怪文本的菜单/UI 元素，用户会认为你的系统太糟糕了将停止使用翻译版本或更糟的是，整个系统。
One major reason not to use automatic translation is quality - you don't want to only "translate" your app, you really want to "localize" it.
And even if you just want to translate it, you want the result to have some meaning, which requires context - otherwise, you'll end up with menus/UI elements that have such weird texts the users will think your system is so crappy they'll stop using the translated version or worse, the system as a whole.