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





Làm thế nào để tắt hoặc bật Vector 2022?


Làm thế nào để tắt nó chỉ cho tôi tại một hoặc tất cả các wiki Wikimedia?
Đầu tiên, hãy kiểm tra xem bạn có đang đăng nhập không. Những người dùng không đăng nhập thì không thể thay đổi giao diện.

Xem thêm:
 * Tại sao lại đặt tên là Vector 2022 và Vector cũ?



Tại sao liên kết tắt Vector 2022 lại không có sẵn cho các thành viên không đăng nhập?
Đó là vì khả năng của server có giới hạn. Các thành viên không đăng nhập có thể sử dụng tiện ích mở rộng của trình duyệt để cá nhân hóa giao diện, hoặc họ có thể tạo tài khoản.

Xem thêm:


 * Tại sao không có tùy chọn nào cho người dùng ẩn danh?



Vector 2022 có thể trở thành mặc định cho tất cả các wiki Wikimedia nhà của tôi như thế nào?
Hãy liên hệ với chúng tôi. Chúng tôi sẽ giới thiệu dự án cho cộng đồng của bạn và bắt đầu việc thảo luận.



Làm cách nào để sử dụng nó ở wiki của riêng tôi?
Nếu bạn muốn thấy các thay đổi của chúng tôi,


 * 1) Trước hết hãy tải về
 * 2) Và thêm dòng sau vào  của bạn:

Chúng tôi rất vui khi biết được rằng bạn trân trọng những cải thiện của chúng tôi!



Làm thế nào để tùy chỉnh Vector 2022?


Tại sao không cung cấp các tùy chọn để lựa chọn giữa những phiên bản khác nhau của các tính năng?
Như vậy sẽ là quá phức tạp để có thể duy trì và phát triển.

Mỗi tùy chọn thì giống như một ngã tư đường nơi người dùng có thể lựa chọn giữa nhiều lựa chọn. Nhiều lựa chọn tức là sẽ có nhiều tổ hợp kết hợp. Việc có tùy chọn sẽ khiến chúng tôi phải chịu trách nhiệm với tất cả các tổ hợp. Chúng tôi sẽ phải duy trì chúng, và, trong trường hợp phát triển tính năng mới, thì sẽ phải kiểm tra xem tính năng này có tích hợp với mỗi tổ hợp hay không. Chúng tôi không thể làm vậy.

Thay vào đó, các cộng đồng có thể tạo ra các tiện ích, tập lệnh người dùng và các cài đặt cá nhân. Như mọi khi, chúng tôi cung cấp không gian cho sự sáng tạo vô hạn, và giúp các người dùng kĩ thuật có thể duy trì code của họ.

Xem thêm: 
 * Hãy cứ biến nó thành một tùy chọn người dùng

Tại sao không có tùy chọn nào cho người dùng ẩn danh?
Tùy chọn ẩn danh sẽ khiến trang load quá chậm.

Hầu hết lượng truy cập đến từ người dùng không đăng nhập. Để giải quyết việc đó, chúng tôi có một vài "server cache" chỉ lưu và gửi "ảnh chụp" của các trang web. Những "ảnh chụp" này sẽ được lưu tối đa 7 ngày, và là một sự thay thế cho việc tạo ra các trang web, và là giống nhau đối với mọi thành viên không đăng nhập. Việc này cho phép chúng tôi tải trang một cách nhanh chóng.

Các tùy chọn yêu cầu phải tạo ra những phiên bản khác nhau của các trang web. Nếu cho phép điều đó đối với các thành viên không đăng nhập thì server của chúng tôi sẽ bị quá tải. Chúng tôi không muốn làm vậy cũng bởi vì chúng tôi muốn giảm việc phân mảnh cache.

Cách khả thi duy nhất để có thể cung cấp các tùy chọn cho người dùng không đăng nhập hiện tại là khiến các cài đặt luôn load sau trang. Việc này mất nhiều thời gian load hơn và trông hơi kì cục. Ví dụ, nếu một người dùng không đăng nhập đang bật chế độ tối, thì ngay khi load mỗi trang, họ sẽ thấy giao diện sáng trong một khoảng thời gian ngắn, sau đó giao diện mới chuyển sang tối.

Lý do duy nhất chúng tôi cung cấp tùy chọn cho người dùng đăng nhập là vì chúng tôi không cung cấp các "ảnh chụp" cho họ. Và điều này là vì lưu lượng tới từ người dùng đăng nhập không lớn.

Xem thêm:


 * Cách một trung tâm dữ liệu mới tại Singapore giúp mọi người truy cập Wikipedia khắp thế giới
 * Xây dựng DReaMeRS: chúng tôi mở một trung tâm dữ liệu ở Pháp như thế nào và tại sao
 * Tại sao hiệu suất lại quan trọng



Bạn làm gì cho những biên tập viên cần các công cụ và tính năng cụ thể?

 * Chúng tôi đã liên hệ với các tình nguyện viên có trình độ kĩ thuật để đảm bảo khả năng tích hợp ngược lại. Chúng tôi yêu cầu họ kiểm tra mã họ đã viết và đề nghị trợ giúp nếu cần thay đổi mã.
 * Bạn có thể tùy chỉnh và cá nhân hóa các thay đổi của chúng tôi. Chúng tôi rất vui khi được làm việc với các tình nguyện viên có kỹ năng kỹ thuật muốn tạo các tiện ích và tập lệnh người dùng mới.
 * Chúng tôi không thay thế công việc của các tình nguyện viên bằng các kỹ năng kỹ thuật. Về nguyên tắc, chúng tôi không chỉnh sửa các bản mẫu hoặc tạo tiện ích mới, nhưng có thể tư vấn khi cần thiết.



Bạn có sửa các tiện ích không tích hợp với những thay đổi của bạn không?
Còn tùy.

Chúng tôi giúp các tình nguyện viên sửa các tiện ích và tập lệnh người dùng. Đôi khi chúng tôi cũng tự sửa chúng. Nhưng nói chung, chúng tôi làm việc trên chính MediaWiki. Các tiện ích và tập lệnh người dùng được viết và duy trì bởi các tình nguyện viên. Về bản chất, những thứ này luôn kém ổn định và khó dự đoán.

Nếu bạn không chắc chắn về cách khắc phục sự cố với tập lệnh hoặc tiện ích – hãy liên hệ với chúng tôi! Chúng tôi sẽ cố gắng hết sức để đưa ra lời khuyên về các bản sửa lỗi tiềm năng.

Xem thêm:


 * Tech trên Meta-Wiki – bạn cũng có thể yêu cầu hỗ trợ kỹ thuật tại đây
 * User:Jdlrobson/Extension:Gadget/Policy – chính sách được đề xuất về vai trò và trách nhiệm liên quan đến tiện ích và tập lệnh người dùng



Những CSS class nào nên được sử dụng để tùy chỉnh Vector 2022?

 * cho cả hai giao diện
 * cho Vector cũ
 * cho Vector mới



Làm cách nào để khôi phục toàn bộ chiều rộng?
Xem thêm:


 * Cải tiến Vector 2022: các tiện ích và tập lệnh người dùng mới



Làm cách nào để tắt các phần dính?
Thêm mã CSS sau vào your global.css:


 * Thanh đầu trang – thêm
 * Mục lục – thêm



Làm cách nào để khôi phục lại mục lục cũ?
Sử dụng mã JavaScript sau: 

Làm cách nào để nút có liên kết ngôn ngữ xuất hiện ở đầu trang chính?

 * 1) Yêu cầu cộng đồng của bạn đồng ý thiết lập tiêu đề trang chính. (Xem lời giải thích tại sao đây là một ý tưởng hay của chúng tôi.)
 * 2) Tiêu đề sẽ được hiển thị trong Vector 2010, Minerva, Timeless và Vector 2022. Nó sẽ không hiển thị trong Monobook.
 * 3) Tiêu đề có thể được định cấu hình bằng cách chỉnh sửa thành MediaWiki:Mainpage-title-loggedin đối với người dùng đã đăng nhập và MediaWiki:Mainpage-title đối với người dùng đã đăng xuất. Đối với người dùng đăng nhập trên thiết bị di động, hãy sử dụng MediaWiki:wikimedia-mobile-mainpage-title-loggedin. Xem chi tiết về cài đặt tiêu đề trang chính.
 * 4) Kiểm tra trang chính trông như thế nào và có phù hợp với nút ở trên cùng không bằng cách thêm tham số   vào URL. Xem [ví dụ https://is.wikipedia.org/wiki/Fors%C3%AD%C3%B0a?vectorlanguageinmainpageheader=1 trên Wikipedia tiếng Iceland]. Lưu ý rằng Wikipedia tiếng Iceland chưa thiết lập tiêu đề nên chỉ có nút xuất hiện.
 * 5) Hãy liên hệ với chúng tôi và yêu cầu chúng tôi di chuyển nút lên trên cùng.
 * 6) Chúng tôi sẽ thay đổi cài đặt cho wiki của bạn.
 * 7) Khi chúng tôi thực hiện việc này, nút sẽ hiển thị ở đầu trang trong Vector 2022. Trong các giao diện khác, danh sách có liên kết ngôn ngữ sẽ được hiển thị ở vị trí tiêu chuẩn tùy theo giao diện.

<span id="How_to_restore_the_previous_user_menu?">

Làm cách nào để khôi phục menu người dùng trước đó?
Hiện tại không thể làm điều đó.

<span id="How_to_change_the_logo_to_a_temporary_one?">

Làm cách nào để thay đổi logo thành logo tạm thời?
Logo trong Vector 2022 được tạo thành từ 3 thành phần, mỗi thành phần có thể thay đổi độc lập bằng CSS.
 * Để thay đổi hình ảnh biểu tượng (tức là quả địa cầu trên Wikipedia):
 * Để thay đổi wordmark (tức là chữ "Wikipedia"):
 * Để thay đổi khẩu hiệu (tức là câu "Bách khoa toàn thư mở"):

Liên hệ
<span id="How_can_I_contact_your_team?">

Làm thế nào tôi có thể liên hệ với nhóm của bạn?
Chọn một trong các tùy chọn sau:
 * Trang thảo luận của trang chính của dự án (bạn có thể viết bằng bất kỳ ngôn ngữ nào)
 * Nhiệm vụ Phabricator với thẻ dự án Desktop Improvements
 * Liên hệ với Chuyên gia Quan hệ Cộng đồng của chúng tôi: SGrabarczuk (WMF) sgrabarczuk@wikimedia.org
 * Liên hệ với một trong những đại sứ của chúng tôi:
 * Đại sứ tiếng Pháp và Ý: Patafisik (WMF) patafisik-ctr@wikimedia.org
 * Đại sứ tiếng Tây Ban Nha: Zapipedia (WMF) izapico-ctr@wikimedia.org
 * Đại sứ tiếng Việt: Bluetpp (WMF) ppham-ctr@wikimedia.org
 * Đại sứ tiếng Ba Tư: Mehran (WMF) mehran@wikimedia.org

<span id="How_can_I_follow_your_activities?">

Làm thế nào tôi có thể theo dõi các hoạt động của nhóm?

 * Hãy đăng ký nhận bản tin. Thay vì tin nhắn ở trang thảo luận, bạn sẽ nhận được thông báo về các bản cập nhật.
 * Xem các trang Cập nhật và Nói chuyện với nhóm Web của chúng tôi.

<span id="Do_you_host_or_attend_online_meetings?">

Nhóm có tổ chức hoặc tham dự các cuộc họp trực tuyến không?
Có chứ!

Chúng tôi tổ chức các cuộc họp trực tuyến mở cho cộng đồng (giờ hành chính). Tại các cuộc họp này, Olga (quản lý sản phẩm của chúng tôi) sẽ thuyết trình về những phát triển gần đây. Tiếp theo, các thành viên cộng đồng có thể đặt bất kỳ câu hỏi nào về dự án.

Chúng tôi cũng sẵn sàng nhận lời mời tham gia bất kỳ sự kiện cộng đồng trực tuyến nào. Đây có thể là các cuộc họp địa phương, toàn quốc hoặc quốc tế.



<span id="What_are_Vector_2022_and_the_Desktop_Improvements?">

Vector 2022 và các Cải thiện dành cho phiên bản máy tính để bàn là gì?
<span id="Is_this_a_redesign?">

Đây có phải là một bản thiết kế lại không?
Không.

Một bản thiết kế lại sẽ là một thay đổi chính duy nhất ảnh hưởng tới cách hoạt động của trang. In the case of this project we have made a series of individual changes. Each feature was a separate small project. At the end, these features were joined together by a cohesive visual design.

What is the timeline of this project?
We have been working on Vector 2022 (originally known as modern Vector) since 2019. Between early 2020 and mid-2022, we were building and releasing different features on "early adopter" wikis. (You can read more about that in the answer to the question below, points 2–4.)

We have finished that part. Vector 2022 isn't "beta" anymore. Currently, we inform about our intention to introduce Vector 2022 on more wikis. By the end of March 2023, we hope that Vector 2022 would be the default skin across almost all Wikimedia wikis.

Why do you use the word Improvements?
Because we have data indicating that the changes are for the better: See also:
 * 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

On which wikis have you tested these changes?
The pilot wikis where we have been testing Vector 2022 have been:

Ngoài ra:
 * Wiki Office
 * 
 * Wiki MediaWiki
 * Wiki Quản trị của Quỹ Wikimedia
 * Wiki Collab
 * Wiki Strategy

Why do you use this naming: Vector 2022 and legacy Vector?
The new skin is a continuation of many of the ideas in the original Vector skin. It is being built using the code the Vector skin uses. We wanted to maintain functional and visual continuity. 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.

See also:
 * What CSS classes should be used?

Will you remove legacy Vector?
No.

Legacy Vector will continue to be available as an option in Preferences, similar to other skins that have been default in the past, such as Monobook.



Are these changes made for readers, and not for editors?
Not exactly.

Our team (Web) works on the reading (viewing) experience on desktop and mobile browsers. Those who both view and edit, and those who view but do not edit, are one large group of the interface users. We work for all of them, bearing in mind that new and advanced editors have specific needs.

The goal of this project is to improve the reading experience on desktop without making editing more difficult.

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.

See also:
 * 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

What tools are the Foundation building for editors?
At the Foundation, there are other teams working on projects dedicated specifically to editors. Among them, there are:
 * 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
 * Anti-Harassment Tools – working on tools for administrators, anti-vandalism patrollers

Do your changes have a negative effect on the editing statistics?
No.

We collect statistics of the editing activity on all wikis. Compared to wikis with Vector legacy (2010) as the default, on wikis with Vector 2022 as the default, there are no negative differences.

Do your changes make it more difficult to explore the community side of the wikis?
No.

Readers and new editors are intimidated by large numbers of links, options, and ways of exploring the editing (in other words, the community) side of the Wikimedia projects. This is a finding of our research.

We want more users to join the communities. We do this by limiting the number of the unhidden links, and bringing additional focus on the most relevant ones. All this is done in collaboration with the Growth and Editing teams.

See also:
 * Core Experiences
 * UX Myth #12: More choices and features result in higher satisfaction

Are you focused on Wikipedia articles?
Yes.

Wikipedia articles, as a whole, have the most part of the viewership and readership compared to other namespaces on Wikipedia or any other projects. We also make adjustments to pages from other namespaces and special pages. Pages which we have made special adjustments and configurations for include: main pages, pages specific to some sister projects, special pages, the 2010 wikitext editor, the 2017 wikitext editor, and the Visual Editor.

We have also been working with the Editing team to ensure that the work they are doing for talk pages aligns with our work, and that special configurations for talk pages are put in place.

Have you been mindful of sister projects?
Yes!

We aim to change the basic elements of the interface. Most features work on the sister projects just as well as they improve Wikipedia. We have made sure to test and build for different sister projects from the beginning of the project. We still make adjustments to the default features where necessary.

Non-Wikipedia projects, such as French Wiktionary, were also a part of our partner communities since 2020. We ensured we have had direct communication and feedback from them.

Regarding the adjustments, for example, on Wikisource, the limited width does not apply to the Page namespace provided by the Proofread Page extension.

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.

What do you do to ensure that the change would work on my wiki?

 * Research we make is relevant to all wikis and includes voices from many different languages and projects.
 * We gather and incorporate feedback from the communities. Most issues are relevant to all wikis.
 * How we adjust our changes to sister projects – go to "Do you remember about sister projects?"
 * What is our approach to gadgets – go "What do you do for editors who need specific tools and features?"

What do you do to ensure that the change is not half-finished?
We make tweaks both before and after we introduce the changes on wikis to make sure they are up to the needs for individual communities. If you think your community would benefit from more adjustments and gadgets, see:


 * What do you do for editors who need specific tools and features?
 * How to customize Vector 2022?

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

Have your changes been tested on users with disabilities?
Yes. We are working with the American Foundation for the Blind. We are asking various questions related to the accessibility of Vector 2022. See more on Phabricator.

Will the wikis be less accessible for users with slow Internet connection?
No.

We want to keep the new skin similarly code-heavy to legacy Vector.

See also:


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

Are the changes inspired by mobile design?
No.

These changes are created specifically for desktop interfaces. All research and testing done for this project has been focused on desktop users only. We have, however, considered the experiences of people who use desktop in narrower screens (for example, if you have two tabs open side by side).

At this time, we do not have plans to merge the desktop and mobile experiences.

Will the new interface be responsive?
We've been working towards that goal, but it's not an official goal of the project.

If you want to make the interface responsive now and you're using Wikimedia wikis, add

to your global.js.

If your community would like this to be the default, please start a conversation on your wiki, and contact us when consensus is reached. We can then make the change.

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!

See also:


 * What do you do for editors who need specific tools and features?



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 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.

See also:


 * 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?
We want it to be default. We are building a common experience that is shared between editors and readers. This could be helpful to editors when making decisions about page layouts*. Currently an editor might be editing a page at a width of 1500px, while a reader reads it at a width of 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.

Why couldn't the list of language links stay in the sidebar?
Because from the readers' perspective, the sidebar is not a place for useful links. Most readers focus on the content area. Links in the sidebar are practically hidden from their sight.

Also, we need to promote the variety of language versions of Wikimedia projects.

For more than 15 years, the list has been displayed in the sidebar. The most active users have developed muscle memory to look for that list in that place. This is why in the sidebar, we have placed a box with information about the language button being displayed in a new place.

Will the Wikidata links be closer to the list of language links?
Yes.

"", "", and "" will eventually be part of the menu activated by the language switching button ("language menu"). This is a task for the Language engineering team.

How to fix the coordinates displaying incorrectly near the languages button?
Consider pages which use page status indicators, pages which have banners or site notices, and the look of the pages at lower resolutions.

Why the button with language links doesn't 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.

See also:
 * 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.

Why doesn't it appear when I complete an edit?
The feature is still in development (T307251). This will be fixed before we make Vector 2022 the default on more wikis.

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

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?
This isn't possible.

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 good 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.

See also:


 * How to restore the old table of contents?

How do magic words work with this feature?
The  and   magic words will 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, will continue to work. So will 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 will continue to work for other skins which render the ToC within the article.

I can't see the table of contents when the sidebar is open
This is a known problem.

This issue should only impact logged in users who have opened the sidebar. In the long term, we plan to reduce the size of this menu, and make the sidebar overlay content. Details and a prototype of how that will look can be found in T302073. This change is planned in the latter part of the year (October-December 2022). Further information can be found on the page about Page tools.

<span id="What_is_the_scope_of_the_project?"> Phạm vi của dự án này là gì?

<span id="Are_you_changing_Monobook_or_Timeless?"> Monobook hay Timeless có bị ảnh hưởng không?

No.

These changes are applied to Vector only. Vector has been the default interface on Wikimedia wikis since 2010. Any other skins such as Monobook, Timeless, Minerva or Modern are not be changed at all.

While working on Desktop Improvements, we did clean up the old skins' code, though. We made it easier to roll out new changes to old skins, removed never used options, and removed 75% of the PHP code of these skins. All this had no effect on the side users interact with.

See also:


 * How and why we moved our skins to Mustache

<span id="Are_you_improving_charts,_maps,_a-/f-/o-/tmboxes,_infoboxes,_navboxes,_and_other_templates?"> Các bạn có cải thiện biểu đồ, bản đồ, hộp thông báo, hộp thông tin, hộp điều hướng, các bản mẫu khác?

No.

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

Are you building the dark mode?
No, not this time.

The Desktop Improvements project provides the architectural changes needed to build dark mode. Building it would be a separate project, though. This is because that project would require significant work with the communities. Now, many templates are not compatible with dark mode. We have learned that while working on the mobile apps.

Initially, our dark mode would be based on the user's operating system preferences. We would not plan to add an in-browser toggle. The reason is we currently do not have a system in place for anonymous user preferences. This could be added at a later date, though.

<span id="What_are_the_features&#039;_success_metrics?"> Các số liệu thành công của tính năng là gì?

Tăng tính hữu dụng với những người dùng có sẵn, được đại diện bởi:


 * Độ tương tác
 * Tăng 5% lượng tìm kiếm mỗi phiên trên toàn dự án
 * Tăng 5% lượng thay đổi ngôn ngữ mỗi dự án trên toàn dự án


 * Sự thu hút
 * Gia tăng cảm giác tích cực và được hoan nghênh với trang (thông qua khảo sát và thử nghiệm người dùng)
 * Gia tăng cảm giác tin tưởng và tín nhiệm (được tính toán thông qua khảo sát và thử nghiệm người dùng)

Chúng tôi sẽ mở rộng danh sách này khi quyết định các thay đổi mà chúng tôi muốn thực hiện một cách cụ thể hơn.

Tham khảo