Wikipédia:Café dos programadores/Arquivo/2019/1

Bug na substituição de predefinição

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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

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

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Tech News writers, editors and translators wish you a pleasant 2019 year.

Recent changes

• RelatedSites extension has been undeployed. It was used to create interwiki links on Wikivoyage, now handled by Wikidata. [1]
• MediaWiki logstash logging is moving to a new infrastructure. This is an ongoing deployment. [2]
• codesearch.wmflabs.org has been updated, with new and updated repositories and a new search options for code. [3]
• On several wikis, an account named "Filtro de edições" has been created on December 17 to perform some technical maintenance on AbuseFilter. This account has sysop rights but it's a system user and no human can use it. The account already existed on wikis where AbuseFilter can perform blocks, which are issued using this account. See T212268 for more information and future plans.

Problems

• In AbuseFilter, the "Limitador" action takes three parameters: count, period and groups. They must now strictly respect the requirements listed on mediawiki.org. A list of broken filters is on Phabricator. If you're familiar with AbuseFilter, please take a look and fix them. [4]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from January 8. It will be on non-Wikipedia wikis and some Wikipedias from January 9. It will be on all wikis from January 10 (calendar).

Meetings

• Search Platform Office Hours is rescheduled to January 9. Check the details for time and date.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

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

Monitorada no Phabricator
Tarefa T210739

[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/T213631 —Pó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

Ver também: WP:Café dos programadores/Arquivo/2016/1 § Alteração da estrutura da infobox

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

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

Ver também: Tópico:Us4b07y2cg9vo7ih

Monitorada no Phabricator
Tarefa T219620

O editor CaiusSPQR reportou um erro nas mensagens que recebe aqui[5], peço que verifiquem.Jo Lorib^d 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 Lorib^d 21h47min de 12 de janeiro de 2019 (UTC)

Foi marcado como resolvido no Phabricator por Etonkovidova. --Luan (discussão) 13h32min de 16 de julho de 2019 (UTC)

InternetArchiveBot novamente

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! ^{talk•contribs} 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! ^{talk•contribs} 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 component

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

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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)

Infobox filme

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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 Lorib^d 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

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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)

você tinhe que especificar qual era a imagem que deveria ficar por cima da outra (no caso, float = Locator_Dot2.gif). Preferi utilizar a predefinição Superimpose2 porque a Superimpose deixa uma borda ao redor da imagem 2804:14C:482:72FD:5837:4300:4F49:B461 (discussão) 11h10min de 2 de julho de 2019 (UTC)

Mapa

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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)

info/Assentamento usa o que parece ser a palavra mágica formatnum: (com o dois-pontos e não barra vertical que seria a predefinição formatnum que tem outro funcionamento) que troca ponto por vírgula, e vírgula por espaço; info/Lago usa formatnumif que, dependendo de como é usada, não altera a formatação do valor. 2804:14C:482:72FD:A17C:C301:585A:6C22 (discussão) 02h41min de 5 de julho de 2019 (UTC)

Login unificado

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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

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 Categoria:Faculdades de medicina do Brasil (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: Categoria:Capitães de cavalos de Portugal (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

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êmicos

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

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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! ^{talk•contribs} 00h17min de 8 de fevereiro de 2019 (UTC)

Info/Objeto redimensionando imagem como miniatura

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

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)

@Renato de carvalho ferreira: {{falta doc}} adicionada por @Stegop: em 20h03min de 12 de dezembro de 2011 — TheJoker 04h21min de 16 de julho de 2019 (UTC)

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

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

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)

Erro na lista de EADs

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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)

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

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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 infocaixas

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

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 pedida

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)

Predefinição:Tabela de certificação

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.

Migrar Mboxes para Lua

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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 [6]) 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 [7] 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 Tlx

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

{{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)

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

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ências

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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)

Verificação de edições com alterações mínimas

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

Olá, pessoal ! Sempre tive muita dificuldade em verificar este tipo de edição [Δ54616739] em que se altera minimamente o texto. Às vezes a alteração é feita em um parágrafo muito extenso e demora-se muito para encontrá-la, como neste exemplo que produzi na minha página de testes [Δ54624967]. Pergunto: é possível tornar as alterações melhor perceptíveis?--PauloMSimoes (discussão) 13h57min de 28 de março de 2019 (UTC)

@PauloMSimoes: Você pode alterar as cores das diferenças de edição editando o seu common.css. Por exemplo você pode colocar os estilos abaixo para colocar cores com mais contraste:

/* Exibir mais contraste na diferença entre edições */
.diff-deletedline .diffchange {background: #fed168}
.diff-addedline .diffchange {background: #69b7ff}

O que você coloca no seu common.css vai alterar somente o que você vê, então pode colocar qualquer estilo que você quiser, pode colocar bordas, negrito, aumentar o texto, etc. ^Danilo.mac_(discussão) 14h57min de 28 de março de 2019 (UTC)

Perfeito, Danilo, obrigado !--PauloMSimoes (discussão) 22h28min de 28 de março de 2019 (UTC)

Eu também me incomodava com isso e acabei fazendo um script que destaca alterações que sejam apenas no espaçamento. Helder 16h58min de 30 de março de 2019 (UTC)

Muito bem, Helder. Mas não quero chegar a esse nível, é muito para mim... rss. Fiz o que sugeriu o Danilo, configurei a diff-deletedline para cinza e a diffchangedline para amarelo e agora sou muito feliz...--PauloMSimoes (discussão) 17h06min de 30 de março de 2019 (UTC)

Predefinição:Info/Oceano

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 aparecem

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?

A discussão a seguir está marcada como respondida (feito). Se quiser acrescentar mais algum comentário, coloque-o logo abaixo desta caixa.

---

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)