PDFPatcher
PDFPatcher copied to clipboard
wmjordan
国际化和本地化
在进行大变更之前，我先创建一个Issue，然后再做PR，以免工作和其他贡献者的产生重复或冲突。大家也可就此进行讨论，达成共识。最终决定权在wmjordan。
这个项目非常有价值，也很有潜力，如能将其进行国际化，相信会吸引更多的开发者加入到项目中来。
国际化待办事项：
- [x] 将注释翻译为英文 (已完成，待 Push, https://github.com/calcitem/PDFPatcher/commit/d7d49cc47dd7b65afeccd26c5f5948dcaa45e2f2)
- [x] 基准语言切换为英文，为建立资源文件时自动将条目命名为英语作准备(当前会命名为中文，故工具不能正常工作)。已完成，待调试，https://github.com/calcitem/PDFPatcher/commit/e4465cf6a8c22f3b0ae1109f5d071d2c3c009aff 暂未制作 PR。
- [x] 将英文文本移动到 Resource 文件中。(已基本完成，详见 https://github.com/calcitem/PDFPatcher/commit/3e9001a58c4e6a0346022ade5aca011e2c49fe46)
- [ ] 使用 Resources 文件实现多语言本地化。
- [ ] 将文本提取到资源文件中。
- [x] 配置文件当前为中文，需处理。
- [ ] 将项目，包括文档一起导入 Weblate 或者其他在线翻译平台。
- [x] 制作英语初始文本。
- [ ] 以英语为基础，自动衍生多国语言。
- [ ] 当基础语言变更时，自动触发多国语言的翻译，自动推送PR。
- [ ] 集成多国志愿者的翻译贡献。
- [x] 本地化相关文档。已完成文档的英语机器翻译，参见 https://github.com/calcitem/PDFPatcher/blob/develop/doc/en_US/UserGuide.md 待重新截图。
提取字符串，人工做肯定也是不现实的，需要找自动化方法，目前正在研究这些文章：https://manas.tech/blog/2009/10/01/using-gnu-gettext-for-i18n-in-c-and-asp-net/ https://www.cnblogs.com/cabbage/p/gettext.html
我之所以考虑将国际化放在高优先级事项上，是想趁着这周这个项目涨粉较快的机会，看看能不能助力于趁势在更广范围吸粉，如果这个项目短时间内涨粉速度更快，就有希望出现在 GitHub 本周推荐项目中，对于项目未来的发展是有利的。个人的力量毕竟有限，创始人的idea大家未必有足够的技能和水平能实现，如项目多一些关注，就多一些可能性。
提取字符串，人工做肯定也是不现实的，需要找自动化方法，目前正在研究这些文章：https://manas.tech/blog/2009/10/01/using-gnu-gettext-for-i18n-in-c-and-asp-net/ https://www.cnblogs.com/cabbage/p/gettext.html
我之所以考虑将国际化放在高优先级事项上，是想趁着这周这个项目涨粉较快的机会，看看能不能助力于趁势在更广范围吸粉，如果这个项目短时间内涨粉速度更快，就有希望出现在 GitHub 本周推荐项目中，对于项目未来的发展是有利的。个人的力量毕竟有限，创始人的idea大家未必有足够的技能和水平能实现，如项目多一些关注，就多一些可能性。
之前搜索过这个，
- c# - Best way to implement multi-language/globalization in large .NET project - Stack Overflow
- How to make a multi-language application in C# - CodeProject
- ResXManager - Visual Studio Marketplace 我感觉第3种方法，使用ResXManager可能会简单一些。
搞Res用微软官方虽正统，工具类更适合通告替换一个txt或者xml或json文件即可全球化；目前我正在做的一个工作是把美国流行的牙科诊所管理软件Open Dental汉化，这软件的思路可以借鉴。等我汉化工作结束，我可以写个blog
以前收集的一些工具，看看有没有可以用得上的。
-
Known users:
-
Known users:
-
Known users:
-
Poedit - Cross-platform translation editor.
-
Known users:
- QGIS
- TortoiseGit
Other Tools:
替换一个txt或者xml或json文件即可全球化
在我接触过的所有多语言程序中，用文本文件作为语言文件的最多。文本文件容易编辑，又有大量现成的差异对照工具可以帮助翻译人员比对语言文件的变化，并且所有专业的翻译软件都支持文本文件。XML 也有人用，但格式太繁琐。还不如用资源文件的多。至于用 json 的，我基本上没见过。
替换一个txt或者xml或json文件即可全球化
在我接触过的所有多语言程序中，用文本文件作为语言文件的最多。文本文件容易编辑，又有大量现成的差异对照工具可以帮助翻译人员比对语言文件的变化，并且所有专业的翻译软件都支持文本文件。XML 也有人用，但格式太繁琐。还不如用资源文件的多。至于用 json 的，我基本上没见过。
XML格式的话，mozilla系列软件汉化包底层都是xml（dtd什么的打开一看全是xml），这样想来也不少。文本文件/XML/json还有一个好处大家没提到，就是如果在git库中包含二进制文件的话，处理不好是会造成git库体积快速膨胀的（因为无法记录差异，只能记录一个文件块），而文本文件/xml/json便于记录差异。对于资源文件不太清楚，但如果是二进制文件还是需要注意一下。 xml的格式要求确实是个问题，但是怎么说呢，我接触的汉化工作原始文件基本都有格式要求所以觉得也还好，有格式的话也便于对照字串序号，防止字符溢出问题，或者根据场景调整翻译。 另外，github有个discussion功能，建议创建者前辈开了这个功能后把这个issue转进discussion，大家慢慢讨论
这是 Weblate 支持的文件格式列表。其他翻译平台暂未了解。
https://docs.weblate.org/zh_CN/weblate-4.10.1/formats.html
另外，文本化不能解决代码库膨胀问题，因为Git代码库中保存的是文件快照，而非不同版本的差异部分。不过文本文件确实是方便版本控制。
此分支 https://github.com/calcitem/PDFPatcher/commits/develop 已将界面文本翻译为英文并制作了英文版用户手册。
从运行效果看，由于英文文本长，所以两竖排的配置项布局可能需要调整为一排，以免文本显示不全。
补充∶ 目前已调整完成。
将英文文本移动到 Resource 文件的工作基本完成，详见 https://github.com/calcitem/PDFPatcher/commit/3e9001a58c4e6a0346022ade5aca011e2c49fe46 ，下一步是将中文原文导入resx文件。
应该可以翻译平台上英文作为原文，但不提供翻译为中文，库内同时维护中英文原文。 翻译必定出现不同译法，而作为原文则会是母语表达。翻译腔甚至机译中文出现在本项目，那就离谱了。 配置文件改英文，中文用户的可编辑性大降。配置也支持多语言就好了。
resx支持汉字key的吧；布局可以国际化，resx里有布局啊。
osu! Lazer 用代码分析器（编译器插件）查找可以本地化的字符串，添加到错误列表 不过分析器大概需要SDK样式项目 添加方法：在项目文件中加入这一段
<ItemGroup Label="代码分析器">
<PackageReference Include="ppy.LocalisationAnalyser" Version="2022.417.0">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
</ItemGroup>
基准语言切换为英文，为建立资源文件时自动将条目命名为英语作准备(当前会命名为中文，故工具不能正常工作)。已完成，待调试，https://github.com/calcitem/PDFPatcher/commit/e4465cf6a8c22f3b0ae1109f5d071d2c3c009aff 暂未制作 PR
跟原始语言没什么关系。近年来获取一个本地化字符串，用resx生成的资源代理类就行。
以这行为例
FormHelper.ErrorBox("An error occurred while saving the program setting " + ex.Message);
简单到FormHelper.ErrorBox(string.Fromat(SR.CannotSaveConfig, ex.Message));就行。真正需要的只有CannotSaveConfig这个键名