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 程式碼，這個頁面也能運作嗎？

如果頁面需要非自由、非trivial 的 JavaScript，並且在停用 JavaScript 的情況下會發生嚴重錯誤，則不應建立連結。同樣地，如果頁面嵌入了 Flash，而 Flash 扮演重要的角色，以至於如果影片無法播放，使用者會錯失重要的內容，則也不應建立連結。

然而，在某些情況下，我們仍然可以使用替代方案來繞過 JavaScript 的要求，藉此連結到這類頁面和資源。

一種可能性是使用 GotHub 的實例—一個無需 JavaScript 即可運作的 GitHub 免費軟體前端—來取代連結到 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 中列出，網址為
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 上的 issue tracker 可以查看和瀏覽，而無需 JavaScript，但是積極參與需要一個帳戶，而建立帳戶不能在不執行非自由 JavaScript 的情況下完成。連結到已關閉的 issue 是可以的，就像我們對這個 issue 所做的那樣：
https://github.com/w3c/fingerprinting-guidance/issues/8.
對於已關閉的 issue，另一種可能性是連結到 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 job 進行，該 cron job 每小時執行兩次。網站管理員無法存取它。

.htaccess 和重新導向

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

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

伺服器端腳本

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

系統管理員

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

實用資源