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 的一个 Web 浏览器，类似于 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 上的页面和资源的链接，该网站需要运行非自由 JavaScript 才能按预期使用。

目前（2024 年 3 月），GotHub 没有得到积极维护，并且缺少某些功能。例如，它没有提供一种在不访问 GitHub 网站的情况下浏览存储库或下载源代码的方法，并且它没有提供 git clone 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 命令

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

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

作为符号链接意味着当符号链接跳转到不同的目录时，来自链接页面的相对链接可能会中断。

名为 .symlinks 的特殊文件在提交到 CVS 树时，会被解释为构建符号链接的规范。将遵守来自 .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]>，而不是发送给个人，除非您有特别的原因这样做。

有用的资源