Abrir menu principal

Wikipédia:Café dos programadores

Information icon.svg Lembre-se: os pedidos serão atendidos por voluntários, de acordo com a disponibilidade deles.

Boas-vindas ao café dos programadores!
Um local onde se tiram dúvidas sobre predefinições, HTML, CSS, JavaScript e outros tipos de edição avançada.

Inserir um novo tópico

Índice

Bug na substituição de predefiniçãoEditar

Acabei de marcar o artigo Bal com {{subst:f-referências}}, mas o aviso que aparece ao salvar a página continua pedindo a substituição.

Yanguas diz!-fiz 01h59min de 3 de janeiro de 2019 (UTC)

Tem alguém aí? O bug continua. Ver Junior Mendes. Yanguas diz!-fiz 15h56min de 9 de janeiro de 2019 (UTC)
@Yanguas: reproduzi o bug e um teste aqui. Apliquei no artigo Bal as duas etapas e funcionou. É isso que você refere? Stuckkey (discussão) 18h40min de 12 de janeiro de 2019 (UTC)
@Stuckkey: Funcionou mesmo? Veja o resultado do seu teste. Yanguas diz!-fiz 18h52min de 12 de janeiro de 2019 (UTC)
@Yanguas: Sim, ele reproduz o bug, mas não é a solução e nem a correção, pois em artigos não deveria solicitar subst: após o uso da predefinição. Como no Junior Mendes você fez e o resultado foi idêntico aqui. Eu vou reverter o do Bal, caso queira desfaço o seu teste no do Junior Mendes.

Vândalo da OiEditar

Como devem saber, algumas páginas têm sofrido ataque de um vândalo que, por meio de contas múltiplas, substitui todo o conteúdo por slogans ou contados da operadora Oi.

Como o conteúdo é praticamente igual, não há como criar um filtro para coibir esses atos?

Yanguas diz!-fiz 17h27min de 4 de janeiro de 2019 (UTC)

Bug nas movimentaçõesEditar

[XDjthwpAMFcAAJatWhoAAABT] 2019-01-11 19:24:56: Fatal exception of type MWException

Isso é o que tem aparecido quando tento movimentar uma página ou categoria que implique a eliminação de outra (um afluente, por exemplo).

Tem conserto?

Yanguas diz!-fiz 19h26min de 11 de janeiro de 2019 (UTC)

Tem alguém aí? Yanguas diz!-fiz 17h18min de 12 de janeiro de 2019 (UTC)
O problema continua ocorrendo? Lembro que tive isso quando fui suprimir umas edições dos socks da Oi.—Pórokhov Порох 17h36min de 12 de janeiro de 2019 (UTC)
Sim, Pórokhov, acabou de ocorrer. Yanguas diz!-fiz 17h37min de 12 de janeiro de 2019 (UTC)
Tentei fazer uma moção desse tipo e também apareceu pra mim o erro ([XDomdgpAADgAAJv80TAAAABT] 2019-01-12 17:40:07: Fatal exception of type MWException). Reportarei no Phabricator. —Pórokhov Порох 17h41min de 12 de janeiro de 2019 (UTC)
https://phabricator.wikimedia.org/T213631Pórokhov Порох 17h56min de 12 de janeiro de 2019 (UTC)

───────────────────────── @Pórokhov: Não sei se tem a ver, mas tentei mover Lake of Fire (filme) para Lake of Fire. Como deu o bug, marquei esta última com ER#9 para depois fazer a movimentação. Ela está marcada, está categorizada em Categoria:!Páginas para eliminação rápida, mas não aparece nesta última, por mais que eu limpe o cache. Yanguas diz!-fiz 18h28min de 12 de janeiro de 2019 (UTC)

A mim ocorre o mesmo.--Rena (discussão) 03h07min de 15 de janeiro de 2019 (UTC)

Formato dos parâmetros da Predefinição:Info/Município do BrasilEditar

Algum problema esta ocorrendo no preenchimento de dados na Infocaixa/Município do Brasil? Só hoje reverti estas edições idênticas com IP de diferentes localidades (e um editor registrado): usuário registrado, IP de Osasco, IP de Toledo, IP de Teresina.

Acho estranho isso. Talvez seja uma ação orquestrada em redes sociais, mas vale perguntar se pode estar ocorrendo algum bug na predefinição. O "R" Aliado 03h58min de 12 de janeiro de 2019 (UTC)

Prezado Revolucionário aliado, bug antigo do Editor Visual, que desfaz a formatação dos parâmetros.--PauloMSimoes (discussão) 09h59min de 12 de janeiro de 2019 (UTC)
Não é um bug. O formato "inline" (uma única linha, sem espaços entre os parâmetros) é o padrão quando a comunidade não especifica no TemplateData da predefinição que ela deve ser inserida no formato "block". Ver mw:Help:TemplateData#Description and parameters e exemplos de predefinições em que fiz essa configuração. Helder 17h40min de 16 de janeiro de 2019 (UTC)
@He7d3r:, como eu não uso a ferramenta, gostaria de entender melhor. É uma opção a "inline"? Não teria como remover esse "online"? Nas Info/Município, principalmente, mas acho que em qualquer infobox, as atualizações e correções na configuração inline, ou seja, todos os parâmetros alinhados, é muito complicado ou o editor perde muito tempo para corrigir dados. Eu, que sempre estou atualizando somente a estimativa populacional nos infobox de cidade, perderia um tempo demasiado para corrigir 10 cidade, pois tudo aglutinado, perde-se tempo para achar o parâmetro. Não teria como acabar com essa opção inline (isso se eu não estiver falando besteira). O "R" Aliado 18h30min de 16 de janeiro de 2019 (UTC)
Se a intenção é fazer com que todas vez que alguém edite uma página onde a predefinição é usada ela seja reformatada para que cada parâmetro fique em uma linha, deve ser definido o parâmetro para "block" (como fiz na última linha desta edição). Se houver mais predefinições em que a comunidade prefira que o código-fonte fique sempre com um parâmetro por linha, deve-se definir o formato "block" para cada uma delas, para que isso se sobreponha ao padrão do MediaWiki que é "inline". Helder 19h13min de 16 de janeiro de 2019 (UTC)

E continua, mesmo em edições que eram para ser aproveitáveis: 1, 2... eu resolveria se soubesse como. --HVL disc. 12h03min de 29 de janeiro de 2019 (UTC)

Já está resolvido. Todas as edições feitas depois que configurei a predefinição para usar o formato "block" (cada parâmetro no início de uma nova linha) farão com que os usos da predefinição nos artigos sejam atualizados. Fiz o mesmo para mais algumas infoboxes que ainda não estavam com essa configuração, pois imagino que também prefiram um parâmetro por linha. Helder 16h01min de 29 de janeiro de 2019 (UTC)
@He7d3r: Mas o problema persiste. Acho pouco provável que essas diffs que apresentei sejam edições de uma mesma pessoa. --HVL disc. 13h34min de 31 de janeiro de 2019 (UTC)
A edição que cita está normalizando a organização dos parâmetros no código-fonte no estilo "block", que é o que foi definido. Por exemplo, o "CEP" estava na mesma linha que o "padroeiro" e o "prefeito", violando a convenção que foi definida. O mesmo ocorria com "site_câmara" e "site_prefeitura".
Há também comentários espúrios que foram copiados indevidamente da documentação da predefinição. Por exemplo, o campo "Apelido" está preenchido com o valor "Neves" seguido de uma quebra de linha e do comentário "<!-- Dados gerais -->". O dif fica mais claro se quando a predefinição foi inserida ao artigo não tivessem sido inseridos também os comentários que aparecem na página de documentação da predefinição, entre alguns dos parâmetros.
Outro aspecto é a presença de mais de um espaço em branco (ou a falta dele) antes e depois do sinal de igual. O padrão adotado utiliza exatamente um espaço, nem mais nem menos. Aliás, esses comentários e espaços em branco que estão sobrando fazem o artigo parecer 5% maior do que realmente é (já que se contam os bytes de wikitexto nas estatísticas da wiki). Há outros artigos onde além disso ainda constam parâmetros em branco, fazendo com que as estatísticas sejam ainda menos corretas...
Enquanto a formatação do código-fonte das predefinições não for normalizado de acordo com as convenções que os editores definirem em suas documentações (manualmente ou por robôs), continuarão aparecendo difs poluídos. As edições seguintes mostrarão apenas o conteúdo que for alterado. Helder 20h27min de 31 de janeiro de 2019 (UTC)
Agora compreendo Helder, obrigado por esclarecer. Fica como sugestão configurar um bot para executar essas mudanças em todas as infocaixas, se possível, devido à grande incidência dessas incorreções. O comentário oculto, por exemplo, é herdado de quando elas foram adicionada em todos os artigos sobre municípios, também roboticamente, em 2004. Isso vai impedir interpretações equivocadas nas mudanças recentes, como a minha, além de sanar os erros de uma vez por todas. --HVL disc. 18h50min de 1 de fevereiro de 2019 (UTC)
Só pra constar: essa sugestão de usar um robô para normalização do formato eu tirei deste comentário: phab:T179259#3730216. Helder 21h13min de 1 de fevereiro de 2019 (UTC)

Erro de concordância na mensagemEditar

  • O editor CaiusSPQR reportou um erro nas mensagens que recebe aqui[1], peço que verifiquem.Jo Loribd 10h06min de 12 de janeiro de 2019 (UTC)
Talvez esta edição de Hamilton Abreu tenha relação com o problema? Helder
  • Dá para arrumar?Jo Loribd 21h47min de 12 de janeiro de 2019 (UTC)

InternetArchiveBot novamenteEditar

Em 29 de julho passado relatei que o InternetArchiveBot estava arquivando referências que já contém o link do arquivo e que a grafia da data adicionada é a antiga (meses iniciados em letra maiúscula), desrespeitando o padrão adotado nos artigos que usam a forma atual (inicial em minúscula nos meses) em conforme ao AO-1990, que são a grande maioria. Essas situações continuaram ocorrendo após algumas pausas do robô e podem ser vistas em suas edições mais recentes, como aqui. O bot não edita desde o último dia 28 de dezembro, mas só notei os problemas agora e talvez até já tenham sido reportados recentemente. --HVL disc. 14h54min de 12 de janeiro de 2019 (UTC)

Que eu saiba, qualquer um pode usar esta interface e executar o bot. Mas quem faz as alterações no código? —Pórokhov Порох 16h45min de 12 de janeiro de 2019 (UTC)

@HVL e Pórokhov: O bot está inativo. Ele editou hoje, mas acho que foi alguém que pediu manualmente pela interface. Quem edita o código é o Cyberpower678, que se disse inativo há alguns meses. Quanto à grafia, WP:LE/NQ indica que ambas estão corretas: As datas devem sempre ser escritas desta forma: 21 de maio de 1957, (Acordo ortográfico de 1990) ou 21 de Maio de 1957, (norma angolana). Tudo bem que não faz sentido usar a norma angolana em artigos brasileiros ou portugueses, mas não me parece nada grave. Vou pingar o autor do bot para usar os meses em minúsculas. Saturnalia0 (discussão) 04h08min de 9 de março de 2019 (UTC)

Em retrospectiva, antes de pingar o autor do bot creio que seja relevante alinhar o que falta fazer. Aos que participaram de discussões a respeito, @Tks4Fish e Stegop: sabem elencar os problemas que ainda persistem? O autor do bot parece estar editando ativamente na anglófona, apesar de bem pouco. Saturnalia0 (discussão) 04h12min de 9 de março de 2019 (UTC)

Acredito que para sanar os problemas para todos, pode-se usar o formato YYYY-MM-DD, que é suportado pelas predefinições de referências, e mostra o formato de data de acordo com o idioma definido pelo usuário. Quanto a duplicar o arquivamento, não notei diferença nas edições mencionadas, visto que tudo que ele fez foi corrigir o formato de URL usado pelo WebCitation. Nos casos que ele realmente estava duplicando, como quando havia o parâmetro |wayb=, pode-se ter dois resultados: suprimir o parâmetro, visto que o parâmetro |arquivourl= e seus correlatos é melhor, ao permitir o uso de todas as ferramentas de arquivo, como o Wayback Machine, Archive.is (atualmente archive.today), WebCite, entre outros; ou ignorar os que possuem esse parâmetro. Enfim, esta é minha opinião. Abraços! —Thanks for the fish! talkcontribs 15h27min de 9 de março de 2019 (UTC)
@Saturnalia0: A sugestão do Tks4Fish sobre as datas é pertinente, porém discordo de suprimir o parâmetro "wayb". Ele é muito prático quando se tem arquivamento pelo Wayback Machine e economiza bastante em espaço no tamanho do link. Quando se optar por outro "arquivador" basta utilizar o "arquivourl" e a meu ver isso vem funcionando bem. Aliás seria interessante, pela questão de economia de tamanho, usar exclusivamente o "wayb". Se não for possível, que o bot continue com o WebCite mas sem depreciar outro banco de dados caso já exista. --HVL disc. 16h46min de 9 de março de 2019 (UTC)

Percebi que nós mesmos podemos ajustar a questão da data pela interface. Removi todas configurações e deixei apenas %Y-%m-%d, como sugerido, pois é convertido para o valor apropriado de acordo com o idioma. Quanto ao resto não sei se dá para resolver pela interface, nem entendi muito bem o problema, caso os colegas queiram comunicar o autor do bot. Saturnalia0 (discussão) 18h19min de 9 de março de 2019 (UTC)

Como ninguém se manifestou e como não achei nenhuma opção na interface pretendo contatar o autor para acionar novamente o bot. Dando mais um espaço caso alguém creia que as questões levantadas acima sejam empecilhos ao acionamento do bot. Saturnalia0 (discussão) 16h29min de 13 de março de 2019 (UTC)

Saturnalia0   Concordo em reativar o bot. —Thanks for the fish! talkcontribs 21h37min de 13 de março de 2019 (UTC)

Cyberpower678 Can you activate the bot to do automated edits on the pt wiki again? I couldn't find anything on the interface to do it myself. There is a discussion above in which we discussed and fixed some of the problems which led to the bot being deactivated (at least its autonomous edits). We'd like the bot to be running on its own again. Saturnalia0 (discussão) 00h49min de 15 de março de 2019 (UTC)

@Saturnalia0: O problema com a grafia das datas parece ter sido sanado ao momento, porém segue inserindo arquivamentos duplicados, como na referência 6 daqui. Nesse caso o parâmetro "wayb", abreviação do link do Wayback Machine, foi ignorado e o robô inseriu outra ferramenta de arquivo, acarretando mensagem de erro na seção de referências. --HVL disc. 16h08min de 15 de março de 2019 (UTC)
HVL Me desculpe, mas eu não compreendi o problema. Os parâmetros que você menciona são configuráveis aqui. Talvez você possa arrumar? Saturnalia0 (discussão) 13h33min de 16 de março de 2019 (UTC)
@Saturnalia0: It should already be on. It may have gotten stuck. I'm working on fixing the bugs right now.—CYBERPOWER (discussão) 17h49min de 15 de março de 2019 (UTC)

O bot parece estar ativo novamente e atuando em ordem alfabética. Saturnalia0 (discussão) 01h10min de 23 de abril de 2019 (UTC)

Random portal componentEditar

Olá, não sei por qual motivo, a predefinição {{Random portal component}} anda mostrando a subpágina /0 algumas vezes (como é possível ver aqui), sendo que não deveria fazer isso, devendo começar do 1, como é feito na maior parte das páginas (para não dizer todas). Mr. Fulano! Fale 23h53min de 12 de janeiro de 2019 (UTC)

Mr. Fulano  corrigido. O problema não era com a predefinição, e sim com um trecho do portal anfíbios e répteis. veja.-- Leon saudanha 01h14min de 13 de janeiro de 2019 (UTC)
@Leon saudanha: Era isso? Eu nem sabia que isso influenciava na predefinição, achava que ela apenas mostrava as páginas de acordo com o limite imposto nela. De qualquer forma, espero que isso resolva o problema. Mr. Fulano! Fale 01h21min de 13 de janeiro de 2019 (UTC)
Mr. Fulano creio que ela segue a sequência de vezes que o título principal do que ela está listando aparece na página. Como havia "Portal:Anfíbios e répteis/Artigo selecionado" antes de "Portal:Anfíbios e répteis/Artigo selecionado/1" ela leu o primeiro como "/0".-- Leon saudanha 15h07min de 13 de janeiro de 2019 (UTC)
@Leon saudanha: Acredito que não, pois quando a predefinição é adicionada ao artigo, deve-se adicionar o parâmetro |max=, definindo quantos a quantidade de artigos a serem randomizados. E fugindo um pouco do assunto, alguma edição, não sei se foi a sua (acredito que não) desconfigurou todo o layout do portal, mostrando tudo no lado esquerdo do monitor. Mr. Fulano! Fale 21h32min de 13 de janeiro de 2019 (UTC)
Mr. Fulano se colocar como estava de novo o erro volta...-- Leon saudanha 13h40min de 15 de janeiro de 2019 (UTC)
@Leon saudanha: Eu coloquei um <noinclude> para que a predefinição não leia o código de estilo, mas de qualquer forma, o erro que divide o portal no meio continua. @He7d3r:, você tem alguma ideia do que seja? Mr. Fulano! Fale 14h19min de 19 de janeiro de 2019 (UTC)
Bom, segundo o verificador de sintaxe do MediaWiki (que pode ser aplicado a artigos específicos com auxílio do en:User:PerfektesChaos/js/lintHint), o Portal:Anfíbios e répteis estava com erro de sintaxe (um elemento <div> incompleto), então tentei resolver mas aparentemente não encontrei o elemento correto e a página ficou daquele jeito. Desfiz minha edição na Portal:Box-footer, pois lá não é prático testar (já que ela é uma das várias "predefinições" que estão fora do domínio correto, onde haveria a possibilidade de ver uma prévia das alterações em páginas que transcluem as predefinições).
Assim, continua pendente encontrar o div problemático e corrigir o erro de sintaxe. Helder 21h06min de 21 de janeiro de 2019 (UTC)

───────────────────────── Aparentemente, o problema foi resolvido "sozinho". A respeito do fato da predefinição está fora do seu respectivo domínio, concordo sim, que ela deveria ser movida, mas infelizmente não é apenas ela que está no domínio Portal, tem diversas outras, dando um grande trabalho mover tudo isso. Mr. Fulano! Fale 13h55min de 22 de janeiro de 2019 (UTC)

Não resolvi o problema. Só troquei o novo erro pelo erro antigo, que continua lá aguardando ser corrigido (como a maioria dos portais - inclusive destacados). Helder

Como destacar um ponto de um mapa com um círculo vermelho que piscaEditar

Exemplo de tal círculo: https://es.wikipedia.org/w/index.php?title=Atentado_a_la_Escuela_General_Santander&oldid=113389546

Eu quero colocar o mesmo no nosso artigo aqui, Atentado a bomba em Bogotá em 2019, mas a nossa predefinição equivalente, a {{Superimpose}}, parece não funcionar. Holy Goo (d . c) 14h57min de 19 de janeiro de 2019 (UTC)

Holy Goo, um pitaco: existem cerca de setecentas páginas que utilizam o gif na pt.wiki. Não entendo disso, mas parece que se utilizam os seguintes parâmetros:

|basemap= |locator_x= |locator_y= |tamanho= --PauloMSimoes (discussão) 15h37min de 19 de janeiro de 2019 (UTC)

Esses parâmetros esstão embutidos em outra predef. Quando fui naquela predef sobre objetos astronômicos para ver qual predef. fazia esse ponto vermelho, vi que é a {{PT locator}}. Mas quando eu uso essa predef. no artigo do atentado a bomba, em vez de aparecer um círculo vermelho, aparece "[[Imagem:{{{float}}}|15px|{{{float_caption}}}]]" Holy Goo (d . c) 15h46min de 19 de janeiro de 2019 (UTC)

MapaEditar

Olá a todos. Eu criei a predefinição:Info/Assentamento/Omã e, por defeito, o mapa de localização é o mapa antigo do país (imagem:Oman location map.svg), antes da reorganização das províncias de 2011. Eu queria trocar por imagem:Oman adm location map.svg, só que não sei como. Ao preencher a predefinição com o nome do país, ela automaticamente chama pelo mapa antigo. Se puderem ajudar, agradeceria.--Rena (discussão) 23h02min de 21 de janeiro de 2019 (UTC)

@Rena:   Feito - foi substituída a imagem usada por {{Mapa de localização/Omã}}. --Stego (discussão) 02h51min de 23 de janeiro de 2019 (UTC)
Outra coisa, só agora percebi que quando preenchidos valores numéricos na infocaixa que tenham vírgula (sei lá, 1,5 quilômetro), se eu preencho com vírgula, como o valor é apresentado no fim das contas, ele aparece o número 1 + espaço + 5 (ex antes e depois). A infocaixa só responde se eu preencho como 1.5. Agora, se por um lado é algo fácil de resolver essa infocaixa, a minha dúvida é se não há algum meio de padronizar isso em todas as infocaixas, sendo possível preencher seja com ponto seja com vírgula, porque hora as infocaixas só respondem com vírgula, hora só com ponto. (a info/rio, sobre a qual já falei à exaustão, só responde com ponto, mas se não me engano a info/lago responde com vírgula).--Rena (discussão) 21h08min de 24 de janeiro de 2019 (UTC)

Moção de categorias e WikidataEditar

Olá pessoal! Até agora parece que foi um caso isolado, mas achei importante relatar. Renomeei uma categoria normalmente pelo Especial:Mover página e o Wikidata criou um novo item para o novo nome. Já existia o item Categoria:Faculdades de medicina do Brasil (Q9685134) (registrou a renomeação) e a conta GZWDer (flood) (de GZWDer) criou o item (Q61016578) para a categoria com o título antigo (que possui artigos ainda, pois não foi superado ainda o tempo de espera de Alch Bot para a recategorização). Os itens duplicados já os fundi. Mas deixo aqui o relato e espero que isso não tenha acontecido noutras situações. E não sei se foi algum problema daqui ou do Wikidata e não saberia onde relatar isso lá, por isso vim aqui. --Luan (discussão) 15h25min de 26 de janeiro de 2019 (UTC)

Achei mais outro caso nas mesmas condições: (Q61016763) e Categoria:Capitães de cavalos de Portugal (Q49677163) (já os fundi). --Luan (discussão) 15h42min de 26 de janeiro de 2019 (UTC)

Matriz de tamanho e acessosEditar

Ei, seria muito legal se a Matriz de tamanho e acessos tivesse uma linha e uma coluna de totais... Será que algum de vocês se anima a fazer essa alteração? Eu tenho usado essa ferramenta frequentemente, para fazer priorização de artigos com problemas dentro de categorias, e esse recurso tornaria a usabilidade mais interessante.--Mister Sanderson (discussão) 22h52min de 26 de janeiro de 2019 (UTC)

Info p/ sistemas de avaliação e trabalhos acadêmicosEditar

Fiz um tópico geral sobre infobox para "avaliação de qualidade", "trabalhos acadêmicos" e, "medidas físicas"

É necessário criar um novo infobox? - Elilopes DEBATE 19h04min de 7 de fevereiro de 2019 (UTC)

Batalha de ArçufeEditar

Olá a todos. É um detalhe pequeno, mas talvez tenha um fundo de programação. Em Batalha de Arçufe eu usei o espaçamento {{br}} na infocaixa de ambos os lados, porém só do lado esquerdo está funcionando bem. Do lado direito, onde ironicamente há o uso da mesma bandeira para todos os indivíduos, o espaçamento está estranho, com algumas bandeiras espaçadas e outras não. Alguém poderia dar uma olhada? Agradeço.--Rena (discussão) 21h06min de 7 de fevereiro de 2019 (UTC)

Renato, acho que é um problema na renderização da página. Aconteceu aqui também, mas aparentemente está tudo certo, e dando zoom é possível notar que há uma separação. Boas! —Thanks for the fish! talkcontribs 00h17min de 8 de fevereiro de 2019 (UTC)

Info/Objeto redimensionando imagem como miniaturaEditar

Pelo menos comigo, a infocaixa {{Info/Objeto}}, que utiliza dados do Wikidata, está redimensionando a imagem conforme o tamanho selecionado para uma miniatura em Preferências > Aparência > Ficheiros > Tamanho da miniatura. Por causa disso, imagens dentro dessa infocaixa ficam com tamanho além dos limites da predefinição, como pode ser visto aqui (artigo sobre polia, com miniaturas em 400 px, captura feita a partir do Google Chrome). Foi necessário purgar a página depois de ter mudado o tamanho da miniatura pra que o tamanho fosse mudado.--ArgonSim (discussão) 02h11min de 15 de fevereiro de 2019 (UTC)

O problema também é visível usando o Firefox. O Módulo:Infobox/Objeto é um fork de fr:Module:Infobox/Objet, criado/mantido por Dbastro. A versão original não tem este problema.
Quanto às preferências: é normal ter que purgar o cache do parser ao alterar preferências que mudem o conteúdo das páginas (como o restauro do tamanho padrão de miniaturas, que é de 220px). Helder 09h56min de 15 de fevereiro de 2019 (UTC)
@He7d3r e ArgonSim: tenho tentado ajustar o estilo para a imagem não sair do quadro, o Module:Infobox á uma versão 3 da infocaixa, uma atualização da versão 2, mas tenho tido problemas ao mostrar com classes e também quando tento utilizar um folha de estilo independente Predefinição:Infobox/common.css na versão Module:Infobox/Testes, ainda que o estilo fica bem (parecido ao fr:Module:Infobox) em algumas partes, e em outras quebra o layout. O layout da caixa é manipulado principalmente por este módulo principal infobox, as diferenças são principalmente em ajustes no estilo. Vou tentar o parâmetro uprightparameter com o valor 1 em vez de 1.2 talvez fique melhor. Dbastro (discussão) 13h32min de 15 de fevereiro de 2019 (UTC)

Info/nobre + info/santoEditar

Olá a todos. Em Wikipédia:Escolha do artigo em destaque/Cormac mac Cuilennáin, questionaram o porque do artigo ter duas infocaixas ({{Info/Santos}} e {{Info/Nobre}}) e como expliquei, alguns parâmetros de um não estão no outro. Sugeri informalmente que alguns parâmetros da primeira podiam ser adicionados na segunda quando um nobre fosse canonizado, evitando usarmos duas infocaixas. Eu não entendo nada de predefinições, me incapacitando à tarefa. Se alguém puder ajudar, ficaria imensamente grato.--Rena (discussão) 01h29min de 16 de fevereiro de 2019 (UTC)

  Comentário Eu particularmente não penso que essa seria uma modificação viável. Há inúmeros parâmetros em uma predefinição sobre santos que são incompatíveis com uma sobre nobres. Ademais, lembro-me de já ter visto outros artigos com mais de uma infocaixa, então não parece haver real necessidade de se remover uma delas. --ArgonSim (discussão) 13h46min de 16 de fevereiro de 2019 (UTC)
  Comentário. Eu também não vejo problema em ter duas infocaixas e provavelmente não se justifica "complicar" a Info/Nobre para suportar os parâmetros da outra. De resto, essa situação acontece noutros casos, como localidades que também são sítios arquológicos (ou em que o conteúdo referente ao sítio arqueológico ou à história é tanto ou mais relevante do que o da localidade atual); o mesmo para muitos sítios do Património Mundial, etc. --Stego (discussão) 16h26min de 16 de fevereiro de 2019 (UTC)
@Renato de carvalho ferreira, Stego e ArgonSim: Agora com a {{InfoLua}}, é possível usar o parâmetro child=yes para "juntar" duas predefinições em uma, de modo que seria possível usar campos de uma predefinição na outra sem a real necessidade de mexer no código. Creio que a melhor solução aqui é convertê-las para poder usar esse parâmetro. Pedro H. diz×fiz 16h39min de 16 de fevereiro de 2019 (UTC)
  Eu vejo problemas. Duas infocaixas costumam repetir informações. Duas infocaixas costumam tirar a harmonia no leiaute do artigo. Duas infocaixas costumam poderem ser fundidas em uma só. A fusão foi aventada em Wikipédia:Fusão/Central de fusões/Predefinição:Info/Biografia; Predefinição:Info/Sacerdote, mas não foi tema daquela proposta de fusão. Ambas as infocaixas devem ser fundidas em Predefinição:Info/Biografia. A função da infocaixa é resumir, duas (ainda mais com repetição) compromete a ideia de resumo das informações. --Luan (discussão) 16h54min de 16 de fevereiro de 2019 (UTC)
Não é bem isso que eu propus. Eu não ligo de ter duas infocaixas, cada qual para sua pessoa específica. O dilema é quando, no mesmo artigo, mais de uma infocaixa é usada. Como exemplifiquei na discussão, em Marciano eu não vou usar duas infocaixas, pois eu perco espaço que posso destinar ao uso de imagens. Se a {{Info/Nobre}} fosse compatível com {{Info/Santos}}, eu poderia simplesmente alimentar a primeira com mais alguns parâmetros que indiquem ao leitor, na infocaixa, que se trata de um indivíduo canonizado. Sinceramente, acho que as duas devem existir. A minha ideia era que ficasse com um aspecto semelhante àquele da en:Template:Infobox military installation que se vocês olharem em en:Krak des Chevaliers tem a possibilidade de indicar, em poucos parâmetros, que se trata de um edifício patrimônio da UNESCO, o que poupa de ter que usar duas infocaixas. Eu mesmo não vou usar duas infocaixas em Fortaleza dos Cavaleiros justamente porque há muitas imagens mais úteis que a infocaixa.--Rena (discussão) 17h51min de 16 de fevereiro de 2019 (UTC)
@Renato de carvalho ferreira, Stego e ArgonSim: Vejam: Com Info/Nobre e Info/Santo convertidas na {{infoLua}}, basta usar uma infobox no artigo com o child=yes que é possível inserir os campos das duas. No exemplo do Renato acontece o mesmo. A predefinição principal Infobox Military Structure chama Infobox UNESCO World Heritage Site através do embutimento por child=yes. Pedro H. diz×fiz 18h19min de 16 de fevereiro de 2019 (UTC)
Eu sou bem burrinho com programação, você poderia testar isso fundindo as informações das duas infocaixas de Cormac mac Cuilennáin e me mostrar? Dali só teria que copiar o campo venerado e festa litúrgica. O ícone dá pra adicionar como imagem solta.--Rena (discussão) 18h30min de 16 de fevereiro de 2019 (UTC)
@Renato de carvalho ferreira: Aqui: Predefinição:Info/Nobre/Testes (omiti a imagem, mas é possível deixá-la na infobox também). Pedro H. diz×fiz 18h41min de 16 de fevereiro de 2019 (UTC)
Fico imensamente agradecido. A imagem eu arrumo no artigo. Obrigadíssimo!--Rena (discussão) 18h43min de 16 de fevereiro de 2019 (UTC)
@Renato de carvalho ferreira: Note que a Info/Nobre não está convertida, é só um teste com os campos usados em Cormac mac Cuilennáin. Na versão completa algum campo está dando conflito com a Info/Santo e é preciso ver o que é. Infelizmente no momento estou sem tempo para esmiuçar a predefinição atrás do problema. Farei isso quando tiver disponibilidade. Todos os outros usuários da discussão são convidados a ajudar também. Pedro H. diz×fiz 18h50min de 16 de fevereiro de 2019 (UTC)

Pedro D​ C​ E​ F, o Leefeni D​ C​ E​ F já fez algumas alterações nesse sentido, introduzindo os campos referentes à infocaixa dos santos na infocaixa dos nobres, mas sua edição tornando as predefinições é bem-vinda, se ainda assim o quiser. E aproveito o comentário para falar, se ninguém nunca falou, que Predefinição:Info/Ilha acusa na sua página algum problema na documentação. Alguém sabe dizer o que tem com a infocaixa?--Rena (discussão) 06h22min de 23 de fevereiro de 2019 (UTC)

Fastbutton para criação de página de DBEditar

Olá, colegas ! Há pouco tempo estava tentando criar uma página de DB e usei equivocadamente o fastbutton "criar pedido de bloqueio". Esse recurso cria um pedido de bloqueio, como diz o título, mas não vejo muita vantagem nisso. A criação de um PB é muito simples (com a função "criar pedido", que existe na página) e um fastbutton para isso nem é tão necessário. Pergunto: não seria possível implementar um fastbutton para criar "página de DB", a exemplo do que já existe para criar páginas de PE's ?--PauloMSimoes (discussão) 11h35min de 21 de fevereiro de 2019 (UTC)

Simplificação do uso de mapas baseados em imagensEditar

Eu estou desenvolvendo o Módulo:Info/local que usa mapas baseados em imagens, mas estou fazendo com um método diferente, as predefinições geralmente usadas para esses mapas precisam de uma subpredefinição ou submódulo para cada mapa que é usado, como Predefinição:Mapa de localização/... e Módulo:Mapa/dados/.... No módulo que desenvolvi você só coloca o nome da imagem e as coordenadas das quatro bordas, o que permite colocar qualquer imagem de mapa desde que você saiba as coordenadas de suas bordas, sem precisar criar uma página para guardar esses dados. A minha dificuldade é que alguns desses mapas usam a projeção azimutal de Lambert, que possui uma fórmula matemática muito mais complexa do que a projeção cilíndrica equidistante usada na maioria dos mapas. Preciso desenvolver uma fórmula matemática para que essa projeção azimutal possa usada informando somente o nome da imagem mais três ou quatro pontos de referência como é feito com a projeção cilíndrica. Algum matemático estaria interessado em ajudar nisso? Danilo.mac(discussão) 21h14min de 25 de fevereiro de 2019 (UTC)

@Danilo.mac: um exemplo que coloca os pontos no mapa que é uma imagem escolhida, é o Módulo:Mapa/dados/américa do sul, a função aparece no módulo de dados, e tinha conseguido portar o módulo para outra wiki pelo que pode ser útil. Dbastro (discussão) 13h09min de 9 de março de 2019 (UTC)
@Dbastro: Esse é o modo como esses mapas funcionam hoje, o {{Mapa de localização/Oceania}} é um outro exemplo que faz isso, com esse método é preciso criar uma predefinição ou módulo para cada mapa, e é isso que eu queria evitar, pois se alguém quiser adicionar um novo mapa para o qual não tem predefinição ou módulo vai ter dificuldade em criar essas fórmulas. Na descrição das imagens tem o comando usado para gerar o mapa no Generic Mapping Tools (GMT), no mapa da América do Sul é -JA-60/-17.5/20.0c e -R-111.71735564517205/-55.20793284837989/-29.863824948966922/25.8980715779886r, a documentação do GMT explica o que esses números significam, o que falta é fazer um algorítimo que receba esses dados e gere a função para colocar o ponto no mapa. Com isso novos mapas poderão ser adicionados mais facilmente. Danilo.mac(discussão) 18h40min de 10 de março de 2019 (UTC)

Ponto de exclamação nos títulos das categoriasEditar

Sei que o ponto de exclamação em categorias serve para distinguir entre as categorias para classificação de artigos do domínio principal e as categorias de manutenção (especialmente as do domínio do projeto). No entanto, não entendo o porquê de o utilizar. A princípio, achava que servia para as categorias de manutenção não aparecessem nos artigos, mas para isso existe a palavra mágica __HIDDENCAT__.

Qual a necessidade, então, desse ponto de exclamação no início dos nomes das categorias? Várias outras wikis não utilizam esse ponto de exclamação, o que prova que não é necessário. Há alguma razão para que ainda o use na Wikipédia lusófona? —CaiusSPQR (discussão) 09h32min de 27 de fevereiro de 2019 (UTC)

Ver WP:Esplanada/propostas/Remover exclamação do início dos nomes de certas categorias (14dez2011). Helder 10h19min de 27 de fevereiro de 2019 (UTC)
Conforme demanda de Michael Pires na referida página, agora há: WP:!CAT. --Luan (discussão) 04h10min de 28 de fevereiro de 2019 (UTC)
Ainda assim, categorias não deviam ser autoexplicativas? Para quê algo como um ponto de explicação para diferenciar as categorias da Wikipédia, se eu poderia ler uma categoria como Categoria:Políticas da Wikipédia, e na página há uma predefinição específica para explicar que é uma categoria de manutenção/administração ({{Categoria de monitoramento}}/{{Categoria de administração}})? Os pontos apresentados nesta proposta para remover o uso do ponto de exclamação são muito mais válidos em minha opinião do que os pontos levantados para seu uso, que são demasiado arbitrários. —CaiusSPQR (discussão) 04h54min de 28 de fevereiro de 2019 (UTC)
@CaiusSPQR: Elas são autoexplicativas na medida em que é possível ser. Logo que chegou à Wikipédia, provavelmente não entendeu o significado de "predefinição" ou de "desambiguação", termos com significado bastante próprio ao funcionamento das coisas por aqui. Igualmente, um título como "Categoria:Angel Sanctuary" pode não te explicar nada, mas com uma descrição na categoria você passará a entender. Neste caso poderia ser "Categoria:Série de mangá Angel Sanctuary", mas careceria de concisão (o que é muito importante também) e poderia ser insuficiente para quem desconhece o que é mangá, necessitando de outro título a"utoexplicativo". Bom, os pontos apresentados lá foram refutados e a mudança não foi aprovada, assim penso que fui claro aqui o suficiente para esclarecer a dúvida inicialmente apresentada. --Luan (discussão) 16h09min de 28 de fevereiro de 2019 (UTC)

Bandeiras em infocaixasEditar

A quem interesse, abri uma discussão sobre o uso de bandeiras em infocaixas de filmes em Ajuda Discussão:Infocaixa#Bandeiras em infocaixas de filmes. Agradeço se quiserem oferecer suas opiniões sobre o assunto. —CaiusSPQR (discussão) 04h36min de 13 de março de 2019 (UTC)

QuadradosEditar

Olá a todos. Hoje a tarde estava editando num computador diferente o artigo Edom e vários caracteres diferentes (em edomita e cuneiforme) estavam visíveis, enquanto agora que voltei a editar em meu computador habitual eles aparecem como quadrados. Bem sei que não tenho habilitado nesse computador os recursos que possibilitariam visualizar os caracteres, mas como não sei o que falta, não sei como corrigir. Algum dos programadores poderia me ajudar com isso? Aquele computador é Windows 10, e esse é Windows 7, se isso ajuda para alguma coisa.--Rena (discussão) 01h05min de 14 de março de 2019 (UTC)

Alguém?--Rena (discussão) 20h39min de 17 de março de 2019 (UTC)
@Rena: Primeiro, tem de verificar se é um problema do sistema operativo ou do browser. Pode colar ao bloco de notas o seguinte: 𒌑𒁺𒈪? (Verifique também com a fonte Arial.) Se não conseguir ver os carateres, é um problema do sistema operativo; caso contrário é do navegador. Se for um problema do SO, pode verificar as seguintes páginas: en:Help:Multilingual support e en:Help:Special characters. Caso seja um problema do navegador, pode-me dizer qual é o navegador que usa e a versão dele? —CaiusSPQR (discussão) 21h40min de 17 de março de 2019 (UTC)
CaiusSPQR, eu acabei de colar no bloco de notas e continuam aparecendo os quadrados. Tanto no computador que funcionou como nesse que não funcionou, eu estava usando Google Chrome, na versão mais atualizada (não sei o número para precisar, verifico depois se isso ainda for relevante).--Rena (discussão) 21h45min de 17 de março de 2019 (UTC)
O problema está no SO; pouco importa então que navegador usa. Verificou as páginas que enviei? Lá, há links que podem ajudá-lo. —CaiusSPQR (discussão) 21h48min de 17 de março de 2019 (UTC)
Vou verificar daqui a pouco.--Rena (discussão) 22h07min de 17 de março de 2019 (UTC)
CaiusSPQR D​ C​ E​ F, o manual é bem intuitivo e consegui baixar as fontes novas, mas continua na mesma. Fiz um teste com as fontes para cuneiforme que eles indicam, baixei e instalei todas, testei e nada. Continuo só vendo quadrados.--Rena (discussão) 02h33min de 23 de março de 2019 (UTC)
Certificou-se de que o seu navegador utiliza a fonte instalada? Pode verificar nas definições do navegador. —CaiusSPQR (discussão) 02h35min de 23 de março de 2019 (UTC)
CaiusSPQR, como verifico isso? Não sei como. Há algum aba específica?--Rena (discussão) 02h42min de 23 de março de 2019 (UTC)
Fiz um teste e abri a mesma página que indiquei no início pelo Firefox e todas as fontes funcionam normalmente.--Rena (discussão) 02h50min de 23 de março de 2019 (UTC)

───────────────── Certamente então é um problema do navegador Chrome. Para definir a fonte desejada, pode acessar o seguinte link: chrome://settings/fonts. Lá, pode definir a fonte instalada como a fonte sans-serif. Se ainda estiver com problemas depois disso, tente utilizar a fonte em todos os campos disponíveis. Tente também, caso não funcione, atualize o navegador. Se não estou enganado, há alguns dias foi lançada uma nova versão do navegador. —CaiusSPQR (discussão) 02h55min de 23 de março de 2019 (UTC)

Eu fiz isso, e ao fazê-lo o texto todo foi reescrito na fonte (tentei fazer isso com o pálavi e foi um desastre). Inclusive eu já baixei a versão atualizada do Chrome.--Rena (discussão) 03h35min de 23 de março de 2019 (UTC)
Agora tentei com uma das fontes do acadiano (uma chamada Assurbanípal) e o texto cuneiforme funciona perfeitamente, entretanto todo o texto em alfabeto latino fica um bocado desconfigurado. Talvez seja necessário outra coisa que não envolva mudar as fontes dali.--Rena (discussão) 03h37min de 23 de março de 2019 (UTC)
Acredito que a melhor fonte para instalar seja Arial Unicode MS (não sei a licença da fonte para uso pessoal). Pode procurar no Google para fazer o download. Não estiu completamente certo se irá resolver seu problema, mas ela suporta carateres Unicode (ou seja, tanto os carateres ASCII quanto os não-ASCII, o que talvez resolva seu problema). —CaiusSPQR (discussão) 03h52min de 23 de março de 2019 (UTC)
Isso também acontece comigo. Por exemplo, os verbetes ဆေးခြောက် e ⲉⲣⲃⲓⲥⲓ só têm caracteres visíveis no Mozilla Firefox. Nem no Microsoft Word consigo ver os caracteres que estão dentro dos quadrados.
Leonardo José Raimundo (discussão) 13h00min de 27 de março de 2019 (UTC)
@Leonardo José Raimundo: Poderia eu saber qual é o sistema operativo do seu dispositivo? Suponho que não seja Windows 10. —CaiusSPQR(discussão) 13h03min de 27 de março de 2019 (UTC)
O sistema operativo do meu dispositivo é Windows 7.
Leonardo José Raimundo (discussão) 13h14min de 27 de março de 2019 (UTC)

─────────────── Sugiro que veja as páginas de ajuda citadas na discussão acima. É necessário instalar uma nova fonte. Suponho que a melhor fonte seja Arial Unicode MS, que suporta todos os carateres Unicode. Acho que é possível encontrar a fonte ao pesquisar no Google, mas não sei qual é a licença para uso pessoal. —CaiusSPQR(discussão) 13h20min de 27 de março de 2019 (UTC)

Pessoal, eu tenho uma péssima notícia para dar a vocês: quando eu imprimi os artigos criados por Al Silonov no Wikcionário em russo, no 72º artigo, criado no dia 27 de fevereiro de 2019, às 22h39min (UTC-3), não foram impressos os caracteres góticos, e no 98º, criado no mesmo dia, às 6h da manhã (UTC-3), foram impressos pontos de interrogação em vez dos caracteres que estavam dentro dos quadrados, que estiveram visíveis no Mozilla Firefox.
Leonardo José Raimundo (discussão) 03h20min de 2 de abril de 2019 (UTC)

Utilizar predefinição:Moção pedidaEditar

Convido-vos a opinarem sobre a utilização de {{Moção pedida}} em Wikipédia:Esplanada/propostas/Utilizar a predefinição Moção pedida (8mar2019). —CaiusSPQR (discussão) 20h07min de 14 de março de 2019 (UTC)

Migrar Mboxes para LuaEditar

Acredito que já esteja na altura de utilizarmos o módulo Módulo:Message box. A versão atual está quase completamente em inglês, o que é ruim por questões óbvias. Por isso, tentei traduzir ao máximo o código e manter a compatibilidade com as predefinições Mboxes atuais.

Podem verificar o código traduzido em Módulo:Message box/Testes e Módulo:Message box/configuration/Testes. O código não está muito limpo; se alguém quiser limpar/melhorar a sintaxe, por favor, sinta-se livre para isso.

De qualquer forma, esse módulo é bem mais vantajoso que o uso de código nas predefinições, como:

  • É necessário apenas desse módulo para fazer alterações a todas as mboxes
  • Os parâmetros são os mesmos para as mboxes (caso as mboxes suportem tais parâmetros)
  • É mais organizado, pois existe a subpágina Módulo:Message box/configuration, que detalha informação para cada mbox
    • Essa subpágina não é muito complicada de se utilizar; é muito semelhante a um arquivo JSON

Enfim, acho importante abrir esta discussão para definir o que fazer com as mboxes. Ademais, decidi não levar esta discussão à WP:E/P, pois muitos nem sabem do que se trata e o plano é não afetar em nada os editores (são os mesmos parâmetros que os atuais + alguns a mais, com suporte tanto ao inglês quanto ao português).

Nota: Meu plano de implementação do módulo é gradual! NÃO DEVE ACONTECER DA NOITE PARA O DIA! Só necessito de que concordem em implementar o módulo a médio prazo. —CaiusSPQR (discussão) 04h23min de 15 de março de 2019 (UTC)

Essa iniciativa pode trazer layouts como esse para as nossas infocaixas? Jardel.[5.250] d 17h05min de 15 de março de 2019 (UTC)
@JardelW: Não. Minha proposta é para mboxes, não para infocaixas. E o layout das mboxes não deve ser alterado. Exemplos de mboxes são {{Ambox}} ou {{ER}}. Teoricamente as únicas alterações de layout são bordas coloridas a depender do tipo da mbox (conteúdo, eliminação etc.), que algumas mboxes já possuem suporte, mas outras não; e, em dispositivos móveis, as mboxes ser juntadas numa nova tela, como em en:Probation (no topo há informações básicas, para informações completas é so tocar na mbox, que é a última da página).
Para infocaixas, não acho que seja necessário necessário migrar para módulos para obter uma predefinição semelhante a seu exemplo. Seria interessante migrá-las, no entanto, mas por questão de uniformidade. —CaiusSPQR (discussão) 17h20min de 15 de março de 2019 (UTC)
Para infoboxes eu estou desenvolvendo o Módulo:Info, que já está funcionando, só falta adicionar algumas funções especiais para temas específicos. Danilo.mac(discussão) 19h53min de 15 de março de 2019 (UTC)
Tenho duas considerações importantes sobre isso. A primeira é que módulo não é sempre melhor que predefinição, infelizmente alguns desenvolvedores (principalmente de língua inglesa) acham que o que é simples para eles é simples para todos e acabam divulgando essa ideia, eu desenvolvo módulos mas sei que muitos têm dificuldade em desenvolver, tanto que diferente do que acontece com predefinições a maioria dos módulos que temos aqui são importados, muitos editores que conseguem criar e modificar predefinições não têm a mesma facilidade com os módulos. Os módulos são uma alternativa a ser considerada quando eles fazem algo que a predefinição não faz, ou quando o código da predefinição é tão complexo que transformá-la em módulo a torna mais simples, não acho que a {{Ambox}} e outras semelhantes se enquadram em um desses casos. A segunda consideração é que esse módulo está usando classes de estilo definidas no MediaWiki:Common.css, classes de estilo são ruins pois o que está no Commons.css é carregado em todas as páginas mesmo que a maioria dessas classes não sejam usadas na página, o que deixa o carregamento das páginas mais lento sem necessidade. Só deveria estar no Common.css o que é usado em muitas páginas e não pode ou não compensa ser feito com estilos em linha definidos na predefinição, eu já havia colocado essa questão na discussão do Common.css, fiz até esta lista que mostra que muitas classes não são usadas, e estou fazendo o Módulo:Info sem classes de estilo para tentar reduzir um pouco esse problema. Então na minha visão o melhor é deixar as mboxes como predefinições, talvez criar uma predefinição única que seja a base das outras para facilitar as alterações, e transformar as classes de estilo em estilos em linha para ajudar a reduzir o Common.css. Danilo.mac(discussão) 19h53min de 15 de março de 2019 (UTC)
@Danilo.mac: As mboxes atuais são completamente péssimas. Elas possuem suporte limitado, não são compatíveis umas com as outras (não possuem os mesmos parâmetros), umas são mais suportadas do que outras (ver {{Fmbox}}) etc. O módulo já existe, querendo ou não, e o ponto dele não é ser editado a toda hora por qualquer um, visto que mboxes são utilizadas em quase toda a Wikipédia (sem qualquer exagero). Já apresentei as vantagens de utilizar módulos em vez de predefinições normais, por favor releia-as novamente.
É bom também lembrar que não há qualquer problema em utilizar classes no MediaWiki:Common.css (ela foi implementada por uma razão — e seu uso quando apropriado é fantástico). Como já disse, mboxes são utilizadas por quase toda a Wikipédia, então utilizar classes CSS é completamente justificável, além de que o uso de CSS na Wikipédia quase que não altera o tempo de carregamento das páginas. Já verificou como a as mboxes e as infoboxes na Wikipédia em inglês são? (Veja-as também na versão móvel.) Elas são infinitamente melhores do que as lusófonas, e a maior parte disso é devido às classes. As infoboxes aqui são incrivelmente grotescas, especialmente as bordas e os espaços entre as linhas, características que são definidas em en:MediaWiki:Common.css. Não há sequer qualquer motivo para não utilizar classes em MediaWiki:Common.css.
A Wikipédia/Wikimedia/MediaWiki vive a introduzir novas funções aqui, tais como módulos, classes universais, TemplateStyles (ainda não há uma página aqui que explique como funciona), Wikidata (o uso aqui é bem pobre), páginas do domínio MediaWiki (até hoje estou à espera de algum editor implementar o uso de referências com letras minúsculas, como [a] em vez de [lower-roman 1], que aparentemente é bastante fácil de implementar), etc. Não vejo fundamento lógico nenhum para não utilizar tais funções. —CaiusSPQR (discussão) 02h27min de 17 de março de 2019 (UTC)
@CaiusSPQR: Primeiramente, funções novas não são necessariamente melhores que as antigas, veja por exemplo o caso do Flow, os desenvolvedores investiram muito tempo naquilo como se aquilo fosse substituir todas as páginas de discussão, e acabou que a maioria dos editores rejeitaram essa nova ferramenta. Claro que isso não vai acontecer com os módulos, eles são úteis, fazem coisas que as predefinições não fazem, mas eles têm também desvantagens como menos editores capazes de editá-los. O ponto que quero chegar é que não podemos dizer que módulo vai ser sempre melhor que predefinição, temos que avaliar caso a caso. Eu reli seu comentário inicial, o fato de ser necessário alterar somente um módulo para alterar tudo, ter parâmetros em comum e ter uma página separada para as configurações de estilo, são coisas que também pode ser feitas com predefinição, essas são característica desse módulo, não é uma característica inerente a todos os módulos.
A questão do Commons.css também é uma questão que tem que ser avaliada caso a caso, o problema é colocar muita coisa desnecessária lá, não precisamos de uma classe que mude somente a borda e a cor de fundo de uma única predefinição se podemos colocar esses estilos diretamente na predefinição, se podemos fazer isso da forma mais simples por que vamos fazer da forma mais complicada? E também dificulta a edição pois são muito poucos editores que podem editar o Common.css. A vantagem das classes é que podem fazer algumas coisas que estilos em linha não podem, algo que tem que ser avaliado caso a caso. E de fato existe uma questão relacionada com a visualização em aplicativos móveis que eu não conhecia e pesquisei mais sobre isso agora. Esta é a visão das nossas ambox na versão mobile, e esta são na enwiki, eu pelo menos não estou vendo as amboxes na enwiki, isso acontece porque o Common.css não é carregado na versão mobile, em vez disso é carregado o MediaWiki:Mobile.css, o nosso está vazio e o en:MediaWiki:Mobile.css não tem nenhum dos estilos das mboxes, por isso elas aparecem sem borda na versão mobile de lá. Já na versão convencional (desktop) me parece muito semelhante as nossas e as deles, mas se existirem aspectos a melhorar nós podemos fazer isso mudando os estilos.
Enfim, acho que temos que começar por listar o que precisa mudar nas mboxes, e a partir disso vamos ver quais são as opções. Se estiver disposto a começar por esse ponto eu posso te ajudar com o desenvolvimento e implementação. Eu também estou interessado em criar soluções para versão mobile que sirvam para várias predefinições e não somente para as mboxes. Danilo.mac(discussão) 18h22min de 17 de março de 2019 (UTC)

─────── @Danilo.mac: Obviamente não quis dizer que todas as funções novas são melhores — quis dizer que as funções novas podem ser mais úteis do que as antigas, como o caso que citei do Wikidata. Claro que há quem utilize tais funções (como as descrições curtas para serem usadas em dispositivos móveis), mas em geral, a maioria da gente está sempre de pé atrás quanto a implementações novas do MediaWiki (e não as julgo), mas no tópico que estamos a discutir não faz sentido essas reservas, visto que módulos foram implementados em 2013. Já não é algo novo, potencialmente com bugs nem um monstro com sete cabeças. Módulos possui a vantagem de suportar uma linguagem de programação (algo que wikitext de predefinições certamente não o são) como bibliotecas, tanto próprias da Lua (que inclui algumas APIs de C) quanto da própria MediaWiki (como mw.ustring.match ou mw.title), algumas inclusive utilizadas em Módulo:Message box que talvez não possam ter alternativas tão simples para predefinições (como a função nativa pcall, string.find, string.gsub), que podem demasiadamente acumular o código, pois a maioria das funções/métodos é utilizada com frequência.

Outro ponto a considerar é que se usasse predefinições ao invés do módulo, não haverá tanta diferença de como já está — vai-se acumular predefinições desnecessariamente. Por exemplo, o módulo utiliza Módulo:Message box/configuration para agregar informação específica para cada mbox, como quais parâmetros elas usam, ou se permite uma certa mbox ser pequena. Caso essa função fosse implementada diretamente na tal «mbox esqueleto», seria necessário repetir cada parâmetro e especificação para cada mbox, o que a princípio não faz qualquer mal, mas à medida que se mistura com o código esqueleto, certamente causará confusão. Uma alternativa para essas predefinições seria a implementação de tais especificidades numa subpágina da mbox esqueleto, mas isso ainda causaria confusão devido a parser functions, como {{#if:}} e {{#switch:}} que haveria de misturar especificações entre si, o que é o oposto do se pretende fazer. A única opção viável seria implementar cada informação específica sobre a mbox numa subpágina para cada mbox (algo como {{Ombox/core}}, mas para tais informações). No entanto, esse é extremamente o oposto do que esta opinião se trata, que é simplicidade e universalidade para mboxes. Para implementar o módulo organizadamente, seriam necessárias apenas três páginas/códigos separados: o módulo per se, sua subpágina e a MediaWiki:Common.css. Essas três páginas seriam responsáveis pela implementação de sete predefinições diferentes. Caso fosse para implementar organizadamente com predefinições, seriam necessárias oito páginas diferentes: a mbox esqueleto e cada subpágina das predefinições (que são sete). Isso não faria qualquer diferença, pois caso, fosse criado um novo parâmetro para todas as predefinições, seria necessário alterar as oito páginas, em vez de duas ao utilizar módulos. Como programadores, é imperativo pensar em praticidade e compatibilidade do código -- é inviável utilizar código confuso para utilizar apenas uma única página de código.

Quando a utilização de classes, obviamente não se deve pôr código inútil em MediaWiki:Common.css, mas para seu ponto de vista, não se deve implementar código CSS de todo visto que é possível implementar código para cada página (por que razão há código CSS lá para a página principal?), o que discordo veementemente: não estamos na década de '90/'00, é não há como implementar CSS para módulos sem ser por meio de MediaWiki:Common.css, e repito, implementar código CSS para mboxes não vai alterar quase nada no carregamento das páginas comparado a outras coisas como o PHP do software MediaWiki aqui.

Veja também como a predefinição com uma mbox funciona numa página da Wikipédia em inglês, como em en:POV. Para saber mais, veja Predefinição Discussão:Ambox#Change coming to how certain templates will appear on the mobile web para saber mais. (Ah, é necessário utiliza classes de CSS para implementar tal função.)

Se o problema real for que a maioria dos editores não sabem utilizar módulos, há duas questões:

  • São poucos os editores que fizeram alterações às predefinições de mboxes -- não haveria uma diferença percetível quanto a editores que fariam alterações ao módulo.
  • Mboxes são utilizadas em quase toda a Wikipédia (até mesmo ao editar uma página protegida ou uma predefinição, há uma mbox). É justificativa suficiente para implementar classes no em MediaWiki:Common.css, e é até uma vantagem para editores não fazer edições desnecessárias (caso queiram implementar alguma função, podem fazer um pedido sem problemas).
  • Poderíamos chamar editores a aprenderem Lua, visto que há muita informação sobre ela e como funciona: tem informação na Wikipédia em português e na em inglês, no Wikibooks e MediaWiki, sem contar com documentações oficiais gratuitas sobre Lua, inclusive em português, visto que a linguagem foi criada no Brasil. Enfim, não falta material para aprender. (O único problema seria uma curva de aprendizagem um tanto alta a princípio para quem não sabe programação, mas Lua é de facto uma boa linguagem de programação para iniciantes.)

Enfim, se considerar todas as razões que apontei, verá que é muito melhor utilizar módulos e classes de CSS em vez de predefinições. --CaiusSPQR (discussão) 20h29min de 17 de março de 2019 (UTC)

@CaiusSPQR: Eu conheço as vantagens dos módulos e também quero que mais editores aprendam a mexer neles, eu até comecei a escrever a Ajuda:Lua há um tempo atrás. E justamente por conhecer e programar em Lua que eu sei que predefinição é muitas vezes mais simples. É possível fazer uma única predefinição para mbox e colocar todas as outras como redirecionamento, a própria predefinição consegue fazer alterações no estilo dependendo de qual domínio a página está, só a fmbox que precisaria de um parâmetro adicional para colocar a largura = 100%, e a asbox poderia ser fundida com {{esboço}}. Isso seria mais simples do que ter dois módulos mais o Common.css. As predefinições podem fazer muita coisa, muitos se esquecem do que elas podem fazer porque criou-se uma ideia que os módulos são o "futuro" e as predefinições são o "passado", quando na verdade não é tão simples assim, as predefinições ainda podem fazer muita coisa e são acessíveis a muito mais editores.
Sobre o Common.css, as classes que estão relacionadas a página principal são coisas que não podem ser feitas com estilos em linha, é um bom exemplo do que deve estar lá, já os estilos das mbox são todas para definir borda, cor de fundo, largura, margem, tamanho da fonte, etc, essas coisas funcionam da mesma forma se colocadas no código da predefinição, não faz sentido passar para os estilos para Common.css quando eles funcionam exatamente da mesma forma se mantidos em linha na predefinição. E é totalmente possível fazer predefinições e módulos sem classes de estilo, eu fiz o Módulo:Info sem nenhuma classe, todas aquelas classes de infobox só estão lá no Common.css porque ninguém tentou usar estilos em linha quando fizeram a {{Info}}.
Eu concordo que para a visualização mobile é preciso usar o Common.css e o Mobile.css, e estou disposto a ajudar nessa tarefa, mas podemos fazer isso colocando nas classes somente o que é diferente no mobile e no desktop, os estilos que não mudam podem ficar em linha em cada predefinição ou módulo. Danilo.mac(discussão) 22h06min de 17 de março de 2019 (UTC)
@Danilo.mac: Sua proposta vai causar demasiados problemas. Primeiro, não há que fundir predefinição nenhuma. Fusão é para quando as predefinições fazem o mesmo. Todas as predefinições servem um propósito distinto e misturá-las todas vai causar um problema enorme. O que pretende pode simplesmente ser melhorado ao utilizar um módulo — o função de Módulo:Message box é exatamente essa (nem mais nem menos). Não utilizar um módulo é completa teimosia e causará mais desvantagens do que vantagens, sem contar com a falta de compatibilidade e simplicidade que isso traria. É como se, num ficheiro HTML, em vez de utilizar tags como <tag>, <section>, <tag>, <tag> etc., fossem utilizadas apenas <tag>, <tag> e <tag>, simplesmente porque visualmente são iguais. Veja também porque muitos programadores separam seus códigos em módulos. As mesmas razões para existir códigos separados são as mesmas para existir predefinições separadas também. Deve-se considerar as diferentes funções das predefinições. Não se deve ficar a fundir todas as predefinições. Por exemplo, {{Asbox}} é uma metapredefinição; {{esboço}} não o é; não há para quê fundi-los os dois.
Nunca afirmei nem acredito que módulos são o futuro e predefinições são o passado. Módulos e predefinições possuem propósitos distintos, e como mostrei, é melhor utilizar módulos para mboxes. Não quero que todas as predefinições que utilizem mboxes sejam migradas para módulos — apenas as sete metapredefinições mboxes. {{POV}}, {{Sem fontes}} etc. devem permanecer como predefinições, pois seu propósito é alcançado por predefinições; já o das sete metapredefinições, não. Para alcançar o seu propósito como predefinições com os mesmos parâmetros, mesmos atributos etc. deve fazer um feito muito maior do que com módulos. Algo completamente desnecessário!
Quanto a CSS, as classes apresentadas não definem somente bordas, cores etc. Como disse, você próprio utilizou classes de MediaWiki:Common.css para criar Módulo:Info. Imagine a desnecessidade que seria se tivesse de escrever os códigos CSS um por um novamente. Classes poupam tempo e implementá-las em MediaWiki:Common.css traz mais vantagens do que desvantagens. Além do mais, muitíssimas classes para mboxes já existem: só pretendo complementá-las.
Que diferença faz implementar as classes CSS em MediaWiki:Common.css se a maioria das páginas da Wikipédia utilizam mboxes? Sem contar que o próprio software MediaWiki requer o uso de classes para mboxes. (Como poderia fazê-lo se fundisse todas as mboxes?)
Minha proposta é relativamente simples e fácil de implementar e não há de causar quaisquer problemas demais ao código da Wikipédia. Não vai afetar a maior parte dos usuários e em nada aos leitores. É uma questão de simplicidade e universalidade que não pode ser adquirida por predefinições.
Entenda, pretendo atualizar um módulo que já existe (e que é utilizada em 8685 páginas [2]) e complementar classes que já existem. Não estou a tentar reinventar a roda, ao contrário de sua proposta de fusão. —CaiusSPQR (discussão) 22h56min de 17 de março de 2019 (UTC)
Auxílio visual para entender a hierarquia entre as predefinições e o módulo: Imagem. (É a mesma que a da Wikipédia em inglês.)
@CaiusSPQR: Você disse que um dos problemas era que hoje são várias predefinições diferentes e o módulo vai centralizar tudo, eu então mostrei como isso também pode ser feito com predefinição, foi mais um argumento do que uma proposta (se bem que eu me disporia em criar essa predefinição). O ponto é que uma predefinição pode fazer tudo o que esse módulo faz. Mas enfim, não vamos convencer um ao outro sobre isso, então vou ceder nesse ponto para não travar a discussão. Já a questão do CSS você não leu direito o que eu escrevi, eu não usei nenhuma classe no Módulo:Info, as classes de infobox que existem no Common.css (são muitas) foram feitas para a {{Info}}, a predefinição mais antiga que não usa módulo, e colocaram classes porque não não tentaram ou não sabiam fazer a mesma coisa com estilos em linha, quando o módulo substituir a predefinição nenhuma daquelas classes serão mais necessárias e poderão ser todas removidas do Common.css. Já que estou cedendo na questão do módulo no lugar da predefinição, se você concordar eu posso editar o Módulo:Message box para que ele não use classes para borda, cor de fundo, etc, mantendo somente classes que fazem coisas que não podem ser feitas com estilos em linha. Danilo.mac(discussão) 23h52min de 17 de março de 2019 (UTC)
@Danilo.mac: Oiça, realmente interpretei mal o que quis dizer, mas porque é que não utilizou as classes já existentes? Não é como se fossem eliminá-las tão cedo (sabemos como funcionam cá as coisas).
Quanto à seu pedido de edição, eu agradeceria (de facto, não me faz diferença; só preferiria utilizar as classes já definidas por praticidade), no entanto há um problema: o código utiliza uma forma diferente para classes. É utilizado algo algo como «mbox-» + resto da classe, que mistura tanto as classes definidas em MediaWiki:Common.css quanto as predefinidas pelo software MediaWiki, que explicitamente requer classes para funcionar em dispositivos móveis (ver página sobre o assunto). Pode verificar o código para ver como funciona. —CaiusSPQR (discussão) 00h10min de 18 de março de 2019 (UTC)
Quando eu fui fazer o Módulo:Info eu li todo o código da predefinição para entender tudo o que ela fazia para tentar replicar no módulo, então me surpreendi com a bagunça dos estilos, tem estilos na predefinição que sobrescreve o que está na classe, borda na classe que sobrescreve a borda na predefinição, estilos que não têm função nenhuma, opção de trocar a classe por outra e muitas classes de infobox no Common.css, por exemplo existe uma classe para cada pictograma e quando mudaram a classe para infobox_v2 deixaram a classe infobox lá porque infoboxes que não usam a predefinição ainda usam essa classe. Pensei nas opções para organizar tudo, e melhor forma que encontrei para manter os estilos organizados, facilitar eventuais alterações e evitar que essa bagunça aconteça novamente é manter tudo na predefinição, pois percebi que tudo o que estava no Common.css poderia estar no código predefinição, e assim também fica mais fácil editar os estilos. Se essa prática for adotada em todas as predefinições e módulos vamos contribuir para manter a organização dos estilos.
Vou ver isso no Módulo:Message então, mas como eu estou terminando uns detalhes do Módulo:Info eu posso demorar um pouco. E antes de mexer no módulo eu vou procurar entender qual é a função de todas essas classes. Danilo.mac(discussão) 01h56min de 18 de março de 2019 (UTC)
Porquê não pedir para fazer alterações em MediaWiki:Common.css? Tem predefinições de mboxes (como {{Categoria vazia}}, que utiliza uma wikitable para ter o tamanho certo!) que possuem certos workarounds malfeitos porque as classes de mboxes não funcionam como deviam. Acho uma boa ideia atualizar o código lá e tentar copiar o código para o módulo; assim, já melhora tanto o módulo quanto as mboxes atuais. —CaiusSPQR (discussão) 02h11min de 18 de março de 2019 (UTC)
Eu ainda não conheço a fundo os problemas de estilo das mboxes, mas acho difícil existir problemas de estilo que não podem ser resolvidos editando os estilos em linha na predefinição, pois estilos em linha geralmente sobrescrevem os estilos da classe. A exceção são os problemas de estilo na versão mobile, para remover a borda só no mobile por exemplo é preciso manter a borda na classe e remover dos estilos em linha. Danilo.mac(discussão) 03h17min de 18 de março de 2019 (UTC)

───────────────── @CaiusSPQR: Adicionei a classe 'caixa' e 'mobile-img-peq' na {{ambox}}, e pedi em MediaWiki Discussão:Mobile.css para adicionar estilos mobile às classes, essas pequenas mudanças já vão dar uma boa melhora na aparência das mbox nos dispositivos móveis. As classes *mbox-* são controladas pela Extensão:MobileFrontend, elas fazem mudanças semelhantes mas de forma muito mais engessada, elas por exemplo não mantém a borda colorida da ambox nem mantém as imagens que foram inseridas pela predefinição, elas trocam ou removem as imagens, por isso que não estou usando elas. Essas classes que estou colocando vão melhorar a aparência mobile de forma semelhante mas mantendo uma aparência mais próxima da versão desktop. Quando eu for adaptar o módulo eu pretendo usar essas mesmas classes. Danilo.mac(discussão) 04h20min de 27 de março de 2019 (UTC)

@Danilo.mac: Obrigado. Eu tenho uma pergunta: onde são definificas as classes "caixa" e "mobile-img-peq"?
Quanto às classes "mbox-", há uma razão para serem assim. Em dispositivos móveis elas são clicáveis. Por exemplo, em Ambox (o do módulo) há os parâmetros |issue= e |fix= (que traduzi como |problema= e |conserto=), que visualmente em desktops não é diferente de |text=/|texto=, mas em dispositivos móveis, apenas o texto em |issue= é exibido. Como message boxes são clicáveis em dispositivos móveis, ao clicar na ambox, surge o resto do texto (e aparece a imagem). —CaiusSPQR(discussão) 11h08min de 27 de março de 2019 (UTC)
@CaiusSPQR: As classes estão em MediaWiki:Mobile.css, pedi ontem para inserir, e a 'caixa' também tem alguns estilos no Common.css mas esses são sobrescritos pelos estilos em linha adicionados na predefinição, então só os do Mobile.css que acabam tendo efeito. Fiz alguns testes colocando a classe ambox, mbox-text-div e hide-when-compact, em minha página de teste, elas dão esse efeito de visualizar somente o problema, e a aparência dada pela classe 'caixa' foi mantida, ainda preciso fazer mais alguns testes mas aparentemente dá para conciliar as duas coisas. Danilo.mac(discussão) 22h43min de 27 de março de 2019 (UTC)
Entendo, e obrigado pela informação. —CaiusSPQR(discussão) 22h50min de 27 de março de 2019 (UTC)

Criei o Módulo:Mbox, me baseei no Módulo:Message box mas fiz modificações para torná-lo mais simples, removi a categorização de data dele pois aqui nós categorizamos por data e assunto usando a {{Manutenção/Categorizando por assunto}}, futuramente podemos fazer com que o módulo faça essa função. Danilo.mac(discussão) 16h18min de 5 de abril de 2019 (UTC)

Com todo o respeito e sinceridade, sinto que esse módulo está mal feito. Aqui estão alguns dos problemas.
  1. Ele engloba todas as mboxes, e desconsidera suas suas individualidades (sinto que basicamente a única diferença entre Ambox e Cmbox, por exemplo, seja unicamente estilística). Por exemplo, não é suposto a mbox possuir o parâmetro |problema=
  2. Engoliu todos os estilos separadas numa só categoria, "global", o que não é suficiente
  3. As imagens não aparentam ter o mesmo tamanho, e o bug de a predefinição estar limitada a até certo tamanho de ecrã ainda não foi corrigido
  4. Estilisticamente, as cores e bordas de cada predefinição não estão padronizadas, e a mbox não aparenta nem ter estilo em dispositivos móveis
  5. Tamanho está completamente desajustado
  6. Desconsiderou completamente alguns parâmetros, como "small" e "imagemdireita", em que algumas predefinições já utilizam. --CaiusSPQR(discussão) 17h06min de 5 de abril de 2019 (UTC)
@CaiusSPQR: Eu estou procurando fazer o meu melhor, mas é difícil dialogar com você da maneira como você se expressa, por exemplo quando você diz que o "tamanho está completamente desajustado", não dá para saber o que você está querendo dizer com isso, além do "completamente" parecer um exagero desnecessário. Se quiser dar sugestões na discussão do módulo, nós podemos ir discutindo cada ponto com calma, mas dessa maneira fica difícil... Respondendo as questões que eu entendi: eu removi várias coisas que não são usadas nas nossas mbox, mas minha intenção era ir recolocando algumas funções ou mesmo inventando novas funções que não existiam no módulo original a medida que vamos encontrando uma utilidade para elas, inclusive eu adicionei algumas coisas que o módulo original não fazia. Os estilos em "global" só são usados quando os estilos não são informados na configuração específica, mas podemos manter os estilos que são repetidos em cada tipo em vez de no global, dá no mesmo. Eu não encontrei nenhuma predefinição nossa que usa o "small" nem o "imagem_direita", e mesmo na enwiki eles usam muito pouco o small, mesmo em seções, em todo caso o |uso=esquerda faz uma função semelhante a do small. Danilo.mac(discussão) 22h11min de 5 de abril de 2019 (UTC)
Peço desculpas se o ofendi; nunca foi minha intenção. Os pontos que apresentei são em geral visualmente reconhecíveis, por isso, não expliquei a fundo. Por exemplo, basta ver as predefinições em Módulo:Mbox/doc que terá uma ideia o que quis dizer. Os tamanho das imagens e da tabela em si não estão padronizados.
A predefinição {{Tmbox}} utiliza parâmetros que não são definidos no módulo que criou (o que inclui |small=).
Sinceramente, deveríamos sim definir passo a passo do que devemos fazer. Antes de tudo, acho melhor que utilize o módulo Módulo:Message box, visto que já é usado. Além disso, já testei seu uso e funciona como esperado. Veja as subpáginas de exemplos para testes das message boxes: Predefinição:Ambox/Exemplos para testes, Predefinição:Ambox/Exemplos para testes2, Predefinição:Cmbox/Exemplos para testes, Predefinição:Cmbox/Exemplos para testes2, Predefinição:Fmbox/Exemplos para testes, Predefinição:Fmbox/Exemplos para testes2, Predefinição:Imbox/Exemplos para testes, Predefinição:Imbox/Exemplos para testes2, Predefinição:Mbox/Exemplos para testes, Predefinição:Mbox/Exemplos para testes2, Predefinição:Ombox/Exemplos para testes, Predefinição:Ombox/Exemplos para testes2, Predefinição:Tmbox/Exemplos para testes e Predefinição:Tmbox/Exemplos para testes2. —CaiusSPQR(discussão) 23h47min de 5 de abril de 2019 (UTC)
@CaiusSPQR: Ainda não vi o que está errado nos tamanhos, mas se tiver algo errado nós corrigimos. Essas páginas de testes são cópias dos testes das predefinições da enwiki. Aqui nós usamos as caixas de forma um pouco diferente, nós não usamos o small aqui, nós temos nossa própria predefinição de categorização por data, que diferentemente da enwiki também categoriza por assunto. Eu li cada linha do Módulo:Message box até entender tudo o que ele faz, e comparei com como usamos as nossas mboxes, removi o que não usamos e adicionei algumas novas funções. Por exemplo eu criei uma função para encontrar a primeira frase do texto para usá-la como a frase que fica visível quando a caixa é compactada, então o parâmetro "problema" não é mais necessário, eu só mantive ele como um backup porque essa nova função precisa ainda ser mais testada, outro exemplo é o gênero do pronome, em inglês o "This" não varia, mas em português varia o gênero (Este artigo/Esta seção), no código que eu fiz o gênero correto é colocado automaticamente se o pronome não for informado, também adicionei o parâmetro "uso" que pode ser usado para fazer a função do small. Enfim, nós não precisamos ficar copiando exatamente o que as outras wikis fazem, nós temos modos diferentes de fazer algumas coisas e temos a capacidade de fazer adaptações e criar coisas novas também. Danilo.mac(discussão) 04h53min de 8 de abril de 2019 (UTC)

──────────── @Danilo.mac: Pode verificar Módulo:Mbox/doc para ver o tamanho desigual entre as mboxes quando no modo para dispositivos móveis. As páginas de testes que citei são sim cópias da enwiki, mas qual é o problema? As mboxes atuais também são cópias (malfeitas), e o módulo também. Não vejo porquê reinventar a roda; apenas gasta tempo e esforço à toa. Não me oponho em fazer alterações que diferem do módulo da enwiki, mas tenho de apresentar alguns pontos sobre as implementações que fez:

  • Você criou o parâmetro |uso=, que é quase como |small=, então não faz muita diferença implementar |small=, além de que faz mais sentido justificar a ausência de uso do parâmetro pela inexistência dele cá na ptwiki. O ponto de implementar todos os parâmetros de enwiki é para padronizar todas as predefinições, para utilizarem os mesmos parâmetros (obviamente, com exceção dos parâmetros específicos). Se não se usa |small=, basta não usá-lo. Ademais, é melhor utilizar |small= em vez de |uso=, pois também há |smallimage=, |smalltext= e |smallimageright=, então faz completo sentido utilizar |small=. (É bom lembrar que todos esses parâmetros estão traduzidos.)
  • Não sei como é essa categorização por assunto cá na Wikipédia, mas certamente percebo que não é em toda a Wikipédia. É bom lembrar que estamos a implementar message boxes no plural, não apenas Ambox. Para resolver esse problema, devemos discutir um pouco mais sobre isto, mas por enquanto, uma solução que proponho é apenas proibir que Ambox categorize por meio da categorização existente no módulo.
  • Se não estou equivocado, a distinção entre artigo/secção ocorre somente com Ambox (por meio do parâmetro |sect=). Em Módulo:Message box/configuration, é possível alterar o texto para "Este artigo" e "Esta secção", sem a necessidade de implementar uma função para isso. (Adicionar uma função como essa apenas aumenta desnecessariamente a quantidade de código.)
  • Não há a necessidade de criar uma função para utilizar a primeira linha para identificar o que |problema= já faz, além de ter o potencial de causar problemas. (Primeira linha? A contar a partir de onde? Onde ficaria então o texto para o problema? E como distinguir ao ler o código o que é para ser considerado problema e o que não é? E a lógica? Se há, |conserto=, onde estaria |problema=? E o parâmetro |texto=? Se teoricamente houvesse a necessidade de colocar texto de problema, de conserto e texto secundário numa só predefinição, como a função distinguiria os três? A lógica é separar por meio de |problema=, |conserto= e |texto=, mas sem isso, torna-se desnecessariamente difícil.) —CaiusSPQR(discussão) 05h33min de 8 de abril de 2019 (UTC)
  • Eu tirei a ideia do parâmetro "uso" do código atual da {{ambox}} (não está na documentação), mas fiz de uma forma que vários "usos" diferentes podem ser programados na página de configuração, no momento na ambox estão configurados o uso=seção, uso=esquerda e uso=direita, então é mais flexível do que o small. Já que vamos implementar algo novo então aproveitei para ampliar a funcionalidade.
  • A diferença nos estilos no mobile acontece porque a extensão MobileFrontend cria essas diferenças, veja que essas diferenças também acontecem na enwiki. Mas isso é só uma questão de ajustar os estilos, não fiz isso porque não sei qual estilo é melhor no mobile, o texto menor da ambox ou o maior das demais mboxes.
  • O parâmetro seção pode ser usado também para outros nomes, "Este tópico", "Esta página", "Esta lista", etc, muitas predefinições já permitem essa flexibilidade, mas precisam informar o pronome junto, essa função torna isso mais simples.
  • Atualmente a função pega a primeira frase do texto, do começo até o ponto final, e quando a frase é muito grande pega até a primeira vírgula, eu olhei o texto usado em algumas predefinições para definir isso, mas como eu disse ainda precisa ser mais testado e aprimorado. A intenção é deixar o uso mais simples, com isso todo o texto será colocado no parâmetro texto, exceto a data que pode ser colocada no parâmetro data. Como essa já é a forma como é feito hoje, nós não vamos precisar ficar mudando todas as predefinições para implementar o módulo. Danilo.mac(discussão) 17h43min de 8 de abril de 2019 (UTC)
Primeiro, perceba que apenas Ambox deve possuir um design completamente diferente na versão móvel. O resto não deve possuir possuir estilo CSS algum, para não afetar negativamente a predefinição, o que inclui a predefinição {{Mbox}} (exceto quando estiver no domínio de artigo, claro).
Segundo, note a diferenças de tamanho das imagens das diferentes mboxes em Módulo:Mbox/doc na versão móvel, e também a tabela em si, que não se estende a todo o ecrã.
Quanto à suas outras respostas aos meus pontos, veja que utilizar |uso= não é necessário, pois |small= já faz tudo isso. Em teoria, o parâmetro deve ser usado em secções, para não atrapalhar o fluxo de texto acima e abaixo. (Utilizar o parâmetro no topo da página não faz sentido, pois o conteúdo principal fica abaixo dela.). Em todas as mboxes, exceto Ambox, que permitem utilizar esse parâmetro, a caixa fica do lado direito, pois o conteúdo da caixa não é importante para o texto (veja a message box usada para responder a pedidos de edição em en:Module talk:Message box). Em Ambox, a caixa deve ficar à esquerda quando compactada, pois as informações da mbox são relacionadas e pertinentes ao texto. Por exemplo, numa secção em que há poucas fontes, o leitor deve estar ciente dessa falta de fontes. (Utilizar o parâmetro |small= nesse caso é para não quebrar o fluxo do conteúdo e, claro, porque a mbox não é mais importante que o conteúdo em si.) Considere também que |uso=secção é redundante e desnecessário, pois |secção= já identifica que é uma secção. Ademais, o que aconteceria se alguém usasse |uso=secção ou |uso=secção em {{Cmbox}}, que não deve suportar secções nem ser compactado? Percebeu como |uso= não é necessário para a predefinição, inclusive pode até ser um problema?
Para |secção= basta escrever "Esta lista" ou "Este tópico", mas uma função para isso não é necessária. Se minha memória não me falha, lembro de já haver implementado isso; se não, é só alterar uma linha. O que quis dizer é que o texto "Este artigo" já está implementado, para ser usado quando necessário, que é quando não há o parâmetro |secção=.
Já considerou o facto de o texto para ser usado como problema pode conter mais de uma oração. Sinto que considerar apenas a primeira oração/período irá causar problemas que podem muito bem ser evitados, além de consumir memória desnecessária. Meu conselho é desconsiderar essa função, pois os contras sobrepõem-se aos prós.
Acho muito mais importante testar cada predefinição que transclui {{Ambox}} antes de simplesmente utilizar o módulo. (Claro, isso não é necessário para outras mboxes, pois não houve tantas alterações para elas.) Há entre 300 e 400 transclusões [3] de {{Ambox}} noutras predefinições. Acho que menos, para ser sincero, porque Especial:Páginas afluentes conta subpáginas como /doc e /Testes. Como havia dito desde o início também, a implementação deve ser a médio prazo, pois milhares de artigos utilizam Mboxes, quanto mais as outras páginas da Wikipédia.
Em conclusão, torna-se claro que Módulo:Mbox está mal feita. Sinto que não realmente criou uma classe que instancie seus objetos (as diferentes message boxes) de forma particular. Sem intenção de ofender, parece-me que englobou todas as mboxes num só objeto sem classe, e só separou os estilos das mboxes (que, por sinal, é o de menos), desconsiderando todas as suas particularidades. Utilizar Módulo:Message box (no caso Módulo:Message box/Testes), que já é utilizado por outros módulos inclusive, é a melhor solução. --CaiusSPQR(discussão) 21h42min de 8 de abril de 2019 (UTC)
Eu de fato não tinha prestado atenção que apesar do |uso=seção estar no código da atual ambox ele não é usado nas predefinições. Removi o "uso", adicionei o "pequeno" e fiz algumas outras alterações, provavelmente ainda deve precisar de alguns ajustes, mas é só ir ajustando. Nós decidimos a aparência na versão mobile, se quiser mudar algo é só editar a configuração, se não souber como fazer é só pedir que eu altero, e uma cor clara de fundo nas mboxes não "afeta negativamente" a predefinição, pelo contrário, isso a diferencia a caixa do restante do texto, o que fica ruim no mobile são bordas, e isso foi removido. Amanhã eu faço mais testes para verificar como o módulo se comporta nas diversas predefinições que usam a ambox. E é melhor continuarmos a discutir isso na discussão do módulo, esta discussão está muito longa e muito específica para ficarmos discutindo no café dos programadores, acaba tirando a atenção de outros tópicos. Danilo.mac(discussão) 01h08min de 9 de abril de 2019 (UTC)
Antes disso, temos de decidir qual módulo utilizar. Ainda acho que Módulo:Message box é melhor, especialmente porque já está completo desde que abri esta discussão, e não possui os problemas que existem em Módulo:Mbox. —CaiusSPQR(discussão) 01h29min de 9 de abril de 2019 (UTC)

Predefinições Tl e TlxEditar

{{Tl}} e {{Tlx}} na ptwiki são iguais. Em vez de fundi-las as duas, proponho distinguir suas funções ao eliminar a tag <code>...</code> de {{Tl}} como na enwiki? Caso concordem, creio que seja melhor antes de alterar o código fazer um pedido em WP:CR para que sejam alteradas todas as transclusões de {{tl}} para {{tlx}}. --CaiusSPQR (discussão) 20h37min de 19 de março de 2019 (UTC)

@CaiusSPQR: a segunda tem a documentação parcialmente em inglês, o que é bastante prejudicial. Mas se você reparar a seção "Ver também" de ambas (e no código de cada uma também), verá que elas são diferentes e tem funções diferentes. Uma não tem espaço para parâmetros e outra tem. --Luan (discussão) 15h05min de 22 de março de 2019 (UTC)
@Luan: Isso pode ser resolvido ao atualizar a documentação da predefinição. Inicialmente, a primeira foi criada sem a tag <code>...</code>, mas hoje, a diferença entre as duas não é grande o suficiente para as manter como estão; no mínimo, deve-se fundi-las, visto que todas as funções que a primeira possui, a segunda também possui. Para evitar fundi-las, fiz minha proposta. As predefinições de tl/lp são padronizadas na enwiki (ver en:Template:Tl-nav), e acho que será útil adotar tal padronização cá na Wikipédia em português. --CaiusSPQR (discussão) 15h18min de 22 de março de 2019 (UTC)
Eu sempre uso {{lp}} para lincar predefinições. Sou a favor de fundir tudo, nós já usamos essas predefinições a tanto tempo que essa forma já se tornou o nosso padrão, não vejo vantagem em alterar isso agora. Danilo.mac(discussão) 16h04min de 22 de março de 2019 (UTC)
@Danilo.mac: Às vezes, é necessário utilizar predefinições diferentes de {{tl}}. Manualmente escrever <nowiki>{{[[Predefinição:...]]}}</nowiki> (ou "apenas" <nowiki>{{...}}</nowiki>) tem-se tornado um incómodo, pois nem sempre é uma boa ideia utilizar a {{tl}} com a tag <code>...</code> (por questões visuais, como utilizar {{tlx}} em hatnotes). Também em documentações das predefinições não faz o mínimo de sentido utilizar {{Tl}} (ou mesmo {{tlx}}), pois ambas geram um link para a página da predefinição, o que não faz o mínimo de sentido um link para a própria página na documentação. Daí surge a necessidade de várias predefinições (inclusive existe {{tlg}} com várias possibilidades de edição de Tls. —CaiusSPQR (discussão) 16h21min de 22 de março de 2019 (UTC)
Me expressei mal, sou a favor de fundir as que fazem a mesma coisa, como a tl, tlx, lp e lpx. Temos também predefinições que fazem coisas diferentes como {{código}} e {{nowiki}} e várias predefinições de formatação, ou podemos simplesmente criar novas predefinições se não existir uma que faça o que queremos. Não precisamos mudar as predefinições que estamos acostumados a usar para criar novas funções. Danilo.mac(discussão) 16h54min de 22 de março de 2019 (UTC)
@Danilo.mac: Sua proposta então é fundir as predefinições e criar uma para atender a minha proposta? Que diferença faz alterar a {{Tl}}? Já foi alterada quando adicionaram <code>...</code>. —CaiusSPQR (discussão) 17h13min de 22 de março de 2019 (UTC)
Eu nem lembrava que existia outras além da lp e tl, esse é meio que o padrão que todos usam e provavelmente continuaram usando, eu pelo menos continuarei usando a lp. Se a maioria achar que não é necessário usar <code> por mim tudo bem, só não vejo necessidade de passar robô em milhares de páginas por causa disso. Danilo.mac(discussão) 17h57min de 22 de março de 2019 (UTC)

Predefinição:Tabela de certificaçãoEditar

Olá, venho humildemente, pedir a sua ajuda para melhoria do artigo Predefinição:Tabela de certificação. Gostaria de pedir a sua contribuição para me ajudar na melhoria dessa Predefinição, deixando-a mais atual, pois a mesma não consta o número de vendas, apenas certificações. Eu tentei mas não estou conseguindo. Agradeço desde já a sua atenção.

Discussão em Predefinição Discussão:Data#Remover links e dia da semanaEditar

Convido-vos a discutir sobre o uso de links e dias da semana na predefinição {{Data}} --CaiusSPQR (discussão) 00h14min de 26 de março de 2019 (UTC)

ReferênciasEditar

Existe um problema importuno com a predefinição {{Referências}}. Ela possui em seu próprio código a secção Referências, que me parece desnecessária (digitar manualmente == Referências == não mata ninguém), mas como a predefinição é usada com muita frequência, não falarei nada sobre isso enquanto não cause problemas. Mas atualmente ela causa. Por a secção estar diretamente dentro da predefinição, o software wiki interpreta que a predefinição está dentro da última secção, o que visualmente para um leitor não faz qualquer diferença, mas para um editor, o código fica desorganizado. Por exemplo, não é possível editar manualmente a secção; para editar, é necessário que seja editado a última secção ou mesmo todo o artigo. Também é ruim pois causa problemas no resumo da edição (aparece algo como /*[nome da última secção antes da secção Referências]*/ em vez de /*Referências*/).

Assim, queria saber se há alguma forma de "substituir" a predefinição, para que se substitua apenas o título da secção, com o resto da predefinição ainda com o predefinição normal. --CaiusSPQR(discussão) 17h58min de 27 de março de 2019 (UTC)

Veja também Wikipédia:Esplanada/propostas/Depreciar Predefinição:Referências em favor de Extension:Cite (28fev2018).
Não li toda essa discussão na esplanada, mas se isso for realmente necessário e houver consenso dá para passar um robô trocando tudo. Danilo.mac(discussão) 23h00min de 27 de março de 2019 (UTC)
@Danilo.mac: Não acho que a proposta citada é sobre o que estou a referir-me. Não me importo muito com a predefinição (embora me pareça desnecessária já que é possível fazer o mesmo que ela faz, mas com duas linhas de código). Estou a reclamar desses problemas indesejáveis que existem ao utilizar a predefinição, e só queria saber qual é, caso possível, a forma mais fácil de separar a secção "Referências" da parte integral da predefinição. —CaiusSPQR(discussão) 23h40min de 27 de março de 2019 (UTC)
@CaiusSPQR: São dois problemas diferentes com a mesma solução, o que foi proposto naquele tópico é parar de usar a {{referências}} e passar a usar == Referências ==(quebra de linha)<references/>, o que também solucionaria o problema que você apontou. Como são muitas páginas é preciso um consenso na esplanada antes de colocar um robô para trocar todas predefinições, e como essa troca solucionaria dois problemas pode ficar mais fácil conseguir o consenso. Até onde sei, não existe outra forma mais fácil de resolver o problema que você apontou. Danilo.mac(discussão) 00h56min de 28 de março de 2019 (UTC)
@Danilo.mac: Entendi. Eu realmente não queria que a única solução fosse eliminar a página ou ter de modificar quase todas as páginas da Wikipédia com bots, pois, por mais que não goste de usá-la, há quem a use, inclusive pode achar até mais prático. Ainda assim, vou continuar a tentar encontrar alguma solução viável. Obrigado de qualquer maneira. —CaiusSPQR(discussão) 01h32min de 28 de março de 2019 (UTC)
Também acho preferível que o título da seção não seja inserido como parte da predefinição, e sim fora dela. Sempre que insiro referências, prefiro colocar o título e a tag <references/> separadamente, sem qualquer predefinição. Além disso, a tendência é eliminar esse tipo de predefinição das wikis (phab:T95543). Helder 16h54min de 30 de março de 2019 (UTC)

Predefinição:Info/OceanoEditar

Olá a todos. Eu estou arrumando o artigo do mar da Noruega e usei essa predefinição, mas ela está muito confusa de usar. Eu não consigo achar um jeito de adicionar os parâmetros que estão sendo alimentados pelo Wikidata. e ao que parece isso se deve à forma como ela foi construída. Dbastro, como foi você que moveu a predefinição em 2018, sabe o que fazer?--Rena (discussão) 02h57min de 29 de março de 2019 (UTC)

Boas @Renato de carvalho ferreira:, a predefinição tem uma função para listar elementos de dimensão, e também não aceita alguns parâmetros informados, vou tentar corrigir a doc de {{Info/Oceano}} e ver se se consegue melhorar como em {{Info/Rio}} e outras pred. de caixas de informação. -- Dbastro (discussão) 13h27min de 29 de março de 2019 (UTC)

Dados da infobox não aparecemEditar

Qual o problema nesta {{Info/Desafio de internet}} que não exibe a descrição informada? - Elilopes DEBATE 15h46min de 29 de março de 2019 (UTC)

  Pergunta: quantos "desafios de internet" existem que foi necessário criar uma infocaixa somente para [padronização da apresentação de um resumo de informações sobre] esse "assunto"? Fiquei curioso pensando…  --Luan (discussão) 15h21min de 30 de março de 2019 (UTC)
  Concordo com o levantado pelo Luan. Pelo bem da padronização, acredito que o mais prudente teria sido empregar alguma infocaixa já existente, em vez de criar uma tão específica e que engloba tão poucos artigos. Imagino que a {{Info/Efeméride}} teria sido capaz de cumprir as exigências. --ArgonSim (ajuda contato) 10h22min de 8 de junho de 2019 (UTC)

Texto alternativo para imagens com erro?Editar

Não sei se preciso ativar alguma função aqui, mas não consigo visualizar nenhum texto alternativo em ficheiros. Exemplos recentes: criei Lista de canções gravadas por Madonna e Lista de canções gravadas por Anitta com várias legendas alternativas nos ficheiros, mas nenhuma delas aparece quando passo o cursor sobre as imagens. O que pode estar ocorrendo? Alguém mais tem esse problema? Jardel.[5.250] d 00h50min de 31 de março de 2019 (UTC)

Ninguém? Jardel.[5.250] d 06h15min de 12 de abril de 2019 (UTC)
Texto alternativo é para quando a imagem não pode ser exibida ou quando algum(a) leitor(a)/editor(a) utiliza um leitor de ecrã. Para texto para ser exibido quando passar o rato sobre a imagem, apenas escreva o que quer. Isso, no entanto, não irá funcionar quando a imagem for uma miniatura/thumbnail.
Exemplo: [[Ficheiro:Example.svg|100x100|Esta é uma imagem de exemplo.]] exibe o texto ao passar o rato sobre a imagem; [[Ficheiro:Example.svg|thumb|Esta é uma imagem de exemplo.]] não. (O texto aparece como legenda abaixo da imagem.) --CaiusSPQR(discussão) 21h35min de 20 de abril de 2019 (UTC)
@CaiusSPQR: Entendi. Mas por que isso só acontece aqui? No caso do artigo da Madonna, tudo que está lá eu transcrevi da Wiki-en - inclusive os ficheiros com o mesmo código. Outro exemplo está nas Predefinições Info. Eu traduzi este artigo com base no artigo em inglês e coloquei também a legenda alternativa no campo correspondente da Info/Canção, mas ela não aparece. Há um tempo atrás isso não acontecia. Jardel.[5.250] d 07h08min de 22 de abril de 2019 (UTC)
Em en:List of songs recorded by Madonna não acontece nada quando passo o rato sobre a fotografia de Madonna (ela possui texto alt). Creio que nada se passa, pois é uma thumbnail. Já em en:So Yesterday, aparece o texto alternativo porque não é uma thumbnail. Acho que isso não ocorre cá na ptwiki por causa da predefinição de infobox. Talvez porque a infobox na enwiki utiliza o módulo Módulo:InfoboxImage, e a infobox na ptwiki não. --CaiusSPQR(discussão) 15h05min de 22 de abril de 2019 (UTC)

Lista de vigiadosEditar

Em relação a lista de vigiados, estão fazendo algumas modificações? Nos últimos dois dias, minha lista de vigiados esta apresentando situações fora do padrão, como: mesmo depois de acessada a página, a mesma continua marcada em negrito na lista ou ao acessar uma página que esta em negrito e fazer a reversão (seja ela uma reversão ou modificação), continua em negrito, mas agora indicando a minha edição (diferente do "padrão" que era indicar no início da lista, após a reversão, mas sem estar em negrito). O "R" Aliado 18h34min de 11 de abril de 2019 (UTC)

Estou com o mesmo problema, mas não é novidade. Saturnalia0 (discussão) 23h58min de 11 de abril de 2019 (UTC)
@O revolucionário aliado e Saturnalia0: esse bug já foi reportado e não é exclusivo daqui, vide phab:T218511. Abraços, e boas edições! —Thanks for the fish! talkcontribs 14h59min de 12 de abril de 2019 (UTC)

Referente a página de vigiados, não consigo ver ou editar a minha lista completa de páginas (dá "erro no servidor"). É por causa da quantidade ("Existem 28 731 páginas na sua lista de páginas vigiadas")? Jardel.[5.250] d 06h18min de 12 de abril de 2019 (UTC)

A minha tem esta quantidade de vigiados (28,5 mil), mas só fica pesada quando coloco para incluir na mesma página, mas de 20 dias de edições não vigiadas, mas carregam todas, com certa demora. O "R" Aliado 17h48min de 12 de abril de 2019 (UTC)

Eu tenho uma ordem de grandeza a menos e tenho o problema de não atualizar as vigiadas, mas de não carregar nunca tive. Eu faço limpeza periódica usando a opção de editar em formato de texto. Um editor de texto bom como vi ajuda na tarefa. Saturnalia0 (discussão) 23h13min de 12 de abril de 2019 (UTC)

Ferramentas quebradas na Predefinição:AnontoolsEditar

Algumas das ferramentas na predefinição já não existem mais, mais especificamente o CheckTOR e traceroute (o IP nos links é real, de um proxy aberto).
Para o Checktor eu não consegui encontrar uma nova versão no Toolforge, pro traceroute há algumas online, como essa, por exemplo.
Acho que seria interessante adicionar o IPCheck na lista também, ele traz um agregado de informações sobre o IP de várias fontes diferentes. Carlos C. disc. / contrib. 21h37min de 1 de maio de 2019 (UTC)

Algum comentário? Não vou editar uma predefinição dessas sem antes consultar alguém. Carlos C. disc. / contrib. 18h17min de 8 de maio de 2019 (UTC)
@CarlosCunha: após discutir com o SQL, acredito que não seria bom adicionar o IPCheck na lista, pois há limite mensal nas consultas a determinadas APIs, e adicionar em uma predefinição com alto acesso não seria válido pois pode exceder esse limite. Quanto às outras ferramentas, não oponho-me a alterá-las, e vou tentar buscar alternativas. Abraços, —Thanks for the fish! talkcontribs 15h15min de 9 de maio de 2019 (UTC)
@Tks4Fish: Entendo. Uma pena, pois é uma excelente ferramenta. Vou procurar alternativas às outras ferramentas também. Abraço! Carlos C. disc. / contrib. 17h49min de 9 de maio de 2019 (UTC)
Para o CheckTOR existe uma ferramenta do próprio Tor Project, porém é necessário passar um timestamp. Nesse teste que eu fiz, pro exemplo, só consegui resultado positivo colocando a data de 3 dias atrás: https://metrics.torproject.org/exonerator.html?ip=100.11.96.205&timestamp=2019-05-15&lang=en. Não sei se vale a pena usar. Já para o traceroute, eu conversei com o pessoal da KeyCDN, dessa ferramenta: https://tools.keycdn.com/traceroute, foi a única que achei que funciona bem e suporta IPv6. Eles disseram que estão passando por um redesign, e pediu para que retornasse o contato em algumas semanas para que eles possam implementar a funcionalidade de passar o IP usando um parâmetro de URL. Carlos C. disc. / contrib. 16h06min de 17 de maio de 2019 (UTC)

Compartilhamento multilíngual de predefinições e módulosEditar

Olá comunidade da pt-wiki ! (Por favor, ajude a traduzir para o seu idioma) Recentemente organizei um projeto para compartilhar predefinições e módulos entre wikis. Ele permite que os módulos e predefinições possuam uma "linguagem neutra", e armazena todas as traduções de texto no Commons. Isso significa que será suficiente copiar/colar uma predefinição sem alterações de uma wiki para outra e atualizar as traduções separadamente. Se alguém corrige um bug ou adiciona um novo recurso no módulo original, você pode copiá-lo/colá-lo novamente sem qualquer trabalho de tradução. Meu bot DiBabelYurikBot pode ajudar com a cópia. Dessa forma, os usuários podem gastar mais tempo no conteúdo e menos tempo na atualização e na cópia de predefinições. Consulte a página do projeto para obter detalhes e fazer perguntas na página de discussão.

P.S. sou atualmente candidato a membro do Conselho da Wikimedia, com foco em conteúdo e suporte de comunidades de vários idiomas. Se você gostou dos meus projetos como mapas, gráficos, ou este, eu me sentiria feliz em receber o seu apoio. (qualquer grupo de usuários registrado pode votar). Obrigado! --Yurik (🗨️) 06h26min de 11 de maio de 2019 (UTC)

Predefinição:Página para eliminarEditar

Fui avisado (55130972]) pelo @CarlosCunha: que a {{página para eliminar}} está adicionando sua subpágina {{página para eliminar/doc}} nas propostas de WP:EC. Desfiz (55132426]) a adição da {{documentação}}, e presumo (55132419]) que seja um bug no gadget fastbuttons. Alguém poderia fazer funcionar propriamente a {{documentação}}? TheJoker 22h02min de 13 de maio de 2019 (UTC)

Edições do bot InternetArchiveBot deixam erros nas referênciasEditar

Edições como estas 55151538] estão deixando erros nas referências "wayb= e |arquivodata= redundantes; |wayb= e |arquivourl= redundantes"

Não seria possível programar esse robô para não colocar o link quando já houver o |wayb= ? Esse formato é muito mais simples, até já coloca a data de arquivamento e não é quilométrico como o do bot. Já conseguimos tornar um artigo "destacado", removendo milhares de bites com o uso dessa predefinição. O bot não consegue colocar simples parâmetros como |wayb= e |urlmorta=sim, quando a ligação estiver morta?--PauloMSimoes (discussão) 21h47min de 15 de maio de 2019 (UTC)

@PauloMSimoes: conversei com o Cyber (mantenedor do bot), e criei uma tarefa no Phabricator, para que ele possa resolver esse problema. Abraços, —Thanks for the fish! talkcontribs 22h55min de 15 de maio de 2019 (UTC)
Caro @Tks4Fish: obrigado pela atenção. Eu não tinha observado que o bot é controlado por um editor de fora,. Creio que um dos problemas seja que na anglófona, o parâmetro |wayb= não existe. Creio que seja necessário transcluir lá (esse é o termo?) e a partir daí ver a possibilidade de fazer a alteração. Como leigo no assunto, tenho observado que as edições do bot colocam o número equivalente ao preenchimento de "wayb" e por isso penso que não seria difícil a alteração. Por exemplo, em uma das alterações no exemplo que dei no início 55151538], o número colocado "20130424085116" é exatamente o mesmo para o preenchimento do campo "wayb", que é a data do arquivamento (24 de abril de 2013), que faz com que essa data seja adicionada de modo automático. Eu particularmente gosto muito do "wayb", que é muito mais fácil de usar nas citações de links arquivados.--PauloMSimoes (discussão) 00h07min de 16 de maio de 2019 (UTC)

Em boa hora. Eu já tinha desistido de falar no assunto, pois no último ano chamei a atenção para a situação várias vezes e nada aconteceu. Aliás, ultimamente, por ter pouco tempo, as minhas tarefas de edição por aqui são quase exclusivamente corrigir o lixo inserido por esse bot. Há ainda dois detalhes que seria bom serem corrigidos:

  1. Não colocar urlmorta=no em alguns casos em que a página obtida com o URL é um erro HTML 404. Não sei se é possível tecnicamente, pois possivelmente só acontece quando o site tem uma landing page para os erros 404 e não assinala erro via HTTP.
  2. A adição de ?url= a seguir aos arquivos de webcitacion.org, pois é completamente redundante. --Stego (discussão) 00h09min de 16 de maio de 2019 (UTC)

@PauloMSimoes, Stegop e Tks4Fish: Já realizei diversas contestações sobre o robô, na última vez o Mr. Fulano chegou a bloquear a conta, mas desbloqueou com a alegação que os pontos questionados foram corrigidos. O principal problema é a inserção de dois parâmetros com a mesma função, como citado pelo Paulo. Normalmente o robô procura por fontes que possuem "urlmorta" como positivo, mas ele não consegue atender o parâmetro "wayb", sendo assim, ele vê o caso como necessário inserir o arquivo, por conta desta incapacidade de verificar que o arquivamento já está incluído. Normalmente verifico as edições do robô apenas nos meus artigos, mas pelo visto o problema continua. Edmond Dantès d'un message? 09h12min de 26 de maio de 2019 (UTC)

@Conde Edmond Dantès: exatamente. Apesar de não entender nada desse assunto, acredito que seja fácil programar o bot para apenas substituir "no"/"não" por "yes"/"sim", quando já houver os parâmetros |wayb= e |arquivourl=. Enquanto não há uma solução, também estou corrigindo os erros manualmente, nas minhas vigiadas.--PauloMSimoes (discussão) 16h10min de 26 de maio de 2019 (UTC)
Acredito ser possível sim, principalmente na questão da tradução, que pode ser facilmente corrigida ao adicionar um parâmetro pra português em paramlang.json, assim como há para o espanhol na linha 179. Sobre o |wayb=, imagino ser possível adicionar um if para toda vez que houver o parâmetro escrito no código da referência, ele não adicione parâmetros adicionais. Mr. Fulano! Fale 19h34min de 26 de maio de 2019 (UTC)
Outro detalhe é que o bot só procura páginas arquivadas no wayback. Se procurasse também em archive.is, muitas marcações "ligação inativa" deixariam de ser colocadas por ele, como já verifiquei em várias de suas edições, como em 55285929]. Obs: na edição esqueci de colocar "urlmorta= sim", mas depois inseri o parâmetro.--PauloMSimoes (discussão) 20h22min de 26 de maio de 2019 (UTC)
Acredito ser possível fazer isso também, mas acredito ser mais difícil pois será necessário criar um outro código para poder usar o archive.is. Aproveito e chamo o Cyberpower678 para essa discussão, já que é ele o criador do bot. If you have some problem to get something wrote here, talk with me to translate to you. Mr. Fulano! Fale 20h57min de 26 de maio de 2019 (UTC)
So the problem here is that IABot shares a codebase among several dozen wikis. Only on ptwiki do the cite templates have a wayb parameter, something the bot is not coded to handle at this time. This will take a bit of coding to integrate this feature and then define it in the configuration files. Also as to me not getting to this sooner, with so much on my plate, I forgot about this because there was no Phabricator task open until recently, which I rely on to making sure all reported bugs are fixed. I am currently working on a solution for this particular problem. I should have a solution ready for the beta16 release.—CYBERPOWER (discussão) 23h57min de 26 de maio de 2019 (UTC)
@Cyberpower678: Thanks for all, if you need help to translate some parameter to add in the code, let us know. Mr. Fulano! Fale 02h25min de 27 de maio de 2019 (UTC)

───────────────────────── Só para avisar que efetuei o bloqueio do robô, os problemas em pauta persistem. Edmond Dantès d'un message? 20h17min de 1 de junho de 2019 (UTC)

Reduzir o tamanho do infoboxEditar

Tem por ai algum programador que saberia como reduzir o tamanho do infobox para esse template => {{#invoke:Info/Gene|getTemplateData|QID=Q000000}}. Eu utilizei AQUI e por conta do seu tamanho, impossibilitou a inclusao de adicional information. Obrigado   Vida longa e próspera! Dr. LooFale comigo 21h13min de 16 de maio de 2019 (UTC)

@Luizpuodzius: Por reduzir o tamanho você se refere a compactá-la verticalmente, seja recolhendo parte de suas seções ou até mesmo removendo campos que você consideraria desnecessários ao artigo? --ArgonSim (ajuda contato) 20h46min de 17 de maio de 2019 (UTC)
Sim, gostaria "compactá-la verticalmente" para que as informacoes addicionais nao empurrem o infobox para baixo. Gostaria de poder usar linguagem tecnica, mas meu conhecimento no assuto e' rudimentar. Gostaria que a caixa funcinasse da mesma forma que funciona aqui. Seria possivel fazer isso? Dr. LooFale comigo 01h27min de 19 de maio de 2019 (UTC)
@Luizpuodzius: Tive de fazer os testes no próprio artigo por conta da dependência dos dados do Wikidata, portanto me desculpe por ter poluído o histórico de edições dele. Mudei tanto a tabela "padrão de expressão RNA" quanto a "ortólogos" para recolhível, o que fez com que a infobox ficasse consideravelmente mais compacta. Se achar que algum deles deveria ficar expandido por padrão, avise-me para que eu reverta a mudança no item (ver Fator de alongamento de tradução eucariótica 1 alfa 1 como exemplo). Sugestão: se for de seu interesse, seria bom que fosse traduzido o artigo en:Gene ontology para ontologia genética, uma vez que é estranho ver uma infobox com identificador para um artigo inexistente.--ArgonSim (ajuda contato) 16h36min de 23 de maio de 2019 (UTC)
@Danilo.mac: Obrigado pela ajuda. Vou traduzir o artigo en:Gene ontology para ontologia genética, mas tem uma 1/2 duzia de expressoes e termos usados em informatica que eu nao sei se devo ou nao ser traduzido. Dr. LooFale comigo 20h52min de 24 de maio de 2019 (UTC)
@Luizpuodzius: Em situações assim, o padrão é traduzir apenas se isso for comum em textos daquele assunto na língua portuguesa. Nos casos em que não for possível encontrar um texto em português citando o termo, o recomendado é mantê-lo na língua original para se evitar pesquisa inédita. --ArgonSim (ajuda contato) 15h58min de 25 de maio de 2019 (UTC)
@Luizpuodzius: O erro estava no módulo, corrigi o módulo e coloquei a infobox usando a {{Info/Gene}} (que usa o mesmo módulo) e coloquei antes do texto no código-wiki para que ela fique ao lado do texto. Compactá-la verticalmente já é mais difícil, o ideal seria criar uma nova infobox sobre genes um pouco menor e com a opção de preencher dados localmente, para isso alguém que entenda mais sobre genes precisaria ver quais informações são realmente necessárias para serem adicionadas na nova infobox. Danilo.mac(discussão) 03h16min de 20 de maio de 2019 (UTC)

Pedido de ajuda para a Info/FaraóEditar

Olá, gostaria de saber se tem alguém ai que gostaria de me ajudar a dar uma limpada na Predefinição:Info/Faraó? Estou começando a editar alguns artigos sobre Egito Antigo e percebi que o código dessa predefinição é extrema e desnecessariamente complexo e que está praticamente inalterado desde que a predefinição foi criada quase 10 anos atrás em agosto de 2009. Não considero que tenho o conhecimento necessário para realizar eu mesmo essas edições, por isso estou vindo aqui. Minha principal ideia é refazer a predefinição usando como base a Predefinição:Info e principalmente encontrar um jeito melhor de fazer a seção sobre os nomes egípcios. Quem estiver interessado, pode me responder aqui ou na minha página de discussão e entraremos em mais detalhes. Obrigado. Cléééston (discussão) 03h38min de 22 de maio de 2019 (UTC)

Acho que posso ajudar, mas não sei quando. Se eu não der notícias até à próxima semana, por favor, relembre-me. --Stego (discussão) 17h10min de 22 de maio de 2019 (UTC)
@Stego: ok Cléééston (discussão) 18h41min de 22 de maio de 2019 (UTC)

Sueco e finlandêsEditar

Olá a todos. Não sei por qual razão, quando usado lang-, o código sv, pertencente ao sueco, está sendo usado para o finlandês, sendo que no langx isso não ocorre. Alguém poderia verificar se alguém não trocou acidentalmente o código?--Rena (discussão) 20h26min de 24 de maio de 2019 (UTC)

Alguém? E já aproveito para falar de outra coisa, que talvez o Dbastro seja ideal pra me ajudar. Como acontecia com a info/Rio, a {{Info/Farol}} tem muitos parâmetros que existe apenas no Wikidata, e não temos aqui. Se você pudesse importar esses parâmetros como fez para os rios, ficaria muito agradecido. Aliás, em Långe Jan, por exemplo, vários parâmetros que aparecem automaticamente de lá estão em inglês.--Rena (discussão) 17h02min de 27 de maio de 2019 (UTC)
  Corrigido {{lang-sv}}. Realmente o código estava trocado. Por mim acabava-se com essa miríade de lang-yy. Em todo o caso, aproveito todas as vezes que tenho que mexer em alguma dessas predefs para que passem a usar o padrão {{língua-meta}}. --Stego (discussão) 17h48min de 27 de maio de 2019 (UTC)
@Stego: concordo contigo sobre acabar com as predef "lang-yy", substituindo-as por {{langx}}. --Luan (discussão) 19h59min de 27 de maio de 2019 (UTC)

Categorização "sem assunto"Editar

Oi. A Predefinição:Sem fontes tem um sistema de categorização temática dentro de si. Entretanto, caso o editor não informe nenhum assunto dentro da etiqueta, o artigo não é categorizado por assunto. Eu acho que seria interessante que, na hipótese de nenhum assunto ser indicado, o artigo ser categorizado como "sem indicação de assunto". Isso permitiria que editores com capacidade de AWB passassem nessa categoria "sem assunto" categorizando-os.

É uma forma de triagem muito menos trabalhosa do quê a que tenho feito mensalmente, pois com o PetScan ou alguma outra ferramenta é possível montar listas de intersecção de categorias. Por exemplo: "sem fontes desde dezembro de 2010" interseção com "sem fontes sobre entretenimento". Se eu pudesse fazer intersecções assim, meu trabalho seria muito mais fácil, mas isso depende, em primeiro lugar, dos artigos estarem categorizados por assunto! E para estarem categorizados por assunto, eu necessito saber quais não estão.

--Mister Sanderson (discussão) 13h18min de 26 de maio de 2019 (UTC)

  Comentário: não sou contra, mas note-se que isso é desnecessário, pois quando há indicação de tema, as páginas não são categorizadas na categoria-mãe. Ou seja, atualmente as que estão na categoria-mãe não têm tema atribuído. --Stego (discussão) 20h55min de 26 de maio de 2019 (UTC)
Stego, você está me dizendo que apenas os 33 artigos listados em Categoria:!Artigos que carecem de fontes não têm indicação de assunto?--Mister Sanderson (discussão) 22h12min de 26 de maio de 2019 (UTC)
@MisterSanderson: Ups. Tem razão. Basta que tenha data para que não apareça na categoria-mãe. Passo a   concordar com a proposta e acho que a mesma coisa deve ser aplicada às outras marcas que categorizam por tema. --Stego (discussão) 22h21min de 26 de maio de 2019 (UTC)
Stego, você tem tempo para aplicá-la? É necessário esperar mais gente opinar?--Mister Sanderson (discussão) 16h10min de 13 de junho de 2019 (UTC)
@MisterSanderson: acho que não é preciso esperar mais. Mas como agora estou sem tempo, lembre-me da implementar caso eu me esqueça do fazer nos próximos dias. --Stego (discussão) 21h40min de 14 de junho de 2019 (UTC)

Erro: a ferramenta de citação automática do editor visual preenche o url indevidamente quando indicado oclcEditar

O Luizgustavovasques chamou-me a atenção para um erro nas predefs de citação (que eu nunca usei): quando se preenche o parâmetro oclc é também preenchido o url para o worldcat.org. Isso está errado por duas razões: i) o URL dev apontar para um endereço que contenha o conteúdo da fonte, o que o worldcat não faz; ii) o preenchimento do parâmetro oclc já gera um link para o worldcat. O efeito disso pode ser visto aqui.

Alguém pode corrigir isso, por favor? Obrigado. --Stegop (discussão) 20h58min de 27 de maio de 2019 (UTC)

  Comentário Apenas complementando o erro apresentado pelo Stegop; o erro ocorre ao preencher o ISBN ou o OCLC na ferramenta de citação automática do editor visual.
@Stegop e Luizgustavovasques: Se entendi bem, foi utilizado o Citoid para gerar essa referência, certo? Nesse caso, tenho a impressão de que qualquer que seja a correção está além do alcance dos editores da Wikipédia. As únicas modificações acessíveis para nós seriam mudar que predefinição (citar web, citar jornal...) corresponderia ao tipo de citação identificada pelo Citoid (blogPost, journalArticle...) e, a partir da predefinição correspondida, mudar que parâmetro dela (|título=,|obra=...) corresponderia aos parâmetros identificados pelo Citoid (title, publicationTitle...). O caso citado seria corrigido impedindo que o parâmetro 'url' fosse derivado do 'oclc'. No entanto, isso é algo que apenas os desenvolvedores da ferramenta podem fazer, sendo necessário abrir um pedido na página de discussão correspondente. --ArgonSim (ajuda contato) 10h00min de 8 de junho de 2019 (UTC)

Assunto dos artigosEditar

Programadores, tenho criado tópicos na Esplanada mensalmente para tratar dos artigos há mais tempo sem fontes... Porém, estou com um problema: eu sempre faço a triagem temática manualmente, abrindo os artigos um-por-um e lendo a introdução para determinar qual é o tema o qual ele aborda. Isso funcionava razoavelmente até agora, muito embora eu perdesse muitas horas com isso, nas quais eu poderia estar fazendo algo mais útil para a Wikipédia ou para mim mesmo. Entretanto, os artigos etiquetados como sem-fontes desde dezembro de 2009 passam de 1500! São artigos demais, e a triagem manual se torna inviável.

Vocês conhecem algum truque/ferramenta para determinar automaticamente os assuntos de um grande número de artigos?

--Mister Sanderson (discussão) 21h10min de 30 de maio de 2019 (UTC)

Predefinição voltou a dar erroEditar

Já havia reportado aqui e corrigiram, mas a predefinição {{dtlink}} voltou a apresentar erro. Exemplo: Jovem Pan News Fortaleza. Jardel.[5.250] d 04h11min de 1 de junho de 2019 (UTC)

@JardelW: Assim como no caso anterior, foi um problema com a maneira pela qual o software identifica as quebras de linha e textos pré-formatados (estranho esses problemas só estarem surgindo agora; talvez sugira que houve uma mudança recente). Pela dificuldade em identificar exatamente qual quebra de linha era defeituosa, fui removendo algumas até que a predefinição voltasse a se comportar normalmente. Por questões de legibilidade, vou tentar descobrir exatamente qual foi para poder reverter as outras removidas desnecessariamente. Pode ser necessário purgar o cache do artigo para que a correção seja perceptível. --ArgonSim (ajuda contato) 10h15min de 8 de junho de 2019 (UTC)

Coordenadas do topo da página aparecendo incorretaEditar

Algum programador poderia por gentileza verificar o que acontece nesta página. Salvei a página com a coordenada errada e não estou conseguindo corrigir. JMGM (discussão) 19h39min de 1 de junho de 2019 (UTC)

Predefinição com lacunasEditar

Olá colegas programadores, a predefinição {{idade em anos e meses}} tem alguns erros:

  • Na idade de 1 ano e 1 mês coloca 1 anos e 1 meses, com os plurais desnecessários
  • Na idade de 1 ano coloca 1 ano e 0 meses, com os meses desnecessários
  • Na idade de 1 mês coloca 1 meses, com o plural desnecessário
  • Numa idade inferior a 1 mês coloca 0 meses, até 30 dias a idade ficaria melhor em dias

Poderiam ajudar? Dux Æ 01h16min de 3 de junho de 2019 (UTC)

Predefinição:Info/Assentamento/NigériaEditar

Eu criei Predefinição:Info/Assentamento/Nigéria e o ponto de localização fica bem pra fora do mapa. Alguém sabe me dizer a razão?--Rena (discussão) 02h27min de 6 de junho de 2019 (UTC)

@Rena: já foi corrigido. --Stego (discussão) 00h41min de 7 de junho de 2019 (UTC)

Predefinição:Info/NobreEditar

Olá a todos. Eu adicionei alguns parâmetros novos em Predefinição:Info/Nobre, essencialmente todos presentes no tópico Titularia egípcia, mas eu gostaria de apresentar esse conteúdo colapsado nos artigos. Alguém pode incluir essa função?--Rena (discussão) 20h12min de 9 de junho de 2019 (UTC)

ArgonSim?--Rena (discussão) 20h12min de 9 de junho de 2019 (UTC)

  Comentário - Estive a editar sobre o assunto na Predefinição:Info/Nobre/Testes, contudo, não consegui fazer com que a opção de colapsar funcionasse, apesar de ver que ela funciona em {{Info/Estado extinto2}}. Talvez tenha estado a cometer um qualquer erro... Peço a alguém que tente por favor. Obrigado. E @Renato de carvalho ferreira:, tentei... mas não consegui. Desculpe-me qualquer imprevisto. Luís Almeida "Tuga1143 22h48min de 9 de junho de 2019 (UTC)

Tuga1143, agradeço imensamente a ajuda. Se alguém mais que saiba mexer com programação puder olhar, ficaria feliz. É algo que parece ser "simples", mas não sei como fazer.--Rena (discussão) 01h30min de 12 de junho de 2019 (UTC)
Leefeni de Karik, saberia fazer isso?--Rena (discussão) 01h32min de 12 de junho de 2019 (UTC)
Poxa, claramente perdi a manha... Leefeniaures audiendi audiat 01h37min de 12 de junho de 2019 (UTC)
Leefeni de Karik, poxa. Eu realmente tava precisando disso com certa urgência pra eu arrumar os artigos. Fica bem desconfigurada a infocaixa quando os parâmetros ficam abertos.--Rena (discussão) 01h59min de 12 de junho de 2019 (UTC)
Estou tendo dificuldade para discriminar a parte relevante do código e fazer funcionar. Leefeniaures audiendi audiat 02h00min de 12 de junho de 2019 (UTC)
@Renato de carvalho ferreira: Utilizei as predefinições Collapsed infobox section begin e Collapsed infobox section end (ambas da wiki-en, sem interwikis em pt) para implementar a mudança sugerida. A predefinição modificada pode ser vista aqui. Depois de alguns testes, diria que a infobox está funcionando adequadamente, então talvez já dê para importar as predefinições que faltam se elas realmente não forem redundantes com alguma outra existente aqui (embora eu não tenha encontrado nenhuma). Caso não haja nenhuma objeção, traduzirei a documentação e os parâmetros de ambas. --ArgonSim (ajuda contato) 12h23min de 13 de junho de 2019 (UTC)
ArgonSim, por favor! Ficou ótimo.--Rena (discussão) 12h38min de 13 de junho de 2019 (UTC)
@Renato de carvalho ferreira: Vou traduzi-los, então. Estava tentando fazer uma maneira para que o título da seção recolhida tivesse a mesma largura que os títulos das demais seções, mas não consegui (no momento, a seção recolhível foi criada como uma tabela dentro de um rótulo da infobox, em vez de dentro de um tópico). Se alguém tiver ideia de como isso pode ser corrigido, agradeceria imensamente. --ArgonSim (ajuda contato) 16h35min de 13 de junho de 2019 (UTC)
ArgonSim, por hora, isso é uma questão menor porque os artigos estão ficando com a infocaixa desconfigurada quando os nomes hieroglíficos são muito grandes (Osocor II), sendo impossível acompanhar a largura na infocaixa toda, do contrário, ia esmagar muito o texto. Fico imensamente grato. Cléééston, isso é do seu interesse também.--Rena (discussão) 16h38min de 13 de junho de 2019 (UTC)
@Renato de carvalho ferreira:   Feito Agora vou traduzir a documentação para que fique claro seu uso. Peço que me avise se encontrar algum erro. --ArgonSim (ajuda contato) 17h06min de 13 de junho de 2019 (UTC)
ArgonSim, a parte egípcia ficou perfeita, sem problemas. Porém, os campos subsequentes, dos santos, agora aparecem fora da infocaixa. Ver exemplo em Estêvão I da Hungria.--Rena (discussão) 21h37min de 13 de junho de 2019 (UTC)

───────────────@Renato de carvalho ferreira: Acho que já sei o que pode estar dando errado. Como não vou ter tempo pra arrumar hoje, reverti as mudanças temporariamente. --ArgonSim (ajuda contato) 21h53min de 13 de junho de 2019 (UTC)

  Feito O problema estava no argumento de um analisador sintático 'se'. Verifiquei alguns artigos com a predefinição transclusa e não percebi nenhum erro, mas peço que se me avisem caso mais algum tenha passado em branco. --ArgonSim (ajuda contato) 12h34min de 14 de junho de 2019 (UTC)

badtokenEditar

Não sei se é o local certo, mas estou recebendo várias mensagens do tipo "A API retornou o código de erro "badtoken": Invalid CSRF token." quando uso os FastButtons (falha nos avisos de bloqueio e de ER). É só comigo que isso está contecendo? Trierweiller (discussão) 18h22min de 10 de junho de 2019 (UTC)

@Trierweiller: isto ocorre comigo quando a conexão oscila. Presumo que a interrupção no tráfego de dados faça com que o script não realize as edições automáticas subsequentes. — TheJoker 23h16min de 10 de junho de 2019 (UTC)

Páginas e subpáginas de usuários em categorias de conteúdoEditar

Gostaria da colocação de algum programador nessa proposta, sobretudo a respeito de sua viabilidade. --HVL disc. 16h26min de 14 de junho de 2019 (UTC)