GNU 网站指南

我们的目标是向人们传递信息。保持网站设计简洁有助于实现这一目标。

目录

请体谅所有访问我们网页的人，并为他们提供便利，包括那些使用纯文本浏览器或旧浏览器的人，以及那些连接速度较慢的人。我们希望防止在某个浏览器版本下看起来很棒，而在其他许多浏览器下看起来很丑陋的网页设计。当然，如果您还没有使用任何专有网络浏览器，请不要安装它们。

通用指南

版权指南

拼写和标点

文件名

URL

HTML 指南

表格和菜单

使用我们的页面模板

样式

模板页面的样式

其他样式表

图形的使用

附录 1 - 链接策略

维护网页最复杂的方面之一是遵循链接准则；然而，它也是这项工作非常关键的一个方面。

我们努力确保我们推广的所有页面（即在我们网站上提供链接的所有页面）都对自由软件运动友好。某些页面显然不符合这些标准；如果该网站诽谤自由软件基金会和/或 GNU 项目，或者与自由软件及周边问题没有明显关系，则不应建立该链接。除此之外，还有一些标准用于确定是否适合从我们的网站提供指向页面的链接。它们按一般重要性降序排列如下。

链接的上下文是什么？

链接在我们网站上的目的将有助于确定应根据其他标准对其进行多大程度的判断。托管 GNU 项目的页面将受到最高标准的约束。关于其他自由软件的页面并给予高度推广（例如，包含在主页的新闻源中）是第二重要的。哲学页面上的链接在谈论专有软件时可能会有更多的回旋余地；GNU/Linux 用户组页面几乎总是应该将系统称为 GNU/Linux，但在其他标准上几乎不检查。在决定如何衡量这些策略的每个方面时，请始终记住这一点。

该页面是否推广专有软件？

自由软件运动提出的重点是，专有软件提出了一个道德困境：您不能同意这种非自由条款，并像您希望被对待的方式对待您周围的人。当推广专有软件时，人们会认为使用它是可以的，而我们正试图说服他们并非如此。因此，我们避免直接在我们的网站上或通过链接间接提供此类免费广告。

此标准中棘手的地方在于“推广”：提及专有软件与为其进行推销之间存在差异。实际上，GNU 项目网站始终提及专有软件，但绝不会给人们留下使用它不会产生道德问题的印象。

在确定对专有软件的引用是推广它还是仅仅提及它时，请记住两件事。首先，它提供有关该软件的多少信息？其次，读者可能从该页面实际获得多少信息？

不同的页面会提供关于专有软件的不同信息量；提供的信息越多，对我们来说问题就越大。例如，有些页面可能会链接到专有软件程序的主要站点。另一些页面可能会详细描述其功能。甚至给出的产品名称也很重要；“Windows”和“Microsoft Windows XP 家庭版”之间就存在差异。

引用的主题也会在决定引用的问题性方面发挥作用。如果该软件已经非常流行，那么对其进行基本提及不太可能对读者来说是新闻。一些被认为“众所周知”的常见专有软件的例子包括主要的操作系统（Windows、Mac OS、Sun OS、HP-UX）和主要的常用应用程序，如 Office、Internet Explorer、Chrome、Photoshop、Acrobat Reader 和 Flash。

GNU 软件项目页面会感受到此政策的全部影响。只有当 GNU 软件提供对专有软件的支持，或将其与知名的专有软件的功能进行比较时，才应提及专有软件。例如，以下文本（以及其他不多内容）是可以接受的：

w3 是 GNU Emacs 的网页浏览器，类似于 Internet Explorer。它可以在 GNU Emacs 运行的所有平台上运行，包括 GNU/Linux、专有的 Unix 系统和 Windows。

出现在其他区域（如推荐或哲学页面）中的链接，以及用户组或第三方组织的链接，可能会更详细地讨论此类软件，但仍应避免链接和鼓励“了解更多”的其他方法。

该页面如何比较自由软件和开源软件？

在我们网站上有链接的几乎所有页面，至少应平等对待自由软件和开源软件。未能做到这一点（无论是遗漏自由软件还是暗示开源软件更优越）通常是不可接受的。GNU 软件项目页面应很少提及开源软件。以下是一种巧妙的做法示例：

XYZ 是 GNU 项目的一部分，是自由/自由软件（有时称为开源软件）。

此规则的任何例外都应从上下文中显而易见。例如，用户组页面或 links.html 中列出的组织的页面可能会更详细地谈论开源；我们在这些页面上声明，“FSF 不对其他网站的内容或其信息的最新程度负责。”

页面如何对待 GNU 项目？

我们链接到的页面应该善待 GNU 项目。在这方面需要注意的主要一点是页面是否将该系统称为 GNU/Linux 而不仅仅是“Linux”。GNU 软件项目和用户组页面几乎绝不应该不这样做。同样，其他页面的例外情况应从上下文中显而易见。

也就是说，页面的某些部分不应根据这些标准进行考虑。例如，假设我们要链接到一个自由软件新闻网站上的页面。在确定其是否符合我们的链接指南时，文章附带的任何广告或读者评论都不会被考虑在内，因为它们被理解为各自作者的观点。同样，在用户组或第三方组织页面上，论坛和 wiki 页面的内容不应在这些方面具有重要意义。

最后，某些网站被理解为始终对大多数这些指南有例外情况。这些网站通常是关于重要但对自由软件运动有些边缘的问题。我们曾多次链接到电子前沿基金会的网站，即使他们鼓励使用 Flash，只谈论开源软件，并且不提倡用户重新分发和更改软件的自由。人们普遍认为，由于这些页面主要不是关于自由软件的，因此这些政策对其不完全适用。

作为最后的解释（来自 RMS）：即使从 www.gnu.org 建立链接，我们也不要求人们将该系统称为 GNU/Linux 或使用“自由软件”而不是“开源”。但是，我们要求他们不要推广任何非自由软件。

如果所有这些看起来都很复杂，那是因为，不幸的是，它确实如此。不用担心；随着时间和经验的积累，你会掌握它的窍门。在学习了解什么是可接受的和什么是不可接受的过程中，您可能会错误地评估一些页面；请随时向更有经验的网站管理员或像首席网站管理员或 RMS 这样的负责人寻求第二意见。新的例外情况总会出现；对此可能性保持开放的心态，并准备好妥善处理它们。

即使用户的浏览器拒绝运行 JavaScript 代码，页面是否也能正常工作？

如果页面需要非自由的、非平凡的 JavaScript，并且在禁用 JavaScript 的情况下会出现严重故障，则不应建立链接。同样，如果页面嵌入了 Flash，并且 Flash 播放起着重要的作用，如果视频不播放，人们将会错过一些重要的内容，则不应建立链接。

但是，在某些情况下，我们仍然可以通过使用解决方法来绕过 JavaScript 要求来引用此类页面和资源。

一种可能性是使用 GotHub 的实例——一个无需 JavaScript 即可工作的 GitHub 自由软件前端——来替换托管在 GitHub 上的页面和资源的链接，GitHub 是一个需要运行非自由 JavaScript 才能按预期使用的网站。

目前（2024 年 3 月），GotHub 没有得到积极维护，并且缺少某些功能。例如，它不提供在不访问 GitHub 网站的情况下浏览存储库或下载源代码的方法，也不提供 git 克隆 URL。不过，GotHub 对于某些用途很有帮助。例如，它非常适合链接到单个文件。

* 软件包。软件项目的一个有用的文件是 README 文件；它包含软件包的描述，通常是用户在尝试获取存储库之前想要看到的第一个内容。我们已经在 www.gnu.org 中多次应用此解决方案；例如，我们用这个替换了这个
https://github.com/pbatard/rufus
用这个替换了
https://gothub.projectsegfau.lt/pbatard/rufus.

另一种解决方案是直接链接到 GitHub 上标记提交的 tarball。这种方法的缺点是它对于随着时间的推移跟踪项目不是很有效。

* 图形、文档、手册。这些资源有时托管在用户页面中，即使它们托管在 GitHub 网站的某个区域内，也不需要 JavaScript 即可完全使用。在这些情况下，可以链接到此类页面。例如，我们将指向
https://github.com/foocorp/gnu-fm/blob/main/clients/meego/librefm/src/librefm-logo.png
的链接替换为指向
https://raw.githubusercontent.com/foocorp/gnu-fm/main/clients/meego/librefm/src/librefm-logo.png .
的链接
并且我们有指向诸如以下文档的链接：.

https://raw.githubusercontent.com/scootergrisen/licenser/master/gpl-3.0.da.txt

有时，资源可能托管在多个可接受的位置。它可以是 GitHub 或其他地方的个人页面，也可以是某个不相关的网站。在评估选择哪一个时，请考虑以下因素：文档的状态如何？它是最终版本还是有可能很快被修改？URL 是否可靠稳定，还是有可能被移动？
例如，过去我们遇到过这种情况，一个手册在 other-free-books.html 中列出，其 URL 为.
https://github.com/davidam/orgguide-es
当时，我们有三种可能性来替换该错误链接
1. GotHub
https://gothub.projectsegfau.lt/raw/davidam/davidam.github.io/master/docu/orgguide.es.pdf
2. 作者在 GitHub 上的个人空间
https://raw.githubusercontent.com/davidam/davidam.github.io/master/docu/orgguide.es.pdf
3. 出版商/书店
https://traficantes.net/sites/default/files/pdfs/orgguide.es_.pdf

我们决定选择第三个，因为该手册似乎不太可能更新到新版本，并且 Traficantes de Sueños 是一家知名的老牌出版商。
可以在没有 JavaScript 的情况下查看和浏览 GitHub 上的问题跟踪器，但积极参与需要一个帐户，而该帐户不能在没有运行非自由 JavaScript 的情况下创建。可以链接到已关闭的问题，就像我们对.
https://github.com/w3c/fingerprinting-guidance/issues/8

所做的那样。对于已关闭的问题，另一种可能性是链接到 Wayback Machine 上的存档页面。

附录 2 - 使用 Web CVS 代码仓库

基本的 CVS 命令

更改（除了 .symlinks 文件）应在几分钟内在 www.gnu.org 上可见。

有关 CVS 的更多详细信息，例如恢复到以前的版本，或查看特定更改的 diff 输出，请参阅 CVS 文档。

由于 CVS 无法直接处理符号链接，因此实现了一种单独的机制，允许网站管理员维护符号链接，如下所示。（实际上，符号链接不再在 www.gnu.org 上创建；而是使用 mod_rewrite 规则。但我们将继续讨论符号链接，因为它更容易理解。）

当提交到 CVS 树中时，名为 .symlinks 的特殊文件会被解释为构建符号链接的规范。.symlinks 文件中的每个符号链接规范都会被执行，即，如果符号链接尚不存在，则会创建它。如果在目录中找到符号链接，但该符号链接未列在 .symlinks 文件中，则会将其删除。

.symlinks 文件遵循 ln -s 格式，如下所述

这是一个 .symlinks 文件的示例

# Make a link named l.html to a target t.html.
# Strictly equivalent to ln -s t.html l.html:
t.html l.html

在每一行中，第一个文件名必须是现有文件的相对路径名。第二个文件名不能包含任何斜杠；它是要在当前目录中创建的符号链接的名称。例如，如果名为 dir.html 的页面存在于 /dir 目录中，并且 index.html 不存在，则 /dir/.symlinks 应该包含如下行

dir.html index.html

ln -s 的类比只说明了部分情况。当前方法实际上利用了 URL 重写的灵活性。因此，.symlinks 文件中的单个 HTML 条目定义了指向所有可能的遵循我们命名约定的翻译版本的链接。这使得无法使用符号链接来重定向到名称看起来像翻译的 HTML 文件或从这些文件重定向，即 page.ll.html 或 page.ll-cc.html，其中 ll 和 cc 是两位字母的代码。当您需要此类重定向时，请使用 htaccess 机制。

现在，.symlinks 的处理是通过 www.gnu.org 上的一个 cron 作业完成的，该作业每小时运行两次。网站管理员无权访问它。

.htaccess 和重定向

对于浏览器来说，上一节中的符号链接与实际文件没有区别。在某些情况下，您可能需要实际的重定向。您可以在顶层控制文件 .htaccess 中执行此操作，或者使用类似以下内容作为要重定向的文件

<meta http-equiv="refresh" content="0; url=https://gnu.ac.cn/target">

服务器端脚本

可以在 脚本和软件的描述中找到 www.gnu.org 上使用的脚本和软件的描述。在编写任何脚本之前，请阅读它，并且如果您具有写入 www 的权限，也请根据需要更新它。

系统管理员

GNU 的系统管理员会不时更换。请发送电子邮件至系统管理员列表 <[email protected]>，而不是发送给个人，除非您有特定的理由这样做。

有用的资源