Wikipédia Discussão:Projetos/Padronização/Arquivo/4

Predefs obsoletas e depreciadas

A mtos meses que tenho esta listinha, mas nunca coloquei na esplanada com medo da demora... me convidaram pra cá e fico mto feliz que este wikiprojeto se preocupe com isto.

Quero dizer que odeio o mau hábito wikipedico de depreciar as predefs ao invés de atualizá-las, pq depois ficamos como estamos, com um monte de predefs inúteis e desnecessariamente duplicadas.

Por isto acredito que o primeiro passo seria acabar com a Categoria:!Predefinições depreciadas e começar a não mais depreciar, mas sim atualizar as predefinições.

Peço desculpas pq eu não entendo nada de códigos e tal (não posso eu mesmo fundir/criar/etc), pretendo participar mais assim mesmo, passando o abaxi pra frente, como faço testando o código do Rjclaudio 'sugerindo e detectando' :)

{{Rec}} - {{Reciclagem}} - {{Fontes primárias}} - {{Fpr}} - {{Sem-fontes}} - {{S-fontes}} Só pra exemplificar, pra que? Ou uma ou outra forma. Novatos? Faz assim: se usar a predef que depende de subst: sem o subst:, o artigo vai pra uma cat oculta, e de tempos em tempos um bot percorre ela adicionando o subst:. Claro que isto é para a exceção, temos que deixar muito bem claro na página que é obrigado usar o subst:.

{{Move}} Necessidade? Não é usada desde 2007 (qdo foi criada)...

{{Adj}} - {{Conteúdo parcial}} Fundir

{{tl|Apagar vaidade}} - {{tl|Apagar-ub}} Ver aqui. Desnecessários e não usados, pode-se usar {{tl|apagar}}, redundantes. Apagar ambas.

{{esr}} - {{esr2}} Pq duas? Necessidade tecnica? Se não, apagar a esr2 e deixar só a esr.

{{er}} - {{er1}} Pq tem a er1 e ela se tornou a padrão? Sugiro inverter, já que er é redirect, é bem mais lógico usar er do que er1. Só não faço eu mesmo pq tem que modificar fastbuttons e documentações (sem contar as páginas já em ER), senão já fazia.

{{VDA}} - {{Copyright}} - {{Copyright disc}} - {{Copyright susp}} - {{Copyright2}} - {{VDA3}} Este é um dos exemplos mais absurdos, pra que tudo isto? Sugiro apagar tudo e deixar só {{VDA}} com o conteúdo de {{VDA3}}. Não sei se {{Copyright2}} é necessária (parece que é, VDA3 chama ela), se for, coloca o conteúdo em {{Copyright}} e apaga {{Copyright2}} (não tem pq ter o 2 no nome).

{{Suspeito}} - {{Suspeito1}} - {{Suspeito2}} Pra que? Sugiro colocar o conteúdo de suspeito1 em suspeito e apagar o resto.

{{tl|Apagar}} - {{tl|Apagar4}} - {{tl|Novoapagar3}} Não entendi ainda o que faz a novoapagar3, se for o mesmo que apagar e apagar4, fundir as novas opções úteis e apagar ela. Desnecessário 3 predefs pra mesma coisa.

(com a ajuda do Daemorris) {{TA2}} - {{Em tradução}} Fundir e apagar uma delas

(caso difícil, e ao que parece resolvido nesta seção. Sim, resolvido ali) {{Dni}} - {{Dnibr}} Não adotamos o AO (letras dos meses minúsculas)? Então não tem pq estas duas, apagar Dni e mover Dnibr para Dni ou Idade. E aí, o AO não está vigorando? Apaguem a {{dni}} e movam {{dnibr}} para lá, então um bot corrige os afluentes.

(fundidas na dni) {{Dnsi}} - {{Dnsibr}} Mesma coisa que acima.

(antes de apagar tem que derrubar a votação que criou elas, ver Wikipedia:Esplanada/geral/Biografia em página de usuário (22fev2010)) {{Biografia sem relevo enciclopédico}} - {{Vaidade2}} - {{Vaidade}} - {{Bio-sem}} Desnecessárias, desconhecidas e portanto inúteis, quando uma página vai para PE, ESR ou ER, já existe o aviso padrão, e tem {{autobiografia}} se quiser avisar sobre autobiografias. Apagar todas.

• {{Pg-banido}} Ver aqui tbm. Não seria melhor neste caso criar uma regra ao invés desta outra predef?

• (ver Wikipedia:Esplanada/propostas/Predefinições de tradução feita (17abr2010)) {{Tradução de}} - {{Traduzido}} - {{Tradução integral}} - {{Página Traduzida}} - {{Tradução-parcial}} Fundir de vez e apagar uma delas (sim, eu tbm não gosto nada de redirects, especialmente de predefs)

• {{Referência a livro}} - {{Ref-livro}} - {{Cite book}} Fundir

• {{ENref}} - {{ESref}} - {{FRref}} Desnecessário, vamos criar uma predef pra cada wiki? Já existe {{Tradução/ref}} que serve para todas.

• {{ProtegidaER}} - {{ProtegidaER2}} - {{Previne recriação}} - {{ProtegidaPU}} Desnecessárias, e nem são usadas, já temos os avisos do domínio mediawiki para isto.

• {{Idade}} - {{Idade2}} Apagar. Dei um jeito na idade2, falta a idade que não sei como fazer. Ela tem uns 3.000 afluentes, fazer na mão com o AWB vai levar o ano todo, e não sei se um bot pode fazer (substituir ela pela {{dni}}), parece um pouco complexo (fora que qdo corrigi os afluentes de idade2 vi vários artigos com a idade nesta predef errada, e tinha que corrigir). Então é melhor fazer na mão de pouco em pouco... peço ajuda.

• Aqui, na parte das imagens, não teriam mais predefs para apagar? Tem predefs de eliminação de imagens, só que não hospedamos mais imagens aqui faz tempo. Mesmo que o fair-use (ou seja lá que nome tem isso) seja implantado aqui elas não fariam sentido, o texto seria diferente, assim como o nome das predefs. Sugiro apagar (pelo menos as de eliminação, as outras não sei se teria problema, se não tiver vão pro limbo tbm).

• {{link}} - {{link2}} - {{link e data de acesso}} Fundir, é só adicionar os parâmetros (de preferência de forma opcional), não precisa de predefinições diferentes.

• {{Língua}} - {{Iso2Lang}} - {{Info/Língua/genetic2}} Não sei bem se estão repetidos ou podem ser fundidos.

Vejo que tomaram providencias enquanto eu estive fora, mto bom!! Mas tem umas coisas que não entendo: {{suspeito1}} chama {{suspeito}}, {{VDA}} (antes VDA3, valeu o Rj pelo ajuste!!) chama {{Copyright2}}, e pq?, é mesmo necessário uma chamar a outra? Não daria pra colocar tudo nelas, tipo {{suspeito}} e {{VDA}} já terem tudo, sem precisar chamar?--Lépton ^✉ 01h11min de 26 de janeiro de 2010 (UTC)

Uma tem que chamar a outra. Qnd as predefs usam parâmetro de data, sempre precisam de subst para colocar a data correta. E se ficar tudo só em uma predef, qnd colocar o subst o código no artigo vai ficar monstruoso, ocupando tamanho, dificultando leitura, e mais fácil de alguém vandalizar sem ser percebido. Por isso chama outra predef, assim no subst na página só vai aparecer uma linha, ao invés de 10 ~ 20 linhas de código. Rjclaudio ^msg 11h14min de 26 de janeiro de 2010 (UTC)

• Isso vale para VDA, Esr, Apagar, Sem-fontes, Wikificar, etc.
• Eu colocaria no padrão as predefs de manutenção {{Reciclagem}}, {{Sem-fontes}}, etc. A predef q usa subst fica sem o número, e a que é chamada fica com o nome e o número 2.Nenhum novato vai usar subst:Fpr, mas pode usar subst:fontes primárias (é mais fácil ele usar subst do q ele colocar a data, já que mts vezes acaba colocando a data errada - com o dia mês ano).
• Rjclaudio ^msg 12h08min de 26 de janeiro de 2010 (UTC)

Blz, se é necessário duas predefs então ok.
Será que não seria possível o código adicionar o subst automaticamente? Tipo simplesmente digitar {{sem-fontes}} e já adicionar subst. Acho que já é pedir demais, se fosse possível já teriam feito....--Lépton ^✉ 16h06min de 26 de janeiro de 2010 (UTC)

Se for possível adicionar subst a partir de uma transcrição (usando {{}}), por favor me avisem, isso seria muito útil! O mais próximo que eu conseguir foi um código para detectar quando é utilizada transcrição ou substituição, vocês podem ver na {{Padronização/Convite}}. Daemorris ^discussão 00h33min de 30 de janeiro de 2010 (UTC)

Tô mandando brasa nas predefs obsoletas e redirects nonsense! Façam o mesmo!! hehehe.--Lépton ^✉ 04h00min de 2 de fevereiro de 2010 (UTC)

Com relação à {{idade}}, se o objetivo é substituí-la pela {{dni}} no comportamento também, é só criar um argumento longo e desencorajador que só funcione como "antigo_método_que_ativa_o_método_ainda_mais_antigo=eu_realmente_quero_o_antigo_método_que_ativa_o_método_ainda_mais_antigo" para que a {{dni}} se comporte exatamente como a {{idade}} se comportava, e jogar os artigos numa categoria temporária e oculta Categoria:!Artigos dependendo da idade (ta, o nome da categoria pode melhorar), e daí usamos vários AWB e robôs para fazer as edições (cerca de 3 mil) em conjunto. Que tal? Daemorris ^discussão 13h42min de 3 de fevereiro de 2010 (UTC)

Meu objetivo não era substituir tbm no funcionamento, mas simplesmente acabar com a pobrezinha!! Não vejo como o comportamento da {{idade}} pode ser útil hoje nos artigos, se for o caso deve ter alguma 'palavra mágica' que faça o mesmo.

Penso que {{dni}} abranger {{ani}} seja útil, mas não {{idade}}.--Lépton ^✉ 02h16min de 4 de fevereiro de 2010 (UTC)

Pera aí, pelo que vi {{dni}} já faz a mesma coisa que {{ani}}!! Daemorris discorda?--Lépton ^✉ 02h36min de 4 de fevereiro de 2010 (UTC)

A {{ani}} é mais precisa que a {{dni}} (acho que é minha culpa) e os parâmetros são invertidos, mas no resto, são praticamente idênticas. Daemorris ^discussão 13h03min de 4 de fevereiro de 2010 (UTC)

E você discorda de eliminar a ani? Se fazem a mesma coisa não tem pq ter duas, na minha opinião.--Lépton ^✉ 21h54min de 4 de fevereiro de 2010 (UTC)

Discordo, há mais vantagem em mantê-las separadas, pois os objetivos são diferentes, embora elas o alcancem da mesma forma. E eu sou 100% ano|mês|dia. Daemorris ^discussão 23h46min de 5 de fevereiro de 2010 (UTC)

Sim, tem propósitos diferentes, mas não vejo problemas nisso. Já eu sou o oposto, detesto este padrão que vc falou, sou bem mais dia|mês|ano!!!--Lépton ^✉ 03h22min de 7 de fevereiro de 2010 (UTC)

Agora que vi, {{dni}} aponta para os nascimentos, enquanto que {{ani}} para o dia do mês e ano. Não dá pra fundir mesmo.--Lépton ^✉ 08h11min de 15 de fevereiro de 2010 (UTC)

Infoboxes repetidos

{{Infobox modelo}} - {{Info/Modelo}} Fundir

{{Estrela}} - {{Info/Estrela}} Fundir

• {{Info/Cidade de Israel 2}} - {{Info/Cidade de Israel}} Fundir

• {{Infobox weather}} - {{Tabela/Clima}} Fundir (se for o caso), estão repetidas.

• {{Info/Wikipedista}} - {{Info user}} - {{!Info pessoal}} Fundir e apagar as outras. Acho que a que deve ficar é a {{Info/Wikipedista}}, e me parece já ter todos os campos necessários.

• {{Info/Língua}} - {{Info/Língua2}} Acho que é caso de fusão mas posso tar enganado.

• {{Info/Arma}} - {{Info/Arma de fogo}} - Fundir

{{S-notas}} e {{Sem-notas}}; redirects; nomes de meses

• Se {{S-notas}} usa {{Sem-notas}}, qual é o sentido de classificar a última como depreciada. Geralmente sou fusicionista, mas neste caso acho que se devem manter as duas, clarificando a documentação, nomeadamente, sugerindo que {{Sem-notas}} se deve usar sempre com |data={{subst:#time:F "de" Y}}. É provável que existam casos semelhantes (família {{sem fontes}}, etc.), tenho que investigar.

• Quanto aos redirects, concordo que se faça um esforço de supressão da maior parte, mas a bem de facilitar a vida de todos em geral e, nalguns casos, daqueles que também editam a en.wp, proponho que se mantenham ou até sejam criados, por exemplo:

1. {{sem notas}}, {{mais-notas}}, etc.
2. {{Cite web}}, {{Cite book}}, {{Cite journal}}, {{Cite news}}

• No caso dos primeiros, uma alternativa quiçá melhor é normalizar o separador de palavras nos nomes de predef.s, o que não tem sentido, po complicar a vida à malta, é umas usarem hífen, outras espaço, outras ainda sublinhado.
• Quanto às "citar", um dia destes vou ver se as expando no sentido de ficarem 100% compatíveis com as equivalentes da en.wp.
  --Stegop (discussão) 21h50min de 3 de fevereiro de 2010 (UTC)

• Nomes de meses, nomeadamente em categorias "geridas" por predefs - convinha normalizarmos tudo para caixa baixa (não insinuem nada, por favor, sou tanto ou mais português que os que são contra o AO). Só que antes de o fazer, convirá preparar um bot para mudar o nome de tudo quanto é categoria que tenha meses no nome. Eu já várias vezes tive a tentação de ver como é que isso se faz, mas tenho resistido, pois queria ter algum tempo para editar em vez de me viciar nestas tarefas de manutenção. --Stegop (discussão) 21h50min de 3 de fevereiro de 2010 (UTC)

Primeiro ponto: concordo, {{sem-notas}} não está depreciada. Melhor fazer uma nota explicativa, pedindo aos mais veteranos que usem {{subst:s-notas}}, assim já sai a tag com a data correta. Não creio que devamos deixar tudo com subst:, os novatos tem que se acostumar com muita coisa, vamos facilitar para eles.

Segundo ponto: concordo com normatizar o nome delas, não em criar redirects. Eis pq deve ter normatização: {{sem fontes}}, {{sem-fontes}}, muitíssimo fácil de se confundir. Vou inclusive mandar para ER {{sem fontes}}, mas daqui a um bom tempo, ela tem cerca de 2.500 afluentes.
Sobre as 'citar', creio que o melhor seja criar um método que quando adicionado subst: na predef em inglês, ela seja automaticamente transformada em português ({{citar web}}), como a {{Info/Empresa-en}}.

Categorias: concordo totalmente, mas não acho que será tão fácil implementar....--Lépton ^✉ 02h16min de 4 de fevereiro de 2010 (UTC)

• {{S-notas}} e {{Sem-notas}} — Se quisermos manter os argumentos opcionais do {{Sem-notas}} (eu até acho que poderíamos pensar em debruçarmo-nos sobre esse assunto também), acho que não fica nada prático usar o {{S-notas}} — subst por subst, fica mais claro usar o subst para a data. Aliás esse subst era uma boa idea pô-lo nos Hot Buttons (se calhar já existe e eu estou aqui a fazer figura de urso).

• {{sem fontes}} e {{sem-fontes}}: Atenção que não são a mesma coisa, o que aumenta ainda mais a confusão. Eu proponho que a prazo se acabe com {{sem fontes}}, {{Carece de fontes}} e afins e se crie um equivalente com um nome mais explícito que não se confunda com o {{sem-fontes}}, por exemplo {{s-fontes-linha}} e {{s-fontes-bloco}} para o atual {{Carece de fontes2}}. Acho ainda que seria útil criar uma espécie de misto de {{Carece de fontes2}} e {{Sem-fontes}} menos intrusivo, para marcar blocos, tipo uma passagem ou um parágrafo. Isto por razões estéticas e para evitar que sejam apagados por quem embirra com eles. Por exemplo, em "Portalegre (Portugal) eu optei por usar {{Carece de fontes}} para marcar partes não referenciadas, pois se usasse o mais correto {{sem fontes}} o aspeto ficava horrível.

• ({{citar web}}) e afins: não tenho a certeza de perceber o que quer dizer com o subst. Acho que se deve permitir, se não mesmo incentivar discretamente, o uso das "{{cite..." e mantê-las sem subst nos artigos, pois facilita imenso a vida a quem traduza da pt.wp para a en.wp. É certo que isso é uma violação do "princípio do não uso de redirect's", mas é por uma boa causa.
  --Stegop (discussão) 07h34min de 4 de fevereiro de 2010 (UTC)

Bem, se for usar mais parâmetros então não usa o subst: (não sei se é possível usar subst com parâmetros adicionais), mas então seria melhor adicionar a data de maneira manual tbm.

Acredito que 'carece de fontes' já é um bom nome, mas pode-se pensar em usar uma variação de {{sem-fontes}} como vc indicou para ficar mais lógico, {{sem-fontes-trecho}} e {{sem-fontes-bloco}}.

Não falei para colocar subst: nas 'citar', mas o citei como recurso de transposição de predefs. Tem um código que faz que quando adicionado subst ele transforma uma predef em outra, no caso a em inglês {{cite web}} pela em português {{citar web}} (isto facilitaria muito trazer fontes de lá para cá).--Lépton ^✉ 21h54min de 4 de fevereiro de 2010 (UTC)

Esqueci de comentar, já existe o subst no FastButtons: [1], [2].--Lépton ^✉ 04h18min de 5 de fevereiro de 2010 (UTC)

Tive uma ideia, o nome pode ser {{trecho sem-fontes}}, {{bloco sem-fontes}}, e renomear {{conteúdo parcial}} para {{trecho parcial}}. Seguindo esta lógica em predefs deste tipo fica mais fácil assimilar. Acho inclusive que seria o caso de renomear {{sem-fontes}} para {{sem fontes}}, e {{sem-notas}} para {{sem notas}} acho mais fácil digitar sem o hífen.--Lépton ^✉ 19h58min de 6 de fevereiro de 2010 (UTC)

Se bem entendi, o {{carece de fontes}} passaria a {{trecho sem-fontes}}, o {{Carece de fontes/bloco}} a {{bloco sem-fontes}}, é isso? A sugestão parece-me boa, mas suprimia os hífenes, pois é difícil memorizar onde é se tem hífen e não tem. Também me parece bem o {{trecho parcial}}. Só falta um nome novo para {{Carece de fontes2}}. --Stegop (discussão) 21h16min de 6 de fevereiro de 2010 (UTC)

Citação: Stegop escreveu: «Se bem entendi, o {{tl|carece de fontes}} passaria a {{trecho sem-fontes}}, o {{tl|Carece de fontes/bloco}} a {{bloco sem-fontes}}, é isso?» Isso mesmo. O {{carece de fontes2}} poderia ser {{trecho sem fontes2}}.--Lépton ^✉ 22h02min de 6 de fevereiro de 2010 (UTC)

{{Não-enciclopédico}}

É algo preciosista, mas, como em tudo quanto é aviso, acho que devia existir uma forma simples de incluir observações ou justificações, e atualmente, embora isso seja possível, não é nada prático, pois o texto opcional aparece sempre entre "Um editor detectou que" e "não ser de natureza enciclopédica".

A minha proposta é que se substitua o código com o de {{Não-enciclopédico2}}, que acabei de criar, que aceita um 2º argumento, que, se existir, aparece a seguir a "Observações".

O que acham? --Stegop (discussão) 22h11min de 8 de fevereiro de 2010 (UTC)

Acho que vc não deveria ter criado nova predef, talvez numa subpágina sua para demonstrar. Não me incomodaria nem mesmo se vc atualizasse a {{não-enciclopédico}}, porque os parâmetros que você adicionou são meramente opcionais, não iria atrapalhar em nada o uso antigo. Bem, apoio a reformulação da {{não-enciclopédico}}.--Lépton ^✉ 22h06min de 9 de fevereiro de 2010 (UTC)

Tem razão, não deveria ter criado {{não-enciclopédico2}}. Vou aguardar mais alguns dias, para ver o que a comunidade tem a dizer e, se não houver objeções, vou substituir {{não-enciclopédico}} por {{não-enciclopédico2}} e propor este último nome para ER. --Stegop (discussão) 01h37min de 10 de fevereiro de 2010 (UTC)

{{Verificar credibiblidade}} e {{Verificar fontes}}

Mais duas "desgarradas" e que, embora o seu nome sugira que sejam úteis, a forma como estão codificadas e implementadas as torna confusas e consequentemente pouco úteis, pois duplicam {{Carece de fontes}}.

Sugiro que ambas ({{Verificar credibiblidade}} e {{Verificar fontes}}) sejam eliminadas e substituidas por {{Carece de fontes}}.

No entanto, acho que seria útil ter uma tag "discreta", do tipo {{Carece de fontes}}, para assinalar ref's/fontes cuja fiabilidade possa ser questionável. Poderia, por exemplo, chamar-se {{fonte pouco fiável}} e ter o mesmo output da atual {{Verificar credibiblidade}}: ^{[fonte fiável?]}. Eventualmente, o wikilink poderia direcionar para a página de documentação da predef em vez de para WP:FF, para o leitor perceber porque a marca tinha sido posta.
--Stegop (discussão) 01h37min de 10 de fevereiro de 2010 (UTC)

ConcordoHyju (discussão) 19h58min de 10 de fevereiro de 2010 (UTC)

Considero que {{verificar fontes}} e {{Verificar credibiblidade}} estão redundantes, pq fazem a mesma coisa. Ao que parece este tópico pretende, na prática, é apagar {{verificar fontes}} e renomear {{Verificar credibiblidade}} mas modificar um pouco sua aparência. Concordo.--Lépton ^✉ 23h00min de 11 de fevereiro de 2010 (UTC)

>Concordo em juntar as duas. Só fazer o redirect? Rjclaudio ^msg 16h47min de 14 de fevereiro de 2010 (UTC)

{{Info/Cidade}}

Dei-me conta que não há nenhuma predef especializada para cidades (ou municípios) da Croácia e, como estou a pensar colaborar nessa área, estou a pensar criar uma.

Ao fazer o levantamento do que acontece com cidades e municípios de outros países, nos casos que vi dei-me conta que:

1. Nenhuma predef de base (que suponho dever ser {{Info/Cidade}}) é usada.
2. Em {{Info/Cidade}} faltam parâmetros que permitam que seja suficientemente abrangente; por exemplo: código postal, prefixo telefónico e matrícula de carros.

Ocorrem-me então as seguintes questões, que possivelmente podem ser pretexto para uma discussão não limitada à especificação da {{Info/Cidade Croácia}} ou afim:

1. {{Info/Cidade}} é o melhor "ponto de partida", ou haverá outra mais indicada? Uma das coisas que acho que complica a normalização é a frequente, mas dificilmente evitável em muito casos, confusão entre "cidade" e município.
2. O que é mais acertado: i) ampliar a "predef base" e evocá-la na predef específica? ii) criar a predef específica usando o código da "predef base"?
   

Se por um lado a 1ª opção´permite uma maior normalização, pode acabar por revelar-se pouco prático ou complicado arranjar uma predef base que sirva a todas as derivadas, pelas especificidades próprias de cada país.

Proponho ainda que, nas predef.s que sejam alteradas, se faça um esforço suplementar no sentido de minimizar ainda mais inputs que requeiram formatação. Ex: números (sugiro que o input seja feito "à inglesa", com ponto como separador decimal - 22550.6 em vez de 22550,6, 22&nbsp;550,6 ou 22.550.6 - para possibilitar o uso de {{#formatnum}}.
--Stegop (discussão) 02h26min de 13 de fevereiro de 2010 (UTC)

• Já tentei mexer nessas predefs, mas parei em algum momento. Podemos usar a {{Info/Assentamento}} como base para todas as infoboxes de localidades (trazida da wiki.en pela jurema). A partir dela fazer a {{Info/Cidade}} (info/país, info/bairro, info/município, etc) para simplificar o código. E depois a {{Info/Cidade da Croácia}} usa a {{Info/Cidade}} colocando os parâmetros comuns a todas as cidades da Croácia (nome das subdivisões, nome do país).
• Minha ideia seria essa. Só não cheguei a ver direito como funciona a {{Info/Assentamento}} pq é complexa demais.
• Rjclaudio ^msg 11h04min de 13 de fevereiro de 2010 (UTC)

{{en}}, {{((en))}}, {{hr}}, {{sr}}, etc.

Ao dar-me conta que não existia {{hr}}, descobri que:

1. Aparentemente todos, ou quase todos as afins são redirec.s (ex: {{en}}→{{((en))}}).
2. Por acaso uma exceção é {{sr}}, que escrevia (sr) com link para "Língua servo-croata" quando sr é o prefixo usado para a wiki sérvia e, ao contrário das similares, usava negrito.
3. Apesar de não existir {{hr}}, {{((hr))}} existia, embora, como a SR, escrevesse usasse negrito e wikilinkasse para "Língua servo-croata".

Já "padronizei" {{sr}}, que agora wikilinka Língua sérvia e escreve "(em sérvio)", e {{((hr))}} que agora wikilinka Língua croata e escreve "(em croata)", ambos sem negrito. Criei igualmente (em croata) com redirec. para {{((hr))}}. No caso de SR, não criei redir e codifiquei diretamente.

A minha pergunta é: estando alguns tão preocupados com redir.s dispensáveis, todos estes teem sentido, ainda para mais sendo tão usados? Pessoalmente não estou convencido que os redir.s sejam uma sobrecarga (overhead) assinalável para os servidores, mas em todo o caso... Não verifiquei os afluentes, mas quase que aposto que quase ninguém usa {{((en))}} e afins.

• O que acham de modificar os {{Lang-xx}} para não escreverem ":" quando não há argumento? Desta forma ficaria equivalente ao {{Código língua}}, mas além de ser mais curto, era menos um código a memorizar.

• E falando em {{Lang-xx}}... Aí estão mais candidatos a unificação e normalização com recurso a {{Código língua}}, pois se bem entendi, poderia perfeitamente existir apenas um {{Lang qq coisa}} ({{Lang}} já existe parece de "baixo nível") que aceitasse como 1º argumento o código da língua.
  --Stegop (discussão) 08h41min de 14 de fevereiro de 2010 (UTC)

Na minha visão essas predefinições deste tipo já deviam ter sido extintas a muito tempo ou Citação: Predefinição:((en)) escreveu: «Atenção: Não use esta predefinição diretamente nas ligações externas! Ao invés disso, use {{link|código da língua|2=endereço web|3=nome do link}} que é forma padronizada.» ou isso é "balela"? Acho que devemos aproveitar essa padronização e remover definitivamente essas predefinições. Abraços Mwaldeck ^msg 15h33min de 14 de fevereiro de 2010 (UTC)

Eu achava q era ela usava pela Link, mas pelo visto me enganei. Como na maioria esmagadora dos casos, ela é usada nas LE, sou a favor de ir arrumando os afluentes com o awb/bot passando para {{Link}}, e os poucos q sobrar arrumar manualmente. Mas como são milhares (só a {{en}} tem 5000+) vai demorar um tempo para podermos apagar essa predef. Só vamos terminar essa tarefa após arrumar os afluentes. Rjclaudio ^msg 15h51min de 14 de fevereiro de 2010 (UTC)

Podemos ir pelas "beiradas" e deixamos a {{en}} por último ou vamos fazendo aos poucos. Que acham? Abraços Mwaldeck ^msg 15h57min de 14 de fevereiro de 2010 (UTC)

• Como tenho dito, primeira semana de março tem uma versão estável do meu script pra awb. aí podemos arrumar os afluentes sem medo de fazer edição com apenas uma mudança, nem editar 10 vezes o mesmo artigo. Se puderem esperar 2 semanas agradeço. (não perco a oportunidade de um spam =)
• Podemos começar pelas beiradas, q tem menos, e ir apagando elas. Assim as pessoas, aos poucos, vão vendo que elas não devem mais ser usadas.
• Rjclaudio ^msg 16h15min de 14 de fevereiro de 2010 (UTC)

Essa é a ideia. Vamos esperar, mas o Carnaval poderia ser um oportunidade boa para essas edições em massa, não? Sem querer pressionar, claro! Abraços Mwaldeck ^msg 16h23min de 14 de fevereiro de 2010 (UTC)

Mas estou usando justamente o carnaval para acelerar bem os testes. Bem, ao menos já tenho mais ajuda para fazer esse script que eu tinha ano passado, trabalhando sozinho. Rjclaudio ^msg 16h28min de 14 de fevereiro de 2010 (UTC)

Opa, ajuda é uma palavra mágica. Eu posso ajudar. Se quiser, conversamos em nossas páginas de discussão. I'm available to help. Abraços Mwaldeck ^msg 16h41min de 14 de fevereiro de 2010 (UTC)

Eu ia sugerir renomear todas para {{código da língua}}, sem os parênteses, mas agora que vc falaram, realmente a única utilidade delas é nas LEs, e como já temos {{link}}, elas não fazem sentido (para as refs devemos usar a {{citar web}} etc). Apoio a ideia de evaporar com elas.--Lépton ^✉ 08h11min de 15 de fevereiro de 2010 (UTC)

DiscordoNem 8 nem 80! É útil existir uma forma de referenciar uma língua de uma forma normalizada, nem que seja para predef.s. Que me lembre, quase tudo quanto é predef que tenha argumento "língua" requer que seja escrito o nome por extenso - isso sim deve mudar, e foi principalmente isso que me levou a abrir esta discussão. Acho que todas essas predef.s devem passar a aceitar um código de língua em vez de, ou como alternativa, ao nome da língua por extenso. Um bom exemplo disso são as {{citar...}}, que eu uso com {{en}}, {{es}} no fim porque não queria alterar o código delas antes de por o assunto a discussão. --Stegop (discussão) 11h48min de 15 de fevereiro de 2010 (UTC)

• No caso da {{Citar web}}, basta mudar pra ela aceitar no campo o código da língua. Ter |língua=en. E a {citar web} usa o "en" como parâmetro para a {{Código de língua}} (ou outra qualquer). Não é necessário colocar {{en}} diretamente no parâmetro da predef.
• Vai acabar com as {en} {es} {it}, e colocar todas na {Código de língua}.
• Ainda acho que pode acabar com elas (não acabar, pq mt usada na wiki.pt e nas traduções), depreciar e passar um bot periodicamente arrumando ela.
• Rjclaudio ^msg 13h07min de 15 de fevereiro de 2010 (UTC)

Pelo menos renomear {{((en))}} pra {{en}} tem que ser feito, sem noção ter estes parênteses...--Lépton ^✉ 16h42min de 15 de fevereiro de 2010 (UTC)

Amigo, essa foi também uma das razões que me fez abrir a discussão! O que eu proponho é o seguinte:

1. {{en}}} e afins deixam de ser redir.s, de preferência usando {{Código língua}} em vez de escreverem o nome da língua diretamente. Bem sei que fazem o mesmo que "({{Código língua}}).", mas é bem mais prático, e as predefs também servem para simplificar a edição, e se for tão complicado, as pessoas vão acabar por preferir escrever o nome da língua e pronto.
2. {{((en))}}} e afins desaparecem.
3. {{Lang-en}} e afins desaparecem, sendo substituídos por algo como {{Langcod}}, cujo 1º argumento é o código da língua; se não tiver mais argumentos, limita-se a gerar o output de {{Código língua}} (isto apenas para dispensar decorar {{Código língua}} para fazer isso). Idealmente esta "nova" predef devia chamar-se {{Lang}}, como na en.wp, mas esse nome está ocupado e não sei se não é ainda mais complicado substitui-lo do que substituir todas as {{Lang-xx}}.
4. Tudo quanto é predef que escreva nomes de línguas e wikilinks para línguas passa a usar {{Código língua}}.
   

--Stegop (discussão) 18h53min de 15 de fevereiro de 2010 (UTC)

Fiz uma modificação na {{Citar web}}, para aceitar o parâmetro língua2, no lugar de língua, para ser usado com "en". |língua2=en. Isso facilita o meu scriptAWB colocar a {Citar web} direito. Acredito que devemos deixar os dois campos mesmo, como opcionais, pois nem sempre saberemos a abreviação para a língua, e pode ter casos de ter mais de uma língua. Rjclaudio ^msg 12h45min de 17 de fevereiro de 2010 (UTC)

Predefs com bandeiras

Discutindo as bandeiras.

1. Imagino ser bom não ter nenhum afluente pra {{ÍconeBandeira}}, certo? Melhor um {BRAb} q um {ÍconeBandeira|Brasil}. Mas tb não podemos acabar com o redirect, pra não atrapalhar as traduções c/ {{Flagicon}}. Proponho um bot passar por ela 1x por mês (ou mais tempo, por semestre) arrumando os afluentes. Proponho tb fazermos um "calendário pra bots", com tarefas q seriam feitas de tempos em tempos (como arrumar {{ref-section}}, {{flagicon}}, {{cite web}}, {{en}}, etc).
2. Acabei de conhecer {{Country flag IOC alias EUA}}. Nome gigante para ser usado em artigo, sendo válido apenas nas predefs. Não sei se seria útil pra artigos, mas mesmo assim prefiro mudar o nome. Talvez USAi (imagem)?
3. Proponho usarmos {{BRAb}} em todas as predefs da família {{BRA}} {{BRAf}} {{BRAfs}} e similares, ao invés de [[Imagem:Flag of Brazil.svg(...)]].. Padronizar a imagem (caso se mude o nome da imagem, como .jpeg -> .svg. Tem alguma bandeira q não é svg?), o tamanho (todas pra 20px, atualmente algumas com 20, 25, 30, 15), e o nome q aparece qnd coloca o mouse sobre a bandeira ("Bandeira do Brasil", poucas imagens tem isso, algo mt importante pra Acessibilidade). Concordam?
4. As bandeiras de estados seguem o padrão{{BR-RJ}}, com BR, código ISO-2, qnd nosso padrão é o ISO-3. Por mim movia todas elas de BR- para BRA-, padronizando.
5. Precisa de ajustes nas {{BRAih}}. Está ligando para Seleção do Brasil de Hóquei no gelo, q é redirect para Seleção Brasileira de Hóquei no Gelo Masculino.
6. Proponho criar predefs pra nacionalidade dos países. {{BRAn}} = brasileiro. Isso daria pra padronizar o nome das seleções, e automatizar a criação das atuais e de futuras (pelo visto faltam mts). Mesmo se não for pra usar diretamente elas, pelo menos ter elas pra colocar subst, isso já basta pros bots. Segundo Wikipedia:Namespace predefinição/Países, temos mts predefs do tipo para criar.
7. Rjclaudio ^msg 11h45min de 16 de fevereiro de 2010 (UTC)

Alguns comentários:

1 Aí entra a questão da simplificação no artigo vs facilidade de manutenção (por exemplo, em anexos de listas de países, nem sempre é fácil editar o artigo que só usa as predefinições com 3 letras, que inserem automaticamente as bandeiras). Pensei em deixar a {{ISO}} para ser utilizada com o subst (para resolver o problema técnico que impedia que o switch fosse usado mais de 200 vezes na mesma página), mas não consegui.

2 Essa predefinição não ia ser usada diretamente do artigo. Ela vem do sistema Flagcountry e {{Country data}} que estava sendo importado da en.wp (questão de comodidade, já que traduziam-se muitos artigos esportivos de lá). Esse sistema utiliza centenas de predefinições, onde, para cada país era necessário cerca de 3 predef., combinadas pelo flagcountry ,para adicionar uma bandeira no artigo. Tentei minimizar isso, criando o {{ISO}}, mas devemos ter vários destas predef. por ai perdidas.

3 Os tamanhos precisam ser padronizados, claro. Mas eu não sei se faz muita diferença, em termos de processamento e velocidade, para o servidor especificar diretamente a imagem ou usar uma predef. que chame ela.

4 As bandeiras dos estados seguem o código ISO 3166-2:BR e os países seguem o código ISO 3166-1 alfa-3 (e a ISO 3166-3 é de países extintos). Alterar para BRA-RJ pode ser mais intuitivo, mas deixará de seguir qualquer norma iso de referência. Giro720^msg 23h05min de 16 de fevereiro de 2010 (UTC)

1. Só com as bandeiras, não vejo mt problema em substituir a ÍconeBandeira. Normalmente a bandeira vem junto com o nome do país, ou com o nome de alguma coisa, de modo q normalmente a bandeira não é o principal. Pra leitura do código não vai afetar. Pra criação de conteúdo pode ser mais fácil usar a IconeBandeira, por isso manteria o redirect. Então talvez não seja boa ideia trocar {{BRAb}} Brasil -> {{BRA}}.

2. Se é mt usada, e só pelas predefs, então deixa quieto. Mt trabalho, temos mais coisas pra fazer.

3. Se a diferença for irrelevante, vamos usar a {BRAb}. Os cegos agracem.

4. Ok, não sabia disso. Que tal um aviso nas páginas das bandeiras dos estados, similar a dos países, falando qual norma isso estamos seguindo?

Rjclaudio ^msg 23h57min de 16 de fevereiro de 2010 (UTC)

Relendo o tópico, percebi que você tem razão em relação ao IconeBandeira; geralmente ele vem acompnahdo ao nome do país, o que é indiferente para edição/manutenção do artigo (ao contrário da troca {{BRAb}} Brasil -> {{BRA}} que pode dificultar alguma coisa), tal como cistaste.

Aproveitando a discussão, fiz algumas mudanças em {{BRAb}}: adicionei |link=Brasil|alt=Bandeira do Brasil e removi a antiga legenda. Assim, ao clicar sobre a bandeira, você é direcionado ao artigo Brasil; se você passar o mouse/rato sobre a imagem, uma caixa tooltip aparecerá indicando "Brasil" (o mesmo texto do link, ou da legenda, se for adiciona), e se você tiver um leitor de tela/ecrã, o mesmo lerá "Bandeira do Brasil". A antiga legenda fazia aparecer um tooltip com "Bandeira do Brasil", mas imagino que o fato de ser uma bandeira é meio óbvio para os usuários que podem ver a imagem, além de pouco prático - geralmente o interesse é descobrir a qual país se refere. Caso gostem da sugestão, espero que seja implementada nas demais bandeiras. Giro720^msg 21h48min de 18 de fevereiro de 2010 (UTC)

Na en.wp, para imagens puramente decorativas, é aconselhado que elas não tenham nem link (link=) nem texto alternativo (alt=), de modo a não ser lido. No caso de bandeiras, quando a informação do país vem ao lado, ok. Mas quando é a bandeira sozinha (ou a bandeira acompanhada do nome de uma pessoa ou associação) ainda considero importante essas informações, por facilitar a identificação do país (deixando de ser uma imagem meramente decorativa). É um assunto a se pensar. Giro720^msg 22h01min de 18 de fevereiro de 2010 (UTC)

Concordo com a sugestão do Giro, e penso que devia ser aplicada às restantes predefs de bandeiras. --- Darwin ^Alô? 08h21min de 24 de fevereiro de 2010 (UTC)

Datas

Em datas de referência e links externos, por vezes vejo 01/01/2000 e por vezes 1 de janeiro de 2000. Existe alguma recomendação? Um padrão? Eu prefiro muito mais a data por extenso, para termos certeza que não é uma data que está na ordem mm-dd-aaaa trazida da wiki.en. Meu scriptAWB está arrumando a ordem de algumas datas óbvias, e no poderia colocar por extenso tb. Rjclaudio ^msg 17h56min de 19 de fevereiro de 2010 (UTC)

Pessoalmente, acho que o formato (acho que é ISO e tudo) ano-mês-dia é o melhor compromisso em termos de comprimento, facilidade de digitação e clareza (como o ano aparece em primeiro, dificilmente alguém vai pensar que o 2º número é do dia). Mas bem sei que há muitos que detestam este formato... --Stegop (discussão) 22h10min de 19 de fevereiro de 2010 (UTC)

O ISO segue um padrão, mas dificilmente as pessoas o usariam. Seria um trabalho só pros bots ficarem arrumando, então não vale a pena. Rjclaudio ^msg 22h38min de 19 de fevereiro de 2010 (UTC)

Salvo erro, em Portugal, há uns bons anos atrás, tentou-se implementar o uso do formato AAAA/mm/dd, mas nunca chegou a ser generalizado o seu uso e até penso que houve um retrocesso para o uso de dd/mm/AAAA. No caso das referências, penso que se devia utilizar a data por extenso, para evitar confusões. --João Carvalho ^{deixar mensagem} 22h50min de 19 de fevereiro de 2010 (UTC)

O formato aaaa-mm-dd é mais interessante para montar a internacionalização como no Commons, onde temos vários editores de várias línguas acessando o mesmo site. Lá, inclusive, existem bots que acertam a data para o formato aaaa-mm-dd. No nosso caso, o melhor é a data por extenso. A questão dos links sempre foi um "tabu" para mim, já que uns dizem uma coisa, outros outro. Nunca li no livro de estilo nada sobre isso. Abraços Mwaldeck ^msg 23h27min de 19 de fevereiro de 2010 (UTC)

Mias um voto por aaaa-mm-dd, aaaa/mm/dd, aaaa.mm.dd et al., apesar de que pelo que sabia este padrão só era usado pela população em geral no japão, mas pesquisando um pouco mais chego a isto. A lista é deveras menor (quando comparada à variante dd.mm.aaaa), mas é um critério muito mais organizável, com muitos dos motivos já citados acima (o principal para mim sendo a ordem lexicográfica). Daemorris ^discussão 01h18min de 20 de fevereiro de 2010 (UTC)

Pelas normas da união europeia a forma correcta é aaaa/mm/dd (podendo ser utilizadas variantes com . ou -) por isso mais tarde ou mais cedo todos os países da união europeia (Portugal inclusive) quer queiram ou não terão que utilizar essa forma, por isso concordo com ela. Pelo Poder do Z ^{Alaf Ogimoc} 18h49min de 20 de fevereiro de 2010 (UTC)

Prefiro por extenso, mas, independente do formato, o ideal seria colocar o link, para se ter certeza da data que é referida. – Opraco (discussão) 03h48min de 21 de fevereiro de 2010 (UTC)

É possível modificar a {{data}} para que ela adicione ligações no formato: 2012/12/25. Daemorris ^discussão 13h10min de 21 de fevereiro de 2010 (UTC)

Se alguém ainda estiver interessado, acabei de fazê-lo:

Formato	Código	Resultado
Antes	{{data|1970|01|01|formato=antes}}	1970/01/01
Depois	{{data|1970|01|01|formato=depois}}	01 de jan. de 1970
(nada)	{{data|1970|01|01}}	01 de janeiro de 1970

Se o caso for, é possível criar o parâmetro "separador=", cobrindo todos possíveis: ., /, -... Além disso o código pode ser reaproveitado em outras predefinições. --Daemorris ^discussão 02h41min de 22 de fevereiro de 2010 (UTC)

Tenho ódio mortal do formato ano-mês-dia, é anti natural digitar assim! Prefiro dia-mês-ano ou por extenso.--Lépton ^✉ 15h35min de 21 de fevereiro de 2010 (UTC)

• Anti natural? Essa é boa, porque anti natural é digitar dia-mês-ano pois é anti lógico e completamente anti-natura. É curioso que quando alguém pergunta pela nossa idade pergunta sempre primeiro em que ano é que nascemos, por alguma razão é que é pois é lógico e natural, em qualquer situação, começa-ser sempre pelas variáveis com menos variantes e passa-se para as maiores por isso começa-se com o ano que é um, depois com o mês que são doze e finalmente com o dia que são (em média) 30. Isto é que é lógico e natural. Pelo Poder do Z ^{Alaf Ogimoc} 23h02min de 21 de fevereiro de 2010 (UTC)

Creio que esse assunto seja tão complicado quanto grafia de nomes de países, onde cada um tem sua preferência. Só para informação, a norma portuguesa para citações bibliográficas (NP 405) aceita tanto o formato ISO quanto a a data por extenso (do tipo 15 Jan. 2010), enquanto a norma brasileira apresenta exemplos apenas com a segunda opção. Chamo a atenção que a data ISO deve ser separada por hífen. Provavelmente teremos que aceitar todos os formatos citados nessa discussão, mas eu sugeriria que, informalmente, as datas DD MM YYYY sejam separados por apenas por "/", e que as datas escritas por extenso, sempre que possível, deveriam ter o mês abreviado e não ser acompanho de "de" (para maior compatibilidade com as normas). Giro720^msg 23h58min de 21 de fevereiro de 2010 (UTC)

Quando propus aaaa-mm-dd já estava à espera de polémica. Apesar de me parecer mais lógico usar aaaa-mm-dd, proponho:

1. Caso não seja alcançado consenso, pelo menos se acorde em apenas dois formatos "admissíveis" recomendados e que não haja reversões entre os dois, à semelhança do que se faz com pt-pt e pt-br.
2. Pegando na sugestão do Giro720 de abreviar as datas por extenso (ex: 21-fev-2010), porque não adotá-lo para *todas* as datas? Deste modo deixaria de haver ambiguidade, referências muito longas e complexidade acrescida a digitar, que, quanto a mim, são os principais problemas das datas por extenso do tipo "21 de fevereiro de 2010".
3. Recomendar o uso de predef.s para indicação de datas ({{data}}, {{dtlink}}, {{dtext}}, {{nascimento}}, {{falecimento}}, {{dni}}, etc.)
   --Stegop (discussão) 00h18min de 22 de fevereiro de 2010 (UTC)

Discordo quanto a aceitar apenas dois formatos, mas Concordo com todo o resto, só abreviar o nome dos meses já seria uma grande padronização. Além disso, recomendar o uso de predefinições de data já é mais de meio caminho andado, inclusive para tudo que for resolvido no futuro. Daemorris ^discussão 00h44min de 22 de fevereiro de 2010 (UTC)

Substitui "admissíveis" por "recomendados" no ponto 1. Se estamos interessados em padronizar, no caso de não conseguirmos consenso numa só norma, parece-me aconselhável que ao menos haja acordo no sentido de recomendar um número mínimo de formatos. --Stegop (discussão) 00h59min de 22 de fevereiro de 2010 (UTC)

Gostei da {{data}}. Eu iria sugerir 3 padrões:

Local	Formato	Prioridade
Corpo do artigo (padrão)	22 de fevereiro de 2010	Acessibilidade
Infobox	22-fev-2010	Simplificação
Referências	2010-02-22	Ordem cronológica

Pro corpo artigo o mais importante é acessibilidade. Tem que estar escrito de um modo que até uma criança da primeira série (ou antes) possa ler. A infobox de certa forma faz parte do artigo, mas como a ideia é resumir as informações, e se colocar por extenso esse pode ser o campo mais largo da predef, podemos usar o formato que mantém a acessibilidade mas dá mais importância à simplificação. E pras refs, o mais importante é saber a ordem cronológica. A primeira coisa que vejo na ref é o ano, pra saber se ela é recente ou está desatualizada. E essa deveria ser a prioridade. Se não tivermos acordo, deixamos opcional para referências usar o modelo pra infobox. Rjclaudio ^msg 15h03min de 22 de fevereiro de 2010 (UTC)

Concordo e isto é fácil de fazer, provavelmente irei fazê-lo, o que está faltando aqui por enquanto é consenso. Acredito que a sua proposta é a que tem mais mais chance de ser aceita, por incorporar os três formatos de maneira racional, ao invés de exigir apenas 1 ou 2. Daemorris ^discussão 16h49min de 22 de fevereiro de 2010 (UTC)

Eu não vejo necessidade de abreviar as datas nas infoboxes, mas o que for decido, aceitarei. Nesse caso, sugeriria que fosse comentado na esplanada, para evitar problemas futuros (pois, ao contrário da padronização nas ref. que é um detalhe pequeno, este envolve muito mais editores). Outra sugestão seria remover os traços de 22-fev-2010, a menos que esse formato seja usado em algum lugar (não há necessidade criar um novo padrão, já temos problemas demais com o existentes...), e se possível, usem o ponto para abreviação do mês, para que fiquem conforme normas NP/ABNT. Giro720^msg 16h57min de 22 de fevereiro de 2010 (UTC)

Concordo que remover os traços e adição do ponto seria útil, se você não tiver nada contra Rjclaudio, eu sugeriria que alterasse na proposta acima. Mas qualquer que seja a decisão, ela sempre pode ser melhorada depois, o que não é vantagem é mantermos como está agora. Daemorris ^discussão 17h40min de 22 de fevereiro de 2010 (UTC)

A quem interessar, o padrão ISO 8601 (para datas e horas) está explicado em inglês no sítio oficial, ou em português aqui na Wikipédia.

Citação: ISO 8601:2004 escreveu: «A ISO 8601:2004 não cobre datas e horas em que palavras são usadas na representação e datas e horas em que caracteres não são usados na representação.»

As vantagens citadas são críticas para sistemas internacionais de trocas de informações, como softwares aplicativos para transações financeiras e similares. Mas realmente é um padrão internacional, e facilita a troca de informações por ser muito bem projetado. Daemorris ^discussão 04h44min de 24 de fevereiro de 2010 (UTC)

• E quanto aos links? Só há pedaço me dei conta que aparentemente a recomendação en:MOS:UNLINKDATES não está em vigor na pt, antes pelo contrário a página que fala no formato só mostra datas com links, embora não fale em links. Eu acho absurdo linkar datas que não tenham que ver diretamente com o assunto, de certa forma a norma de "não exagerar" nos links conduz a isso, no entanto, noto que há muita gente que tem o hábito de linkar tudo, inclusivamente datas de acesso. --Stegop (discussão) 21h28min de 22 de fevereiro de 2010 (UTC)

Discordo que seja abreviada a data nas caixas de informação, existem coisas mais simples a simplificar, aliás nem ocupa assim tanto espaço no modelo. Mas se for decidido em consenso, por mim tudo bem, desde que não aproveitem para dar "uma volta" ao nome dos meses, nomeadamente retirar a maiúscula do início da palavra. Vítor&R™ ^{The Wait is Ova!} 22h10min de 22 de Fevereiro de 2010 (UTC)

E o assunto vira disputa? Daemorris ^discussão 21h50min de 22 de fevereiro de 2010 (UTC)

Não há disputa nenhuma, pelo menos da minha parte. Aliás a minha parte como membro do projecto está feita, dei o meu parecer sobre o assunto aqui debatido. Vítor&R™ ^{The Wait is Ova!} 21h52min de 22 de Fevereiro de 2010 (UTC)

Desculpe, mas a sua última edição mudou completamente o sentido do que você escreveu, se esta foi uma correção, retiro o que disse acima. Daemorris ^discussão 22h01min de 22 de fevereiro de 2010 (UTC)

Foi uma correcção, acho que cada um deve fazer como quiser, desde que não vá contras as regras e políticas, mas não percebo o seu problema, se nem é dirigido à sua pessoa. Mas se for necessário, eu recoloco o comentário. Vítor&R™ ^{The Wait is Ova!} 22h13min de 22 de Fevereiro de 2010 (UTC)

• Dando a minha colher de chá... Concordo com a versão do Rjclaudio para o corpo do artigo. Nas infoboxes, sou mais pelo formato igual ao do artigo, e, sendo simplificado, sem os traços que o Rjclaudio colocou, conforme diz o Giro. Concordo com o formato das referências, mas nesse caso não deve levar link para a página da data, pois não tem qualquer interesse.--- Darwin ^Alô? 08h10min de 24 de fevereiro de 2010 (UTC)

Eu prefiro manter os traços, eles são usados no padrão ISO, e causam uma boa distribuição do texto, facilitando a interpretação tanto em datas únicas, quanto em sequências. Usar espaços vai trazer a impressão de serem elementos cada vez mais separados, ao invés de uma única data, completa, e organizada (do modo como for). Daemorris ^discussão 14h06min de 24 de fevereiro de 2010 (UTC)

Os traços são utilizados no padrão ISO onde datas/tempos são representadas numericamente. Como você meso disse, a ISO não cobre datas/tempo que são representadas por palavras (e portanto escrever 22-fev-2010 seria criar um outro padrão, e não seguir a ISO). Giro720^msg 15h33min de 24 de fevereiro de 2010 (UTC)

Citação: Giro720 escreveu: «escrever 22-fev-2010 seria criar um outro padrão, e não seguir a ISO», usar palavras na representação já não é seguir o padrão ISO, todas as formas aceitas pela ISO estão no artigo ISO 8601 (logo no começo). Você não entendeu o que eu quis dizer, os traços são usados na norma, não escrevi que "usar os traços é seguir a norma". Estamos tentando achar um modo lógico de mesclar padronização com facilidade de uso, não forçar um padrão totalmente técnico como 2010-02-24 em todos os lugares, o que perderia propósito. Daemorris ^discussão 16h01min de 24 de fevereiro de 2010 (UTC)

Bom, eu não gosto de ver os traços no formato dd-mmm-yyyy, mas é só isso mesmo, não gosto. Se decidirem pelos traços, não serei eu a me opor. --- Darwin ^Alô? 16h41min de 24 de fevereiro de 2010 (UTC)

E eu não gosto de barras ("/"), pois acho que dificultam a leitura e o meu separador preferido é o traço (hífen). Mas por mim não será por isso que não temos consenso. O que acho mais importante é evitar ambiguidades e por isso é que embirro com tudo o que não seja aaaa-mm-dd, exceto quando o mês é indicado com letras, por extenso ou abreviado. Não tem sentido evocarmos normas ou padrões nesta discussão, dado que esse argumento vale tanto para o hábito enraizado do dd/mm/aaaa, como para os aaaa-mm-dd, como já foi por aqui dito mais do que uma vez. À semelhança do AO, a culpa disso é a hipocrisia e falta de coragem dos governos que aprovam normas que depois hesitam em fazer cumprir quando há protestos. --Stegop (discussão) 20h37min de 24 de fevereiro de 2010 (UTC)

• Ainda em relação à questão de dd/mm/AAAA, temos a opção de seguir o nosso padrão, certo? É uma vergonha ter de colocar AAAA/mm/dd. Vítor&R™ ^{The Wait is Ova!} 15h46min de 24 de Fevereiro de 2010 (UTC)

Ainda estamos discutindo o mérito técnico de cada formato, justamente para evitar criar mais polêmica. Daemorris ^discussão 16h01min de 24 de fevereiro de 2010 (UTC)

Só pode ser usado de uma forma? Seguindo o exemplo de como ficou decidida a ordem dos modelos de artigo discutido na Esplanada, poderiam ser adoptados os dois formatos. Vítor&R™ ^{The Wait is Ova!} 16h05min de 24 de Fevereiro de 2010 (UTC)

Diferente do caso da ordem REF/VT, a {{citar web}} é usada várias vezes no mesmo artigo. Tem artigo com 100+ Citar web, se mantermos 2 modelos teremos metade das refs usando aaaa/mm/dd e outra metade com dd/mm/aaaa. Isso não fica com um visual lá mt bom, de preferência devemos tentar manter a coerência dentro do artigo.

Sou totalmente contra o modelo dd/mm/aaaa, por dar margem à confusão com mm/dd/aaaa, q vem junto das traduções da wiki.en. Se tiver um 03/04/2000, alguém bota a mão no fogo afirmando ser 3 de abril? eu não. Esse modelo nunca deveria ser aceito. Vou tentar uma regra pro meu script pra pelo menos trocar dd/mm/aaaa para a forma extensa. Mais pra frente vemos se fica a extensa ou a aaaa-mm-dd. Ninguém contra né?

Rjclaudio ^msg 21h39min de 24 de fevereiro de 2010 (UTC)

Imagens pequenas: símbolos

Ver artigo principal: Wikipedia:Esplanada/anúncios#Parâmetros para imagens e texto alternativo, Wikipedia:Acessibilidade, Ajuda:Guia de edição/Como usar imagens, Wikipedia:Texto alternativo para imagens

Segundo as novas discussões, vi a importância de prestarmos mais atenção ao código da imagem e não apenas ao seu visual. Assim como tem, em uma seção mais acima, uma melhoria para os códigos das predefs {{BRAb}}, {{BRA}}, e similares, gostaria de expandir a ideia para todos os símbolos.

Nos artigos, todas as imagens com menos de 30 kb podem ser consideradas como um símbolo / ícone, e como um bom símbolo ela vai aparecer frequentemente em vários artigos diferentes. E tb como símbolo, por ser detalhe pequeno ninguém se preocupa em seguir o código completo. Para resolver isso, só mesmo uma predef para esses símbolos, mantendo o código pequeno (menor que se fosse apenas usar o código da imagem+tamanho), completo e correto.

Proponho adotarmos predefs para todas as imagens pequenas q são mt usadas em artigos.

Rjclaudio ^msg 18h59min de 27 de fevereiro de 2010 (UTC)

Concordo, é um assunto pertinente Pelo Poder do Z ^{Alaf Ogimoc} 22h46min de 27 de fevereiro de 2010 (UTC)

Bandeiras de estados e cidades

Assim como temos predefinições para bandeiras dos países, penso ser útil termos também para as suas subdivisões, ao menos para as de primeiro e segundo nível (estado/cidade, por exemplo). Todo mundo aqui sabe as vantagens de usar a predef (código simples, completo, acessibilidade, padronizado, etc).

Pelo o que entendi, as divisões de primeiro nível (estado) já possuem um código próprio {{BR-RJb}}, então basta pesquisar o código de outros países e fazer as predefs. Mas e as de segundo nível, tem algum código padrão?

Rjclaudio ^msg 13h41min de 11 de março de 2010 (UTC)

Suponho que existem códigos ISO para tudo quanto é divisão administrativa com alguma importância. Veja-se, por exemplo Ficha de entidad subnacional ou uma das suas instâncias es:Provincia de Ávila ou es:Provincia de Gerona. Esse código ISO e os seus "pais" e "avós" são bons candidatos para {{Info/Assentamento}}, não acham? --Stegop (discussão) 18h06min de 11 de março de 2010 (UTC)

Podemos usar os códigos para a Info/Assentamento, desde que seja opcional já que muita gente (ainda mais os novatos) não conhecem os códigos (nem eu conheço). Algo como: |estado= Rio de Janeiro, ou |estado-iso = RJ, usando um ou outro.

Se formos usar é mais um motivo para criarmos as predefs de subdivisões. É possível criarmos as predefs de modo automático, usando um bot?

Rjclaudio ^msg 19h08min de 11 de março de 2010 (UTC)

Vale a pena criar esse tipo de predefinição para cidades e municípios também? Além de serem muitos, não terem padrões ISO associados, elas não seriam tão exaustivamente utilizadas como é o caso das predef. de bandeiras de países e estados/subdivisões principais (que justifica a criação de qualquer predef.). Mesmo nas seções das cidades-irmãs, as bandeiras mais adequadas são dos países, justamente porque a bandeira da cidade não traz muito a informação ao leitor (apenas aos poucos leitores que, por acaso, reconhecem a bandeira). Giro720^msg 23h20min de 12 de março de 2010 (UTC)

Argumentos numéricos de predefs e sua formatação

Parece-me que idealmente deveríamos caminhar no sentido de tudo quanto é argumento numérico de predef ser introduzido não formatado, deixando a formatação a cargo da predef.

Ao que sei, só há uma forma padronizada de formatar números ({{formatnum}}), a qual imagino que para alguns tem o senão de exigir o input "à inglesa", com ponto como separador decimal. Receio que isto pode ser causa para um coro de protestos contra qualquer tentativa de exigir que os números passem a ser introduzidos "à inglesa". Isso e o facto de que se me afigura complicado substituir em todos os artigos o formato dos números, leva-me a sugerir que, pelo menos numa fase transitória se criem argumentos opcionais ou complementares para a indicação de números (por exemplo: comprimento2, área2, altura2, população2, etc.), recomendando-se que se usem esses em vez dos já existentes.

O que acham? --Stegop (discussão) 04h09min de 13 de março de 2010 (UTC)

Verdade; e não se trata apenas uma questão de padronização de formatação ou de estilo. A falta de algum padrão, ou de algumas frases comuns dificultam em muito a atualização de dados por bots, como, por exemplo, o números de habitantes em município inserido no interior do artigo. Já nas predefinições, algumas informações (como hab./km²) poderiam ser calculas automaticamente se o formato um formato específico for seguido. Giro720^msg 00h14min de 14 de março de 2010 (UTC)

Simplificação de uso de {{Código língua}}

Espero que não me levem muito a mal, mas a minha preguiça leva-me a achar complicado escrever {{Código língua |xx=1}}, pelo que criei {{Ling}}, que faz isso mesmo. Não ponho qualquer objeção a bots e AWB substituirem {{Ling}} por {{Código língua}}. --Stegop (discussão) 01h01min de 14 de março de 2010 (UTC)

Isso não tem o mesmo efeito de um redirect? Qual a vantagem de chamá-la dessa forma? – Opraco (discussão) 01h06min de 14 de março de 2010 (UTC)

• Entendi o conceito. A {{código língua}} foi feita para só ser necessário uma língua, então não tem pq a predef exigir o "|xx=1", bastaria o "|xx". A "código língua" deveria ser uma predef base com uma subpredef, fazendo exatamente o q vc propõe. A proposta é mover a "código lingua" para "código língua/2" (2, opções, lista, conversão, qualquer coisa), e a atual "ling" para "código língua", e arrumar os afluentes da código língua para o novo padrão.
• Pensei em mudar o nome de {{código língua}} para {{Iso2língua}}, seguindo o padrão da {{Iso2país}}, deixando mais explícito que a entrada é a iso e a saída é a língua, pq por vezes podemos querer o oposto (ao menos com os países já vi casos dos dois lados).
• Podemos deixar a ling como redirect. Só tenho um certo medo de termos {{ling}}, {{lang}} e as {{lang-en}}, todas com o nome mt parecido um com o outro. Temos até variações como {{Língua com nome}}. Precisamos padronizar isso.
• Rjclaudio ^msg 02h18min de 14 de março de 2010 (UTC)

Agora entendi como funciona. Assim, a forma como o Claudio explicou pode ser útil, mas não seria melhor adaptar a {{código língua}} com um switch para que não seja mais necessário colocar um "=1" no parâmetro? A {{ling}} poderia ser ajeitada para isso, sem ser dependente da primeira, que poderia ser depreciada e apagada futuramente. – Opraco (discussão) 03h00min de 14 de março de 2010 (UTC)

Embora concorde que {{ling}} se pode confundir com outras predesf.s, acho que deve ter um nome bastante curto, pois em certos artigos pode ser muito usada e torna-se complicado e confuso usar um nome comprido. Não se ganha muito em dispensar apenas o "=1". --Stegop (discussão) 07h20min de 14 de março de 2010 (UTC)

Campos de infobox

Resumo conforme a discussão vai prosseguindo:

• "nascimento_data" , o mesmo para morte / local -> primeiro assunto, depois tipo
• _ no lugar de espaço
• minúsculas
• nome por extenso
• "_n" para campos numéricos, para aceitar valores a moda inglesa, que na predef terá o formatnum e o nowrap
• imagem / imagem_tamanho / imagem_legenda / imagem_alt desmembrando o campo imagem.

Em discussão

• |país= ou |nacionalidade= ? E uso de |nascimento_local=

---

Devo começar os testes para inserir/preencher as infoboxes usando meu scriptAWB, só que pra isso seria bom os campos das infoboxes terem um certo padrão.

Pegando apenas nascimento/morte de biografia, temos "nasc" x "nascimento" x "n" + "data" antes x "data" depois, dando 3 x 2 = 6 combinações, além dos casos em que só tem 1 campo tanto para data como para local.

Queria padronizar então para todos os campos de data de nascimento estarem com o mesmo nome: "data_nasc". O mesmo para "local_nasc", "data_morte" e "local_morte".

Seria feita edição nas infoboxes primeiro para aceitar esses campos como a forma padrão, mas também as outras variações que estiverem em uso na infobox enquanto os afluentes não forem arrumados.

Concordam? Rjclaudio ^msg 18h41min de 14 de março de 2010 (UTC)

Concordo e acho que devia ter sido feito desde sempre: campo com a mesma função nome igual. Acho inclusive que deveriamos ter um padrão para as imagens, pq umas vc tem que colocar [[Ficheiro:Imagem.svg|tamanho]], e noutras tem os campos para colocar só o nome da imagem, outro pro tamanho, outro pra legenda (o que me parece mto melhor, não sei se para o AWB seria tbm).--Lépton ^✉ 19h09min de 14 de março de 2010 (UTC)

Essa da imagem é o ideal, pq pega o erro do checkwiki de imagens sem legenda já que a própria infobox colocaria a legenda. Incluir tb um novo campo q tá virando moda agora: imagem_alt (texto alternativo para imagens). Pra imagens já vi "imagem x img x foto" e "tamanho x tam". Eu prefiro a abreviação para não deixar os campos mt largos: img, img_tam, img_leg, img_alt.

O problema dessa padronização é que para separar os campos de imagem em 4 e de nasc/morte em 2 precisa arrumar os afluentes assim que mudar a infobox, senão vai dar erro nos artigos. Então é uma padronização mais trabalhosa e demorada. Talvez uma força-tarefa da coordenação robótica ajude a resolver logo isso.

Pensei em padronizar tb o campo que fica no topo da infobox, o campo |nome, q por vezes é |título outras é |bairro (se a infobox for para bairros, por exemplo).

Temos os campos nascimento/morte, imagem, e o campo principal. Mais algum outro para a lista?

Rjclaudio ^msg 19h16min de 14 de março de 2010 (UTC)

• Eu só tenho uma duvida/pergunta em vês de se escrever com traço (data_nasc etc) não será melhor elimina-lo (data nasc etc)? É muito mais pratico para escrever, não entendo o porque de se ter que usar o traço. À alguma razão lógica para isso ou é só uma questão de gosto? Eu pelo menos não gosto nem acho prático. Pelo Poder do Z ^{Alaf Ogimoc} 20h24min de 14 de março de 2010 (UTC)

Sim, boa pergunta. Não sei o pq do _ , qnd comecei achava que era alguma limitação do software, fiquei com essa ideia na cabeça. mas agora vejo que não é. Se não tem motivo, por mim tiramos o _ e fica só o espaço mesmo. Por mim fazemos isso em todos os campos de predefinições, para termos um padrão único e ser fácil de mudar com o awb. Rjclaudio ^msg 20h38min de 14 de março de 2010 (UTC)

• Acho uma excelente ideia normalizar os nomes dos argumentos, não é nada prático ter que andar constantemente a conferir se é titulo ou título, etc. Talvez por hábito de programador, embirro com "_", espaços e acentos (diacríticos) nos nomes de "variáveis", pois tornam o código menos claro e complicam a vida com buscas em muitos editores. Será que é tão grave usar, por exemplo, datnasc ou datanasc em vez de data_nasc ou "data nasc"? --Stegop (discussão) 21h51min de 14 de março de 2010 (UTC)

• • Eu acho mais claro "data nasc" que "datanasc". Talvez nesse exemplo não tenha mt diferença, mas pode ter casos que a junção atrapalhe, e aí deixar alguns campos com espaço e outros sem vai ficar pior ainda.
  • Não tenho opinião formada sobre os acentos. Tendo a preferir com o acento, já q é o nome correto e é o que as pessoas (novatos, por exemplo) vão tentar primeiro, sendo a padronização mais fácil de ter aceitação. Nesse caso dos acentos, se escolher pela padronização sem acento todas as predefs terão que aceitar os dois tipos de campo, com e sem acento. Mas se escolher pela padronização com acento isso só será necessário mesmo aceitar o campo com acento, ficando o sem acento como opcional para casos específicos e predefs extremamente usadas (como a Citar web).
  • Outro ponto é a inicial. Inicial maiúscual ou minúscula? Essa é outra variação do código. Maiúscula x minúscula, junto x com espaço x com _, com x sem acento, são 2 x 3 x 2 = 12 opções de campos. A padronização dos nomes é algo urgente, ao meu ver. A separação dos campos em 2 ou 3 campos já fica como secundário (importante, mas secundário).
  • Rjclaudio ^msg 23h05min de 14 de março de 2010 (UTC)

Acho óptimo a padronização sugerida! Em relação a maiúscula / minúscula inicial, eu optava por minúscula, até porque facilita a vida a algumas pessoas com dificuldades motoras. --João Carvalho ^{deixar mensagem} 23h34min de 14 de março de 2010 (UTC)

• Separador / não separador - concordo que haverá casos em que não suar separador causa confusão e que é preferível que se opte entre usar sempre ou nunca usar. Embora concorde que o espaço é mais prático do que o "_" para separador, continuo a preferir o "_", por ser mais claro.

• Acentos - sou contra o seu uso, pois são fonte de confusão, porque nem todos sabem onde e quando os usar, nomeadamente nestes tempos de Ao, elas diferenças entre pt-pt e pt-br, e porque é ligeiramente mais complicado de digitar. No entanto, não vejo problema na criação de "sinónimos".

• Maiúsculas - Não vejo qualquer utilidade em usá-las; mais uma vez, complica ligeiramente a digitação.

• Também concordo que a padronização é urgente.

• Embora nem eu próprio esteja certo da praticabilidade/ergonomia disso, será que não se devia ponderar a aceitação de datas com dia, mês e ano separadamente por causa da padronização de formato? --Stegop (discussão) 23h37min de 14 de março de 2010 (UTC)

• A vantagem não precisa explicar: com um padrão não precisamos ficar procurando qual o nome certo, e facilita bastante pros bots.
• Será trabalhoso apenas a fase de preparação, ao arrumar o nome dos parâmetros nas infoboxes. Dá pra usar um script para varrer as infoboxes e listar apenas as que precisam ter algum parâmetro arrumado. Depois com regras de awb específicas para isso fazer as alterações, criando o campo novo e mantendo o opcional para o antigo. Os casos que sobrarem (apenas alguma variação rara de |datanascimento= nas infoboxes de pessoas) será feito manualmente.
• Pra mim por enquanto o principal são as infoboxes, pro uso dos bots, as outras podemos fazer posteriormente já q vai precisar de mais trabalho manual.
• Depois de arrumado as infoboxes só colocar a regra no meu sciprtAWB e podemos esquecer o assunto, com o tempo isso vai sendo arrumado sem urgência.
• As regras de divisão de parâmetro, como imagem, nascimento, e data, já são complexas e imagino se será prático fazer isso, já q o nome do campo será igual antes e depois da mudança. Um script para ordenar as infoboxes por afluente ajudaria a aplicarmos a padronização nas infoboxes menos usadas, e deixar as mt usadas para o final depois q tivermos mais experiência no assunto e ter dado tempo para toda a discussão necessária.
• Pras datas, tb não tenho certeza. Testando meu script para aplicar a {{nascimento}} e {{falecimento}}. Tendo a apoiar a divisão do campo, por permitir colocar a idade no campo nascimento (se tiver vivo) ou no campo morte (se tiver morto) e fazer o link para a seção correspondente no artigo das efemérides. Se tiver a divisão desse campo precisamos de um nome menor: nasc_d nasc_m nasc_a morte_d etc ? Como os nomes serão diferentes, podemos manter o campo atual funcionando como opcional (dando preferência pro novo), assim podemos mudar a predef sem problema no artigo e colocar a regra no awb tb.
• Rjclaudio ^msg 00h35min de 15 de março de 2010 (UTC)

Já que se vai mexer nas infobox's, sugiro que se pense também em argumentos numéricos que aceitem valores "inglesa", para que sejam formatados com {{formatnum}} (ver "#Argumentos numéricos de predefs e sua formatação"). Ainda há bocado estive tentado em fazê-lo para uma, mas achei preferível esperar por esta discussão sobre nomes de argumentos. Qual acham que deveria ser a regra para os nomes desses argumentos? Acrescentar _n ao nome já existente (p/ex: população_n, área_n, etc.)?

Estou na disposição de ajudar no trabalho de programação, mas suponho que o melhor é indicarem-me umas quantas predef.s para eu tratar. --Stegop (discussão) 01h53min de 15 de março de 2010 (UTC)

Fico na dúvida entre manter dois campos pra mesma coisa ou ficar só com um. Eu tendo a usar só 1 campo, com um texto oculto explicando pra colocar a moda inglesa (e explicando as diferenças). Assim também ensinamos aos novatos como fazer, já q isso pode acabar sendo usado em outros lugares tb. A desvantagem é ter q esperar para atualizar as predefs junto com os artigos. A regra pra essa conversão já tenho praticamente pronta (tava testando uma para aplicar a {{formatnum}} no texto do artigo - não deu certo, mas depois trabalho de novo nisso. Rjclaudio ^msg 02h20min de 15 de março de 2010 (UTC)

Concordo que o ideal era ter só um campo, mas como é que consegue automatizar a conversão do que já existe? Como é que o código vai descobrir se o ponto e a vírgula são o separador decimal ou de agrupamento? Eu lembrei-me doutra coisa, mas é algo deselegante: começar novas predef's, pôr o AWB a substituir as existentes e acabar com as existentes quando não houver afluentes. --Stegop (discussão) 02h28min de 15 de março de 2010 (UTC) --Stegop (discussão) 02h28min de 15 de março de 2010 (UTC)

Pra maioria dos campos dá pra saber pela ordem de grandeza. Uma população de 10,2 pessoas é meio impossível. Se tiver "mil" do lado tb dá pra saber, pq não será separador de milhar. Se tiver ponto e vírgula fica fácil. Ou só vírgula. Tem mts casos que dá pra pegar. O difícil será pegar os casos em que não for mudar. Precisaria de um estudo dos campos pra ver se dá pra fazer uma regra boa pra isso. Se der o bot arruma, se tiver chance de não pegar algum caso, aí é awb revisado (tenta arrumar, na maioria das vezes consegue, se não conseguir o usuário arruma).

Talvez dê pra fazer um meio termo, que seria o mais rápido. Um script analisando todos os afluentes para verificar se algum campo que tenha ponto ou vírgula não será alterado. Se isso acontecer, o script separa esse artigo em uma lista a parte, para depois ele ser corrigido manualmente.

Sou contra criar uma outra predef, pq pra isso seria preciso mudar o nome. Aí qnd o awb arrumar os afluentes, os artigos terão predefs com nomes diferentes, e depois precisaria passar pelos artigos voltando o nome pro normal. Devemos evitar uma edição só pra isso, se possível.

Rjclaudio ^msg 02h46min de 15 de março de 2010 (UTC)

Particularmente não gosto dessas abreviações (data nasc, dnasc, etc) prefiro o "nascimento_data" e "nascimento_local" (com o "_" mesmo, que facilita identificar o que é parâmetro do que é texto). Mas obviamente é minha visão. Acho difícil alguém escrever parâmetro a parâmetro da predefinição. Normalmente se "rouba" de outro artigo ou da documentação da predefinição e se preenchem os dados (eu, pelo menos, faço assim). Quanto ao "novo" parâmetro o ideal é fazer como foi feito na {{Info/Campeonato de futebol}}: existia o "publico" (sem acento) e criei o "público" (com acento). No primeiro o que vier, é exibido. No segundo se usa o {{formatnum}} e se usa para cálculo automático da média (se outro parâmetro - público_jogos - for informado). Além disso, removi da documentação o parâmetro antigo. Assim, ninguém usa mais ele e vamos ajustando a predefinição ao poucos (o que está com o "antigo", fica como está). Abraços Mwaldeck ^msg 19h01min de 15 de março de 2010 (UTC)

• Em predefs com muitos argumentos, como infobox's, até acho preferível nomes compridos, mas noutras, dá imenso jeito que os argumentos sejam curtos. Se houver padronização, por exemplo com dnasc, não vai haver confusão e passa até a não ser assim tão complicado fazer o input separado de ano, mês e dia (dnascd, dnascm, dnasca).

• Como já disse, não gosto de acentos em nomes de argumentos, mas pior ideia que isso é usar a variante com e sem acento para distinguir o uso de {{formatnum}}.

• A ideia de suprimir da documentação o parâmetro antigo é muito boa.

• Dica: sugiro que se "embrulhe" o {{formatnum}} em <div nowrap="true">, para que não haja quebra de linha no meio do número formatado. Ex: <div nowrap="true">{{formatnum:{{{1}}}}}</div>^{(ver nota)} --Stegop (discussão) 20h01min de 15 de março de 2010 (UTC)

• ^(nota) Correção: <span style="white-space:nowrap;">{{formatnum:{{{1}}}}}</span> --Stegop (discussão) 21h19min de 15 de março de 2010 (UTC)

• Vamos discutir apenas sobre as infoboxes, que reduz as questões da mudança pq todo mundo só copia+cola o código de algum lugar. Assim mts problemas de dificultar a escrita por ser _ ao invés de espaço acabam.
• Agora que o Mwaldeck falou, concordo com o _ pra diferenciar do texto. Principalmente quando os campos tem mt conteúdo e passa para a linha de baixo no código, o nome do campo fica meio misturado. Com o _ ele fica mais destacado do texto.
• Tb fico com o Mwaldeck sobre o nome completo. Isso facilita para os novatos saberem imediatamente pra que serve aquele campo. E como na infobox só se copia nada se cria, não atrapalha.
• Como será o padrão na ordem dos nomes? "nascimento_data" ou "data_nascimento" ? eu prefiro "nascimento_data", primeiro vindo o assunto (data) e depois o tipo (nascimento), assim como temos imagem_tamanho, imagem_legenda (primeiro assunto imagem, depois tipo tamanho/legenda).
• Rjclaudio ^msg 16h52min de 16 de março de 2010 (UTC)

Para os biografados, usamos |país= ou |nacionalidade= ? |país= tem a vantagem de ser o mesmo campo para todas as infoboxes, e |nacionalidade= faz mais sentido quando o biografado tem duas nacionalidades. Qual devemos usar? Rjclaudio ^msg 18h18min de 16 de março de 2010 (UTC)

Pensei em um bom modo para desmembrar o campo imagem. A predef vai usar {{{imagem|}}} caso o campo |imagem_tamanho não seja preenchido, e usar [[Ficheiro:{{{imagem|}}}{{!}}{{{imagem_tamanho}}}]] caso o campo tamanho seja preenchido. Assim as infoboxes com o modelo antigo continuarão a valer enquanto se desmembra o campo usando o bot. Que acham? Rjclaudio ^msg 18h23min de 16 de março de 2010 (UTC)

Por que não aceitar ambos? Exemplo:

• {{#ifexist:Media:{{{imagem|}}}|[[Ficheiro:{{{imagem}}}|{{{imagem_tamanho|200px}}}|center|{{{nome|{{PAGENAME}}}}}]]|{{{imagem|}}}}}

Daemorris ^discussão 20h42min de 16 de março de 2010 (UTC)

• Sim, estava vendo isso agora na Info/Biografia. Trocaria Media: por Ficheiro: Concordo com isso.
• Dá pra incluir um campo para texto alternativo? Um |imagem_alt= ? Como ficaria o código?
• Se ninguém for contra podemos já ir aplicar isso em todas as infoboxes. Rjclaudio ^msg 20h46min de 16 de março de 2010 (UTC)

Concordo com tudo. Só faltam os nomes dos argumentos para os números "à inglesa". O mesmo dos já existentes com sufixo "_n"? --Stegop (discussão) 21h12min de 16 de março de 2010 (UTC)

• Pro país do biografado, como fica? |país= ou |nacionalidade= ? Se o campo for |nacionalidade= ele não será usado para colocar o local de nascimento, devendo ser incluído o país no |nascimento_local= . Se o campo for |país= a predef pode colocar o país junto ao local de nascimento.
• Pode ser com "_n" mesmo. Melhor que a diferença ser por acento ou outra qualquer. Esse é o modo mais prático. Como disse, colocar texto oculto explicando uso do ponto, vírgula, espaço.
• Coloquei um resumo no início da seção
• Rjclaudio ^msg 21h28min de 16 de março de 2010 (UTC)

Quer que eu ajude nalgum(ns)? --Stegop (discussão) 21h39min de 16 de março de 2010 (UTC)

• Assim que acabarmos as discussões vou programar o awb para passar nas infoboxes em modo bot para fazer isso. Isso reduz bastante as correções a fazer. Depois sim vamos precisar de ajuda pra terminar o serviço.
• Mas então, país ou nacionalidade?
• Rjclaudio ^msg 21h50min de 16 de março de 2010 (UTC)

• Não sei se percebi a questão nacionalidade/País mas, acho que nacionalidade e País, são coisas diferentes. A nacionalidade até pode ser dupla ou trípla, enquanto país de nascimento é um só, mas isso vai aparecer em "|nascimento_local=" , penso eu. Será País se for referência a local de residência, ou no caso de "|nascimento_local=" se referir só a localidade , então país pode referir-se a "país de nascimento" . --João Carvalho ^{deixar mensagem} 22h23min de 16 de março de 2010 (UTC)

Perguntei pq tenho visto infoboxes com |nascimento_local e com |país. E artigos com |nasc_local= apenas com o estado, e colocando o país apenas no |nacionalidade= . É pra colocar |nacionalidade= em todas as infoboxes de biografias então? E retirar o |país= colocando no |nasc_local= ? Rjclaudio ^msg 23h02min de 16 de março de 2010 (UTC)

Rjclaudio, na minha opinião é isso. Com duas linhas, defines por exemplo: (|nasc_local= localidade, país) e (|nacionalidade= Argentina / Espanha), ou seja, ficamos a saber que nasceu na localidade XX do país YY e tem nacionalidade YY e AA (ou só YY). --João Carvalho ^{deixar mensagem} 23h11min de 16 de março de 2010 (UTC)

Acabei de descobrir que existem traduções para o português das funções usadas em predefs, como #se no lugar de #if e #seigual em vez de #ifeq. Tem outras em Ajuda:ParserFunctions. Como as infoboxes serão mudadas, isso pode ser útil para facilitar o entendimento de novatos. O que acham? – Opraco (discussão) 20h36min de 20 de março de 2010 (UTC)

Acho que isso só vai aumentar a confusão. Aposto que a maior parte dos que se "atrevem" a mexer, pelo menos de forma conscienciosa, em predefs deve ter um conhecimento mínimo de programação e/ou de inglês e o "if" é bem mais usual do que o "se". --Stegop (discussão) 21h02min de 20 de março de 2010 (UTC)

Novo padrão de nomenclatura

Tenho adotado esse modelo de nomenclatura para predefs que inserem tabela no artigo: "Tabela/". Assim, movi {{Infobox Clima}} para {{Tabela/Clima}}. Sugiro adotarmos esse padrão. Deve ter outras predefs do tipo, mas não me lembro de nenhuma agora. E tb que riemos uma "Convenção de nomenclatura" para predefinições, alguém disposto? Rjclaudio ^msg 00h28min de 1 de abril de 2010 (UTC)

Concordo.--Lépton ^✉ 00h07min de 3 de abril de 2010 (UTC)

Unificação de {{Citar ...}}

Já há muito que ando a ruminar esta ideia, que já expus superficialmente pelo menos nestas discussões: [3] e [4]...

Apesar do pouco interesse que isso parece suscitar, continuo a achar que acho que se devia tentar dar alguma ordem nas predef.s de referências.

Analisando a tabela abaixo, que compara os diversos argumentos daquelas que me parecem as predefs mais relevantes, acho que se pode concluir que a maior parte das funcionalidades, pelo menos as mais usadas e menos "subtis", já são implementadas por {{Citar web}} e a "minha" proposta para a substituir ({{Stegop/Citar web}}) vai ainda mais longe nesse sentido.

Embora ciente que se possa vir a revelar demasiado complicado, quer tecnicamente, quer em termos de consenso da comunidade, a unificação completa de todas as predefs, quero crer que uma {{Citar web}} mais genérica, baseada ou não numa expansão de {{Stegop/Citar web}}, responderá a maior parte das necessidades de muitos editores, que ficariam assim dispensados de ter que estar familiarizados com 6 predefs que, embora sendo muito semelhantes, cada uma tem pequenas diferenças em termos da nomenclatura de argumentos.

Ciente do potencial de polémica que acabar com predefs que provavelmente resultaram de discussões aturadas, não me atrevo a propor tal coisa, mas por outro lado não vejo porque há-de haver muita oposição à criação de uma predef que possa ser utilizada, por quem o preferir, para citar tanto sites como periódicos, enciclopédias, livros, notícias e artigos.

Quero ainda chamar a atenção para a lacuna, a meu ver com alguma gravidade, de atualmente a {{Citar web}} não ter um argumento "ligação inativa", o que impossibilita a marcação de url's que não estão operacionais.

Nota quanto a {{Stegop/Citar web}}: esta predef foi tanto um exercício de treino de programação para mim como uma tentativa de "modularizar" e de minimizar a duplicação de código em {{Citar web}}. Como autor, não estou em posição de saber se o consegui fazer, mas, pelo menos para mim, será mais fácil de implementar qualquer expansão do que no código de {{Citar web}}.

Quadro comparativo de argumentos usados nas principais predefs para referências:

• baseado apenas na documentação, pelo que alguns argumentos podem estar omissos;
• estão também omissos de {{Stegop/Citar web}} os sinónimos/abreviaturas de argumentos e de indicação e formatação de datas através de dia, mês, ano separadamente, as quais podem ser consultadas na documentação incipiente;

{{Stegop/Citar web}}	{{Citar web}}	{{Citar enciclopédia}}	{{Citar periódico}}	{{Citar notícia}}	{{Citar livro}}	{{Referência a artigo}}
acessoano	acessoano	acessoano		acessoano
acessodata	acessodata	acessodata	acessodata	acessodata		acessadoem
acessodia
acessomes	acessomesdia	acessomes		acessomesdia
ano	ano	ano	ano	ano	ano
arquivodata	arquivodata			arquivodata
arquivourl	arquivourl			arquivourl
			aspas
autor	autor	autor	autor	autor		autor
autorlink	autorlink	autorlink	autorlink	autorlink
citacao	citação	citacao		citacao
coautores	coautores	coautores	coautores	coautores
data	data	data	data	data
doi		doi	doi
		edicao			edicao
editor		editor
formato	formato		formato	formato		formato
		id	id	id	id
isbn
			issn
		local	local		local
ligação inativa
lingua	língua	lingua	idioma	lingua	idioma	língua
lingua2	lingua2		lingua2
mes	mes	mes	mes	mes
			numero
obra	obra	enciclopedia	jornal	obra
			oclc
paginas	paginas	paginas	paginas	paginas	paginas
			pmid
primeiro	primeiro	primeiro	primeiro	primeiro	nome
publicado	publicado	publicado	editora	publicado	editora	editora
					subtítulo
titulo	título	titulo	titulo	titulo	titulo	titulo
ultimo	ultimo	ultimo	ultimo	ultimo	sobrenome
url	url	url	url	url	url	url
						versão
		volume	volume		volume
					volumes

--Stegop (discussão) 01h26min de 16 de abril de 2010 (UTC)

Eu tentei fazer isto há uns meses atrás numa página de testes, logo apoio completamente a iniciativa. A meu ver a maneira mais simples é utilizar a {{Citation/core}}, como na wiki anglófona, com essa tabela fica fácil definir os parâmetros em si. Em uma primeira etapa podemos manter as nomenclaturas de predefinições intactas, que é a alteração que acho mais complicada de passar, e apenas transferir as funcionalidades para uma única, citei a {{Citation/core}} como exemplo, mas podemos utilizar algo como {{Citar/código}}, desde que a unidade se mantenha. Também podemos redirecionar todas documentações para uma única, que demonstre exemplos de cada tipo de citação que pode ser feita, mas utilizando apenas uma predefinição, ex. {{Citar}}. Daemorris ^discussão 04h32min de 16 de abril de 2010 (UTC)

Não conhecia a {{Citation/core}} da pt. Lembro-me de ter olhado para a da en e ter ficado assustado com a complexidade. :-8 --Stegop (discussão) 13h22min de 16 de abril de 2010 (UTC)

Eu sou adepto de fundir todas as predefinições deste tipo numa só e acho que {{Citar}} seria o ideal. Pelo Poder do Z ^{Alaf Ogimoc} 17h06min de 16 de abril de 2010 (UTC)

Como funcionaria a coisa? preciso de exemplos...--Lépton ^msg 19h31min de 16 de abril de 2010 (UTC)

• Concordo com a fusão numa possível {{citar}}, mas alguns dos argumentos propostos têm problemas. Por exemplo,"publicado" não faz nem nunca fez qualquer sentido, quando muito seria "publicado por" ou, preferencialmente na minha opinião, "editora". Faltam também parâmetros importantes, e por vezes essenciais, como "volume", "número", "capítulo", "urlcapítulo" e "página".--- Darwin ^Ahoy! 22h23min de 30 de junho de 2010 (UTC)

Aquilo que está no quadro não são sugestões, é o que existe... Ou existia há uns meses, a acreditar na documentação... A minha {{Stegop/Citar web}} foi um bocado um delírio meu, se bem que acho que pode ser aproveitada por causa de estar muito estruturada, o que, pelo menos quanto a mim, facilita as alterações. --Stegop (discussão) 22h36min de 30 de junho de 2010 (UTC)

Por mim podes fazer a fusão logo que queiras. Em relação às predefs de citação para livros e periódicos, eu jamais usei nenhuma dessas, pois são extremamente incompletas, recorrendo sempre à {{citation}} que é bem mais prática, além de permitir a integração com a {{harvnb}} e outras similares, melhorando imenso a referenciação dos artigos.--- Darwin ^Ahoy! 22h49min de 30 de junho de 2010 (UTC)

A falta de documentação é o que dá: eu julgava que {{citation}} era mais uma da muitas traduções feitas "à paposseco", possivelmente incompleta... Vou ver se me inspiro para unificar aquela tralha toda... --Stegop (discussão) 22h54min de 30 de junho de 2010 (UTC)

Não, não, a {{citation}} é bem mais "profissional" que essas daí, e até penso que deveria ser usada como matriz para o formato dessa nova predefinição, já que segue uma ordem e estilo de formatação largamente utilizada em obras de referência e guias de formatação universitários, ao contrário dessas "citar" que sempre me pareceram ter um ar meio amador e esculhambado, com os itens por vezes aparecendo numa ordem ilógica e difícil de ler na secção de referências do artigo..--- Darwin ^Ahoy! 23h11min de 30 de junho de 2010 (UTC)

Já que vamos reformular a coisa, é bom melhorar o que já tá aí, aproveitando que está-se com a mão na massa. Melhor uma discussão mais longa e com mais usuários, que tal um tópico na esplanada ou uma subpágina neste projeto? Neste último caso melhor anunciar. Esta última pág tá mto grande já.--Lépton ^msg 00h08min de 1 de julho de 2010 (UTC)

Tem também a {{Citar bíblia}}. --Mister Sanderson 15h53min de 17 de abril de 2011 (UTC)

Novamente as Datas

Descobri que existem uma série de predefs sobre datas que fazem basicamente o mesmo:

{{data}}, {{dtlink}}, {{dtext}}, {{nascimento}}, {{falecimento}}, {{dni}} (e se calhar à mais)

Porque não se altera a mais usada para suportar as outras e se descontinua as outras?

Pelo Poder do Z ^{Alaf Ogimoc} 07h47min de 26 de abril de 2010 (UTC)

Pelo que percebi {{data}}, {{dtlink}}, {{dtext}} podem ser fundidas sem problemas; {{nascimento}} já tá depreciada (foi fundida na dni); e acho que o resto pode ficar separado por uma questão de afluentes e facilidade de uso. Ficariam então: {{data}}, {{falecimento}} e {{dni}}.--Lépton ^msg 09h47min de 26 de abril de 2010 (UTC)

Eu só trocaria o nome de dni -> nascimento. {{nascimento}} e {{falecimento}} tem diferença em relação a genérica de datas ao colocar o link direto para a seção de nascimento/falecimento da efeméride, por isso melhor ficarem separadas mesmo. Rjclaudio ^msg 12h38min de 26 de abril de 2010 (UTC)

Zorglub e Lépton, viram em detalhe o que cada uma delas faz? Lá por serem iguais no texto que produzem, não quer dizer que façam a mesma coisa. Por sinal, {{dtext}} nem sequer na forma é igual às outras. Suponho que {{data}} poderia ser fundido com {{dtlink}}.

Rjclaudio: Por mim até preferia {{nasc}}, pois não gosto de nomes grandes e o {{dni}} passou a ter pouco sentido desde que passou a poder não mostrar a idade. No entanto, concordei e concordo com o Lépton que faz mais sentido manter {{dni}} por causa de ter muito mais afluentes, o que tb. quer dizer que é muito mais conhecida. --Stegop (discussão) 14h05min de 26 de abril de 2010 (UTC)

• Mais uma achas para a fogueira...

1. {{DataExt}} e {{Dtlink}} - Nomes à parte, parece-me evidente que devem ser fundidas. Questões: i) em caso de omissão de |lang, qual é o que vale? br, como em {{Dtlink}}, ou pt, como em {{DataExt}}?; ii) Qual o nome a adotar? É certo que {{DataExt}} é mais antiga e se a conhecesse não teria criado {{Dtlink}}, mas o nome desta parece-me melhor por denotar que linka a data.
2. {{Data}} - Ao contrário de todas as outras que conheço, a ordem dos argumentos é a-m-d. Não fosse isso, e o facto, que considero relevante em casos como estes, de predef.s "curtas", de requerer argumentos adicionais para não mostrar o dia da semana, era evidente que devia ser fundida com {{Dtlink}} e {{DataExt}}.
3. Acho que seria útil criar uma predef que, por via de argumentos, fizesse tudo o que fazem todas elas, {{dni}} e {{Falecimento}} incluídas. No entanto, não me parece boa ideia acabar com as variantes de uso mais simples. Uma solução possível, que garante simultaneamente padronização, simplifica as alteração de todas elas e mantém a facilidade de uso, é criar a "complicada" e pôr as outras a evocá-la com os argumentos adequados. --Stegop (discussão) 02h27min de 29 de abril de 2010 (UTC)

Concordo. Daemorris ^discussão 03h18min de 29 de abril de 2010 (UTC)

1- veja o ponto 2 abaixo.

2- verifiquei os afluentes, as 3 tem no máximo 100 afluentes cada. Sou a favor de se reformular a {{data}} para abranger {{dtext}}, ela já abrange parcialmente {{dtlink}} e {{dataExt}}, pelo que só falta os parâmetros |idade e |lang=br para a fusão estar completa:

• {{data}} - 1 de janeiro de 2000
• {{dtlink}} - 1 de janeiro de 2000
• {{dataExt}} - 1 de janeiro de 2000

Com o parâmetro |sem link (|sl) abrangeria {{dtext}} também.

Fundiria tbm {{data/hora}} adicionando o parâmetro |hora.

3- já tinha pensado nisto, mas cheguei a conclusão que não valeria a pena, mto complicado. Mesmo que seja possível, melhor deixar dni e falecimento separadas justamente pela simplicidade. O povo vai reclamar se fundirmos tudo numa só, não tenho dúvidas. Ademais, não vejo necessidade de algo assim.--Lépton ^msg 11h58min de 29 de abril de 2010 (UTC)

É muito bonito apresentar só parte das funções levando as pessoas a pensar que a {{data}} faz o mesmo que as outras quando é falso. Não só não faz o mesmo que a {{DataExt}}, predef para apresentar uma data por extenso, com wikilinks para o dia/mês e ano. Tem alternativas para apresentar a idade (se for incluído |idade) e a variante linguística (se for incluído |lang=br). O dia e o mês podem ser omitidos, como é menos prática. No entanto estou de acordo que se fundam as três (quatro com a data/hora), mas reformulando a DataExt, ou seja inserir os parâmetros em falta (acrescentar o dia da semana como opção + a hora como opção) e passa-la para Data. Pelo Poder do Z ^{Alaf Ogimoc} 12h33min de 29 de abril de 2010 (UTC)

Aff, acalme-se e leia direito o que eu escrevi.--Lépton ^msg 12h39min de 29 de abril de 2010 (UTC)

• Pormenores importantes para os quais não há sugestões: i) quais os nomes das predef.s fundidas; ii) qual são os formato de defeito (br, pt, dma, amd); iii) manteem-se as predef. atuais como simplificação da fundida ou não? eu repito que acho que se devem manter. --Stegop (discussão) 14h48min de 29 de abril de 2010 (UTC)

i) {{dtlink}}, {{dataExt}}, {{dtext}} e {{data/hora}} (as 4 fundidas na {{data}}) ii) melhor deixar pt, eu gosto e prefiro dma, mas se a maioria quiser amd... iii) não vejo pq, a sintaxe será a msm, com exceção da {{dtext}} (vai precisar de |sl) e {{data/hora}} (vai precisar de |hora).--Lépton ^msg 15h10min de 29 de abril de 2010 (UTC)

Acabei de achar {{data2}}, que produz o msm resultado de {{data}}, mas como posso não estar percebendo alguma coisa, vejam se está redundante msm.

• data - sexta-feira, 24 de maio de 2024
• data2 - 24 maio 2024
  

--Lépton ^msg 15h51min de 29 de abril de 2010 (UTC)

{{Data2}} não costumava mostrar o dia da semana. Mudaram... (veja a documentação, que não alteraram) Daemorris ^discussão 22h05min de 30 de abril de 2010 (UTC)

O que exatamente está faltando para a fusão ser feita? Isto tá a quase 1 mês parado.......--Lépton ^msg 19h19min de 26 de maio de 2010 (UTC)

Gente.--- Darwin ^Ahoy! 19h21min de 26 de maio de 2010 (UTC)

Gente pra fundir ou gente pra concordar? Me parece obvia a fusão.. mas já que vc está aqui, poderia dar sua opinião.--Lépton ^msg 19h31min de 26 de maio de 2010 (UTC)

Dificuldade em infoboxes

não consigo alterar as seguintes infoboxes para {{Info}}:{{Info/Organização}}, {{Info/ONU}}. tem trocar as cores de fundo desta predefinição {{Info/BD asiática}} apenas digitando o subtítulo? e nesta {{Info/Livro}} como faz pra colocar rodapé?, é preciso usar caixa info?Hyju (discussão) 03h39min de 3 de maio de 2010 (UTC)

Nas duas primeiras predefinições, provavelmente, é só você copiar o conteúdo do style="", e colocar no parâmetro {{{título-estilo}}} da {{Info}}. Com relação à {{Info/BD asiática}}, acredito que você vai precisar desenvolver um pouco mais a pergunta, não entendi exatamente o que você pretende. Seria que dependendo do que for especificado em {{{subtítulo}}} a cor de fundo mude? Vai depender da implementação, as comparações teriam que ser totais (usando {{#ifeq:}}, talvez com {{lc:}}). Daemorris ^discussão 12h56min de 26 de junho de 2010 (UTC)

Tamanho das imagens em {{Vgratings}}

Não encontrei nenhuma determinação impondo que o tamanho de todas as imagens deva ser 25 pixels. Com esse tamanho, o texto destinado à classificação ocupa um espaço desproporcional nas infoboxes, como pude constatar no artigo Passione.

Tentei alterar isso, mas estou sendo sistematicamente revertido, sem que ninguém explique porque deva ser utilizado esse tamanho.

Aguardo os comentários

Flávio, o Maddox ^{(msg! • contrib)} 12h39min de 18 de maio de 2010 (UTC)

Novamente a {{Info/Assentamento}}

Chamo a vossa atenção para este tópico na coordenação robótica, onde está a ser contestado o uso da Info/Assentamento para padronizar as infoboxes de localidades (pelo menos algumas) por obrigar à inserção da área no sistema imperial, obrigatoriedade derivada de, pelo que li, o software da wikipédia não permitir o cálculo de valores que usam a vírgula como separador decimal. É estranho que depois de tanto tempo de existência e utilização desta predefinição só tenham contestado isso agora, e a meio de um trabalho de correcção e melhoria de localidades, mais aí está. Agradeço as vossas opiniões.--- Darwin ^Ahoy! 17h26min de 25 de maio de 2010 (UTC)

Não percebo essa de "obrigar à inserção da área no sistema imperial". Podes dar um exemplo? --Stegop (discussão) 17h57min de 25 de maio de 2010 (UTC)

Claro. A Info/Assentamento só calcula automaticamente a densidade populacional se a área estiver introduzida usando o ponto como separador decimal (sistema imperial de medidas). Na verdade nem é essa predefinição que calcula a densidade, mas uma outra que essa chama. Ao procurar forma de resolver isso nas outras wikipédias não só não encontrei qualquer predefinição que faça a conversão do sistema métrico para o imperial, como encontrei esses avisos de que o software não faz correctamente os cálculos quando a vírgula é usada como separador decimal, pelo que os dados têm de ser introduzidos com o ponto a separar as casas decimais, mesmo nos países que usam o sistema métrico.--- Darwin ^Ahoy! 18h04min de 25 de maio de 2010 (UTC)

Deixa ver se percebo: o "auto" só usa as variáveis "imperiais"? Ou estás a chamar "imperial" ao formato numérico em que mil mil e duzentos mais três décimas se escreve: 1200.3? --Stegop (discussão) 18h18min de 25 de maio de 2010 (UTC)

As duas coisas: Esse é o sistema imperial, e o auto só funciona com ele, pelos testes que fiz. Se tiver a vírgula dá erro.--- Darwin ^Ahoy! 19h24min de 25 de maio de 2010 (UTC)

Não dá para fazer o que eu fiz em {{Info/Distrito da Turquia}}? Eventualmente, criando argumentos novos com outro nome para indicar a área e a população, como o que eu fiz em {{Info/Município de Portugal}} (população_n e área_n), o que me permite ir atualizando sem estragar os que ainda não estão atualizados. --Stegop (discussão) 02h17min de 26 de maio de 2010 (UTC)

Não creio que alguém se oponha fortemente ao uso do ponto ao invés da vírgula na infoxbox, visto que os ganhamos com a automatização de cálculos e com a formatação dos números (hoje em dia pode-se encontra nos artigos 10.000, 10 000 e 10000, por exemplo...). O que geraria conflito seria a obrigatoriedade de inserção de dados em outro sistema de medidas (como as jardas), ou o período de transição do uso de vírgula para o uso do ponto, pois os vários artigos que já utilizam a infobox teriam problemas. Esse sistema já é usado nas localidades dos EUA e não lembro de ter visto rejeição pois antes não havia infobox semelhante. Giro720^msg 02h47min de 26 de maio de 2010 (UTC)

Stegop, um problema desses argumentos provisórios é o provisório passar a ser definitivo. No caso passaria a ser usado um novo argumento "area_n" em vez do argumento mais simples. De qualquer modo, uma vez que a densidade estava a ser alterada para o cálculo automático, essa necessidade nem se punha.

Giro, foi isso mesmo que eu pensei, que o ganho com a adaptação à nova predef, que passou a ser facilmente expansível, compensava largamente as alterações necessárias. E como neste momento só andamos eu e o Vagenau a mexer naquilo, nem pensei que alguém se fosse opor, já que o trabalho de alterar estava a ser meu e não interferia com o de mais ninguém. Se puderes vê a questão do brasão, que não fica centrado na Info/Assentamento, fiz um quebra-galho temporário para resolver isso, mas o que eu fiz (meter o brasão no lugar do mapa alternativo) não pode ser solução definitiva, e na predef correspondente da wiki-en isso não acontece.--- Darwin ^Ahoy! 08h51min de 26 de maio de 2010 (UTC)

(off topic) A Info/Assentamento, ela está um bocado... pobre... em termos visuais. Sinto falta de linhas de separação (filetes, como diriam os meus ex-colegas gráficos), uns alinhamentos diferentes, etc. Não digo isto como crítica negativa a quem a criou e tem trabalhado nela, pois está ali muito trabalho e muito bem feito. --Stegop (discussão) 18h20min de 26 de maio de 2010 (UTC)

Também era útil se desse para alterar a cor do topo, assim dava para configurar cores diferentes para cada tipo de infobox, como se usa agora nas infoboxes específicas que não chamam a Info/Assentamento. Não deve ser nada difícil, apenas acrescentar o parâmetro para a cor.--- Darwin ^Ahoy! 18h25min de 26 de maio de 2010 (UTC)

Giro, o problema de não calcular a virgula provavelmente deve-se aos servidores estarem configurados com as definições locais americanas. ´Creio que todos concordamos de que o ideal seria que todos os dados devam estar preferencialmente com o sistema métrico, por isso a questão que me incomoda prende-se com alterações do sistema métrico para o Imperial. Outro dado relevante, e que está relacionado com o parâmetro auto, prende-se com o facto de os dados relativos à população normalmente serem acompanhados pelos dados da densidade, ou seja, na prática, sempre que se actualizam os dados demográficos, automaticamente poder-se-à actualizar a densidade, sem recorrer ao cálculo pela predefinição. Entendo a utilidade do cálculo pela predef, mas te igualmente desvantagens. Uma delas é fácil de perceber: caso um vândalo altere o valor da área ou o valor da população, são afectados dois valores, se for inserido, sempre que possível o valor da densidade ser recorrer ao auto, pelo menos uma alteração dessas gera uma inconsistência mais fácil de reparar. Alchimista ^{Fala comigo!} 09h59min de 28 de maio de 2010 (UTC)

A facilidade de reparação é precisamente a mesma, e essa afirmação de que "os dados relativos à população normalmente serem acompanhados pelos dados da densidade"{{carece de fontes}}, no mínimo.--- Darwin ^Ahoy! 20h18min de 8 de junho de 2010 (UTC)

Nova versão de {{Coor dms}}

Se não houver erros nem oposição, acho que a maior parte, senão todas as predef.s de coordenadas podem ser unificadas/fundidas, pois a nova versão tem todas as funcionalidades. --Stegop (discussão) 07h15min de 17 de junho de 2010 (UTC)

Se a predef passar a receber também coordenadas decimais, como espero que passe, o nome "Coor dms" passará a induzir em erro, pelo que deve ser alterado. Porque não se usa a {{coord}} para isso, como fazem na wiki-en? Além do mais é bem mais simples e intuitivo.--- Darwin ^Ahoy! 12h57min de 23 de junho de 2010 (UTC)

Já não sei porque é que peguei na {{Coor dms}} e não noutra... Dado que na prática o que fiz, entre outras coisa, foi unificá-la com {{Coor dm}} e {{Coor d}}, ela já aceita coordenadas decimais, basta que não se usem os minutos e segundos. Nomes à parte, assim de repente, a única funcionalidade interessante que existe na {{coord}} da en que sinto falta (não muita, diga-se de passagem) é a possibilidade de indicar num formato e mostrar noutro. Note-se que a nossa {{coor dms}} atualmente faz tudo o que {{coord}} faz (e provavelmente melhor) e mais algumas coisas, embora a documentação (que eu limpei) prometesse tudo e mais alguma coisa. --Stegop (discussão) 17h25min de 23 de junho de 2010 (UTC)

Ah, excelente. Então nesse caso penso que o que deve ser feito é mesmo apagar a {{coord}} e mover para lá a {{coor dms}}, e redireccionar as outras todas para ali.--- Darwin ^Ahoy! 17h28min de 23 de junho de 2010 (UTC)

• Passadas umas semanas sobre a nova versão de {{Coor dms}} e relacionadas, acho que vou marcar uma série de predef.s de coordenadas para fusão com {{Coord}} após substituir o código desta pelo de {{Coor dms}}. O que acham? Será caso de fazer uma proposta na esplanada ou podemos decidir aqui?

• Tenho a impressão de que a maior parte do que está em Categoria:!Predefinições de coordenadas que não é passível de incluir nessa fusão não é usado, talvez porque são traduções ou codificações inacabadas ou porque a documentação não existe ou é incompreensível. Mas como não sei qual é o historial daquilo nem o fim com que foram criadas, não me vou por a dar palpites sobre o que fazer com elas. --Stegop (discussão) 18h54min de 9 de julho de 2010 (UTC)

Não vejo necessidade de levar isso à esplanada, até porque é uma questão mais técnica que outra coisa. Desde que a compatibilidade seja preservada, essa simplificação só é benéfica. No meio desse entulho que está na cat devem haver algumas predefs criadas por mim, mas julgo que já não precisarei delas depois dessa fusão.--- Darwin ^Ahoy! 19h51min de 9 de julho de 2010 (UTC)

---

Qual deverá ser o nome da predef genérica?

Ia começar com a fusão quando me dei conta que a {{Coord}}, cujo nome, concordo, a torna a mais lógica para ser a base para as que não podem ser simplesmente redirecionadas, tem uma estrutura de argumentos incompatível com {{Coor dms}}. E o pior é que essa estrutura não me parece adequada para uma predef flexível como tem que ser uma predef genérica, que responda à maior parte das necessidades. Em {{Coor dms}} só os graus teem que obrigatoriamente ter valores, mas teem que ser indicados pelo menos 7 argumentos (a longitude é assumida O/W caso não exista), isto é, por exemplo o 3º argumento é sempre os segundos da latitude. Já em {{Coord}}, pode haver apenas 6 argumentos: se existir o 8º arg, assume os valores são latG, latM, latS, etc.; caso contrário, assume que são latG, latM, latNS, etc.

Pode ainda haver outro problema: como a equivalente da en.wp admitia display=title(,inline), coisa que a documentação da pt.wp referia até há pouco tempo que também fazia, suponho que haverá casos em que, se se substituir o código pelo que está atualmente em {{Coor dms}}, a página terá duas coordenadas no título.

A {{Coor}} também tem uma estrutura diferente, mas como tem menos de 50 afluentes, é bem mais fácil de corrigir. No entanto, não me parece boa ideia alterar o comportamento de uma predef. Ou será que neste caso, em que é pouco utilizada, não haverá grandes problemas?

Ocorre-me pensar que o ideal seria, talvez, pôr um bot a retirar "title" das ocorrências atuais de {{Coord}} ou, melhor ainda, fazê-lo nos casos em que haja na página outra predef que coloque as coordenadas no título. No entanto, continuaria a haver o problema de alguns editores estarem habituados a usar só 6 argumentos.

Alguém tem sugestões? --Stegop (discussão) 21h49min de 16 de julho de 2010 (UTC)

[[Predefinição:Apagar]]

Só pra sentir o clima aqui, dps vamos pra esplanada. O q acham de mover esta predef para {{PE}} e {{eliminar}} para o título apagar? Ambas as moções são bons nomes, PE é bem conhecido, serve mto bem e não será difícil assimilar, e apagar é o nome mais óbvio qdo se quer participar de uma PE. Proponho isto tendo em vista que as PEs vão mudar para consenso ao invés de votação burra (ainda bem), então estas predefs serão mto usadas, e logo imagino a confusão de nego usando {{[[Predefinição:apagar|apagar]]}} ao invés de {{eliminar}} (ver exemplo).--Lépton ^msg 12h49min de 23 de junho de 2010 (UTC)

Desculpa lá, mas onde é que ouviste essa de as PEs passarem a ser por consenso? Não sei de nada. Pelo Poder do Z ^{Alaf Ogimoc} 16h41min de 25 de junho de 2010 (UTC)

Não será melhor esperar para ver o que dá a discussão? Não acho boa ideia que predef.s com funções diferentes tomem o nome de outras, por isso discordo da renomeação de {{tl|eliminar}} → {{tl|apagar}}. --Stegop (discussão) 17h07min de 25 de junho de 2010 (UTC)

Zorglub, vão, já existem propostas pra isto, e do que depender de mim tornar-se-ão realidade o mais breve possível, pq já passou da hora das PEs seguirem as regras e não uma votação matemática burra.
Stegop, leu o que eu escrevi? E lá pq estou sentindo o clima por aqui, não quer dizer que será implementado imediatamente....--Lépton ^msg 05h03min de 26 de junho de 2010 (UTC)

Predefinição:Alto uso e Predefinição:Alto risco

Proponho deixar somente a alto risco pq o critério pra se usar uma e outra é: de 2000 a 100,000 afluentes usar a alto uso, e mais que 100,000 alto risco. Critério completamente arbitrário e vai de encontro ao que diz Wikipedia:Predefinições em alto risco, para além de eu não concordar com tal disparate: só se tiver 100,000 afluentes é alto risco? o.O Além disto, o texto da alto uso serve para qualquer predef, já que não é só nas que tem muitos afluentes que se deve pesar as alterações. E se tem mtos afluentes, é alto risco. Mas se fizerem msm questão de se ter 2 avisos, um parâmetro na alto risco seria suficiente. Ou pode-se pensar num texto mais neutro.--Lépton ^msg 18h46min de 16 de julho de 2010 (UTC)

Concordo --Stegop (discussão) 21h22min de 16 de julho de 2010 (UTC)

Predefs de bandeiras

A propósito das predef.s de bandeiras (listadas em Wikipedia:Namespace predefinição/Países):

1. Por uma questão de padronização, proponho que as imagens não sejam referenciadas diretamente, mas sim com recurso a, por exemplo, {{BRAb}} no caso de {{BRA}}, {{BRAf}}, etc. Para isto basta que {{BRAb}} passe a aceitar opcionalmente o texto que deverá figurar em link e alt, o que tem a vantagem adicional de se poder ter outros usos não previstos.
2. No caso dos nomes-PT sejam diferentes dos BR, criar o argumento lang (opcionalmente sem nome) para mostrar o nome na variante desejada e poder acabar com os poucos e feios casos em que aparece, por exemplo:  Polónia. Se o editor desejar as duas variantes, usará, por exemplo, lang=2. --Stegop (discussão) 13h56min de 10 de outubro de 2010 (UTC)

Acho uma ideia interessante, da minha parte tem o meu apoio. Mais acho que também se poderia adicionar a opção de nacionalidade e eliminar as configs {{AGOn}}. Pelo Poder do Z ^{Alaf Ogimoc} 17h09min de 10 de outubro de 2010 (UTC)

Acho que percebi a opção "nacionalidade", mas o que queres dizer com "configs"? --Stegop (discussão) 17h17min de 10 de outubro de 2010 (UTC)

lol configs=configurações por outras palavras predefs=predefinições Pelo Poder do Z ^{Alaf Ogimoc} 18h44min de 10 de outubro de 2010 (UTC)

Normalização e unficação de predefs de línguas

Há quase um ano que trouxe aqui ou à esplanada este assunto e nada se adiantou entretanto. Mas estou cada vez mais farto de tropeçar em situações em que {{Código língua|xx=1}} existe, mas {{lang-xx}} não existe ou é diferente, etc. Também não se percebe porque é que {{Link/línguas}} não usa o mesmo código que {{Código língua|xx=1}}. Da forma como está atualmente, nem sei quantos sítios é que se teem que alterar quando queremos incluir mais uma língua. E depois acontecem aqueles casos ridículos de ter "espanhol" nuns casos e "castelhano" noutra. Acho que saber qual é o "mais certo" (pessoalmente já nem sei bem, embora em termos "legais espanhóis" e históricos, a segunda forma talvez seja mais correta), mas coexistirem as duas é que não faz sentido.

Qual é a minha ideia muito por alto?

• Centralizar a "conversão" do código ISO em nome da língua em {{ling}} (que atualmente apenas chama {{Código língua}}, cuja síntaxe não é nada prática)

• A prazo, acho que se poderia acabar com os {{lang-xx}}, criando antes uma genérica do tipo {{langx|cod. ISO}} (é pena que {{lang}} esteja ocupado, aceitam-se sugestões para alternativas a langx).

• De forma semelhante, (tentar?) alterar as mastodônticas {{link}}, {{link2}} e as que as suportam. --Stegop (discussão) 19h02min de 27 de janeiro de 2011 (UTC)

Nome do projeto, e lista de tarefas

A muito tempo que esse projeto já deixou de ser apenas uma padronização visual, para ser uma padronização de verdade, geral. Então posso mover as páginas pra Wikipédia:Projetos/Padronização?

Atualizei algumas coisas na lista de tarefas. Vou passar a usar mais ela. Podem rever as minhas alterações e comentar, e tirar da lista oq já foi feito?

Rjclaudio ^msg 21h02min de 12 de fevereiro de 2011 (UTC)

Por mim pode, até acho que está muito mais correcto. Pelo Poder do Z ^{Alaf Ogimoc} 21h49min de 12 de fevereiro de 2011 (UTC)

Padronização de campos (2)

Conforme discutido a quase 1 ano em Wikipédia Discussão:Projetos/Padronização visual#Campos de infobox, estive aplicando o padrão aos poucos, mas agora finalmente fiz o código pra awb e podemos passar em todas as infocaixas. Ver essa edição como exemplo.

Incluiu tb a {{Manutenção de predefinição}} por não achar um campo |nome= |título= |titulo= (concordam com essa padronização? sempre tem q ter pelo menos um desses 2 campos? Nada de |montanha= para colocar o nome da montanha.)

Rjclaudio ^msg 22h21min de 12 de fevereiro de 2011 (UTC)

Bom trabalho. Uma pergunta: a nomenclatura padrão de campos está em alguma página? Se não está deveria estar, pois padrão não documentado e ou mal publicado dificilmente será padrão de facto. Talvez aqui neste projeto... --Stegop (discussão) 21h49min de 16 de fevereiro de 2011 (UTC)

Substituição/padronização de {Info/Município da Espanha}

Ver Predefinição Discussão:Info/Município da Espanha#Padronização/ampliação --Stegop (discussão) 21h49min de 16 de fevereiro de 2011 (UTC)

Padronização de links de línguas

Estou a tentar unificar os links para verbetes de línguas baseadas em códigos ISO e da Wikipédia, algo que anda espalhado por uma série de predefs. Para isso refiz completamente {{Ling}}, que antes apenas chamava {{Código língua}}. {{Ling}} cria links para todos os códigos que constam em en:List of ISO 639-1 codes e en:Template:List of language names ordered by code mais os que existiam por aqui em {{Link/línguas}}.

Espero que não esteja a fazer asneira. Se estiver, agradeço que me expliquem o que fiz mal e não se limitem a reverter e a dizer que "está mal", pois é absurdo continuarem a existir várias formas de fazer a mesma coisa, com a consequente incoerência, confusão e redundância.

Uma das asneiras que já me dei conta foi que {{Ling}} deveria usar {{Língua}} em vez de escrever diretamente o nome das línguas.

Agradeço que me indiquem quais as predef.s que devem ser modificadas para passarem a usar {{Ling}}.

Há exatamente um ano e 3 dias (foi por acaso, mas até parece que foi de propósito) sugeri fazer isto mesmo aqui nesta discussão e já o propus noutras discussões. --Stegop (discussão) 05h59min de 17 de março de 2011 (UTC)

Já tenho uma proposta de meta-predef que acho que permite unificar/padronizar tudo quanto é nome e links de línguas mais usadas na Wikipédia. Está com 252 línguas. Podem ver e testar em Usuário:Stegop/Língua-meta. A minha ideia é que todas as predef.s padrão que envolvem nomes de línguas com ou sem links para os verbetes respetivos passem a chamar essa predef (a {{Ling}} modificada ontem incluída. Aguardo comentários e sugestões. --Stegop (discussão) 03h55min de 18 de março de 2011 (UTC)

Parece-me bastante bem. Já que estamos nisto, há uma questão que parece ter algum impacto na performance, segundo os desenvolvedores, que é o excesso de links nos artigos. A {{Ling}} pode eventualmente contribuir para isso se levar sempre o link. Há maneira de isso não acontecer? Só a primeira vez que a {{Ling}} é usada com um dado código de língua num artigo é que deve ter link, das outras não.--- Darwin ^Ahoy! 04h32min de 18 de março de 2011 (UTC)

Esta predef e a {{Ling}} não aquecem nem arrefecem isso, já que apenas são uma forma normalizada de construir os links. Mas isso de se poder indicar a língua através do código sem link já me tinha ocorrido - ultimamente faço sempre isso que dizes, de linkar só a primeira ocorrência de {{Citar web}}. E para isso, a metapredef pode ajudar, pois basta chamá-la com "nome" em vez de "link". Eu estava a pensar criar uma nova {{link}} ({{linkx}}?), pois acho aquela história de listas de códigos completamente obtusos e de manutenção complicadíssima (apesar de ontem já ter feito uma limpeza nas listas retirando os códigos únicos, que passaram a ser construídos com {{ling}}). A {{link2}} não é nada prática porque é uma seca e muito sujeito a enganos escrever |4=en|5=de, etc. Estava a pensar que, dado que não é seguro usar argumentos anónimos e não custa escrever |url=, |titulo= e |descri, essa nova   só teria como argumentos anónimos precisamente os códigos de língua. E como é uma predef nova, podemos criá-la de forma a que por defeito não linke as línguas, existindo um argumento próprio para o fazer quando for caso disso. Uma coisa que me parece simples e pacífico é criar, por exemplo, |lingua3 em {{Citar web}} e afins, que não crie os links para as línguas.

PS: Mas essa batalha contra os links supérfluos é árdua! Há uns meses "consegui" alterar o WP:LE para haver comedimento nos links em datas e anos, mas vai ver se alguém respeita isso, inclusive nas WP:EAD... Até as datas de acesso às fontes eles linkam! E quando se trata dos futebóis, das listas de episódios e outras coisas que tais, nem se fala, há mais azul e vermelho do que preto! --Stegop (discussão) 05h20min de 18 de março de 2011 (UTC)

• Parece-me que já fiz quase tudo o que tinha em mente para unificar a questão dos nomes, links e códigos de línguas. Recapitulando:

• {{Língua-meta}} é a metapredef de base de toda a estrutura e único local onde se devem alterar códigos, links e nomes de línguas.
• {{Link}}, que até há pouco era uma forma simplificada de usar {{Código língua}}, passou a ser uma forma simplificada de usar {{Língua-meta}}.
• {{Link/línguas}} evoca {{Língua-meta}}.
• {{Langx}} torna obsoletas todas as {{lang-XX}}, com o bónus de se poder indicar a variante (pt ou br) nos casos em que ela difere (ex: hy/armênio/arménio).

Embora não tenha diretamente a ver com as línguas, também tenho uma proposta para substituir ou ser alternativa a {{Link}}, {{Link2}} e também servir de base a tudo quanto é codificação de URL's: Usuário:Stegop/Link.

--Stegop (discussão) 05h33min de 27 de março de 2011 (UTC)

Parece-me muito bom mesmo, Stegop, sinceramente não me ocorre nada que possa ser acrescentado aí. Resta-me, somente, dar-te os parabéns pelo trabalho e excelente resultado.--- Darwin ^Ahoy! 05h42min de 27 de março de 2011 (UTC)

Unificação de {Citar ...} (2)

Voltando a discussão do ano passado mais acima. Usei o awb pra extrair todos os campos das predefs, e com o excel fiz a lista, manualmente fiz a correspondência, e etc etc etc. Bem, aqui está todos os campos com todas as variações. Contei 88 linhas. A predef resultante vai ficar grande hein.

Total	{{Citar entrevista}}	{{Citar periódico}}	{{Citar notícia}}	{{Citar vídeo}}	{{Citar web}}	{{Referência a artigo}}	{{Stegop/Citar web}}
Total de campos: 88	28	33	27	18	32	10	44
acessoano			acessoano	acessoano / ano de acesso	acessoano		acessoano / aca
acessodata	acessodata	acessodata	acessodata	acessodata / data de acesso	acessodata		acessodata / acdt / acesso_data /
acessodia							acessodia / acd
acessodiames			acessodiames		acessodiames		acessodiames
acessomes				acessomes / mês de acesso			acessomes / acm
acessomesdia			acessomesdia		acessomesdia		acessomesdia
ano	ano	ano	ano	ano	ano		ano
ano2				ano2
arq							arq
arquivoano							arqano / arqa
arquivodata			arquivodata		arquivodata		arquivodata / arqdt / arqdata
arquivodia							arqd / arqdia
arquivomes							arqmes / arqm
arquivourl			arquivourl		arquivourl		arquivourl
arquivourl datali					arquivourl datali
arquivourl inativo					arquivourl inativo / arquivourl li
autor		autor	autor		autor	autor	autor / aut
autores							autores
autorlink		autorlink	autorlink		autorlink		autorlink / autlink
bibcode		bibcode
callsign	callsign
cidade	cidade
citação		aspas	citacao	citação	citação / citacao		citacao / cit / quote
coautores		coautores	coautores		coautores		coautores / coaut
codling		codling					codling
curly		curly				curly
data	data	data	data	data	data	data	data / d / dt
datafmt							datafmt
datali					datali		datali
datasepar							datasepar
dia							dia
doi
data2				data2
doi		doi	doi		doi		doi
editor			editor		editor
editora		editora				editora
entrevistado	entrevistado
entrevistado2	entrevistado2
entrevistado3	entrevistado3
entrevistado4	entrevistado4
entrevistadolink	entrevistadolink
entrevistadolink2	entrevistadolink2
entrevistadolink3	entrevistadolink3
entrevistador	entrevistador
entrevistadores	entrevistadores
formato	formato	formato	formato	formato	formato	formato	formato / fmt
hora				hora
id		id
issn		issn
isbn							isbn
isbn2							isbn2
isbn3							isbn3
isbn4							isbn4
jornal		jornal
lang		lang
ligação inativa					li / ligação inativa		ligação inativa / li / ligação_inativa
língua	língua / lingua	língua / lingua / ling / idioma	língua / lingua	língua / lingua	língua / lingua	língua	língua / ling / lingua
língua2	língua2 / lingua2	língua2 / lingua2	língua2 / lingua2	língua2 / lingua2	língua2 / lingua2	língua2 / lingua2	lingua2
local		local					local
localização				localização
medium				medium
mes	mes	mes	mes		mes		m / mes
mês2				mês2
nome	nome	primeiro	primeiro		primeiro		primeiro
nome2	nome2
nome3	nome3
número		número / numero
obra			obra		obra		obra
oclc		oclc
páginas		páginas / paginas / página	paginas		páginas / paginas		páginas / paginas / pg
periódico		periódico
pessoas				pessoas
pmid		pmid
programa	programa
publicado			publicado	publicado por	publicado		publicado / pub
rotulodoi			rotulodoi		rotulodoi		rotulodoi
sobrenome	sobrenome	último / ultimo	ultimo		último / ultimo		último / ultimo
sobrenome2	sobrenome2
sobrenome3	sobrenome3
sobrenome4	sobrenome4
tipo	tipo			tipo
título	título / titulo	título / titulo	título / titulo	título	título / titulo	título	título / titulo / title / tit
trabalho			trabalho		trabalho
url	url	url	url	url	url	url
volume		volume					url
versão						versão

Temos que definir um nome definitivo para cada campo, e um nome abreviado. E arrumar as documentações, pq atualmente tem campo com várias ... variações (acesso, arquivo e data são os que tem mais). Acho que esse é o primeiro passo. Fazemos todas as predefs permitirem o campo padronizado e o abreviado, assim os novos usos já seguem o padrão, menos trabalho pra arrumar tudo depois. Eu sugiro que o nome completo padronizado seja o que está na primeira coluna. Alguém com outra sugestão?

Alguém interessado em criar a metapredef? Não precisamos fundir todas elas de uma vez só, podemos fundir duas hoje, daqui a mais três meses fundir mais uma, depois outra. Assim ao menos vamos fundindo. Pq do ano passado pra cá não tivemos nenhuma fusão (só um esboço de uma predef pra servir como base, q já é mt).

Podemos fazer a metapredef aos poucos. Fazemos uma só com autor/título/data (todas as predefs precisam desses campos). Aí colocamos essa metapredef nas citar. Pronto, o início delas já está certo. Depois vamos para acesso / arquivo / url. E depois pros campos opcionais de cada uma.

Preferem fazer como, por partes, duas a duas, ou tudo de uma vez só (que demora, trabalhoso, e quem sabe quando ficará pronto)?

Rjclaudio ^msg 17h34min de 24 de março de 2011 (UTC)

Não é por nada mas esqueceram-se da {{Citar livro}}. Pelo Poder do Z ^{Alaf Ogimoc} 23h18min de 24 de março de 2011 (UTC)

Além de {{Citar livro}}, também falta {{Citar enciclopédia}}.

Creio que o melhor é começar por tentarmos chegar a uma meta-predef de formatação e URL's genérica e depois ir unificando uma de cada vez. Não faço questão de que a metapredef seja baseada em {{Stegop/Citar web}}, mas na altura tentei construí-la de forma o mais estruturada possível (para ser mais fácil de manter/alterar e de utilizar), evitando a repetição de código para por sua vez evitar comportamentos díspares para as mesmas situações; não sei se consegui e é provável que tenha que ser muito melhorada.

Se fosse hoje, possivelmente não teria complicado tanto em termos de parâmetros a {{Stegop/Citar web}}, nomeadamente para a indicação de datas, mas como na altura se discutiam formatos de data, achei que fazia sentido tentar criar uma predef que suportasse diversos formatos. E como é uma metapredef, não há grande problema em manter essa "complicação", pois ela não tem que transparecer para as predef.s que a usam.

Uma coisa que acho que devia ser explorada antes de avançar com a unificação/padronização era explorar a {{Citation}}, coisa que eu nunca tive coragem para fazer. Se alguém que a conhece pudesse produzir a documentação... Mesmo que se chegasse à conclusão que o código é demasiado complicado para servir de base para trabalhar, pelo menos poderíamos aproveitar as funcionalidades.

Uma coisa que eu sinto falta com alguma frequência é a possibilidade de indicar mais do que um URL, por exemplo, para mais do que uma página da mesma obra, ou para uma ou várias cópias online de um livro ou um periódico; outra coisa que me parece que as predef.s que existem suportam mal é a situação comum de referenciar uma obra do editor X, que pertence à organização Y e que está disponível no site Z - qual é a "obra", "editora" ou "publicado" nestes casos? --Stegop (discussão) 03h00min de 25 de março de 2011 (UTC)

Eu nunca me entendi com a parafernália de predefinições que existem aqui, de modo que só uso duas: a {{cite web}}, para sacar refs da web, pois é uma applet do FF (eu até conseguia traduzir, mas nunca tive pachorra para isso), e sobretudo a acima referida {{citation}}, que desde que a descobri e trouxe para cá, se tornou para mim o santo graal das predefinições, pois faz tudo o que preciso em qualquer situação e nunca me deixou na mão. Por exemplo, nesse caso das múltiplas urls, preenche-se a citation com a url do livro e com a do capítulo, se existirem as duas, e depois na {{harvnb}} coloca-se a url para a página propriamente dita. Além da citation ser extremamente prática de usar, ainda dá um aspecto elegante e funcional às referências. O código é bastante complexo, por isso quando quero actualizar faço copy paste da wiki-en e pronto. Creio que também lhe fiz alguns ajustes, como para o caso acima citado de não mostrar link nos códigos de língua. Existe uma predefinição especialmente monstruosa cujo uso já devia ter sido banido, pois desformata as referências, a {{Ref-livro}}. Infelizmente essa porcaria é a que está disponível nos mybuttons para colocação de refs de livros, por isso até deve ser muito usada. --- Darwin ^Ahoy! 03h25min de 25 de março de 2011 (UTC)

Eu sinto deficiência no sistema de citação de textos da predefinição {{Citar web}}, por exemplo. Se uso uma mesma página como referência em vários trechos do artigo e coloco uma citação para cada trecho, a citação na referência não fica muito agradável de ser lida, fica bagunçada - não se sabe mais onde é a citação de cada trecho. E criar um referência para cada trecho inunda a seção de referência com páginas iguais, o que também não é legal. Eu não entendo muito de padronização visual, mas me parece que isto seria algo interessante de ser melhorado. No dia 20 abri na página de discussão da predefinição um tópico para discutir isto, mas não obtive resposta, infelizmente. --Mister Sanderson 15h44min de 25 de março de 2011 (UTC)

Não sei se percebi o seu problema, mas será que ele não se resolve usando <ref name="xpto">código da referência</ref> num dos locais do texto e <ref name="xpto" /> nos restantes locais onde a ref é usada? --Stegop (discussão) 23h00min de 26 de março de 2011 (UTC)

Assim uma mesma referência vai ser usada duas vezes, certo. Mas quando preciso citar um trecho na primeira vez que a usei e outro trecho na segunda vez (usando o campo citação)? Lá embaixo, nas referências, isto fica bagunçado. --Mister Sanderson 23h22min de 26 de março de 2011 (UTC)

Pode resolver isso usando {{nota de rodapé}} em vez da ref, e na nota de rodapé coloca a citação seguida da ref.--- Darwin ^Ahoy! 02h38min de 27 de março de 2011 (UTC)

---

Criei um protótipo de predef. para padronizar a criação de links: Usuário:Stegop/Link. A ideia é que todos os links passem a ser construídos pela mesma predef. Comentários são bem vindos. --Stegop (discussão) 23h00min de 26 de março de 2011 (UTC)

{{Info/Personagem de Naruto}}

Depreciei a predefinição acima em favor da Info/Personagem animangá (como pode ser visto na página de discussão). Entretanto, ela é usada em uma duzentas páginas, e eu não tenho condições de, sozinho, alterar todas. Os participantes do projeto animangá e animangá/naruto infelizmente não se preocupam com isto... Como proceder? --Mister Sanderson 23h30min de 24 de março de 2011(UTC)

Quer o meu conselho? Não se meta nisso. Esse projecto está associado ao BD, que coordeno, e já desisti de tentar o que quer que seja por lá. O loby animangá, só faz o que quer e tem poder que chega para isso. Pelo Poder do Z ^{Alaf Ogimoc} 23h58min de 24 de março de 2011 (UTC)

Não entendi. Não devo me meter com o projeto, com a depreciação ou com a substituição nos artigos pela "info/...animangá"? --Mister Sanderson 00h07min de 25 de março de 2011 (UTC)

O que quis dizer é que podes fazer o que te apetecer que eles não te ligam nenhuma, a menos que os contraries, ai não consegues fazer nada. Pelo Poder do Z ^{Alaf Ogimoc} 01h15min de 25 de março de 2011 (UTC)

Ah, já tive problemas com isto, mas atualmente já sei como lidar e contornar estas situações. A propósito, como esta depreciação não foi contrariada, parece-me que está tudo bem. --Mister Sanderson 01h41min de 25 de março de 2011 (UTC)

Pelo visto não há outra forma senão fazer "na mão". Que pena. --Mister Sanderson 13h29min de 27 de março de 2011 (UTC)

Claro que há, basta pedir na coordenação robótica a substituição. Se você quiser, se essa mudança é consensual, eu mesmo posso fazer isso com o meu bot.--- Darwin ^Ahoy! 13h33min de 27 de março de 2011 (UTC)

Na página de discussão da predefinição houve um consenso. Então, por favor, poderia substituir? --Mister Sanderson 13h52min de 27 de março de 2011 (UTC)

Basta mudar o nome ou é necessário fazer a correspondência entre os campos?--- Darwin ^Ahoy! 14h00min de 27 de março de 2011 (UTC)

É necessário fazer a correspondência. Lá na página de discussão eu já coloquei quais são os campos correspondentes. --Mister Sanderson 14h29min de 27 de março de 2011 (UTC)

Ah, alguns campos foram removidos da predefinição por um consenso anterior e precisam ser removidos simplesmente. (Como jutsu, peso, íris e aniversário). --Mister Sanderson 14h36min de 27 de março de 2011 (UTC)

Mais fácil fazer a Info/Naruto transcluir a Info/Personagem animangá (aí os artigos já ficam com o novo visual) e depois o bot só faz o subst (aí tb tira todos os campos desnecessários). Rjclaudio ^msg 14h43min de 27 de março de 2011 (UTC)

Boa sugestão. Nos próximos dias farei isto. --Mister Sanderson 14h52min de 27 de março de 2011 (UTC)

Já fiz a transclusão. Veja se está tudo certo. Não sei se o subst vai pegar direito pq tem ifs na predef, e se fizer subst talvez o if vá para o artigo (não tenho certeza). Tem q fazer o teste. Se não der, só copiar o código para uma página temporária xxx/temp, colocar um includeonly e subst no if, e trocar a Info/Naruto por subst:xxx/temp. Rjclaudio ^msg 14h57min de 27 de março de 2011 (UTC)

Pelo que vi, está tudo certo. Obrigado. --Mister Sanderson 15h03min de 27 de março de 2011 (UTC)

Transformar Info/Biografia em metapredef

Deixei aqui proposta para transformar a {{Info/Biografia}} em metapredef. Peço que deem uma olhada e comentem por lá. Rjclaudio ^msg 00h51min de 4 de abril de 2011 (UTC)

Nova predef (Lk)

Dado que numa semana ninguém comentou, criei {{lk}}, que pretende ser uma alternativa mais completa a {{link}} e {{link2}} e que talvez possa vir a ser usada para tudo quanto é construção de link. --Stegop (discussão) 14h23min de 4 de abril de 2011 (UTC)

interessante. Hyju (discussão) 01h37min de 11 de abril de 2011 (UTC)

Fusão das predefinições Info/Jogo de tabuleiro e Info RPG

na wiki anglófona a predefinição en:Infobox game é usada tanto para jogo de tabuleiro, quanto para RPG, aqui temos a {{Info/Jogo de tabuleiro}} e {{Info RPG}} proponho uma fusão das duas, adicionando novos campos relacionados ao RPG (adicionar alguma coisa da {{Info/Jogo}}, como a licença) e fazer algo parecido com a {{Info/Banda desenhada}}, no que se refere a rodapés (Porta:Jogos e Portal:RPG), seria bom se no topo tivesse um dado para diferenciar o tabuleiro do RPG. a Info Jogo devia se referiar a jogos comuns e não a Video games, na wiki anglo card game como o Magic: The Gathering usa a mesma predefinição "Infobox game". Hyju (discussão) 01h50min de 11 de abril de 2011 (UTC)

Padronização de predefinições de caixa informativa

Animangá

Olá editores! Recentemente padronizei as predefinições {{Info/Bleach}} e {{Info/Bucky}} com {{Info/Personagem animangá}}. Gostaria de saber o que pensam. --Mister Sanderson 13h53min de 16 de abril de 2011 (UTC)

Agora também {{Info/Personagem One Piece}}. --Mister Sanderson 19h04min de 16 de abril de 2011 (UTC)

Outro editor padronizou a {{Info/Personagem de Pokémon}}. Eu padronizei a {{Info/Personagem Star Wars}} com a {{Info/Personagem fictícia}}. --Mister Sanderson 15h33min de 17 de abril de 2011 (UTC)

Seria bom padronizar o nome das infobox de personagem. Algumas são "Info/Personagem de série" outras "Info/Personagem série", outras "Info/Série", com 3 modelos fica difícil achar a predef. Rjclaudio ^msg 16h12min de 17 de abril de 2011 (UTC)

De fato seria bom mesmo. --Mister Sanderson 16h33min de 17 de abril de 2011 (UTC)

a {{Info/Livro}} é mais complicada, tem muitos campos, quando as predefinições de personagens, o certo seria "{{Info/personagem de}}", tem que colocar mais categorias infoboxes, tem categorias de predefinições que ficam difícil de saber quais são navboxes e quais são infoboxes, fora que muitas não estão categorizadas no lugar certo, na predefinição/doc entre junto com as interwikis em <includeonly></includeonly>. Hyju (discussão) 02h18min de 18 de abril de 2011 (UTC)

Corrigi o nome de {{Info/Shurato}}, {{Info/Bleach}}, {{Info/Bucky}}, {{Info/Personagem CDZ}} e {{Info/Fullmetal Alchemist}} (assim como suas respectivas documentações), mas estou sem tempo para corrigir os redirecionamentos nos afluentes e eliminar o nome antigo (tarde demais, preciso dormir). --Mister Sanderson 02h59min de 18 de abril de 2011 (UTC)

As páginas de documentação e discussão já foram apagadas e entrei com um pedido na coordenação robótica para correção dos afluentes, a fim de eliminar o redirecionamento. Além disso, coloquei a "Animangá" dentro da "Shurato", onde havia antes apenas a "Info". --Mister Sanderson 17h09min de 19 de abril de 2011 (UTC)

Outras

Seria interessante padronizar a {{Info/Livro}} com a {{Info}}. --Mister Sanderson 15h52min de 17 de abril de 2011 (UTC)

Três predefinições para personagens de Ursinho Pooh:{{Info/Personagem de Ursinho Puff}}, {{Info/Personagem de Ursinho Pooh HD}} e {{Info/Personagem de Ursinho Pooh 2}}, a predefinição personagen fictícia tem que ter mais campos livres.

na {{Info/Personagem Star Trek}} dever usada o campo tv, na {{Info/Personagem da Bíblia}} e {{Info/Personagem Tolkien}} romance e por aí vai. Hyju (discussão) 03h16min de 18 de abril de 2011 (UTC)

Hyju, todas as infoboxes devem seguir o padrão de nomenclatura e começar com "Info/", assim fica fácil saber qual predef é infobox e qual é navbox. Se encontrar alguma infobox q não segue esse padrão por favor faça a movimentação. Sobre as cats, não vi nenhuma cat de infobox que tenha mais de 50 páginas então não creio ser necessário desmembrar alguma cat para criar mais subcats, pq sou contra cats de apenas 2 ou 3 páginas. Mas como deve ter infobox por aí que não está na cat de infobox, esse número pode estar errado. Fazendo a categorização de tudo veremos se vai precisar mesmo criar novas cats. Rjclaudio ^msg 14h52min de 18 de abril de 2011 (UTC)

entendi, deviam ser fundidas as predefinições {{Info/Escritor}} e {{Info/Autor}}. Hyju (discussão) 21h16min de 18 de abril de 2011 (UTC)

Predefinição:Tópico de continente

Criei essa metapredefinição para as várias navboxes de tópicos de continentes (Tema de Continente, linkando os artigos dos temas de cada país do continente). Ela chama uma predef específica de cada continente, como Predefinição:Tópico de continente/África. Apliquei essa nova metapredef nas páginas dessa cat. Gostaria que dessem uma olhada, se tem algo que posso expandir para pegar mais navbox, se posso continuar aplicando no resto, se o layout da predef está correto, essas coisas. Rjclaudio ^msg 17h01min de 18 de abril de 2011 (UTC)

Pedido para uso do AWB

Criei um pedido aqui. --Mister Sanderson 14h34min de 21 de abril de 2011 (UTC)

Referências com {{Citar web}}

Olá editores! Gostaria que, se possível, pudessem me tirar esta dúvida. A predefinição citar web é usada no artigo Governo Dilma Rousseff‎, mas de forma diferente das recomendações da predefinição: a data, o título e o autor ficam todos no mesmo campo título. Quando separei estas informações nos campos adequados e adicionei data de acesso, minha edição foi questionada justificando-se que deixei de uma forma pouco utilizada em outros artigos, tirei a padronização que já estava feita e deixei de forma medonha, e que há vários tipos de padronização existentes na Wikipédia. Disse que os artigos destacados usam a predefinição da forma que alterei e que a documentação da predefinição recomenda que seja utilizada da forma que fiz. Gostaria de saber se estou fazendo errado. --Mister Sanderson 19h22min de 22 de abril de 2011 (UTC)

Existem de facto várias formas de efectuar uma referência, e todas elas são aceites, no entanto algo é bem claro, dentro de um mesmo artigo, todas elas devem ser iguais. Já agora no artigo em questão, estão um nojo, todas elas, pois não seguem nenhuma norma, a não ser se calhar a que está na cabeça de quem as lá colocou. Pelo Poder do Z ^{Alaf Ogimoc} 20h20min de 22 de abril de 2011 (UTC)

Se for usar a citar web deve usar ela de acordo com a documentação. Usar ela de outra forma é criar outro padrão já que ela foi feita para aplicar uma padronização específica.

Se existem várias formas de fazer referência então precisamos de uma página listando todas elas. Senão daqui a pouco teremos milhares de formas diferentes sem controle algum.

Esse formato do artigo sou contra pq o link fica na referência toda, impedindo de, por exemplo, colocar o link interno quando a fonte da notícia é relevante.

Rjclaudio ^msg 20h28min de 22 de abril de 2011 (UTC)

Rectifiquei as refs da introdução, agora é só seguir a mesma estrutura. Pelo Poder do Z ^{Alaf Ogimoc} 20h33min de 22 de abril de 2011 (UTC)

Obrigado. --Mister Sanderson 20h38min de 22 de abril de 2011 (UTC)

Obrigado também. Eu questionei a edição de MisterSanderson. Saudações a todos!!!--Justus (discussão) 22h50min de 22 de abril de 2011 (UTC)

Wikipédia:Esplanada/propostas/Data nas infobox de eventos (25abr2011)

Proposta para padronizar as datas nas infoboxes de eventos (de modo geral serve para todo campo de data de infobox). Rjclaudio ^msg 15h20min de 25 de abril de 2011 (UTC)

Geocoordenada e infobox

{{AP|[[WP:CR#Geodata}} É melhor as infoboxes terem um campo "coordenada" e usar alguma das predefs tipo {{coord}} ou a infobox ter os campos |latd= |latm= |lats= |latNS= e ela mesma aplicar a coord e qualquer outro parametro necessário (tipo regionx, inline, titleshow, sei lá mais oq tem)? Rjclaudio ^msg 19h13min de 25 de abril de 2011 (UTC)

Prefiro o 1º caso. A predefinição teria o parâmetro "coordenada" e o usuário informa {{Coord|blá|blá|blá...}}. Trazer os parâmetros da {{Coord}} para a predefinição limita e, se alterarmos a {{Coord}} temos que modificar todas as predefs. Acho que perdemos a flexibilidade no 2º caso. Abraços Mwaldeck ^msg 21h45min de 26 de abril de 2011 (UTC)

Flexibilidade: qualquer flexibilidade é feita pelos campos extras das coordenadas além da latitude/longitude (campos que estão na {{coor dms}} mas não na {{coord}}), e esses campos seriam preenchidos pela infobox. Não consigo pensar em nenhum caso que exija uma flexibilidade maior que por assunto, não há motivo para um artigo específico estar diferente de outro artigo com a mesma infobox.

Quantidade de edições: no modo 2 há baixo risco (difícil mudar os campos para latitude/longitude) de editar 0,1% a mais das páginas se tiver mudança (as predefs). No modo 1 será preciso editar 90% das páginas (pra preencher todos os campos extras) + médio risco de editar 100% das páginas se tiver mudança nos campos extras (mudança nos campos extras exige editar tudo)

Rjclaudio ^msg 01h52min de 27 de abril de 2011 (UTC)

Tb. não vejo qual é a perda de flexibilidade. Por outro lado, uma das funções da infocaixa é padronizar, logo nem sequer tem muito sentido flexibilizar. Como o RJClaudio apontou, a {{Coor dms}} (ao contrário da obtusa {{Coord}}, mal importada "à paposseco" da en), permite indicar qual o "sufixo" do URL na chamada do geohack, pelo que qualquer "flexibilidade" pode ser implementada incluindo um parâmetro com esse sufixo. No entanto, a bem da padronização, possivelmente nem isso é muito boa ideia. --Stegop (discussão) 09h29min de 27 de abril de 2011 (UTC)

Eu prefiro os termos latG/latM/latS/latP/lonG/lonM/lonS/lonP, que são os termos usados na {{Info/Freguesia de Portugal}}, pois não tem os termos latd, longd e longEW que são em inglês, e não precisaria modificar os artigos com os termos antigos, seria só deixar as duas opções. E também acho que todas infoboxes com as coordenadas preenchidas deveriam colocá-las no topo do artigo por padrão em vez de ter que colocar "|coord_título=sim" como é pedido na {{Info/Assentamento}}. ^Danilo.mac_(discussão) 20h10min de 27 de abril de 2011 (UTC)

Já comentei sobre exibir o topo, o padrão deve ser exibir. Se realmente pensarem em algum caso que seja preciso ocultar aí usamos algum campo para isso.

A {{Info/Assentamento}} usa |latd = |latm = |lats = |latNS = |longd = |longm = |longs = |longEW = . Pessoalmente até prefiro esse, pra facilitar o relacionamento com outras wikis, e pq tem o latNS aí já sei que esse é o campo que coloca N ou S. Mas pra mim tanto faz, contanto que exista um padrão preferido (para ser o modelo na criação dos artigos), e concordo em não precisar editar os campos pra converter de um modo pra outro, que sirva os dois.

Rjclaudio ^msg 20h28min de 27 de abril de 2011 (UTC)

Campos nome para pessoas

Seguindo o padrão principal_característica, padronizando nome_outros, nome_completo, nome_nascimento. Entendo que há casos de troca de nome mas é mesmo necessário ter os dois campos nome_completo e nome_nascimento ou basta um deles (e qual)? Rjclaudio ^msg 15h16min de 27 de abril de 2011 (UTC)

Suponho que, embora raros, haverá casos em que o "nome de nascimento" pode ser diferente do "nome completo". Em contrapartida, atendendo a essa raridade e a outros casos incomuns, que tal se se mantivesse apenas "nome_completo" e se criasse "nome_alt", "título_nome_alt"? Assim ficava mais abrangente. --Stegop (discussão) 15h44min de 27 de abril de 2011 (UTC)

Vendo todos os "outros nomes" tem vários: outros nomes, conhecido como, apelido, nick, pseudonimo, nome de batismo, nome de nascimento, nome completo. Tem predef com a opção de usar qualquer um desses campos, talvez até os 8 ao mesmo tempo. Como fica os campos?

Então pra nome teremos apenas |nome= e |nome_alt= . E o rótulo do |nome_alt= será |nome_alt_tit= (se vazio usar Nomes alternativos). Tendo mais de um nome alternativo, usar o br. Assim?

Rjclaudio ^msg 16h10min de 27 de abril de 2011 (UTC)

Embora a opção me pareça pouco elegante, se calhar é a única forma da metapredef conseguir suportar todos os casos: em vez de existir somente um nome_alt, existirem mais (6? 10?). Embora não fique muito elegante, talvez se possa criar rótulos de defeito (ex: Nome de batismo. --Stegop (discussão) 17h06min de 27 de abril de 2011 (UTC)

Depois de reescrever isso aqui 5 vezes, farei uma proposta:

nome, nome_completo, nome_nascimento seriam obrigatórios em todas as infoboxes de pessoas. Passarei o awb pra incluir em todas.

nome_conhecido seria usado para o nome oficial do assunto: pra um gamer o nome oficial é o nick, nome de guerra, nome fantasia, pseudonimo, etc, são todos usados no lugar do nome quando estão no contexto (jogo, luta, guerra, ... diversão proibido para menores). Cada predef colocaria o próprio rótulo para esse campo (se for de gamer, o rótulo será "nick" mas o nome do campo continuaria como nome_conhecido). Como varia com o assunto, nem todas as predefs teriam esse campo.

Os artigos teriam apenas esses 4 campos, e cada infobox colocaria o rótulo do nome_conhecido de acordo com o seu tema ou deixa o valor padrão "Conhecido como". A {{Info/Biografia}} teria o campo nome_conhecido_tit para ser usado apenas pelas infoboxes nunca pelos artigos, e uma variação extra só por segurança pro futuro, nome_conhecido2 e nome_conhecido_tit2.

Todos os outros campos seriam fundidos em um desses quatro. E uma recomendação para as infoboxes só usarem outros campos se não puderem usar o nome_conhecido.

Rjclaudio ^msg 19h02min de 27 de abril de 2011 (UTC)

Wikipédia:Coordenação robótica/Localidades

Está sendo iniciado na Coordenação robótica um esforço para usar os bots para padronizar os artigos de localidades. Nessa etapa inicial isso significa arrumar as infoboxes. Peço aos interessados que vigiem a página / discussão. Rjclaudio ^msg 23h51min de 29 de abril de 2011 (UTC)

{{Info/Automóvel}}

A predefinição linkada acima não usa a Info em seu código. --Mister Sanderson 16h20min de 27 de maio de 2011 (UTC)

Agora usa.--Mister Sanderson 00h11min de 1 de junho de 2011 (UTC)

{{Info/Hino}} e {{Info/Estádio}} também não. --Mister Sanderson 03h36min de 25 de junho de 2011 (UTC)

A {{Info/Presidente}} também não usa. --Mister Sanderson 03h45min de 25 de junho de 2011 (UTC)

Adiciona {{Manutenção de predefinição|meta=info}} na parte do noinclude dessas predefs que faz a categorização em Categoria:!Infocaixas que não usam a metapredefinição. Já temos nove ali, a tendencia é aumentar. Rjclaudio ^msg 13h03min de 25 de junho de 2011 (UTC)

Feito. Passarei a fazer isto de agora em diante. --Mister Sanderson 15h46min de 25 de junho de 2011 (UTC)

-moz-border-radius

Olá editores! Venho aqui sugerir que, quando forem fazer suas edições, alterem -moz-border-radius para border-radius. O comando anterior foi obsoletado pela mozilla, como se pode ver aqui. --Mister Sanderson 00h56min de 6 de junho de 2011 (UTC)

Seguindo as recomendações desta página, fiz esta alteração. Muitas outras infocaixas usam a forma antiga, seria interessante corrigir. --Mister Sanderson 17h00min de 13 de julho de 2011 (UTC)

Link para edição em infocaixas

A {{Info/Hospital}} apresenta um link para edição do código da infocaixa, que eu removi a 5-jun por me parecer despropositado, inútil e até pouco recomendável, já que aumenta a probabilidade de edições desastrosas involuntárias por parte de editores menos experientes. No entanto, o link foi rapidamente reposto. Como quem repôs o link não me respondeu até agora, trago esse assunto à discussão.

Nota: a {{Info/Jornal}} também apresenta um link para visualização da página da predef, o qual me parece igualmente desnecessário. --Stegop (discussão) 15h01min de 10 de junho de 2011 (UTC)

A info/jornal leva para a página da predefinição, totalmente desnecessário. A info/hospital leva para uma edição da própria página, desnecessário também. --Mister Sanderson 15h07min de 10 de junho de 2011 (UTC)

A {{Info}} tem o campo |nome= que serve justamente para criar esse link para "ver" (não editar) a predef. Se tem na info então a princípio é permitido. Se não for necessário tem que remover o campo da info então.

Fico neutro nessa parte. As navboxes todas tem link para v e d , não chega a ser tão diferente (talvez seja, pela maior complexidade das infoboxes). Entendo que o link pra ver ajuda os mais experientes a editar a predef.

Rjclaudio ^msg 16h37min de 10 de junho de 2011 (UTC)

Para mim faz todo o sentido que as navcaixas tenham links para facilitar a edição delas, mas não as infocaixas. Isto porque, ao contrário do que é hábito por aqui, com a insistente mania de usar links vermelhos em páginas de navegação (desambigs é outro exemplo), as navcaixas devem refletir a realidade existente e não aquela que quem edita julga que poderá vir a existir. Ou seja, devem evitar-se links vermelhos nas navcaixas, para evitar as situações (muito comuns, por sinal), de ter links vermelhos para temas com verbete. Por essa razão, as navcaixas (deveriam?) têm tendência para sofrer muitas alterações, pelo menos enquanto não existem artigos relacionados com o tema. Pelo contrário, as infocaixas devem ser o mais estáveis possíveis, pelo que não tem sentido ter um link para edição. Isto para não falar no aspeto estético e na questão de padronização: ou todas têm ou nenhuma tem! --Stegop (discussão) 16h50min de 10 de junho de 2011 (UTC)

Além disso, as navcaixas são feitas para aquele tema em questão, logo, já tem valores preenchidos que eventualmente são alterados. As infocaixas normalmente são modelos em que os valores são preenchidos com textos diferentes em cada página em que é usada. Assim, um link que leva para a página da predefinição não parece útil, pois quem for levado para lá, na maior parte das vezes, não vai obter o resultado desejado, pois deseja editar as informações da infocaixa no artigo, não da infocaixa em si. Ou não? --Mister Sanderson 17h12min de 10 de junho de 2011 (UTC)

Depois dos argumentos, concordo em remover. Rjclaudio ^msg 17h40min de 10 de junho de 2011 (UTC)

Vamos lá (já que quem reverteu fui eu). A vantagem do "Editar" está em possibilitar a edição da seção 0 sem que se edite a página toda. Isso facilita a vida de quem atualizar somente a infobox, nem todos tem isso habilitado nas preferências (editar a seção 0). Isso também evita que, em se editando só a seção 0, altere onde não se deve, por exemplo, por desconhecimento. Ou seja, na minha visão, o "Editar" tem o efeito contrário, facilita a vida. Não vejo porque retirar algo que facilita a vida de alguém. Quanto ao argumento de que em outras wikis não tem, melhor não comentar. Abraços Mwaldeck ^msg 01h39min de 7 de julho de 2011 (UTC)

{{Mostrar previsão}} e {{Prev2}}

Olá editores! Não é meio redundante haver duas predefinições tão parecidas? Além disto, esta segunda quase não foi usada... Gostaria de discutir o futuro delas. --Mister Sanderson 17h20min de 14 de julho de 2011 (UTC)

Também acho desnecessário haver duas predefs para o mesmo efeito. No entanto, {{Prev2}} parece-me mais bem conseguida e eficaz que {{Mostrar previsão}}. --Stegop (discussão) 15h36min de 8 de agosto de 2011 (UTC)

Acho {{Mostrar previsão}} melhor que {{Prev2}}, exceto pelo fato de não estar enquadrada. No caso, o que você quis dizer com "mais bem conseguida"? --Mister Sanderson 18h30min de 8 de agosto de 2011 (UTC)

Essas mensagens de aviso não devem estar dentro de caixas, se não ninguém as lê. Eu lembro-me de receber as primeiras quando ainda era novato, odiei verdadeiramente aquilo e fiz o que qualquer novato faz. Se tivesse vindo em prosa normal não teria achado tão humilhante (ainda por cima uma mensagem que dizia "Nós agradecemos a sua contribuição, mas todos os artigos da Wikipedia devem cumprir nossos critérios de inclusão" sobre um artigo que eu achava perfeitamente idiota e queria eliminar. E para cúmulo, eu fui lá onde essa mensagem dizia para ir e dar a opinião, e recebi outra mensagem dizendo que afinal não podia, porque não tinha direito de voto. Se eu não fosse mais resistente que a praga dos 100 anos tinha mandado a wiki-pt para o caraculum na hora.).--- Darwin ^Ahoy! 18h37min de 8 de agosto de 2011 (UTC)

Se todos pensássemos da mesma maneira morríamos de aborrecimento... Pessoalmente acho a {{Prev2}} mais "bem conseguida" porque me parece mais eficaz visualmente para chamar a atenção para o problema. Mas não vou insistir, é um detalhe e tanto se me dá. E quanto ao teu caos, Darwin, não foi por "seres uma praga" que resististes, mas provavelmente porque estás habituado aos percalços usuais que qualquer recém-chegado tem quando entra num grupo ou comunidade. Sempre achei as praxes uma parvoíce, mas ao mesmo tempo percebo o seu fundo (muito deturpado) de "iniciação" - em qualquer sítio, por mais que se queira evitar, caloiro "tem" é humilhado e isso "faz parte". Salvo um ou outro abuso, a maior parte de quem se vai embora por causa dessas humilhações tem um problema de adaptação, pois a entrada em qualquer comunidade implica umas peripécias menos agradáveis e achar que aqui pode ser completamente diferente é mais uma dessas utopias que faz mais mal que bem. --Stegop (discussão) 18h54min de 8 de agosto de 2011 (UTC)

Pessoalmente tenho muitas dúvidas sobre a utilidade da maioria desses caixotões. O que me mandaram sobre a categorização era absolutamente críptico, por exemplo. Não sei se essas mensagens ajudam alguém, sinceramente. Eu nunca as mando, quando quero avisar um usuário de alguma coisa mando uma mensagem normal, e peço para ele me contactar se tiver dúvidas. Além da utilidade duvidosa, essas mensagens transformam as PDUs em verdadeiros campos de batalha após a batalha, dando logo uma má imagem do utilizador. Já vi casos em que isso funcionou como uma bola de neve, e acabaram bloqueando o usuário sem motivo algum, apenas pela aparência. Aliás, um deles está em discussão neste momento. É triste quando a "praxe" acaba dessa maneira. :\ --- Darwin ^Ahoy! 19h39min de 8 de agosto de 2011 (UTC)

{{Info/Associação}}?

Infocaixa criada por novata sem perguntar nada a ninguém, que não usa {{Info}}, que pouco ou nada adianta a {{Info/Organização}} e que nem sequer é usada em qualquer artigo. De acordo que a wiki é completamente aberta e livre, mas se as infocaixas pretende padronizar, não é nada bom que se permita a criação de infocaixas sem consulta à comunidade. Que se deve fazer nestes casos? --Stegop (discussão) 20h30min de 16 de setembro de 2011 (UTC)

Vi mal. Afinal já é antiga. Mas continuo a não ver qq. utilidade. Não se deveria enviar para eliminação? --Stegop (discussão) 20h34min de 16 de setembro de 2011 (UTC)

Concordo q é desnecessária. Enviaria para ER, mas depois dos problemas com eliminação de predefs q algum dia já foram usadas, já nem sei se pode. No mínimo um redirect pra evitar recriação. Rjclaudio ^msg 21h08min de 16 de setembro de 2011 (UTC)

O mais correcto é fundir as duas Infocaixas e criar um redirect. Pelo Poder do Z ^{Alaf Ogimoc} 22h08min de 16 de setembro de 2011 (UTC)

Proposta para uniformização de infoboxes de edifícios

Contexto

Esta proposta vem na sequência desta discussão para {{Info/Prédio}}, mas já há muito que reparo nisto mesmo antes de me registar. Penso que seja urgente chegar a um consenso sobre infoboxes de edifícios, porque neste momento na pt.wiki há uma grande dispersão, tanto a nível estético, como de ambiguações que de seguida vou demonstrar.

Problema actual nº 1: dispersão de infoboxes

Vamos tomar como exemplo paradigmático Mosteiro da Batalha. Um editor chega ali e que infobox escolhe?
{{Info/Prédio}} ? {{Info/Património Mundial}} ? {{Info/Monumento de Portugal}} ? {{Info/Edifício religioso}} ?

ou ainda as menos completas

{{Info/Patrimônio histórico}} ? {{Info/Templo católico}} ? {{Info/Sítio do Patrimônio Mundial}} ? {{Info/Museu}} ?

Pois, é complicado. Os campos que umas oferecem, outras não oferecem. Por exemplo, as de prédio e edifício religioso não oferecem campos para a protecção patrimonial, quando na maioria dos casos os edifícios e construções são notáveis por serem património. E as de protecção patrimonial, das quais a {{Info/Património Mundial}} é o exemplo maior porque é sempre a escolhida, nunca oferecem os dados básicos... quem construiu o edifício, quando, em que estilo...

Problema actual nº 2

A infobox {{Info/Prédio}}, que deveria ser o padrão para as demais, é demasiadamente extensa e com campos a mais. Eu sei que é copiada da Inglesa, mas mesmo assim a própria Inglesa é exagerada. Chega ao ponto de ter campos para a empresa de construção, empreiteiros de obras, altitude, empresa do restauro e por aí fora. Pensem nisto: em quantos casos é que aquilo vai ser tudo preenchido? Talvez em meia dúzia, talvez aqueles arranha céus novos onde se saiba tudo ao detalhe. Mas em 99% dos casos, vai ficar tudo por preencher.

Não seria mais lógico ter uma infobox mais simples, que não assustasse editores e que não ficasse sempre por preencher?

Mas gostava de deixar isto para outra discussão.

As propostas

Trago aqui duas propostas possíveis para resolução do problema. Ou melhor, uma é minha, outra foi inspirada pelo Stegop, mas que também me parece viável. Tudo muito resumido é: optamos pelo modelo francês ou inglês?

1. O modelo francês

O modelo francês divide. Ou seja, não existe uma infobox para "prédio" ou "edifício". Obriga o editor a escolher uma de várias infoboxes já feitas e tem obrigatoriamente de escolher um tipo de edifício (ver o link). A vantagem é que já está tudo definido e padronizado e raramente admitem alterações.

Gosto particularmente da estética e da padronização adoptada. Visualmente, é o mais apelativo e estruturado de todas as wikis.

Seguindo este modelo, o Mosteiro da Batalha, por exemplo, teria uma infobox para edifício religioso. Note-se como aqui a questão do património não requer uma infobox à parte, mas são apenas linhas dentro das infoboxes. Tenho feito alguns testes para isto criando {{UNESCO}}, {{MN}}, {{IIP}} ou {{IIM}} faltando ainda os monumentos do Brasil.

2. O modelo inglês

Esta proposta seria a adopção de uma única metainfobox de um módulo genérico para prédio , ao qual podiam ser acrescentados vários sub-módulos, consoante o caso. Não sei se o sistema de módulos está implementado na pt.wiki, pelo que tudo depende disso estar activo ou não.

O módulo principal contemplaria tudo o que fosse genérico e aplicável a todos os edifícios: header, nome, imagem, legenda, geolocalização. Seria uma versão muito truncada de {{Info/Prédio}}

Os sub-módulos seriam chamados pelo editor consoante o tipo de edifício e encaixariam no módulo geral.

• Por exemplo, no caso de um teatro chamaria um sub-módulo teatro, onde constassem informações como data de construção, número de salas, capacidade, director, sitio web.
• E não têm que ser sub-módulos apenas consoante o tipo de edifício. Noutro exemplo, no caso de ser património classificado, chamaria um sub-módulo património onde constasse a protecção legal da Unesco, de portugal ou do brasil.

Síntese das Propostas

Proposta 1 seguindo o modelo francês

Seria criado um modelo gráfico padrão semelhante ao francês e seriam feitas de uma só vez, ou padronizadas, todas as infoboxes que contemplassem todos os tipos possíveis de edifícios:

Aeroporto, Aqueduto, Arranha-céus

Banco central, Barragem, Base militar, Base permanente,

Campus, Canal, Casino, Central nuclear, Centro comercial (shopping), Castelo, Casa

Edifício/estrutura militar (ou fortaleza), Edifício religioso, Estádio, Estação de metro

Farol, Fábrica (usina)

Gare (comboio/trem e autocarro)

Hospital, Hotel

Mosteiro, Monumento, Museu

Observatório

Palácio, Prisão, Ponte

Restaurante

Sala de espectáculos

Tribunal, Túnel

A negrito marquei as mais urgentes. Isto implicaria um controle apertado para não se andarem a criar mais infoboxes fora destas. Por exemplo, alguém se lembrar de criar infoboxes para o metro de determinada cidade.

Implicaria também a eliminação de todas as infoboxes que não estivessem na lista. A ideia é de uma vez por todas reorganizar coisas que nasceram mal há seis anos.

Vantagens Como elimina a predefinição genérica Info/prédio, obriga sempre o editor a ir buscar o modelo respectivo, sem qualquer ambiguação. A estética é unificada e podem ser alterados os pictogramas do topo consoante o tipo de edifício. A sintaxe é também muito mais simples que a proposta 2, tanto para quem edita como para quem a coloca no artigo.

Desvantagens Se se quiser adicionar ou retirar campos, tem que se fazer uma a uma.

A estética final seria qualquer coisa deste género que tenho estado a testar aqui:

Projetos/Padronização/Arquivo/4
Nome local
Tipo
Proprietário inicial
Função inicial
Proprietário atual
Função atual
Website
Arquitectura
Início de construção
Fim dos trabalhos
Estilo(s) dominante(s)
Arquiteto(s)
Intervenções de artistas
Tipo
Tipo
Classificação
Protecção 1	Monumento Nacional
Protecção 2	Património Mundial (1982) ver registo

Referências

Proposta 2 com base no modelo inglês

Haveria um módulo principal de base, fixo e protegido com os seguintes parâmetros

• Header, título, imagem, legenda, coordenadas geográficas, mapa

Depois haveria sub módulos que os editores podiam acrescentar, dentro de dois géneros: tipo de edifício e características do edificio.

• Dentro dos de género de edifício, teríamos basicamente a lista da proposta 1.
• Dentro das características haveria um sub módulo para "arquitectura" com os campos de arquitecto, data de projecto, estilo, etc, e um sub módulo para protecção, com as protecções legais e internacionais (unesco).

Polyethylen (discussão) 03h25min de 19 de setembro de 2011 (UTC)

(Tarde da noite, olhando rapidamente, e respondendo rapidamente) Na wiki não usamos o sistema de módulos (exceto pela info/química) já tendo até proposta na esplanada para aplicar mas não teve quase nenhum apoio. Temos preferência por metapredefs então o caso seria esse. A metapredef teria os campos talvez parecido com a atual Info/Prédio, q é completa e tem campo até não poder mais, e aí teria as várias infobox para cada tipo, que teriam campos específicos. Por exemplo, prédios de Portugal substituiriam o campo "classificação" por "IGESPAR" q vai produzir a url direto facilitando o preenchimento. Rjclaudio ^msg 03h46min de 19 de setembro de 2011 (UTC)

Para começar, as infobox que apresentou são da versão antiga, ou seja infobox v.1, neste momento na wiki pt está-se a alterar todas para a infobox v.2. Para terminar, não existe problema nenhum nas metainfobox se as souber usar, além do mais tem as vantagens de se poder utilizar padrões de todas elas numa só se assim quiser. Veja o exemplo da que eu criei para as personagens ficticias {{Info/Personagem fictícia}} e a para livros de BD {{Info/Banda desenhada}}, são ambas metainfobox v.2 que são adaptadas consoante as necessidades e são claras e sucintas não gerando confusão a quem as utiliza. Acho que o ideal, seria discutir que campos se devem utilizar e criar uma do género. Pelo Poder do Z ^{Alaf Ogimoc} 03h47min de 19 de setembro de 2011 (UTC)

• Independentemente do modelo a escolher, há que fazer primeiro uma lista das infoboxes necessárias e das que podem ser fundidas/apagadas. Na minha opinião, a lista da proposta 1, que no fundo é igual aos submodulos que propunha para a 2, era o que deveria ser mantido. As que já existissem, seriam redesenhadas, as que estão a mais podem ser eliminadas. Eu fiz a lista com base na francesa. Alguém se opõe ou vê alguma que esteja a faltar?

Aeroporto, Aqueduto, Arranha-céus

Banco central, Barragem, Base militar, Base permanente,

Campus, Canal, Casino, Central nuclear, Centro comercial (shopping), Castelo, Casa

Edifício/estrutura militar (ou fortaleza), Edifício religioso, Estádio, Estação de metro

Farol, Fábrica (usina)

Gare (comboio/trem e autocarro)

Hospital, Hotel

Mosteiro, Monumento(apenas para os que não são edifícios como arcos, estátuas), Museu

Observatório

Palácio, Prisão, Ponte

Restaurante

Sala de espectáculos

Tribunal, Túnel

Referências

Polyethylen (discussão) 04h15min de 19 de setembro de 2011 (UTC)

Claro que me oponho, você não só não respondeu a nada, como insiste na sua ideia não discutindo propostas alternativas, por isso começo logo por dizer que discordo de tudo o que disse e que a sua proposta é completamente absurda. E fico-me por aqui que são 6 da manha e ainda não fui dormir. Pelo Poder do Z ^{Alaf Ogimoc} 04h20min de 19 de setembro de 2011 (UTC)

Primeiro é um bocadinho triste o tom desagradável e azedo que dá logo às conversas quando até tive o trabalho de tentar organizar uma coisa que actualmente está um pântano e que ninguém quer pegar. Não sei a que é que "não respondi", não sei do que é que fala quando "me recuso a discutir alternativas" e do que é que "discorda de tudo". Só apresentei duas propostas de organização. Muito parecidas. Fiz o trabalho de casa, estudei outras interwikis que já têm isto sistematizado, reuni a tudo em duas propostas. O tema é imenso, mas tentei ser o mais claro possível para dar o mote à discussão.

Não sabia que não tínhamos módulos, mas o conceito geral da segunda proposta é igual às metapredefs.

Como há muitos pontos a discutir, pensei em assumir um pouco o papel de moderador e organizar isto por pontos, orientando primeiro a discussão para a fusão dos temas e limpeza geral das infoboxes e duplicações que andam por aí perdidas, que me parece ser o ponto de partida, antes de discutir outras coisas. E nem me pus a defender nada nem a propagandear nada, só dei o ponto de partida.

E eis que do meio do nada chovem insultos e palhaçadas autênticas. Cansa. É maçador. Parece que estamos a falar com meninos da primária. Já me tinham avisado que era uma perda de tempo tentar fazer alguma coisa de produtivo na pt.wiki e que mais valia fazer como toda a gente faz e ficar-me pela inglesa. Discorde lá, fique lá com a confusão em que estão as predefinições. Devemos ser a única wiki com esta dimensão que nem para um monumento consegue ter uma infobox decente. Realmente é dar pérolas a porcos... Polyethylen (discussão) 04h50min de 19 de setembro de 2011 (UTC)

Para começar ninguém insultou ninguém, e palhaçada só se for a sua atitude e a sua proposta. Você entrou numa de "eu tenho esta proposta e vocês tem que a discutir porque eu quero", não ouve ninguém, não discute mais nada e só existe você e mais você. Deveria ser mais humilde e começar primeiro por perguntar se havia interesse em fazer isso em vez de começar logo a arrotar postas de pescada como vez. Para começar nem levou em consideração que muitas dessas predefs estão associadas a projectos diferentes e que cada projecto tem a sua predef especifica. Uma jogada inteligente seria, antes de entrar a matar, o de ir aos respectivos projectos e começar por os informar que seria interessante normalizar as predfs e que seria aberta aqui uma discussão, mas fez isso? Claro que não. Julga que este projecto é Deus ou que? Nos aqui temos que conviver com todos os outros projectos e quando se pretende fazer algo desta magnitude, o que eu não acho errado, tem que ser discutido com os restantes projectos não só aqui. De facto como lhe disseram, é perda de tempo "quando não se quer ou não se sabe fazer as coisas" em condições, como é o seu caso. Quanto a mim, não tem maior defensor da padronização, mas levo sempre em conta os desejos dos outros projectos e analiso com eles os seus objectivos e interesses. As coisas não funcionam tipo Lone Ranger, como voce fez. Este projecto é colaborativo e os assuntos são para ser discutidos entre todos, não é para fazer (usando palavras suas) esta palhaçada. As coisas para serem feitas em condições tem que ter cabeça tronco e membros e não se começa uma casa pelo telhado que é o que voce está a tentar fazer. Pelo Poder do Z ^{Alaf Ogimoc} 13h24min de 19 de setembro de 2011 (UTC)

• Zorglub, fica difícil arranjar pachorra para o teu mau feitio. Se te conhecesse pessoalmente e fisicamente mandava-te a um certo sítio (de forma amigável, se é que me entendes)... Bolas, o rapaz está na disposição de fazer o que 99.9% dos editores aqui não faz e que 90% dos editores considerados experientes e empenhados tb. não faz: melhorar as predefs e tentar colocar alguma ordem nelas. E para isso começou por onde devia: estudou o assunto e fez uma proposta aqui neste projeto. E aí tu começas a desancá-lo... --Stegop (discussão) 14h35min de 19 de setembro de 2011 (UTC)

Seguindo a ideia da metapredef, aproveitei q a {{Info/Prédio}} tem a maioria dos campos e complementei alguns pra transformar ela em metapredef e fazer a {{Info/Museu}} chamar ela. Ao menos agora já há um pouco mais de padronização entre as duas (qualquer mudança de layout na Prédio mudará tb a Museu). Qnd avançarmos mais com a discussão melhoramos isso. Rjclaudio ^msg 14h51min de 19 de setembro de 2011 (UTC) ] Como fica as construções q não são prédios? Monumento às Bandeiras usa {{Info/Patrimônio histórico}} mas essa seria fundida com a {{Info/Prédio}}, mas um monumento não é um prédio. Talvez usar algo mais genérico q Prédio, "Construção"? Ou deixa as construções q não são prédio para outra predef? Rjclaudio ^msg 14h55min de 19 de setembro de 2011 (UTC)

É apenas um detalhe, mas provavelmente um nome mais adequado para a metapredef seja {{Info/Construção}} ou {{Info/Edificação}}. Apesar de haver monumentos (naturais, imateriais, obras de arte, etc.) que não são construções, são largamente a exceção. --Stegop (discussão) 15h19min de 19 de setembro de 2011 (UTC)

Pensando em usar campos genéricos para os líderes, como pessoa1, pessoa2, pessoa3, e cada predef define o cargo da pessoa (pastor, presidente, diretor, etc). Assim a metapredef não precisa ficar com 100 campos para pessoas para cobrir todos os cargos possíveis. Rjclaudio ^msg 15h28min de 19 de setembro de 2011 (UTC)

Acho muito boa a iniciativa. No âmbito do Wiki Loves Monuments, digo que tenho cruzado com muitos artigo e pensado para mim que deveria haver uma infoboz para eles, mas não ponho, ou porque não há, ou porque não sei bem a que colocar. Focando-me no caso de Portugal, essas boxs podem ter em conta a info das colunas das listas de património edificado ([5])? E como se poderia encaixar a info/sistema do Sistema de Informação para o Património Arquitectónico ([6]), tendo em conta que muitos dos itens aí inventariados não têm classificação formal pelo IGESPAR (vejo que a predefinição proposta dá para aparecer a classificação do IGESPAR e o link para lá)? No caso do SIPA estão classificados por graus.

Quanto às opções apresentadas, apenas tenho a dizer que dou mais valor a predefinições que sejam fáceis de usar pelos novatos, mas não consigo avaliar qual delas é melhor nesse aspecto. Abs. Lijealso (discussão) 16h39min de 19 de setembro de 2011 (UTC)

Metapredef aplicada tb em {{Info/Templo católico}}. Usei o templatetiger (ex: Info/Templo católico) pra corrigir a maior parte dos problemas q as edições causaram (especialmente o tamanho das imagens, q agora precisa colocar o px no campo do artigo, assim como todas as outras infoboxes). O resto dos ajustes melhor só fazer qnd as fusões / discussões acabarem e estabilizar o esqueleto das infoboxes.

Paro por aqui a espera de comentários sobre as fusões q fiz, se concordam com o modo q estou fazendo, e como está essas duas predefs até agora ({{Info/Templo católico}} e {{Info/Museu}}) se precisam de mais campos, de menos, se precisa mudar algum campo, etc.

Falta os campos sobre patrimonio / proteção, q todas as infoboxes de construção vão precisar ter. Até apoiaria usar {{UNESCO}}, {{IIP}} e similares (com o problema q elas são sempre siglas, e pode atrapalhar em predef, {{MN}} pode ser uma sigla de outra coisa tb).

Rjclaudio ^msg 19h13min de 19 de setembro de 2011 (UTC)

Começando pelo Stegop, caro colega, deveria ver quem começou a desancar quem, eu no inicio até estava numa de tentar ajudar, fiz esclarecimentos e dei explicações, e sua senhoria, não só ignorou tudo o que eu e o Rjclaudio dissemos, como indirectamente nos mandou a M****, tratando-nos com condescendência clara do género, coitadinhos, falem para ai que não me interessa, eu perdi muito tempo nisto e agora tem que fazer o que propus. A que lhe retorqui que com atitudes dessas não íamos a lado nenhum e ele começou a disparatar e a insultar, o que por si só já demonstra a clara atitude do personagem, por isso a seguir ouviu e bem, e só não ouviu mais porque concordo que tem que se fazer algo em relação ao assunto. Agora falando para a geral, aquilo que eu lhe disse a ele é valido para o resto do pessoal que está aqui a começar a discutir esta brilhante ideia, começando pelo telhado. Meus caros, devido ao envolvimento de vários projectos nestas predefs, não só é de bom tom ir-se ás respectivas páginas informa-los do que se pretende, como temos que os convidar para a discussão, sob pena de depois de tudo estar feito e se começar a implementação eles nos caírem em cima e protestarem a dizer que não temos nada de meter o bedelho onde não somos chamados, ou se preferirem, meter a foice em ceara alheia. Pelo Poder do Z ^{Alaf Ogimoc} 21h00min de 19 de setembro de 2011 (UTC)

Exacto. Numa discussão potencialmente complexa, nada mais fiz do que a dividir em pontos, e tentar primeiro chegar a um consenso em relação aos tipos de edifício. Apresentei uma proposta base para se poder melhorar e discutir. Outros pontos se seguiriam. Se isso é insultar, usar condescendência e mandar à m... vou ali e já venho. Tenho mais do que fazer do que aturar burgessos sem cultura. Além de ter claras dificuldades em compreender e interpretar o que os outros escrevem, resultando numa óbvia disfunção em relação à realidade, nada mais faz aqui do que azedar discussões. Já me tinham avisado que a pt.wiki era uma perda de tempo e que ia passar a vida a aturar imbecis. É pena, porque há gente aqui de valor. Quem tiver paciência que ature esta canalhada da escolinha a poluir discussões, eu já saltei fora e tentar arranjar aqui um consenso foi das maiores perdas de tempo que já tive. Agora já chorar para os administradores a pedir para me banir, estou-me nas tintas. Peço desculpa aos que contribuíram com alguma coisa produtiva. Polyethylen (discussão) 21h25min de 19 de setembro de 2011 (UTC)

Categorização de esboços por bytes

Ver Wikipédia:Café dos programadores#Categorização de esboços por bytes. --Stego (discussão) 15h23min de 22 de outubro de 2011 (UTC)

Links para datas

Devo informar que abandonei formalmente o projecto (Wikipédia), pois já não me revejo no mesmo, no entanto antes de ir embora quero aqui levantar um assunto que recentemente tem vindo muito à baila que é o caso dos links para as datas.

Já muita gente tem falado no assunto, já inclusive tendo sido discutido na esplanada, que linkar todas as datas é errado, pois os liks devem direccionar para um assunto especifico dessa data, e não de forma genérica e sem nexo como é actualmente. Como tal proponho que se removam nas predf todos os links para datas, passando as mesmas a apresentar as datas em texto simples sem links, eliminando dessa forma tais contradições. Até breve e bom trabalho. Pelo Poder do Z ^{Alaf Ogimoc} 14h39min de 20 de novembro de 2011 (UTC)

As vezes é bom colocar o link, como em campos específicos da infobox (data de nascimento/lançamento/formação). O ideal era ter um campo para escolher ocultar os links (ou um campo para criar os links). E um campo para permitir colocar um tema para o artigo do ano ({data|||2011|tema} = 2011 no tema) seria o ideal (padronizando assim a preposição / genero / número e não precisaria mais se preocupar com isso). Rjclaudio ^msg 14h50min de 20 de novembro de 2011 (UTC)

Mais parâmetros em Info/Assentamento

Ver Predefinição Discussão:Info/Assentamento#Link para Wikipédia audível e a secção seguinte (População rural, percentagens,Stegop (discussão) 23h34min de 21 de dezembro de 2011 (UTC) etc.). --

Bordos de Info/Assentamento

Ver Predefinição Discussão:Info/Assentamento#Substituir os bordos arrendondados por bordos angulares. Só o RJcaludio se manifestou além de mim. Será que devemos ser WP:AUDAZes e modificar, ou leva-se à esplanada? --Stegop (discussão) 19h29min de 12 de maio de 2012 (UTC)

Eu podia jurar que tinha comentado. Não houve também um tópico na esplanada em relação à padronização de bordos rectangulares há uns 3 meses? Polyethylen (discussão) 19h47min de 12 de maio de 2012 (UTC)

Aliás, toda essa história dos bordos arredondados foi muito mal feita. Começaram a existir alterações que só se aplicavam ao firefox (moz-border-radius). Quem não usava firefox não se apercebeu durante meses e meses. Depois começou-se a trocar o código para todos os browsers e foi só aí que notei. Quem se opôs depois de começar a ver bordos redondos em tudo quanto era lado, já vinha "muito tarde" para discordar fosse o que fosse e o status quo já eram os redondos, embora eu e muitos só tenhamos começado a ver essa coisa dos redondos lá para o Natal. Eu não estou a dizer que foi de má-fé ou intencional para fazer as coisas à socapa, mas a forma como foi gerido impediu qualquer discussão. Polyethylen (discussão) 19h52min de 12 de maio de 2012 (UTC)

Asbox sem linhas

A nossa {{Asbox}} tem duas linhas a enquadrá-la. Graficamente, isto até faz algum sentido no caso de se usar apenas essa predefinição, para não a deixar a flutuar no vazio. O problema é que na maioria dos casos a asbox é usada em conjugação com outras boxes. O resultado é uma salada de fruta. Hoje estava a tentar enquadrar uma asbox com uma navbox e com um portal3. Tentei inúmeras variantes, trocando a ordem, mas nenhuma ficava bem. Exemplo:

A juntar a isso, há as próprias margens do layout da wikipédia e ainda aquele mono horrendo da avaliação de artigos. Portanto, o que sugiro é retirar as linhas da Asbox, o que resultaria em

Muito melhor. Mas indo até mais longe, aproveitava para sugerir que a espessura das linhas da margem das navboxes fossem iguais às do Portal3. Polyethylen (discussão) 17h26min de 13 de maio de 2012 (UTC)

Predefs sobre bandeiras de nacionalidade

Isto ainda está vivo por aqui???

Vamos ao que interessa, parece que duma forma geral se optou para que as predefs de bandeira com nacionalidade ficassem com letra minúscula, como é o caso destas mexicano(a), espanhol(a), venezuelano(a), inglês(esa), alemã(ão), entre outras, o que é um erro, pois o correcto seria estarem com letra maiúscula.

Porque é que é o correcto? Pelo simples facto de que em 90% dos casos, estas predfs são utilizadas isoladas ou no inicio de uma preposição, logo devendo ser utilizadas com letra maiúscula e não minúscula, o que constitui um erro ortográfico. No entanto quando as mesmas são utilizadas em sequência, ou no interior de uma frase o resultado é também um erro ortográfico, se ficarem em maiusculas.

Portanto proponho que alguém que perceba um pouco da estrutura destas predfs altera as mesma para que por defeito fiquem em letra maiúscula, mas que tenham uma opção para serem utilizadas em minúsculas. O que é que acham? Pelo Poder do Z ^{Alaf Ogimoc} 20h53min de 4 de junho de 2012 (UTC)

Bem visto. Isso encaixa na proposta que fiz há quase dois anos (#Predefs de bandeiras), mas como se me afigura um trabalho monstruoso ainda não arranjei coragem para lhe pegar. --Stegop (discussão) 22h31min de 4 de junho de 2012 (UTC)

Padronização e aperfeiçoamento de Info/Lago

Ver Predefinição Discussão:Info/Lago. --Stegop (discussão) 01h04min de 29 de junho de 2012 (UTC)

Categoria:!Desambiguações com entradas sem ligações

Alguém me pode explicar o que significa esta categoria? Vi que há uma ligação daqui. GoEThe (discussão) 11h21min de 24 de agosto de 2012 (UTC)

É para desambigs q tem itens (entradas) sem ligação para artigo algum. Ou melhor, sem ligação para o artigo desambiguado, as vezes tem para a explicação do artigo. Ex: HAL, q um item a ligação leva para uma desambig, e HG, com um item sem ligação nenhuma.

Antes tinha várias desambigs assim, depois essas q sobraram ninguém removeu a predef de manutenção. Algumas marcações foram indevidas, por erro do meu script / revisão minha, mas na época a maioria estava certa. Rjclaudio ^msg 11h47min de 24 de agosto de 2012 (UTC)

OK, obrigado. GoEThe (discussão) 12h02min de 24 de agosto de 2012 (UTC)

Info/Assentamento - apelido/alcunha(s)

Ver Predefinição Discussão:Info/Assentamento#apelido/alcunha(s). Stegop (discussão) 02h30min de 19 de maio de 2013 (UTC)

Padronização de infocaixas para hierarquia católica

A Predefinição:Info/Prelado_da_Igreja_Católica foi criada com o objetivo de arrumar um pouco a bagunça que é a Categoria:!Infocaixas sobre pessoas e reunir numa predefinição apenas, os títulos das autoridades católicas, substituindo as seguinte predefinições:

• Predefinição:Info/Bispo da Igreja Católica
• Predefinição:Info/Arcebispo da Igreja Católica
• Predefinição:Info/Cardeal
• Predefinição:Info/Padre_da_Igreja_Católica
• Predefinição:Info/Monsenhor da Igreja Católica

Pretendo marcá-las como depreciadas e posteriormente fundi-las. Que acham? Cainamarques 00h24min de 13 de junho de 2013 (UTC)

Partindo do princípio de que o processo não envolve riscos de perda de informação (o "fundidor" acha que é necessário fazê-lo ou está 100% seguro disso?), é evidente que Concordo. Mas uma das coisas que talvez continue a faltar é o suporte para vários cargos (datas, etc.). Afinal, ao longo da vida, um prelado passa por vários cargos e é muito redutor falar só em um. E será que não é boa ideia aproveitar para incluir alguns campos mais de {{Info/Biografia}}? Em muitos casos, prelados não se destacaram apenas como tal. --Stegop (discussão) 03h40min de 13 de junho de 2013 (UTC)

Um prelado passa por vários cargos e nestes casos sua identidade é determinada pelo seu atual/último posto. Da mesma forma são as patentes militares ou cargos políticos, e é por isso que sou a favor da fusão de infocaixas "de hierarquias" para uma infocaixa da carreira inteira. Tanto políticos quanto militares já tem infocaixas desta forma. Ficar trocando a infocaixa (com campos diferentes) toda vez que um padre é eleito bispo ou qualquer outra mudança na hierarquia eu acho contraproducente, da mesma forma o seria se tivéssemos {{Info Cabo}}, {{Info Sargento}} e o resto das patentes. Na Info/Prelado é só trocar o estilo, tudo padronizado. Quanto a seu último ponto, esta será uma eterna questão desta categoria. Em Augusto Cury, se põe Info/Escritor, Info/Médico ou Info/Psicólogo? Estou disposto a acrescentar qualquer campo da {{Info/Biografia}} ou formatação para ajudar nas datas para que esta predefinição ajude um pouco na confusão, porque logo do outro lado tem {{Info/Sacerdote}}, {{Info/Papa}} e outras sobre títulos religiosos. Cainamarques 04h43min de 13 de junho de 2013 (UTC)

Citação: «sua identidade é determinada pelo seu atual/último posto» É mesmo? Em todos os casos? Para um bispo que não chegue a cardeal só é importante referir a última diocese? Isso é o mesmo que dizer que para um político basta indicar um cargo. Quanto a essas Info/Escritor, Info/Médico e afins, do pouco que conheço delas, a impressão que tenho é que Info/Biografia chega e sobra e muitas vezes até é mais adequada até para os dados supostamente mais particulares do que as restantes. Um caso desses é, salvo erro, Info/Militar. Pessoalmente só não uso a Info/Biografia para políticos, monarcas e nobres (às vezes). --Stegop (discussão) 05h03min de 13 de junho de 2013 (UTC)

Um bispo será referido como bispo até que se torne cardeal, ou até que abandone a batina enquanto vivo. Entendo que políticos, cujos cargos tem duração, são referidos pelo título do cargo até o fim do mandato. Por mim também se usava a Info/Biografia em praticamente todos as biografias, a ela são redundantes a maioria das infocaixas. No entanto, não vejo como isto poderia ser padrão aqui na wiki no futuro. Mas concordamos que gostaríamos de ver menos desta tamanha proliferação de infocaixas, de modo que predefinições mais gerais são uma direção neste passo. Por exemplo, poderia haver uma Info/Esportista para todos os praticantes de esportes ao invés de 40 predefinições diferentes. Cainamarques 06h29min de 13 de junho de 2013 (UTC)

Olá a todos. Só vi esta entrada agora. Para um prelado da igreja católica, é mais importante que se mencione o cargo actual, ou último, no caso de ter passado à condição de emérito, ou outro tipo de desvinculação. Mas na predefinição em causa, tive o cuidado de colocar um campo para a referência de outros cargos hierárquicos. E penso que assim resulta. Veja por o exemplo Manuel José Macário do Nascimento Clemente ou José da Cruz Policarpo. Quanto a marcar as outras como depreciadas.. e fundi-las. Bem este é naturalmente o caminho que espero, mas até ao momento, e apesar de ter colocado mensagens nas páginas de discussão de cada uma delas (bem como na página de alguns wikipedistas que têm contribuído para artigos do género), não tenho tido um feedback em número razoável. Como tal, optei por começar em incluir esta nova predefinição em alguns perfis de bispos/arcebispos/cardeais, mas na volta as edições foram revertidas, ou reeditadas para colocarem a anterior. Para mim, o ponto de partida para a criação desta nova predef foi a utilização de uma formatação actual e transversal a toda a wikipedia. Foi este o motivo que me fez regressar à Wikipedia até agora, de forma permanente, e tenho contribuido quase exclusivamente para a edição de perfis de bispos/arcebispos/cardeais. A nova predef utiliza alguns parâmetros diferentes das outras, pelo que estas não poderão ser redireccionadas para a nova.. se é que percebi bem. Para além dos rótulos e dos tópicos, acho que também se deve ser rigoroso nos parâmetros. (é ordenação episcopal em vez de consagração, daí utilizar bispo_data em vez de consagração, etc..) Claro que isto dá trabalho, pois é necessário ir a cada artigo e fazer a alteração, mas penso que estas correcções poderão ser úteis caso seja adoptado uma outra predef no futuro. Concordo com a marcação de depreciação nas predefinições referidas. --Jfrodrigues (discussão) 21h52min de 29 de junho de 2013 (UTC)

Marquei como depreciadas as predefinições. Cainã Marques 17h15min de 4 de julho de 2013 (UTC)

Predefinições depreciadas de taxonomia

Ei-las:

1. {{Taxocaixa cor}}
2. {{Taxocaixa especie}}
3. {{Taxocaixa nome}}
4. {{Taxocaixa nome binominal}}
5. {{Taxocaixa nome trinominal}}
6. {{Taxocaixa subdivisao}}
7. {{Taxocaixa subespecie}}
8. {{Taxocaixa autoridade}}
9. {{Taxocaixa inicio}}
10. {{Estado-ExtintaNaNatureza}}
11. {{Taxocaixa_imagem}}
12. {{Taxocaixa_separador_inicio}}
13. {{Taxocaixa_reino}}
14. {{Taxocaixa_filo}}
15. {{Taxocaixa_classe}}
16. {{Taxocaixa_superordem}}
17. {{Taxocaixa_ordem}}
18. {{Taxocaixa_subordem}}
19. {{Taxocaixa_infraordem}}
20. {{Taxocaixa_micrordem}}
21. {{Taxocaixa_familia}}
22. {{Taxocaixa_genero}}
23. {{Taxocaixa_especie}}
24. {{Taxocaixa_subespecie}}
25. {{Taxocaixa_separador_fim}}
26. {{Taxocaixa_nome_trinominal}}
27. {{Taxocaixa_fim}}
28. {{Registo fóssil}}

Com a padronização da {{Info/Taxonomia}}, estas predefinições não são mais utilizadas. Fiquei em dúvida como proceder. Elimina-se, cria-se uma categoria de predefinições depreciadas só para elas, redireciona... Cainã Marques 19h39min de 28 de julho de 2013 (UTC)

Já fui mais adepto de eliminar predefs não usadas, para evitar que continuem a ser usadas. Só que isso desabilita a correta visualização de versões antigas, o que é um bocado chato. Talvez o mais sensato seja apenas categorizá-las todas em cats de predefs obsoletas, para não apareceren junto com as outras. --Stegop (discussão) 22h07min de 28 de julho de 2013 (UTC)

Acho que não há grande perigo de elas continuarem a ser usadas. É muito mais fácil usar a {{Taxocaixa}} completa, pelo que sigo o Stegop. GoEThe (discussão) 17h05min de 29 de julho de 2013 (UTC)