Reading/Web/Desktop Improvements/Frequently asked questions/zh





如何禁用或启用Vector 2022？


我该如何在单个或所有维基媒体项目上启用或禁用它？
首先，检查您是否已经登录. 未登录用户无法更改皮肤.

参见：
 * 为什么要命名为Vector 2022和旧版Vector？



为什么未登录用户无法使用切换外观按钮？
因为服务器性能有限. 未登录用户可以通过浏览器扩展来定制外观，或者也可以创建账户.

参见：


 * 为什么匿名用户没有参数设置？



如何让Vector 2022成为我所有维基媒体的维基主页的默认设置？
联系我们. 我们会向你的社群展示该项目并开始讨论.



如何在自己的/私人维基上启用？
如果您喜欢该更改，


 * 1) 请确定您已下载
 * 2) 在加入下列内容：

我们很高兴知道您赞许我们的改进！



如何自定义Vector 2022？


为什么你们不提供设置以让用户在不同版本的功能之间进行选择？
那样會過於复杂，难以维护和开发.

每个设置都像是一个可以讓用户自行选择的十字路口. 多個选择意味着多種组合. 参数设置会造成我们要对所有的组合负责. 我们就必须维护它们，并且在构建新功能时，還要检查这些功能是否能与每種组合都兼容. 我们心有餘而力不足.

取而代之的是，我们为社群提供了创建小工具、用户脚本、和个人设置的选项. 一如既往，我们提供空间給小到細節、大到總體的创造力，并協助技术用户维护他们的代码.

另见： 
 * 只需将其设置为用户偏好即可

为什么匿名用户没有参数设置？
匿名的置参数设置会造成页面加载的速度太慢.

大部分流量来自未登录用户. 为了应对这一问题，我们有一些“缓存服务器”，它们只保存和发送网页的“快照”. 作为生成网页的替代品，这些“快照”最多持续七天，且对所有未登录用户而言都是相同的. 这能让服务器更快地运行.

提供参数设置意味着要生成不同版本的网页. 这有可能导致未登录用户让服务器超载. 不向匿名用户提供参数设置也是因为我们希望减少缓存的碎片化.

向匿名用户提供参数设置的唯一办法是让设置在页面之后加载. 这会导致加载时间变长而且看起来很奇怪. 例如，如果一个未登录用户想使用暗黑模式，那么在访问页面时，页面会先以浅色模式加载，然后再变暗.

因此，我们为登录用户提供参数设置的唯一原因是我们不向他们提供“快照”. 这是因为来自登录用户的流量很小.

参见：


 * 新加坡的新数据中心如何帮助全球各地的人访问维基百科
 * 构建DReaMeRS：我们如何以及为何在法国开设数据中心
 * 为什么性能很重要



你们为需要特定工具和功能的编辑者们做了什么？

 * 我们联系了有技术能力的志愿者以确保向后兼容性. 我们让他们检查了自己编写的代码，并在代码需要更改时提供帮助.
 * 我们使配置和个性化我们的更改成为可能. 我们很高兴与具有技术且愿意创建新的小工具和用户脚本的志愿者合作.
 * 我们不会取代有技术的志愿者的工作. 原则上，我们不会对编辑模板或创建新的小工具，但会在必要时提出建议.



你们是否会修复因你们的修改而不兼容的小工具？
看情况.

我们帮助志愿者修复小工具和用户脚本. 有时，我们自己修复这些. 但总的来说，我们的工作在MediaWiki本身上. 小工具和用户脚本由志愿者编写和维护. 从本质上讲，这些总是不太稳定和可预测的.

如果您不确定如何解决脚本或小工具的问题——联系我们！ 我们将尽最大努力就潜在的修正提供通知.

参见：


 * 元維基中技術的討論——您也可以在这里寻求技术支持
 * Stable interface policy/Frontend——定義哪些代码是稳定的以及我们如何弃用这些代码的一项政策
 * Recommendations for gadget developers on Wikimedia wikis——关于小工具和用户脚本的角色和责任的一些建议



哪些CSS类选择器可以用于自定义Vector 2022？

 * ：所有皮肤
 * ：旧版Vector
 * ：Vector 2022

See also:



如何恢复全宽度？
如果您的屏幕宽度至少有1400px，您应该会在底角看到一个按钮. 单击它将会恢复完全宽度.

你也可以：

要重新使用网页边缘的空间，请将以下CSS代码添加到您的global.css：

参见：


 * Vector 2022的修改：新的小工具和用户脚本



如何禁用粘性元素？
将以下CSS代码添加到您的global.css：


 * 标题——添加
 * 目录——添加



如何恢复內嵌式目录
使用下方的JS：

Note, the table of contents will not look like the old table of contents. Additional CSS will be required for that, if necessary.



如何将章节编号恢复到目录
将下列CSS代码添加到您的global.css：

User:Jdlrobson/vector-2022/tocNumbering.css

<span id="How_to_make_the_button_with_language_links_appear_at_the_top_of_the_main_page?">

如何使带有语言链接的按钮出现在主页顶部？

 * 1) 请您的社区同意设置主页标题.  （请参阅我们的解释为什么这是一个好主意. ）
 * 2) 标题将显示在Vector 2010、Minerva、Timeless和Vector 2022中.  它在Monobook中不可见.
 * 3) 可以通过编辑登录用户的标题MediaWiki:Mainpage-title-loggedin和注销用户的MediaWiki:Mainpage-title来配置标题.  对于移动登录用户，使用MediaWiki:wikimedia-mobile-mainpage-title-loggedin.  请参阅有关主页标题设置的详细信息.
 * 4) 通过将 参数添加到URL来测试主页的外观并使用顶部的按钮.  请参阅冰岛语维基百科上的示例.  请注意，冰岛语维基百科没有设置标题，因此仅显示按钮.
 * 5) 联系我们，并请求我们将按钮移到顶部.
 * 6) 我们将更改您的Wiki的设置.
 * 7) 当我们这样做时，该按钮将在Vector 2022的页面顶部可见.  在其他皮肤中，带有语言链接的列表将显示在标准位置，该位置因皮肤而异.

<span id="How_to_restore_the_previous_user_menu?">

如何恢复以前的用户菜单？
目前无法做到这一点.

<span id="How_to_change_the_logo_to_a_temporary_one?">

如何将Logo更改为临时Logo？
Vector 2022中的Logo由3个元素组成，每个元素都可以使用CSS独立更改.
 * 更改图标的图像（例如维基百科上的地球仪）：
 * 更改文字标记（例如「维基百科」這一词）：
 * 更改标语（例如「自由的百科全书」）：

联络方式
<span id="How_can_I_contact_your_team?">

如何联系你们的团队？
选择下列中的一个：
 * 项目主页的討論页面(您可以用任何语言书写)
 * 带有桌面改进项目标签的Phabricator任务
 * 请联系我们的社群关系专家：SGrabarczuk (WMF) sgrabarczuk@wikimedia.org
 * 联系我们的大使：


 * 西班牙大使：IZapico (WMF) izapico-ctr@wikimedia.org
 * 越南大使：Bluetpp (WMF) ppham-ctr@wikimedia.org
 * 俄罗斯、格鲁吉亚、土耳其和阿塞拜疆大使：Mehman (WMF) mibragimov-ctr@wikimedia.org

<span id="How_can_I_follow_your_activities?">

我如何跟进你们的活动？

 * 订阅我们的電子报. 您将收到有关更新的通知，而不是在用户讨论页上的信息.
 * 请关注我们的最新消息和与网络对话页面.

<span id="Do_you_host_or_attend_online_meetings?">

你们会举办或出席线上会议吗？
会！

我们组织社群在线公开会议. 在这些会议上，Olga（我们的产品经理）会介绍最近的发展情况. 接下来，社群成员可以就项目提出任何问题.

我们也欢迎网上任何社群活动的邀请. 这些会议可以是地方会议、全国性会议，也可以是国际会议.



<span id="What_are_Vector_2022_and_the_Desktop_Improvements?">

Vector 2022和桌面版改进是什么？
<span id="Is_this_a_redesign?">

这是重新设计吗？
不是.

重新设计是对网站运行方式的一次重大改变. 就本项目而言，我们进行了一系列单独的改动. 每个功能都是一个独立的小项目. 最后，这些功能通过协调一致的视觉设计连接在一起.

<span id="What_is_the_timeline_of_this_project?">

這個项目的时间表是什么？
自2019年以来，我们一直著手在做Vector 2022（最初称为 "现代Vector"）. 在2020年初至2022年中期間，我们曾在「早期采用者」wiki上构建并发佈了不同的功能. (您可以在下面问题的第2-4点的答案中了解更多信息. )

我们已经完成了该部分. Vector 2022不再是個“测试”了. 目前，我们打算在所有的wiki上引入Vector 2022.

<span id="Why_do_you_use_the_word_Improvements?">

为什么你們會使用“改进”一词？
因为我们有数据表明，改变是为了更好地：
 * 1) 通过对读者和编辑的研究，我们发现了一些问题.  在2019年的这一阶段，我们研究了人们使用网站的方式，并找出了最大的可用性问题.  我们还发现了进一步探索网站、更多参与阅读或编辑的问题.  为此，我们采访了多个国家、地区和语言的读者和编辑.  参见：研究与设计：第一阶段、研究与设计：第二阶段.
 * 2) 我们制作并测试了原型.  我们构思出每项功能，并开始向用户展示.  通过采访和更多轮的原型测试，读者和编辑对每项功能都进行了测试.  在对编辑进行测试时，我们使用了中央通知横幅.  我们通过多种语言和维基媒体项目展示了这些作品，这样我们就能获得广泛而多样的受众.  每个原型平均接受了约200名编辑者的测试.  (示例)
 * 3) 我们完善并构建了我们的功能.  我们根据原型测试的反馈意见，对原型进行了相应的改进或修改.  在某些情况下，我们会征求更多的反馈意见，以确保我们做出正确的决定.
 * 4) 我们联系了多个wiki，要求加入早期采用者（"试点维基"）.  这就是「Beta」阶段.  在这些wiki上，我们对每个功能进行了定量测试，其是否有如预期运行.
 * 5) 我们对已登录的用户进行了A/B测试.  遗憾的是，我们无法对注销的用户执行这些操作.  这就是我们进行前后对比的原因.
 * 6) 拿到测试结果后，我们将其与之前定义的成功标准进行比较.  测试结果不理想时，我们改变了功能，然後再次测试一次.
 * 7) 从这一阶段开始，我们还对所有wiki的使用情况进行了监测，许多账户持有人已经在那裏開始使用Vector 2022.

另见：


 * 一篇百科全书式的條目：迭代式开发
 * 一篇博客文章：Vector界面的迭代设计：移动跨语言链接案例

<span id="On_which_wikis_have_you_tested_these_changes?">

你们已在哪些wiki测试了这些更改？
我们一直在测试Vector 2022的试点维基有：

<span id="Why_do_you_use_this_naming:_Vector_2022_and_legacy_Vector?">

为什么要命名为Vector 2022和旧版Vector？
新皮肤是原始Vector中的許多元素的延续. 它的代码是建立在旧版Vector皮肤的基础上的. 我们希望保持功能和视觉上的延续性. 之前为旧版Vector所构建和设计的一切，我们的修改都应能配合起作用，或者可以相当容易地进行配置而起作用.

在2010年建立、发展至2019年的版本目前已被冻结. 换句话说，我们将保留和维护它，但不会为它开发新功能.

我们使用「Vector 2022」这個名称纯属技术原因. 这个名称标志着新的Vector可以作为新皮肤提供给第三方wiki. (第三方是指安装MediaWiki的人).

在每个wiki上，可以更改MediaWiki:Skinname-vector-2022来覆盖皮肤的名称. 不过，这可能会造成混乱，因为它不会更改用于网站和用户样式的相关皮肤键.

参见： <span id="Will_you_remove_legacy_Vector?">
 * 哪些CSS类选择器可以用于自定义Vector 2022？

你们会移除旧版Vector吗？
不会.

旧版Vector皮肤仍将作为参数设置中的可选项存在，就像过去的默认皮肤（如Monobook）那样.



<span id="Target_audience">

終端-{zh-hant:讀者;zh-hans:受众}-
<span id="Are_these_changes_made_for_readers,_and_not_for_editors?">

这些改变不是为了编辑者，而是为了读者嗎？
不完全是.

我们的团队 (Web) 致力于提升桌面和移动浏览器的阅读（查看）体验. 那些既阅读条目又编辑的人、加上阅读条目但不编辑的人，是界面用户中的一大群体. 我们为他们所有的人工作，時刻牢记新手与老手都會有特定的需求.

本项目的目标是在不增加编辑难度的情况下改善桌面版的阅读体验.

話說回來，我们的运动战略建议恳求我们以包容的方式去改善用户体验. 本着此一精神，该项目有一个具体目标，即确保自由知识能在未来公平增长. When building, we made sure to collect the voices of readers from different demographics and geographies. We also wanted to make their opinions a focus when defining what we were to work on, and evaluating whether a given idea was able to satisfy their needs.

参见： <span id="What_tools_are_the_Foundation_building_for_editors?">
 * What do you do to ensure that the change is not half-finished?
 * What do you do for editors who need specific tools and features?
 * Past projects of the Web team

基金会为编辑者们制作了什么工具？
At the Foundation, there are other teams working on projects dedicated specifically to editors. 其中包括： <span id="Do_your_changes_have_a_negative_effect_on_the_editing_statistics?">
 * Community Tech – working on projects selected by the communities during the Community Wishlist Survey
 * Editing – working on the discussion tools
 * Growth – working on the Newcomer experience project
 * Moderator Tools – focusing on the moderation needs of medium-sized Wikimedia projects
 * Trust and Safety Product – working on tools for stewards, CUs, administrators, and other anti-vandalism patrollers

你们的修改是否对编辑的统计数据产生了负面影响？
没有.

我们在所有的维基上收集相关统计数据. 与以旧版Vector（2010）作为默认设置的维基相比，以Vector（2022）作为默认设置的维基并没有受到负面影响.

<span id="Do_your_changes_make_it_more_difficult_to_explore_the_community_side_of_the_wikis?">

你们的修改是否会使了解wiki社群变得更加困难？
不会.

读者和新编辑者常常被维基媒体项目的侧边栏中大量的链接、选项和探索编辑的方式（换而言之——社群）吓倒. 这是我们研究得到的结果.

我们希望更多的用户参与到社群中. 因此，我们限制了放在外面的链接的数量，希望能将他们的注意力带到最相关的链接上. 所有这些都是与Growth和Editing团队合作完成的.

参见： <span id="Are_you_focused_on_Wikipedia_articles?">
 * 核心经验
 * UX Myth #12: More choices and features result in higher satisfaction

你们是否关注维基百科的条目？
是的.

与维基百科或任何其它项目上的其它命名空间相比，维基百科的条目有着最多的浏览量和读者数量. 我们还对其它命名空间的页面和特殊页面进行了调整. 我们特别调整和配置的有：主页、一些姊妹项目的特定页面、特殊页面、2010版维基文本编辑器、2017版维基文本编辑器和可视化编辑器.

我们还一直在与编辑者们合作，以确保他们为讨论页面所做的工作与我们的工作保持一致，并确保讨论页的特殊配置到位.

<span id="Have_you_been_mindful_of_sister_projects?">

你们有关注姊妹项目吗？
有！

我们的目标是改变界面的基本元素. 大多数功能都适用于姐妹项目，就像它们对维基百科的改善一样. 我们从项目一开始就在为不同的姊妹项目进行测试和构建. 我们仍然会在必要时对默认功能进行调整.

非维基百科项目，例如法语维基词典，自2020年来也是与我们合作的社群之一. 我们确定我们之间有直接的沟通和反馈.

关于调整，例如，在维基文库上，限制宽度不适用于 页面校对扩展提供的Page命名空间.

Are you focused on English Wikipedia?
No.

We take into account the needs of various communities and test our changes across 30+ languages. We are also inspired by the interface and gadgets built on various wikis, for example Korean and Vietnamese Wikipedias.

<span id="What_do_you_do_to_ensure_that_the_change_would_work_on_my_wiki?">

你们如何确定这些更改在我的wiki上有效？

 * 我们的研究与所有的维基有关，我们听取了来自许多语言版本和项目的声音.
 * 我们收集并整合了来自社群的反馈. 大多数问题都与所有wiki相关.
 * 我们如何调整对姊妹项目的更改——请见“你们有关注姊妹项目吗？”
 * 我们对小工具的态度是什么——请见“你们为需要特定工具和功能的编辑者们做了什么？”

<span id="What_do_you_do_to_ensure_that_the_change_is_not_half-finished?">

你们怎么确定这些修改不是半成品？
我们在wiki上引入更改之前和之后都会进行调整，以确保它们满足各个社群的需求. 如果您认为您的社群会从更多调整和小工具中受益，请参阅：


 * 你们为需要特定工具和功能的编辑者们做了什么？
 * 如何自定义Vector 2022？

After making these changes on all wikis, we will work on projects related to Desktop Improvements.

易用性
<span id="Have_your_changes_been_tested_on_users_with_disabilities?">

你们是否已为身心障碍用户测试过修改？
是的. 我们正在与美国盲人基金会合作. 我们正在咨询与Vector 2022的易用性相关的各种问题. 在Phabricator上了解进一步信息.

<span id="Will_the_wikis_be_less_accessible_for_users_with_slow_Internet_connection?">

对网络链接较差的用户而言，维基项目是否会更难访问？
不会.

我们希望新皮肤的代码量能与旧版Vector相近.

参见：


 * How can I get both the old and the new table of contents?

<span id="Mobile,_large_screens,_and_responsiveness">

移动版、大屏幕、以及响应能力
<span id="Are_the_changes_inspired_by_mobile_design?">

这些更改是否受到了移动版设计的启发？
不是.

这些更改是专为桌面版作出的. 该项目所有相关的研究与测试均仅針對桌面版用户. 不过，我们也考虑到了在较窄屏幕上使用桌面的用户的体验（例如，两个并排打开的标签页）.

目前，我们並没有合并桌面和移动体验的计划.

<span id="Will_the_new_interface_be_responsive?">

新界面是否会响应快速？
我们一直在努力实现这一目标，但这并不是项目的正式目标.

如果你想让界面现在就响应快速，而你正在使用维基媒体的维基，请在你的 global.js 中添加以下内容：

如果您的社群希望它成为默认设置，请在您的维基上开始讨论，并在达成共识后联系我们. 然后，我们就可以进行更改.

Will you build a dedicated setting for high resolutions?
We don't have plans to build a specific setting at this time. We want the experience to be optimized for the majority of users, while still providing the tools necessary at all resolutions. We believe the current version of the new skin does this successfully. That said, we encourage personal customization!

参见：


 * 你们为需要特定工具和功能的编辑者们做了什么？



Why have you replaced the area used for content by an empty space?
Reading efficiently is crucial to most people using our projects. Our goal here is to improve the readability of the content. There are several factors that affect it – i.e. font size, contrast, font, line length, and empty space.


 * Shorter lines
 * 1) When reading short lines, readers don't move their eyes too much, use the eye's muscles less intensively, thus avoiding eye strain.
 * 2) Narrow paragraphs allow readers to memorize new information better.
 * 3) On websites, there should be between 35 and 100 characters per line. Numbers closer to the smaller end are preferred.
 * 4) The overwhelming number of major websites have similar limitations on content width. For example: academic journals like Nature, news websites like The New York Times, government and intergovernmental websites like the United Nations, academic documents like LaTeX, and word processors like Google Docs and Etherpad.


 * Empty (white) space


 * 1) White space is used for the eyes' resting spots. It helps readers over the age of 60 focus on content and increases content comprehension by 20%.
 * 2) People are able to focus more easily without the distraction of sidebars or other elements.
 * 3) We are using some of this space for other functionality. We have made the sidebar sticky, and have placed the table of contents next to the content. Also, limiting the content area gives us new options for the more distant future. Community members have suggested to put infoboxes, images, or references there. As a separate project, we will consider ways of using this space.

参见：


 * UX Myth #28: White space is wasted space

Why can’t we leave it for readers to narrow their browser windows down?
Most users don't resize their browser windows or use browser plugins to improve the design of the websites they view. Wikis should be good-looking immediately, in their basic form.

Some tables and templates don’t fit within the limited width
We should make sure that all of our content is as responsive as possible to accommodate all visitors. A large percentage of our users, who don’t have large screens and are accessing Wikipedia from their laptops, already had issues with tables and templates even before the change.

Why don’t you just make it a setting?
我们希望它成为默认设置. 我们正在构建一种编辑者与读者共享的体验. 这有助于编辑者考虑页面布局. 当前，编者可能在编辑一个1500px宽度的页面，而读者则在阅读一个1200px宽度的页面. By implementing a limited width, we don’t remove this discrepancy (because there would still be variation below the max-width, for people with narrower screens), however we would be greatly limiting the range of variation.

<span id="Why_did_you_change_the_list_of_language_links?">

为什么你们修改了跨语言链接列表？
<span id="Why_couldn&#039;t_the_list_of_language_links_stay_in_the_sidebar?">

为什么跨语言链接列表不能留在侧边栏？
因为根据读者的反馈，侧边栏不是一个放置有用链接的地方. 大多数读者关注的是内容部分. 侧边栏的链接实际上是不在他们的视线范围内的.

此外，我们需要增加维基媒体项目的语言版本.

15 年来，该列表一直显示在侧边栏中. 最活跃的用户已经形成了肌肉记忆——可以在那里寻找那个列表. 这就是为什么在侧边栏中，我们放置了一个信息框来提示语言列表换位置了.

<span id="Will_the_Wikidata_links_be_closer_to_the_list_of_language_links?">

维基数据链接会更靠近语言链接列表吗？
会.

“”、“”和“”将逐渐成为由语言切换按钮所打开的菜单（“语言菜单”）的一部分. 这是语言工程团队的任务.

How to fix the coordinates displaying incorrectly near the languages button?
For those who prefer a working example, details on how this was fixed for English Wikipedia can be found here: T281974.

Consider pages which use page status indicators, pages which have banners or site notices, and the look of the pages at lower resolutions.

Why doesn't the button with language links appear at the top of the main page?
We have discovered that readers focus on the content page and ignore the sidebar. They will be more likely to switch between languages if the button with the language links appears at the top of the page, next to the heading.

On many wikis, headings on main pages are hidden. This is why the button with language links isn't displayed next to it. Instead, it's at the bottom of the main pages. It is possible to make it appear at the top, though.

参见：
 * How to make the button with language links appear at the top of the main page?

Why doesn't the table of contents work well on my mobile device or when I resize the browser?
Users on mobile and resized browsers account for a small fraction of page traffic. Because of this, we chose to build the feature for the majority of our users first. For narrow screens we plan to make the table of contents available as a sticky interface element that's accessible from anywhere in the page.

Note what is displayed to mobile devices differs from what you see when you resize your browser. On mobile devices, the site is currently presented as a zoomed out version of the desktop site.

Is it possible to change the label indicating the top of the page? ("")
可以.

This label should be distinct from the content headings. To do that, wikis written in different scripts (for example, Latin and Japanese) and different Wikimedia projects (Wikipedia and Wiktionary) may need to use different words and/or punctuation marks in this label. It is possible for each community to set up a label that would work just for them. This may be done by editing the page MediaWiki:Vector-toc-beginning.

How can I get both the old and the new table of contents?
这不可能.

We intentionally do not add the old table of contents in addition to the new sidebar location. It's a trade off. We have taken it to reduce the work involved maintaining the code and keeping the site work as well as possible. The old table of contents displayed in addition to the new one would have important technical disadvantages. It would increase the overall size of HTML, increase the storage requirement for our parser cache, and require additional CSS to render.

参见：


 * 如何恢复旧目录

How do magic words work with this feature?
The  and   magic words do not work as the table of contents is always in the sidebar and this cannot be changed.

However, magic words relating to the presence of the table of contents, such as, do work. So do templates which then create an alternate ToC. For example, an article can disable the default ToC and apply its own if necessary.

All magic words continue to work for other skins which render the ToC within the article.

<span id="My_project&#039;s_logo_is_incorrect._How_do_I_fix_this?">

我们项目的Logo出现了问题，如何修复？
We've done our best to ensure that your project logo is consistent between the Vector legacy and Vector 2022 skin. However, there is a chance we've overlooked something or had to make a hasty decision without consulting your community.

Notably in the case of various Wiktionary, Wikiversity, Wikibooks projects, we show the project default logo. This is because we couldn't derive a logo for Vector 2022 from the existing Vector legacy logo. Customizations that localize the logo to your languages are however available on request. More context on this can be found at T341243.

Any project can update its logo or request a change to its logo. It needs to follow the Site request lifecycle. Please do not comment on any existing task relating to logos.

<span id="What_is_the_scope_of_the_project?">

本项目的范围是什么？
<span id="Are_you_changing_Monobook_or_Timeless?">

你们修改了Monobook或Timeless皮肤吗？
没有.

这些修改仅应用于Vector. Vector是维基媒体项目2010年开始使用的默认界面. 其它的皮肤，如Monobook、Timeless、Minerva、Modern完全不会变动.

不过，在进行桌面版改进时，我们确实清理了旧皮肤的代码. 我们让对旧皮肤进行新更改变得更加容易，并移除了这些皮肤从未使用过的选项及75%的PHP代码. 不过这些对用户所使用的界面没有影响.

参见：


 * 我们如何以及为何将我们的皮肤移至Mustache

<span id="Are_you_improving_charts,_maps,_a-/f-/o-/tmboxes,_infoboxes,_navboxes,_and_other_templates?"> 你们将改进图表、地图、信息框元模板、信息框、导航框和其他模板吗？

不会.

We do not change anything within the light gray article content area (except for the table of contents):

<span id="Are_you_building_the_dark_mode?">

你们会开发暗黑模式吗？
这不是此次桌面版改进的一部分. 不过，2023年，我们启动了一个项目. 构建暗黑模式是此项目的一部分.

<span id="What_are_the_features&#039;_success_metrics?">

这个功能的成功指标是什么？
提高现有-{zh-hant:讀者;zh-hans:受众}-的效用，具体表现为：


 * 互动性
 * 通过项目，增加5%的搜索率/每次会话
 * 通过项目，增加5%的语言切换率


 * 亲和力
 * 增加对网站的正面和喜爱情绪（通过用户调查和测试）
 * 增加信任感和可信度（通过调查和用户测试度量）

当我们更具体地定义要进行的更改时，我们将在此列表上进行扩展和更新.

参考文献