doc: Add Simplified Chinese translation.

* doc/local.mk (info_TEXINFOS): Add guix.zh_CN.texi. (TRANSLATED_INFO): Add guix.zh_CN.texi and contributing.zh_CN.texi. * po/doc/local.mk (DOC_PO_FILES): Add guix-manual.zh_CN.po. * doc/contributing.zh_CN.texi, doc/guix.zh_CN.texi: New files.
2019-04-24 00:26:15 +02:00 · 2019-04-24 00:26:15 +02:00 · de712e5286
parent 3068509ac1
commit de712e5286
4 changed files with 26268 additions and 15 deletions
--- a/doc/contributing.zh_CN.texi
+++ b/doc/contributing.zh_CN.texi
@ -0,0 +1,897 @@
@node 贡献
@chapter 贡献
 这个项目是大家合作的成果，我们需要你的帮助以更好地发展。请通过
@email{guix-devel@@gnu.org} 和 Freenode IRC 上的 @code{#guix} 联系我们。我们欢迎
 您的想法、bug反馈、补丁，以及任何可能对项目有帮助的贡献。我们特别欢迎帮助我们打
 包（@pxref{打包指导}）。
@cindex 行为准则和贡献者
@cindex 贡献者契约
 我们希望提供一个温暖、友好，并且没有骚扰的的环境，这样每个人都能尽最大努力贡献。
 为了这个目的，我们的项目遵循“贡献者契约”，这个契约是根据
@url{http://contributor-covenant.org/}制定的。你可以在源代码目录里的
@file{CODE-OF-CONDUCT}文件里找到一份本地版。
 贡献者在提交补丁和网上交流时不需要使用法律认可的名字。他们可以使用任何名字或者假
 名。
@menu
 * 从Git编译::             最新的并且最好的.
 * 在安装之前运行Guix::  黑客技巧。
 * 完美的配置::          正确的工具。
 * 打包指导::             Growing the distribution.
 * 代码风格::             开发者的卫生情况
 * 提交补丁::             分享你的工作。
@end menu
@node 从Git编译
@section 从Git编译
 如果你想折腾Guix本身，建议使用Git仓库里最新的版本：
@example
 git clone https://git.savannah.gnu.org/git/guix.git
@end example
 当从Git检出构建Guix时，除安装指导（@pxref{Requirements}）里提及的软件包之外还需
 要这些包。
@itemize
@item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
@item @url{http://gnu.org/software/automake/, GNU Automake};
@item @url{http://gnu.org/software/gettext/, GNU Gettext};
@item @url{http://gnu.org/software/texinfo/, GNU Texinfo};
@item @url{http://www.graphviz.org/, Graphviz};
@item @url{http://www.gnu.org/software/help2man/, GNU Help2man （可选）}。
@end itemize
 设置Guix开发环境的最简单的方式当然是使用Guix！下面这些命令启动一个shell，所有的
 依赖和环境变量都为折腾Guix设置好了：
@example
 guix environment guix
@end example
 这个命令更多的信息请参考@xref{Invoking guix environment}。额外的依赖可以通过
@option{--ad-hoc}选项添加：
@example
 guix environment guix --ad-hoc help2man git strace
@end example
 运行 @command{./bootstrap} 以使用Autoconf和Automake生成编译系统的基础框架。如果
 你的得到这样的错误：
@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}.
 然后，像正常一样运行@command{./configure}。确保提供
@code{--localstatedir=@var{directory}}参数，@var{directory}是你当前系统的
@code{localstatedir}的值。（@pxref{The Store}）
 最后，用@code{make check}执行测试（@pxref{Running the Test Suite}）。如果遇到任
 何错误，请参考“安装指导”（@pxref{Installation}）或者给
@email{guix-devel@@gnu.org, 邮件列表}发邮件。
@node 在安装之前运行Guix
@section 在安装之前运行Guix
 为了保持一个合适的工作环境，你会发现在你的本地代码树里测试修改而不用安装它们会很
 有用。TODO: So that you can distinguish between your ``end-user'' hat and your
 ``motley'' costume.
 这样，即使你没有运行@code{make install}，所有的命令行工具都可以使用。为此，你先
 要有一个包含全部依赖的环境（@pxref{从Git编译}），然后，为所有的命令添加
 前缀@command{./pre-inst-env}（@file{pre-inst-env}脚本在Guix编译树的最顶层，它由
@command{./configure}生成），如@footnote{@command{sudo}命令的@option{-E}参数
 确保@code{GUILE_LOAD_PATH}被正确设置，从而@command{guix-daemon}和它使用的工具可
 以找到它们需要的Guile模块。}：
@example
 $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
 $ ./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 Guile Interactively,,, guile, Guile
 Reference Manual}):
@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
@command{pre-inst-env}脚本设置为此好了所有必要的的环境变量，包括@env{PATH}和
@env{GUILE_LOAD_PATH}。
@command{./pre-inst-env guix pull} @emph{不} 会更新本地源代码树，它只更新符号链
 接@file{~/.config/guix/current} (@pxref{Invoking guix pull})。如果你想更新本地源
 代码树，请运行@command{git pull}。
@node 完美的配置
@section 完美的配置
 折腾Guix的完美配置也是折腾Guile的完美配置@pxref{Using Guile in Emacs,,, guile,
 Guile Reference Manual})。首先，你需要的不仅是一个编辑器，你需要
@url{http://www.gnu.org/software/emacs, Emacs}，以及美妙的
@url{http://nongnu.org/geiser/, Geiser}。为此，请运行：
@example
 guix package -i emacs guile emacs-geiser
@end example
 Geiser允许在Emacs里进行交互式的、增长式的开发：buffer里的代码补全和执行，获取一
 行的文档（docstrings），上下文敏感的补全，@kbd{M-.}跳转到对象定义，测试代码的
 REPL，及更多（@pxref{Introduction,,, 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{http://www.emacswiki.org/emacs/ParEdit, Paredit}。它提供了直接操作语法树的
 的功能，例如，用S-表达式替换父节点，为S-表达式添加、删除前后的括号，删除后面的S-
 表达式，等等。
@cindex 代码片段
@cindex 模板
@cindex reducing boilerplate
 在@file{etc/snippets}文件夹里，我们还为普通的git commit信息和软件包定义提供模板。
 这些模板可以通过@url{http://joaotavora.github.io/yasnippet/, YASnippet}使用，它
 可以把短的触发字符串扩展成交互式的文字片段。你可能希望将这个文件夹添加到Emacs的
@var{yas-snippet-dirs}变量里。
@lisp
 ;; @r{假设Guix项目在 ~/src/guix.}
 (with-eval-after-load 'yasnippet
  (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))
@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{...}结尾的触发字符串，它们可以被继续展开。
@node 打包指导
@section 打包指导
@cindex 软件包, 创建
 这个GNU发行版正在开发的早期阶段，可能缺少一些你喜欢的软件。这个章节介绍你可以怎
 样帮助这个发行版成长。
 自由软件通常以@dfn{源代码包}的形式分发，通常是包含完整代码的@file{tar.gz}包。添
 加软件包到这个发行版意味着两件事：添加描述如何编译包的@dfn{配方}和一系列依赖软件，
 以及添加配方之外的@dfn{软件包元数据}，如一段文字描述和证书信息。
 在Guix里所有这些信息都包含在@dfn{软件包定义}里。软件包定义提供了软件包的高层视角。
 它们使用Scheme编程语言编写，事实上，对每个软件包我们都定义一个绑定到软件包定义的
 的变量，并且从模块（@pxref{Package Modules}）中导出那个变量。然而，深入的Scheme
 知识@emph{不}是创建软件包的前提条件。若要了解软件包的更多信息，@pxref{Defining
 Packages}。
 一旦软件包定义准备好了，并且包存在Guix代码树的一个文件里，你可以用@command{guix
 build} (@pxref{Invoking 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
 一旦你的软件包可以正确编译，请给我们发送补丁（@pxref{提交补丁}）。当然，
 如果你需要帮助，我们也会很乐意帮助你。一旦补丁被提交到Guix仓库里，这个新的软件包
 会被自动地在支持的平台上编译@url{http://hydra.gnu.org/jobset/gnu/master, our
 continuous integration system}。
@cindex substituter
 用户可以通过运行@command{guix pull}命令获取最新的软件包定义（@pxref{Invoking
 guix pull}）。当@code{@value{SUBSTITUTE-SERVER}}编译好这些软件包之后，安装这些软
 件包时会自动从服务器（@pxref{Substitutes}）上下载编译好的二进制包。唯一需要人工
 干预的地方是评审和应用代码补丁。
@menu
 * 软件自由::             什么可以进入这个发行版。
 * 软件包命名::          名字里包含什么？
 * 版本号::                当名字不够时
 * 简介和描述::          帮助用户寻找合适的软件包
 * Python模块::             接触英式的喜剧
 * Perl模块::               小珍珠。
 * Java包::                  喝咖啡休息。
 * 字体::                   字体的乐趣。
@end menu
@node 软件自由
@subsection 软件自由
@c ===========================================================================
@c
@c This file was generated with po4a. Translate the source file.
@c
@c ===========================================================================
@c Adapted from http://www.gnu.org/philosophy/philosophy.html.
@cindex 自由软件
 开发GNU操作系统是为了用户拥有计算的自由。GNU是@dfn{自由软件}，这意味着它有
@url{http://www.gnu.org/philosophy/free-sw.html,四项重要的自由}：运行程序的自由，
 以源代码形式学习和修改程序的自由，原样重新分发副本的自由，和分发修改后的版本的自
 由。GNU发行版里包含的软件包只提供遵守这四项自由的软件。
 此外，GNU发行版遵循
@url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,自由软
 件发行版准则}。这些准则拒绝非自由的固件和对非自由软件的推荐，并讨论解决商标和专
 利的方法。
 某些上游的软件包源代码包含一小部分违反上述准则的可选的子集，比如这个子集本身就是
 非自由代码。这时，这些讨厌的代码需要用合适的补丁或者软件包定义（@pxref{Defining
 Packages}）里的@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}。
 我们不给库软件包添加@code{lib}前缀，除非它是项目官方名字的一部分。但是
@pxref{Python模块}和@ref{Perl模块}有关于Python和Perl语言的特殊规则。
 字体软件包的名字处理起来不同，@pxref{字体}.
@node 版本号
@subsection 版本号
@cindex 软件包版本
 我们通常只为每个自由软件的最新版本打包。但是有时候，比如对于版本不兼容的库，需要
 有同一个软件包的两个或更多版本。它们需要使用不同的Scheme变量名。我们为最新的版本
 使用@ref{软件包命名}里规定的名字，旧的版本使用加上后缀的名字，后缀是@code{-}
 和可以区分开版本号的版本号的最小前缀。
 软件包定义里的名字对于同一个软件包的所有版本都是相同的，并且不含有版本号。
 例如，GTK+的2.24.20和3.9.12两个版本可以这样打包：
@example
 (define-public gtk+
  (package
    (name "gtk+")
    (version "3.9.12")
    ...))
 (define-public gtk+-2
  (package
    (name "gtk+")
    (version "2.24.20")
    ...))
@end example
 如果我们还需要GTK+ 3.8.2，就这样打包
@example
 (define-public gtk+-3.8
  (package
    (name "gtk+")
    (version "3.8.2")
    ...))
@end example
@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，以避免混淆。
@example
 (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 example
@node 简介和描述
@subsection 简介和描述
@cindex 软件包描述
@cindex 软件包简介
 我们已经看到，GNU@tie{}Guix里的每个软件包都包含一个简介（synopsis）和一个描述
 （description）（@pxref{Defining Packages}）。简介和描述很重要：它们是
@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''。
 Keep in mind that the synopsis must be meaningful for a very wide audience.
 For example, ``Manipulate alignments in the SAM format'' might make sense
 for a seasoned bioinformatics researcher, but might be fairly unhelpful or
 even misleading to a non-specialized audience.  It is a good idea to come up
 with a synopsis that gives an idea of the application domain of the
 package.  In this example, this might give something like ``Manipulate
 nucleotide sequence alignments'', which hopefully gives the user a better
 idea of whether this is what they are looking for.
 Descriptions should take between five and ten lines.  Use full sentences,
 and avoid using acronyms without first introducing them.  Please avoid
 marketing phrases such as ``world-leading'', ``industrial-strength'', and
 ``next-generation'', and avoid superlatives like ``the most
 advanced''---they are not helpful to users looking for a package and may
 even sound suspicious.  Instead, try to be factual, mentioning use cases and
 features.
@cindex Texinfo markup, in package descriptions
 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 package
 --show} take care of rendering it appropriately.
 Synopses and descriptions are translated by volunteers
@uref{http://translationproject.org/domain/guix-packages.html, at the
 Translation Project} 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.
 To allow @command{xgettext} to extract them as translatable strings,
 synopses and descriptions @emph{must be literal strings}.  This means that
 you cannot use @code{string-append} or @code{format} to construct these
 strings:
@lisp
 (package
  ;; @dots{}
  (synopsis "This is translatable")
  (description (string-append "This is " "*not*" " translatable.")))
@end lisp
 Translation is a lot of work so, as a packager, please pay even more
 attention to your synopses and descriptions as every change may entail
 additional work for translators.  In order to help them, it is possible to
 make recommendations or instructions visible to them by inserting special
 comments like this (@pxref{xgettext Invocation,,, gettext, GNU Gettext}):
@example
 ;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
 (description "ARandR is designed to provide a simple visual front end
 for the X11 resize-and-rotate (RandR) extension. @dots{}")
@end example
@node Python模块
@subsection Python模块
@cindex python
 We currently package Python 2 and Python 3, under the Scheme variable names
@code{python-2} and @code{python} as explained in @ref{版本号}.  To
 avoid confusion and naming clashes with other programming languages, it
 seems desirable that the name of a package for a Python module contains the
 word @code{python}.
 Some modules are compatible with only one version of Python, others with
 both.  If the package Foo compiles only with Python 3, we name it
@code{python-foo}; if it compiles only with Python 2, we name it
@code{python2-foo}. If it is compatible with both versions, we create two
 packages with the corresponding names.
 If a project already contains the word @code{python}, we drop this; for
 instance, the module python-dateutil is packaged under the names
@code{python-dateutil} and @code{python2-dateutil}.  If the project name
 starts with @code{py} (e.g.@: @code{pytz}), we keep it and prefix it as
 described above.
@subsubsection Specifying Dependencies
@cindex inputs, for Python packages
 Dependency information for Python packages is usually available in the
 package source tree, with varying degrees of accuracy: in the
@file{setup.py} file, in @file{requirements.txt}, or in @file{tox.ini}.
 Your mission, when writing a recipe for a Python package, is to map these
 dependencies to the appropriate type of ``input'' (@pxref{package Reference,
 inputs}).  Although the @code{pypi} importer normally does a good job
 (@pxref{Invoking guix import}), you may want to check the following check
 list to determine which dependency goes where.
@itemize
@item
 We currently package Python 2 with @code{setuptools} and @code{pip}
 installed like Python 3.4 has per default.  Thus you don't need to specify
 either of these as an input.  @command{guix lint} will warn you if you do.
@item
 Python dependencies required at run time go into @code{propagated-inputs}.
 They are typically defined with the @code{install_requires} keyword in
@file{setup.py}, or in the @file{requirements.txt} file.
@item
 Python packages required only at build time---e.g., those listed with the
@code{setup_requires} keyword in @file{setup.py}---or only for
 testing---e.g., those in @code{tests_require}---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.
 Examples are the @code{pytest}, @code{mock}, and @code{nose} test
 frameworks.  Of course if any of these packages is also required at
 run-time, it needs to go to @code{propagated-inputs}.
@item
 Anything that does not fall in the previous categories goes to
@code{inputs}, for example programs or C libraries required for building
 Python packages containing C extensions.
@item
 If a Python package has optional dependencies (@code{extras_require}), it is
 up to you to decide whether to add them or not, based on their
 usefulness/overhead ratio (@pxref{提交补丁, @command{guix size}}).
@end itemize
@node Perl模块
@subsection Perl模块
@cindex perl
 Perl programs standing for themselves are named as any other package, using
 the lowercase upstream name.  For Perl packages containing a single class,
 we use the lowercase class name, replace all occurrences of @code{::} by
 dashes and prepend the prefix @code{perl-}.  So the class @code{XML::Parser}
 becomes @code{perl-xml-parser}.  Modules containing several classes keep
 their lowercase upstream name and are also prepended by @code{perl-}.  Such
 modules tend to have the word @code{perl} somewhere in their name, which
 gets dropped in favor of the prefix.  For instance, @code{libwww-perl}
 becomes @code{perl-libwww}.
@node Java包
@subsection Java包
@cindex java
 Java programs standing for themselves are named as any other package, using
 the lowercase upstream name.
 To avoid confusion and naming clashes with other programming languages, it
 is desirable that the name of a package for a Java package is prefixed with
@code{java-}.  If a project already contains the word @code{java}, we drop
 this; for instance, the package @code{ngsjava} is packaged under the name
@code{java-ngs}.
 For Java packages containing a single class or a small class hierarchy, we
 use the lowercase class name, replace all occurrences of @code{.} by dashes
 and prepend the prefix @code{java-}.  So the class @code{apache.commons.cli}
 becomes package @code{java-apache-commons-cli}.
@node 字体
@subsection 字体
@cindex fonts
 For fonts that are in general not installed by a user for typesetting
 purposes, or that are distributed as part of a larger software package, we
 rely on the general packaging rules for software; for instance, this applies
 to the fonts delivered as part of the X.Org system or fonts that are part of
 TeX Live.
 To make it easier for a user to search for fonts, names for other packages
 containing only fonts are constructed as follows, independently of the
 upstream package name.
 The name of a package containing only one font family starts with
@code{font-}; it is followed by the foundry name and a dash @code{-} if the
 foundry is known, and the font family name, in which spaces are replaced by
 dashes (and as usual, all upper case letters are transformed to lower
 case).  For example, the Gentium font family by SIL is packaged under the
 name @code{font-sil-gentium}.
 For a package containing several font families, the name of the collection
 is used in the place of the font family name.  For instance, the Liberation
 fonts consist of three families, Liberation Sans, Liberation Serif and
 Liberation Mono.  These could be packaged separately under the names
@code{font-liberation-sans} and so on; but as they are distributed together
 under a common name, we prefer to package them together as
@code{font-liberation}.
 In the case where several formats of the same font family or font collection
 are packaged separately, a short form of the format, prepended by a dash, is
 added to the package name.  We use @code{-ttf} for TrueType fonts,
@code{-otf} for OpenType fonts and @code{-type1} for PostScript Type 1
 fonts.
@node 代码风格
@section 代码风格
 In general our code follows the GNU Coding Standards (@pxref{Top,,,
 standards, GNU Coding Standards}).  However, they do not say much about
 Scheme, so here are some additional rules.
@menu
 * Programming Paradigm::     How to compose your elements.
 * Modules::                  Where to store your code?
 * Data Types and Pattern Matching::  Implementing data structures.
 * Formatting Code::          Writing conventions.
@end menu
@node Programming Paradigm
@subsection Programming Paradigm
 Scheme code in Guix is written in a purely functional style.  One exception
 is code that involves input/output, and procedures that implement low-level
 concepts, such as the @code{memoize} procedure.
@node Modules
@subsection Modules
 Guile modules that are meant to be used on the builder side must live in the
@code{(guix build @dots{})} name space.  They must not refer to other Guix
 or GNU modules.  However, it is OK for a ``host-side'' module to use a
 build-side module.
 Modules that deal with the broader GNU system should be in the @code{(gnu
@dots{})} name space rather than @code{(guix @dots{})}.
@node Data Types and Pattern Matching
@subsection Data Types and Pattern Matching
 The tendency in classical Lisp is to use lists to represent everything, and
 then to browse them ``by hand'' using @code{car}, @code{cdr}, @code{cadr},
 and co.  There are several problems with that style, notably the fact that
 it is hard to read, error-prone, and a hindrance to proper type error
 reports.
 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.
@node Formatting Code
@subsection Formatting Code
@cindex formatting code
@cindex coding style
 When writing Scheme code, we follow common wisdom among Scheme programmers.
 In general, we follow the @url{http://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.
 Some special forms introduced in Guix, such as the @code{substitute*} macro,
 have special indentation rules.  These are defined in the
@file{.dir-locals.el} file, which Emacs automatically uses.  Also note that
 Emacs-Guix provides @code{guix-devel-mode} mode that indents and highlights
 Guix code properly (@pxref{Development,,, emacs-guix, The Emacs-Guix
 Reference Manual}).
@cindex indentation, of code
@cindex formatting, of code
 If you do not use Emacs, please make sure to let your editor knows these
 rules.  To automatically indent a package definition, you can also run:
@example
 ./etc/indent-code.el gnu/packages/@var{file}.scm @var{package}
@end example
@noindent
 This automatically indents the definition of @var{package} in
@file{gnu/packages/@var{file}.scm} by running Emacs in batch mode.  To
 indent a whole file, omit the second argument:
@example
 ./etc/indent-code.el gnu/services/@var{file}.scm
@end example
@cindex Vim, Scheme code editing
 If you are editing code with Vim, we recommend that you run @code{:set
 autoindent} so that your code is automatically indented as you type.
 Additionally, @uref{https://www.vim.org/scripts/script.php?script_id=3998,
@code{paredit.vim}} may help you deal with all these parentheses.
 We require all top-level procedures to carry a docstring.  This requirement
 can be relaxed for simple private procedures in the @code{(guix build
@dots{})} name space, though.
 Procedures should not have more than four positional parameters.  Use
 keyword parameters for procedures that take more than four parameters.
@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.
 This mailing list is backed by a Debbugs instance accessible at
@uref{https://bugs.gnu.org/guix-patches}, which allows us to keep track of
 submissions.  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{NNN}@@debbugs.gnu.org}, where @var{NNN} is the tracking
 number (@pxref{Sending a Patch Series}).
 Please write commit logs in the ChangeLog format (@pxref{Change Logs,,,
 standards, GNU Coding Standards}); you can check the commit history for
 examples.
 Before submitting a patch that adds or modifies a package definition, please
 run through this check list:
@enumerate
@item
 If the authors of the packaged software provide a cryptographic signature
 for the release tarball, make an effort to verify the authenticity of the
 archive.  For a detached GPG signature file this would be done with the
@code{gpg --verify} command.
@item
 Take some time to provide an adequate synopsis and description for the
 package.  @xref{简介和描述}, for some guidelines.
@item
 Run @code{guix lint @var{package}}, where @var{package} is the name of the
 new or modified package, and fix any errors it reports (@pxref{Invoking guix
 lint}).
@item
 Make sure the package builds on your platform, using @code{guix build
@var{package}}.
@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 following service to the list of services in
 your @code{operating-system} configuration:
@example
 (service qemu-binfmt-service-type
 (qemu-binfmt-configuration
   (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))
   (guix-support? #t)))
@end example
 Then reconfigure your system.
 You can then build packages for different platforms by specifying the
@code{--system} option.  For example, to build the "hello" package for the
 armhf, aarch64, or mips64 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
 guix build --system=mips64el-linux --rounds=2 hello
@end example
@item
@cindex bundling
 Make sure the package does not use bundled copies of software already
 available as separate packages.
 Sometimes, packages include copies of the source code of their dependencies
 as a convenience for users.  However, as a distribution, we want to make
 sure that such packages end up using the copy we already have in the
 distribution, if there is one.  This improves resource usage (the dependency
 is built and stored only once), and allows the distribution to make
 transverse changes such as applying security updates for a given software
 package in a single place and have them affect the whole system---something
 that bundled copies prevent.
@item
 Take a look at the profile reported by @command{guix size} (@pxref{Invoking
 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{Packages with Multiple Outputs}), and which optional
 dependencies should be used.  In particular, avoid adding @code{texlive} as
 a dependency: because of its extreme size, use @code{texlive-tiny} or
@code{texlive-union} instead.
@item
 For important changes, check that dependent package (if applicable) are not
 affected by the change; @code{guix refresh --list-dependent @var{package}}
 will help you do that (@pxref{Invoking guix refresh}).
@c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
@cindex branching strategy
@cindex rebuild scheduling strategy
 Depending on the number of dependent packages and thus the amount of
 rebuilding induced, commits go to different branches, along these lines:
@table @asis
@item 300 dependent packages or less
@code{master} branch (non-disruptive changes).
@item between 300 and 1,200 dependent packages
@code{staging} branch (non-disruptive changes).  This branch is intended to
 be merged in @code{master} every 3 weeks or so.  Topical changes (e.g., an
 update of the GNOME stack) can instead go to a specific branch (say,
@code{gnome-updates}).
@item more than 1,200 dependent packages
@code{core-updates} branch (may include major and potentially disruptive
 changes).  This branch is intended to be merged in @code{master} every 2.5
 months or so.
@end table
 All these branches are @uref{https://hydra.gnu.org/project/gnu, 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.
 Generally, branches other than @code{master} are considered @emph{frozen} if
 there has been a recent evaluation, or there is a corresponding @code{-next}
 branch.  Please ask on the mailing list or IRC if unsure where to place a
 patch.
@item
@cindex determinism, of build processes
@cindex reproducible builds, checking
 Check whether the package's build process is deterministic.  This typically
 means checking whether an independent build of the package yields the exact
 same result that you obtained, bit for bit.
 A simple way to do that is by building the same package several times in a
 row on your machine (@pxref{Invoking guix build}):
@example
 guix build --rounds=2 my-package
@end example
 This is enough to catch a class of common non-determinism issues, such as
 timestamps or randomly-generated output in the build result.
 Another option is to use @command{guix challenge} (@pxref{Invoking guix
 challenge}).  You may run it once the package has been committed and built
 by @code{@value{SUBSTITUTE-SERVER}} 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
 When writing documentation, please use gender-neutral wording when referring
 to people, such as @uref{https://en.wikipedia.org/wiki/Singular_they,
 singular ``they''@comma{} ``their''@comma{} ``them''}, and so forth.
@item
 Verify that your patch contains only one set of related changes.  Bundling
 unrelated changes together makes reviewing harder and slower.
 Examples of unrelated changes include the addition of several packages, or a
 package update along with fixes to that package.
@item
 Please follow our code formatting rules, possibly running the
@command{etc/indent-code.el} script to do that automatically for you
 (@pxref{Formatting Code}).
@item
 When possible, use mirrors in the source URL (@pxref{Invoking guix
 download}).  Use reliable URLs, not generated ones.  For instance, GitHub
 archives are not necessarily identical from one generation to the next, so
 in this case it's often better to clone the repository.  Don't use the
@command{name} field in the URL: it is not very useful and if the name
 changes, the URL will probably be wrong.
@end enumerate
 When posting a patch to the mailing list, use @samp{[PATCH] @dots{}} as a
 subject.  You may use your email client or the @command{git send-email}
 command (@pxref{Sending a Patch Series}).  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.
 When a bug is resolved, please close the thread by sending an email to
@email{@var{NNN}-done@@debbugs.gnu.org}.
@unnumberedsubsec Sending a Patch Series
@anchor{Sending a Patch Series}
@cindex patch series
@cindex @code{git send-email}
@cindex @code{git-send-email}
@c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
 When sending a patch series (e.g., using @code{git send-email}), please
 first send one message to @email{guix-patches@@gnu.org}, and then send
 subsequent patches to @email{@var{NNN}@@debbugs.gnu.org} to make sure they
 are kept together.  See @uref{https://debbugs.gnu.org/Advanced.html, the
 Debbugs documentation} for more information.
--- a/doc/guix.zh_CN.texi
+++ b/doc/guix.zh_CN.texi
--- a/doc/local.mk
+++ b/doc/local.mk
@ -24,7 +24,8 @@
 info_TEXINFOS = %D%/guix.texi			\
  %D%/guix.es.texi				\
  %D%/guix.fr.texi				\
-  %D%/guix.de.texi
+  %D%/guix.de.texi				\
  %D%/guix.zh_CN.texi
 %C%_guix_TEXINFOS = \
  %D%/contributing.texi \
@ -59,9 +60,11 @@ TRANSLATED_INFO = \
  %D%/guix.de.texi				\
  %D%/guix.es.texi				\
  %D%/guix.fr.texi				\
  %D%/guix.zh_CN.texi				\
  %D%/contributing.de.texi			\
  %D%/contributing.es.texi			\
-  %D%/contributing.fr.texi
+  %D%/contributing.fr.texi			\
  %D%/contributing.zh_CN.texi
 # Bundle this file so that makeinfo finds it in out-of-source-tree builds.
 BUILT_SOURCES        += $(OS_CONFIG_EXAMPLES_TEXI) $(TRANSLATED_INFO)
--- a/po/doc/local.mk
+++ b/po/doc/local.mk
@ -19,7 +19,8 @@
 DOC_PO_FILES=					\
  %D%/guix-manual.es.po				\
  %D%/guix-manual.de.po				\
-  %D%/guix-manual.fr.po
+  %D%/guix-manual.fr.po				\
  %D%/guix-manual.zh_CN.po
 EXTRA_DIST = \
  %D%/guix-manual.pot \