華夏公益教科書:功能請求

這是一個已廢棄的存檔專案頁面，保留以供歷史參考。它可能包含過時的資訊。在 Bugzilla 上請求功能。在華夏公益教科書：閱讀室中與社群討論可能的特性。

華夏公益教科書特有的錯誤和功能請求列表。要將以下錯誤/請求之一直接提交給開發人員（以及檢視其他錯誤和功能請求），請參閱 Mediazilla。

錯誤

冒號引導錯誤？

冒號“：”，當它作為一行中的第一個專案時，會執行縮排功能。但是，如果它放在模組中第一行的最前面，則不再是這種情況。它曾經有效（我所有的德語高階課程都以縮排的說明段落開頭；現在它們都以“：此頁面...”開頭），但最近剛停止工作。如果在以冒號開頭的行之前新增一個空行，則功能將恢復。這是一個錯誤還是新的怪癖？ - Marsh 2004 年 2 月 28 日 02:27 (UTC)

模板和跨維基連結

跨維基連結是否不允許在 mediawiki 訊息中使用？我已經放置了

此榮譽勳章的要求受美國童子軍協會的版權保護。它們部分轉載於此，根據合理使用，作為童軍和童軍領袖在獲得和教授榮譽勳章方面的資源。美國童子軍協會發布的要求應始終用於替代此處的列表。如果對要求的準確性有任何疑問，請諮詢您的榮譽勳章顧問。
閱讀此頁面不滿足任何榮譽勳章的要求。根據國家規定，唯一可以簽署要求的人是榮譽勳章顧問，該顧問經過當地理事會正式註冊和授權。要獲取註冊的榮譽勳章顧問的清單，或開始榮譽勳章，請聯絡您的童軍領袖或理事會服務中心。

在某些討論頁面上，它顯然無法正常工作，儘管它在 Template:Meritbadgedisclaimer 上顯示良好。 TUF-KAT 2004 年 2 月 28 日 20:11 (UTC)

我注意到標題沒有從 mediawiki 頁面繼承，但我不知道是不是這樣。相反，使用以下程式碼，它適用於以下情況

The requirements to this merit badge are copyrighted by the Boy Scouts of America. 
 They are reproduced in part here under [http://en.wikipedia.org/wiki/fair_use fair use]

看起來像

此榮譽勳章的要求受美國童子軍協會的版權保護。它們部分轉載於此，根據合理使用。

錯誤 : MSIE 執行時錯誤

在 MSIE 中瀏覽華夏公益教科書時，我一直收到執行時錯誤：“addcss 未定義”。通常是在導致錯誤的任何東西的第 18 行左右，但有時它會報告其他數字，例如 17。我在任何其他維基媒體網站上都沒有遇到這個問題，只是華夏公益教科書。維基文庫、維基語錄等網站都正常載入。我在華夏公益教科書的所有頁面上都遇到了這個問題，儘管如此。 :( --Furrykef 2004 年 5 月 25 日 19:22 (UTC)[回覆]

錯誤 : "編輯幫助" 彈出視窗太小

我剛看了“編輯幫助”，想重新整理一下某事。彈出的視窗比我想象的要小，而且它被設定成我無法調整大小。我不知道更改這些東西有多難（它是否嵌入在 MediaWiki 程式碼中？），但我認為我應該記錄一下我的體驗。（...而且我真的很喜歡 MediaWiki 的新外觀！） --Rs2 2004 年 6 月 1 日 17:31 (UTC)

您使用什麼瀏覽器/作業系統？ Sj

錯誤 : 使用者登入訊息

使用者登入頁面上“給我發一個新密碼”按鈕下面的訊息顯示不正確：錨標籤可見（儘管連結是可點選的）

要註冊，只需選擇使用者名稱和密碼，然後點選“建立新帳戶”。有關選擇使用者名稱的提示，請參見<a href="http://wikibooks.org/wiki/Wikibooks:Username">使用者名稱</a>頁面。請選擇可讀的名稱，不要只是數字。

如果您需要有關登入的更多資訊，請參見<a href="http://wikibooks.org/wiki/Wikibooks:How_to_log_in">如何登入</a>頁面。

回頭使用者只需填寫使用者名稱和密碼。

您必須啟用<A HREF="http://en.wikipedia.org/wiki/HTTP_cookie">cookies</A>才能登入華夏公益教科書。

--surueña 2005 年 4 月 14 日 08:23 (UTC)

錯誤 : SVG 影像渲染問題

不確定這是維基系統上的錯誤，還是可能是 Chrome 瀏覽器上的錯誤。

我建立了一個模板，使用以下程式碼。

<templatestyles src="End-user Computer Security/Upvote downvote section links/styles.css" />

<table style="padding:0px;margin:0px">
<tr valign="top" style="padding:0px;margin:0px">
<td>
[[Image:Thumbs up font awesome.svg|15px|⬆ Up-vote `{{{sectionname|error: no section name specified}}}` section|link=https://wikibook.tw/w/index.php?title={{urlencode:{{TALKPAGENAME}}}}&action=edit&section=new&preloadtitle=👍%20{{urlencode:{{{sectionname|error: no section name specified}}}}}&preload=Template:End-user_Computer_Security/Upvote_section|class=upvoteicon]]
</td>
<td style="padding-top:5px">
[[Image:Thumbs up font awesome.svg|15px|⬇ Down-vote `{{{sectionname|error: no section name specified}}}` section|link=https://wikibook.tw/w/index.php?title={{urlencode:{{TALKPAGENAME}}}}&action=edit&section=new&preloadtitle=👎%20{{urlencode:{{{sectionname|error: no section name specified}}}}}&preload=Template:End-user_Computer_Security/Downvote_section|class=downvoteicon]]
</td>
</tr>
</table>

過了一會兒，在使用了一段時間的模板後，突然之間，SVG 影像就停止顯示了，無論是在模板中，還是在使用模板的地方。但是，如果我將模板程式碼中其中一個影像的畫素大小從 15px 更改為其他大小，則突然之間影像開始出現在模板程式碼中（即使是其他影像仍然將大小設定為 15px）。但是，在使用模板的地方，影像仍然沒有顯示（即使影像在檢視模板（預覽）時顯示）。為了使影像在使用模板的地方顯示，我發現我需要做的就是新增程式碼以以 15px 以外的解析度顯示 SVG 影像。然後突然模板引用開始正常工作。

影像開始工作後，上述用來“解決”它的措施可以撤銷，並且影像可以正常工作。但是，過了一會兒，錯誤再次出現，影像再次停止顯示。再次執行這些措施可以“解決”它，但過了一會兒它又停止工作。

由於上述“奇怪”的行為，我強烈懷疑這實際上是一個錯誤，而不是我做錯了什麼。可能是某種快取問題嗎？

發現問題的系統

網際網路瀏覽器：Google Chrome。

作業系統：ChromeOS，版本 76.0.3809.136（官方版本）（64 位）。

計算機：宏碁 Chromebook C720 系列。

附錄
如果將解析度永久更改為 20px（如 Mrjulesd 所建議），此問題似乎已解決。可能是華夏公益教科書方面的縮放問題？

--MarkJFernandes (討論 • 貢獻) 2020年4月30日 (星期四) 17:01 (UTC)[回覆]

🏆 Mrjulesd 已識別出此錯誤/問題的具體性質，並提出了一種解決方法。詳細資訊請見他下面的訊息

是的，我認為我在 HTML 程式碼中找到了問題，這是點贊圖示的 img 標籤

<img alt="⬆ Up-vote section | error: no section name specified" src="//upload.wikimedia.org/wikipedia/commons/thumb/e/ef/Thumbs_up_font_awesome.svg/16px-Thumbs_up_font_awesome.svg.png" decoding="async" width="16" height="16" class="upvoteicon" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/e/ef/Thumbs_up_font_awesome.svg/24px-Thumbs_up_font_awesome.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/e/ef/Thumbs_up_font_awesome.svg/32px-Thumbs_up_font_awesome.svg.png 2x" data-file-width="512" data-file-height="512" />

問題出在 srcset 屬性：它訪問的其中一個圖示（取決於縮放比例）是 https://upload.wikimedia.org/wikipedia/commons/thumb/e/ef/Thumbs_up_font_awesome.svg/24px-Thumbs_up_font_awesome.svg.png，而該圖示恰好是空白的。因此，這不是 MediaWiki 軟體的直接問題，而是它試圖從 Commons 訪問的影像資料集中的一個問題，其中缺少一個影像。

一種解決方法是訪問另一個圖示，這一個圖示存在問題，具體取決於瀏覽器縮放比例。如果以前沒有報告過，可能值得在 Phabricator 上提及。 Jules (Mrjulesd) 2020年5月1日 (星期五) 10:37 (UTC)[回覆]

錯誤：影像連結集中不允許使用相對 URL

我不確定這是否是一個錯誤，但為了保持一致性，影像連結集中似乎應該允許使用相對 URL，就像文字連結集中允許使用相對 URL 一樣。我不是 Wikibooks 編輯方面的專家，所以問題可能更多地在於我的知識不足。無論如何，能夠為影像設定相對 URL 在使用影像作為圖示時非常有用。這就是我一直以來的做法，因為否則超連結文字的顏色方案會破壞書籍的視覺美觀。如果這不是一個錯誤，請將其歸類為功能請求，因為實現此功能是可取的。

--MarkJFernandes (討論 • 貢獻) 2020年4月17日 (星期五) 11:59 (UTC)[回覆]

功能請求

在書籍中搜索

如何將搜尋範圍限制在一本書中？ JWSchmidt 2004年3月15日 (星期一) 14:31 (UTC)

目前無法在單本書中搜索。你可以透過在搜尋中包含書籍標題來近似地實現這一點，但無法限制這種搜尋。 TUF-KAT 2004年3月15日 (星期一) 22:10 (UTC)

Entrez Bookshelf 上的書籍有一個很好的搜尋功能。我不確定在沒有對書籍進行有用的搜尋和索引的情況下，是否可以讓多個貢獻者構建一本複雜的科學或技術書籍。 JWSurf 2004年3月16日 (星期二) 00:20 (UTC)

我完全同意我們需要一個書籍特定的搜尋功能。這是我在網站最初開始使用書籍名稱結構化頁面時所提出的論點，例如：wiki/bookname/partofbook。但是，即使我們沒有朝這個方向發展，最終我們應該擁有一個書籍特定的功能。例如，現在有了 MediaWiki 目錄功能，每本書的每一頁都包含一個標籤，將其連結回目錄，而新的軟體可以將搜尋範圍限制在包含該標籤的頁面。但是，我們需要等待開發人員完成這項工作。據我所知，這些傢伙沒有得到報酬，而且已經被工作壓得喘不過氣來……但隨著時間的推移，它應該會發生（Karl 充滿希望，儘管沒有關於開發流程的具體個人經驗）。 --Karl Wick

我不知道開發人員是否投入了任何時間來設計這樣的功能，但絕對需要一個標準的“在本本書中搜索”介面選項，即使它不完美。 Sj 2004年8月9日 (星期一) 22:16 (UTC)

可以透過在搜尋欄位末尾使用prefix:選項將搜尋範圍限制在單本書中。例如，搜尋Stephenson prefix:History of Rail Transport可以找到鐵路運輸史中所有提及Stephenson的頁面。更多資訊請訪問WB:SEARCH。 — Sam Wilson ( 討論 • 貢獻 ) … 2014年3月10日 (星期一) 23:23 (UTC)[回覆]

自動編號

有沒有辦法進行自動方程式編號？對於數學和許多科學書籍來說，能夠說“見方程 1.4c”（第 1.4 節中的第三個編號方程式）肯定會很有用，但手動嘗試這樣做很麻煩。我可能會在結束時得到順序錯誤的方程式標籤和與參照物不匹配的引用。使用 # 不起作用 Carandol

沒有。抱歉……你可以手動插入 TeX，但它並不漂亮。 Dysprosia 2004年4月21日 (星期三) 06:48 (UTC)

書籍特定佈局功能

Wiki 軟體似乎沒有針對書籍寫作的任何特定功能。是否有任何開發人員正在開發新增支援的功能？據我瞭解，即使為一本書中的所有頁面新增目錄也必須手動完成。 Norman Weiner

這方面有什麼進展嗎？所需的特徵規範？ Sj 2004年7月23日 (星期五) 05:50 (UTC)

標籤和用於影像生成的外部程式

擁有類似於數學標籤的影像標籤是個好主意。它將使影像可編輯，標籤內的命令將由外部程式處理以生成 png。書籍中的大多數圖片都是向量圖形，這也將有助於將書籍的原始檔集中在一個地方。有什麼意見嗎？ Norman Weiner

你的意思是什麼？像 SVG 的東西？你可能想把功能請求提交到 Sourceforge。 Dysprosia 06:06, 24 Apr 2004 (UTC)

它不一定要是 SVG。目前，math 標籤包含 TeX 標記。我們可以在一個 graphics 標籤內使用圖形程式的標記。我希望這裡 Wikibooks 的負責人能夠在達成共識的情況下，與 sourceforge 的開發者進行協商。一個單獨的請求可能不會引起注意。 Norman Weiner

當然，對於更技術性的書籍來說，這和自動編號都是有用的。Wikibooks 可以使用 Gnuplot 和/或 SVG 來製作圖表和圖形，並支援 LaTeX 的一些自動編號功能。要實現這些需要做些什麼？ Carandol

需要做的就是有人在 sourceforge 中檢入程式碼。math 模組似乎是一個獨立的模組，用 ocaml 編寫 (!)。 Norman Weiner

目前是否有建立數學/科學書籍圖表的標準程式/風格？我已經查找了，但沒有找到任何標準。 magefile

我的程式設計技能太基礎了，無法對程式碼做任何事情。我想我們能做的就是提出請求，看看是否有人會跟進。 Carandol

表格/線上問卷

Mediawiki 引擎能夠允許建立簡單的表單（彈出列表、文字框、單選按鈕）就好了，這些表單最終可以用於像粗糙的線上問卷或快速輸入表單之類的事情。--DougHolton 21:30, 16 May 2004 (UTC)[回覆]

當前語言的隨機頁面

雖然“隨機模組”功能很好，但我遇到了一些非我母語的頁面。我建議在偏好設定中新增一個選項，將隨機頁面限制在當前語言。

--Eibwen 06:08, 25 Sep 2004 (UTC)

隱藏自己的貢獻

另一個有用的過濾器是隱藏你自己的貢獻，尤其是當你創作了許多出現在 最近更改 頁面上的頁面時。

--Eibwen 22:20, 25 Sep 2004 (UTC)

將滑鼠懸停在連結上時顯示連結預覽

維基百科有一個非常好的功能，當滑鼠懸停在任何一個指向維基百科文章的超連結上時，都會顯示該連結文章的小預覽。這個功能在 Wikibooks 上似乎不可用。我建議實現這個功能，以便至少對指向維基百科文章的連結自動顯示預覽。

--MarkJFernandes (討論 • 貢獻) 13:53, 15 April 2020 (UTC)[回覆]

包含書籍的格式化皮膚

有些書籍帶有插圖和裝飾，這些裝飾有時也是功能性的。為此，為標題和超連結選擇的配色方案可能成為審美裝飾和書籍功能屬性的重要方面。目前，似乎無法覆蓋為連結設定的顏色。我建議允許釋出書籍格式化皮膚，與書籍一起釋出，如果使用者希望覆蓋書籍的自定義皮膚，那也沒問題。

我已經發現你實際上可以在 Wikibooks 創作端自定義連結的顏色，請參見 https://en.wikipedia.org/wiki/Help:Link_color#Styling_individual_links_on_a_page。因此，這個功能請求不再需要。

--MarkJFernandes (討論 • 貢獻) 11:29, 27 April 2020 (UTC)[回覆]

更高效和更有效的法律宣告

每次我進行頁面編輯時，都會出現關於適用許可和條款的法律宣告。因為此類文字隨時可能更改，所以每次我進行頁面編輯時，都應該檢查文字自上次編輯後是否已更改。這對使用者來說可能是昂貴的。確實，我可以只複製文字，然後進行瀏覽器搜尋，看看文字是否完全相同，但這也是對使用者的懲罰（為了使用者）。更好的做法是，法律宣告只顯示一次，然後可以選擇一個複選框，指示 Wikibooks 除非文字更改，否則不要顯示宣告。

上傳也是如此，儘管上傳可能由維基共享資源而不是 Wikibooks 處理。

大多數網站的使用者協議都很糟糕。所以，如果我批評你的協議，不要感到難過。無論如何，在許多網站上使用一份使用者協議是一件很棒的事情。你應該保持這種做法，並儘可能多地採用這種做法。這意味著使用者在切換到姊妹網站時，通常不必繼續閱讀新的協議。此外，另一件好事是你不會頻繁更新你的條款和條件。這也節省了使用者使用你的網站所需要花費的工作。

如果你更改了你的條款和條件，並且之前只有一個協議，你應該起草兩份新檔案：一份檔案應該是新的協議；另一份檔案應該是一個簡短的修訂檔案，它只是修訂了之前的協議，以便讓使用者充分了解新的協議，同時在使用者已經處理了之前的協議的情況下，減少他們總體工作量。然後使用者可以選擇處理哪份檔案，這兩份檔案在本質上都相當於相同的使用者協議。當存在幾個歷史版本協議時，也適用同樣的原則。不要建立一個非法律約束力的“模糊”檔案，描述協議更改的方式。除了大體瞭解事情的變化方式之外，此類檔案通常無用。當你可以建立一個具有法律約束力的修訂檔案時，這比“模糊”檔案好得多。始終要思考，使用者需要做多少工作才能儘快上手。

你的法律協議應該在起草過程中經過多次迭代，每次迭代都簡化條款，提高可讀性和可用性。不要想著在寫作上創造一個“烏托邦”，而是要想著在實踐中創造一個“烏托邦”。許多網站和公司都犯了在寫作上創造“烏托邦”的錯誤，他們最終往往會得到大多數人可能忽略的冗長協議。此類公司的例子有：Facebook、Twitter、WhatsApp、Microsoft。使用者協議的目的不是講述你是誰的故事。去掉廢話。使用者協議的目的是作為一份法律合同，明確規定法律關係，使使用者儘快上手。

您應該從使用者端轉向提供商端考慮條款和條件。這是因為，對於一份寫得不好的協議，以及龐大的使用者群（也許有百萬使用者），使用者和提供商共同進行的與合同相關的總工作量通常遠高於編寫好協議以及使用者處理一份寫得好的協議所涉及的工作量。

MarkJFernandes (討論 • 貢獻) 2020年5月6日 (星期三) 09:38 (UTC)[回覆]

事實上，我認為我們很多年來都沒有改變過我們的許可證。大多數姊妹專案都使用相同的許可證（我知道只有維基新聞是例外，因為新聞的性質要求它更廣泛地傳播），而且我聽說近年來許多姊妹專案希望升級到新版本（從3.0到4.0？），但事實證明在舊版本和新版本之間存在相容性問題。我相信，通知的顯示方式是由維基媒體法律部門決定的，我總體上感覺他們可能傾向於專業上的偏執。--Pi zero (討論 • 貢獻) 2020年5月6日 (星期三) 12:42 (UTC)[回覆]

順便說一下，@MarkJFernandes: 由於此頁面標記為“歷史”，我建議我們將所有這些內容提取出來，並將其移至閱讀室之一。--Pi zero (討論 • 貢獻) 2020年5月6日 (星期三) 12:47 (UTC)[回覆]

@Pi zero: 👍 將內容移至閱讀室。由於版權問題，我們可能應該使用轉包而不是複製貼上（出於對其他作者貢獻的尊重）。如果你不做，我可能有一天會做。謝謝。 🙏

MarkJFernandes (討論 • 貢獻) 2020年5月6日 (星期三) 17:03 (UTC)[回覆]