GNU 網站指南

我們的目標是將資訊傳達給人們。保持網站設計簡潔有助於實現這一目標。

目錄

請體諒所有存取我們網頁的人，並為他們提供便利，包括那些使用純文字瀏覽器或舊瀏覽器的人，以及那些連線速度較慢的人。我們希望防止網站設計在某個瀏覽器的某個版本下看起來很棒，但在許多其他瀏覽器下卻很醜陋的情況。當然，如果您還沒有使用任何專有網頁瀏覽器，請不要安裝它們。

通用指南

著作權指南

拼字和標點符號

檔案名稱

網址

HTML 指南

表格和選單

使用我們的頁面範本

樣式

範本頁面的樣式

其他樣式表

圖形的使用

附錄 1 - 連結政策

維護網頁最複雜的方面之一是遵循連結指南；但是，這也是工作的一個非常關鍵的方面。

我們力求確保我們宣傳的所有頁面（我們網站上給出連結的所有頁面）都對自由軟體運動友好。某些頁面顯然不符合此類標準；如果該網站抨擊自由軟體基金會和/或 GNU 計畫，或者與自由軟體及周邊問題沒有明顯的關係，則不應建立連結。然而，除此之外，還有一些標準用於確定從我們的網站提供指向頁面的連結是否合適。它們在下面按一般重要性降序排列。

連結的背景是什麼？

連結在我們網站上的用途將在確定應根據其他標準對其進行多嚴格的判斷方面發揮作用。託管 GNU 專案的頁面將受到最高標準的約束。關於其他自由軟體並給予高度宣傳的頁面（例如，包含在首頁的新聞提要中）緊隨其後。哲學頁面上的連結在談論專有軟體時可能會被給予更多的自由；GNU/Linux 使用者群組頁面幾乎總是應呼叫系統為 GNU/Linux，但幾乎不檢查其他標準。在決定如何權衡這些政策的各個方面時，始終請記住這一點。

該頁面是否宣傳專有軟體？

自由軟體運動提出的重點是，專有軟體提出了倫理困境：您不能同意此類非自由條款，並且像您希望被對待那樣對待您周圍的人。當專有軟體被宣傳時，人們會覺得使用它是可以的，而我們正試圖說服他們不要這樣做。因此，我們避免提供此類免費廣告，無論是直接在我們的網站上還是透過連結間接提供。

此標準的棘手之處在於「宣傳」點：提及專有軟體和為其進行銷售宣傳之間存在差異。實際上，GNU 計畫網站始終提及專有軟體，但從未給人留下其使用不存在倫理問題的印象。

在確定對專有軟體的引用是宣傳它，還是僅僅提及它時，有兩件事要記住。首先，它提供有關該軟體的多少資訊？其次，讀者可能從此頁面實際獲得多少資訊？

不同的頁面提供不同數量的有關專有軟體的資訊；它提供的資訊越多，它對我們造成的問題就越多。例如，某些頁面可能會連結到專有軟體程式的主要網站。其他頁面可能會詳細描述其功能。即使給出的產品名稱也很重要；「Windows」和「Microsoft Windows XP Home Edition」之間存在差異。

引用的主題也將在確定引用有多成問題方面發揮作用。如果該軟體已經非常流行，那麼對它的基本提及不太可能成為讀者的新聞。一些常見到足以被認為是「眾所周知」的專有軟體範例是主要作業系統（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 的實例（一個適用於 GitHub 的自由軟體前端，無需 JavaScript 即可運作）來取代指向 GitHub（一個網站，需要執行非自由 JavaScript 才能按預期方式使用）託管的頁面和資源的連結。

目前（2024 年 3 月），GotHub 並未積極維護，並且缺少某些功能。例如，它沒有提供在不造訪 GitHub 網站的情況下瀏覽儲存庫或下載原始碼的方法，並且它沒有提供 git clone 網址。儘管如此，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 中的個人頁面或其他地方，或者在一些不相關的網站中。在評估選擇哪一個時，請考慮以下因素：文件的狀態是什麼？它是最終版本還是有可能隨時修改？網址是否可靠穩定，還是有可能移動？

例如，過去我們有一個手冊的案例，該手冊在 other-free-books.html 中列出，網址為
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 是一家歷史悠久、著名的出版商。

GitHub 上的問題追蹤器可以在沒有 JavaScript 的情況下檢視和瀏覽，但積極參與需要一個無法在不執行非自由 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 的處理透過每小時執行兩次的 cron 工作在 www.gnu.org 上進行。網站管理員無法存取它。

.htaccess 和重新導向

對於瀏覽器來說，上一節中的符號連結與實際檔案沒有區別。在某些情況下，您可能需要實際的重新導向。您可以透過頂層控制檔案 .htaccess 執行此操作，或使用如下內容作為要重新導向的檔案

<meta http-equiv="refresh" content="0; url=https://gnu.dev.org.tw/target">

伺服器端腳本

www.gnu.org 上使用的腳本和軟體描述已提供。在撰寫任何腳本之前，請先閱讀它，如果您有 www 的寫入權限，也請根據需要更新它。

系統管理員

GNU 的系統管理員會不時更換。除非您有特殊原因，否則請發送電子郵件給系統管理員列表 <sysadmin@gnu.org>，而不是個人。

實用資源