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





Як вимкнути чи увімкнути Вектор 2022?


Як мені це вимкнути лише для себе на одній чи усіх вікі Вікімедіа?
Перш за все, переконайтеся, що ви увійшли в систему. Незалогінені користувачі не можуть змінювати оформлення.

Див. також:
 * Чому ви використовуєте ці назви: Вектор 2022 і старий вектор?



Чому у незареєстрованих користувачів немає можливості вимкнути цю тему?
Це через обмежену можливість наших серверів. Користувачі, які не увійшли в систему, можуть використовувати браузерні розширення для персоналізації свого інтерфейсу, або ж вони можуть створити обліковий запис.

Див. також:


 * Чому в анонімних користувачів немає налаштувань?



Як Вектор 2022 може стати темою за замовчуванням для всіх у моїй домашній Вікі Вікімедіа?
Зв'яжіться з нами. Ми презентуємо проєкт вашій спільноті і розпочнемо обговорення.



Як я можу увімкнути це у власній/особистій вікі?
Якщо ви бажаєте побачити наші зміни,


 * 1) Переконайтеся, що завантажили
 * 2) Додайте такі рядки у свій :

Ми раді дізнатися, що вам подобаються наші покращення!



Як налаштувати Вектор 2022?


Чому ви не даєте змоги вибирати між різними версіями функцій?
Це було б надто складно підтримувати і розвивати.

Кожне налаштування — це як перехрестя, на якому користувачі можуть вибирати між опціями. Багато варіантів вибору означає багато комбінацій. Налаштування зробили б нас відповідальними за всі такі комбінації. Нам би треба було підтримувати їх, а ще, в разі розробки нових функцій, перевіряти, чи вони сумісні з кожною з комбінацій налаштувань. Ми таке не потягнемо.

Натомість ми даємо спільнотам можливість створювати додатки, користувацькі скрипти та індивідуальні налаштування. Як завжди, ми надаємо простір для локальної творчості і допомогаємо технічнопідкованим користувачам підтримувати їхній код.

Див. також: 
 * Просто зробіть це налаштуванням користувача

Чому в анонімних користувачів немає налаштувань?
Анонімні налаштування змушували б сторінки завантажуватися дуже довго.

Більшість трафіку надходить від незалогінених користувачів. Щоб справлятися з цим, у нас є кілька «серверів кешування», які лише зберігають і надсилають «знімки» вебсторінок. Такі «знімки» можуть бути віком до 7 днів і є заміною генеруванню вебсторінок, і вони однакові для усіх незалогінених користувачів. Це дозволяє нам видавати сторінки швидко.

Налаштування вимагають генерування різних версій вебсторінок. Якщо зробити це доступним для незалогінених користувачів, це перевантажить наші сервери. Також, ми не хочемо це робити, бо нам треба зменшити фрагментацію кешу.

Єдиний можливий спосіб надавати налаштування для незалогінених користувачів — це завантажувати налаштування завжди після сторінки. Це робить час завантаження значно довшим і виглядає дивно. Наприклад, якщо незалогінений користувач хоче побачити темну тему, тоді одразу після завантаження кожної сторінки вони б спочатку на коротку мить бачили світлий інтерфейс, а вже тоді інтерфейс би став темним.

Для контексту: єдина причина, чому в нас є налаштування для користувачів, що увійшли в систему, полягає в тому, що ми не видаємо їм «знімки». А це тому, що трафік, що надходить від залогінених користувачів, невеликий.

Див. також:


 * Як новий дата-центр у Сінгапурі допомагає людям у всьому світі отримувати доступ до Вікіпедії
 * Створення DReaMeRS: Як і чому ми відкрили дата-центр у Франції
 * Чому продуктивність важлива



Що ви робите для редакторів, яким потрібні спеціальні інструменти та функції?

 * Ми зв'язуємося з волонтерами, що мають технічні навички, щоб забезпечити зворотну сумісність. Ми просимо їх перевірити написаний код і пропонуємо допомогу, якщо код потребує змін.
 * Ми робимо можливими конфігурацію та персоналізацію наших змін. Ми раді працювати з технічнопідкованими волонтерами, які хотіли б створювати нові додатки та користувацькі скрипти.
 * Ми не заміняємо роботу технічнопідкованих волонтерів. В принципі, ми не робимо зміни до шаблонів чи створюємо нові додатки, але, за потреби, ми можемо дати пораду.



Чи ремонтуєте ви додатки, які не працюють із вашими змінами?
Залежить.

Ми допомагаємо волонтерам лагодити додатки та користувацькі скрипти. Інколи ми ремонтуємо їх самі. Але загалом ми працюємо над самою MediaWiki. Додатки та користувацькі скрипти пишуть і підтримують волонтери. За своєю природою, вони завжди менш стабільні й передбачувані.

Якщо ви не впевнені, як виправити проблему зі скриптом чи додатком, зв'яжіться з нами! Ми докладемо зусиль, щоб порадити вам потенційні виправлення.

Див. також:


 * Tech на Мета-вікі — тут теж можна просити про технічну допомогу
 * User:Jdlrobson/Extension:Gadget/Policy — пропонована політика щодо ролей та обов'язків, пов'язаних із додатками та користувацькими скриптами



Які класи CSS треба використовувати, щоб видозмінити Вектор 2022?

 * для обох тем
 * для старого вектора
 * для Вектора 2022



Як відновити повну ширину?
Див. також:


 * міни у Векторі 2022: нові додатки та користувацькі скрипти



Як вимкнути фіксовані елементи?
На своїй сторінці global.css додайте такий CSS-код:


 * Шапка — додайте
 * Зміст — додайте



Як відновити старий зміст сторінки?
Скористайтеся таким кодом JavaScript: 

Як зробити так, щоб кнопка з мовними посиланнями показувалася угорі головної сторінки?

 * 1) Запитайте у своєї спільноти про згоду налаштувати шапку головної сторінки. (Див. наше пояснення, чому це гарна ідея.)
 * 2) Шапка буде показуватися в оформленнях Вектор 2010, Мінерва, Позачасове і Вектор 2022. Її не буде видно у Монокнизі.
 * 3) Шапку можна налаштувати редагуваннями MediaWiki:Mainpage-title-loggedin для залогінених користувачів і MediaWiki:Mainpage-title для незалогінених користувачів. Для залогінених користувачів мобільного вигляду використовується MediaWiki:wikimedia-mobile-mainpage-title-loggedin. Див. детальніше про налаштування шапки головної сторінки.
 * 4) Протестуйте, як виглядає головна сторінка як вона працює з кнопкою угорі, додавши параметр   до URL. Див. приклад у Вікіпедії ісландською мовою. Зверніть увагу, що в ісландській Вікіпедії ще немає шапки, тому з'являється лише кнопка.
 * 5) Зв'яжіться з нами, якщо кнопку треба перемістити вгору.
 * 6) Ми змінимо налаштування для вашої вікі.
 * 7) Коли ми це зробимо, кнопка буде розташована угорі сторінки у Векторі 2022. В інших оформленнях список мов буде показуватися у стандартному місці для окремо взятого оформлення.

<span id="How_to_restore_the_previous_user_menu?">

Як відновити попереднє меню користувача?
Наразі цього не можна зробити.

<span id="How_to_change_the_logo_to_a_temporary_one?">

Як змінити логотип на тимчасовий?
Лого у Векторі 2022 складається з трьох елементів, кожен з яких можна змінити окрема з допомогою CSS.
 * Щоб змінити зображення іконки (наприклад, кулю Вікіпедії):
 * Щоб змінити текстове лого (наприклад, слово «Вікіпедія»):
 * Щоб змінити підпис (наприклад, слова «Вільна енциклопедія»):

Контакти
<span id="How_can_I_contact_your_team?">

Як мені зв'язатися з вашою командою?
Оберіть один з поданих варіантів:
 * Сторінка обговорення головної сторінки проєкту (ви можете писати будь-якою мовою)
 * Завдання на Фабрикаторі з тегом проєкту Desktop Improvements
 * Зв'яжіться з нашим спеціалістом зі зв'язків зі спільнотою: SGrabarczuk (WMF) sgrabarczuk@wikimedia.org
 * Зв'яжіться з одним із наших амбасадорів:
 * французький та італійський амбасадор: Patafisik (WMF) patafisik-ctr@wikimedia.org
 * іспанський амбасадор: Zapipedia (WMF) izapico-ctr@wikimedia.org
 * в'єтнамський амбасадор: Bluetpp (WMF) ppham-ctr@wikimedia.org
 * амбасадор фарсі: Mehran (WMF) mehran@wikimedia.org

<span id="How_can_I_follow_your_activities?">

Як можна стежити за вашою діяльністю?

 * Підпишіться на нашу розсилку. Замість повідомлень на своїй сторінці обговорення ви отримуватимете сповіщення про оновлення.
 * Додайте наші сторінки Оновлення та Talk to Web до свого списку спостереження.

<span id="Do_you_host_or_attend_online_meetings?">

Чи проводите ви або ходите на онлайн-зустрічі?
Так!

Ми організовуємо відкриті онлайн-зустрічі для спільнот (т. зв. office hours). На цих зустрічах Ольга (наша менеджерка продукту) робить презентації про нещодавні розробки. Далі члени спільноти можуть ставити будь-які запитання щодо проєкту.

Ми також відкриті до запрошень на будь-яку онлайн-подію спільноти. Це можуть бути локальні, національні чи міжнародні зустрічі.



<span id="What_are_Vector_2022_and_the_Desktop_Improvements?">

Що таки Вектор 2022 та Стаціонарні покращення?
<span id="Is_this_a_redesign?">

Це редизайн?
Ні.

Редизайн був би єдиною значною зміною, яка впливає на те, як працює сайт. У випадку цього проєкту ми зробили серію окремих змін. Кожна функція була окремим маленьким проєктом. У решті-решт ці функції були сполучені об'єднавчим візуальним дизайном.

<span id="What_is_the_timeline_of_this_project?">

Яка хронологія цього проєкту?
Ми працювали на Вектором 2022 (початкова назва «сучасний вектор») з 2019 року. Від початку 2020 до середини 2022 ми розробляли і розгортали різні функції на пілотних вікі. (Ви можете почитати про це у відповіді на запитання нижче, пункти 2—4).

Ми закінчили цю частину. Вектор 2022 більше не «бета». Наразі ми повідомляємо про свої наміри впровадити Вектор 2022 у більшій кількості вікі. Ми сподіваємося, що до кінця березня 2023 Вектор 2022 буде темою за замовчуванням у майже всіх вікі Вікімедіа.

<span id="Why_do_you_use_the_word_Improvements?">

Чому ви використовуєте слово «покращення»?
Тому що ми маємо дані, які показують, що ці зміни на краще: Див. також:
 * 1) Через дослідження разом з читачами й редакторами ми визначили проблеми. Під час цієї фази, у 2019 році, ми вивчали те, як люди користуються сайтами, і визначили найбільші проблеми зручності. Ми також виявили те, що заважає досліджувати сайт далі, глибше занурюючись у читання чи редагування. Ми зробили це через інтерв'ю з читачами й редакторами у різних країнах і місцевостях, різними мовами. Див.: Дослідження й дизайн: Фаза 1, Дослідження й дизайн: Фаза 2.
 * 2) Ми розробили і протестували прототипи. Ми розробили скелет кожної функції і почали показувати їх користувачам. Кожна функція була протестована читачами й редакторами, ми робили інтерв'ю та ширші раунди тестування прототипів. Для тестування редакторами ми використовували банери центрального сповіщення. Ми показували їх різними мовами й у різних проєктах Вікімедіа, щоб могти отримати широку та різноманітну аудиторію. Кожен прототип протестували, в середньому, близько 200 редакторів. (Приклад)
 * 3) Ми розробили й відполірували наші функції. Ми врахували відгуки з тестування прототипів і покращили чи змінили прототипи відповідно до них. У деяких випадках ми просили про додаткові відгуки, щоб упевнитися, що робимо правильний вибір.
 * 4) Ми зв'язувалися з різними вікі, запрошуючи їх приєднатися до групи пілотних вікі (early adopters). Це була «бета»-фаза. У цих вікі ми проводили кількісні тести, щоб оцінити, чи кожна з функцій працює так, очікували.
 * 5) Ми проводили A/B-тестування серед залогінених користувачів. На жаль, нам не вдалося провести його з користувачами, що не увійшли в систему. Ось чому ми робимо порівняння до та після.
 * 6) Отримавши результати тестування, ми порівнювали їх з критеріями успіху, які визначили для себе раніше. Коли результати нашого тесту були негативні, ми змінювали функцію і продовжували тестувати далі.
 * 7) З часу цієї фази ми також моніторили використання у всіх вікі, де багато власників облікових записів уже використовували Вектор 2022.
 * Енциклопедична стаття: Iterative and incremental development
 * Допис у блозі: Ітеративний дизайн Векторного інтерфейсу: про переміщення міжмовних посилань

<span id="On_which_wikis_have_you_tested_these_changes?">

У яких вікі ви тестували ці зміни?
Пілотними вікі, де ми тестували Вектор 2022, були:

а також: <span id="Why_do_you_use_this_naming:_Vector_2022_and_legacy_Vector?">
 * офісна вікі
 * 
 * MediaWiki вікі
 * Вікі врядування Фонду Вікімедіа
 * Collab-вікі
 * Стратегічна вікі

Чому ви використовуєте ці назви: Вектор 2022 і старий вектор?
Нове оформлення є продовженням багатьох ідей оригінального Векторного оформлення. Воно будується з використанням коду, який використовує тема Вектор. Ми хотіли зберегти функціональну та візуальну послідовність. Усе, що створювалося для старого Вектора, повинно працювати з нашими змінами, або має відносно легко налаштовуватися для цього.

Версію, яку створили у 2010 і розробляли до 2019, було заморожено. Іншими словами, ми її зберігаємо й будемо підтримувати, але не будемо створювати для неї нових функцій.

Ми використовуємо назву «Вектор 2022» із суто технічних причин. Ця назва позначає, коли новий Вектор був готовий як нове оформлення для сторонніх вікі. (Під іншими сторонами маються на увазі ті, хто встановлює MediaWiki).

У кожній вікі назву оформлення можна вказати окремо, змінивши MediaWiki:Skinname-vector-2022. Однак це може спричинити плутанину, бо це не змінює пов'язаний ключ теми, який використовується для стилів сайту і користувачів.

Див. також: <span id="Will_you_remove_legacy_Vector?">
 * Які CSS-класи треба використовувати?

Чи ви приберете старий Вектор?
Ні.

Старий Вектор залишиться доступним як функція у налаштуваннях, подібно до інших оформлень, які були за замовчуванням у минулому, як-то Monobook.



<span id="Target_audience">

Цільова аудиторія
<span id="Are_these_changes_made_for_readers,_and_not_for_editors?">

Ці зміни робляться для читачів, не для редакторів?
Не зовсім.

Наша команда (Web) працює над досвідом читання (перегляду) стаціонарної та мобільної браузерної версій. Ті, хто і переглядають, і редагують, і ті, хто лише переглядають, але не редагують, є однією великою групою користувачів інтерфейсу. Ми працюємо для них усіх, пам'ятаючи про те, що нові та досвідчені редактори мають відмінні потреби.

Мета цього проєкту — покращити досвід читання стаціонарної версії, не ускладнюючи при цьому редагування.

Крім цього, наші рекомендації стратегії руху наполягають, щоб ми покращили користувацький досвід в інклюзивний спосіб. Пам'ятаючи про це, проєкт має конкретну мету впевнитися, що вільні знання у майбутньому зростатимуть справедливо. При розробці ми докладали зусиль зібрати голоси читачів з різних демографічних та географічних груп. Також ми прагнули зосереджуватися на їхніх думках, коли вирішували, над чим будемо працювати, й оцінювали, чи певна ідея здатна задовольнити їхні потреби.

Див. також: <span id="What_tools_are_the_Foundation_building_for_editors?">
 * Що ви робите, що переконатися, що зміна не закинута на півдорозі?
 * Що ви робите для редакторів, яким потрібні спеціальні інструменти та функції?
 * Попередні проєкти Команди Web

Які інструменти Фонд розробляє для редакторів?
У Фонді є інші команди, які працюють над проєктами, що присвячені конкретно редакторам. До них належать: <span id="Do_your_changes_have_a_negative_effect_on_the_editing_statistics?">
 * Community Tech — працює над проєктами, обраними спільнотами під час Опитування побажань спільноти
 * Editing — працює над інструментами обговорення
 * Growth — працює над проєктом Досвіду новачків
 * Moderator Tools — зосереджуються на потребах модерування у середньовеликих проєктах Вікімедіа
 * Anti-Harassment Tools — працює над інструментами для адміністраторів та патрульних, що відкочують вандалізм

Чи мають ваші зміни негативний вплив на статистику редагувань?
Ні.

Ми збираємо статистику щодо редагувань у всіх вікі. У порівнянні вікі, де за замовчуванням старий Вектор (2010), і вікі, де за замовчуванням Вектор 2022, немає негативних відмінностей.

<span id="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.

[{note|1= Note: 1024px is mentioned as a minimum size to consider in the English Wikipedia Manual of Style, though that’s not quite the same thing. }}

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?"> Який масштаб цього проєкту?

<span id="Are_you_changing_Monobook_or_Timeless?"> Чи теми Monobook або Timeless будуть зачеплені?

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?"> Чи будете ви покращувати графіки, мапи, шаблони повідомлень, картки, навігаційні чи інші шаблони?

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?"> За якими параметрами визначаєте успіх функції?

Підвищення корисності для наших наявних аудиторій з врахуванням такого:


 * Взаємодії
 * Зростання кількості пошуків за сеанс на 5% протягом проєкту
 * Зростання перемикання мов для кожного проєкту на 5% протягом проєкту


 * Симпатія
 * Зростання позитивних і привітних настроїв щодо сайту (за допомогою опитувань та тестування користувачів)
 * Зростання настроїв довіри (вимірюється за допомогою опитувань та тестування користувачів)

По ходу того, як ми визначаємо зміни, які хочемо зробити, більш детально, ми розширимо і поновимо цей список.

Примітки