我想参与这个项目

[playNoA]

弱弱的问下，想参与这个项目的话，是不是得先学会玩GitHub？

[da-liii]

加油，很简单的

[hosiet]

@playNoA 会用 GitHub 网站或者会使用 Git 版本控制系统都是加分项。我个人建议的工作流可以看 README.md 所写内容，但除此之外，最重要的还是内容；如果你能提供改进的建议或者手册页，那么即使是纯文本方式贴上来也完全可以。

[playNoA]

还是transifex简单，我尽量学下GitHub

[hosiet]

朋友，transifex 要钱（

[playNoA]

O(∩_∩)O哈哈~，怪不得

[liao20081228]

你好，其实目前我积累了大量的手册页，最近忽然发现这个项目，我想知道的是Linux的man手册页究竟是如何生成的？需要按照什么语法？

[onlinelei]

如果您对某个手册页做了翻译或翻译的改进，您可以提交一份完整的手册页以便收录。 为保证您的手册页起到最大作用，请确认其内容可以使用 GFDL-1.2+ 兼容的授权协议， 并在向本项目提交前先与上游联系以确认能否被上游收录。

上面这句话中被上游收录是什么意思

[hosiet]

有些软件本身便计划提供多语言的手册页，但限于无人翻译而并未提供。在这种情况下，应当按照上游项目本身的翻译流程在上游直接翻译并生成对应的手册页而无需涉及其它项目（例如本仓库）。

[Freed-Wu]

我想知道的是Linux的man手册页究竟是如何生成的？需要按照什么语法？

https://medium.com/theconsole/unix-typesetting-resources-5dd62c8a4d2c

我觉得 nroff 对大多数人可能还是偏难了，为何不考虑像exa 一样改成 markdown 然后用 pandoc 生成 man 手册？或者像nmap 一样用 xml 生成 man 手册?

最重要的还是内容

现在 chatGPT 这么流行，干脆用 chatGPT 来辅助翻译好啦。。。

[hosiet]

• 如何生成手册页和本项目完全无关，本项目只管翻译。如何生成手册页是上游项目（软件原作者）关心的事情。
• 翻译工作流目前来看 po4a 最靠谱，包括 https://manpages-l10n-team.pages.debian.net/manpages-l10n/ 同样采用类似的工作流。
• 翻译内容机器翻译还是手工翻译没有本质区别，但机器翻译太容易破坏 roff 语法，至少需要手工校对。
• 本项目没有合并进入 manpages-l10n 项目的主要原因是需要 opencc 处理中文变体，但如果可以处理好的话统一进相同框架也是可以的。

[Freed-Wu]

本项目没有合并进入 manpages-l10n 项目的主要原因是需要 opencc 处理中文变体，但如果可以处理好的话统一进相同框架也是可以的。

看起来把这个项目合并到 https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/tree/master/po 可能比单独维护更好

[Freed-Wu]

翻译内容机器翻译还是手工翻译没有本质区别，但机器翻译太容易破坏 roff 语法，至少需要手工校对。

po4a 生成的 msgid 把原来 roff 格式全部替换为 pod 了。机器翻译很容易破坏 pod 的内部序列，比如：

As with the commands described in Section 1, the commands described in this section terminate with an exit status that indicates whether the command succeeded or failed. See B<intro>(1) for more information.

google translate:

与第 1 节中描述的命令一样，本节中描述的命令以退出状态终止，该退出状态指示命令是成功还是失败。 有关详细信息，请参阅 B<简介>(1)。

这里的 B(1) 不该翻译。

对 ChatGPT 之类的大语言模型，如果输入好的 prompt ，例如 "请将以下 perlpod 文档从英文翻译为中文，保留内部序列前后的空格，只输出翻译结果":

与第1节中描述的命令一样，本节中描述的命令也以表示命令成功或失败的退出状态终止。有关更多信息，请参见 B(1)。

对于 perlpod 的内部序列占多数的 msgid, 例如

B<blkid> [B<--no-encoding> B<--garbage-collect> B<--list-one> B<--cache-file> I<file>] [B<--output> I<format>] [B<--match-tag> I<tag>] [B<--match-token> I<NAME=value>] [I<device>...]

google translate:

B [B<--无编码> B<--垃圾收集> B<--list-one> B<--缓存文件> I<文件>] [B<--输出> I <格式>] [B<--匹配标签> I<标签>] [B<--匹配令牌> I<名称=值>] [I<设备>...]

这里的 --no-encoding, --garbage-collect, ... 都是命令行选项，不该被翻译。

使用同样的 prompt "请将以下 perlpod 文档从英文翻译为中文，保留内部序列前后的空格，只输出翻译结果":

B命令 [B<--no-encoding> B<--garbage-collect> B<--list-one> B<--cache-file> I] [B<--output> I] [B<--match-tag> I] [B<--match-token> I] [I...]

会生成一些原先不存在的词，比如 '命令'。但不排除换用更好的 prompt 能否解决这个问题。

第二个问题是访问问题。OpenAI 提供的 API 接口访问随着是否付费有每天 200 或 2000 次的限制，而 整个 manpages 项目下搜索 msgid 能搜到 24 万条需要翻译的 msgid 。仅靠 OpenAI 提供的 API 接口会频繁的触发上限 "Access is limited". 开源的大语言模型 LLaMA 也有测试，但在本地部署实时性其式比使用 OpenAI 提供的 API 接口更差，而且目前还很不成熟，类似 segmentation fault 之类的 bug 仍有发生。

目前仍然看不到解决这些问题的最好方案。