New requirements for user signatures/uk

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

Ви можете знайти більше подробиць про те, що і для чого пропонується, нижче:


 * Яких відгуків потребує команда: Введення: ваш відгук
 * Чому пропонується ця зміна: Передісторія: чому така зміна?
 * Яка зміна пропонується: Пропозиція: вимоги валідації підпису
 * Як ці зміни могли б вплинути на вас: Наслідки: ефекти зміни

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

Введення: ваш відгук
Команда бажає отримати ваш відгук про цю пропозицію.

Будь ласка, залишіть свої коментарі до цих питань на сторінці обговорення:


 * 1) Чи зумовить валідація підписів проблеми на вашій вікі?
 * 2) На що, на вашу думку, повинна звернути увагу команда перед внесенням змін?
 * 3) Як слід вчинити з вже наявними підписами, які не відповідають новим обмеженням? Наприклад, чи потрібно їх заборонити?

Просимо не обмежувати себе вищенаведеними питаннями. Команда хотіла б почути всі думки, якими ви можете поділитися.

Передісторія: чому така зміна?
У 2019 році добровольці з 20 проектів Вікімедіа та груп користувачів, спільно з працівниками Фонду Вікімедіа, взяли участь в консультації про сторінки обговорення. Це був захід з визначення кращих засобів спілкування на вікі.

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

Для забезпечення правильної роботи цієї можливості, програмне забезпечення мусить працювати з "машино-читабельними" підписами, щоб точно знаходити коментарі користувачів і давати змогу відповідати на них.

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

Ця додаткова послідовність форматування підписів покращила б наявні можливості, наприклад сповіщення про "згадки", які надсилаються лише тоді, коли у вашому редагуванні можна виявити підпис.

Пропозиція: вимоги валідації підпису
В цьому розділі описано три запропоновані критерії. Вони застосовуватимуться до користувацьких підписів у Налаштуваннях, коли користувач зберігатиме відредагований підпис. За пропозицією Команди з редагування наявні підписи *НЕ БУДУТЬ* зачеплені.

Заборонити невалідну HTML та інші помилки Linter
Перш за все, ця зміна заборонить езакриті теги форматування, наприклад або відповідну розмітку вікі-тексту, , без парного закриваючого тегу (в цьому випадку,  або  , відповідно). Підписи, що містять невалідну розмітку, можуть датися взнаки всій сторінці обговорення, оскільки форматування пошириться на подальші коментарі.

Критерій також виявлятиме неправильне вкладання тегів, як-от  (або обидва теги , або обидва теги   мають бути назовні), і непарні теги, закриваючі теги без відповідних відкриваючих тегів (протилежність "незакритих тегів форматування", згаданих вище).

Підписи, які містять менш критичні помилки, також будуть заборонені, як-от застарілі теги HTML  і . Хоча вони безпосередньо не викликають проблем, така заборона зупинить поширення застарілого коду на нові вікі-сторінки, яке дратує редакторів, що прибирають помилки Linter.

Повний список можливостей синтаксису, які буде заборонено, разом з посиланнями на сторінки пояснень, як оновити або виправити код з помилками Linter, доступний за цією адресою.

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

Обов'язкове посилання на сторінку користувача, сторінку обговорення або внеску
Багато інструментів не працюють належним чином, якщо підпис не містить хоча б одного з настуних посилань: на сторінку користувача, сторінку обговорення користувача, або сторінку внеску користувача. Наприклад, сповіщення про "згадки" не надсилаються, а очікуване невдовзі розширення DiscussionTools не зможе відповідати на коментарі з такими некоректними підписами. Гаджети та інші інструменти, які взаємодіють з підписами, також можуть працювати неочікуваним чином.

Ця вимога давно присутня в багатьох правилах проектів Вікімедіа, але MediaWiki досі не забезпечує її обов'язкове виконання.

Заборона "вкладених" підстановок у підписах
Деякі використання розмітки subst: і тильд також будуть заборонені в підписах. До цього можна було використовувати ці можливості для створення підпису, який підставляв у ваш коментар ім'я наступного редактора. Усі форми фальсифікації підписів давно заборонені правилами великих вікі, і цьому виду фальсифікації віднині буде запобігати програмне забезпечення. Проста розмітка subst: і далі дозволятиметься.

Що буде з наявними підписами?
Всі наявні підписи, які стануть некоректними за новими правилами, залишаться дозволеними (зворотньої дії немає). При перегляді ваших налаштувань ви побачите попередження про це, і якщо ви пробуєте відредагувати ваш підпис, результат має бути коректним. Але якщо ви його не редагуватимете, старий некоректний підпис і далі використовуватиметься, і ви зможете змінювати інші налаштування, оминаючи його.

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

Коли можуть відбутися ці зміни?
Будь ласка, залиште коментар до 31 березня 2020 року. Команда з редагувань прийме рішення щодо цього проєкту на початку квітня. Результати буде опубліковано на сторінці обговорення.

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

Як ми дізнаватимемося, які зміни відбудуться?
Ми зробимо оповіщення в Tech/News, коли цю зміну скоро буде реалізовано.

Як будуть виглядати помилки валідації підпису?
Помилки HTML/lint включатимуть посилання на наявну документацію про помилки lint, як-от Help:Extension:Linter/missing-end-tag, і кнопку для підсвітки проблемної частини підпису.

Помилки обов'язкового посилання включатимуть приклад вікітексту для використання.

Результат
The proposal was largely accepted. In response to comments from volunteers, a few small changes were made and a few points were clarified.


 * 1) Disallow some invalid HTML and other Linter errors
 * The scope of these changes will be reduced. Misnested and stripped tags will be rejected.  Some low-priority errors will still be accepted.  Specifically, obsolete HTML tags like   and   will not be banned at this time.  This decision does not prejudice any future decision for or against removing these obsolete HTML tags.
 * 1) Require a link to user page, talk page or contributions
 * This will be implemented as originally planned.
 * For clarity, there must be at least one local direct link (not via a redirect, e.g. from old username) to one of those pages. Thus, a signature of  would be acceptable (one local link, one link to another wiki), but a signature that includes only links to another wiki, or only redirects from a former username, will be invalid.  This is for technical reasons.
 * 1) Disallow "nested" substitution in signature
 * This will be implemented as originally planned.

The process for implementing this change is:


 * A general announcement will be made in Tech News when the new requirements are deployed.
 * Once the software change has been made on the servers, users will no longer be able to save invalid custom signatures. However, existing signatures will remain.
 * Active editors with invalid signatures will be encouraged to change their signatures. This process will likely take some months.
 * Eventually, all signatures will need to conform. If editors do not correct their custom signatures, then their custom signatures will stop working, and the default signature will appear instead.

Third-party wikis will be able to enable this change manually.