clsty
1
背景
Hyprland 是当前 Linux 下最美观且强大的 WM/Compositor 之一。
它的官方文档 hyprland-wiki 的内容非常丰富，是 Linuxer 使用 Hyprland 自定义桌面环境的重要资料——但是，没有中文，频繁查看还是比较不便的。
好在，它的仓库是开放的，许可为BSD-3-Clause，这就为翻译 Hyprland-wiki 创造了条件。
现状分析
首先看内容。
-
此仓库中的 md 文件分散在各目录下，明明没有排序，但网站内却是有排序的。
-
每个 md 文件的开头都没有 frontmatter，比如这篇。
-
md 文件内似乎有自定义的短代码（比如 {{< toc >}}），那么后端就有可能是 Hugo。
再看 GitHub Actions 的 workflow 文件。
其中引用了 “hyprwm/hyprland-wiki-backend” 这个私有仓库。
综上可以合理猜测，Hyprland Wiki 在源文件更新后，通过 GitHub Actions 推送到某私有仓库，在此仓库中自动添加 frontmatter，并使用 Hugo 生成静态站点。
（更新：实际上它确实是 Hugo，见此 issue 中 fufexan 所说的“So far I see no reason to switch from Hugo.”。）
目标与难点
创建一个 GitHub 仓库，名称可以为“hyprland-wiki-l10n”之类的。
要求达成以下目的：
- 支持多语言，能够在本地预览网站，并在 GitHub Pages 上部署网站。
- 这个用 Hugo 或 Starlight 都可以。
- 使用固有 frontmatter 而不必自动化添加（否则不便于本地预览），但是部分短代码最好要实现（比如
{{< hint type=warning >}} {{< /hint >}}）。
- 但这也不是必须的，因为某些 Hugo 主题内置效果类似的短代码，Starlight 同理。
- 正确处理站内链接，比如
pages/Configuring/Dispatchers.md 中有个链接是 ../Binds/#submaps，对应的文件是 pages/Configuring/Binds.md。
- 一般来说，这是默认行为。稍微注意一下，别出错就行。
- 在生成站点的每个网页开头，自动反映出原文与翻译版本的时间差异，比如像 ArchWiki 的简体中文页面开头：
翻译状态：
-
- 不过这其实也不是大问题，因为可以在每次翻译时手动更新这个日期，并不需要自动化显示英语原文的日期。
针对上述问题，希望大家能给点提示或意见，谢谢。
3 个赞
clsty
2
我发现最大的问题可能还是翻译的自动化问题。
首先，如果有类似于 weblate 那种辅助平台，避开对于常人来说较为复杂的 git 工作流，就能让更多人参与进来，减轻工作量。（但是我记得 weblate 是那种字符串的，可能不适合这种长篇文档）
其次，如果能仅翻译改变的部分（比如在译本的开头标上原文对应的 git commit hash 值，用脚本自动匹配这个值，然后左边打开译本，右边打开针对此 commit 下此文件改变的 git diff），也能降低追踪压力。（但是终端里的 git diff 太原始了，红红绿绿地看着眼花。或许要调整下配色）
需要注意 hyprland-wiki 的显著特点：更新频率快，文本量大，文件数多。
为了走在地上不脏脚，与其铺路不如穿鞋 
考虑到文档更新频繁，也许写自己的教程然后引用文档会更好一些，当然个人看法罢了。
翻译流程弄好了确实可以让更多的人参与进来，不过这方面我也没什么经验。不过具体的翻译工作可以考虑用用 ChatGPT，我试过，效果非常不错。
2 个赞
clsty
4
谢谢建议！
教程加引用文档，对于入门来说很不错，不过我既然要翻译 wiki，其实就是想进阶一下，来个全面一点的参考。
人工智能辅助加人工校对，效果确实很不错，Linux 中国（顺便怀念一下）之前也是这么做的。
不过这是具体翻译时要考虑的问题，我不打算将其算到基础方案里面。
clsty
5
补充一下，
我目前翻译字符串类型的经验比较多：
- archinstall 和 paru，两个都是 Arch Linux 相关
- 还有 uhuru photos
长文档的翻译经验，
建静态站点的经验，
我觉得 hyprland 与我之前的这些经验都不同的一点是，它的量太大了，必须加强自动化。
上面我说的那个在文档开头自动加 commit hash 那个我想了下，可行性应该还挺好。
用 Hugo 短代码大概可以实现半自动化（把 hash 值当参数），自动生成一个命令放到代码块里，点一下复制按钮，粘贴运行之后，就能在终端里显示英语原文的变动了。
不过我 Hugo 刚入门，短代码其实并没有经验。
另外还要考虑一下 Hugo 主题要选什么，至少三个标准：
- 多语言
- 为文档设计，或者说有一个显示所有文章的树状导航栏，一般是左侧边栏。
- 搜索支持中文（Pagefind 和 FlexSearch 应该都行，Lunr.js 不行）
同时符合这些要求的 Hugo 主题其实不太好找，因为 Hugo 官网的主题列表只能每次只能筛选一个条件，而且有一些其实是支持多语言（Multilingual）的但是它没放到 Tags 里面就找不到。
目前已知同时符合这些条件的 Hugo 主题有：
不过说到这里，我干脆建个 issue 好了，请 hyprland 官方支持多语言（反正都打算用 lotusdocs 了，对吧）
2 个赞
clsty
6
更新：issue 已关闭。
vaxerski 说 Hyprland 更新速度太快了，翻译很快会过时。
We’ve had like at least 3 breaking changes in your config alone since latest release 0.35 like 2-3 weeks ago.
对于不能接受文档（哪怕是翻译版本）中有过时部分，这一点我倒是很能理解。而且，如果没有这样的高要求，恐怕就不会有 Hyprland 今天这种更新速度和丰富的功能。
但是，说真的，我作为 Hyprland 用户（我的配置在这里）其实没怎么感知到这一点，反而是每次阅读 Hyprland-wiki 时都真真切切地感受到了英语的晦涩难懂。
即使是容易过时的翻译，对于我以及其他用户来说，在理解这个现状的前提下，我想也是有参考意义的。
所以我的第三方翻译还是要进行下去。而且在机翻+人工校准的工作流下，效率不见得会多差（？）
只需要做 zh-CN 就好了（至于其他语言的，谁想做谁做去），所以这实际上是个 wiki 的第三方汉化。
Hugo 主题可能还是选 lotusdocs。
另外此 Wiki 上线时必须要做好说明：
- 这是个非官方的翻译版本，仅供参考。
- Hyprland 更新速度非常快，所以此 Wiki 中任何一页的过时可能性都很高。
- 如前面所说的，要在每页开头把中文版本的上次更新时间及对应的 commit hash 显示出来。
总之，如果一切正常的话，一段时间之后，大家可能会看到 demo 站（也可能不会）。
3 个赞
说到翻译，最近看了看 emacs-devel，现在 emacs 里面已经有一份 ses 的法语翻译了：
emacs/doc/translations/fr/misc/ses-fr.texi at master
emacs 也为翻译添加了一些规范：
Add README file about translations of Emacs manuals · emacs-mirror/emacs@aa8baf7
（具体的讨论可以看看 emacs-devel 从 23 年的 12 月到 2 月的归档）
两年前论坛上好像有人完成了 emacs lisp manual 的翻译： advanceflow/Elisp，这是帖子： Elisp28.1中文文档1.0 - Emacs-Lisp，不过具体的翻译内容我没有细看，某些术语感觉可能不翻译的话会更好一点，比如 kill ring。
相比于 ses 这个很多年都没什么变化的文档，elisp manual 改动比较频繁，要维护下去的话费力不少。在法国人注意到之前这个 ses 的文档很多年都没怎么改了：
2 个赞
