Kde.org已迁移到Hugo

KDE.org现在使用Hugo。Hugo是一个用围棋编写的快速而现代的静态站点生成器。与使用纯PHP的旧系统相比，它提供了一些改进。很大一部分工作是由Anuj在GSOC 2020期间完成的。这是一项巨大的工作，要转换存储了20多年KDE历史的存储库。

网站现在只生成一次，不再使用PHP在运行时自动生成，这提高了网站的加载速度，但速度提升并不明显，因为以前使用的PHP代码非常小，而且KDE的服务器功能强大。

但最大的改进是在功能方面。我们现在使用的是markdownfile而不是原始的HTML文件，这使得宣传团队的生活变得容易得多。

网站的内部化现在为每种语言创建了一个唯一的URL，这应该允许Google使用正确的语言链接到网站的版本。法语、乌克兰语、加泰罗尼亚语、荷兰语和其他几种语言已经可用。还有一个合适的语言选择器！我们也不需要手动标记每个字符串以进行翻译。

现在还有一个RSS订阅源，上面有所有最新的公告。另一个重大改进是公告列表是自动生成的，不再需要手动修改，也不再需要在发布脚本的帮助下修改。

对于网站开发人员来说，另一个很好的改变是，现在单个页面的SCSS代码位于kde-org存储库本身，而不是其他存储库。总体来说，开发人员的体验要好得多，不需要设置一个缓存服务器和PHP配置来包括容量框架，只需让网站在本地运行即可。现在您只需要从他们的发布页面下载Hugo二进制文件，并在repo上运行它。

KDE.org的内部化是一个相当大的挑战。当与Hugo一起处理多语言网站时，Hugo希望每个翻译页面都有一个每种语言的标记文档。

问题是，传统翻译工作流希望使用基于字符串的方法，即将文档拆分成段落并单独翻译。因此，我不能将每个文件标记为po文件中的大BLOB。为了解决这个问题，我创建了一个Python脚本，将标记文件拆分成段落，简化了标记语法(去掉了标题和列表项的前导#和+)。此脚本还处理Hugo短码转换：

脚本可以不知不觉地将各个字符串放回原位。目前，脚本只是kde-org存储库中的一个文件，但我想将其转换为独立库，以便其他gettext和Hugo用户可以翻译他们的网站。

<；ul class="；navbar-nav ml-AUTO"；>；{{if.IsTranslated}}<；li class="；nav-item下拉菜单"；aria-describedby="；language-picker-description"；>；<；p class="；sr-only"；id="；language-picker-description"；>；{{i18n"；选择您的语言"；}}<；/p>；<；A class="；nav-link下拉切换="；href="；#"；数据切换="；下拉"；角色="；按钮"；aria-haspopup="；true"；aria-Expanded="；false"；>；<；img src="；/Language-Icons/icon20x24px-exported-transparent.png"；alt="；"；/>；<；span>；{{i18n"；翻译"；}}<；/span>；<；/a>；<；div class="；Dropdown-Menu Dropdonw-trans&34；Role="；listbox"；>；<；a class="；aria-Selected="；true"；hrefang="；{{.Site.Language.lang}}"；Role="；Option"；lang="；{{.Site.Language.Lang}}"；href="；{{.Permalink}}"；>；{{.Site.Language.LanguageName}}<；/a>；{{range.Translations}}<；a class="；DropDown-Item"；hrefang="；{{.Language.Lang}}"；Role="；Option"；lang="；{{.Language.Lang}}"；href="；{{.Permalink}}"；>；{{.Language.LanguageName}}<；/a>；{{end}}<；/div>；<；/li>；{{end}}<；/ul>；

这有点冗长，因为屏幕阅读器也可以完全访问此选择器。

在kde.org中使用了更多的技巧来提高内部化，例如，当页面不存在于语言中时，有一条Apache规则将其重定向到英文版本。另一个好把戏是有一个特殊的Hugo短编码i18n_var，用于参数化字符串。例如：

{{<；i18n_var"；今天KDE发布了对KDE等离子体5版本%[1]s"；"；5.20.2"；>；}的错误修复更新}。

而且提取器很聪明，只提取需要翻译的部分。