在文档应用程序中处理多语言的最佳方法
我们有一个 SaaS Web 应用程序（多租户），用于创建在线文档（如 wiki）。 目前我们仅支持英语。我们希望支持其他语言。我们已将所有界面控件设置为可以工作，但我们只需要弄清楚如何处理实际的用户内容。
我们似乎正在考虑单独存储每种语言的每个页面。 因此，如果他们用户创建一个“如何重置密码”页面，并希望它有英语、荷兰语和西班牙语版本，我们会在数据库中存储该页面的 3 个不同版本。
我很乐意对此提出任何建议！
We have a SaaS web application (multi-tenant) for creating online documentation (like a wiki).
Right now we only support English. We want to support other languages. We have all the interface controls set up to work, but we just need to figure out how to handle the actual user content.
It seems we are thinking about storing each page for each language separately.
So if they user create a page "how to reset password", and wants it in English, Dutch, and Spanish, we would store 3 different version of that page in the database.
I would love any advice on this!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
以我自己的经验为例 - 您实际上有两个选择：
每种语言完全独立
当用户想要翻译其文档的内容时 - 他们只需启动一个新的、单独的、完整的文档版本- 并翻译每一页。您可以复制现有文档作为起点，但每种语言在任何情况下都是独立的。例如，CakePHP 文档当前的组织方式。每种语言实际上都是独立的，因此具有最大的灵活性。我所说的灵活性是指，例如，一种语言的页面不必存在于所有其他语言中 - 或者具有相同的网址/名称。
这里的缺点是保持版本同步，或者知道翻译何时需要更新（主语言版本的新更改）。
将翻译存储为原始版本
或者，您可以将翻译存储为主语言/主要语言的版本。 那个 是 如何 我们之前做过。它可以更轻松地跟踪正在翻译的内容，但代价是灵活性。
这里的缺点是它可能过于严格 - 添加特定于语言的页面可能并不容易，添加非主要语言的新页面也可能会导致问题
这类似于“
我们将存储 3 个不同的 页面数据库中该页面的版本”。上述两种方法都非常有效，选择解决最多问题且问题最少的一种:)
Using my own experience as examples - you have two choices really:
Each language is completely seperate
When a user wants to translate the contents of their documentation - they simply start a new, separate, complete version of the docs - and translate each page as they go. You could copy the existing docs as a start point but each language would in any case be independent. For example, this is how the docs for CakePHP are currently organized. Each language is effectively independent which allows the most flexibility. By flexibility I mean, for example, a page in one language doesn't have to exist in all the others - or with the same url/name.
The disadvantage here is keeping the versions in sync, or knowing when a translation needs updating (new changes to master language version).
Store translations as versions of the original
Alternatively you could store translations as versions of the master/main language. that is how we did it before. It made it easier to track what was being translated but at the cost of flexibility.
The disadvantage here is it's potentially too rigid - it may not be easy to add a page that is language specific, adding a new page in not-main-language could also cause problems
This is analogous to "
we would store 3 different version of that page in the database".Both of the mentioned approaches are quite valid, pick the one that solves the most problems whist giving the least issues :)
在多语言应用程序中处理文档的最佳方法是通过将文档嵌入到应用程序中来避免这种情况，但不是将文档作为整个页面，而只是作为句子。。
尝试使应用程序的使用尽可能简单直观，在 UI 中包含提示，并为需要更多信息的用户提供按语言划分的论坛。
现在，请确保每种语言至少有一个人来报告界面中的任何问题，以便您可以根据他们的输入改进文本或设计。
The best way to deal with documentation in multilanguage applications is to avoid it by embedding the documentation in your application, but not as entire pages, just as sentences..
Try to make the usage of your application as simple and intuitive as possible, include hints in the UI and for those who need more provide a forum split by languages.
Now, be sure that you have at least one person for each language that will report back any issues in the interface, so you could improve the texts or the design based on the input from them.