Neue Anforderungen für Benutzersignaturen

This page is a translated version of the page New requirements for user signatures and the translation is 54% complete.
Outdated translations are marked like this.

Viele Wikis haben Anforderungen an Benutzersignaturen. Das Redaktionsteam bittet Sie um Ihre Meinung zu einem Vorschlag, einige dieser Anforderungen in der Wikipedia-Software zu implementieren. Dies erleichtert es, auf bestimmte Kommentare auf Diskussionsseiten zu antworten und einige andere Tools zu verwenden.

Weitere Informationen darüber, was vorgeschlagen wird und warum, finden Sie unten:

Eingabe: Ihr Feedback

Das Team wünscht sich Ihr Feedback zu diesem Vorschlag.

Bitte posten Sie Ihre Kommentare zu diesen Fragen auf der Diskussionsseite:

  1. Würden diese Signaturüberprüfungen Probleme in Ihrem Wiki verursachen?
  2. Was sollte das Team Ihrer Meinung nach beachten, bevor Sie diese Änderung vornehmen?
  3. Was gilt es mit vorhandenen Signaturen zu tun, die die neuen Vorraussetzungen nicht erfüllen? Sollten sie beispielsweise nicht zugelassen werden?

Bitte fühlen Sie sich durch die obigen Fragen nicht eingeschränkt. Das Team möchte jedes Feedback hören, das Sie uns mitteilen möchten.

Hintergrund: Warum diese Änderung?

Im Jahr 2019 nahmen Freiwillige aus Wikimedia-Projekten und Benutzergruppen zusammen mit Mitarbeitern der Wikimedia Foundation an der Konsultation zu Diskussionsseiten teil. Es wurde versucht, bessere Tools für die On-Wiki-Kommunikation zu definieren.

Eines der Ergebnisse dieser Konsultation war eine Anfrage nach einer einfacheren Möglichkeit, auf bestimmte Kommentare zu antworten auf Diskussionsseiten.

Damit diese Funktion gut funktioniert, benötigt die Software Signaturen, die "maschinenlesbar" sind, damit sie die Kommentare der Benutzer zuverlässig erkennen und auf sie antworten können.

Das Problem ist, dass viele Wikis bereits über die erforderlichen Signaturanforderungen verfügen, diese Anforderungen jedoch nicht in der Software selbst enthalten sind. Dies erhöht die Wahrscheinlichkeit, dass jemand eine Signatur setzt, die gegen die Konventionen des Wikis verstößt, und erschwert möglicherweise die Teilnahme an Gesprächen.

Diese zusätzliche Einheitlichkeit im Format der Signaturen würde vorhandene Funktionen wie "Erwähnungen" verbessern, die nur gesendet werden, wenn die Signatur in Ihrer Bearbeitung erkannt werden kann.

Vorschlag: Anforderungen an die Gültigkeit der Signatur

This is an archived record of a previous proposal. Please do not modify it. A summary of the conclusions reached is in the #Outcome section.

Wenn keine wesentlichen Hindernisse festgestellt werden, könnte diese Änderung im April 2020 erfolgen. Wenn das Team aufgrund Ihres Feedbacks wesentliche Änderungen vornehmen muss, dauert es länger.

Die drei vorgeschlagenen Abfragen werden in dieser Sektion beschrieben. Diese würden auf die Benutzer-Signaturen in den Eigenschaften angewandt, sobald ein Benutzer eine modifizierte Signatur speichert. Under the Editing team's proposal existing signatures will *NOT* be affected.

Ungültiges HTML und andere Linter Fehler nicht zulassen

Most importantly, this change would disallow unclosed formatting tags, like ‎<i> or the corresponding wikitext markup, '', without a matching closing tag (in this case, ‎</i> or '', respectively). Signatures containing invalid markup can affect the entire discussion page, when the formatting continues into subsequent comments.

The check would also identify misnested tags, like <b>foo<i>bar</b></i> (either both of the i, or both of the b, tags should be on the outside), and stripped tags, which are closing tags without a corresponding opening tag (the opposite of the "unclosed formatting tag" listed above).

Signatures that contain some less critical problems would also be disallowed, e.g., obsolete HTML tags like ‎<tt>...‎</tt> and ‎<font>...‎</font>. While these do not cause immediate issues, doing this would prevent the spread of obsolete code to new wiki pages, which is an annoyance for editors cleaning up Linter errors.

A full list of syntax features that would not be allowed, along with links to pages that explain how to update or fix code with Linter errors, is available at this address.

Unclosed formatting tags were already supposed to be prevented by the software, but due to limitations of the current wikitext parser, this worked only in some cases. A more robust solution has become possible thanks to Parsoid.

Einen Link zur Benutzerseite, Diskussionsseite oder zu den Beiträgen verlangen

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. (The link must be for a page on the wiki the signature is used on; interwiki or interlanguage links – e.g., to a different language of Wikipedia – are not sufficient.) 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.[1]

"Verschachtelte" Signaturen nicht zulassen

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.

Additional proposal (2021)

Disallow line breaks in signature

This is an archived record of a previous proposal. Please do not modify it. A summary of the conclusions reached is in the #Outcome section.

The signature must consist of a single line of wikitext. Line breaks can result in incorrect formatting when the signature is used in a nested comment. They can also cause problems with tools used on discussion pages. This affects the literal carriage return and line feed characters, not ‎<br> and ‎<p>.

At this time, you cannot add these characters to a custom signature in Special:Preferences. This proposal will prevent them from being added via a substituted signature template or by editing your preferences programatically.

Auswirkungen: Auswirkungen von Veränderungen

Was würde mit vorhandenen Signaturen passieren? Alle vorhandenen Signaturen, die nach den neuen Regeln ungültig werden würden, sind weiterhin zulässig (grandfathered in). Wenn Sie Ihre Einstellungen anzeigen, wird eine Warnmeldung angezeigt. Wenn Sie versuchen, die Signatur zu ändern, muss die neue gültig sein. Wenn Sie es jedoch nicht ändern, wird die alte ungültige Signatur beim Signieren weiterhin verwendet, und Sie können Ihre anderen Einstellungen ändern, ohne sie zu beeinflussen.

Wir bitten um Feedback, ob vorhandene ungültige Signaturen nicht zugelassen werden sollen. Wenn ungültige Signaturen nicht zulässig sind, wird die Standardsignatur eingefügt, wenn betroffene Benutzer ihre Beiträge signieren, bis sie ihre personalisierten Signaturen korrigieren.

Wann könnten diese Änderungen stattfinden? 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.

Wenn keine Hindernisse identifiziert werden, würde diese Änderung frühestens im April 2020 erfolgen. Dieses Datum könnte verschoben werden, wenn das Team aufgrund Ihres Feedbacks wesentliche Änderungen vornehmen muss.

Woher wissen wir, welche Veränderungen stattfinden?

Wir werden über m:Tech/News informieren, wenn diese Änderung bereitgestellt werden soll.

Wie könnten die Signaturvalidierungsfehler aussehen?

Die HTML-/Linterrors enthalten Links zu vorhandener Dokumentation zu Linterrors wie Help:Extension:Linter/missing-end-tag und eine Schaltfläche zum Hervorheben des problematischen Teils der Signatur.

Zu den erforderlichen Linkfehlern gehört die zu verwendende Beispiel-Wikitext-Syntax.

Outcome

Original proposal

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 ‎<tt>...‎</tt> and ‎<font>...‎</font> will not be banned at this time. This decision does not prejudice any future decision for or against removing these obsolete HTML tags.
  2. 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 [[User:Example|Example]] ([[m:User talk:Example]]) 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.
  3. Disallow "nested" substitution in signature
    This will be implemented as originally planned.

The process for implementing this change is:

  • Yes Erledigt A general announcement will be made in Tech News when the new requirements are deployed.
  • Yes Erledigt 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.
  • In Arbeit In Arbeit 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.

2021 proposal

The line break characters carriage return and line feed (but not the HTML codes for them, e.g., ‎<br /> and ‎<p>) are disallowed.

Anmerkungen

  1. See examples listed on T237700.