一种策略是在 XML 文档中使用 xml:lang 属性，这需要与 Sandcastle XSLT 文件进行一些协调。 Visual Studio 2010 允许保留多个标记（尽管您可能会收到有关重复标记的投诉）。
/// <summary>
/// Gets or sets the fill size of the load operation.
/// </summary>
/// <summary xml:lang="fr">
/// Obtient ou définit la taille de remplissage de l'opération de chargement.
/// </summary>
public int FillSize
{
get;
set;
}
结果输出：
<member name="P:Namespace.MyAttribute.FillSize">
<summary>
Gets or sets the fill size of the load operation.
</summary>
<summary xml:lang="fr">
Obtient ou définit la taille de remplissage de l'opération de chargement.
</summary>
</member>
One strategy, which would require some coordination with the Sandcastle XSLT files, would be to use the xml:lang attribute on your XML documentation. Visual Studio 2010 allows multiple tags to remain (although you may get complaints about duplicate tags).
/// <summary>
/// Gets or sets the fill size of the load operation.
/// </summary>
/// <summary xml:lang="fr">
/// Obtient ou définit la taille de remplissage de l'opération de chargement.
/// </summary>
public int FillSize
{
get;
set;
}
Resulting output:
<member name="P:Namespace.MyAttribute.FillSize">
<summary>
Gets or sets the fill size of the load operation.
</summary>
<summary xml:lang="fr">
Obtient ou définit la taille de remplissage de l'opération de chargement.
</summary>
</member>
We put a "<EN>" tag after all our documentation tag like this :
/// <summary>
/// Description du produit
/// <EN>Product's description</EN>
/// </summary>
Then in the sandcastle xslt file (Development/presentaton/vs2005/transforms/main_sandcastle.xsl) we went to the template matching "param" (line 95 for us) and we added
你会如何处理变化？假设我给你一个补丁，但我的评论只有英文，你的流程是什么？如果您有英语补丁 A、西班牙语补丁 B 以及英语 + 法语补丁 C，该怎么办？
另一种选择是分叉该项目。主分支是否使用最新版本的法语，然后在自己的时间更新其他语言？
将源代码中的注释分开会导致维护变得混乱。然后，您基本上在构建脚本中使用资源文件。
这个问题已经解决了吗？如果您想到任何大型、多语言、开源项目，他们如何处理它？
You have yourself a tricky one. There really isn't a "best practise" since most software is developed in English.
That being said, if you look at other multi lingual documentation, how do they handle this problem?
Take International Standards. Something like ISO 9001. You have the same document (ISO 9001:2008) available in English, French, Russian etc.
Or ISO 5247-2 has the one document in English+French+Russian.
How would you handle changes? Say I give you a patch, but my comments are only in English, what would your process be? What if you have patch A in English, patch B in Spanish and patch C in English + French?
Another option is to fork the project. Have the main branch be in French with the latest build, then bring the other languages up to date in their own time?
Separating the comments in your source code would get messy to maintain. You are then basically using a resource file in your build script.
Is this a solved problem already? If you think of any large, multi lingual, open source project, how do they handle it?
发布评论
评论（5）
一种策略是在 XML 文档中使用
xml:lang属性，这需要与 Sandcastle XSLT 文件进行一些协调。 Visual Studio 2010 允许保留多个标记（尽管您可能会收到有关重复标记的投诉）。结果输出：
One strategy, which would require some coordination with the Sandcastle XSLT files, would be to use the
xml:langattribute on your XML documentation. Visual Studio 2010 allows multiple tags to remain (although you may get complaints about duplicate tags).Resulting output:
我们这样做了：
我们放了一个“”在我们所有的文档标签之后添加这样的标签：
然后在 sandcastle xslt 文件（Development/presentaton/vs2005/transforms/main_sandcastle.xsl）中，我们转到匹配“param”的模板（我们的第 95 行）并添加 < /p>
然后您可以更改 css 以以您喜欢的颜色显示翻译。
We did that like this :
We put a "<EN>" tag after all our documentation tag like this :
Then in the sandcastle xslt file (Development/presentaton/vs2005/transforms/main_sandcastle.xsl) we went to the template matching "param" (line 95 for us) and we added
And then you can change the css to display the translation in your favorite color.
一种可能的策略是在代码中使用默认语言，并单独提供翻译。
无论我最终选择哪种本地化语言，我都更愿意选择英语作为文档的默认/后备语言。
代码结构为您的翻译数据库提供索引，例如：
您可以拥有一个工具，允许在 UI 中为每个命名空间/成员进行翻译。
您可以让一个单独的翻译团队查看尚未翻译的项目，并提供翻译。
一旦翻译项目的数量超过阈值，您就可以在发布版本时开始发布翻译的文档。
更改默认翻译将表明您也需要所有其他语言的新翻译。
当然，如果您仅对命名空间进行重大更改，则可以将命名空间重新映射为数据库中的临时重新映射操作。
如果您运行开源项目，那么使用协作在线翻译工具是有意义的。
在生产中实施这种协作翻译策略的一个例子是
https://translations.atlassian.com/
基本上，您可以介入并开始在线贡献翻译。
它的目的是翻译产品本身，而不是文档，但同样的做法也适用。
One possible strategy would be having a default language in code, and supply translations separately.
No matter which localized languages i would have finally, i'd prefer to choose English as the default/fallback language of the documentation.
Code structure provides indexing for your translation database, for example:
You could have a tool that would allow for translation in a UI for each namespace/member.
You can have a separate team of translators looking through the items that have no translation yet, and supply translations.
And you can start shiping a translated documentation as your ship a release as soon as you get the amount of translated items above a threshold.
A changed default translation would indicate that you need a new translation for all other languages too.
Of course, if you do a major namespace-only changes, you can remap the namespaces as an ad-hoc remapping operation in database.
If you run opensource project, it makes sence to use a collaborative online translation tool.
One example of such collaborative translation strategy implemented in production is
https://translations.atlassian.com/
Basically you could just step in and start contributing translations online.
It is set up to translate the products themselves, not the documentation, but the same practice apply.
以防万一有人需要解决方案，有一个名为 Surviveplus.XmlCommentLocalization 的 nuget 包。令人惊叹的！
Just in case anyone needs a solution there is nuget package called Surviveplus.XmlCommentLocalization. Stunning!
你自己也有一个棘手的问题。由于大多数软件都是用英语开发的，因此确实不存在“最佳实践”。
话虽如此，如果您查看其他多语言文档，他们是如何处理这个问题的？
采取国际标准。类似于 ISO 9001。您有相同的文档 (ISO 9001:2008)提供英语、法语、俄语等版本。
或者 ISO 5247-2 有一份英文+法文+的文档俄语。
你会如何处理变化？假设我给你一个补丁，但我的评论只有英文，你的流程是什么？如果您有英语补丁 A、西班牙语补丁 B 以及英语 + 法语补丁 C，该怎么办？
另一种选择是分叉该项目。主分支是否使用最新版本的法语，然后在自己的时间更新其他语言？
将源代码中的注释分开会导致维护变得混乱。然后，您基本上在构建脚本中使用资源文件。
这个问题已经解决了吗？如果您想到任何大型、多语言、开源项目，他们如何处理它？
You have yourself a tricky one. There really isn't a "best practise" since most software is developed in English.
That being said, if you look at other multi lingual documentation, how do they handle this problem?
Take International Standards. Something like ISO 9001. You have the same document (ISO 9001:2008) available in English, French, Russian etc.
Or ISO 5247-2 has the one document in English+French+Russian.
How would you handle changes? Say I give you a patch, but my comments are only in English, what would your process be? What if you have patch A in English, patch B in Spanish and patch C in English + French?
Another option is to fork the project. Have the main branch be in French with the latest build, then bring the other languages up to date in their own time?
Separating the comments in your source code would get messy to maintain. You are then basically using a resource file in your build script.
Is this a solved problem already? If you think of any large, multi lingual, open source project, how do they handle it?