Novas exigências para as assinaturas dos usuários

This page is a translated version of the page New requirements for user signatures and the translation is 97% complete.

Diversas wikis têm exigências para a personalização das assinaturas dos usuários. A Equipe de Edição está buscando sua opinião sobre uma proposta para por alguns desses requisitos na Wikipedia. Facilitando responder a comentários específicos nas páginas de discussão e usar algumas outras ferramentas.

Para mais detalhes sobre o que está sendo proposto, e por que, veja abaixo:

Entrada: sua avaliação

A equipe deseja seu feedback sobre esta proposta.

Por favor, poste seu comentário sobre essas perguntas nessa página de discussão:

  1. Essas validações de assinatura criariam problemas em sua wiki?
  2. O que você acha que a equipe deve estar ciente antes de fazer essa alteração?
  3. O que deve ser feito com as assinaturas existentes que não atendem aos novos limites? Por exemplo, eles devem ser proibidos?

Por favor, não se sinta limitado pelas perguntas acima. A equipe deseja ouvir qualquer feedback que você queira compartilhar.

Bastidores: porque está mudando?

Em 2019, voluntários de 20 projetos e grupos de usuários da Wikimedia, junto com a equipe da Fundação Wikimedia, participaram doa consulta de páginas de discussão. Foi um esforço para definir melhores ferramentas para comunicação na wiki.

Um dos resultados desta consulta foi um pedido de uma maneira mais fácil de responder a comentários específicos nas páginas de discussão.

Para que este recurso funcione bem, o software precisa de assinaturas para ser "legível por máquina", para que possa detectar os comentários dos usuários de forma confiável e permitir respondê-los.

O problema é que, embora muitas wikis já tenham os requisitos de assinatura necessários em vigor, esses requisitos não estão incluídos no próprio software. Isso aumenta as chances de alguém definir uma assinatura que quebre as convenções da wiki e, potencialmente, torne mais difícil para as pessoas participarem das conversas.

Essa consistência adicional no formato das assinaturas melhoraria os recursos existentes, como notificações de "menção", que são enviados apenas se a assinatura puder ser detectada em sua edição.

Proposta: requisitos de validação de assinatura

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.

Se não forem identificados obstáculos significativos, essa mudança poderá ocorrer em abril de 2020. Se a equipe precisar fazer mudanças significativas como resultado de seu feedback, demorará mais.

As três verificações propostas são descritas nesta seção. Eles seriam aplicados às assinaturas do usuário em Preferências quando um usuário salvasse uma assinatura modificada. De acordo com a proposta da equipe de edição as assinaturas existentes *NÃO* serão afetadas.

Proibir alguns erros de HTML inválido e outros erros Linter

Mais importante, essa mudança não permitiria tags de formatação não fechadas, como ‎<i> ou a marcação wikitexto correspondente, '', sem uma etiqueta de fechamento correspondente (neste caso, ‎</i> ou '', respectivamente). As assinaturas contendo marcação inválida podem afetar toda a página de discussão, quando a formatação continua nos comentários subsequentes.

A verificação também identificaria etiquetas misnested, como <b>foo<i>bar</b></i> (as etiquetas i ou b devem estar do lado de fora), e etiquetas removidas, que são etiquetas de fechamento sem uma tag de abertura correspondente (o oposto da "etiqueta de formatação não fechada" listada acima).

As assinaturas que contêm alguns problemas menos críticos também não seriam permitidas, por exemplo, tags HTML obsoletas como ‎<tt>...‎</tt> e ‎<font>...‎</font>. Embora isso não cause problemas imediatos, fazer isso evitaria a propagação de código obsoleto para novas páginas da wiki, o que é um aborrecimento para os editores que estão limpando erros do Linter.

Uma lista completa de recursos de sintaxe que não seriam permitidos, junto com links para páginas que explicam como atualizar ou corrigir o código com erros Linter, está disponível nesse endereço.

As etiquetas de formatação não fechadas já deveriam ser evitadas pelo software, mas devido às limitações do analisador wikitexto atual, isso funcionou apenas em alguns casos. Uma solução mais robusta tornou-se possível graças a Parsoid.

Exigir um link para a página do usuário, página de discussão ou contribuições

Várias ferramentas não funcionam corretamente quando uma assinatura não contém pelo menos um dos seguintes links: um link para a página do usuário do usuário, página de discussão do usuário ou página de contribuições. Por exemplo, notificações de "menção" não são enviados, e próximos DiscussionTools não permitirá responder a comentários com essas assinaturas inválidas. Gadgets e outras ferramentas que interagem com assinaturas também podem não funcionar como esperado.

Este requisito está presente há muito tempo nas políticas de muitas wikis da Wikimedia, mas não foi imposto pelo software MediaWiki.[1]

Não permitir a substituição "aninhada" na assinatura

Algum uso de marcação subst: e tis também não seria permitido nas assinaturas. Anteriormente, era possível usar esses recursos para definir uma assinatura que faria com que o nome de um editor subsequente fosse colocado em seus comentários. Todas as formas de falsificação de assinaturas foram proibidas há muito tempo pela política das wikis maiores e esse tipo de falsificação agora será evitado no software. Subst simples: marcação simples ainda é permitida.

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.

Impacto: efeitos da mudança

O que aconteceria com as assinaturas existentes?

Quaisquer assinaturas existentes que se tornariam inválidas sob as novas regras ainda são permitidas (grandfathered in). Ao visualizar suas preferências, você verá uma mensagem de aviso sobre isso e, se tentar alterar a assinatura, a nova deve ser válida. Mas se você não alterá-la, a antiga assinatura inválida continuará a ser usada quando você assinar, e você poderá alterar suas outras preferências sem afetá-la.

Estamos procurando um feedback sobre se você deseja que as assinaturas inválidas existentes sejam rejeitadas. Se assinaturas inválidas não forem permitidas, a assinatura padrão será inserida quando os usuários afetados assinarem seus comentários, até que corrijam suas assinaturas personalizadas.

Quando essas mudanças podem ocorrer?

Comente antes de 31 de março de 2020. A equipe de edição tomará decisões sobre este projeto no início de abril. Os resultados serão publicados na página de discussão.

Se nenhum obstáculo for identificado, essa mudança não acontecerá antes de abril de 2020. Essa data pode ser adiada se a equipe precisar implementar mudanças significativas como resultado de seu feedback.

Como saberemos quais mudanças estão acontecendo?

Incluiremos outro aviso em m:Tech/News quando essa mudança estiver prestes a ser implementada.

Como podem ser os erros de validação de assinatura?

Os erros de HTML/lint incluem links para documentação existente sobre erros de lint, como Help:Extension:Linter/missing-end-tag, e um botão para destacar a parte problemática da assinatura.

Os erros de link necessários incluem sintaxe de wikitexto de exemplo a ser usada.

Resultado

Original proposal

A proposta foi amplamente aceita. Em resposta aos comentários dos voluntários, algumas pequenas mudanças foram feitas e alguns pontos foram esclarecidos.

  1. Proibir alguns HTML inválidos e outros erros de Linter
    O escopo dessas mudanças será reduzido. As etiquetas Misnested e stripped será rejeitado. Alguns erros de baixa prioridade ainda serão aceitos. Especificamente, etiquetas de HTML obsoletas como ‎<tt>...‎</tt> e ‎<font>...‎</font> não serão banidas neste momento. Esta decisão não prejudica qualquer decisão futura a favor ou contra a remoção dessas etiquetas HTML obsoletas.
  2. Exigir um link para a página do usuário, página de discussão ou contribuições
    Isso será implementado conforme planejado originalmente.
    Para maior clareza, deve haver pelo menos um link direto local (não por meio de um redirecionamento, por exemplo, do nome de usuário antigo) para uma dessas páginas. Assim, uma assinatura de [[User:Example|Exemplo]] ([[m:User talk:Example]]) seria aceitável (um link local, um link para outra wiki), mas uma assinatura que inclui links somente para outra wiki, ou only redirecionamentos de um nome de usuário anterior serão inválidos. Isso ocorre por motivos técnicos.
  3. Não permitir a substituição "aninhada" na assinatura
    Isso será implementado conforme planejado originalmente.

O processo para implementar essa mudança é:

  •   Concluído Um anúncio geral será feito nas novidades técnicas quando os novos requisitos são implantados.
  •   Concluído Uma vez que a mudança de software tenha sido feita nos servidores, os usuários não poderão mais salvar assinaturas personalizadas inválidas. No entanto, as assinaturas existentes permanecerão.
  •   Em andamento Editores ativos com assinaturas inválidas serão incentivados a alterar suas assinaturas. Este processo provavelmente levará alguns meses.
  • Eventualmente, todas as assinaturas precisarão estar em conformidade. Se os editores não corrigirem suas assinaturas customizadas, então suas assinaturas customizadas irão parar de funcionar e a assinatura padrão aparecerá em seu lugar.

As wikis de terceiros poderão ativar essa alteração manualmente.

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.

Notas

  1. Veja os exemplos listados em T237700.