Wikipédia Discussão:Predefinição de navegação

[Ver]

Predefs expansíveis

Notei que a maioria das predefs expansíveis, principalmente as de rodapé, aparecem abertas. Como acredito que por serem expansíveis deveriam aparecer fechadas, trago a proposta de mudança, por um bot, do comando "autocolapsed" para "colapsed", nas citadas predefs. Seguindo o sábio conselho, coloco essa mudança em discussão aqui. Fra Amats ^disputatio 22h29min de 3 de agosto de 2010 (UTC)

A priori concordo, pois não gosto nada delas abertas, mas as que não são muito grandes não me incomodam muito, além de que é daquelas questões mais de gosto pessoal do que outra coisa, para as quais não me sinto à vontade para me alongar em argumentos com quem se opuser. Por outro lado, para mim o problema não são as "autocolapsed", porque ao que me parece essas aparecem inicialmente fechadas se o texto do artigo for grande, mas sim as "show". Talvez tivesse sentido discutir acabar com a opção show em {{navbox}}, passando a ser equivalente a "autocolapsed". --Stegop (discussão) 22h41min de 3 de agosto de 2010 (UTC)

Concordo. Discutamos pois a opção show, na verdade, creio que a forma de fazer é o de menos, o que importa mesmo é que elas apareçam fechadas. Fra Amats ^disputatio 22h44min de 3 de agosto de 2010 (UTC)

• Favor não esquecer de observar como estes dados aparecerão em impressão e no formato .pdf.  Dé✓^msg  Quarta-feira, 00h01min de 4 de agosto de 2010 (UTC)

Posso estar a ver mal a coisa, mas possivelmente até é desejável que estas caixas nem sequer apareçam na impressão, pois a sua função é de navegação,, não fazendo muito sentido em papel. --Stegop (discussão) 00h57min de 4 de agosto de 2010 (UTC)

Sim, claro. As de fundo ok, mas por exemplo existe na Predefinição:Info/Química, acho que é o smiles, que qd imprime não aparece o dado no .pdf. E lembro que foi proposto (só que ninguém fez) para colocar tds as caixas como show, para diminuir espaço. É apenas um lembrete. Como .pdf é gerado link clicável tb, lógico, apenas como arquivo, hehe.  Dé✓^msg  Quarta-feira, 14h35min de 4 de agosto de 2010 (UTC)

• Discordo Nem sempre o botão para abrir uma predef é visível, além de dificultar a consulta para quem não é familiarizado com o português. Já passei pela experiência desagradável de achar um artigo sobre química na wiki.pl tinha sido vandalizado porque não vi que a chembox estava colapsada. Albmont (discussão) 19h19min de 5 de agosto de 2010 (UTC)

Não percebi o que quer dizer, Albmont: "nem sempre está visível? como assim? dificultar a consulta?" --Stegop (discussão) 19h28min de 5 de agosto de 2010 (UTC)

Também não entendi o comentário do Albmont. Pra mim parece óbvio e lógico, se existe a opção de se "colapsar" a predefinição ela deve ficar assim por padrão, do contrário a função perde totalmente sua utilidade, e obriga-se o editor a ficar "fechando-as" manualmente a cada artigo que abre... RafaAzevedo ^disc 20h10min de 5 de agosto de 2010 (UTC)

A proposta é pra tornar padrão mostrar a predefinição escondida, certo? Se fim, eu apoio.

Flávio, o Maddox ^{(msg! • contrib)} 20h20min de 5 de agosto de 2010 (UTC)

• Brevis esse laboro, obscurus fio... Seguinte: eu acho que, no momento em que se coloca uma predefinição dessas caixinhas no artigo, é porque ela deve ser visível. Se não, era melhor não ter a caixinha, mas ter uma ligação para um artigo. A exceção possível seria uma predefinição para spoilers, como a usada no wikilivros para tratar demonstrações (que devem ficar ocultas, para que o estudante possa tentar fazer, sem, acidentalmente, colar a resposta). Então trocar tudo que é predef colapsável para sua forma colapsada é madness, e eu discordo disso. Albmont (discussão) 20h21min de 5 de agosto de 2010 (UTC)

Madness é impor a obrigatoriedade do conteúdo se existe a opção de deixá-lo fechado. Então para quê a opção de fechar? Sinceramente, não compreendo... RafaAzevedo ^disc 20h44min de 5 de agosto de 2010 (UTC)

DiscordoSe existe a 'opção' colapsar, trata-se obviamente de uma 'opção', geralmente criada para predefs longas, e não um padrão, nem trata-se de uma obrigação. Cabe a cada editor 'optar' se quer ve-la aberta ou fechada, ou não seria uma 'opção'. Fica a critério do usuario, sem imposições. Há coisa mais importantes. A função é util como 'opção', obviamente. Alguns a preferem aberta para consulta automatica, outros não, deixa-se à escolha do freguês ao invés de se impor nada. MachoCarioca ^oi 20h21min de 5 de agosto de 2010 (UTC)

Exatamente, deixa-se "à escolha do freguês"; quem quiser, a expande, e quem não quiser deixa-a fechada. Deixá-la aberta é que é impor algo ao leitor. Predefinições abertas só colaboram para o já célebre "efeito árvore de Natal", e poluem totalmente o fim do artigo (sem falar no exagero, tem artigo com quatro ou cinco ou até mais destas predefinições). RafaAzevedo ^disc 20h42min de 5 de agosto de 2010 (UTC)

Na verdade, a escolha é do editor do artigo, que deve optar, usando o bom senso, se a predef deve vir aberta ou fechada. O errado é querer impor que todas predefs comecem fechadas como padrão. Albmont (discussão) 20h48min de 5 de agosto de 2010 (UTC)

Citação: Albmont escreveu: «O errado é querer impor que todas predefs comecem fechadas como padrão.» E você não está querendo impor também que elas comecem abertas como padrão?

Num projeto como esse não existe "o editor do artigo", e sim diversos editores, cada um com sua vontade. Supondo que um deles queira e o outro não, como fica? É sempre desejável alguma padronização. Em artigos sobre televisão por exemplo esta sua proposta é totalmente inviável, tendo em vista que cada IP que passa num desses artigos sapeca lá uma predefinição-trambolho... RafaAzevedo ^disc 20h52min de 5 de agosto de 2010 (UTC)

Citação: RafaAzevedo escreveu: «E você não está querendo impor também que elas comecem abertas como padrão?» Não, eu estou discordando de que elas sejam fechadas por padrão. Mas, se o consenso for por um padrão, então eu prefiro as predefs abertas a fechadas. Quanto a Citação: RafaAzevedo escreveu: «Em artigos sobre televisão por exemplo esta sua proposta é totalmente inviável, tendo em vista que cada IP que passa num desses artigos sapeca lá uma predefinição-trambolho...» a solução é banir os IPs, e não banir as predefinições :-) Albmont (discussão) 21h01min de 5 de agosto de 2010 (UTC)

Citação: Albmont escreveu: «Não, eu estou discordando de que elas sejam fechadas por padrão.» Tarde demais, já que muitas delas já o são por default. RafaAzevedo ^disc 21h06min de 5 de agosto de 2010 (UTC)

Na verdade, eu estou discordando de que todas elas sejam fechadas por padrão. Eu não me oponho que algumas delas estejam fechadas por conveniência (por exemplo, o SMILES da caixa Info/Química é um exemplo de caixa que deve vir fechada; dá uma olhada em Amineptina para ver porque esse treco tem que estar fechado - e olha que tem outras piores). Albmont (discussão) 21h45min de 5 de agosto de 2010 (UTC)

Nesse ponto concordo, não sou tão radical, acho que podem ser abertas exceções para predefinições mais "discretas" (de uma linha apenas, por exemplo). RafaAzevedo ^disc 22h03min de 5 de agosto de 2010 (UTC)

Tentando fazer uma síntese dos "concordo" e "discordo", que tal se, em vez de decidir mudar (quase) tudo, tentássemos chegar a dois consensos:

1. Alterar {{navbox}} e outras semelhantes para que o comportamento de defeito seja "autocolapse" em vez do atual "show". Desta forma, vai depender do código do "autocolapse" apresentar inicialmente aberta ou fechada.
2. Escrever uma recomendação no sentido de se dever evitar que navboxes e caixas afins apareçam inicialmente abertas quando são muito grandes. Sendo uma recomendação, quanto a mim ela deveria deixar explícito que o comportamento aconselhado em princípio é "colapsed". Não resisto a dar um exemplo caricatural, em que o absurdo não se limita a ela aparecer aberta: {{Shopping centers do Brasil}}. --Stegop (discussão) 23h11min de 5 de agosto de 2010 (UTC)

Devem ser todas deixadas no padrão em que foram ou sejam criadas, esse é o mais logico, de bom senso e democratico. Acredito entretanto que claro, predefinições absurdas com 40 linhas como algumas aqui devem ficar fechadas como padrão, per si.

Citação: Stegop escreveu: «Escrever uma recomendação no sentido de se dever evitar que navboxes e caixas afins apareçam inicialmente abertas quando são muito grandes»

Isso é bom senso, o resto é querer impor coisas que não podem ser impostas, pela propria variedade dos assuntos cobertos pela Wiki. Aqui é o lugar do 'depende', pois é Ciencia Humana. MachoCarioca ^oi 01h12min de 6 de agosto de 2010 (UTC)

Acho que não fui claro: quando falei no "comportamento de defeito" referia-me ao facto de que atualmente, se não se indicar o parâmetro "state" em {{navbox}}, é assumido "open". O que eu proponho é que passe a ser assumido "autocolapse". Isso não vai alterar em nada o comportamento das predef.s que indicam explicitamente qual o "state". Ou seja, quem achar que o "state" deve ser "show", o que tem a fazer é ir ao código da predef e alterar.

Quanto ao "bom senso", concordo, mas se existir uma recomendação para não abrir as navboxes com mais do que X linhas, fica mais fácil argumentar com aqueles cujo "bom senso" nada tem a ver com o meu ou com o que acredito que seja o dos que estão aqui a discutir. --Stegop (discussão) 02h47min de 6 de agosto de 2010 (UTC)

[Ver]

Chega de pseudo-listas!

Coisas que não são listas (formatadas como se fossem)

Esta proposta (assim como a de acabar com as tabelas bonitas) pode ser vista como um subtópico da proposta mais abrangente que visa dar a devida importância à acessibilidade e a semântica das páginas da Wikipédia.

As três têm em comum o objetivo de se iniciar de uma vez a limpar a bagunça que tem se acumulado nas páginas ao longo dos anos devido à má utilização de tags e atributos HTML (para formatar em vez de dar significado aos trechos das páginas), e consequente subutilização de CSS.

Inicialmente eu só ia fazer uma correção na Predefinição:Artigo principal, que conforme indiquei no sumário, visava a

"remoção de <dd> e <dl> supérfluos, pois isso não é uma lista de definições (se houver motivo para aumentar a margem à esquerda, defina-se isso em uma classe CSS aplicada neste <div>, talvez a dablink)".

Como fui revertido, deduzo que a margem à esquerda do texto da predefinição é importante, então acho que para corrigir o problema semântico em questão será preciso alterar não apenas a predefinição mas também o MediaWiki:Common.css, para que as páginas que a utilizam fiquem corretas.

Se quiser mais detalhes, expanda este trecho...

A princípio, bastaria refazer minha edição e acrescentar um atributo style="margin-left:1.5em;" para que obtivéssemos o mesmo efeito visual da versão anterior à minha edição, e sem usar <dd> e <dl> indevidamente. No entanto, como o texto também está sendo formatado em itálico, com uma tag <i>...</i>, e a predefinição é usada em muitos artigos, imaginei que seria vantajoso remover a tag extra, deixando apenas o div e uma classe "dablink", e mover a formatação para a folha de estilos global do site.

Fui bisbilhotar na wiki inglesa e vi que estava reinventando a roda: por incrível que pareça, a classe já está lá na predefinição desde [20??], mas sua aparência nunca foi definida, ou melhor, até foi: definiu-se que quem usa o monobook não verá a dablink ao imprimir a página.

Obviamente, os leitores lusófonos é que pagam a conta por causa da nossa inércia... (o monobook deixou de ser o tema padrão há anos, e o excesso de tags adicionais só aumenta o tamanho das páginas à toa).

Além disso, enquanto os ingleses em 2006 já estavam otimizando as páginas por meio da remoção do ":" e do itálico que seriam incorporados na classe "dablink" (cuja aparência na época também não tinha nada de especial), nós em abril de 2010 estávamos triplicando a quantidade de código necessária na predefinição:

• Incluímos a classe "dablink" (apenas para fins semânticos, já que não havia há estilos associados a ela por padrão), mas
• Mantivemos o ":", que faz com que o texto vire uma lista de definições (<dl>, <dd>, em HTML), o que é semanticamente incorreto (afinal isso não é uma lista!)
• Mantivemos a tag extra para o itálico, sendo que bastava ter definido isso na dablink.

Para quem quiser ver um pouco mais, as discussões que precederam a mudança na enwiki foram estas:

• en:Wikipedia:Village pump (technical)/Archive AF#Disambig link formatting
• en:Template talk:Hatnote#visual formatting should be done in CSS, not wiki markup

O que proponho é copiarmos o seguinte da en:MediaWiki:Common.css para a MediaWiki:Common.css (para ser possível corrigir/simplificar a predefinição mencionada e outras do gênero - imagino que há várias parecidas):

/* Hatnotes and disambiguation notices */
.rellink,
.dablink {
    font-style: italic;
    /* @noflip */
    padding-left: 1.6em;
    margin-bottom: 0.5em;
}
.rellink i,
.dablink i {
    font-style: normal;
}

Alguém se opõe às simplificações? Se sim, por que? Helder 22h42min de 5 de julho de 2012 (UTC)

PS: Não sei se por aqui aconteceu de aplicarem "subst" em predefinições que usam dablink/rellink, mas se for o caso talvez seja preciso ajuda de robôs para corrigir esses casos (como na wiki inglesa). Helder 22h42min de 5 de julho de 2012 (UTC)

Concordo. Abaixo a quantidade de HTML inútil enviado aos leitores e a subutilização do CSS. !Silent (discussão) 23h18min de 5 de julho de 2012 (UTC)

Concordo Fui eu que desfiz a alteração, não por discordar, mas porque modificações que implicam alterações de layout de muitas páginas, nomeadamente mudar uma predef muito usada há muito tempo, devem ser discutidas. Dito de outra forma: possivelmente nem era necessário esta discussão, conquanto o aspeto visual não fosse muito alterado. Só tenho uma pergunta: as classes CSS acima só são usadas por {{Artigo principal}}? Convém averiguar isso antes de se avançar com as alterações. --Stegop (discussão) 23h50min de 5 de julho de 2012 (UTC)

Não, as classes são usadas para substituir o : quando necessário, como no caso da predef {{Artigo principal}}.
Só não entendi o por quê de duas classes para fazer exatamente a mesma coisa. !Silent (discussão) 00h19min de 6 de julho de 2012 (UTC)

Também não sei ainda o motivo de existirem duas classes. Talvez possamos descobrir com o WikiBlame com e onde a "rellink" surgiu, e com que objetivo foi criada. Aí saberemos se é necessário manter as duas. Helder 12h31min de 6 de julho de 2012 (UTC)

As duas classes têm significados diferenets: a "rellink" serve para marcar os "links relacionados" enquanto que a "dablink" serve para os de "desambiguação". Ver en:Wikipedia:Village pump (technical)/Archive 57#Dablink for section hatnotes. Helder 03h12min de 19 de julho de 2012 (UTC)

Pesquisar por "dablink" só mostra um resultado no domínio predefinição: a Predefinição:Dablink. Mas sabemos que a dablink está na Predefinição:Artigo principal, então acho que não poderemos confiar na Especial:Busca para isso . Será melhor que alguém com uma cópia do dump mais recente da Wikipédia (de 27 de junho de 2012) use o AWB para gerar uma lista de todas as páginas que contenham "dablink", para termos uma ideia melhor do que precisará ser alterado (e se há artigos em que ela está sendo usada diretamente, talvez por causa do "subst"). Por hora, observei o seguinte:

A Predefinição:Rellink tem cerca de 500 afluentes e a Predefinição:Dablink cerca de 100.

A Categoria:!Predefinições para desambiguações tem algumas predefinições que usam dablink e o ":". Não conferi todas. Helder 12h31min de 6 de julho de 2012 (UTC)

Aqui estão as listas obtidas ao procurar por "rellink" e por "dablink" no dump de 27 de junho de 2012. A "rellink" aparece em 15 páginas e a "dablink" em 119. Helder 13h45min de 8 de julho de 2012 (UTC)

Apoio a proposta, com isso poderá ajudar a simplificar ainda mais. Vitor Mazuco ^Msg 13h49min de 9 de julho de 2012 (UTC)

Concordo e Apoio! Gostei! Abraços! Mar França (discussão) 04h12min de 25 de julho de 2012 (UTC)

Concordo. Não entendi muito bem a parte técnica, mas tem havido abuso nessas tabelas (fenômeno que eu chamo de "tabelite") — ator com duas novelas tendo a filmografia tabelada, por exemplo. Se a proposta vai inibir isso, eu apoio. Yanguas ^diz!-fiz 14h53min de 26 de julho de 2012 (UTC)

Concordo. Não entendi bem isso tecnicamente, mas vale a boa vontade! Braz Leme (discussão) 13h04min de 16 de outubro de 2015 (UTC)

Implementação

Defini a classe no MediaWiki:Common.css e atualizei algumas predefinições, mas há varias outras na lista de páginas que contém as classes. Helder 13h24min de 25 de outubro de 2012 (UTC)

Listas (formatadas como se não fossem)

Listas horizontais

Conforme mencionei nesta página, acredito que deveríamos definir também os estilos necessários no MediaWiki:Common.css para que pudessem ser usadas listas de verdade em diversas predefinições e páginas em que atualmente usa-se o caractere "•" para separar diversos itens do que deveria ser, de fato, uma lista. Alguns exemplos são:

• Predefinição:Carnaval de São Paulo
• Predefinição:MRDebates

Na Wikipédia inglesa, o estilo parece estar definido nas classes "hlist" e "hnum" do en:MediaWiki:Common.css. Sugiro que seja implementado o mesmo por aqui, para que listas horizontais possam passar a ser feitas de forma semanticamente correta.

Para mais detalhes, ver:

• en:Wikipedia:Manual of Style/Accessibility#Horizontal lists

E sobre como foi criada a classe, ver:

• en:MediaWiki talk:Common.css/Archive 13#Horizontal lists
• en:Wikipedia talk:Manual of Style/Accessibility/Archive 12#Horizontal lists in navboxes

Helder 00h22min de 29 de julho de 2012 (UTC)

E então? Isso pode ser implementado? Helder 00h08min de 11 de agosto de 2012 (UTC)

Eu apoio. Isso parece ser um recurso que não mudará (ou mudará pouco) o visual das coisas, e facilitará a edição dessas predefs pq seria só criar a lista como se faz normalmente, padronizando tb as coisas (alguns usam *, outros  • , e tem outras variações por aí), além de arrumar a semantica (ou algo técnico por aí) das páginas. Não vejo impedimento algum, ao menos nenhum impedimento grande para exigir mt apoio para poder aprovar, tendo ficado aberto já por duas semanas sem oposição já poderia implementar. Rjclaudio ^msg 00h29min de 11 de agosto de 2012 (UTC)

Também concordo. !Silent (discussão) 00h38min de 11 de agosto de 2012 (UTC)

Fiz o pedido aos administradores (espero não ter esquecido nenhuma parte do código necessário). Helder 20h19min de 11 de agosto de 2012 (UTC)

O Common.css foi mudado. E agora? Tem q mudar algo na {{Navbox}}? Como aplica nas predefs? Rjclaudio ^msg 15h27min de 15 de agosto de 2012 (UTC)

É só usar asteriscos normalmente e colocar a classe "hlist" nos elementos apropriados. Por exemplo, a MRDebates eu alterei assim. Na wiki inglesa existe a en:Template:Flatlist que pode ser útil em alguns casos. Ainda não sei em que lugar colocam a classe na navbox (imagino que é cheia de sub (ou meta) predefinições). Helder 22h52min de 15 de agosto de 2012 (UTC)

Acredito que bastará fazer esta alteração para tornar possível começar a migrar as navboxes. Helder 22h17min de 24 de agosto de 2012 (UTC)

Na verdade, foi preciso fazer mais uma correção na Predefinição:Navbox/core. Helder 20h42min de 1 de setembro de 2012 (UTC)

Conversão

Acredito que agora já podemos começar a corrigir as navboxes típicas como eu fiz na Predefinição:CPLP e na Predefinição:Astronomia. Para facilitar, parece que pode-se usar uma expressão regular:

• Localizar: /(\| *(?:lista?\d+|acima|ab(?:ove|aixo)|below) *= *)(?:\{\{ *[Nn]owrap begin *\}\} *)?| *(?:(\|list\d+ *= *)(?:\{\{ *[Nn]owrap begin *\}\} *)?|\{\{ *(?:[·•][Ww](?:rap)?|[·,•*]|[Dd]ot|[Pp]onto|[Bb]ullet) *\}\}|(?:(?: )?[·•]|&(?:bull|#8226|#x2022|middot);)) */g
• Substituir por: $1\n* 

Helder 20h42min de 1 de setembro de 2012 (UTC)

No caso de listas horizontais em que certos itens são agrupados com parênteses, ou nas quais o primeiro item é diferenciado com negrito, pode-se usar sublistas como neste exemplo. Helder 15h47min de 2 de setembro de 2012 (UTC)

Nossa qnt coisa diferente. Imagino q o uso principal da hlist seja pra navbox certo? Isso tudo merece ir pra documentação da navbox. Se usar em outro lugar podia simplesmente linkar para essa doc. Rjclaudio ^msg 15h53min de 2 de setembro de 2012 (UTC)

Não consegui usar o ** na {{Artigos de Sonic}} e na {{Assassin's Creed}}, embora tenha conseguido na {{Age of Empires}} e {{Action Hero}}. Pq? Seria a demora no servidor de atualizar os afluentes da {{NavboxVG}}? A {{Assassin's Creed}} usa {{Navbox subgroup}}, tb precisa atualizar essa predef ou só o q foi feito na {{Navbox}} está bom? Rjclaudio ^msg 16h19min de 2 de setembro de 2012 (UTC)

Olha, não conheço bem a hierarquia dessas predefinições. Mas se alguma navbox usa algo diferente de {{Navbox}} + {{Navbox/core}} como base, provavelmente serão necessárias mais atualizações como as que fizemos recentemente nessas duas... Helder 16h23min de 2 de setembro de 2012 (UTC)

Além da {{·}} tb tem a {{•}}, {{*}} e {{ponto}}, além das q não usam a predef e simplesmente colocam ·, •, e até as q usam &xxxx (não sei como é), e as q usam - ou | como separador. Tem uma infinidade de variações, finalmente vamos conseguir padronizar isso. Rjclaudio ^msg 16h06min de 2 de setembro de 2012 (UTC)

Atualizei a regex acima com os nomes que indicou e também a {{Bullet}} (resta descobrir qual é o &xxxx). Helder 16h23min de 2 de setembro de 2012 (UTC)

De acordo com esta tabela de símbolos em HTML, •, • e • resultam em •. Helder 15h36min de 8 de setembro de 2012 (UTC)

Agora q reparei, o ** só funciona se for no campo |list1=, se for no |list2= ou outros não funciona. Fiz o teste com a Predefinição:CPLP q vc usou como exemplo pra alteração e é isso mesmo. Sabe pq? Rjclaudio ^msg 16h08min de 4 de setembro de 2012 (UTC)

Ainda não sei o motivo, mas talvez tenha relação com as mudanças feitas recentemente lá na enwiki por causa de certo problema causado pelas alterações anteriores. Helder 21h57min de 4 de setembro de 2012 (UTC)

┌────┘ O problema não tem a ver com o CSS. Alguma coisa (o MW ou uma das predefinições) está causando um problema semântico neste exemplo, pois o HTML do primeiro grupo é diferente do dos demais. Compare:

Primeiro (uma lista, com uma sublista)	Segundo/Terceiro (três listas)
<ul> <li>A <ul> <li>A1</li> <li>A2</li> </ul> </li> <li>B</li> </ul>	<ul> <li>A</li> </ul> <ul> <li>A1</li> <li>A2</li> </ul> <ul> <li>B</li> </ul>

Falta descobrir o motivo disso... Helder 19h33min de 15 de setembro de 2012 (UTC)

Informei no bugzilla:40274 uma esquisitice do MW ao lidar com quebras de linha em tabelas. Acredito que ela seja a causa do problema. Parece que se colocar mais algumas quebras de linha na {{Navbox/core}} vai funcionar. Helder 19h33min de 15 de setembro de 2012 (UTC)

Já editei lá para corrigir o bug, e as predefs q estavam dando erro agora estão funcionando direito. Já posso voltar a rodar o awb. Rjclaudio ^msg 01h50min de 16 de setembro de 2012 (UTC)

A Predefinição:Navbox subgroup também já foi corrigida, para que as listas do Portal:Conteúdo destacado ficassem semanticamente corretas. Helder 23h50min de 4 de novembro de 2012 (UTC)

Fui editar uma predefinição e percebi que a classe "hnum" não está implementada. Não há a pretensão de acrescentar a classe ao Common.css? Cainã Marques 03h27min de 18 de junho de 2013 (UTC)

Mas já está lá no MediaWiki:Common.css. Onde testou e o que aconteceu? Helder 11h30min de 18 de junho de 2013 (UTC)

Desculpa Heder, não sabia que deveria ser utilizada conjuntamente com a "hlist". Está funcionando perfeitamente. Inclusive melhor que na anglófona, que atualmente funciona apenas na "list1". Cainã Marques 15h22min de 18 de junho de 2013 (UTC)

Além disso, a classe rellink é realmente necessária? Seu estilo é o mesmo da dablink e acredito que nunca será necessário diferenciá-las. Afinal, servem para o mesmo elemento textual (hatnotes). Cainã Marques 03h41min de 18 de junho de 2013 (UTC)

Como já foi dito, as duas classes tem significados (semântica) diferentes (mas isso não impede que tenham a mesma aparência, como é atualmente). Helder 11h30min de 18 de junho de 2013 (UTC)

Listas simples (sem marcadores/bullets)

A Dianakc nos chamou a atenção para o fato de que a classe plainlist não estava funcionando, e como ela é necessária para que possamos incentivar o uso de, digamos,

{{Lista simples| * [[teste]] * [[exemplo]] * [[fim]] }}

ou

<div class="plainlist"> * [[teste]] * [[exemplo]] * [[fim]] </div>

nos lugares onde hoje é usado

[[teste]]<br />[[exemplo]]<br />[[fim]]

atendi o pedido inserindo no MediaWiki:Common.css o código que é necessário para que isso funcione. Helder.wiki (discussão) 11h41min de 20 de junho de 2014 (UTC)

[Ver]

Navboxes gigantes

Temos alguma recomendação sobre excesso de navbox em artigos? {{Goiânia}}, {{Cidade do Rio de Janeiro}}, {{Cidade de São Paulo}}, entre outras, são 10 navboxes em uma.

Entendo q a WP não é um repositório de ligações internas, e q as listas no Ver também não devem ser muito extensas e incluir só o que tem ligação direta com o artigo. As navboxes foram criadas para facilitar (padronizar) as listas de ver também. Então deviam seguir a mesma lógica de só ter links importantes pro artigo.

Do jeito que a coisa está, com a {{Cidade do Rio de Janeiro}} sendo usada em todos aqueles artigos, na página de uma faculdade do rio há link para ruas, praias, templos, museus, esportes, etc, nada disso tem a mínima relação com a faculdade exceto o fato de estar na mesma cidade. Se algo tiver uma relação mais próxima com a faculdade q liste manualmente isso na seção ver também.

Proponho q essas navboxes sejam desmembradas em navboxes mais específicas e só essas específicas sejam usadas nos artigos. E essas navboxes da cidade só tenham os links para os artigos principais da cidade: história, geografia, ..., pode até ter lista de shoppings / praias / ruas / bairros.

Rjclaudio ^msg 23h49min de 23 de outubro de 2012 (UTC)

Faz sentido. Além do mais, o tamanho do texto está muito menor do que deveria para que fosse legível (quem consegue ler um texto cuja fonte tem tamanho de 8px!?). Diminuam o excesso de informação, não o tamanho do texto que a apresenta! Helder 00h16min de 24 de outubro de 2012 (UTC)

Concordo Aberrações dessas abundam por aqui. Há ou havia até gente que quase não fazia outra coisa. E, confesso, como "em Roma sê romano", eu próprio sou culpado duma: {{Istambul}}, mesmo se em comparação com exemplos como o mencionado acima, aquela até é pequena.

Não quero discutir o assunto aqui, mas aproveito para sondar superficialmente: e faz sentido navboxes em que grande parte dos links são vermelhos? --Stegop (discussão) 00h53min de 24 de outubro de 2012 (UTC)

Depende. Se o conteúdo é nitidamente e inquestionavelmente enciclopédico, que nunca seria questionável por alguém com bom senso e que façam parte de uma lista externa com muita credibilidade, não vejo porque não. Estou-me a lembrar das navboxes de doenças, por exemplo, que têm por base as tabelas internacionais de classificação. Polyethylen (discussão) 01h05min de 24 de outubro de 2012 (UTC)

Concordo Madalena (discussão) 00h57min de 24 de outubro de 2012 (UTC)

Concordo, mas vejo problemas no futuro. Teoricamente, não haveria um racional para impedir que uma predefinição {{Papas}} listasse 238 artigos diferentes em 238 páginas. Este caso real da enwiki demora uns 4 segundos pra carregar, em alguns casos num artiguinho mínimo. Enfim, acho que falta é uma boa solução técnica, a nível de software, pra resolver esse problema. José Luiz ^disc 20h11min de 25 de outubro de 2012 (UTC)

O interessante é que essa en:Template:Patriarchs of Constantinople tem mais itens que a Predefinição:Cidade do Rio de Janeiro, ocupa menos espaço completamente expandida do que a nossa expandida apenas uma vez (!), usa um tamanho de fonte que é legível, e não tem aquele monte de "[Expandir]". Helder 21h41min de 25 de outubro de 2012 (UTC)

Depois de duas semanas, consenso então. Devemos evitar navboxes gigantes. Isso seria tanto grande verticalmente após totalmente aberta, quanto grande de escopo (juntar tudo sobre um tema em uma mesma navbox ao invés de fazer o link para os artigos principais de cada subtema). É isso? Se for melhor colocar esse 'critério' (recomendação, indicação, sinais) em WP:Navbox (com ref para cá) para ficar pelo menos em algum canto (se tiverem algum lugar melhor) Rjclaudio ^msg 12h48min de 8 de novembro de 2012 (UTC)

Desmembrei da {{Cidade do Rio de Janeiro}} as predefs {{Praias da cidade do Rio de Janeiro}} e {{Transporte da cidade do Rio de Janeiro}}, e posteriormente devo fazer o resto do trabalho.

Coloquei o seguinte trecho em WP:Navbox: "Os artigos linkados na navbox devem ter uma certa proximidade de temas de modo que quem consulte uma das páginas possa ter interesse em consultar as outras. Deve ser evitado navboxes que juntem muitos temas diferentes apenas por estar em uma mesma região (principalmente quando a navbox resultante fica muito grande) pois, por exemplo, quem está no artigo de uma faculdade da cidade provavelmente não terá interesse em ler o artigo de uma das praias, q por sua vez terá pouco interesse em um dos templos da região. A menos que a navbox tenha um tema que permita essa mistura de temas (como, pontos turísticos), isso deve ser evitado." Não sei se ficou muito grande, e se refletiu bem esse consenso, mas aceita-se mudanças. Rjclaudio ^msg 15h00min de 21 de fevereiro de 2013 (UTC)

Está bom, apesar de quê o ideal era isto ser evidente e nem precisar ser incluído...--Mister Sanderson (discussão) 15h12min de 21 de fevereiro de 2013 (UTC)

Aos interessados neste tópico:Wikipédia:Páginas para eliminar/Predefinição:Navbox long. Cainamarques 20h47min de 8 de março de 2013 (UTC)

E também Wikipédia:Páginas para eliminar/Predefinição:Lecionários do Novo Testamento. Cainã Marques 00h58min de 8 de julho de 2013 (UTC)

[Ver]

Predefinições sem uso

Por favor, gostaria da opinião da comunidade sobre como proceder no caso desses dois exemplos de predefinição:

• Predefinição:Rios de Norfolk
• Predefinição:Shopping centers de Rondônia.

A primeira é cheia de links vermelhos, apenas um artigo existente e utilidade nula.

A segunda tem apenas um artigo listado. Não tem afluentes, mas por ora, suponhamos que tivesse esse único artigo como tal. Como proceder?

Acabar com os afluentes e mandar para eliminação? Ou esperar ter utilidade no futuro, a medida que os artigos forem sendo criados? Se as navboxes tem como função melhorar a experiência de navegação do usuário, estas certamentente não tem emprego, correto? Cainamarques (discussão) 05h47min de 23 de dezembro de 2012 (UTC)

As navcaixas são basicamente índices e por isso devem conter apenas artigos que existem, já que mais não seja porque a probabilidade dos artigos serem criados com outro título é muitas vezes elevada, induzindo o consulente em erro. Sempre assumi que essa era a única razão para elas terem essa coisa algo aberrante, mas muito útil, que é o link para saltar diretamente para a sua edição. Sou adepto do uso e abuso de links vermelhos em artigos e listas (quem duvidar pode conferir as minahs edições, inclusivamente em artigos destacados), mas acho que o seu uso em páginas "estruturantes", como navcaixas e desambigs deve ser evitado na esmagadora maioria dos casos, pela confusão que causam.

Se praticamente não há artigos sobre os rios de Norfolk, é ridículo existir uma navcaixa. E se só há um artigo sobre shoppings da Rondônia (que por coincidência é duvidoso que cumpre quaisquer critérios de notoriedade), também não faz sentido existir navcaixa. --Stegop (discussão) 06h18min de 23 de dezembro de 2012 (UTC)

Entendo, mas meu medo é este ou algo do tipo. Cainamarques (discussão) 07h55min de 23 de dezembro de 2012 (UTC)

A função dessas predefinições não é exclusivamente de índice para quem consulta a enciclopédia. Em primeiro lugar, ela serve de orientadora para os editores saberem quais artigos precisam ser feitos. Se alguém disser que as categorias e listas fazem essa função, digo que as listas tem a mesma função, mostrar o que falta ser feito, ao passo que as categorias só mostram o que já foi feito. Portanto, nunca é irrelevante uma predefinição que irá ajudar tanto os novos usuários como os velhos. Se os links vermelhos incomodam, por outro lado também serve de atração para novos editores que queiram azular os mesmos. Vendo por outro lado, nem todo novo usuário é familiarizado com predefinições e sem ela teria mais dificuldade em ajudar na edição, por não saberem fazer uma predefinição. Sou contra eliminação de qualquer coisa que oriente os editores. JMGM (discussão) 01h19min de 25 de dezembro de 2012 (UTC)

Duas opiniões totalmente contrárias, trago mais alguns casos para que deem seus pareceres:

• Predefinição:Campeonato Malaio de Futebol
• Predefinição:Cidades e vilas do Oblast de Ryazan
• Predefinição:Artes plásticas da Europa
• Predefinição:Faróis do Japão

Citação: Stegop escreveu: «Se praticamente não há artigos sobre os rios de Norfolk, é ridículo existir uma navcaixa», eu concordo plenamente, e concordo também com o que foi dito pela JMGM, talvez seja o certo ver caso a caso. Nestas 4 predefinições que trago, apenas a do Campeonato Malaio tem algum link azul, mesmo que um só. Nestes casos concordam que devem ser eliminadas? Cainamarques (discussão) 18h48min de 29 de dezembro de 2012 (UTC)

Eu talvez concordasse com a JMGM se estivéssemos a falar de listas, mas tratando-se de navcaixas (que pela sua natureza são, repito, índices), discordo frontalmente. Ter estas navcaixas (que se chamam "*de navegação*" e não de "orientação de editores") sob o pretexto de orientar os editores conduz a deorientar o consulente comum que não lhe passa pela cabeça ser editor. Aliás, em muitíssimos casos nem sequer se orienta o editor, antes se desorienta, pois há links outros títulos para temas que já têm artigos. O processo mais natural para a criação de artigos são os links vermelhos em artigos, pois estes sim estimulam a criação de artigos por quem se interessa pelo assunto; pelo contrário, os "amontoados" de links vermelhos só estimulam a produção em massa, em muitos casos, provavelmente a maioria, de mínimos cheios de erros feitos em cima do joelho. Quem produz bons esboços em massa não precisa destes amontoados de listas vermelhas para absolutamente nada, pois irá basear-se em fontes (externas, obviamente).

Todas as predefs acima devem também ser eliminadas. Stego (discussão) 19h53min de 29 de dezembro de 2012 (UTC)

Discordo veementemente da eliminação de predefinições, só sugere eliminação quem não faz ideia nenhuma do trabalho que dá para fazer certas predefinições. Quando muito, posso concordar em ocultar as que estiverem quase toda em vermelho, para serem usadas futuramente. Essas predefinições são totalmente válidas, de acordo com os princípios da Wikipédia, onde diz que deve ser um trabalho colaborativo, iniciado por um editor e editado posteriormente por centenas de outros. Se os links vermelhos incomodam, como disse acima, ao invés de colocar uma tag para eliminar, perca um pouquinho de seu valioso tempo e azule-os, ou não sabe fazer isso? Se não souber é só perguntar que terei o maior prazer em explicar. Trabalho colaborativo é o objetivo da Wikipédia, ou melhor sempre foi, só se agora, não é mais, e eu não estou sabendo. Eliminar trabalho que pode ser continuado por outros usuários no meu entender, é desrespeito aos editores que aceitaram editar uma enciclopédia que pode ser editada por qualquer pessoa, conforme o convite que é feito aos que não conhecem a Wikipédia. Estimula o desânimo, e desistência muito frequentemente. JMGM (discussão) 21h42min de 29 de dezembro de 2012 (UTC)

Citação: JMGM escreveu: «só sugere eliminação quem não faz ideia nenhuma do trabalho que dá para fazer certas predefinições». O meu trabalho em predefs pode ser conferido por qualquer um. E precisamente por isso, sei como dá trabalho fazer algo mais do que traduzir cegamente e de forma trapalhona predefs de outras wikis, nomeadamente deixando links em línguas estrangeira, não traduzindo documentação e não se dando ao trabalho de ver o que já existe feito. Não admira que a oposição venha de quem cria dezenas de predefs que ninguém sabe nem vai saber para que servem, que em muitos casos duplicam a função de outras. Trabalho colaborativo nada tem que ver com criar mal e argumentar que para quem acha isso errado tem a obrigação de corrigir, nomeadamente quando tentar aproveitar a porcaria que existe e é inútil dá mais trabalho do que criar do zero. Só mencionando alguns dos últimos exemplos de uma certa mentalidade: [1], [2], [3]. Stego (discussão) 22h03min de 29 de dezembro de 2012 (UTC)

Fico neutro.

Link vermelho pra título errado em navbox e em lista é fácil de ser resolvido já q os links são de um tema em comum, só olhar a categoria ou artigos relacionados, algo q não acontece com as desambigs. E mts casos nem há mts problemas com o título, é um título oficial ou padronizado, não há o que errar. Se uma lista não fosse apagada por ter títulos errados então uma navbox tb não seria.

Se os artigos são notórios e um dia serão criados, não vejo problema em deixar lá a navbox com os links vermelhos. Mas isso só se for óbvio q um dia os artigos serão criados, e q são notórios, só faltando o trabalho de criar. {{Campeonato Malaio de Futebol}} e {{Cidades e vilas do Oblast de Ryazan}} são elementos notórios (cumprem o CDN temático) e um dia existirão. Agora uma predef tipo {{Shopping centers de Rondônia}} q tivesse uma lista grande de shoppings tudo (ou a maioria) com link vermelho, aí já seria contra, por não poder dizer que todos ou a maioria dos elementos são notórios e um dia existirão. Ou seja, não dá para dizer que um dia essa navbox será útil para alguém.

E tb entra verificabilidade. {{Campeonato Malaio de Futebol}} poderia muito bem ser toda invenção, não há ref na navbox e nem há o artigo pro campeonato.

Rjclaudio ^msg 22h08min de 29 de dezembro de 2012 (UTC)

Até agora, estou sendo bem educada com V.Sª, mas peço que da próxima vez que estiver em uma discussão comigo, não leve para o lado pessoal e nem me ofenda e guarde suas críticas sobre minhas edições para um lugar apropriado e não numa discussão de artigo, que nada tem há ver com nossas diferenças. Caso não respeite esse meu pedido, serei obrigada a tratá-lo de acordo com vosso comportamento. JMGM (discussão) 22h39min de 29 de dezembro de 2012 (UTC)

PS: O primeiro link que citou, foi apenas uma ironia de minha parte, relacionada ao que escreveu no resumo de edição quando mexeu no artigo que ainda estava sendo editado, esse link você esqueceu de colocar este. JMGM (discussão) 22h46min de 29 de dezembro de 2012 (UTC)

Não fui quem fulanizou a discussão... E não confunda má educação com franqueza. Nem espere que escreva com tom sarcástico de de desprezo e os outros façam de conta que não o fez. E, claro, aquela tradução não foi feita nas coxas... --Stego (discussão) 22h49min de 29 de dezembro de 2012 (UTC)

┌─────────────────────────┘ Vamos por um momento fazer de conta que queremos uma wikipédia onde há o cuidado de evitar ser trapalhão quando isso é relativamente simples... Uma questao: não é suposto as navcaixas serem incluídas nos artigos que elas ligam? Então não será mais lógico deixar para quem faz essa inclusão atualizar a respetiva navcaixa? Repetindo-me, essa é a única razão que vejo para a existência do link inusitado "editar" nas navcaixas.

Uma coisa é assumir, pragmaticamente, que se queremos manter o projeto completamente aberto a contribuições de gente que está pouco familiarizada com os meandros esotéricos da codificação wiki e da estruturação de artigos ou que é simplesmente é trapalhona ou preguiçosa, não devemos implicar com links vermelhos nos artigos, pois o mais importante aqui é a informação que é adicionada. Isso eu nunca porei em causa! Mas coisas como navcaixas, que mexem com estruturação/organização e não com conteúdo, só têm sentido se forem feitas com algum cuidado, sob pena de fazerem exatamente o contrário do seu objetivo, que é organizar/indexar, causando a confusão no consulente; a este nada servem situações que "podem ser facilmente resolvidas". Stego (discussão) 23h11min de 29 de dezembro de 2012 (UTC)

Eu fiz o primeiro salvamento às 01h09min de 15 de dezembro de 2012 e sua intervenção foi feita às 02h49min de 15 de dezembro de 2012, como pode saber que eu ainda não estava editando o artigo? Por acaso está vigiando minhas edições? E o termo usado não seria ofensivo (tradução automática feita nas coxas) para uma senhora de 64 anos? É assim que você fala com as mulheres de sua família? E guarde a palavra trapalhona ou preguiçosa para os seus mais íntimos, porque isso não é palavreado para ser usado com nenhum editor e muito menos comigo. JMGM (discussão) 23h33min de 29 de dezembro de 2012 (UTC)

Voltando a discussão

Jurema, pode explicar o sentido dessa predefinição :Predefinição:Left60(sem afluentes) e por que a criou sem documentação?Cainamarques (discussão) 23h42min de 29 de dezembro de 2012 (UTC)

Como posso saber o sentido dessa predefinição? Ela foi eliminada na en e provavelmente a predefinição que a chamava também foi. Só que a que chamava foi eliminada aqui então essa ficou sem ligação nenhuma. discussão. JMGM (discussão) 00h19min de 30 de dezembro de 2012 (UTC)

O fato de não ter documentação, provavelmente a original também não tinha. Vai encontrar muitas que a documentação só foi colocada mais recentemente, ou ainda não foram colocadas. JMGM (discussão) 00h45min de 30 de dezembro de 2012 (UTC)

Você pode saber o sentido porque foi você que criou. Irei marca-la para eliminação se concordar. Quanto ao resto da discussão, eu gostei da opinião do Rjclaudio, se uma navbox tem links para artigos notórios que eventualmente serão criados, o certo é mante-la. Mas é complicado, primeiro, não é possível classificar com segurança artigos que ainda não foram criados como notórios ou não. E se uma navbox não tem afluentes, nem links para páginas existentes, só poderá ser encontrada fuçando nas Especial:Predefinições não utilizadas, tem um número impressionante de navboxes la. No final é a mesma questão, ainda não resolvida, que se põe se devemos eliminar artigos sem fontes ou com sérios problemas ou se devemos marcar tags de manutenção e melhorar os artigos. Navboxes só com liks vermelhos devem ser eliminadas, mas no caso da {{Cidades e vilas do Oblast de Ryazan}} e {{Faróis do Japão}}, elas merecem o esforço de extra da criação dos artigos. As predefinições que acreditar que não, enviarei para PE. Cainamarques (discussão) 02h29min de 30 de dezembro de 2012 (UTC)

Não é só pela Especial:Predefinições não utilizadas q se acha predefs sem afluentes, sempre há as categorias. Tem uma ideia excelente para se achar a {{Cidades e vilas do Oblast de Ryazan}}: procure na Categoria:Cidades do Oblast de Riazan. Alias, quando alguém for criar qualquer artigo dessa navbox, vai categorizá-lo nessa cat, e achar milagrosamente essa navbox, que já estará bem arrumadinha (talvez um ou outro ajuste, não sei) para ser usada. O mesmo pra Farois do Japão, está em 2 cats. Se a predef estiver nas cats q os seus artigos estarão, ela será achada. E sempre dá para transcluir a predef no artigo principal, em Oblast de Riazan#Cidades transcluir {{Cidades do Oblast de Riazan}}, olha que maravilha, teremos uma lista das cidades, e uma lista "bonita" por estar em forma de navbox, vários artigos fazem isso de colocar a navbox dentro do artigo (não sei se é correto, mas nunca teve discussão e já vi em vários artigos, acho q inclusive em artigo destacado, então tá valendo).

Citação: não é possível classificar com segurança artigos que ainda não foram criados como notórios ou não - para alguns casos dá, para isso que serve os critérios de notoriedade do tipo "todo X é notório". Se o CDN temático diz q toda cidade é notória, uma predef para as cidades do lugar mesmo se nenhuma tiver artigo está bem claro que todas elas são notórias pq todas elas cumprem o CDN temático. Pros outros casos que não dá, aí fiquei neutro, podendo até concordar em eliminar (manda pra PE).

Rjclaudio ^msg 02h47min de 30 de dezembro de 2012 (UTC)

Essa {{Cidades e vilas do Oblast de Ryazan}} acaba por ser um bom exemplo do problema que há nesse tipo de começar a construir a casa pelo telhado que é criar predefs para realidades que (ainda) não existem na nossa wiki: quem não sofrer de inglesite nunca vai transliterar os nomes russos daquela forma, a começar em Ryazan, que as wikis linguisticamente mais próximas da nossa transliteram (apesar do Y fazer parte do alfabeto deles) como Riazan. E será Riazan? Provavelmente o mais correro é Riazã... Ryazan é que quase certamente não é. Aí se quem criar os artigos usar outra transliteração não reparar ou, como é hábito, não se der ao trabalho de corrigir a navcaixa, quem se fiar nesta vai pensar que os artigos não existem e pode até resolver criá-los em duplicado.

Esta minha argumentação não é em abstrato; não formei a minha opinião teorizando, mas sim por constantemente me deparar com situações de falsos links vermelhos. E "estar valendo" agora porque é usual fazer não quer dizer que não se deva discutir se isso é o mais sensato a fazer. Quanto a mim, definitivamente não é! --Stego (discussão) 03h12min de 30 de dezembro de 2012 (UTC)

Gera várias complicações traduzir predefinições da wiki.en cujos artigos nem foram criados aqui, concordo com você, a dos Faróis do Japão é outro caso, acho difícil que algum editor irá se dedicar a criar esses artigos, mas é diferente quando a predefinição já foi criada, ai fica a nós a decidir o que fazer. Rjclaudio, você criou a {{Artes plásticas da Europa}}, não acha que foi mancada sua? Porque por mim irmão, eu mandava pra ER. Cainamarques (discussão) 03h30min de 30 de dezembro de 2012 (UTC)

A mudança do nome Ryazan para Riazan, foi feita em 2007 sob a alegação: Pedro Aguiar (discussão | contribs)‎ . . (30 bytes) (+30)‎ . . (Oblast de Ryazan movido para Oblast de Riazan: TRANSLITERAÇÃO EM LÍNGUA PORTUGUESA - não se usa "y", nem "zh", nem "sh", nem "w" nem dígrafos e letras inexistentes em nosso alfabeto). Gostaria de saber se essa alegação ainda é válida, uma vez que muita água já passou? A eliminação dessas letras em nomes estrangeiros ainda se aplica? JMGM (discussão) 19h46min de 17 de janeiro de 2013 (UTC)

[Ver]

Predefinições com cores

Detesto o uso destas predefinições com cores (ainda por cima com duas cores!). As predefinições na Wikipédia inglesa são muito mais organizadas (por exemplo esta). Proponha o uso de cores nas predefinições apenas nos clubes de futebol/hóquei em patins/basquetebol etc e nos cantores e bandas (o mais comum é o amarelo). O uso de imagens como aqui também polui bastante os artigos e gostaria de extingui-los. Andreazevedo (discussão) 09h21min de 17 de janeiro de 2013 (UTC)

Concordo com você, uma padronização é necessária nesse sentido. Acho muito feias e desnecessárias as predefinições com cores fortes e contrastantes, assim como os gifs de bandeiras que surgiram nas predefinições de portais que eu discuti em tópico recente. Jml3^msg 09h40min de 17 de janeiro de 2013 (UTC)

Notem também que a combinação de vermelho e amarelo usada na predefinição citada deixa a desejar em relação às recomendações para a acessibilidade do conteúdo de páginas WEB que dizem respeito ao contraste entre as cores do texto e do fundo. Outra discussão em que se reforçou a importância da acessibilidade foi a seguinte:

• WP:Esplanada/propostas/As páginas precisam ser acessíveis e semanticamente corretas! (13mai2012)

Helder 10h42min de 17 de janeiro de 2013 (UTC)

Não houve uma discussão acerca disso à relativamente pouco tempo? Já não me lembro se nos aproximámos de algum consenso... --Stegop (discussão) 14h52min de 17 de janeiro de 2013 (UTC)

Além das discussões da esplanada, e dos projetos, tb teve discussões em predefs. Teve tanta discussão espalhada, realmente não sei qual foi o resultado. Na Predefinição:Carnaval de São Paulo teve discussão e se decidiu remover as cores. Não sei qual o estado atual das coisas. Rjclaudio ^msg 15h01min de 17 de janeiro de 2013 (UTC)

Esqueci-me de mencionar que a minha proposta é apenas para as navbox. Peço desculpa. Andreazevedo (discussão) 19h06min de 17 de janeiro de 2013 (UTC)

Como ficou isso aqui? Com cores ou sem cores? Já estou perdido sobre isso. Rjclaudio ^msg 15h13min de 21 de fevereiro de 2013 (UTC)

Por mim fica sem cores, assim evitar de ter aqueles artigos parecendo uma árvore de natal. JAMAL 15h23min de 21 de fevereiro de 2013 (UTC)

Como a discussão "As páginas precisam ser acessíveis e semanticamente corretas" chegou a um resultado razoável, concluindo pela acessibilidade e moderação no uso das cores (ver e entender melhor na própria), e a atual discussão é só uma extensão daquela citada, creio que é importante encerrar aqui como cedência em benefício ao resultado já alcançado lá. Fecho portanto. Hallel^diga! 19h29min de 14 de outubro de 2014 (UTC)

[Ver]

Texto não linkado em navbox

Traduzi em Wikipédia:Predefinição de navegação uma parte das regras da wiki.en. Uma delas é "Texto não linkado deve ser evitado, podendo ser mais apropriado para o artigo ou uma lista." Já vi várias navboxes desse modo, até mandei a pouco tempo para ER uma de shopping q tinha todos os itens sem link (e até tentei linkar mas nenhum tinha artigo), provavelmente foram sendo removidos aos poucos conforme os artigos foram eliminados em PE ou ESR. Proponho então q isso vire uma regra. Uma expansão seria não ter link vermelho, mas na última discussão (recente, mes passado) não teve consenso, e teve pouca participação então deixa para depois. Ao menos texto sem link espero q tenha consenso. Rjclaudio ^msg 12h35min de 24 de fevereiro de 2013 (UTC)

Suponho que será feita excepção aos títulos/subtítulos. De resto, mais do que concordo e é prática comum; de outra forma seria um contrassenssp a uma caixa de navegação. Polyethylen (discussão) 12h47min de 24 de fevereiro de 2013 (UTC)

Concordo com a excepção aos títulos/subtítulos também. Poderia ser acrescentado ao texto embora talvez nem seja muito necessário. Cainamarques 13h45min de 24 de fevereiro de 2013 (UTC)

Desde que se proíba que virem "links vermelhos azulados na marra" com CSS (tornando-os indistinguíveis dos que apontam para artigos existentes, o que reduz a acessibilidade), concordo. Caso contrário, para não tirar o texto, transformarão em link (vermelho), mas para não deixá-los vermelhos colocarão <span>s onde não devem... Helder 14h05min de 24 de fevereiro de 2013 (UTC)

Concordo; e claro, não deve ser obrigatório ter links nos títulos e subtítulos (aliás, aí até é comum haver links desnecessários). --Stegop (discussão) 21h28min de 24 de fevereiro de 2013 (UTC)

• A proposta é mais sobre o conteúdo da navbox, a parte da navegação. Título / subtítulo não está incluído.
• Citação: Helder escreveu: «Desde que se proíba que os links vermelhos sejam "azulados na marra"» - a proposta, por hora, é só sobre texto não linkado, e não sobre links vermelhos. Pq já teve discussão recente sobre predef com link vermelho e não teve consenso, e sendo mt recente não vejo sentido em abrir de novo uma proposta pra isso. Mas se alguém apoiar remover tb links vermelhos só deixar seu comentário na proposta linkada lá no comentário inicial.
• Rjclaudio ^msg 00h40min de 25 de fevereiro de 2013 (UTC)

Obs.: o trecho seguinte está "compactado" de modo a despoluir visualmente o contexto da página toda.

[off-topic] Não me refiro a regulamentar a presença de links vermelhos, mas sim proibir o uso de CSS (ou pior, códigos obsoletos como o <font>) como artifício para fazer com que os links para artigos inexistentes (vermelhos por padrão) tenham a mesma aparência dos que apontam para páginas existentes (azuis por padrão). Se não for incluído na proposta qualquer proibição a isso, sou contra, pois veríamos coisas do tipo "colocar texto sem link é ruim, mas se inserir um link ele ficará vermelho, o que também é ruim, então vou azular com CSS...". Helder 11h38min de 25 de fevereiro de 2013 (UTC)

Texto azulado não é um texto com link, é um texto colorido, ou melhor, um texto colorido sem link. Texto azulado sem link será eliminado da mesma maneira. Não acho necessário especificar q não se pode azular. Ainda mais qnd é tão comum navboxes com texto (e links) branco, preto, vermelho, verde, rosa, azul. Aí já seria outra discussão. Rjclaudio ^msg 12h12min de 25 de fevereiro de 2013 (UTC)

Pelo visto isso não ficará claro se eu não mostrar um exemplo aleatório. Na Predefinição:Carnaval de Maricá, há um link com o texto "AESBM" e um link com o texto "Campeãs". São links de tipos diferentes, pois o primeiro aponta para uma página que não existe e o segundo para uma que existe. No entanto, foram colocadas tags <font> para deixá-los com a mesma cor (no caso, branca, em vez de azul), tornando-os indistinguíveis (ao contrário do que deveria ocorrer). O problema não é "azular", é fazer com que coisas diferentes sejam apresentadas como se fossem iguais. Helder 12h27min de 25 de fevereiro de 2013 (UTC)

Analogamente, na Predefinição:Futebol brasileiro, "Seleções nacionais" e "Campeonatos estaduais" estão com a mesma aparência, sendo que no segundo caso há um link mas no primeiro não. Helder 12h39min de 25 de fevereiro de 2013 (UTC)

Campeãs é um texto com link para uma página inexistente, então pode ficar. AESBM é um texto com link para uma página inexistente, então pode ficar pq é um texto com link. Só poderia remover AESBM se o link fosse considerado indevido, aí passaria a ser um texto sem link.

Como disse, cores do texto é outra coisa. Se links para artigo existente, links para artigo inexistente, e texto sem link não podem ficar com a mesma cor, isso deve estar escrito em WP:Acessibilidade e WP:Navbox já faz referência a acessibilidade qnd trata de cores. E como eu disse antigamente, eu concordo com essa ideia, apresente essa proposta para expandir WP:Acessibilidade e terá o meu apoio. Mas são propostas diferentes. Um tópico para cada proposta, por favor, principalmente qnd não são interdependentes, facilita acompanhar a discussão e depois achar nos arquivos.

A proposta aqui é de texto sem link. Se o texto é azul, vermelho, preto, branco, se está da mesma cor q um texto com link, não importa, não é uma regra sobre formatação de texto e de links, é uma regra sobre remover ou manter texto sem link.

Rjclaudio ^msg 12h42min de 25 de fevereiro de 2013 (UTC)

Citação: Helder escreveu: «para não tirar o texto, transformarão em link (vermelho)» - aí é outro ponto, sobre qnd se pode colocar link vermelho em navbox, algo q não teve consenso. Se quiserem salvar o texto colocando um link para um artigo inexistente, sem problema (se for um link para artigo já eliminado não pode colocar o link, creio já ter consenso pra isso), aí é outra discussão (a ser resolvida por consenso na página de discussão, ou por mediação, ou outra coisa qualquer). Rjclaudio ^msg 13h12min de 25 de fevereiro de 2013 (UTC)

Precisa avisar...

Precisa ter uma nota avisando que as navbox não são impressas nem exportadas para impressão posterior (através do links da esquerda "Imprimir/exportar") o que significa que informações importantes não devem figurar apenas em navboxes. Di ^msg 14h18min de 4 de janeiro de 2014 (UTC)

Collpased

Eu vi que houve uma discussão sobre collpasar ou não collapsar e alguns discordam que as navbox tenham que ser fechadas por padrão. Mas eu gostaria de retomar o assunto dizendo que normalmente quando se tem duas ou mais navcaixas no final do artigo, elas ficam collapsadas. Nunca vi alguém discordar do autocollapsed. Então eu gostaria de saber qual seria o problema de manter todas collapsadas, ter apenas uma navbox fechada não tem diferença nenhuma para ter duas fechadas. Manter aberta só porque ela é uma só não faz muito sentido. Net Esportes (discussão) 16h38min de 9 de janeiro de 2014 (UTC)

Sobre a (in)utilidade deste ensaio

Convido toda a comunidade a opinar sobre a validade, serventia, ou mesmo a necessidade de termos este ensaio, uma vez que, como iremos mostrar, ela não serve mais que a opinião de um editor.

Os ensaios sempre tiveram um papel de nortear nossas edições, sanar conflitos, orientar nas votações e pedidos de opinião - uma vez que foram na sua imensa maioria amplamente debatidos neste e noutros projetos. No caso desta, é seguida por mais de vinte Wikis...

Nesta eliminação, contudo, o administrador JMSilva encerrou-a declarando que todos os "Votos em Eliminar inválidos, como claro exemplos de TUDOOUNADA". Meu voto foi todo ele baseado no que orienta este ensaio aqui.

Questionado por mim, o referido administrador declarou que baseou tal opinião invalidatória com base no argumento: "ensaio é ensaio, como o nome diz. Como ressaltou o Érico: {{Citação|"O que esse ensaio diz ou deixa de dizer não é "regra" que deve ser "cumprida em todos os artigos". Ensaios não possuem validade, pois não foram aprovados pela comunidade"}}". Ou seja, vale o que acha o Érico; não vale um ensaio, nada que tenha sido elaborado comunitariamente. Mesmo que tenha tantos interwikis como este, temos de nos nortear agora na opinião do Érico (foi o nome que ele citou, mas é possível que outros detentores de opinião superem nossos ensaios - me é impossível saber).

Assim, trago aos editores da Wikipédia as seguintes perguntas:

1. De que vale este ensaio, se opiniões particulares a superam, para um administrador?
2. Se o "ensaio é ensaio", e não vale nada, então por quê os temos? Para que serve este aqui? Como saberemos quais opiniões valerão para os administradores, se nem os ensaios valem nada?
3. Vale a pena lermos este ensaio? Para usarmos onde, se a opinião de alguém o supera tão facilmente que basta dizer que "ensaio é ensaio"?
4. De que adiantou anos de debates para fazermos este ensaio? O que pensam aqueles que aqui trabalharam, diante da completa inutilidade do mesmo?

Grato aos que puderem me esclarecer. André Koehne (discussão) 21h46min de 4 de novembro de 2017 (UTC)

PS: Mesmo sem me citar na página de discussão de outro usuário, vi hoje que o administrador Érico (que deixo também de citá-lo na forma devida) respondeu-me dizendo que é isto: ensaio vale menos que a opinião dele próprio. Acredito que, se esta for a opinião dominante, é preciso que se coloque no aviso do topo de cada ensaio (sim, na predefinição {{Ensaio}}) que nada do que se diz ali é para nada... André Koehne (discussão) 21h46min de 4 de novembro de 2017 (UTC)

Precisa de um chilique desses, André Koehne? Achei muito feia sua reação. Ensaio não foi aprovado pela comunidade, logo, não é uma regra a ser seguida: segue quem quer. Ter interwiki não significa que outras wikis sigam, como você erroneamente afirmou. Se fosse para ser seguido, alguém teria levado à Esplanada, e conseguido aprovar para que se tornasse uma recomendação ou política.--Mister Sanderson (discussão) 22h20min de 4 de novembro de 2017 (UTC)

Esclarecendo porquê achei sua reação feia, antes que me questione: aqui não é o local certo para pedir revisão de ação administrativa. Ficou sem foco o texto. Você está querendo realmente definir se ensaios têm utilidade? Está querendo elevar esse a recomendação? Parece que está apenas querendo jogar as pessoas contra os admins envolvidos.--Mister Sanderson (discussão) 22h23min de 4 de novembro de 2017 (UTC)

Desconheço o status do Ensaio, mas, se não passou por discussão pública e consenço, oq temos que fazer com pequenas coisas (pq somos novos?), creio que não deve ter validade nenhuma além de orientação a ser ou não seguida por decisão de cada um.--Fonseca 22h47min de 4 de novembro de 2017 (UTC)

Ensaios que não foram aprovados pela comunidade não tem força, o que não significa que não tem utilidade. São duas coisas absolutamente diferentes! A ONU não tem força para fazer quase nada, o que não significa que ela não seja útil para quase nada. No caso em questão, o ensaio pode ser utilizado para esclarecer como um editor pensa e qual é o raciocínio que ele seguiu, o que encurta muito o processo de discussão. Mas se o desejo é que o ensaio se torne lei ou recomendação, aí só levando à comunidade para aprovação. José Luiz ^disc 00h33min de 5 de novembro de 2017 (UTC)

Comentário Existe um motivo pra que no cabeçalho do ensaio esteja {{Ensaio}} em vez de {{Política oficial}} ou {{Recomendação}}. O que não faltam na Wikipédia são ensaios que contradizem um ao outro, então não faz sentido dar predileção apenas àqueles com os quais concorda. --ArgonSim (discussão) 01h05min de 5 de novembro de 2017 (UTC)

@MisterSanderson:, @Felipe da Fonseca:, @Jbribeiro1:, @ArgonSim: Pessoal, tinha jurado a mim mesmo apenas ouvir o que têm a dizer, mas parece que realmente não fui compreendido... A questão não é se ensaios são bons, ruins; nem tampouco revisar atos administrativos. A questão é: se citar um ensaio torna inválida uma opinião (fixem-se nesta palavra: opinião), então para que eles servem - se nem para referendar uma opinião eles servem? Se não servem nem para validar a opinião de alguém (notem, não é nem para ser majoritária tal opinião: o caso concreto mostra isso e ninguém está indo contra a ação de discordar do ensaio, ou mesmo discordar da opinião vencedora).
Por favor, respondam apenas a isso, repetindo de novo e de novo: se nem para validar uma opinião serve um ensaio, então... para quê os temos? Muitos deles (e o caso deste aqui que citei é lapidar disto) foram debatidos, traduzidos, melhorados, etc e nem isto bastou para que a opinião nele fundamentada tivesse qualquer serventia. Foi anulada. Não seria, então, o caso de respeitando a decência - apagarmos tais coisas inválidas? Ou, então, pelo ao menos, avisar de sua inutilidade com a devida clareza para que gente como eu que, inutilmente, os leia à procura de bases objetivas para opinar, sem que tenha de ver suas opiniões invalidadas pura e simplesmente? Grato se puderem superar os detalhes do caso concreto, e opinar naquilo que estou, de fato, questionando: a inutilidade dos ensaios, a falta de aviso dessa inutilidade, a perda de tempo de editores em lê-los acreditando num aviso falso no topo da página, contrariando mesmo o que falaram acima... André Koehne (discussão) 04h39min de 5 de novembro de 2017 (UTC)

Caro André Koehne, neste caso, terei que concordar com MisterSanderson: vc está forçando uma resposta, a resposta que vc deseja. Diferentemente daquilo que vc alega, a questão foi sim respondida em termos gerais: a questão da importância do ensaio foi tocada por todos que comentaram. Agora, se vc quer uma resposta sobre a utilização ou não dela, no caso concreto, para (indevidamente ou não) afastar seu voto (opinião), então temos uma outra questão completamente diferente e diz respeito ao acerto ou não do adm no caso particular. Creio que ninguém irá dizer que citar um ensaio ou qualquer outra coisa invalide o voto (opinião), resta saber se foi realmente isso que o adm fez, questão em que eu, particularmente, não vou entrar.--Fonseca 12h06min de 5 de novembro de 2017 (UTC)

@Felipe da Fonseca:... Jesus... Em que momento você leu que eu quero isto? O que quero (sabe, é meu direito) é saber antes o que posso ou não fazer neste projeto. A constatação foi de que não posso usar ensaios como argumentos. Vocês todos se esquivam, por acharem que estou a criar caso com administrador (repito, não estou; se estivesse, eu mesmo pediria meu bloqueio por abusar do espaço público!) de opinar diante do óbvio (leia o caso todo de novo, se ainda tiver dúvida):

1. Diante da inutilidade dos ensaios, mesmo quando construídos coletivamente, devemos colocar um aviso disto na predefinição {{Ensaio}}.
2. Este "aviso" deve ser bastante claro, para que editores não percam mais seu tempo com eles.

Pode, agora, opinar sobre isso? Todo o caso é para saber se vamos ou não avisar da inutilidade dos ensaios! Grato. André Koehne (discussão) 13h01min de 5 de novembro de 2017 (UTC)

Respondendo objetivamente: acho que um argumento bem elaborado como o ensaio, eventualmente (não sei) construirdo por mais de uma pessoa, é um argumento que deve ser considerdo até mais do que os outros para instrução, mas o mesmo tanto para votação ou consenso. Dito isto: pelo que pude entender das discussões, ensaios não são inúteis, só não possuem status de norma (não precisam ser seguidos). Quanto a indicar ou não seu status, me abstenho, uma vez que é questão puramente adm.--Fonseca 13h08min de 5 de novembro de 2017 (UTC)

Tem que haver uma certa coerência, sempre vi ENSAIO ser citado sempre que se dizia que determinado texto era "apenas um ensaio". A propósito, sou a favor de revogar ENSAIO, mas enquanto ele estiver la, deve valer. Por outro lado, eu teria finalizado Wikipédia:Páginas para eliminar/Predefinição:Dilma Rousseff também como Manter, não por que Wikipédia:Predefinição de navegação é apenas um ensaio, mas porque a discussão não demonstrou de que forma a Predefinição:Dilma Rousseff violaria tal ensaio.  -- Leon saudanha 22h06min de 5 de novembro de 2017 (UTC)

Concordo em revogar ENSAIO, principalmente no que diz respeito ao seguintes trechos dele: Citação: Temos políticas que nos dizem o que fazer e porquê fazê-lo, e recomendações que nos ajudam a como fazê-lo. Citação: Na maioria dos casos[, os ensaios] estão escritos de acordo com as políticas e recomendações, pelo que simplesmente rotulá-los de "apenas um ensaio" pode ser falso. Segundo eles, espera-se que um ensaio válido siga uma política vigente na Wikipédia em português; citar essa determinada política, portanto, tem igual ou maior poder argumentativo que tê-la "terceirizada" em um ensaio. Existem inúmeros ensaios que contradizem um ao outro, como é o caso de Wikipédia:Não destrua a casa enquanto ela está sendo construída, Wikipédia:Uma casa incompleta é um verdadeiro problema e Wikipédia:Não espere que a casa se construa sozinha. Em uma discussão de eliminação, segundo ENSAIO, os três deveriam ser levados em conta, ainda que digam coisas completamente diferentes. Assim, faz muito mais sentido pautar-se unicamente em políticas vigentes, já que, na melhor das hipóteses, um ensaio válido irá simplesmente repetir o que uma política já diz. --ArgonSim (discussão) 15h29min de 8 de novembro de 2017 (UTC)

Eu nem lembrava de ENSAIO, mas sim de POL. Não vejo nenhum problema, em nenhum dos dois casos. ArgonSim, ENSAIO diz apenas que, ao invés de dizer que "é apenas um ensaio", o editor deve argumentar para o caso específico que está em discussão, dado que o ensaio sumariza uma opinião mais genérica, apenas. De fato, dizer "é apenas um ensaio" não é um argumento válido numa PE. Ok, é um ensaio, mas e aí? O que ele diz faz ou não faz sentido nesse caso? Por quê? É esse o espírito da lei de ENSAIO, ao meu ver. Concordas? Saturnalia0 (discussão) 00h59min de 10 de novembro de 2017 (UTC)

Apoio o André Koehne. PS: Vide discussão abaixo. Em minha opinião, o consenso foi mal auferido pelo JMSilva. O André não apenas argumentou que havia um ensaio dizendo tal e qual, ele explicitamente iniciou uma discussão sobre o caso específico do artigo proposto para eliminação, não indo contra ENSAIO, e cumprindo com POL. Saturnalia0 (discussão) 00h59min de 10 de novembro de 2017 (UTC)

Reitero que argumentação do Saturnalia0 se torna incompleta, simples fato de que não leu completamente a seção WP:APDE/POL, onde deixa claro que os ensaios devem ser debatidos nos argumentos e políticas da Wikipédia, como disse anteriormente, outro ensaio muito conhecido e amplamente aceito na PEs que é o WP:SFFSVSA, é baseado nas políticas e foi batido a respeito, e este ensaio das navegações não. Não foi mal auferido, espero que possa ler:

Citação: No entanto, deve se ficar claro que não é porque é ensaio que a página se torna um argumento válido. Ensaios podem ser somente a opinião unilateral de um grupo reduzido ou de um único usuário, portanto, deve ser discutido se o ensaio é válido ou não, a partir do debate de outros argumentos e políticas.

E foi por esta questão que o Sr Érico referiu-se no sentido de que não era válido. Marcos Silva ✉ 01h06min de 10 de novembro de 2017 (UTC)

Estou de acordo com você que, porque é um ensaio, não é necessariamente válido. A questão que pretendi levantar foi justamente o contrário, como traz ENSAIO: Não é porque é um ensaio que é inválido, como o Érico afirmou. Em resposta ao Érico, o André se propôs a debater o conteúdo do ensaio, e não obteve resposta. Sendo assim, temos uma oposição válida per POL. Com oposição válida e não contestada, não há consenso. Ou estou enganado? Saturnalia0 (discussão) 01h13min de 10 de novembro de 2017 (UTC)

Como disse, acredito que ensaios são argumentos baseados em pontos de vista de grupo, e por isto podem ser baseado em políticas ou não, que poderão no futuro serem aceitas. Como infelizmente este ensaio não teve embasamento em alguma política objetiva, não posso aceita-la pelo simples fato de não tida indo em consenso anteriormente, daria uma brecha ainda maior para uma RAA. Agora devemos sim debater sobre este ensaio e vários outros, e me disponho a isto. Marcos Silva ✉ 01h18min de 10 de novembro de 2017 (UTC)

Concordo com você até o seguinte: Agora devemos sim debater sobre este ensaio e vários outros, e me disponho a isto. Isso deveria ter sido discutido na PE quando o André se propôs a fazê-lo - e o Holy Goo insistiu. Dito isso, e relendo toda a discussão agora, talvez a argumentação do André tenha sido de fato insuficiente per POL pois, apesar dele mencionar de que maneira o ensaio se aplica ao artigo, ele não menciona um argumento independente do ensaio ou baseado em alguma outra política como requer POL. Levando isso em consideração, apesar de eu continuar achando a argumentação utilizada para o encerramento da discussão estranha, vendo os argumentos expostos pelo JMSilva acima e comparando com mais cuidado a opinião do André com o que cita AEDE/POL, creio que eu tenha me precipitado em dizer que o consenso foi mal auferido - mas, acima de tudo, continuo com a opinião de que a oposição do Érico é inválida. Em suma: Invalidar a oposição do André por TUDOOUNADA como foi feito no encerramento da PE me é estranho. Se, por outro lado, era para estar implícito a invalidez do argumento do André através a resposta do Érico a ele, então o encerramento foi sim equivocado, pois a resposta do Érico é, até onde posso ver, ENSAIO em todas as letras. Saturnalia0 (discussão) 01h51min de 10 de novembro de 2017 (UTC)

Comentário Complementando aqui, entendo perfeitamente o ponto de vista do usuário e colega André Koehne e peço desculpas por não entrar no debate. Sim, de fato é constrangedor que percamos o tempo baseando em algo que não seja útil ou é útil. Não é questão de deixar claro na predefinição, mas sim que o ensaio pode ser utilizado sim, desde que ele se baseia na política de recomendações, por isto que invalidamos muitos dos ensaios, pelo simples fato lógico de que, ele pode ter sido criado de imediato apenas para aferir uma opinião, o ensaio pode ser como seu argumento, muitas vezes alguns citam ensaios para facilitar a não-repetição de argumentos, porém estes ensaios devem ser baseado na política para serem aceitos na PEs, e você pode perguntar, porque não está na predefinição de ensaio??? Pelo simples fato de que a predefinição das PEs deixa claro que os argumentos devem ser válidos pertinentes, com base no WP:APDE. Por isso é meio inútil isto, mas com todo respeito a sua contribuição enorme, como você deixou claro anteriormente, sei que não tem nenhum embasamento de querer me atacar ou reverter, mas deixar claro e objetivo, e respeito seu espaço fundamental de argumentar e de questionar, pois só assim avançamos. Marcos Silva ✉

JMSilva, obrigado pelo que falou. Se outros editores demoraram a perceber que não se tratava de um ataque ao administrador, fiquei realmente preocupado que fosse levado em conta de stalking meu... Felipe da Fonseca, você disse algo totalmente fora daquilo que se pratica deveria praticar aqui: Citação: Felipe escreveu: «Quanto a indicar ou não seu status, me abstenho, uma vez que é questão puramente adm.»; pelo que sei nós editores fazemos as regras e nós dizemos como, quando e onde elas devem ser cumpridas por todos, inclusive os administradores...
Vemos que a questão realmente não está clara; Quando o Marcos cita a WP:APDE, por exemplo, não vejo que aquilo ali invalide numa discussão onde se procura saber o que pensa majoritariamente a opinião da comunidade num caso concreto o uso de um ensaio, como tínhamos feito (lá está bem dito: "Este rol não é taxativo, ou seja, conforme o caso, podem surgir outros argumentos pertinentes"). Aliás, poderíamos não ter usado qualquer ensaio, e isto não invalidaria a opinião: o caso concreto é levado a PE por alguém julgar não ser cabível num artigo da Wiki e a situação não está clara, daí muitas vezes se aplicar a analogia com casos anteriores, ou mesmo argumentos inéditos por se tratar de alguma situação inteiramente nova (não foi este o caso, claro, é só uma possibilidade). Por isto as opiniões são pedidas, o debate é feito... Ao desconsiderarmos, como opinião, o uso de um ensaio (mesmo, como disse acima o ArgonSim, tenha outro ensaio contraditório), deveria haver uma justificativa para o caso de se invalidar tal opinião... Nesta coisa que o Marcos falou de "avançarmos", entretanto, creio que já seja de consenso que a informação contida na {{Ensaio}} precisa ser modificada. Alguém tem uma proposta de como seria isso?... (peço desculpas a todos por vir pouco esses dias, tenho editado em brechas cada vez menores de tempo - talvez por isso tenha ficado meio confusa minha fala no início). André Koehne (discussão) 10h52min de 10 de novembro de 2017 (UTC)

Abstenção é um direito. Fiz não porque achei que não poderia comentar, mas porque achei o tema desinteressante e indiferente para mim.--Fonseca 12h57min de 10 de novembro de 2017 (UTC)

Felipe_da_Fonseca, abstenção é um direito. Dizer que "é assunto administrativo" é dar opinião. Ou se abstém... ou dá opinião; muito estranho vir se "abster" de opinar, e opinar... André Koehne (discussão) 01h47min de 11 de novembro de 2017 (UTC)

Discordo veementemente Ensaios são um punhado de baites que entulham o, já inchado, domínio de projeto. Nada a mais. Nada a menos. Já argumentei, no passado, para que fossem deportados para o domínio de usuário. Att --Usien6 19h34min de 27 de novembro de 2017 (UTC)

Converter este ensaio para recomendação

Estas predefinições encontram-se espalhadas por milhares de artigos aqui. Apesar deste ensaio explicar a forma como devem ser utilizadas, observa-se que não existe coerência no seguimento das itens expostos por parte de vários editores. Desde a inserção de imagens indevida até à utilização destas caixas de navegação como listas sem artigos, tudo acontece por aqui. Esta minha proposta advém desta discussão em que editores alegam o facto de, como se tratar de um ensaio, não existir obrigatoriedade em cumprir o que se encontra aqui estabelecido. Desde já agradeço a manifestação sobre este assunto. Sds., Vanthorn^® 20h38min de 19 de abril de 2019 (UTC)

Chamo para a discussão, editores que se pronunciaram anteriormente sobre esta predefinição como: @Conde Edmond Dantès:, @Pedrohoneto:, @GRS73:, @Tks4Fish: e @Luan:. Vanthorn^® 01h08min de 20 de abril de 2019 (UTC)

Chamo igualmente para esta discussão, editores activos que participaram em Wikipédia:Esplanada/propostas/Texto não linkado em navbox (24fev2013) - @JMagalhães:, @Cainamarques:, @He7d3r:, @Stegop:. Vanthorn^® 20h45min de 20 de abril de 2019 (UTC)

Concordo O facto deste ser um ensaio não deveria significar opcionalidade, principalmente para iniciar uma disputa editorial. O ponto principal deste ensaio em específico é que possui três propostas consensuais, esta por exemplo. Sendo assim, não foi escrito seguindo uma opinião qualquer, mas segue um consenso já estabelecido, sendo que já considero que o texto em pauta como uma recomendação. Edmond Dantès ^{d'un message?} 05h00min de 20 de abril de 2019 (UTC)

Concordo com a transformação em recomendação e com o que Conde falou. E vale lembrar que ser ensaio não automatiza o descumprimento, mas o descumprimento deve estar baseado em argumentação sólida tal qual a do ensaio (WP:SOENSAIO). --Luan (discussão) 07h14min de 20 de abril de 2019 (UTC)

Concordo --Stegop (discussão) 23h30min de 20 de abril de 2019 (UTC)

Concordo Não tenho muito a acrescentar ao que já foi dito em cima. JMagalhães (discussão) 01h05min de 21 de abril de 2019 (UTC)

Concordo per Conde e Luan. —Thanks for the fish! ^{talk•contribs} 17h42min de 21 de abril de 2019 (UTC)

Convido João Justiceiro, que estava numa das discussões mencionadas e não foi marcado. Jardel.[5.250] ^d 04h49min de 21 de abril de 2019 (UTC)

Comentário A origem desta proposta se baseia no fato de como o usuário foi confrontado acerca do uso de um ensaio como política oficial. Portanto, trata-se mais de querer impor na marra algo que não necessariamente deveria ser uma regra do que uma coisa realmente relevante a se discutir. Isto posto, há múltiplos usos de predefinições, como por exemplo em conjuntos musicais. Se nem todos os membros de um conjunto possuírem um artigo próprio, como fazer para citar a todos, sendo que todos possuem a mesma relevância? Desde já, eu alerto aos senhores que a política oficial (também WP:CONSENSOLOCAL) manda resolver questões como essa através da Esplanada ou nos Pedidos de opinião. Aqui só se estabelecem consensos em relação ao conteúdo do artigo. João Justiceiro (disc • cont) 05h16min de 21 de abril de 2019 (UTC)

Bem lembrado. Discutindo aqui só vai fazer com que apenas usuários selecionados apareçam pra opinar e não a comunidade em geral que pode discordar da proposta. Jardel.[5.250] ^d 05h49min de 21 de abril de 2019 (UTC)

Feito: Wikipédia:Esplanada/propostas/Converter WP:NAV em recomendação (21abr2019). Vanthorn^® 20h05min de 21 de abril de 2019 (UTC)