Wikipédia:Café dos programadores

Origem: Wikipédia, a enciclopédia livre.
Saltar para a navegação Saltar para a pesquisa
▼ Ir para o fim da página ▼
Mudanças recentes nos pedidos

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

▼ Ir para o fim da página ▼
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

Bug na substituição de predefinição[editar código-fonte]

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 Oi[editar código-fonte]

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)

Tech News: 2019-02[editar código-fonte]

18h30min de 7 de janeiro de 2019 (UTC)

Notem que a conta usada pela extensão AbuseFilter é a User:Filtro de edições (que está no grupo dos administradores) e não o fantoche User:Filtro de Edições. Helder 17h04min de 16 de janeiro de 2019 (UTC)

Bug nas movimentações[editar código-fonte]

[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 Brasil[editar código-fonte]

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 mensagem[editar código-fonte]

  • O editor CaiusSPQR reportou um erro nas mensagens que recebe aqui[5], 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 novamente[editar código-fonte]

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 Symbol support vote.svg 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)

Random portal component[editar código-fonte]

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 Simcorrigido. 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

Atualização dos números de artigos em português e de usuários ativos[editar código-fonte]

Estou com a impressão que os números não estão sendo atualizados na página de boas vindas. Alguém sabe porque ?--PauloMSimoes (discussão) 14h48min de 14 de janeiro de 2019 (UTC)

Os números estão idênticos aos da página Especial:Estatísticas. Mas lembre-se que o MediaWiki guarda o conteúdo das páginas em cache para não ter que recriá-las sempre que alguém acessa as páginas (o que tornaria o site extremamente lento). Pode forcá-lo a fazer isso mais cedo purgando a página Helder 16h42min de 16 de janeiro de 2019 (UTC)

Tech News: 2019-03[editar código-fonte]

17h55min de 14 de janeiro de 2019 (UTC)

Infobox filme[editar código-fonte]

Olá, meus caros. Eu criei um artigo dia desses sobre um filme muito antigo. Esse é um filme que (como quase todos os filmes antigos) tem duração de segundos e não de minutos, mas na Predefinição:Info/Filme quando vc insere a duração da obra, ela já aparece em minutos (é automático), sem a opção de segundos. Eu chequei outros artigos de filmes antigos e esse é um problema que existe em todos. Será que não seria possivel modificar isso para que seja possivel escolher se a duração é em minutos ou segundos. Desde já agradeço.--SirEdimon (discussão) 01h12min de 16 de janeiro de 2019 (UTC)

  • Use fração decimal, para um filme de trinta segundos, 0,5 minutos.Jo Loribd 11h56min de 16 de janeiro de 2019 (UTC)
Estão não existe forma de modificar a predefinição?--SirEdimon (discussão) 19h24min de 16 de janeiro de 2019 (UTC)
@SirEdimon:, o parâmetro duração está reservado para minutos, o que sugere é que se adicione outro parâmetro por exemplo "duração_seg" para informar a duração em segundos aparecendo "xx segundos", exemplo 15 segundos, 91 segundos etc. Neste caso deve ser possível incluir a alteração que sugeriu. -- Dbastro (discussão) 22h26min de 16 de janeiro de 2019 (UTC)
Dbastro Nesse caso quando o filme tivesse segundos e não minutos bastaria preencher o "duração_seg" e deixar o "duração" vazio? Se for isso, me parece perfeito. Para mim funcionaria bem.--SirEdimon (discussão) 22h29min de 16 de janeiro de 2019 (UTC)
SirEdimon, nesse caso já preparei uma versão com o parâmetro duração_seg em {{Info/Filme/Testes}}, mas gostaria dar um pequeno intervalo antes de atualizar a pred. principal visto ser muito utilizada. -- Dbastro (discussão) 22h58min de 16 de janeiro de 2019 (UTC)
Dbastro Ok. Se eu puder fazer algo para ajudar, basta me dizer.--SirEdimon (discussão) 00h21min de 17 de janeiro de 2019 (UTC)

O custo de tal alteração é maior do que os benefícios. Não é só o custo de fazer a alteração, é o custo de acrescentar mais um parâmetro à documentação e ter mais uma coisa a confundir todas as pessoas que quiserem usar a predefinição. Quando os únicos beneficiados vão ser meia dúzia de artigos. Porque não escrever simplesmente "<1"? Exemplo: "Duração: <1 min." JMagalhães (discussão) 01h37min de 17 de janeiro de 2019 (UTC)

Alguns dos filmes mais importantes da história do cinema só tem poucos segundos de duração. Eu acredito que a inclusão de um parametro a mais não causará tanto mal e ainda beneficiará artigos sobre filmes muito importantes para a sétima arte.--SirEdimon (discussão) 02h08min de 17 de janeiro de 2019 (UTC)
Por existirem artigos sobre filmes com duração reduzida, alguns que entraram para o domínio público, n. sei se faz falta uma infobox só para esses filmes, atualizei.a pred. e documentação. {{Info/Filme}}. Dbastro (discussão) 13h28min de 18 de janeiro de 2019 (UTC)
Nossa. Ficou perfeito. Obrigado e parabéns. Vou tentar atualizar em outros artigos. Obrigado mesmo.--SirEdimon (discussão) 18h50min de 18 de janeiro de 2019 (UTC)

Como destacar um ponto de um mapa com um círculo vermelho que pisca[editar código-fonte]

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)

Tech News: 2019-04[editar código-fonte]

20h33min de 21 de janeiro de 2019 (UTC)

Mapa[editar código-fonte]

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: Yes check.svg 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)

Login unificado[editar código-fonte]

Olá pessoal! Não sei se acontece com vocês, mas há um tempo o login unificado não está funcionando para mim. A cada nova wiki que visito, tenho de entrar com meu cadastro. Por exemplo, se entro aqui na Wikipédia em português e tenho de fazer algo no Commons; quando visito lá, tenho de informar meu nome de usuário e senha para ficar logado. Alguém sabe como fazer funcionar a bendita unificação que aconteceu tempos atrás? Grato, Luan (discussão) 14h57min de 26 de janeiro de 2019 (UTC)

Isso pode acontecer, por exemplo, se tiver mudado as configurações de cookies (de terceiros?) no seu navegador, ou instalado alguma extensão/recurso que manipule seus cookies de alguma forma (por exemplo, containers do Firefox). Tente investigar situações análogas a esta, ou talvez usar momentaneamente outro navegador ou computador ou conta de usuário. Helder 16h09min de 26 de janeiro de 2019 (UTC)
@He7d3r: obrigado por responder. Os contêineres multi-contas foram instalados em alguma atualização no Firefox tempos atrás. Fui fazer o que consta em Para usuários avançados (fim da página) e as configurações já estavam como instruído. Não sei como desativar. --Luan (discussão) 17h23min de 26 de janeiro de 2019 (UTC)
Se estiver abrindo a Wikipídia em um certo container "X", pode ser que precise abrir todas as wikis e configurá-las para sempre serem abertas neste mesmo container "X", para que compartilhem algum cookie da Wikimedia (possivelmente do https://login.wikimedia.org, mas não tenho certeza). Helder 17h27min de 26 de janeiro de 2019 (UTC)
Eu abria em nenhum contêiner. Fiz o teste abrindo em um e o acesso às contas unificadas está de volta para mim. Muito obrigado, He7d3r!! --Luan (discussão) 11h00min de 28 de janeiro de 2019 (UTC)

Moção de categorias e Wikidata[editar código-fonte]

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 acessos[editar código-fonte]

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)

Tech News: 2019-05[editar código-fonte]

18h15min de 28 de janeiro de 2019 (UTC)

Tech News: 2019-06[editar código-fonte]

17h12min de 4 de fevereiro de 2019 (UTC)

Info p/ sistemas de avaliação e trabalhos acadêmicos[editar código-fonte]

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çufe[editar código-fonte]

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)

Tech News: 2019-07[editar código-fonte]

18h45min de 11 de fevereiro de 2019 (UTC)

Info/Objeto redimensionando imagem como miniatura[editar código-fonte]

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/santo[editar código-fonte]

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)

Symbol comment vote.svg 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)
Symbol comment vote.svg 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)
Symbol declined.svg 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)

Tech News: 2019-08[editar código-fonte]

23h14min de 18 de fevereiro de 2019 (UTC)

Fastbutton para criação de página de DB[editar código-fonte]

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 imagens[editar código-fonte]

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)

Tech News: 2019-09[editar código-fonte]

21h17min de 25 de fevereiro de 2019 (UTC)

Ponto de exclamação nos títulos das categorias[editar código-fonte]

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)

Erro na lista de EADs[editar código-fonte]

O texto seguinte foi movido de: Wikipédia:Tire suas dúvidas#Erro na lista de EADs

A partir desta edição 54372831], criou-se o seguinte erro na seção "Nota" de Wikipédia:Escolha do artigo em destaque/Lista:

  • "Erro de citação: marca <ref> definida em está com atributo de grupo "" que não aparece no texto anterior."

Leandro Drudo, saberia resolver? Abraço. Caio! (discussão) 18h28min de 27 de fevereiro de 2019 (UTC)

@Caio!: Aparentemente o erro está sendo causado por Wikipédia:Escolha do artigo em destaque/Suérquero (rei lendário). Tentei resolver isso ontem, mas não achei exatamente o que resulta na mensagem. Pedro H. diz×fiz 18h31min de 27 de fevereiro de 2019 (UTC)
@Pedrohoneto: Usando {{efn}} + {{notas}}, dá certo. O problema é que a referência fica um pouco maior: deixa de ser "[1]" e vira "[nota 1]". Seria o caso de mudarmos? Caio! (discussão) 13h42min de 28 de fevereiro de 2019 (UTC)
@Caio!: O problema é que o Módulo:ECD chama a ref "speed-close" diretamente dele para que cada entrada de EAB apareça com a nota ao lado da data avisando quando a candidatura poderá ser encerrada por speed-close. Ou seja, é preciso usar a tag references na lista para o recurso funcionar corretamente. Pedro H. diz×fiz 13h59min de 28 de fevereiro de 2019 (UTC)

O texto acima foi movido de: Wikipédia:Tire suas dúvidas#Erro na lista de EADs

Salve, prezados. Alguém sabe resolver este problema? Caio! (discussão) 15h13min de 28 de fevereiro de 2019 (UTC)

@He7d3r, Dbastro e Danilo.mac: prezados, olá. Poderiam dar uma olhada neste tópico? Talvez saibam consertar o erro. Abraço. Caio! (discussão) 15h47min de 6 de março de 2019 (UTC)
Esse módulo foi o primeiro que eu fiz nos primeiros dias da extensão Scribunto por aqui, como eu não conhecia muito bem a extensão eu transcluí toda a página de votação como argumento do módulo para procurar e contar os votos em vez de usar o Title:getContent(), provavelmente é isso que está gerando esse bug. É preciso refazer boa parte do módulo para corrigir isso, pois ao mudar para o getContent tem que mudar os Lua patterns que busca os votos. Vou fazer as correções assim que possível. Danilo.mac(discussão) 16h08min de 6 de março de 2019 (UTC)
@Caio!: Problema corrigido. Aproveitei e coloquei o módulo para gerar a linha inteira e não só o placar, então a {{EAD/Link}} não é mais necessária. Danilo.mac(discussão) 19h38min de 10 de março de 2019 (UTC)
Muito agradecido, Danilo! Caio! (discussão) 13h50min de 11 de março de 2019 (UTC)

Tech News: 2019-10[editar código-fonte]

16h38min de 4 de março de 2019 (UTC)

Tech News: 2019-11[editar código-fonte]

19h29min de 11 de março de 2019 (UTC)

Bandeiras em infocaixas[editar código-fonte]

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)

Quadrados[editar código-fonte]

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)

Utilizar predefinição:Moção pedida[editar código-fonte]

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 Lua[editar código-fonte]

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 [30]) 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)