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上构建并发佈了不同的功能. (You can read more about that in the answer to the question below, points 2–4.)

我们已经完成了该部分. Vector 2022不再是“测试”了. Currently, we inform about our intention to introduce Vector 2022 on all the wikis.

<span id="Why_do_you_use_the_word_Improvements?">

为什么使用“改进”一词？
Because we have data indicating that the changes are for the better:
 * 1) We identified problems through research with both readers and editors. During this phase, in 2019, we studied the way people used the sites and identified the largest usability issues. We also identified issues to exploring the site further, becoming more engaged with reading or editing. We did this by interviewing readers and editors across multiple countries, locations, and languages. See: Research and design: Phase 1, Research and design: Phase 2.
 * 2) We built and tested prototypes. We built out the ideas of each feature and began showing them to the users. Each feature was tested with readers and editors through interviews and wider rounds of prototype testing. For testing with editors, we used central notice banners. We displayed them across multiple language and Wikimedia projects so that we can get a wide and diverse audience. Each prototype was tested by approximately 200 editors on average. (Example)
 * 3) We refined and built our features. We took the feedback from the prototype testing and refined or changed the prototypes accordingly. In some cases, we asked for additional feedback to ensure we're making the right decisions.
 * 4) We contacted various wikis asking to join the early adopters ("pilot wikis"). This was the "beta" phase. On these wikis, we performed quantitative tests for whether each feature worked as expected.
 * 5) We performed A/B testing on logged-in users. Unfortunately, we are not able to perform these on logged-out users. This is why we make before and after comparisons.
 * 6) When we had the test results, we compared the results with the criteria of success we had previously defined. When we got negative results from our test, we changed the feature and test again.
 * 7) Since this phase, we have also monitored usage across all wikis, where many account holders have already been using Vector 2022.

参见：


 * An encyclopedic article: Iterative and incremental development
 * A blog post: The iterative design of the Vector interface: the case of moving interlingual links

<span id="On_which_wikis_have_you_tested_these_changes?">

你们已在哪些wiki测试了这些更改？
The pilot wikis where we have been testing Vector 2022 have been:

<span id="Why_do_you_use_this_naming:_Vector_2022_and_legacy_Vector?">

为什么要命名为Vector 2022和旧版Vector？
新皮肤是旧版Vector很多元素的延续. 它的代码是建立在旧版Vector的基础上的. 我们希望保持功能和视觉上的连续性. Everything built and meant for legacy Vector should be working with our changes, or can be configured to do so fairly easily.

The version built in 2010 and developed until 2019 has been frozen. In other words, we will keep and maintain it, but will not be building new features for it.

We use the name Vector 2022 for purely technical reasons. This name marks when the new Vector was available to third-party wikis as a new skin. (Third parties mean those who install MediaWiki).

On each wiki, the skin name can be overriden by changing MediaWiki:Skinname-vector-2022. However, this may cause confusion since it won't change the associated skin key that is used for site and user styles.

参见： <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) 致力于提升桌面和移动浏览器的阅读（查看）体验. 既阅读条目又编辑的，以及阅读条目但不编辑的，是用户的主要组成部分. 我们为他们所有人工作，谨记新手与老手有着特定的需求.

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

That said, our movement strategy recommendations implore us to improve our user experience in an inclusive manner. In this spirit, the project has a specific goal of ensuring the free knowledge grows equitably in the future. 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%的语言切换率


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

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

参考文献