New requirements for user signatures/uk

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Обов'язкове посилання на сторінку користувача, сторінку обговорення або внеску
Various tools don't work correctly when a signature does not contain at least one of the following links: a link to the user's user page, user talk page, or contributions page. For example, "mention" notifications are not sent, and forthcoming DiscussionTools will not allow replying to comments with these invalid signatures. Gadgets and other tools that interact with signatures also may not work as expected.

This requirement has been present for a long time in many Wikimedia wikis' policies, but it has not been enforced by the MediaWiki software.

Disallow "nested" substitution in signature
Some use of subst: markup and tildes would also be disallowed in signatures. Previously, it was possible to use these features to set a signature that would cause a subsequent editor's name to be placed on your comments. All forms of signature forgery have long been banned by policy at the larger wikis, and this type of forgery will now be prevented in software. Simple subst: markup is still allowed.

What would happen to existing signatures?
Any existing signatures that would become invalid under the new rules are still allowed (grandfathered in). When viewing your preferences, you would see a warning message about this, and if you try to change the signature, the new one must be valid. But if you don't change it, the old invalid signature will continue to be used when you sign, and you'll be able to change your other preferences without affecting it.

We're looking for feedback as to whether you would like existing invalid signatures to be disallowed. If invalid signatures are disallowed, the default signature would be inserted when affected users sign their comments, until they correct their personalized signatures.

When might these changes take place?
Please comment before 31 March 2020. The Editing team will make decisions about this project in early April. The results will be posted on the talk page.

If no obstacles are identified, this change would happen no earlier than April 2020. This date could be pushed back if the team needs to implement significant changes as a result of your feedback.

How will we know what changes are happening?
We'll include another notice in Tech/News when this change is about to be deployed.

What might the signature validation errors look like?
The HTML/lint errors include links to existing documentation about lint errors, such as Help:Extension:Linter/missing-end-tag, and a button to highlight the problematic part of the signature.

The required link errors include example wikitext syntax to use.

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