维基教科书:功能请求

维基教科书特有的错误和功能请求列表。 要将以下错误/请求之一直接提交给开发人员（以及查看其他错误和功能请求），请参阅 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://wikibooks.cn/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://wikibooks.cn/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)