@node 贡献
@chapter 贡献

本项目是团体合作成果，我们需要您的帮助以更好地发展。请通过 @email{guix-devel@@gnu.org} 邮箱和 Libera Chat
IRC 网络上的 @code{#guix} 频道联系我们。我们欢迎您的想法、Bug
反馈、补丁和任何可能对项目有帮助的贡献。我们特别欢迎帮助我们打包（@pxref{打包指导}）。

@cindex 行为准则和贡献者
@cindex 贡献者契约
我们希望提供一个温暖、友好，并且没有骚扰的的环境，这样每个人都能尽最大努力贡献。为了这个目的，我们的项目遵循“贡献者契约”，这个契约是根据
@url{https://contributor-covenant.org/} 制定的。你可以在源代码目录里的
@file{CODE-OF-CONDUCT} 文件里找到一份本地版。

贡献者在提交补丁和网上交流时不需要使用法律认可的名字。他们可以使用任何名字或者假名。

@menu
* 从Git构建::             最新的并且最好的。
* 在安装之前运行Guix::  黑客技巧。
* 完美的配置::          正确的工具。
* 打包指导::             帮助发行版成长。
* 代码风格::             出资者的卫生状况。
* 提交补丁::             分享你的工作。
* 跟踪程序漏洞和补丁::  保持井井有条。
* 提交权利::             推送到管方的仓库。
* 更新Guix软件包::      更新Guix的软件包定义。
* 撰写文档::             完善GNU Guix中的文档。
* 翻译 Guix::              用您的母语翻译 Guix。
@end menu

@node 从Git构建
@section 从Git构建

如果你想折腾Guix本身，建议使用Git仓库里最新的版本：

@example
git clone https://git.savannah.gnu.org/git/guix.git
@end example

@cindex authentication, of a Guix checkout
如何确保您获得了存储库的真实副本？为此，运行@command{guix git authenticate}，将@dfn{channel
introduction}（@pxref{调用guix git授权}）的提交和OpenPGP指纹传递给它：

@c ===========================================================================
@c
@c This file was generated with po4a. Translate the source file.
@c
@c ===========================================================================

@c The commit and fingerprint below must match those of the channel
@c introduction in '%default-channels'.
@example
git fetch origin keyring:keyring
guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad \
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
@end example

@noindent
此命令完成，若成功退出代码为零；否则打印一条错误消息，以非零代码退出。

如你所见，存在一个先有鸡还是蛋的问题：首先你需要安装Guix。更多情况，您将在另一个发行版（@pxref{系统安装}）上安装Guix系统（@pxref{二进制文件安装}）或Guix；但无论如何，您都需要在安装介质上验证OpenPGP签名。这“保证”了信任链。

设置Guix开发环境的最简单的方式当然是使用Guix！下面这些命令启动一个shell，所有的依赖和环境变量都为折腾Guix设置好了：

@example
guix shell -D guix --pure
@end example

@xref{Invoking guix shell}, for more information on that command.

当从Git检出构建Guix时无法使用Guix，除安装指导（@pxref{需求}）里提及的软件包之外还需要这些包。

@itemize
@item @url{https://gnu.org/software/autoconf/, GNU Autoconf};
@item @url{https://gnu.org/software/automake/, GNU Automake};
@item @url{https://gnu.org/software/gettext/, GNU Gettext};
@item @url{https://gnu.org/software/texinfo/, GNU Texinfo};
@item @url{https://www.graphviz.org/, Graphviz};
@item @url{https://www.gnu.org/software/help2man/, GNU Help2man（可选）}。
@end itemize

On Guix, extra dependencies can be added by instead running @command{guix
shell}:

@example
guix shell -D guix help2man git strace --pure
@end example

From there you can generate the build system infrastructure using Autoconf
and Automake:

@example
引导
@end example

If you get an error like this one:

@example
configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
@end example

@noindent
它可能意味着Autoconf无法找到由pkg-config提供的@file{pkg.m4}。请确保@file{pkg.m4}可用。由Guile提供的@file{guile.m4}宏也类似。假如你的Automake安装在@file{/usr/local}，那么它不会从@file{/usr/share}里寻找@file{.m4}文件。这种情况下，你必须执行下面这个命令：

@example
export ACLOCAL_PATH=/usr/share/aclocal
@end example

参考@xref{Macro Search Path,,, automake, The GNU Automake Manual}.

Then, run:

@example
./configure --localstatedir=/var
@end example

@noindent
... where @file{/var} is the normal @code{localstatedir} value (@pxref{仓库}, for information about this).  Note that you will probably not run
@command{make install} at the end (you don't have to)  but it's still
important to pass the right @code{localstatedir}.

Finally, you can build Guix and, if you feel so inclined, run the tests
(@pxref{运行测试套件}):

@example
make
make check
@end example

@noindent
If anything fails, take a look at installation instructions
(@pxref{安装}) or send a message to the @email{guix-devel@@gnu.org,
mailing list}.

From there on, you can authenticate all the commits included in your
checkout by running:

@example
make authenticate
@end example

The first run takes a couple of minutes, but subsequent runs are faster.

Or, when your configuration for your local Git repository doesn't match the
default one, you can provide the reference for the @code{keyring} branch
through the variable @code{GUIX_GIT_KEYRING}.  The following example assumes
that you have a Git remote called @samp{myremote} pointing to the official
repository:

@example
make authenticate GUIX_GIT_KEYRING=myremote/keyring
@end example

@quotation 注
You are advised to run @command{make authenticate} after every @command{git
pull} invocation.  This ensures you keep receiving valid changes to the
repository.
@end quotation

After updating the repository, @command{make} might fail with an error
similar to the following example:

@example
error: failed to load 'gnu/packages/dunst.scm':
ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <origin>>: record ABI mismatch; recompilation needed
@end example

This means that one of the record types that Guix defines (in this example,
the @code{origin} record) has changed, and all of guix needs to be
recompiled to take that change into account.  To do so, run @command{make
clean-go} followed by @command{make}.

@node 在安装之前运行Guix
@section 在安装之前运行Guix

为了保持一个合适的工作环境，你会发现在你的本地代码树里测试修改而不用安装它们会很有用。TODO: So that you can distinguish
between your ``end-user'' hat and your ``motley'' costume.

To that end, all the command-line tools can be used even if you have not run
@code{make install}.  To do that, you first need to have an environment with
all the dependencies available (@pxref{从Git构建}), and then simply
prefix each command with @command{./pre-inst-env} (the @file{pre-inst-env}
script lives in the top build tree of Guix; it is generated by running
@command{./bootstrap} followed by @command{./configure}).  As an example,
here is how you would build the @code{hello} package as defined in your
working tree (this assumes @command{guix-daemon} is already running on your
system; it's OK if it's a different version):

@example
$ ./pre-inst-env guix build hello
@end example

@noindent
同样，一个使用 Guix 模块的 Guile 会话的例子：

@example
$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'

;;; ("x86_64-linux")
@end example

@noindent
@cindex REPL
@cindex read-eval-print loop
@dots{} and for a REPL (@pxref{Using Guix Interactively}):

@example
$ ./pre-inst-env guile
scheme@@(guile-user)> ,use(guix)
scheme@@(guile-user)> ,use(gnu)
scheme@@(guile-user)> (define snakes
                       (fold-packages
                         (lambda (package lst)
                           (if (string-prefix? "python"
                                               (package-name package))
                               (cons package lst)
                               lst))
                         '()))
scheme@@(guile-user)> (length snakes)
$1 = 361
@end example

If you are hacking on the daemon and its supporting code or if
@command{guix-daemon} is not already running on your system, you can launch
it straight from the build tree@footnote{The @option{-E} flag to
@command{sudo} guarantees that @code{GUILE_LOAD_PATH} is correctly set such
that @command{guix-daemon} and the tools it uses can find the Guile modules
they need.}:

@example
$ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
@end example

@command{pre-inst-env}脚本设置为此好了所有必要的的环境变量，包括@env{PATH}和@env{GUILE_LOAD_PATH}。

@command{./pre-inst-env guix pull} @emph{不}
会更新本地源代码树，它只更新符号链接@file{~/.config/guix/current} (@pxref{调用guix pull})。如果你想更新本地源代码树，请运行@command{git pull}。

Sometimes, especially if you have recently updated your repository, running
@command{./pre-inst-env} will print a message similar to the following
example:

@example
;;; note: source file /home/user/projects/guix/guix/progress.scm
;;;       newer than compiled /home/user/projects/guix/guix/progress.go
@end example

This is only a note and you can safely ignore it.  You can get rid of the
message by running @command{make -j4}.  Until you do, Guile will run
slightly slower because it will interpret the code instead of using prepared
Guile object (@file{.go}) files.

You can run @command{make} automatically as you work using
@command{watchexec} from the @code{watchexec} package.  For example, to
build again each time you update a package file, run @samp{watchexec -w
gnu/packages -- make -j4}.

@node 完美的配置
@section 完美的配置

折腾 Guix 的完美配置也是折腾 Guile 的完美配置 @pxref{Using Guile in Emacs,,, guile, Guile
Reference Manual})。首先，你需要的不仅是一个编辑器，你需要
@url{https://www.gnu.org/software/emacs, Emacs}，以及美妙的
@url{http://nongnu.org/geiser/, Geiser}。为此，运行：

@example
guix install emacs guile emacs-geiser emacs-geiser-guile
@end example

Geiser 允许在 Emacs 里进行交互式的、增长式的开发：buffer 里的代码补全和执行，获取一行的文档
(docstrings)，上下文敏感的补全，@kbd{M-.} 跳转到对象定义，测试代码的
REPL，及更多（@pxref{介绍,,, geiser, Geiser User Manual}）。为了方便的 Guix
开发，请确保修改 Guile 的加载路径 (load path) 以使其能从你的项目里找到源代码文件：

@lisp
;; @r{假设Guix项目在 ~/src/guix.}
(with-eval-after-load 'geiser-guile
  (add-to-list 'geiser-guile-load-path "~/src/guix"))
@end lisp

真正编辑代码时别忘了 Emacs 自带了方便的 Scheme 模式。而且，一定不要错过
@url{https://www.emacswiki.org/emacs/ParEdit, Paredit}。它提供了直接操作语法树的的功能，例如，用
S- 表达式替换父节点，为 S- 表达式添加、删除前后的括号，删除后面的 S- 表达式，等等。

@cindex 代码片段
@cindex 模板
@cindex 减少样板
We also provide templates for common git commit messages and package
definitions in the @file{etc/snippets} directory.  These templates can be
used to expand short trigger strings to interactive text snippets. If you
use @url{https://joaotavora.github.io/yasnippet/, YASnippet}, you may want
to add the @file{etc/snippets/yas} snippets directory to the
@var{yas-snippet-dirs} variable.  If you use
@url{https://github.com/minad/tempel/, Tempel}, you may want to add the
@file{etc/snippets/tempel/*} path to the @var{tempel-path} variable in
Emacs.

@lisp
;; @r{Assuming the Guix checkout is in ~/src/guix.}
;; @r{Yasnippet configuration}
(with-eval-after-load 'yasnippet
  (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets/yas"))
;; @r{Tempel configuration}
(with-eval-after-load 'tempel
   ;; Ensure tempel-path is a list -- it may also be a string.
   (unless (listp 'tempel-path)
     (setq tempel-path (list tempel-path)))
   (add-to-list 'tempel-path "~/src/guix/etc/snippets/tempel/*"))
@end lisp

commit信息片段显示staged文件需要依赖@url{https://magit.vc/,
Magit}。编辑commit信息时，输入@code{add}，然后按@kbd{TAB}就可以插入一段用于新增软件包的模板；输入@code{update}，然后按@kbd{TAB}可以插入一段更新软件包的模板；输入@code{https}然后按@kbd{TAB}可以插入一段修改主页URI为HTTPS的模板。

@code{scheme-mode}最重要的模板可以通过输入@code{package...}，然后按@kbd{TAB}触发。这个片段还插入了触发字符串@code{origin...}，以进一步展开。@code{origin}片段更进一步的可能插入其它以@code{...}结尾的触发字符串，它们可以被继续展开。

@cindex insert or update copyright
@cindex @code{M-x guix-copyright}
@cindex @code{M-x copyright-update}
We additionally provide insertion and automatic update of a copyright in
@file{etc/copyright.el}.  You may want to set your full name, mail, and load
a file.

@lisp
(setq user-full-name "Alice Doe")
(setq user-mail-address "alice@@mail.org")
;; @r{Assuming the Guix checkout is in ~/src/guix.}
(load-file "~/src/guix/etc/copyright.el")
@end lisp

To insert a copyright at the current line invoke @code{M-x guix-copyright}.

To update a copyright you need to specify a @code{copyright-names-regexp}.

@lisp
(setq copyright-names-regexp
      (format "%s <%s>" user-full-name user-mail-address))
@end lisp

You can check if your copyright is up to date by evaluating @code{M-x
copyright-update}.  If you want to do it automatically after each buffer
save then add @code{(add-hook 'after-save-hook 'copyright-update)} in Emacs.

@node 打包指导
@section 打包指导

@cindex 软件包, 创建
这个GNU发行版正在开发的早期阶段，可能缺少一些你喜欢的软件。这个章节介绍你可以怎样帮助这个发行版成长。

自由软件通常以@dfn{源代码包}的形式分发，通常是包含完整代码的@file{tar.gz}包。添加软件包到这个发行版意味着两件事：添加描述如何构建包的@dfn{配方}和一系列依赖软件，以及添加配方之外的@dfn{软件包元数据}，如一段文字描述和证书信息。

在Guix里所有这些信息都包含在@dfn{软件包定义}里。软件包定义提供了软件包的高层视角。它们使用Scheme编程语言编写，事实上，对每个软件包我们都定义一个绑定到软件包定义的的变量，并且从模块（@pxref{软件包模块}）中导出那个变量。然而，深入的Scheme知识@emph{不}是创建软件包的前提条件。若要了解软件包的更多信息，@pxref{定义软件包}。

一旦软件包定义准备好了，并且包存在Guix代码树的一个文件里，你可以用@command{guix build} (@pxref{调用guix build})命令测试它。假设这个新软件包的名字叫做@code{gnew}，你可以在Guix构建树里运行这个命令(@pxref{在安装之前运行Guix})：

@example
./pre-inst-env guix build gnew --keep-failed
@end example

使用@code{--keep-failed}参数会保留失败的构建树，这可以使调试构建错误更容易。@code{--log-file}也是一个调试时很有用的参数，它可以用来访问构建日志。

如果@command{guix}命令找不到这个软件包，那可能是因为源文件包含语法错误，或者缺少导出软件包的@code{define-public}语句。为了查找错误，你可以用Guile导入这个模块以了解这个错误的详情：

@example
./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
@end example

Once your package builds correctly, please send us a patch
(@pxref{提交补丁}).  Well, if you need help, we will be happy to
help you too.  Once the patch is committed in the Guix repository, the new
package automatically gets built on the supported platforms by
@url{https://@value{SUBSTITUTE-SERVER-1}, our continuous integration
system}.

@cindex substitutes
Users can obtain the new package definition simply by running @command{guix
pull} (@pxref{调用guix pull}).  When @code{@value{SUBSTITUTE-SERVER-1}}
is done building the package, installing the package automatically downloads
binaries from there (@pxref{substitutes}).  The only place where human
intervention is needed is to review and apply the patch.


@menu
* 软件自由::             什么可以进入这个发行版。
* 软件包命名::          名字里包含什么？
* 版本号::                当名字不够时。
* 简介和描述::          帮助用户寻找合适的软件包。
* Snippets versus Phases::   Whether to use a snippet, or a build phase.
* Emacs Packages::           Your Elisp fix.
* Python模块::             接触英式的喜剧。
* Perl模块::               小珍珠。
* Java包::                  喝咖啡休息。
* Rust Crates::              谨防氧化。
* Elm Packages::             Trees of browser code
* 字体::                   字体的乐趣。
@end menu

@node 软件自由
@subsection 软件自由

@c Adapted from http://www.gnu.org/philosophy/philosophy.html.
@cindex 自由软件
开发 GNU
操作系统是为了用户拥有计算的自由。GNU是@dfn{自由软件}，这意味着它有@url{https://www.gnu.org/philosophy/free-sw.html,四项重要的自由}：运行程序的自由，以源代码形式学习和修改程序的自由，原样重新分发副本的自由，和分发修改后的版本的自由。GNU
发行版里包含的软件包只提供遵守这四项自由的软件。

此外，GNU
发行版遵循@url{https://www.gnu.org/distros/free-system-distribution-guidelines.html,自由软件发行版准则}。这些准则拒绝非自由的固件和对非自由软件的推荐，并讨论解决商标和专利的方法。

某些上游的软件包源代码包含一小部分违反上述准则的可选的子集，比如这个子集本身就是非自由代码。这时，这些讨厌的代码需要用合适的补丁或者软件包定义（@pxref{定义软件包}）里的@code{origin}里的代码片段移除。这样，@code{guix build
--source}就可以返回自由的源代码而不是未经修改的上游源代码。


@node 软件包命名
@subsection 软件包命名

@cindex 软件包名字
一个软件包事实上有两个名字：第一个是@emph{Scheme变量}的名字，即用@code{define-public}定义的名字。通过这个名字，软件包可以被Scheme代码找到，如用作其它软件包的输入。第二个名字是软件包定义里的@code{name}属性的字符串值。这个名字用于软件包管理命令，如：@command{guix
package}，@command{guix build}。

两个名字通常是相同的，常是上游项目名字转成小写字母并把下划线替换成连字符的结果。比如，GNUnet转成@code{gnunet}，SDL_net转成@code{sdl-net}。

A noteworthy exception to this rule is when the project name is only a
single character, or if an older maintained project with the same name
already exists---regardless of whether it has already been packaged for
Guix.  Use common sense to make such names unambiguous and meaningful.  For
example, Guix's package for the shell called ``s'' upstream is
@code{s-shell} and @emph{not} @code{s}.  Feel free to ask your fellow
hackers for inspiration.

我们不给库软件包添加@code{lib}前缀，除非它是项目官方名字的一部分。但是@pxref{Python模块}和@ref{Perl模块}有关于Python和Perl语言的特殊规则。

字体软件包的名字处理起来不同，@pxref{字体}.


@node 版本号
@subsection 版本号

@cindex 软件包版本
我们通常只为每个自由软件的最新版本打包。但是有时候，比如对于版本不兼容的库，需要有同一个软件包的两个或更多版本。它们需要使用不同的Scheme变量名。我们为最新的版本使用@ref{软件包命名}里规定的名字，旧的版本使用加上后缀的名字，后缀是@code{-}和可以区分开版本号的版本号的最小前缀。

软件包定义里的名字对于同一个软件包的所有版本都是相同的，并且不含有版本号。

例如，GTK+的2.24.20和3.9.12两个版本可以这样打包：

@lisp
(define-public gtk+
  (package
    (name "gtk+")
    (version "3.9.12")
    ...))
(define-public gtk+-2
  (package
    (name "gtk+")
    (version "2.24.20")
    ...))
@end lisp
如果我们还需要GTK+ 3.8.2，就这样打包
@lisp
(define-public gtk+-3.8
  (package
    (name "gtk+")
    (version "3.8.2")
    ...))
@end lisp

@c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
@c for a discussion of what follows.
@cindex 用于版本控制快照的版本号
有时候，我们为软件包上游的版本控制系统（VCS）的快照而不是正式发布版打包。这是特殊情况，因为决定哪个是稳定版的权力应该属于上游开发者。然而，有时候这是必须的。那么，我们该如何决定写在@code{version}里的版本号呢？

显然，我们需要让VCS快照的commit ID在版本号中体现出来，但是我们也需要确保版本号单调递增，以便@command{guix package
--upgrade}决定哪个版本号更新。由于commit ID，尤其是Git的commit
ID，不是单调递增的，我们添加一个每次升级快照时都手动增长的revision数字。最后的版本号字符串看起来是这样：

@example
2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- 上游的commit ID
  |    |
  |    `--- Guix软件包的revision
  |
最新的上游版本号
@end example

把@code{版本号}里的commit
ID截短，比如只取7个数字，是一个好主意。它避免了美学上的烦恼（假设美学在这里很重要），以及操作系统限制引起的问题（比如Linux内核的127字节）。尽管如此，在@code{origin}里最好使用完整的commit
ID，以避免混淆。通常一个软件包应该看起来是下面这样：


@lisp
(define my-package
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;Guix软件包的revision
    (package
      (version (git-version "0.9" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "git://example.org/my-package.git")
                      (commit commit)))
                (sha256 (base32 "1mbikn@dots{}"))
                (file-name (git-file-name name version))))
      ;; @dots{}
      )))
@end lisp

@deffn {Scheme Procedure} git-version @var{VERSION} @var{REVISION} @var{COMMIT}
Return the version string for packages using @code{git-fetch}.

@lisp
(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
@result{} "0.2.3-0.93818c9"
@end lisp
@end deffn

@deffn {Scheme Procedure} hg-version @var{VERSION} @var{REVISION} @var{CHANGESET}
Return the version string for packages using @code{hg-fetch}.  It works in
the same way as @code{git-version}.
@end deffn

@node 简介和描述
@subsection 简介和描述

@cindex 软件包描述
@cindex 软件包简介
我们已经看到，GNU@tie{}Guix里的每个软件包都包含一个简介（synopsis）和一个描述（description）（@pxref{定义软件包}）。简介和描述很重要：它们是@command{guix package
--search}搜索的信息，并且是帮助用户决定一个软件包是否符合自己需求的重要信息。因此，打包的人应该关注怎样写它们的内容。

简介必须以大写字母开头，并且不能以句号结尾。它们不能以 ``a'' 或者 ``the'' 等没有意义的词开头。例如 ``File-frobbing
tool'' 要比 ``A tool that frobs files'' 更好。简介需要说明软件包是什么－－如 ``Core GNU
utilities (file, text, shell)''，或者它的用途－－如 GNU@tie{}grep 的简介是 ``Print lines
matching a pattern''。

记住，简介必须能被广大的听众理解。例如，“以SAM格式修改对齐”可能对经验丰富的生物信息科研工作者来说能理解，但是对普通对听众则是无用的甚至是令人误解的。简介最好说明软件包应用的领域。在这个例子中，应该这样描述“修改核苷酸序列的对齐格式”，这会让用户更容易判断这是不是他们想要的。

描述应该在5至10句话之间。使用完整的句子，并且避免在未介绍的情况下使用缩写。请避免推广营销性对词汇，如“世界领先”，“行业最强”，“下一代”，并且避免高级的形容词，如“最先进的”--他们对用户寻找软件包是无用的，甚至是可疑的。相反的，尽量务实，提及用例和功能。

@cindex 软件包描述里的Texinfo标记
Descriptions can include Texinfo markup, which is useful to introduce
ornaments such as @code{@@code} or @code{@@dfn}, bullet lists, or hyperlinks
(@pxref{Overview,,, texinfo, GNU Texinfo}).  However you should be careful
when using some characters for example @samp{@@} and curly braces which are
the basic special characters in Texinfo (@pxref{Special Characters,,,
texinfo, GNU Texinfo}).  User interfaces such as @command{guix show} take
care of rendering it appropriately.

Synopses and descriptions are translated by volunteers
@uref{https://translate.fedoraproject.org/projects/guix/packages, at
Weblate} so that as many users as possible can read them in their native
language.  User interfaces search them and display them in the language
specified by the current locale.

为了让@command{xgettext}可以把它们提取成待翻译的字符串，简介和描述@emph{必须是文字字符串}。这意味着你不能使用@code{string-append}或@code{format}来合成字符串：

@lisp
(package
  ;; @dots{}
  (synopsis "这是可以翻译的")
  (description (string-append "这是" "*不可以*" "翻译的")))
@end lisp

翻译是很繁重的工作，所以，作为打包者请更加注意你的简介和介绍，每一个改动都会增加翻译的工作量。为了帮助他们，你可以插入这类可以被他们看到的建议和指示（@pxref{xgettext Invocation,,, gettext, GNU Gettext}）：

@lisp
;; TRANSLATORS: "X11 resize-and-rotate"不需要翻译。
(description "ARandR为X11 resize-and-rotate (RandR)扩展提供简单的图形界面。@dots{}")
@end lisp

@node Snippets versus Phases
@subsection Snippets versus Phases

@cindex snippets, when to use
The boundary between using an origin snippet versus a build phase to modify
the sources of a package can be elusive.  Origin snippets are typically used
to remove unwanted files such as bundled libraries, nonfree sources, or to
apply simple substitutions.  The source derived from an origin should
produce a source that can be used to build the package on any system that
the upstream package supports (i.e., act as the corresponding source).  In
particular, origin snippets must not embed store items in the sources; such
patching should rather be done using build phases.  Refer to the
@code{origin} record documentation for more information (@pxref{origin参考手册}).

@node Emacs Packages
@subsection Emacs Packages

@cindex emacs, packaging
@cindex elisp, packaging
Emacs packages should preferably use the Emacs build system
(@pxref{emacs-build-system}), for uniformity and the benefits provided by
its build phases, such as the auto-generation of the autoloads file and the
byte compilation of the sources.  Because there is no standardized way to
run a test suite for Emacs packages, tests are disabled by default.  When a
test suite is available, it should be enabled by setting the @code{#:tests?}
argument to @code{#true}.  By default, the command to run the test is
@command{make check}, but any command can be specified via the
@code{#:test-command} argument.  The @code{#:test-command} argument expects
a list containing a command and its arguments, to be invoked during the
@code{check} phase.

The Elisp dependencies of Emacs packages are typically provided as
@code{propagated-inputs} when required at run time.  As for other packages,
build or test dependencies should be specified as @code{native-inputs}.

Emacs packages sometimes depend on resources directories that should be
installed along the Elisp files.  The @code{#:include} argument can be used
for that purpose, by specifying a list of regexps to match.  The best
practice when using the @code{#:include} argument is to extend rather than
override its default value (accessible via the @code{%default-include}
variable).  As an example, a yasnippet extension package typically include a
@file{snippets} directory, which could be copied to the installation
directory using:

@lisp
#:include (cons "^snippets/" %default-include)
@end lisp

When encountering problems, it is wise to check for the presence of the
@code{Package-Requires} extension header in the package main source file,
and whether any dependencies and their versions listed therein are
satisfied.

@node Python模块
@subsection Python模块

@cindex python
我们目前为Python 2和Python 3打包，如@ref{版本号}的规则所述，它们的Scheme变量名分别是@code{python-2}和@code{python}。为了避免和其他编程语言的冲突，Python模块的软件包名字最好含有@code{python}。

Some modules are compatible with only one version of Python, others with
both.  If the package Foo is compiled with Python 3, we name it
@code{python-foo}.  If it is compiled with Python 2, we name it
@code{python2-foo}.  Packages should be added when they are necessary; we
don't add Python 2 variants of the package unless we are going to use them.

如果一个项目的名字已经含有@code{python}这个单词，我们把它丢掉；例如，python-dateutil模块打包后的名字是@code{python-dateutil}和@code{python2-dateutil}。如果项目的名字以@code{py}开头（如@:
@code{pytz}），我们把它保留，并且添加上面所述的前缀。

@quotation 注
Currently there are two different build systems for Python packages in Guix:
@var{python-build-system} and @var{pyproject-build-system}.  For the longest
time, Python packages were built from an informally specified
@file{setup.py} file.  That worked amazingly well, considering Python's
success, but was difficult to build tooling around.  As a result, a host of
alternative build systems emerged and the community eventually settled on a
@url{https://peps.python.org/pep-0517/, formal standard} for specifying
build requirements.  @var{pyproject-build-system} is Guix's implementation
of this standard.  It is considered ``experimental'' in that it does not yet
support all the various PEP-517 @emph{build backends}, but you are
encouraged to try it for new Python packages and report any problems.  It
will eventually be deprecated and merged into @var{python-build-system}.
@end quotation

@subsubsection 指定依赖
@cindex Python软件包的输入

Dependency information for Python packages is usually available in the
package source tree, with varying degrees of accuracy: in the
@file{pyproject.toml} file, the @file{setup.py} file, in
@file{requirements.txt}, or in @file{tox.ini} (the latter mostly for test
dependencies).

你在写软件包配方时的任务是把这些依赖转换成相应的“输入”（@pxref{软件包引用,
inputs}）。尽管@code{pypi}导入工具通常可以做得很好（@pxref{调用guix import}），你可能想检查下面这个清单，以决定每个依赖放在哪儿。

@itemize

@item
We currently package Python with @code{setuptools} and @code{pip} installed
per default.  This is about to change, and users are encouraged to use
@code{python-toolchain} if they want a build environment for Python.

@command{guix lint} will warn if @code{setuptools} or @code{pip} are added
as native-inputs because they are generally not necessary.

@item
运行时需要的Python依赖要放进@code{propagated-inputs}。它们通常由@file{setup.py}文件里的@code{install_requires}关键字或@file{requirements.txt}文件定义。

@item
Python packages required only at build time---e.g., those listed under
@code{build-system.requires} in @file{pyproject.toml} or with the
@code{setup_requires} keyword in @file{setup.py}---or dependencies only for
testing---e.g., those in @code{tests_require} or @file{tox.ini}---go into
@code{native-inputs}.  The rationale is that (1) they do not need to be
propagated because they are not needed at run time, and (2) in a
cross-compilation context, it's the ``native'' input that we'd want.

例如@code{pytest}，@code{mock}，@code{nose}测试框架。当然，如果在运行时需要这里的任何一个包，它需要被加进@code{propagated-inputs}。

@item
任何不属于上述类别的包都要被加进@code{inputs}，如，构建含有C语言扩展的Python包所需的程序和C语言库。

@item
如果一个Python软件包由可选的依赖（@code{extras_require}），由你根据它们的性价比（用处/负担）决定是否添加它们（@pxref{提交补丁, @command{guix size}}）。

@end itemize


@node Perl模块
@subsection Perl模块

@cindex perl
Perl程序和其它软件包的命名规则类似，用小写的上游名字命名。对于仅包含一个类的Perl包，我们使用小写的类名，把所有的@code{::}替换成破折号，并且添加@code{perl-}前缀。所以类@code{XML::Parser}变成@code{perl-xml-parser}。包含多个类的模块保留它们上游的名字，并且添加@code{perl-}前缀。这类模块的名字通常含有@code{perl}，这个单词需要被删掉。例如，@code{libwww-perl}变成@code{perl-libwww}。


@node Java包
@subsection Java包

@cindex java
Java程序和其它软件包的命名规则类似，用小写的上游名字命名。

为了避免和其它编程语言混淆和命名冲突，Java软件包的名字最好有@code{java-}前缀。如果一个项目的名字已经含有@code{java}，我们把它删掉；例如，@code{ngsjava}打包后的名字是@code{java-ngs}。

对于仅包含一个或很少几个类的Java软件包，我们使用小写的类名，把所有的@code{.}替换成破折号，并且添加@code{java-}前缀。因此，类@code{apache.commons.cli}打包后的名字是@code{java-apache-commons-cli}。


@node Rust Crates
@subsection Rust Crates

@cindex rust
Rust 程序和其它软件包的命名规则类似，用小写的上游名字命名。

To prevent namespace collisions we prefix all other Rust packages with the
@code{rust-} prefix.  The name should be changed to lowercase as appropriate
and dashes should remain in place.

In the rust ecosystem it is common for multiple incompatible versions of a
package to be used at any given time, so all package definitions should have
a versioned suffix.  The versioned suffix is the left-most non-zero digit
(and any leading zeros, of course).  This follows the ``caret'' version
scheme intended by Cargo.  Examples@: @code{rust-clap-2},
@code{rust-rand-0.6}.

Because of the difficulty in reusing rust packages as pre-compiled inputs
for other packages the Cargo build system (@pxref{构建系统,
@code{cargo-build-system}}) presents the @code{#:cargo-inputs} and
@code{cargo-development-inputs} keywords as build system arguments.  It
would be helpful to think of these as similar to @code{propagated-inputs}
and @code{native-inputs}.  Rust @code{dependencies} and
@code{build-dependencies} should go in @code{#:cargo-inputs}, and
@code{dev-dependencies} should go in @code{#:cargo-development-inputs}.  If
a Rust package links to other libraries then the standard placement in
@code{inputs} and the like should be used.

Care should be taken to ensure the correct version of dependencies are used;
to this end we try to refrain from skipping the tests or using
@code{#:skip-build?} when possible.  Of course this is not always possible,
as the package may be developed for a different Operating System, depend on
features from the Nightly Rust compiler, or the test suite may have
atrophied since it was released.


@node Elm Packages
@subsection Elm Packages

@cindex Elm
Elm applications can be named like other software: their names need not
mention Elm.

Packages in the Elm sense (see @code{elm-build-system} under @ref{构建系统}) are required use names of the format
@var{author}@code{/}@var{project}, where both the @var{author} and the
@var{project} may contain hyphens internally, and the @var{author} sometimes
contains uppercase letters.

To form the Guix package name from the upstream name, we follow a convention
similar to Python packages (@pxref{Python模块}), adding an @code{elm-}
prefix unless the name would already begin with @code{elm-}.

In many cases we can reconstruct an Elm package's upstream name
heuristically, but, since conversion to a Guix-style name involves a loss of
information, this is not always possible.  Care should be taken to add the
@code{'upstream-name} property when necessary so that @samp{guix import elm}
will work correctly (@pxref{调用guix import}). The most notable
scenarios when explicitly specifying the upstream name is necessary are:

@enumerate
@item
When the @var{author} is @code{elm} and the @var{project} contains one or
more hyphens, as with @code{elm/virtual-dom}; and

@item
When the @var{author} contains hyphens or uppercase letters, as with
@code{Elm-Canvas/raster-shapes}---unless the @var{author} is
@code{elm-explorations}, which is handled as a special case, so packages
like @code{elm-explorations/markdown} do @emph{not} need to use the
@code{'upstream-name} property.
@end enumerate

The module @code{(guix build-system elm)} provides the following utilities
for working with names and related conventions:

@deffn {Scheme procedure} elm-package-origin @var{elm-name} @var{version} @
  @var{hash} Returns a Git origin using the repository naming and tagging
regime required for a published Elm package with the upstream name
@var{elm-name} at version @var{version} with sha256 checksum @var{hash}.

For example:
@lisp
(package
  (name "elm-html")
  (version "1.0.0")
  (source
   (elm-package-origin
    "elm/html"
    version
    (base32 "15k1679ja57vvlpinpv06znmrxy09lbhzfkzdc89i01qa8c4gb4a")))
  ...)
@end lisp
@end deffn

@deffn {Scheme procedure} elm->package-name @var{elm-name}
Returns the Guix-style package name for an Elm package with upstream name
@var{elm-name}.

Note that there is more than one possible @var{elm-name} for which
@code{elm->package-name} will produce a given result.
@end deffn

@deffn {Scheme procedure} guix-package->elm-name @var{package}
Given an Elm @var{package}, returns the possibly-inferred upstream name, or
@code{#f} the upstream name is not specified via the @code{'upstream-name}
property and can not be inferred by @code{infer-elm-package-name}.
@end deffn

@deffn {Scheme procedure} infer-elm-package-name @var{guix-name}
Given the @var{guix-name} of an Elm package, returns the inferred upstream
name, or @code{#f} if the upstream name can't be inferred.  If the result is
not @code{#f}, supplying it to @code{elm->package-name} would produce
@var{guix-name}.
@end deffn

@node 字体
@subsection 字体

@cindex 字体
对于通常不会被用户安装用于排版的字体，或者随更大的软件包分发的字体，我们使用通常的命名规则。例如，这适用于X.Org系统附带的字体或TeX
Live附带的字体。

为了让用户更容易搜索字体，其它仅含有字体的软件包按以下规则命名，不管上游的包名是什么。

仅含有一个字体家族的软件包需要以@code{font-}开头；如果作者名字已知，则添加作者名字和@code{-}，接着是字体家族名字（把空格替换成破折号），（和通常一样，把所有的大写字母转换成小写字母）。例如，由SIL设计的Gentium字体家族打包后的名字是@code{font-sil-gentium}。

对于一个含有多个字体家族的软件包，用集合的名字替换字体家族的名字。例如，Liberation字体含有三个家族，Liberation
Sans、Liberation Serif和Liberation
Mono。它们可以用@code{font-liberation-sans}等名字分开打包；但是由于它们以一个共同的名字分发，我们倾向于以@code{font-liberation}名字统一打包。

当同一个字体家族或字体集合的不同格式分开打包时，把破折号和格式（缩写）添加在软件包名字后面。我们用@code{-ttf}代表TrueType字体，@code{-otf}代表OpenType字体，@code{-type1}代表PostScript
Type 1字体。


@node 代码风格
@section 代码风格

总的来说，我们的代码遵循GNU代码规范（@pxref{Top,,, standards,
GNU代码规范}）。但是，这个规范对Scheme的介绍不多，所以这儿提供一些额外的规则。

@menu
* 编程范例::             怎样合成元素。
* 模块::                   在哪里保存代码？
* 数据类型和模式匹配::  实现数据结构。
* 格式化代码::          书写规范。
@end menu

@node 编程范例
@subsection 编程范例

Guix里的Scheme代码是以纯函数的风格写的。一个例外是有关输入/输出的代码，和实现底层概念的过程，如@code{memoize}过程。

@node 模块
@subsection 模块

用于构建的Guile模块必须放在@code{(guix build
@dots{})}命名空间里。它们不允许引用其它Guix或GNU模块。但是，主机端（host-side)模块可以使用构建端（build-side）模块。

关于更广的GNU系统的模块应该在@code{(gnu @dots{})}命名空间里而不是@code{(guix @dots{})}。

@node 数据类型和模式匹配
@subsection 数据类型和模式匹配

经典的Lisp倾向于用列表表示所有的东西，然后用@code{car}，@code{cdr}，@code{cadr}等手动浏览它们。这种风格有几个问题，特别是难以阅读，易出错，并且妨碍生成合适的类型错误报告。

@findex define-record-type*
@findex match-record
@cindex pattern matching
Guix code should define appropriate data types (for instance, using
@code{define-record-type*}) rather than abuse lists.  In addition, it should
use pattern matching, via Guile’s @code{(ice-9 match)} module, especially
when matching lists (@pxref{Pattern Matching,,, guile, GNU Guile Reference
Manual}); pattern matching for records is better done using
@code{match-record} from @code{(guix records)}, which, unlike @code{match},
verifies field names at macro-expansion time.

@node 格式化代码
@subsection 格式化代码

@cindex 格式化代码
@cindex 代码风格
When writing Scheme code, we follow common wisdom among Scheme programmers.
In general, we follow the
@url{https://mumble.net/~campbell/scheme/style.txt, Riastradh's Lisp Style
Rules}.  This document happens to describe the conventions mostly used in
Guile’s code too.  It is very thoughtful and well written, so please do read
it.

一些Guix添加的special
form，如@code{substitute*}宏，有特殊的缩进规则。它们的规则在@file{.dir-locals.el}文件里定义，Emacs会自动使用。另外，Emacs-Guix提供的@code{guix-devel-mode}模式可以正确地缩进和高亮Guix代码（@pxref{开发,,,
emacs-guix, Emacs-Guix参考手册}）。

@cindex 代码缩进
@cindex 代码格式化
如果你不使用Emacs，请确保让你的编辑器知道这些规则。为了自动地缩进软件包定义，你也可以运行：

@example
./pre-inst-env guix style @var{package}
@end example

@noindent
@xref{Invoking guix style}, for more information.

@cindex Vim，编辑Scheme代码
如果你用Vim编辑代码，我们推荐你运行@code{:set
autoindent}，以使你在输入时自动缩进代码。另外，@uref{https://www.vim.org/scripts/script.php?script_id=3998,
@code{paredit.vim}}可以帮你处理括号。

我们要求所有的顶级过程附带一个docstring。这个要求对@code{(guix build @dots{})}命名空间里的简单的私有过程可以放宽。

过程不应该有多于四个定位参数。对于接收多于四个定位参数的过程应使用关键字参数。


@node 提交补丁
@section 提交补丁

Development is done using the Git distributed version control system.  Thus,
access to the repository is not strictly necessary.  We welcome
contributions in the form of patches as produced by @code{git format-patch}
sent to the @email{guix-patches@@gnu.org} mailing list (@pxref{Submitting patches to a project,,, git, Git User Manual}).  Contributors are encouraged
to take a moment to set some Git repository options (@pxref{配置Git}) first, which can improve the readability of patches.  Seasoned Guix
developers may also want to look at the section on commit access
(@pxref{提交权利}).

This mailing list is backed by a Debbugs instance, which allows us to keep
track of submissions (@pxref{跟踪程序漏洞和补丁}).  Each message sent
to that mailing list gets a new tracking number assigned; people can then
follow up on the submission by sending email to
@code{@var{ISSUE_NUMBER}@@debbugs.gnu.org}, where @var{ISSUE_NUMBER} is the
tracking number (@pxref{发送补丁系列}).

请以ChangeLog格式（@pxref{Change Logs,,, standards,
GNU代码规范}）写commit日志；你可以浏览commit历史里的例子。

提交添加或者修改软件包定义的补丁之前，请过一遍这个检查列表：

@enumerate
@item
如果软件包的作者为发布的文件包提供了密码学签名，请验证文件的真实性。对于独立的 GPG 签名文件，这可以通过 @code{gpg --verify}
命令完成。

@item
花些时间为软件包提供一个合适的简介和描述。更多指导，@xref{简介和描述}。

@item
运行@code{guix lint
@var{软件包}}，@var{软件包}是新添加的或修改过的软件包的名字，修复它报告的错误（@pxref{调用guix lint}）。

@item
Run @code{guix style @var{package}} to format the new package definition
according to the project's conventions (@pxref{Invoking guix style}).

@item
用@code{guix build @var{软件包}}命令确保这个软件包可以在你的平台上构建。

@item
We recommend you also try building the package on other supported
platforms.  As you may not have access to actual hardware platforms, we
recommend using the @code{qemu-binfmt-service-type} to emulate them.  In
order to enable it, add the @code{virtualization} service module and the
following service to the list of services in your @code{operating-system}
configuration:

@lisp
(service qemu-binfmt-service-type
 (qemu-binfmt-configuration
   (platforms (lookup-qemu-platforms "arm" "aarch64"))))
@end lisp

然后重新配置你的系统。

You can then build packages for different platforms by specifying the
@code{--system} option.  For example, to build the "hello" package for the
armhf or aarch64 architectures, you would run the following commands,
respectively:
@example
guix build --system=armhf-linux --rounds=2 hello
guix build --system=aarch64-linux --rounds=2 hello
@end example

@item
@cindex 构建
请确保软件包里不捆绑出现已经被打过包的软件的副本。

有时，软件包为了方便用户，捆绑了依赖库的源代码。然而，当依赖库在发行版里已经存在时，做为一个发行版，我们希望确保这些软件包使用发行版里已有的副本。这提高资源使用率（依赖库只构建一次，存储一份），并且使发行版更容易管理，如仅在一个地方对某个软件包进行安全更新就可以影响整个系统－－捆绑软件会妨碍这么做。

@item
Take a look at the profile reported by @command{guix size} (@pxref{调用guix size}).  This will allow you to notice references to other packages
unwillingly retained.  It may also help determine whether to split the
package (@pxref{有多个输出的软件包}), and which optional
dependencies should be used.  In particular, avoid adding @code{texlive} as
a dependency: because of its extreme size, use the @code{texlive-tiny}
package or @code{texlive-union} procedure instead.

@item
For important changes, check that dependent packages (if applicable) are not
affected by the change; @code{guix refresh --list-dependent @var{package}}
will help you do that (@pxref{调用guix refresh}).

@c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
@cindex 分支策略
@cindex 重新构建的调度策略
取决于受影响的软件包的数量，即需要重新构建的数量，commit需要被提交到不同的分支，具体如下：

@table @asis
@item 300个或更少的受影响的软件包
@code{master}分支（非破坏性的更改）。

@item 300 至 1800 个受影响的软件包
@code{staging} branch (non-disruptive changes).  This branch is intended to
be merged in @code{master} every 6 weeks or so.  Topical changes (e.g., an
update of the GNOME stack) can instead go to a specific branch (say,
@code{gnome-updates}).  This branch is not expected to be buildable or
usable until late in its development process.

@item 超过 1800 个受影响的软件包
@code{core-updates} branch (may include major and potentially disruptive
changes).  This branch is intended to be merged in @code{master} every 6
months or so.  This branch is not expected to be buildable or usable until
late in its development process.
@end table

All these branches are @uref{https://@value{SUBSTITUTE-SERVER-1}, tracked by
our build farm} and merged into @code{master} once everything has been
successfully built.  This allows us to fix issues before they hit users, and
to reduce the window during which pre-built binaries are not available.

@c TODO: It would be good with badges on the website that tracks these
@c branches.  Or maybe even a status page.
When we decide to start building the @code{staging} or @code{core-updates}
branches, they will be forked and renamed with the suffix @code{-frozen}, at
which time only bug fixes may be pushed to the frozen branches.  The
@code{core-updates} and @code{staging} branches will remain open to accept
patches for the next cycle.  Please ask on the mailing list or IRC if unsure
where to place a patch.

@item
@cindex 构建过程的确定性
@cindex 检查可复现的构建
检查软件包的构建过程是不是确定性的。这通常意味着检查对软件包的独立构建是否能得到每一个比特都完全相同的结果。

为此，一个简单的做法是在你的机器上多次构建同一个软件包（@pxref{调用guix build}）：

@example
guix build --rounds=2 <我的软件包>
@end example

这足以查出一批普通的不确定性问题，如构建结果里存在时间戳或随机生成的输出。

Another option is to use @command{guix challenge} (@pxref{调用guix challenge}).  You may run it once the package has been committed and built
by @code{@value{SUBSTITUTE-SERVER-1}} to check whether it obtains the same
result as you did.  Better yet: Find another machine that can build it and
run @command{guix publish}.  Since the remote build machine is likely
different from yours, this can catch non-determinism issues related to the
hardware---e.g., use of different instruction set extensions---or to the
operating system kernel---e.g., reliance on @code{uname} or @file{/proc}
files.

@item
在编写文档时，请用性别中立的词语指代人，如@uref{https://en.wikipedia.org/wiki/Singular_they,
“他”@comma{} “他的”}，等。

@item
检查你的补丁只包含一些相关的更改。把不相关的更改捆绑在一起会让评审更困难和更慢。

不相关的更改的例子有：同时新增多个软件包，或更新软件包同时修补这个软件包。

@item
Please follow our code formatting rules, possibly running @command{guix
style} script to do that automatically for you (@pxref{格式化代码}).

@item
当可能时，请在源URL里使用镜像@pxref{调用guix download}。使用可靠的而不是生成的URL。例如，GitHub的下载文件每次生成时不一定是相同的，所以这时最好克隆仓库。不要在URL里使用@command{name}变量：这没有什么用，而且如果名字变了，URL很可能就错了。

@item
Check if Guix builds (@pxref{从Git构建}) and address the warnings,
especially those about use of undefined symbols.

@item
Make sure your changes do not break Guix and simulate a @code{guix pull}
with:
@example
guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master
@end example

@end enumerate

When posting a patch to the mailing list, use @samp{[PATCH] @dots{}} as a
subject, if your patch is to be applied on a branch other than
@code{master}, say @code{core-updates}, specify it in the subject like
@samp{[PATCH core-updates] @dots{}}.

You may use your email client or the @command{git send-email} command
(@pxref{发送补丁系列}).  We prefer to get patches in plain text
messages, either inline or as MIME attachments.  You are advised to pay
attention if your email client changes anything like line breaks or
indentation which could potentially break the patches.

Expect some delay when you submit your very first patch to
@email{guix-patches@@gnu.org}. You have to wait until you get an
acknowledgement with the assigned tracking number. Future acknowledgements
should not be delayed.

When a bug is resolved, please close the thread by sending an email to
@email{@var{ISSUE_NUMBER}-done@@debbugs.gnu.org}.

@node 配置Git
@subsection 配置Git
@cindex git configuration
@cindex @code{git format-patch}
@cindex @code{git send-email}

If you have not done so already, you may wish to set a name and email that
will be associated with your commits (@pxref{telling git your name, ,
Telling Git your name, git, Git User Manual}).  If you wish to use a
different name or email just for commits in this repository, you can use
@command{git config --local}, or edit @file{.git/config} in the repository
instead of @file{~/.gitconfig}.

We provide some default settings in @file{etc/git/gitconfig} which modify
how patches are generated, making them easier to read and apply.  These
settings can be applied by manually copying them to @file{.git/config} in
your checkout, or by telling Git to include the whole file:

@example
git config --local include.path ../etc/git/gitconfig
@end example

From then on, any changes to @file{etc/git/gitconfig} would automatically
take effect.

Since the first patch in a series must be sent separately (@pxref{发送补丁系列}), it can also be helpful to tell @command{git format-patch} to
handle the e-mail threading instead of @command{git send-email}:

@example
git config --local format.thread shallow
git config --local sendemail.thread no
@end example

@node 发送补丁系列
@subsection 发送补丁系列
@cindex 补丁系列
@cindex @code{git send-email}
@cindex @code{git format-patch}

@unnumberedsubsubsec Single Patches
@anchor{Single Patches}
The @command{git send-email} command is the best way to send both single
patches and patch series (@pxref{Multiple Patches}) to the Guix mailing
list.  Sending patches as email attachments may make them difficult to
review in some mail clients, and @command{git diff} does not store commit
metadata.

@quotation 注
The @command{git send-email} command is provided by the @code{send-email}
output of the @code{git} package, i.e. @code{git:send-email}.
@end quotation

The following command will create a patch email from the latest commit, open
it in your @var{EDITOR} or @var{VISUAL} for editing, and send it to the Guix
mailing list to be reviewed and merged:

@example
$ git send-email -1 -a --base=auto --to=guix-patches@@gnu.org
@end example

@quotation Tip
To add a prefix to the subject of your patch, you may use the
@option{--subject-prefix} option.  The Guix project uses this to specify
that the patch is intended for a branch or repository other than the
@code{master} branch of @url{https://git.savannah.gnu.org/cgit/guix.git}.

@example
git send-email -1 -a --base=auto \
    --subject-prefix='PATCH core-updates' \
    --to=guix-patches@@gnu.org
@end example
@end quotation

The patch email contains a three-dash separator line after the commit
message.  You may ``annotate'' the patch with explanatory text by adding it
under this line.  If you do not wish to annotate the email, you may drop the
@option{-a} flag (which is short for @option{--annotate}).

The @option{--base=auto} flag automatically adds a note at the bottom of the
patch of the commit it was based on, making it easier for maintainers to
rebase and merge your patch.

If you need to send a revised patch, don't resend it like this or send a
``fix'' patch to be applied on top of the last one; instead, use
@command{git commit -a} or @url{https://git-rebase.io, @command{git rebase}}
to modify the commit, and use the
@email{@var{ISSUE_NUMBER}@@debbugs.gnu.org} address and the @option{-v} flag
with @command{git send-email}.

@example
$ git commit -a
$ git send-email -1 -a --base=auto -v @var{REVISION} \
      --to=@var{ISSUE_NUMBER}@@debbugs.gnu.org
@end example

You can find out @var{ISSUE_NUMBER} either by searching on the mumi
interface at @url{issues.guix.gnu.org} for the name of your patch or reading
the acknowledgement email sent automatically by Debbugs in reply to incoming
bugs and patches, which contains the bug number.

@unnumberedsubsubsec Notifying Teams
@anchor{Notifying Teams}
@cindex teams
The @file{etc/teams.scm} script may be used to notify all those who may be
interested in your patch of its existence (@pxref{Teams}).  Use
@command{etc/teams.scm list-teams} to display all the teams, decide which
team(s) your patch relates to, and use @command{etc/teams.scm cc} to output
various @command{git send-email} flags which will notify the appropriate
team members, or use @command{etc/teams.scm cc-members} to detect the
appropriate teams automatically.

@unnumberedsubsubsec Multiple Patches
@anchor{Multiple Patches}
@cindex cover letter
While @command{git send-email} alone will suffice for a single patch, an
unfortunate flaw in Debbugs means you need to be more careful when sending
multiple patches: if you send them all to the @email{guix-patches@@gnu.org}
address, a new issue will be created for each patch!

When sending a series of patches, it's best to send a Git ``cover letter''
first, to give reviewers an overview of the patch series.  We can create a
directory called @file{outgoing} containing both our patch series and a
cover letter called @file{0000-cover-letter.patch} with @command{git
format-patch}.

@example
$ git format-patch -@var{NUMBER_COMMITS} -o outgoing \
      --cover-letter --base=auto
@end example

We can now send @emph{just} the cover letter to the
@email{guix-patches@@gnu.org} address, which will create an issue that we
can send the rest of the patches to.

@example
$ git send-email outgoing/0000-cover-letter.patch -a \
      --to=guix-patches@@debbugs.gnu.org \
      $(etc/teams.scm cc-members ...)
$ rm outgoing/0000-cover-letter.patch # we don't want to resend it!
@end example

Ensure you edit the email to add an appropriate subject line and blurb
before sending it.  Note the automatically generated shortlog and diffstat
below the blurb.

Once the Debbugs mailer has replied to your cover letter email, you can send
the actual patches to the newly-created issue address.

@example
$ git send-email outgoing/*.patch \
      --to=@var{ISSUE_NUMBER}@@debbugs.gnu.org \
      $(etc/teams.scm cc-members ...)
$ rm -rf outgoing # we don't need these anymore
@end example

Thankfully, this @command{git format-patch} dance is not necessary to send
an amended patch series, since an issue already exists for the patchset.

@example
$ git send-email -@var{NUMBER_COMMITS} \
      -v@var{REVISION} --base=auto \
      --to @var{ISSUE_NUMBER}@@debbugs.gnu.org
@end example

If need be, you may use @option{--cover-letter -a} to send another cover
letter, e.g. for explaining what's changed since the last revision, and
these changes are necessary.

@node Teams
@subsection Teams
@cindex teams

There are several teams mentoring different parts of the Guix source code.
To list all those teams, you can run from a Guix checkout:

@example
$ ./etc/teams.scm list-teams
id: mentors
name: Mentors
description: A group of mentors who chaperone contributions by newcomers.
members:
+ Christopher Baines <mail@@cbaines.net>
+ Ricardo Wurmus <rekado@@elephly.net>
+ Mathieu Othacehe <othacehe@@gnu.org>
+ jgart <jgart@@dismail.de>
+ Ludovic Courtès <ludo@@gnu.org>
@dots{}
@end example

You can run the following command to have the @code{Mentors} team put in CC
of a patch series:

@example
$ git send-email --to @var{ISSUE_NUMBER}@@debbugs.gnu.org $(./etc/teams.scm cc mentors) *.patch
@end example

The appropriate team or teams can also be inferred from the modified files.
For instance, if you want to send the two latest commits of the current Git
repository to review, you can run:

@example
$ guix shell -D guix
[env]$ git send-email --to @var{ISSUE_NUMBER}@@debbugs.gnu.org $(./etc/teams.scm cc-members HEAD~2 HEAD) *.patch
@end example

@node 跟踪程序漏洞和补丁
@section 跟踪程序漏洞和补丁

This section describes how the Guix project tracks its bug reports and patch
submissions.

@menu
* The Issue Tracker::        The official bug and patch tracker.
* Debbugs User Interfaces::  Ways to interact with Debbugs.
* Debbugs Usertags::         Tag reports with custom labels.
@end menu

@node The Issue Tracker
@subsection The Issue Tracker

@cindex bug reports, tracking
@cindex patch submissions, tracking
@cindex issue tracking
@cindex Debbugs, issue tracking system
Bug reports and patch submissions are currently tracked using the Debbugs
instance at @uref{https://bugs.gnu.org}.  Bug reports are filed against the
@code{guix} ``package'' (in Debbugs parlance), by sending email to
@email{bug-guix@@gnu.org}, while patch submissions are filed against the
@code{guix-patches} package by sending email to
@email{guix-patches@@gnu.org} (@pxref{提交补丁}).

@node Debbugs User Interfaces
@subsection Debbugs User Interfaces

A web interface (actually @emph{two} web interfaces!) are available to
browse issues:

@itemize
@item
@url{https://issues.guix.gnu.org} provides a pleasant interface@footnote{The
web interface at @url{https://issues.guix.gnu.org} is powered by Mumi, a
nice piece of software written in Guile, and you can help! See
@url{https://git.elephly.net/gitweb.cgi?p=software/mumi.git}.} to browse bug
reports and patches, and to participate in discussions;
@item
@url{https://bugs.gnu.org/guix} lists bug reports;
@item
@url{https://bugs.gnu.org/guix-patches} lists patch submissions.
@end itemize

To view discussions related to issue number @var{n}, go to
@indicateurl{https://issues.guix.gnu.org/@var{n}} or
@indicateurl{https://bugs.gnu.org/@var{n}}.

If you use Emacs, you may find it more convenient to interact with issues
using @file{debbugs.el}, which you can install with:

@example
guix install emacs-debbugs
@end example

For example, to list all open issues on @code{guix-patches}, hit:

@example
@kbd{C-u} @kbd{M-x} debbugs-gnu @kbd{RET} @kbd{RET} guix-patches @kbd{RET} n y
@end example

@xref{Top,,, debbugs-ug, Debbugs User Guide}，了解更多有关此实用工具的信息！

@node Debbugs Usertags
@subsection Debbugs Usertags

@cindex usertags, for debbugs
@cindex Debbugs usertags
Debbugs provides a feature called @dfn{usertags} that allows any user to tag
any bug with an arbitrary label.  Bugs can be searched by usertag, so this
is a handy way to organize bugs@footnote{The list of usertags is public
information, and anyone can modify any user's list of usertags, so keep that
in mind if you choose to use this feature.}.

For example, to view all the bug reports (or patches, in the case of
@code{guix-patches}) tagged with the usertag @code{powerpc64le-linux} for
the user @code{guix}, open a URL like the following in a web browser:
@url{https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix}.

For more information on how to use usertags, please refer to the
documentation for Debbugs or the documentation for whatever tool you use to
interact with Debbugs.

In Guix, we are experimenting with usertags to keep track of
architecture-specific issues.  To facilitate collaboration, all our usertags
are associated with the single user @code{guix}.  The following usertags
currently exist for that user:

@table @code

@item powerpc64le-linux
The purpose of this usertag is to make it easy to find the issues that
matter most for the @code{powerpc64le-linux} system type.  Please assign
this usertag to bugs or patches that affect @code{powerpc64le-linux} but not
other system types.  In addition, you may use it to identify issues that for
some reason are particularly important for the @code{powerpc64le-linux}
system type, even if the issue affects other system types, too.

@item reproducibility
For issues related to reproducibility.  For example, it would be appropriate
to assign this usertag to a bug report for a package that fails to build
reproducibly.

@end table

If you're a committer and you want to add a usertag, just start using it
with the @code{guix} user.  If the usertag proves useful to you, consider
updating this section of the manual so that others will know what your
usertag means.

@node 提交权利
@section 提交权利

@cindex commit access, for developers
Everyone can contribute to Guix without having commit access
(@pxref{提交补丁}).  However, for frequent contributors, having
write access to the repository can be convenient.  As a rule of thumb, a
contributor should have accumulated fifty (50) reviewed commits to be
considered as a committer and have sustained their activity in the project
for at least 6 months.  This ensures enough interactions with the
contributor, which is essential for mentoring and assessing whether they are
ready to become a committer.  Commit access should not be thought of as a
``badge of honor'' but rather as a responsibility a contributor is willing
to take to help the project.

The following sections explain how to get commit access, how to be ready to
push commits, and the policies and community expectations for commits pushed
upstream.

@subsection Applying for Commit Access

When you deem it necessary, consider applying for commit access by following
these steps:

@enumerate
@item
Find three committers who would vouch for you.  You can view the list of
committers at
@url{https://savannah.gnu.org/project/memberlist.php?group=guix}.  Each of
them should email a statement to @email{guix-maintainers@@gnu.org} (a
private alias for the collective of maintainers), signed with their OpenPGP
key.

Committers are expected to have had some interactions with you as a
contributor and to be able to judge whether you are sufficiently familiar
with the project's practices.  It is @emph{not} a judgment on the value of
your work, so a refusal should rather be interpreted as ``let's try again
later''.

@item
Send @email{guix-maintainers@@gnu.org} a message stating your intent,
listing the three committers who support your application, signed with the
OpenPGP key you will use to sign commits, and giving its fingerprint (see
below).  See @uref{https://emailselfdefense.fsf.org/en/}, for an
introduction to public-key cryptography with GnuPG.

@c See <https://sha-mbles.github.io/>.
Set up GnuPG such that it never uses the SHA1 hash algorithm for digital
signatures, which is known to be unsafe since 2019, for instance by adding
the following line to @file{~/.gnupg/gpg.conf} (@pxref{GPG Esoteric Options,,, gnupg, The GNU Privacy Guard Manual}):

@example
digest-algo sha512
@end example

@item
Maintainers ultimately decide whether to grant you commit access, usually
following your referrals' recommendation.

@item
@cindex OpenPGP, signed commits
If and once you've been given access, please send a message to
@email{guix-devel@@gnu.org} to say so, again signed with the OpenPGP key you
will use to sign commits (do that before pushing your first commit).  That
way, everyone can notice and ensure you control that OpenPGP key.

@quotation Important
Before you can push for the first time, maintainers must:

@enumerate
@item
add your OpenPGP key to the @code{keyring} branch;
@item
add your OpenPGP fingerprint to the @file{.guix-authorizations} file of the
branch(es) you will commit to.
@end enumerate
@end quotation

@item
Make sure to read the rest of this section and... profit!
@end enumerate

@quotation 注
Maintainers are happy to give commit access to people who have been
contributing for some time and have a track record---don't be shy and don't
underestimate your work!

However, note that the project is working towards a more automated patch
review and merging system, which, as a consequence, may lead us to have
fewer people with commit access to the main repository.  Stay tuned!
@end quotation

All commits that are pushed to the central repository on Savannah must be
signed with an OpenPGP key, and the public key should be uploaded to your
user account on Savannah and to public key servers, such as
@code{keys.openpgp.org}.  To configure Git to automatically sign commits,
run:

@example
git config commit.gpgsign true

# Substitute the fingerprint of your public PGP key.
git config user.signingkey CABBA6EA1DC0FF33
@end example

To check that commits are signed with correct key, use:

@example
make authenticate
@end example

You can prevent yourself from accidentally pushing unsigned or signed with
the wrong key commits to Savannah by using the pre-push Git hook located at
@file{etc/git/pre-push}:

@example
cp etc/git/pre-push .git/hooks/pre-push
@end example

It additionally calls @code{make check-channel-news} to be sure
@file{news.scm} file is correct.

@subsection Commit Policy

If you get commit access, please make sure to follow the policy below
(discussions of the policy can take place on @email{guix-devel@@gnu.org}).

Non-trivial patches should always be posted to @email{guix-patches@@gnu.org}
(trivial patches include fixing typos, etc.).  This mailing list fills the
patch-tracking database (@pxref{跟踪程序漏洞和补丁}).

For patches that just add a new package, and a simple one, it's OK to
commit, if you're confident (which means you successfully built it in a
chroot setup, and have done a reasonable copyright and license auditing).
Likewise for package upgrades, except upgrades that trigger a lot of
rebuilds (for example, upgrading GnuTLS or GLib).  We have a mailing list
for commit notifications (@email{guix-commits@@gnu.org}), so people can
notice.  Before pushing your changes, make sure to run @code{git pull
--rebase}.

When pushing a commit on behalf of somebody else, please add a
@code{Signed-off-by} line at the end of the commit log message---e.g., with
@command{git am --signoff}.  This improves tracking of who did what.

When adding channel news entries (@pxref{通道, Writing Channel News}),
make sure they are well-formed by running the following command right before
pushing:

@example
make check-channel-news
@end example

For anything else, please post to @email{guix-patches@@gnu.org} and leave
time for a review, without committing anything (@pxref{提交补丁}).  If you didn’t receive any reply after two weeks, and if you're
confident, it's OK to commit.

That last part is subject to being adjusted, allowing individuals to commit
directly on non-controversial changes on parts they’re familiar with.

@subsection Addressing Issues

Peer review (@pxref{提交补丁}) and tools such as @command{guix
lint} (@pxref{调用guix lint}) and the test suite (@pxref{运行测试套件}) should catch issues before they are pushed.  Yet, commits that
``break'' functionality might occasionally go through.  When that happens,
there are two priorities: mitigating the impact, and understanding what
happened to reduce the chance of similar incidents in the future.  The
responsibility for both these things primarily lies with those involved, but
like everything this is a group effort.

Some issues can directly affect all users---for instance because they make
@command{guix pull} fail or break core functionality, because they break
major packages (at build time or run time), or because they introduce known
security vulnerabilities.

@cindex reverting commits
The people involved in authoring, reviewing, and pushing such commit(s)
should be at the forefront to mitigate their impact in a timely fashion: by
pushing a followup commit to fix it (if possible), or by reverting it to
leave time to come up with a proper fix, and by communicating with other
developers about the problem.

If these persons are unavailable to address the issue in time, other
committers are entitled to revert the commit(s), explaining in the commit
log and on the mailing list what the problem was, with the goal of leaving
time to the original committer, reviewer(s), and author(s)  to propose a way
forward.

Once the problem has been dealt with, it is the responsibility of those
involved to make sure the situation is understood.  If you are working to
understand what happened, focus on gathering information and avoid assigning
any blame.  Do ask those involved to describe what happened, do not ask them
to explain the situation---this would implicitly blame them, which is
unhelpful.  Accountability comes from a consensus about the problem,
learning from it and improving processes so that it's less likely to
reoccur.

@subsection Commit Revocation

In order to reduce the possibility of mistakes, committers will have their
Savannah account removed from the Guix Savannah project and their key
removed from @file{.guix-authorizations} after 12 months of inactivity; they
can ask to regain commit access by emailing the maintainers, without going
through the vouching process.

Maintainers@footnote{See @uref{https://guix.gnu.org/en/about} for the
current list of maintainers.  You can email them privately at
@email{guix-maintainers@@gnu.org}.} may also revoke an individual's commit
rights, as a last resort, if cooperation with the rest of the community has
caused too much friction---even within the bounds of the project's code of
conduct (@pxref{贡献}).  They would only do so after public or
private discussion with the individual and a clear notice.  Examples of
behavior that hinders cooperation and could lead to such a decision include:

@itemize
@item repeated violation of the commit policy stated above;
@item repeated failure to take peer criticism into account;
@item breaching trust through a series of grave incidents.
@end itemize

When maintainers resort to such a decision, they notify developers on
@email{guix-devel@@gnu.org}; inquiries may be sent to
@email{guix-maintainers@@gnu.org}.  Depending on the situation, the
individual may still be welcome to contribute.

@subsection Helping Out

One last thing: the project keeps moving forward because committers not only
push their own awesome changes, but also offer some of their time
@emph{reviewing} and pushing other people's changes.  As a committer, you're
welcome to use your expertise and commit rights to help other contributors,
too!

@node 更新Guix软件包
@section 更新Guix软件包

@cindex update-guix-package, updating the guix package
It is sometimes desirable to update the @code{guix} package itself (the
package defined in @code{(gnu packages package-management)}), for example to
make new daemon features available for use by the @code{guix-service-type}
service type.  In order to simplify this task, the following command can be
used:

@example
make update-guix-package
@end example

The @code{update-guix-package} make target will use the last known
@emph{commit} corresponding to @code{HEAD} in your Guix checkout, compute
the hash of the Guix sources corresponding to that commit and update the
@code{commit}, @code{revision} and hash of the @code{guix} package
definition.

To validate that the updated @code{guix} package hashes are correct and that
it can be built successfully, the following command can be run from the
directory of your Guix checkout:

@example
./pre-inst-env guix build guix
@end example

To guard against accidentally updating the @code{guix} package to a commit
that others can't refer to, a check is made that the commit used has already
been pushed to the Savannah-hosted Guix git repository.

This check can be disabled, @emph{at your own peril}, by setting the
@code{GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT} environment variable.  When this
variable is set, the updated package source is also added to the store.
This is used as part of the release process of Guix.

@cindex documentation
@node 撰写文档
@section 撰写文档

Guix is documented using the Texinfo system.  If you are not yet familiar
with it, we accept contributions for documentation in most formats.  That
includes plain text, Markdown, Org, etc.

Documentation contributions can be sent to @email{guix-patches@@gnu.org}.
Prepend @samp{[DOCUMENTATION]} to the subject.

When you need to make more than a simple addition to the documentation, we
prefer that you send a proper patch as opposed to sending an email as
described above.  @xref{提交补丁} for more information on how to
send your patches.

To modify the documentation, you need to edit @file{doc/guix.texi} and
@file{doc/contributing.texi} (which contains this documentation section), or
@file{doc/guix-cookbook.texi} for the cookbook.  If you compiled the Guix
repository before, you will have many more @file{.texi} files that are
translations of these documents.  Do not modify them, the translation is
managed through @uref{https://translate.fedoraproject.org/projects/guix,
Weblate}.  @xref{翻译 Guix} for more information.

To render documentation, you must first make sure that you ran
@command{./configure} in your source tree (@pxref{在安装之前运行Guix}).  After that you can run one of the following commands:

@itemize
@item @samp{make doc/guix.info} to compile the Info manual.
      You can check it with @command{info doc/guix.info}.
@item @samp{make doc/guix.html} to compile the HTML version.
      You can point your browser to the relevant file in the @file{doc/guix.html}
directory.
@item @samp{make doc/guix-cookbook.info} for the cookbook Info manual.
@item @samp{make doc/guix-cookbook.html} for the cookbook HTML version.
@end itemize

@cindex translation
@cindex l10n
@cindex i18n
@cindex native language support
@node 翻译 Guix
@section 翻译 Guix

Writing code and packages is not the only way to provide a meaningful
contribution to Guix.  Translating to a language you speak is another
example of a valuable contribution you can make.  This section is designed
to describe the translation process.  It gives you advice on how you can get
involved, what can be translated, what mistakes you should avoid and what we
can do to help you!

Guix is a big project that has multiple components that can be translated.
We coordinate the translation effort on a
@uref{https://translate.fedoraproject.org/projects/guix/,Weblate instance}
hosted by our friends at Fedora.  You will need an account to submit
translations.

Some of the software packaged in Guix also contain translations.  We do not
host a translation platform for them.  If you want to translate a package
provided by Guix, you should contact their developers or find the
information on their website.  As an example, you can find the homepage of
the @code{hello} package by typing @code{guix show hello}.  On the
``homepage'' line, you will see @url{https://www.gnu.org/software/hello/} as
the homepage.

Many GNU and non-GNU packages can be translated on the
@uref{https://translationproject.org,Translation Project}.  Some projects
with multiple components have their own platform.  For instance, GNOME has
its own platform, @uref{https://l10n.gnome.org/,Damned Lies}.

Guix has five components hosted on Weblate.

@itemize
@item @code{guix} contains all the strings from the Guix software (the
      guided system installer, the package manager, etc), excluding packages.
@item @code{packages} contains the synopsis (single-sentence description
      of a package) and description (longer description) of packages in Guix.
@item @code{website} contains the official Guix website, except for
      blog posts and multimedia content.
@item @code{documentation-manual} corresponds to this manual.
@item @code{documentation-cookbook} is the component for the cookbook.
@end itemize

@subsubheading General Directions

Once you get an account, you should be able to select a component from
@uref{https://translate.fedoraproject.org/projects/guix/,the guix project},
and select a language.  If your language does not appear in the list, go to
the bottom and click on the ``Start new translation'' button.  Select the
language you want to translate to from the list, to start your new
translation.

Like lots of other free software packages, Guix uses
@uref{https://www.gnu.org/software/gettext,GNU Gettext} for its
translations, with which translatable strings are extracted from the source
code to so-called PO files.

Even though PO files are text files, changes should not be made with a text
editor but with PO editing software.  Weblate integrates PO editing
functionality.  Alternatively, translators can use any of various
free-software tools for filling in translations, of which
@uref{https://poedit.net/,Poedit} is one example, and (after logging in)
@uref{https://docs.weblate.org/en/latest/user/files.html,upload} the changed
file.  There is also a special
@uref{https://www.emacswiki.org/emacs/PoMode,PO editing mode} for users of
GNU Emacs.  Over time translators find out what software they are happy with
and what features they need.

On Weblate, you will find various links to the editor, that will show
various subsets (or all) of the strings.  Have a look around and at the
@uref{https://docs.weblate.org/en/latest/,documentation} to familiarize
yourself with the platform.

@subsubheading Translation Components

In this section, we provide more detailed guidance on the translation
process, as well as details on what you should or should not do.  When in
doubt, please contact us, we will be happy to help!

@table @asis
@item guix
Guix is written in the Guile programming language, and some strings contain
special formatting that is interpreted by Guile.  These special formatting
should be highlighted by Weblate.  They start with @code{~} followed by one
or more characters.

When printing the string, Guile replaces the special formatting symbols with
actual values.  For instance, the string @samp{ambiguous package
specification `~a'} would be substituted to contain said package
specification instead of @code{~a}.  To properly translate this string, you
must keep the formatting code in your translation, although you can place it
where it makes sense in your language.  For instance, the French translation
says @samp{spécification du paquet « ~a » ambiguë} because the adjective
needs to be placed in the end of the sentence.

If there are multiple formatting symbols, make sure to respect the order.
Guile does not know in which order you intended the string to be read, so it
will substitute the symbols in the same order as the English sentence.

As an example, you cannot translate @samp{package '~a' has been superseded
by '~a'} by @samp{'~a' superseeds package '~a'}, because the meaning would
be reversed.  If @var{foo} is superseded by @var{bar}, the translation would
read @samp{'foo' superseeds package 'bar'}.  To work around this problem, it
is possible to use more advanced formatting to select a given piece of data,
instead of following the default English order.  @xref{Formatted Output,,,
guile, GNU Guile Reference Manual}, for more information on formatting in
Guile.

@item packages

Package descriptions occasionally contain Texinfo markup (@pxref{简介和描述}).  Texinfo markup looks like @samp{@@code@{rm -rf@}},
@samp{@@emph@{important@}}, etc.  When translating, please leave markup as
is.

The characters after ``@@'' form the name of the markup, and the text
between ``@{'' and ``@}'' is its content.  In general, you should not
translate the content of markup like @code{@@code}, as it contains literal
code that do not change with language.  You can translate the content of
formatting markup such as @code{@@emph}, @code{@@i}, @code{@@itemize},
@code{@@item}.  However, do not translate the name of the markup, or it will
not be recognized.  Do not translate the word after @code{@@end}, it is the
name of the markup that is closed at this position (e.g.@: @code{@@itemize
... @@end itemize}).

@item documentation-manual and documentation-cookbook

The first step to ensure a successful translation of the manual is to find
and translate the following strings @emph{first}:

@itemize
@item @code{version.texi}: Translate this string as @code{version-xx.texi},
      where @code{xx} is your language code (the one shown in the URL on weblate).
@item @code{contributing.texi}: Translate this string as
      @code{contributing.xx.texi}, where @code{xx} is the same language code.
@item @code{Top}: Do not translate this string, it is important for Texinfo.
      If you translate it, the document will be empty (missing a Top node).
Please look for it, and register @code{Top} as its translation.
@end itemize

Translating these strings first ensure we can include your translation in
the guix repository without breaking the make process or the @command{guix
pull} machinery.

The manual and the cookbook both use Texinfo.  As for @code{packages},
please keep Texinfo markup as is.  There are more possible markup types in
the manual than in the package descriptions.  In general, do not translate
the content of @code{@@code}, @code{@@file}, @code{@@var}, @code{@@value},
etc.  You should translate the content of formatting markup such as
@code{@@emph}, @code{@@i}, etc.

The manual contains sections that can be referred to by name by
@code{@@ref}, @code{@@xref} and @code{@@pxref}.  We have a mechanism in
place so you do not have to translate their content.  If you keep the
English title, we will automatically replace it with your translation of
that title.  This ensures that Texinfo will always be able to find the
node. If you decide to change the translation of the title, the references
will automatically be updated and you will not have to update them all
yourself.

When translating references from the cookbook to the manual, you need to
replace the name of the manual and the name of the section.  For instance,
to translate @code{@@pxref@{Defining Packages,,, guix, GNU Guix Reference
Manual@}}, you would replace @code{Defining Packages} with the title of that
section in the translated manual @emph{only} if that title is translated.
If the title is not translated in your language yet, do not translate it
here, or the link will be broken.  Replace @code{guix} with @code{guix.xx}
where @code{xx} is your language code.  @code{GNU Guix Reference Manual} is
the text of the link.  You can translate it however you wish.

@item website

The website pages are written using SXML, an s-expression version of HTML,
the basic language of the web.  We have a process to extract translatable
strings from the source, and replace complex s-expressions with a more
familiar XML markup, where each markup is numbered.  Translators can
arbitrarily change the ordering, as in the following example.

@example
#. TRANSLATORS: Defining Packages is a section name
#. in the English (en) manual.
#: apps/base/templates/about.scm:64
msgid "Packages are <1>defined<1.1>en</1.1><1.2>Defining-Packages.html</1.2></1> as native <2>Guile</2> modules."
msgstr "Pakete werden als reine <2>Guile</2>-Module <1>definiert<1.1>de</1.1><1.2>Pakete-definieren.html</1.2></1>."
@end example

Note that you need to include the same markups.  You cannot skip any.
@end table

In case you make a mistake, the component might fail to build properly with
your language, or even make guix pull fail.  To prevent that, we have a
process in place to check the content of the files before pushing to our
repository.  We will not be able to update the translation for your language
in Guix, so we will notify you (through weblate and/or by email) so you get
a chance to fix the issue.

@subsubheading Outside of Weblate

Currently, some parts of Guix cannot be translated on Weblate, help wanted!

@itemize
@item @command{guix pull} news can be translated in @file{news.scm}, but is not
      available from Weblate.  If you want to provide a translation, you can
prepare a patch as described above, or simply send us your translation with
the name of the news entry you translated and your language. @xref{Writing Channel News}, for more information about channel news.
@item Guix blog posts cannot currently be translated.
@item The installer script (for foreign distributions) is entirely in English.
@item Some of the libraries Guix uses cannot be translated or are translated
      outside of the Guix project.  Guile itself is not internationalized.
@item Other manuals linked from this manual or the cookbook might not be
      translated.
@end itemize

@subsubheading Conditions for Inclusion

There are no conditions for adding new translations of the @code{guix} and
@code{guix-packages} components, other than they need at least one
translated string.  New languages will be added to Guix as soon as
possible.  The files may be removed if they fall out of sync and have no
more translated strings.

Given that the web site is dedicated to new users, we want its translation
to be as complete as possible before we include it in the language menu.
For a new language to be included, it needs to reach at least 80%
completion.  When a language is included, it may be removed in the future if
it stays out of sync and falls below 60% completion.

The manual and cookbook are automatically added in the default compilation
target.  Every time we synchronize translations, developers need to
recompile all the translated manuals and cookbooks.  This is useless for
what is essentially the English manual or cookbook.  Therefore, we will only
include a new language when it reaches 10% completion in the component.
When a language is included, it may be removed in the future if it stays out
of sync and falls below 5% completion.

@subsubheading Translation Infrastructure

Weblate is backed by a git repository from which it discovers new strings to
translate and pushes new and updated translations.  Normally, it would be
enough to give it commit access to our repositories.  However, we decided to
use a separate repository for two reasons.  First, we would have to give
Weblate commit access and authorize its signing key, but we do not trust it
in the same way we trust guix developers, especially since we do not manage
the instance ourselves.  Second, if translators mess something up, it can
break the generation of the website and/or guix pull for all our users,
independently of their language.

For these reasons, we use a dedicated repository to host translations, and
we synchronize it with our guix and artworks repositories after checking no
issue was introduced in the translation.

Developers can download the latest PO files from weblate in the Guix
repository by running the @command{make download-po} command.  It will
automatically download the latest files from weblate, reformat them to a
canonical form, and check they do not contain issues.  The manual needs to
be built again to check for additional issues that might crash Texinfo.

Before pushing new translation files, developers should add them to the make
machinery so the translations are actually available.  The process differs
for the various components.

@itemize
@item New po files for the @code{guix} and @code{packages} components must
      be registered by adding the new language to @file{po/guix/LINGUAS} or
@file{po/packages/LINGUAS}.
@item New po files for the @code{documentation-manual} component must be
      registered by adding the file name to @code{DOC_PO_FILES} in
@file{po/doc/local.mk}, the generated @file{%D%/guix.xx.texi} manual to
@code{info_TEXINFOS} in @file{doc/local.mk} and the generated
@file{%D%/guix.xx.texi} and @file{%D%/contributing.xx.texi} to
@code{TRANSLATED_INFO} also in @file{doc/local.mk}.
@item New po files for the @code{documentation-cookbook} component must be
      registered by adding the file name to @code{DOC_COOKBOOK_PO_FILES} in
@file{po/doc/local.mk}, the generated @file{%D%/guix-cookbook.xx.texi}
manual to @code{info_TEXINFOS} in @file{doc/local.mk} and the generated
@file{%D%/guix-cookbook.xx.texi} to @code{TRANSLATED_INFO} also in
@file{doc/local.mk}.
@item New po files for the @code{website} component must be added to the
      @code{guix-artwork} repository, in @file{website/po/}.
@file{website/po/LINGUAS} and @file{website/po/ietf-tags.scm} must be
updated accordingly (see @file{website/i18n-howto.txt} for more information
on the process).
@end itemize
