Mais recente tech news da comunidade técnica da Wikimedia. Favor informar outros usuários sobre essas mudanças. Traduções estão disponíveis.
Mudanças recentes no software
(Nem todas mudanças afetarão vocês.)
A última versão do MediaWiki ($wmf8) foi adicionada as wikis de teste em 27 de junho. Ela será ativada nas wikis não-Wikipédia em 8 de julho, e em todas as Wikipédias em 11 de julho.
No Wikisource, os nomes canônicos dos domínios "Galeria" e "Página" na extensão Proofread Page não são mais localizados (bug #47596). Por favor verifique scripts que dependam de $wgCanonicalNamespace. [1]
Um problema com o JavaScript fez as abas "Ver histórico" e "Adicionar tópico" no Vector skin serem movidos para o menu drop-down nas wikis de idiomas que se escrevem da direita para a esquerda. O problema foi corrigido e as abas estão visíveis como antes (bug #50196). [2]
Os sites saíram do ar por alguns minutos em 28 de junho.
Vários problemas relacionados com a sobreposição de elementos com a barra de ferramentas do Editor Visual foram corrigidos (bug #50096, #50159, #50324).
Informações sobre dados da predefinição são agora exibidos para predefinições que foram adicionadas a uma página (bug #49778).
As ligações para editar seção agora exibem ligações tanto para o Editor Visual quanto para a edição do código wiki (bug #49666).
As imagens agora são carregadas com segurança quando HTTPS é usado (bug #43015). [7]
Mudanças futuras no software:
O Editor Visual será ativado para todos os usuários logados na Wikipédia anglófona em 1º de julho, e para todos usuários em 8 de julho.
A partir de 1º de julho será possível carregar ficheiros WAV e FLAC no Commons, e então usá-los diretamente nas páginas das wikis (bug #49505). [8]
O tech news #26 incorretamente reportou que a conversão de áudio foi adicionada ao TimedMediaHandler; na verdade eram estatísticas sobre conversões de áudio que foram adicionadas. [10]
Segundo me pareceu perceber, a ideia é esverdear os redirects nos artigos, como são amareladas as desambiguações. Se for isso, acho que seria óptimo ! Ajudaria a rectificar muitos erros. Além disso há vários redirects errados e assim seria mais fácil serem detectados e corrigidos --João Carvalhodeixar mensagem10h13min de 2 de julho de 2013 (UTC)[responder]
A diferença é que da forma que propus não existe aba a acresentar e os redirecionamentos ficam verdes sempre, inclusive em sumários de edição, páginas especiais... ou seja, em todo lugar.—Teles«fale comigo» 10h54min de 2 de julho de 2013 (UTC)[responder]
A diferença é que talvez agora mais editores fiquem tentados a "corrigir" links que não têm nada de errado (por apontarem para um nome alternativo totalmente válido, mas que é diferente do nome que foi escolhido para o artigo).
!Silent, será possível em vez de os caracteres ficarem a verde, fazer uma mancha como nas desambiguações ? Pergunto isto porque o verde é um verde tão desmaiado que, pelo menos para mim, não é facilmente perceptível no meio do texto. De qualquer das formas, parabéns porque sempre dá uma ajuda a rectificar erros. --João Carvalhodeixar mensagem22h19min de 2 de julho de 2013 (UTC)[responder]
Stegop, será que não te aparece no ecrã aquelas frases a vermelho em todas as linhas da página da predefinição ? . Vou copiar a primeira linha.
Calendário gregoriano Outros calendários
Erro de expressão: Palavra "outros" não reconhecidaErro de expressão: Palavra "outros" não reconhecidaErro de expressão: Palavra "outros" não reconhecida
Ainda em relação ao gadget, penso que devia ser activado por defeito para todos os usuários, porque nos novos artigos os editores percebem de imediato que existe algum problema, como alguns nomes próprios iniciados por minúsculas, etc. Ao notarem essas cores no texto, provavelmente irão clicar para ver o que se passa. Vejam a quantidade de redirects rectificados num simples artigo --João Carvalhodeixar mensagem23h07min de 2 de julho de 2013 (UTC)[responder]
Contra. Não há nada de errado em um link apontar para um redirecionamento (muito menos a ponto de chamar a atenção dos leitores a esse mero detalhe que é a existência de mais de um título válido que leva a um mesmo tema). Helder02h15min de 3 de julho de 2013 (UTC)[responder]
Hélder, percebo o que queres dizer. De facto mostrar redirects e desambigs para os leitores não faz sentido, mas faz sentido mostrar para os editores. Será possível, mostrar por defeito para algumas categorias de editores ? --João Carvalhodeixar mensagem10h48min de 3 de julho de 2013 (UTC)[responder]
A implantação do Editor Visual foi adiada em uma semana. Esta planejado para ativar o editor para editores registrados em algumas Wikipédias em 22 de Julho, e em todas as Wikipédias em 29 de Julho.
Um bug que tornou impossível salvar edições pelo Editor Visual que acionavam o CAPTCHA foi corrigido. [11]
Vários bugs que ocorriam nas wikis de escrita direita para esquerda foram corrigidos na última semana (bug #49416, bug #49613, bug #50543).
O carregamento de arquivos na Meta Wiki foi restringido a administradores e ao grupo recentemente criado "uploader". Uma política de exceções está sendo desenvolvida (bug #50287). [12]
Notificações (banners) de prioridade emergencial da extensão CentralNotice serão sempre exibidos salvo se os utilizadores os tenham ocultado, ignorando a configuração dos cookies das notificações de menor prioridade. [13]
Mudanças futuras no software
O MediaWiki permitirá a escolha de uma específica página de um documento pdf ou miniatura de um arquivo de vídeo para aparecer dentro da tag <gallery /> (bug #8480). [14]
Será agora possível criar mensagens vazias no domínio MediaWiki:, para desativá-las por exemplo (bug #50124). [15]
O Nearby será em breve ativado nas wikis Wikivoyage novamente. [16]
As mensagens da extensão Notifications incluirão uma ligação directa às mudanças entre as edições (diffs) nas wikis assim como nos e-mails de notificação (bug #48183). [17]
O índice de conteúdos (TOC) agora utilizará o elemento HTML <div /> ao invés do <table />, corrigindo um bug de nove anos bug #658. [18]
Os primeiros mock-ups de uma aplicação móvel Wikidata foram publicados por Pragun Bhutani como parte do seu projecto do Google Summer of Code. [19]
Não está mostrando os totais {{PAGESINCAT:!Páginas para eliminação rápida}} e {{PAGESINCAT:!Todas as páginas para eliminação semirrápida}} no Portal comunitário, no lugar do total mostra o número 0(e não estão zeradas, nas MR aparece o número correto). Tentei corrigir para ver se aparecia, sem sucesso... Alguém sabe corrigir ? Vulcan (discussão) 03h56min de 10 de julho de 2013 (UTC)[responder]
Cainã, a única consequência de usar muitas vezes na mesma página os comandos "exigentes" (os que estão marcados como "expensive") é que se exceder o limite configurado pelos administradores do sistema (500 atualmente), elas não funcionarão. O limite é estabelecido de modo que usando tal quantidade não haja qualquer problema para os servidores. Então, a princípio, não precisamos nos preocupar com o desempenho propriamente dito, mas com o fato de que é inútil tentar usar mais do que a quantidade permitida... Helder15h45min de 10 de julho de 2013 (UTC)[responder]
Olá. Tenho várias algumas dúvidas em relação a tradução das mensagens do Mediawiki. Sei que não é a minha praia mas acontece que mw:Localization é muito confusa e não explica muita coisa, falta uma página de ajuda ao sistema em geral e também específica às Wikipédias, principalmente à lusófona, que engloba duas variantes. Fui descobrir o Translatewiki muito depois de ter me registrado e acredito que a maioria dos editores aqui ignora sua existência.
Além disso, qual o papel da página Especial:Todas as mensagens no "esquema geral das coisas" e qual a razão de todas aquelas mensagens não criadas mas que estão definidas?
Desculpa tantas perguntas, mas penso em criar, a partir das eventuais explicações aqui, algo como Wikipédia:Translatewiki, uma página de ajuda para os próximos editores se informarem deste processo de tradução, saberem sua importância e principalmente como contribuir. Cainã Marques07h49min de 13 de julho de 2013 (UTC)[responder]
É verdade que as versões do Translatewiki só aparecem se não houver uma página local, mas isso não se sobrepõe ao idioma definido nas preferências. A versão sem barra depois do nome serve só para a língua padrão da wíki (pt no nosso caso). Se o idioma das preferências é pt-BR, vai ser usada a página de translatewiki:MediaWiki:xxx/pt-br exceto se a versão local MediaWiki:xxx/pt-br existir. No exemplo que deu, como MediaWiki:Recentchangeslinked-summary/pt-br não existe, é usada a versão do TW. Para que MediaWiki:Recentchangeslinked-summary também seja mostrada a quem usa o pt-BR, seria preciso criar a versão brasileira com o mesmo texto (ou melhor, transcluir com {{MediaWiki:Recentchangeslinked-summary}}).
As mensagens não criadas mas definidas são aquelas que não têm versão local e portanto usam a do Translatewiki. (Não se esqueça de escolher pt-br no seletor de línguas.)
Imagino que sim, mas nunca me aventurei nelas.
Também não sei responder, já fiquei na dúvida sobre isso.
Ainda não entendi direito o que vai mudar (e o que já mudou), mas há pelo menos três bugs e uma série de alterações recentes no código do MediaWiki que podem influenciar a forma como o programa lida com as "fallback chains". Caso alguém queira investigar:
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Translations are available.
Recent software changes(Not all changes will affect you.)
The latest version of MediaWiki (1.22/wmf10) was added to test wikis on July 11. It will be enabled on non–Wikipedia sites on July 15, and on all Wikipedias on July 18. [20]
The Disambiguator extension was enabled on all Wikimedia wikis on July 9 (bug #50174). To use it, add the __DISAMBIG__ code to disambiguation templates (see example). [21]
A new version of the Single User Login system for global accounts will be enabled on July 17. Users will now automatically go back to the previous page instead of seeing the "Login success" page with logos. [23]
The software that resizes images on all wikis will change on July 18. Resizing of big images will be faster and more reliable, and the resolution limit for GIF, PNG and TIFF files (currently set at 50 megapixels) will be removed. [24]
Edit tags (mostly used by AbuseFilter) will now also be on diff pages. They include a link to Special:Tags before the edit summary. Wikis that use links in tag messages should remove them. [25][26]
Global edit filters are currently in testing and will be added to wikis later. [27]
Fiz recentemente uma alteração à predefinição {{Mapa de localização/Alemanha}} para poder ver um mapa de localização de um acidente geográfico na sua página, que era esta: Cabo Arkona. Trata-se de um cabo na Alemanha, e sabendo as suas coordenadas gostava de ter um mapa com a localização do dito cabo num mapa da Alemanha. De um modo similar criei a página Ras Ibn Hani sobre um cabo na Síria, e a sintaxe é a mesma (usam ambas a predefinição {{Info/Cabo}}. Na página do cabo sírio, tudo bem. Na do cabo alemão, nada está bem.
Reparei então que a predefinição {{Mapa de localização/Alemanha}} não era nada parecida com todas as outras predefinições de mapas de localização. A predefinição {{Mapa de localização/Alemanha}} tem algo complexo nela, pois quando a alterei para ficar uniforme com a maioria das outras predefinições de mapa de localização isso resultou em não mostrar mapa nenhum noutra predefinição muito usada: {{Info/Cidade da Alemanha}}, usada em centenas de artigos (todas as cidades alemãs têm o seu mapa de localização).
Seria possível algum programador paciente descobrir como manter a predefinição {{Info/Cidade da Alemanha}} a mostrar o mapa da Alemanha com um ponto na cidade em causa, e em simultâneo poder usá-la em outras predefinições como {{Info/Cabo}}, {{Info/Montanha}}. A título de exemplo, estão aqui ao lado duas invocações da predefinição {{Info/Montanha}} que mostram a caixa de texto do artigo Wetterspitzen, uma montanha da Alemanha e da Áustria: se puser Alemanha na predefinição, nada se vê..., mas se puser Áustria já funciona bem...
Suponho que a solução passe por mudar algo na predefinição {{Info/Cidade da Alemanha}} depois de colocar a {{Mapa de localização/Alemanha}} igual a todas as dos restantes países, pois é a única (creio) que há de funcionar com uma chamada diferente.
Sugiro que o código de {{Info/Cidade da Alemanha}} seja mudado, de preferência para passar a usar {{Info/Assentamento}} e um mapa padrão. Ou alternativamente, e temporariamente, se pegue no código atual de Mapa de localização/Alemanha e se coloque, por exemplo, em {{Info/Cidade da Alemanha/Mapa}}, para ser usado por Mapa de localização/Alemanha sem mais alterações de código.
Eu refiz as modificações do Zdtrlik na {Mapa_de_localização/Alemanha} e modifiquei a {Info/Cidade_da_Alemanha}. Deu certo de primeira, mas estou achando os "alfinetes" muito ao sul, apesar das coordenadas estarem corretas, deem uma olhada em Bad Tölz por exemplo. Falta saber também o que o Stegop bem colocou, se há "ocorrências em que é usada diretamente em artigos ou anexos". Como acabei de fazer as modificações na {Info/Cidade da Alemanha}, a página de afluentes não está atualizada. Cainã Marques06h04min de 17 de julho de 2013 (UTC)[responder]
Bobagem esta ultima frase minha. A predefinição é usada diretamente pela infocaixa, os afluentes não vão a lugar algum. Acho que é uma boa inserir na infocaixa uma página intermediária entre o {Mapa de localização/Alemanha} para identificar estes artigos. Cainã Marques12h59min de 17 de julho de 2013 (UTC)[responder]
Já notei esse tipo de desvio noutros mapas. O certo é que se usar uma largura maior, por exemplo 400px, o ponto já parece ficar no local correto. Será que os mapas não são 100% lineares? --Stegop (discussão) 16h14min de 17 de julho de 2013 (UTC)[responder]
Olá, ao inserirmos interwikis nos artigos através da opção Adicionar links que está no lado esquerdo da página, esta ação não aparece no histórico de edições. É um erro ou não tem que constar como edição mesmo? Rodrigolopes (discussão) 02h54min de 17 de julho de 2013 (UTC)[responder]
Parece que existe algum interesse de parte da comunidade em melhorar e esclarecer o funcionamento das eliminações. Pensei até em criar um projeto(um Wikipédia:Wikiprojeto) temporário para a comunidade definir o que quer, deixar lá alguns links de páginas úteis relacionadas a esse tema e para centralizar todas as discussões e ideias lá, pois fica tudo muito espalhado em páginas de discussão de usuários, Esplanadas, etc(e isso em PDUs dá a impressão que estamos tramando alguma coisa). O "produto final" desse projeto seriam Propostas bem trabalhadas, fundamentadas e explicadas que visassem solucionar os problemas que surgem desse assunto(provavelmente o foco principal seria a mudança das regras). Poderia ser 'Projeto/Eliminação' ou algum termo parecido. E como falei, seria temporário, apenas para a comunidade entrar em um acordo(se 80% da comunidade concordar sobre algo já está ótimo) em relação a alguns pontos que hoje causam tremendo stress, isso precisa ser resolvido, não é agradável editar em um ambiente que todo mundo fica se xingando e se bloqueando. Vulcan (discussão) 01h34min de 18 de julho de 2013 (UTC)
”
Devido aos recentes eventos e a divisão da comunidade sobre o tema "eliminação", vejo que existe uma necessidade de criarmos esse projeto temporário, o Wikipédia:Projetos/Eliminação de páginas, para a comunidade organizar melhor as ideias, centralizar as discussões e ideias de melhorias lá, hoje fica tudo espalhado, não dá para acompanhar muito bem o que acontece. E como disse acima, o produto final seriam propostas que visariam solucionar essa série de problemas que hoje temos. Como nome deixo a sugestão de Wikipédia:Projetos/Eliminação de páginas pois é sobre isso que iremos discutir lá.
Sobre a estrutura, não precisa ser complicado ou ter "participantes"(participa quem quer a qualquer hora), só precisa de uma página de frente do projeto com todos os links relacionados ao assunto para facilitar a consulta nas discussões, com o objetivo claro no topo "Melhorar o processo de eliminação através da elaboração de propostas"(ou algo parecido), explicando que é temporário, e ter a página de discussão para discutirmos. Depois da elaboração das propostas e vendo que a maior parte(não disse todos, disse maior parte) da comunidade está satisfeita, desativamos o projeto. Vulcan (discussão) 20h26min de 18 de julho de 2013 (UTC)[responder]
Apareceu 1 pop-up com alguma coisa e depois outro popup falando isso pra avisar do erro aqui. No topo a direita da página ficou lendo e o script falou que estava criando (apareceu apenas o "primeiro balão" com o símbolo se mexendo), mas ele fica nisso infinitamente e não cria. Vulcan (discussão) 21h46min de 18 de julho de 2013 (UTC)[responder]
Agora funcionou, mas mesmo assim há vários dias/semanas tem que depois que cria o tópico ir até a Esplanada e : "Este é um tópico novo. Se foi você quem o começou, clique aqui para inserir a sua mensagem." clicar lá e salvar. Vulcan (discussão) 22h19min de 18 de julho de 2013 (UTC)[responder]
Mais recentes novidades de tecnologia da comunidade técnica da Wikimedia. Favor informar outros usuários sobre essas mudanças. Traduções estão disponíveis.
Mudanças recentes no software(Nem todas mudanças afetarão vocês.)
A versão mais recente do MediaWiki (1.22/wmf11) foi colocada nas wikis de teste e no Mediawiki.org em 18 de julho. Ela será ativada nas demais wikis, excetuando-se as Wikipédias, em 22 de julho, e em todas as Wikipédias em 25 de julho. [32]
Foi alterado o cronograma para a instalação do Editor Visual nas Wikipédias (exceto em inglês): o novo editor estará disponível para os usuários registrados nas Wikipédias em alemão (de), espanhol, (es), francês (fr), hebreu (he), italiano (it), neerlandês (nl), polonês (pl), russo (ru) e sueco (sv) em 24 de julho, e para todos os usuários dessas wikis em 29 de julho. [34]
Agora é mostrado um aviso quando uma edição feita com o Editor Visual é detectada por um filtro de edição (bug #50472).
Interessante essa extensão, poderíamos criar alguma regra para promover a um estatuto automaticamente. O menos problemático seria por exemplo o de Autorrevisor, a partir de X mil edições e Y tempo poderia ser promovido. Pegar por exemplo para ter estatuto de sysop precisa de 2 mil edições e 6 meses, poderia usar esses parâmetros(ou outros menos ou mais exigentes), isso ajuda inclusive a desafogar as páginas a patrulhar. Vulcan (discussão) 17h05min de 23 de julho de 2013 (UTC)[responder]
Poderíamos fazer uma proposta em breve sobre isso então, dos "autopatrolled", e deixar algumas sugestões de valores para a comunidade decidir. Pelo que vi aí a francófona deixa 90 dias 500 edições, eu acho pouco, poderiam virar autorrevisores automaticamente depois de 6 meses e 1000 edições(=exigência mínima para Eliminadores), é um pouco mais razoável(ou quem sabe 2000), mas claro que é melhor discutir tudo isso em uma proposta na Esplanada algum dia. Vulcan (discussão) 17h44min de 23 de julho de 2013 (UTC)[responder]
Em Preferências → Edição há a opção em pt "Marcar todas as edições como secundárias, por padrão".
Não seria melhor deixar como a pt-br que é "Marcar todas edições como menores por padrão" ?
Secundária a quê? Menor em relação a qual edição? As duas traduções são incorretas, sendo que "menor" é menos errada. Os dois adjetivos transformam o substantivo de uma forma que precisam de outro substantivo para comparação. Entretanto, uma edição não precisa ser comparada a nenhuma outra para poder ser classificada assim. Um termo que poderia ser usado é "pequena", em vez de "menor", pois ele não é comparativo. Se quem edita a translate wiki não concordar, não importa. Não somos obrigados a aceita as decisões de lá.—Teles«fale comigo» 01h38min de 25 de julho de 2013 (UTC)[responder]
Aproveitando o assunto seria importante na página de edição ter na frase "Marcar como edição menor" uma ligação para a página que ensina o que é, a Ajuda:Guia de edição/Menus e ferramentas/Edição menor, pois atualmente ela tem média de 5 visitas/dia, é muito pouco. Mais gente precisa saber o que é isso. Podia deixar:
Ou seja, a documentação da Wikipédia não poderia ser usada por outros projetos lusófonos se decidirem mudar a terminologia só aqui, em vez de manter a consistência entre os sites que utilizam o MediaWiki. Helder20h45min de 25 de julho de 2013 (UTC)[responder]
Nada impede que na translatewiki usem o que decidirmos aqui. Assim como nada nos obriga a seguir o que eles decidirem especialmente se discordarmos disso. Ou há algo que nos obrigue?—Teles«fale comigo» 21h23min de 25 de julho de 2013 (UTC)[responder]
São vários e ainda não terminei de mapeá-los. Basicamente estou vendo quais são os campos em comum para todas, quais serão necessários renomear (e.g. o campo "renda" na "Bairro do Brasil 3" precisa ser renomeado para "rendimento médio mensal" conforme está na "Bairro do Brasil" e quais parâmetros vou incluir na "Bairro do Brasil" para manter as outras funcionais e daí recorre ao trabalho extra de melhorar a Info/Assentamento. Tem um robô para ajudar? :) OTAVIO1981 (discussão) 20h59min de 24 de julho de 2013 (UTC)[responder]
Olha Otávio, eu fundi várias e várias infocaixas nos últimos meses, acabei desenvolvendo algumas técnicas. Em casos de incompatibilidades nos campos (mesmo campo tendo funções diferentes), campos que precisam ser renomeados e/ou mais de uma predefinição a ser fundida, o melhor a fazer é eleger uma infocaixa para ter todos os recursos e parâmetros e depois colocar as outras em função da primeira e depois substituir. Veja [39] e [40]. Dê uma olhada em Wikipédia:Coordenação robótica#Fusão de predefs onde eu discuto com o Danilo as vantagens deste sistema. Certamente neste caso é o melhor a fazer. Cainã Marques21h42min de 24 de julho de 2013 (UTC)[responder]
Fiz a primeira fusão de {{Info/Bairro do Brasil 2}} com {{Info/Bairro do Brasil}} e agradeço imensamente se puderem verificar se não ficou nada muito errado. Infelizmente a falta de padronização no uso da própria predefinição dificulta imensamente a fusão. Por exemplo, o campo "água encanada" em que é suposto utilizar percentual, alguns preenchimentos são com a palavra "sim". Campos como "população" às vezes tem a unidade de medida e outras vezes não, o que também dificulta um resultado final homogêneo. O mais importante é que nenhum campo foi excluído na fusão e particularmente fiquei satisfeito de conseguir calcular o índice de alfabetização a partir do índice de analfabetização de modo a uniformizar a informação. Não havendo comentários ou ações a serem desfeitas, efetuarei a fusão das próximas em breve.OTAVIO1981 (discussão) 18h54min de 31 de julho de 2013 (UTC)[responder]
Feito a fusão de {{Info/Bairro do Brasil 3}} que era o meu principal objetivo para remover a hiddenstructure e substituir pela meta predefinição Info/Assentamento basea da Bairro do Brasil. Ainda devo fazer as outras mas vou aguardar mais tempo entre para que reportem eventuais erros.OTAVIO1981 (discussão) 20h17min de 1 de agosto de 2013 (UTC)[responder]
Não percebi nenhum problema, os dias correspondentes de cada mês até aparecem alinhados na vertical (e o estilo usado é o mesmo em todas as listas formatadas horizontalmente). Helder13h19min de 26 de julho de 2013 (UTC)[responder]
Latest tech news from the Wikimedia technical community. Please inform other users about these changes; not all changes will affect you. Translations are available.
The latest version of MediaWiki (1.22/wmf12) was added to test wikis and MediaWiki.org on July 25. It will be enabled on non–Wikipedia sites on July 29, and on all Wikipedias on August 1. [41]
Wikivoyage was offline for around 40 minutes on July 24. [42]
The Notifications and Thanks extensions were added to Meta-Wiki on July 26; other wikis will get them soon. [44]
It is now possible to add edit summaries on Wikidata using the API; the feature will be added to user interface soon. [45]
The software that resizes large PNG images on all wikis was changed on July 25. Resizing of PNG files bigger than 35 megapixels should be faster and more reliable now. [46]
Three new webfonts (Gentium, Old Persian and Shapour) will be added to Universal Language Selector. [47], [48], [49]
Special:MIMESearch, which gives a list of files by type, will be enabled on all Wikimedia wikis with MediaWiki version 1.22/wmf12 (bug #13438). [50]
A mailing list to discuss multimedia features was started; users are encouraged to sign up.
On July 24, VisualEditor was added for logged-in users on the German (de), Spanish (es), French (fr), Hebrew (he), Italian (it), Polish (pl), Russian (ru) and Swedish (sv) Wikipedias; it will be added for all users on those wikis on July 29. [51]
A preference to completely disable VisualEditor while it is in beta phase was added on July 24. [52]
Quase toda vez que vou bloquear algum IP, preciso marcar a opção de bloquear também uma conta que for usá-lo. Como na maioria das vezes esse bloqueio é necessário, gostaria de saber se é possível fazer alguma alteração pra que isso apareça marcado como padrão (caixa "Impedir que usuários autenticados editem a partir deste endereço IP"). É possível?
Já aproveitando e talvez eu esteja pedindo demais, mas não custa falar. A maioria dos bloqueios que faço é por vandalismo e por um prazo de seis horas. Isso é bem repetitivo. Assim como existe um botão pra mandar mensagem de aviso de bloqueio com reversão e avisos (acho), será que não existe um botão pra bloquear com esses parâmetros e mandar a mensagem de bloqueio?—Teles«fale comigo» 03h45min de 29 de julho de 2013 (UTC)[responder]
Bom, eu não sei como se faz isso, se soubesse faria pessoalmente. Nesta página logo no inicio há um erro #coordinates: invalid latitude, creio que isso é graças a predefinição de latitude e longitude. Peço que qualquer usuário sábio e bondoso com tempo e conhecimento disponível o corrija. Obrigado. --Zoldyick (discussão) 20h58min de 29 de julho de 2013 (UTC)[responder]
Iniciei com o pouco que sei sobre o Bugzilla a página de documentação Ajuda:Bugzilla, convido todos que tiverem conhecimentos sobre o assunto a melhorarem a página. Isso é para evitar confusões futuras e poder acompanhar discussões da melhor forma; quando alguém perguntar o que é isso é só enviar o link da página. Não há pressa em ser feito, vamos melhorando a página com o tempo, infelizmente eu sei muito pouco sobre o assunto, apenas me limitei a começar a página.
O conteúdo da Wikipédia:MediaWiki é essencialmente um arquivo do histórico do projeto, mas não acho que valha a pena ficar mantendo-a atualizada. Não seria o caso de melhorar o artigo sobre o MediaWiki (compare com en:MediaWiki)?
Acredito que seria preferível analisar a documentação existente no mediawiki.org, para identificar aquilo que é relevante para a Wikipédia, e simplesmente traduzir (lá mesmo) para o português, em vez de criar páginas locais que ficarão desatualizadas mais facilmente. Helder15h57min de 1 de agosto de 2013 (UTC)[responder]
Gente, em breve vou dispor no meu website um gerador de referências (para predefs citar livro, citar website, citar bíblia etc) é coisa bem simples mesmo, mas quem sabe um dia posso hospedá-lo no Toolserver sei lá? Acho que criar o gerador pode ajudar e muito a questão das referências, é difícil cobrar das pessoas algo que elas não sabem. Por enquanto é isso!
▪ Dioii!03h24min de 2 de agosto de 2013 (UTC)[responder]
Interessante essas ferramentas, não sei se tem muito a ver com o que estou fazendo rsrs, no caso são forms onde se preenche os dados de uma referência e se gera o código usando a predefinição adequada, não tem nada automatico nesse gerador, mas uma hora tento fazer um capaz de obter os dados de sites que podem servir de fontes, ai vai ser um outro projeto :) ▪ Dioii!04h57min de 2 de agosto de 2013 (UTC)[responder]
Acabei de criar a {{re}} para ser utilizada no Café dos novatos quando uma pergunta é respondida/resolvida, e resolvi sugerir que também fosse utilizada aqui ou outros lugares que acharem útil.
Tem também a {{resp}}/{{respondido}} mas eu não acho ela tão prática de usar pois tem que fazer isso:
{{resp|texto=
texto aqui
}}
(e ocorrem problemas quando alguém utiliza uma barra vertical, aí tem que ir lá e alterar o texto)
Acho muito formal e menos prática para usar no dia-a-dia, por isso criei a {{re}}, que é prefixo de respondido e resolvido e fica fácil de lembrar e usar. Na Esplanada/geral não é útil, na Esplanada/propostas não sei... mas acho que aqui no Café dos programadores daria para usar. TheVulcan (discussão) 18h33min de 5 de agosto de 2013 (UTC)[responder]
Alguém saberia criar um módulo em Lua que simplificasse as frequentes atualizações das Predefinição:MR***?
O que eu gostaria é de algo que não exigisse a contagem e atualização manual do número de itens em cada seção, e seria ainda melhor se fosse possível simplificar a sintaxe, como neste exemplo (o código em lua é que se encarregaria de formatar isso adequadamente). Helder19h59min de 5 de agosto de 2013 (UTC)[responder]
Se for possível remover automaticamente da Concluídos depois de XX dias melhor ainda. Se não for possível fazer isso via Lua, bot ou outro jeito, teria que continuar manualmente, mas adicionar um "<!-- Adicione a data de conclusão e remova dessa seção depois de passados XX dias -->". Senão os tópicos ficam mofando por meses lá, recentemente eu removi uns concluídos de 2012, um era de fev/2012 da {{MRDebates}}. TheVulcan (discussão) 20h43min de 5 de agosto de 2013 (UTC)[responder]
Melhor ainda se puder pegar automaticamente a lista de votações pela cat (tem cat para novo e concluído), e os pedidos de opinião pela WP:Pedidos de opinião/pedidos. Até as propostas poderiam ser atualizadas ali na lista dos pedidos de opinião, afinal, um pedido de opinião sobre uma política (e similares) quase sempre é uma proposta, e propostas quase sempre tem um pedido de opinião sobre mudança de política, dá no mesmo. Pedido de opinião seriam os pedidos sobre conteúdo, e propostas seriam os pedidos sobre documentação interna. E atualizariamos apenas a WP:Pedidos de opinião/pedidos. Rjclaudiomsg21h31min de 5 de agosto de 2013 (UTC)[responder]
Acho que esse não é o caminho para desenvolver uma boa solução com lua, pois pode cair num limbo de funcionalidades novas e nunca ficar estável suficiente para substituir a predefinição em questão.
Acho que os passos devem ser:
1. Converter a predefinição de modo que ela faça "exatamente" o que ela já faz atualmente (simplificando apenas o modo de fazer ou o numero de subpáginas requeridas e a performasse)
2. Adicionar mais automação e novas funcionalidades.
A predefinição {{Sidebar with collapsible lists}} utiliza o parâmetro "expanded" para saber qual lista que deve expandir, então, se no código da sidebar este parâmetro estiver preechido com {{{cTopic}}}, significa que se eu colocar num artigo: {{Mecânica Clássica|cTopic=belesma}}, a lista "belesma" será expandida. Os anglófonos tem mania deste parâmetro "cTopic", mas é mais simples colocar {{{1}}} no parâmetro "expanded", assim é só pôr {{Mecânica Clássica|belesma}}. Cainamarques17h18min de 6 de agosto de 2013 (UTC)[responder]
Não sei se alguém mais notou, mas no mês passado foi desenvolvida e instalada a mw:Extension:TemplateData, para uso ao documentar as predefinições, de modo que scripts (como o Editor Visual) possam obter informações sobre os parâmetros a partir da API. Para testar, atualizei a documentação da {{Correlatos}}, e o resultado já está visível na API:
(compare com uma outra predefinição qualquer, para a qual ainda não tenham sido inseridas informações na tag <templatedata>).
Se tentarem, por exemplo, editar o artigo sobre Lorentz com o Editor Visual, poderão rolar a página até a parte inferior e clicar na predefinição que fornece o link para o Commons. Depois de clicar na peça de quebra-cabeça, aparecerá uma janela com as informações sobre a predefinição, e sobre o parâmetro. Experimentem também digitar "wikisource" no campo para adicionar um novo parâmetro: o rótulo e a descrição do campo aparecerá automaticamente.
Não deveria ser assim. Aquele monstro de código no meio da documentação predefinição a espantar ainda mais os novatos e confundir os editores. Deveria ser incluído como metadado em outro lugar. Helder, o que acha de passar a transcluir a partir duma supágina {correlatos/data} ou criar uma predefinição que faça o mesmo? Cainã Marques05h09min de 25 de junho de 2013 (UTC)[responder]
Se refere ao código em JSON que vai dentro da tag <templatedata>? Acho que não teríamos qualquer problema (técnico) ao movê-lo para uma subpágina "/dados" (se está funcionando a partir de /doc, também deve funcionar a partir de "/dados"). Mas antes de decidir exatamente como lidar com essas informações, acho bom ler alguns outros tópicos sobre a novidade:
Ah, e respondendo ao que perguntou na minha página de discussão: sim, sempre que for incluído ou depreciado um parâmetro de uma certa predefinição, os dados correspondentes precisam ser atualizados, para os detalhes também fiquem visíveis para quem usar o Editor Visual. Helder11h50min de 30 de junho de 2013 (UTC)[responder]
Neste caso precisamos duma:
Por favor não altere esta predefinição sem também atualizar a documentação em JSON inserida na subpágina {{PAGENAME}}/dados.
Acho que quem for capaz de editar o código não terá problemas com isso. Continuo achando que um aviso na documentação é uma boa, discrepâncias com a documentação em JSON não será divertido, mas se isso for exagero talvez uma lista com as predefinições em questão poderia ser utilizada pelas Alterações relacionadas para monitorar suas modificações. Cainã Marques19h32min de 1 de julho de 2013 (UTC)[responder]
Preciso fazer um upgrade no script que envia as notificações de pedido de bloqueio, e para evitar notificações repetidas, estava a pensar associar cada pedido a um hash. Alguém se voluntaria para desenvolver um pequeno script, ou adicionar a um já existente com ferramentas para sysops, que simule o já feito em Usuária:Aleth Bot/Revisão de bloqueio, mas que adione um novo campo para colocar em Usuária:Aleth Bot/Revisão de bloqueio/Lista algo como {{Usuária:Aleth Bot/rblock|hash=0001|1=Teste|Status=Feito}}? Ou seja, em Usuária:Aleth Bot/Revisão de bloqueio/Hash ficaria o nº do último pedido, portanto para adicionar um novo pedido, o script leria o nº dessa página, acrescentaria 1, que seria usado para essa predefinição, e ao salvar em /revisão do bloqueio, actualizaria igualmente a página do hash. AlchimistaFala comigo!13h08min de 16 de agosto de 2013 (UTC)[responder]
Feito. A predefinição {{coor title dm}} estava mal formatada mas não foi necessário corrigi-la, pois a {{Info/Cidade da Polônia}} utiliza o parâmetro opcional coord_título para exibir as coordenadas em cima da página, além de debaixo do mapa, que é o padrão. Como as coordenadas já estavam preenchidas na infocaixa foi apenas adicionar este parâmetro e remover a predefinição coor title dm. Cainamarques04h59min de 20 de agosto de 2013 (UTC)[responder]
Olá. Acabei de aplicar uma alteração na predefinição acima, mas um recurso novo não está funcionando e eu não consigo perceber porquê. Junto com outras alterações, eu tinha trazido a capacidade dessa etiqueta incluir os atalhos das políticas dentro de si, através da Predefinição:Ombox/Shortcut, que me parece idêntica na Wikipédia anglófona e lusófona. Essa predefinição é usada dentro da etiqueta no campo "imageright", que também é suportado aqui. Alguém poderia corrigir o que está errado?--Mister Sanderson (discussão) 00h59min de 22 de agosto de 2013 (UTC)[responder]
O primeiro parâmetro foi sempre utilizado para o local onde foi a política foi decidida, a modificação não levou isto em conta, e corrigi da minha forma, sinta-se livre para alterar a sua posição no texto da forma que desejar. Não sei se foi intencional mas se quer alterar isto eu realmente discordo. O problema que descreveu não está corrigido, vou dar uma olhada aqui. Cainamarques01h37min de 22 de agosto de 2013 (UTC)[responder]
Ter sido sempre utilizado para tal afeta em quê a proposta? Não se pode mudar qual campo será usado? Citação: MisterSanderson escreveu: «Minha ideia era mudar a posição de onde consta a informação sobre o local de aprovação da política. Ele sairia do parâmetro '1' e iria para o parâmetro 'texto'. Isso é mais adequado para não atrapalhar a padronização "1 a 5 para atalhos", e para não deixar as frases muito longas.»--Mister Sanderson (discussão) 01h42min de 22 de agosto de 2013 (UTC)[responder]
Afeta não a proposta em si, mas sua implementação. O código inserido foi copiado exatamente da anglófona, na qual o 1º parâmetro é utilizado para o atalho. Todos os afluentes daqui utilizam o primeiro parâmetro para o local de discussão, se quer mudar isto, tem que alterar afluente por afluente, mas seria bobeira, é só utilizar o segundo em diante. Quanto ao problema, o parâmetro imagem_direita da Ombox simplesmente não funciona. Cainamarques02h10min de 22 de agosto de 2013 (UTC)[responder]
Finalmente consegui encontrar, o problema é na ombox/core deve-se retirar a classe no trecho <td class="mbox-imageright"> {{{imagem_direita}}} </td>. Faz lá o pedido na PP, vou dormir, abs. Cainamarques02h22min de 22 de agosto de 2013 (UTC)[responder]
Mas eu vou ter de passar em todos os afluentes de qualquer forma para inserir os atalhos dentro dessa etiqueta. Atualmente eles ficam fora. Logo, não há problema em mudar o nome do campo, pois eu vou passar corrigindo de qualquer forma.--Mister Sanderson (discussão) 02h23min de 22 de agosto de 2013 (UTC)[responder]
Primeiro, a pergunta: posso mover essa discussão para a página da proposta? O Café dos Programadores não é o lugar para discutir isso. Agora, a resposta.
Motivo 1: com o tempo essa informação "aonde foi aprovada" vai sair das etiquetas, conforme for passando para notas de rodapé dentro dos textos das políticas. Através do processo wiki, depois de algumas propostas de modificação, a política fica totalmente diferente do que tinha sido aprovado, e por isso não faz sentido dizer nessa etiqueta que o texto atual foi aprovado no lugar X, quando a versão atual deriva-se de X, Y, Z, W, K, etc. As notas de rodapé cumprem melhor esse papel, informando de qual decisão veio cada frase. Por isso, a informação "aonde foi aprovado" deveria ficar no campo "texto" e não no 1, pois a ideia é que seja um dado excepcional temporária.
Motivo 2: colocar isso no campo "1" vai ferrar com os atalhos. Enquanto toda política tem pelo menos um atalho (que preencheria o campo "1"), nem toda política informa seu lugar de aprovação. Se uma não informar o lugar e os editores quiserem colocar os atalhos, vão ter que escrever "2=", "3=", sendo que, se o local de aprovação estivesse no campo "texto", não seria preciso escrever os números. (Por padrão a predefinição pega o primeiro parâmetro e deduz que ele se destina ao campo "1", ainda que não exista "1="). Como a ideia é que os locais de aprovação saiam da etiqueta e passem para notas de rodapé, não se justifica a formatação suja de escrever "2=, 3=", pois ela passará a existir devido a uma informação que nem constará mais.
Motivo 3: colocar o local de aprovação dentro da frase da etiqueta vai deixá-la longa demais, quebrando o raciocínio de quem lê. Colocar depois da frase não atrapalha em nada a detecção do local de aprovação, e não vai gerar esse problema que falei.
O erro não é esse que você apontou, a en:Template:Ombox/core também inclui esse código. Mas você ter apontado esse trecho do código permitiu-me identificar uma diferença entre as duas ali: a nossa usa um switch, e a deles usa um ifeq. Porém, nosso switch está configurado errado:
Isso funciona da seguinte forma: se o campo "imagem_direita" é preenchido, ele ativa o switch, se não, ele não faz nada. Ativando o switch, ele verifica qual é o valor do campo. Se for "none", ele deixa em branco. Agora, se estiver preenchido com alguma outra coisa, ele escreve "nenhuma" ou coloca a imagem na direita? Só deve existir um caso default, mas nesse switch existem dois! Por isso que ele não funciona...
Se o campo "imageright" é preenchido, ele ativa o ifeq, se não, ele não faz nada. Ativando o ifeq, ele verifica se o valor de "imageright" é "none". Se for, deixa sem imagem, se não for, coloca a imagem. Viu, esse funciona direitinho.
Fiz testes e descobri a mudança necessária. Temos que mudar nosso switch atual para o seguinte:
{{#if:{{{imagem_direita|}}}
| {{#switch:{{{imagem_direita|}}}
|nenhuma= <!-- No image. -->
|none= <!-- No image. -->
|#default= <td class="mbox-imageright"> {{{imagem_direita}}} </td>
}}
}}
Não MS, não existem dois defaults, o parâmetro switch aceita a sintaxe:
{{#switch: cadeia | caso1 | caso2 = ação para caso 1 e 2 | ação padrão }}
A nossa sintaxe está correta, tanto "nenhuma" quanto "none" retornam nada. Removi a classe daquela linha e agora está funcionando correto. Eu sinceramente não sei porque isto ocorre, mas tentar estilizar aquela cédula com class ou style simplesmente torna-a nula, não aparece. Cainamarques04h05min de 23 de agosto de 2013 (UTC)[responder]
Entendi o porquê, a célula sumia porque os parâmetros não podem conter o caractere sinal de igual [ = ]. Para evitar o problema deve-se declarar explicitamente com #default= ou utilizar uma das outras medidas descritas em mw:Help:Extension:ParserFunctions#Raw equal signs Ufa Quanto a questão principal, me convenceu com sua argumentação, mas lembre-se que nas versões antigas das páginas que contém a predefinição não ficará nada bonito. Cainamarques12h43min de 23 de agosto de 2013 (UTC)[responder]
Atualmente, a cada novo portal inserido na Predefinição:Portal3/Portais, é preciso inserir uma linha na página de documentação (vejam o histórico da documentação). Não seria melhor se lista de portais da documentação fosse gerada automaticamente por um módulo escrito em Lua? Ele poderia fazer um loop pelas linhas do código da predefinição procurando por trechos como
|urss
|união soviética = {{Portal3/Suporte|atribuição=não|Flag of the Soviet Union.svg|URSS|Portal da União Soviética}}
Sim, e seria melhor ainda se existisse um módulo genérico em que fosse dado a página e o lua pattern (é como regex só que com algumas limitações) e que gerasse uma lista a partir das correspondências dessa busca, assim o mesmo módulo poderia ser usado também em outros tipos de listagens. Vou tentar fazer isso. Danilo.mac(discussão)05h15min de 23 de agosto de 2013 (UTC)[responder]
Criei o Módulo:Busca. Porém não consegui fazer ele expandir as predefinições {{Portal3/Portais}} dessa lista. as predefinições dentro do resultado de um módulo não são expandidas automaticamente, pois os módulos são processados depois das predefinições. Cheguei a fazer uma função para detectar e expandir as predefinições, para poucas predefinições até funcionou, mas para todas predefinições dessa lista ele retorna o erro "o tempo limite alocado para execução deste script foi atingido", então removi essa função do código pois parece que deixa o módulo muito pesado. Depois tentei listar usando o código já expandido da predefinição, mas começou a ficar tão complicado que desisti, as limitações dos Lua patterns e dos módulos, as quais expliquei na documentação desse módulo, fazem isso se tornar muito difícil. Mas enfim, não consegui para essa lista, mas o módulo pode ser usado para várias tarefas diferentes, além da criação de listas a partir de buscas em páginas coloquei também uma função para contagem. Danilo.mac(discussão)01h39min de 25 de agosto de 2013 (UTC)[responder]
Estou rodando o MW 1.21 (baixado no site MediaWiki.org, não é o módulo baixado no BitNami) em um servidor local Apache (pacote Xampp) e estou com um problema para criar uma predef: {{CURRENTTIME}} funciona normalmente, mas {{CURRENTTIME/UTC-3}} não funciona. Em vez de calcular a hora, a predef fica mostrando o código. Como resolvo isso? Agradeço a quem puder me ajudar. - Fabsouza1 (discussão) 13h57min de 23 de agosto de 2013 (UTC)[responder]
Tomei conhecimento do site http://wikiapiary.com/ que mostra uma série de estatísticas de outras wikis que utilizam MediaWiki, utiliza Semantic MediaWiki portanto a possibilidade de filtrar e interagir com os dados é grande.
Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.
New features
The previous version of MediaWiki (1.22/wmf13) was added to test wikis and MediaWiki.org on August 15. It was enabled on non-Wikipedia sites on August 19, and on all Wikipedias on August 22. [61]
The latest version of MediaWiki (1.22/wmf14) was added to test wikis and MediaWiki.org on August 22. It will be enabled on non-Wikipedia sites on August 26, and on all Wikipedias on August 29. [62]
You can now use the <wbr> HTML5 tag to say where a word can be cut. (52468) [65]
Gadget authors: you can now use the wikipage.content hook, so that your scripts are re-run when a page is changed after the document-ready event (for example using Ajax). (30713) [66]
Problems fixed
There was a bug where file redirects didn't work when a file was renamed; it is now fixed. There is still an issue with purging, but it should be fixed soon. (52200)
Relatórios de manutenção provided by special pages will now all be updated on each wiki every six months. This will for example give you recent information on uncategorized pages, unused templates and most wanted pages (see details).
There was a bug that caused false positives for anti-blanking edit filters; it is now fixed. (52077) [67]
The "edit" and "edit source" tabs and section edit links can now be changed more easily; for example, some wikis are using "edit source" for wikitext editing, and "edit beta" for VisualEditor. You can ask for the same change in bugzilla.
You can now edit references that are added inside a <references> block. (51741)
You can now test on mediawiki.org new basic tools to add and edit struck text (with the button for the <s> tag), lower text ( for <sub>), upper text ( for <sup>), underlined text ( for <u>), computer code ( for <code> and <tt>), math text ( for <math>), Egyptian hieroglyphs ( for <hiero>), and to say that text is in another language ( for lang="ar" dir="rtl"). (51609, 51612, 51611, 51590, 51610, 52352)
You can now use VisualEditor with the Opera browser. [68]
Future
Starting on August 26, you will be able to use data from Wikidata on Wikivoyage sites. [69]
Starting on August 27, you will also get notifications on the mobile site if you're logged in to a wiki using notifications. [70]
Starting on August 28, all users with an account will be using HTTPS to access Wikimedia sites. HTTPS brings better security and improves your privacy. Some countries (like China) will not use HTTPS. If HTTPS causes problems for you, tell us on meta. [71]
Starting on August 29, you will get the code editor interface to edit JavaScript and CSS pages on all wikis. [72]
The plan to use Solr for search in MediaWiki was changed; instead, Elasticsearch is now planned. [73]
Você está certo, Helder, na verdade eu é que havia subestimado a estrutura da predefinição utilizada e pensei que conteúdos haviam sido perdidos durante as movimentações. De qualquer modo, obrigado pela resposta! Sturm (discussão) 18h00min de 28 de agosto de 2013 (UTC)[responder]
Link "Developers" no rodapé de todos os sites wikimedia.
Agora há pouco, fui informado que foi ativado um link apontando para mw:Como contribuir no rodapé de todas as páginas dos projetos. Há também uma pequena chance de no futuro os gadgets (bug 20153), scribunto modules, e templates (bug 4547) sejam movidos para o mediawiki também. Acho que essa é nossa chance de nos apropriarmos do mediawiki.org. Acho que o primeiro passo é concentrarmos-nos na tradução, e depois criar canais de comunicação lusófonos lá dentro. Nesse quesito o mw:echo pode ajudar. Não sei se ele já funciona para notificações interwikis. Mas suspeito que em algum momento será possível receber na wikipédia, as notificações do mediawiki. Então podemos vigiar o portal. - Raylton P. Sousa (discussão) 17h04min de 27 de agosto de 2013 (UTC)[responder]
A página de gadgets em Especial:Preferências conta com alguns gadgets ativos por padrão; atualmente eles estão misturados com os outros gadgets e para identificá-los utiliza-se um (padrão). O que acham da ideia de adicionar uma subseção intitulada "Padrão"(ou 'Ativados por padrão') em cada seção(Aparência, Edição, Navegação) e deixar separado os opcionais deixando os opcionais no topo da seção e os ativos por padrão na parte de baixo de cada seção? Dessa forma ficaria muito mais fácil de visualizar o que é opcional.
Vou fazer um exemplo com a seção "Aparência" para facilitar a visualização, ficaria algo assim:
== Aparência ==
Adiciona uma aba na parte superior que, quando pressionada, oculta as referências do artigo.
Compactar a lista de referências
Conversor de idiomas: inclui menus no topo das páginas para permitir a conversão do texto para a variante ou idioma local preferido pelo leitor [documentação | comentários]
Deixa a skin em cores em contraste (verde e preto).
Detector de desambiguações: colora automaticamente todas as ligações para desambiguações em um artigo [documentação | comentários]
Histórico com uma cor para cada usuário, de acordo com seu status (bot, IP, administrador e editor).
Mostra todos os históricos e páginas especiais em ordem numérica.
Nova seção: inclui um link para criar uma nova seção nas páginas de discussão [comentários]
Remoção de avisos: Permite esconder avisos centrais como os da arrecadação de fundos anual. [comentários]
Relógio UTC: um relógio na barra de ferramentas pessoais que mostra o tempo atual em UTC numa ligação para purgar a página [comentários]
Redirecionamentos: acrescenta uma aba que permite verificar se existem redirecionamentos numa página, apresentando as ligações para redirecionamentos a verde [documentação | comentários]
Traduz os interwíkis para o português.
Traduz páginas em vários idiomas com o mecanismo do Google.
=== Ativados por padrão ===
Correlatos: move para a barra lateral os links para os conteúdos correlatos nos projetos irmãos [comentários]
Destacar comentários: altera a cor dos comentários nas páginas de discussão conforme a sua indentação [comentários]
Elementos ocultáveis: habilita a criação e exibição de elementos ocultáveis pelos métodos antigos (NavFrames e tabelas com a classe collapsible) [comentários]
Metacaixas: permitir o uso de caixas com abas, feitas com a Predefinição:Metacaixa [comentários]
Reescrita de títulos: Permitir o uso de {{título errado}} e HTML para contornar a configuração normal da {{DISPLAYTITLE}}, e modificar significativametne os títulos das páginas (não apenas maiúsculas e minúsculas) [comentários]
Reference Tooltips: mostra o conteúdo das referências ao passar o mouse sobre as citações em linha, em vez de ter que ir para o final do artigo [documentação | comentários]
Página de testes: incluir um link "Testes" na área da barra de ferramentas pessoal [comentários]
Topicon: ao exibir um artigo protegido, informar sobre a existência dessa proteção [comentários]
Fica mais fácil para ver as opções de gadgets, dessa forma é só ignorar visualmente o que estiver na seção padrão e focar a atenção nos campos opcionais; a maioria das pessoas não costuma desativar as opções padrão. Aliás sobre o que o Cainã disse, agora ordenei a lista de exemplo acima em ordem alfabética, vejam como fica. TheVulcan (discussão) 18h50min de 28 de agosto de 2013 (UTC)[responder]
Criei este tópico para centralizar as informações sobre como alguns usuários ativos devem proceder para atualizar seus scripts, dadas algumas mudanças recentes (e outras um pouco mais antigas).
Há mais de seis meses, apagamos várias páginas que até 2011 continham scripts que hoje já estão disponíveis como gadgets. No entanto, há vários editores (ver lista mais adiante) cujos scripts pessoais ainda tentam utilizá-las (sem sucesso).
Recomendo que os editores mencionados abaixo removam essas versões antigas e ativar os gadgets correspondentes, que geralmente serão mantidos atualizados, para evitar também eventuais problemas (bugs) causados por alguns códigos obsoletos que estiver utilizando...
Abaixo há uma lista com os usuários ativos, dos grupos "sysop", "bureaucrat", "eliminator" e "rollbacker", cujos scripts common.js, vector.js ou monobook.js mencionam páginas apagadas:
PS: Imagino que a nova extensão de notificações deve ter se encarregado de avisar os editores que mencionei sobre a existência deste tópico, senão teríamos que informar cada um em suas páginas de discussão. Alternativamente, usuários com as permissões necessárias poderiam simplesmente remover das páginas dos usuários acima esses códigos que já não funcionam... Helder18h32min de 29 de agosto de 2013 (UTC)[responder]
Uma nota: o mesmo se aplica aos popups de navegação, como o da figura ao lado. Tinham parado de funcionar para mim, daí retirei o script do meu commons.js e habilitei o gadget. Agora funciona perfeitamente. --Brandizzi (discussão) 14h42min de 30 de agosto de 2013 (UTC)[responder]
Olá. Desde que voltei à Wikipédia, há algumas semanas, notei que o HotCat não estava funcionando. Agora, orientado pelo MwaldeckD C E F, fiz as alterações pedidas nas duas páginas, mas ele ainda não está funcionando. Alguém sabe se é preciso fazer mais alguma coisa? Filipe RibeiroMsg22h22min de 9 de setembro de 2013 (UTC)[responder]
A propósito, FilRB, se testou o HotCat enquanto o seu vector.js tinha {{ER|...}}, isso talvez tenha sido o motivo de não funcionar (pois o código causaria um erro de sintaxe, por não estar dentro de um /* comentário */). Ou testou tanto com o skin vector quanto com o monobook? Helder12h10min de 10 de setembro de 2013 (UTC)[responder]
Copiei esta predefinição direto da en.wiki sem alterar nada! Foi também necessário copiar a Predefinição:Harvard citations/core. A predefinição foi usada em Paul Bernays duas vezes. Na primeira vez aparece "Hilbert and Bernays", quando deveria ser "Hilbert e Bernays". Na segunda vez resulta "[[#CITEREF|]]", quando deveria ser "Müller 1976". Alguém sabe como arrumar isto? Obrigado, Kaktus Kid (discussão) 20h42min de 29 de agosto de 2013 (UTC)[responder]
Acho que essa forma de citação já tinha predefinição [ões] compatível [eis] por aqui, vide: Predefinição:Harv, Predefinição:Harvard citação sem parênteses, Predefinição:Harvard reference, Predefinição:Harvnb, Predefinição:HarvRef etc. Burmeister (discussão) 14h26min de 30 de agosto de 2013 (UTC)[responder]
Eu não costumo editar na anglófona, mas eu vi a mudança e fui conferir lá e lá está assim também. Acho que tem a ver com isso: mw:Micro Design Improvements.
Recentemente(umas 2 semanas atrás?) deixaram as predefinições do rodapé em menus ocultáveis(o que ficou excelente), poderiam continuar com essas mudanças, está ficando muito bom; poderíamos ter também:
Melhorar a parte da licença Creative Commons.
Modificar os botões (gravar/mostrar previsão/alterações) para aqueles botões azuis e cinzas.
No topo da janela de edição vá em Ajuda → Discussão e está aparecendo na coluna Resultado:
wikieditor-toolbar-help-content-signaturetimestamp-result: Parse error at position 19 in input: Nome de utilizador (discussão) 15h54min de 10 de junho de 2009 (UTC)
wikieditor-toolbar-help-content-signature-result: Parse error at position 19 in input: Nome de utilizador (discussão)
Concordo que seja por default/defeito. José Luiz disc 00h17min de 3 de julho de 2013 (UTC)
Contra. Não há nada de errado em um link apontar para um redirecionamento (muito menos a ponto de chamar a atenção dos leitores a esse mero detalhe que é a existência de mais de um título válido que leva a um mesmo tema). Helder 02h15min de 3 de julho de 2013 (UTC)
Paulo Eduardo - Disc 11h30min de 19 de julho de 2013 (UTC)
Feito a fusão de {{Info/Bairro do Brasil 3}} que era o meu principal objetivo para remover a hiddenstructure e substituir pela meta predefinição Info/Assentamento basea da Bairro do Brasil. Ainda devo fazer as outras mas vou aguardar mais tempo entre para que reportem eventuais erros.OTAVIO1981 (discussão) 20h17min de 1 de agosto de 2013 (UTC)
Quanto a questão principal, me convenceu com sua argumentação, mas lembre-se que nas versões antigas das páginas que contém a predefinição não ficará nada bonito. Cainamarques 12h43min de 23 de agosto de 2013 (UTC)
button for the 
for 
for 
for 
for 
for 
for 
for 
Sturm (discussão) 18h00min de 28 de agosto de 2013 (UTC)
Neutro. Como é feito em outras wikis? Por quê? Helder 16h57min de 28 de agosto de 2013 (UTC)
Discordo dos links, TheVulcan, pois pioraria a acessibilidade. Os 