Wikilivros Discussão:Portal comunitário

Origem: Wikilivros, livros abertos por um mundo aberto.
Ir para: navegação, pesquisa
Bem-vindo aos diálogos comunitários do Wikilivros em língua portuguesa.
Domingo, 21 de dezembro de 2014 — 7 058 módulos em 477 livros

Esta é a página onde qualquer pessoa (leitores, colabordadores e demais interessados no projeto) põem as suas dúvidas, propostas e comentários relacionadas ao Wikilivros.

  • Antes de criar um novo tópico, consulte os existentes para ter certeza de que sua questão ainda não foi abordada.
  • Para pesquisar diálogos iniciados antes da instalação da extensão LiquidThreads (agosto de 2010), consulte nossos arquivos mais antigos.
Iniciar uma discussão nova

Conteúdos

Título do tópicoRespostasÚltima alteração
Tech News: 2014-51016h43min de 15 de dezembro de 2014
Tech News: 2014-50017h11min de 8 de dezembro de 2014
Tech News: 2014-48019h31min de 24 de novembro de 2014
Tech News: 2014-47018h28min de 17 de novembro de 2014
VisualEditor News #9—2014023h29min de 14 de novembro de 2014
Global AbuseFilter017h34min de 14 de novembro de 2014
Tech News: 2014-46015h00min de 10 de novembro de 2014
Tech News: 2014-45017h28min de 3 de novembro de 2014
Tech News: 2014-44005h20min de 27 de outubro de 2014
Meta RfCs on two new global groups018h04min de 26 de outubro de 2014
Tech News: 2014-43013h47min de 20 de outubro de 2014
VisualEditor News #8—2014009h49min de 13 de outubro de 2014
Tech News: 2014-42008h53min de 13 de outubro de 2014
Tech News: 2014-41006h10min de 6 de outubro de 2014
Imagens usadas no projeto2317h47min de 2 de outubro de 2014
Tech News: 2014-40009h44min de 29 de setembro de 2014
Navegação automática3618h42min de 18 de setembro de 2014
Índice do livro e lista de módulos4818h41min de 18 de setembro de 2014
Propostaː Criar domínio para páginas com características em comum (Was a Reː Criação de um espaço nominal para as receitas)515h50min de 10 de setembro de 2014
Encontro Wikimedia Ibero-Americano 2014001h20min de 4 de setembro de 2014
Primeira página
Primeira página
Página anterior
Página anterior
Última página
Última página

16h43min de 15 de dezembro de 2014 (UTC)

MediaWiki message delivery (Discussão)16h43min de 15 de dezembro de 2014

17h10min de 8 de dezembro de 2014 (UTC)

MediaWiki message delivery (Discussão)17h11min de 8 de dezembro de 2014

19h31min de 24 de novembro de 2014 (UTC)

MediaWiki message delivery (Discussão)19h31min de 24 de novembro de 2014

18h28min de 17 de novembro de 2014 (UTC)

MediaWiki message delivery (Discussão)18h28min de 17 de novembro de 2014

VisualEditor News #9—2014

23h29min de 14 de novembro de 2014 (UTC)

MediaWiki message delivery (Discussão)23h29min de 14 de novembro de 2014

Global AbuseFilter

Hello,

AbuseFilter is a MediaWiki extension used to detect likely abusive behavior patterns, like pattern vandalism and spam. In 2013, Global AbuseFilters were enabled on a limited set of wikis including Meta-Wiki, MediaWiki.org, Wikispecies and (in early 2014) all the "small wikis". Recently, global abuse filters were enabled on "medium sized wikis" as well. These filters are currently managed by stewards on Meta-Wiki and have shown to be very effective in preventing mass spam attacks across Wikimedia projects. However, there is currently no policy on how the global AbuseFilters will be managed although there are proposals. There is an ongoing request for comment on policy governing the use of the global AbuseFilters. In the meantime, specific wikis can opt out of using the global AbuseFilter. These wikis can simply add a request to this list on Meta-Wiki. More details can be found on this page at Meta-Wiki. If you have any questions, feel free to ask on m:Talk:Global AbuseFilter.

Thanks,

PiRSquared17, Glaisher

— 17h34min de 14 de novembro de 2014 (UTC)

MediaWiki message delivery (Discussão)17h34min de 14 de novembro de 2014

15h00min de 10 de novembro de 2014 (UTC)

MediaWiki message delivery (Discussão)15h00min de 10 de novembro de 2014

17h28min de 3 de novembro de 2014 (UTC)

MediaWiki message delivery (Discussão)17h28min de 3 de novembro de 2014

05h20min de 27 de outubro de 2014 (UTC)

MediaWiki message delivery (Discussão)05h20min de 27 de outubro de 2014

Meta RfCs on two new global groups

Hello all,

There are currently requests for comment open on meta to create two new global groups. The first is a group for members of the OTRS permissions queue, which would grant them autopatrolled rights on all wikis except those who opt-out. That proposal can be found at m:Requests for comment/Creation of a global OTRS-permissions user group. The second is a group for Wikimedia Commons admins and OTRS agents to view deleted file pages through the 'viewdeletedfile' right on all wikis except those who opt-out. The second proposal can be found at m:Requests for comment/Global file deletion review.

We would like to hear what you think on both proposals. Both are in English; if you wanted to translate them into your native language that would also be appreciated.

It is possible for individual projects to opt-out, so that users in those groups do not have any additional rights on those projects. To do this please start a local discussion, and if there is consensus you can request to opt-out of either or both at m:Stewards' noticeboard.

Thanks and regards, Ajraddatz (talk) 18h04min de 26 de outubro de 2014 (UTC)
MediaWiki message delivery (Discussão)18h04min de 26 de outubro de 2014

13h47min de 20 de outubro de 2014 (UTC)

MediaWiki message delivery (Discussão)13h47min de 20 de outubro de 2014

VisualEditor News #8—2014

09h49min de 13 de outubro de 2014 (UTC)

MediaWiki message delivery (Discussão)09h49min de 13 de outubro de 2014

08h53min de 13 de outubro de 2014 (UTC)

MediaWiki message delivery (Discussão)08h53min de 13 de outubro de 2014

06h10min de 6 de outubro de 2014 (UTC)

MediaWiki message delivery (Discussão)06h10min de 6 de outubro de 2014

Imagens usadas no projeto

Editado pelo autor.
Última edição: 14h16min de 25 de maio de 2011

Gostaria de retomar a questão dos carregamentos de imagens aqui no Wikilivros. Já foi falado sobre isso em outros lugares, por exemplo:

Como alguns podem ter visto, em julho do ano passado foi anunciado o início de um projeto de usabilidade focado especificamente no Wikimedia Commons: usability:Multimedia:Hub. Naquela página, há uma tabela indicando a prioridade que é dada a algumas funcionalidades desejáveis para o Commons. Entre as mais importantes estão:

  • Uma nova interface para substituir a Especial:Upload (quem quiser pode testar ou assistir aos vídeos listados naquela página - em inglês)
  • Um tutorial sobre copyright e licenças livres
  • Sugestão de categorias com base nas descrições fornecidas pelo usuário
  • Possibilidade de realizar carregamentos diretamente para o Commons a partir de qualquer wiki

Foi desenvolvida também uma extensão chamada de Add Media Wizard, para oferecer uma interface mais adequada para a inserção de imagens nos artigos (ver imagem de exemplo). Pode-se testar o recurso na Wikipédia anglófona. Quem quiser, já pode testar o Add Media Wizard aqui mesmo no Wikilivros Teeth.png: Habilite o Add Media Wizard e experimente colocar umas imagens na caixa de areia usando o botão da barra de ferramentas.

Gostaria de sugerir que deixássemos de carregar imagens localmente, tendo em vista:

  • O que tem sido planejado para o futuro do Commons
  • O fato de que os participantes e administradores do Commons estão mais acostumados a lidar com questões envolvendo arquivos, licenciamento e outras coisas do gênero
  • E a vantagem de se centralizar as imagens e demais arquivos naquele repositório central.

O que pensam a respeito?

Helder18h45min de 8 de outubro de 2010

Sou a favor da remoção das principais ligações para o carregamento interno e da adição de ligações para o commons, mas não de desativar o carregamento totalmente.

Raylton P. Sousa qualquer coisa estou aqui! =D14h31min de 9 de outubro de 2010

Helder,

Desta vez, mas é só desta vez, já estou avisando... concordo com o Raylton (afinal ele também até concordou lá com aquela coisa da ficha em vez dos dados, e não estávamos no casino). Mais vale prevenir que remediar (slogan de preservativo de há cinquenta anos). Fica assim uma coisa mais reservada, mas que pode ser usada em caso de necessidade. Não precisa de mostrar a toda a moça da caixa de cada vez que vc. vai pagar qualquer coisa. Pode guardar mais dentro da carteira, não é? O mais provável é não ter que usar mesmo, mas tem sempre aquela esperançazinha...

Atenciosamente,

Virgílio A. P. Machado

Vapmachado (Discussão)03h31min de 10 de outubro de 2010

Entendi o que disseram mas não consegui perceber nenhum "caso de necessidade" em que seria preciso dispor do recurso local, quando se pode sempre usar a solução global.

Notem ainda que localmente nossas imagens tendem a ficar absolutamente bagunçadas, pois não há qualquer esforço nem mão de obra para mantê-las devidamente categorizadas como acontece no Commons (só existe a Categoria:Imagens e as das licenças, mas aparentemente nenhuma com o fim de organizá-las). Compare-se, por exemplo, a nossa Especial:Ficheiros não categorizados com a commons:Special:UncategorizedFiles e percebam a proporção (no momento 105/1 032 versus 16/7 536 316).

Helder (Discussão)11h42min de 10 de outubro de 2010
 

Outra coisa, inspirada por Tópico:Wikilivros:Diálogos comunitários/Sistema de avaliação e premiação/resposta (13):

Em que seria mais fácil procurar uma imagem existente aqui, em vez de procurá-la no Commons? Para mim, em nada. Tanto "uma imagem qualquer de lá" ou uma imagem qualquer daqui não têm a ver com os livros do nosso projeto: em geral têm a ver com o objetivo para o qual foi criada, mas para pouca coisa além disso. É justamente por este motivo que costuma ser preciso carregar novas imagens (e que até me ofereci há uns anos para ilustrar o livro de Análise real). Só não acho que aqui seja o lugar de carregá-las, já que existe um lugar comum a todos os projetos.

Um outro aspecto é que aqui não dispomos de um grupo de editores que possa ajudar aperfeiçoar imagens existentes, ou ajudar com aspectos técnicos relacionados às imagens e outros arquivos, como há no Commons o Commons:Graphics village pump.

Os carregamentos locais também dificultam iniciativas de tradução de wikilivros entre os projetos, pois se alguém for traduzir um texto daqui para colocar no Wikilivros em outro idioma, terá que carregar cada imagem local daqui novamente (e se carregar local novamente, haverá duas cópias locais inacessíveis para uma próxima tradução) para poder usá-la no texto traduzido (supondo que seja um diagrama ou imagem que não dependa do idioma).

Helder (Discussão)11h53min de 10 de outubro de 2010
 
 

Consigo ver todas as vantagens, mas se haverá "possibilidade de realizar carregamentos diretamente para o Commons a partir de qualquer wiki" será que faz diferença deixar de carregá-las aqui?

Outra coisa: acho que concordo com a Patrícia: não será mais fácil lidarmos com usuários tentando carregar imagens aqui do que forçá-los a se virarem por lá?

Jota (Discussão)13h34min de 11 de outubro de 2010

Deixe me explicar... continuo sendo a favor do bloqueio como anteriormente, só que agora por conhecer um pouco mais o software e o projeto penso que remover as ligações também é um jeito de bloquear o carregamento, só que de maneira menos traumatizante.

Raylton P. Sousa qualquer coisa estou aqui! =D18h03min de 12 de outubro de 2010

Só não entendi o motivo para não ser a favor "de desativar o carregamento totalmente"?

Helder (Discussão)18h29min de 12 de outubro de 2010
 
Editado pelo autor.
Última edição: 12h30min de 16 de outubro de 2010

Se haverá diferença? Acho que sim: tendo o carregamento local ativo, sempre haverá a necessidade de cuidar de tais imagens. Isso inclui:

  • Verificar cada upload, e também as existentes, para certificar-se de que não são violações dos direitos de autor;
  • Verificação daquelas que não tem qualquer uso no projeto e eventual eliminação;
  • Categorização local
  • Indisponibilidade das mesmas para outras wikis (implicando na necessidade de re-carregamento no Commons no caso de alguém querer traduzir algo daqui que use uma imagem que não está no Commons).

Ou seja, essencialmente os mesmos problemas que já existe agora.

Não acho preciso esperar (vários meses, já que, conforme a tabela deles, os "carregamentos no Commons a partir das wikis" não são de prioridade máxima) até que os novos recursos que estão sendo planejados para o Commons estejam disponíveis.

Helder (Discussão)18h39min de 12 de outubro de 2010

Exemplo aleatório: Quando queremos que as pessoas parem de comer gordura trans não tiramos das prateleiras simplesmente(pois há pessoas que, por algum motivo, querem ou precisam comer), em vez disso vamos incentivando o uso de comida sem gordura trans e diminuindo sua produção, e quando ninguém mais lembrar de gordura trans, então não há mais motivos para produzi-la e nem traumas da transição. Percebe?

Raylton P. Sousa qualquer coisa estou aqui! =D19h21min de 12 de outubro de 2010
 

Helder,

Tal como a Raylton, acima às 18h 03min de 12 de Out., concordo com a remoção das ligações, mas acho que não há necessidade de «desactivar o carregamento totalmente», mas não pela razão atribuída à Patrícia: por ser mais fácil lidar «com os usuários tentando carregar imagens aqui do que forçá-los a se virarem por lá». Acho que se deve manter essa alternativa para ser usada nalgum caso excepcional, como alternativa temporária a qualquer dificuldade que surja no Commons ou outras situações igualmente imprevistas. A utilização deve ser desencorajada e vigiada para que não se acumulem lá imagens, sem terem sido carregadas no Commons. Ou seja, normalmente, não devem estar aqui arquivadas imagens nenhumas.

Atenciosamente,

Virgílio A. P. Machado

Vapmachado (Discussão)02h17min de 16 de outubro de 2010

Ok!

Deixaríamos então a página de upload local escondida para que fosse usada em caso de necessidade (algo que impeça o carregamento no Commons, ou sei lá o que). Então, quando alguém utilizar, deve-se mover a imagem para o Commons assim que o impedimento para o carregamento global desapareça?

Por mim tudo bem (apesar de achar que é o tipo de vigilância que esqueceremos de fazer =/).

Helder (Discussão)12h37min de 16 de outubro de 2010

Citação: Helder escreveu: «Então, quando alguém utilizar, deve-se mover a imagem para o Commons assim que o impedimento para o carregamento global desapareça? » Não entendi direito o que quer dizer carregamento global e desapareça

Raylton P. Sousa qualquer coisa estou aqui! =D12h40min de 26 de outubro de 2010
 
 
 
 
 

09h44min de 29 de setembro de 2014 (UTC)

MediaWiki message delivery (Discussão)09h44min de 29 de setembro de 2014

Navegação automática

Editado por 2 outros utilizadores.
Última edição: 16h51min de 23 de janeiro de 2014
  1. Atualmente, há alguns bugs em Autonav:
  2. É possível gerar HTML através de coleção? Se o MediaWiki não tem esse recurso, talvez um script poderia ser usado para gerar o HTML para o usuário através da coleção quando ele pedir. Assim, não precisaríamos de páginas especiais de impressão.
  3. {{LivroPP}} resolve redundância entre índice e coleção, mas exige que a pessoa escreva o nome do livro completamente, o que não é necessário se o índice estivesse na página inicial.
  4. Acho que seria bom a possibilidade de usar uma aparência alternativa em livros específicos em vez da aparência padrão. Este livro teria uma predefinição com nome padrão e a aparência alternativa. O script de Autonav poderia verificar se essa predefinição existe para usá-la. Se isso não for possível, poderíamos pelo menos definir a cor de borda e preenchimento na página da coleção e o script leria a cor dela.
Abacaxi (Discussão)21h30min de 28 de dezembro de 2013

2. O formato ZIM é bem dizer uma versão "HTML" da coleção (ele arquiva e indexa HTML). Temos também o EPUB. Eu "desisti" de gerar HTML através de transclusão, porque o script teria que dar um jeito para aumentar os níveis de cada seção, antes de gerar esse "HTML". Eu até fiz um simples script para aumentar os níveis, mas essa não seria uma solução, pois necessitaria de alterações na forma como fazemos wikilivros (dessa forma cada módulo teria que começar com uma seção com nome do módulo e colocar todo conteúdo dentro dessa seção). Por isso optei por deixar o ZIM como a versão "HTML".

3. Pois é, a pessoa tem que escrever o nome do livro completamente, mas não acho que isso seja tão difícil assim (rs). Também acho interessante criar a coleção a partir de um índice montado na primeira página do livro, mas como ninguém havia criado um "script" para fazer isso, logo criei essa predefinição para eliminar ao menos uma redundância. Posso dizer também que me motivei a criar essa predefinição, para também, padronizar em parte a estrutura de um livro (prefácio, colocação de elementos na primeira página, etc.).

4. Eu sugeri que houvessem classes CSS para cada livro (claro, algo editável por "editores", ou seja, não limitado a "administradores"). Infelizmente isso ainda não é possível :/

Guiwp (Discussão)22h23min de 28 de dezembro de 2013
  1. O recurso de definir CSS específico para cada livro foi pedido no bugzilla:15075. Até que seja resolvido, estamos utilizando um gadget como hack: Wikilivros:Gadgets dos livros. Ele se encarrega de carregar estes scripts e folhas de estilos nos livros correspondentes. De qualquer modo, a permissão necessária para editar páginas de CSS e JS, que estão no domínio MediaWiki é a editinterface, que só é concedida a administradores. Futuramente, se/quando implementarem os gadgets 2.0 a situação poderá mudar: mw:Thread:Talk:ResourceLoader/V2 testing/Questions about permission model and developer workflow.
Helder.wiki (Discussão)19h27min de 21 de janeiro de 2014
 
Editado por outro utilizador.
Última edição: 19h31min de 21 de janeiro de 2014

Colocar índice na página inicial do livro[editar | editar código-fonte]

Abacaxi, você entende de Lua? Talvez seja possível fazer o script que colete os links na primeira página do livro através dessa linguagem. Mas para ser mesmo automático, precisamos de um "trigger", ou algo orientado a eventos (tipo, quando atualizarem a página, aciona-se o "script" e ele atualiza a coleção).

Eu não entendo de Lua, mas se você quiser dar início a "este script", eu tento ajudar. Também, possivelmente, o Helder e o Raylton em coisas mais emergenciais, ou difíceis, eles podem prestar um "suporte" rs.

Notas[editar | editar código-fonte]

Elementos sintáticos idênticos e significados diferentes[editar | editar código-fonte]

A sintaxe usada na coleção parece dar significados diferentes a determinados elementos:

  • Declaração de capítulo: usa-se a sintaxe para definição de termos ;. Na coleção é entendido como "capítulo", no "livro" é entendido como "definição de termo" (como os elementos tipo HTML dt, etc.). Usaríamos uma sintaxe alternativa para indicar o capítulo? E qual seria?

Como pretende solucionar isso Abacaxi?

Recursos do Scribunto (Lua)[editar | editar código-fonte]

Dei uma breve leitura agora, parece que você pode usar:

Guiwp (Discussão)15h45min de 30 de dezembro de 2013

2. Não consegui visualizar ZIM pelo navegador. A ideia da versão HTML é poder visualizar no navegador e imprimir sem precisa de outro programa.

4. Se é possível para um script coletar dados de uma página, como lista de links, significa que é possível ler cor de uma predefinição.

Lua não é o problema. A dificuldade é saber como scripts do Mediawiki funcionam. Eu vi scripts em Lua e JavaScript espalhados em vários lugares. Por ser coisas sensíveis, só administradores podem mexer.

Abacaxi (Discussão)19h35min de 30 de dezembro de 2013

2. O ZIM precisa mesmo de um leitor próprio, já EPUB tem addon para navegador (significa que você pode ler no próprio navegador). E infelizmente, ainda o melhor documento para impressão é o PDF. HTML não foi feito para impressão, agora é que estão aliando CSS3 para poder, quem sabe, criar o tal "HTML para impressão". Mas isso é um assunto "longo", na internet tem muita coisa sobre isso.

4. Acredito que trabalhar diretamente com CSS seria mais interessante. No mais eu deixo Helder.wiki e Raylton P. Sousa comentarem sobre isso.

Guiwp (Discussão)20h18min de 30 de dezembro de 2013

Em teoria poderíamos utilizar lua para ler a página de índice e processa-la conforme necessário. Só não sei qual a viabilidade disso. Provavelmente faríamos o mesmo processo que fazemos com javascript só que com uma linguagem diferente. Não é possível pular a etapa de criar coleção porque a coleção é padronizada e o índice não. Automação exige padronização.

A predefinição {{LivroPP}} parece interessante. Vou dar uma olhada nela em breveǃ

O resto comento logo maisǃ Abraçoǃ

Raylton P. Sousa qualquer coisa estou aqui! =D20h40min de 30 de dezembro de 2013
Editado pelo autor.
Última edição: 18h42min de 18 de setembro de 2014

Exato. O melhor é que o sistema possa ter uma sintaxe padronizada, e como a Collection não aceita que a lista seja gerada por transclusão, a única opção é que a sintaxe utilizada seja aquela reconhecida por essa extensão.

Os índices não eram feitos de forma padronizada, então mesmo o JavaScript que criei para facilitar a criação das coleções encontra problemas pelo caminho, que exigem correção manual...

Helder.wiki (Discussão)19h35min de 21 de janeiro de 2014

Seria mais adequado atualizações automáticas, porque as páginas continuarão mudando com o tempo. O Raylton tinha um script que cria ou atualiza páginas de coleção de acordo com a página inicial.

Abacaxi (Discussão)18h16min de 26 de janeiro de 2014
 
 
 
 

Abri o pedido de exportação em formato HTML no bugzilla:60300. Isso já havia sido sugerido no Tópico:Wikilivros:Plantão de dúvidas/Coleção de HTML e na mw:Extension:Collection/Wishlist#Output HTML.

O MediaWiki propriamente dito não tem nenhum outro recurso que gere o livro inteiro em HTML. Uma tentativa minha e do Raylton nesse sentido foi a mw:Extension:BookManager#Automatic print version, mas infelizmente ainda não temos uma versão que possa ser instalada nas wikis da WMF.

Outras opções seriam:

  • Abandonar o suporte a quem não tem/desativa JavaScript no navegador, e desenvolver um gadget que gere a versão HTML on the fly, quando requisitado pelo leitor, sem criar página alguma na wiki.
  • Utilizar links deste tipo para a Special:ExpandTemplates, que se encarrega de expandir o código wiki quando alguém clicar? A desvantagem é que no HTML resultante também aparece a interface da página especial...
Helder.wiki (Discussão)19h57min de 21 de janeiro de 2014

Não acho difícil eles fazerem a versão HTML, porque seria só juntar todas as página em uma só e mostrar como versão de impressão. E a motivação é poder ver tudo ou imprimir sem precisar de software especial.

Sim, essas alternativas podem ser usadas temporariamente enquanto eles não implementam versão HTML. Mas seria bom atualizar para usar a coleção como base, em vez de Predefinição:Lista de capítulo.

Seria mais adequado usar domínio "Livro" em vez de "Wikilivros:Livro/...". Na Wikipédia, esse domínio é usado (Livro:Mitologia Grega). O trabalho será renomear tudo.

E qual seria o padrão proposto para índice e página inicial do livro? Como falei, seria adequado o editor se preocupar em editar em só um lugar. Os outros poderiam ser atualizados automaticamente ou por um robô que monitora as edições de índices.

Abacaxi (Discussão)13h54min de 22 de janeiro de 2014

Difícil não é. Tanto que eu e o Raylton até incluímos um protótipo na extensão BookManager... A questão é que esse tipo de coisa, que só beneficia um dos projetos menores (ou seja, quase todos exceto a Wikipédia inglesa), costuma ser tratado como baixa prioridade. Então a não ser que a gente mesmo coloque a mão na massa, e escreve o código necessário, para que "eles" só precisem revisar, as coisas costumam andar bem lentamente...

Como disse em outro lugar, a discussão sobre o domínio específico para as coleções deveria ser continuada em um tópico específico.

Helder.wiki (Discussão)16h20min de 22 de janeiro de 2014
 

Acrescentei ao Módulo:Book (antes chamado de "Módulo:Nav") uma função que gera a versão para impressão, e coloquei no lugar da predefinição que era utilizada na Predefinição:Versão para impressão automática.

Optei por ignorar (não transcluir, nem mencionar) eventuais links vermelhos que estejam na coleção, por não acrescentarem nada à versão impressa.

Helder.wiki (Discussão)20h32min de 23 de janeiro de 2014

Para simplificar as coisas, acho que {{Versão para impressão}} poderia então ser movido para {{livro}}. Assim usaríamos só uma predefinição. Poderia ser colocado também o link de HTML em {{Livro gravado}} por ser um dos formatos também. Quando eles implementarem HTML pelo próprio MediaWiki é só substituir na predefinição.

Agora é saber qual é a melhor solução, para não ter que criar páginas "/imprimir". Posso ver Special:ExpandTemplates e o problema com a interface, mas não sei como ficaria aquela com JavaScript. Não sei se é possível, mas pode ser bom que a predefinição seja carregada numa página que esteja sendo prevista e ter algum bloqueio para evitar que ela seja salva. A vantagem é que a interface ficaria na parte debaixo.

Abacaxi (Discussão)22h06min de 23 de janeiro de 2014
 

Que boa notícia Helder. Podemos colocar a {{Lista de capítulos}} em desuso agora né? Pelas minhas contas era só isso que faltava tornar a antiga predefinição obsoleta.

Raylton P. Sousa qualquer coisa estou aqui! =D22h29min de 23 de janeiro de 2014

Creio que sim, mas é bom que testem em mais casos, para nos certificarmos de que está funcionando como deveria.

Helder.wiki (Discussão)23h00min de 23 de janeiro de 2014
 
 
 
Editado pelo autor.
Última edição: 10h41min de 26 de janeiro de 2014

Acho que resolvi o nosso problema com mais uma gambiarra. Ela combina:

Provavelmente precisará de mais uns ajustes para ficar ótimo (e mover o CSS para o lugar ideal), mas por enquanto, o que acharam?

Helder.wiki (Discussão)22h59min de 23 de janeiro de 2014

Tô só de espectador, mas tô gostando de ver! rs

Guiwp (Discussão)02h04min de 24 de janeiro de 2014
 

A {{Lista de capítulos/Imprimir}} tá obsoleta também? Vi alguns afluentes!

Raylton P. Sousa qualquer coisa estou aqui! =D02h31min de 24 de janeiro de 2014

Parecem ser afluentes fantasmas...

Eu pensava que a atualização de afluentes ia para a fila de tarefas, mas conforme esta consulta à API, ela está vazia, mesmo havendo 27 afluentes que precisam ser corrigidos. Será que ela não está funcionando como deveria?

De qualquer modo, abrir cada página em modo de edição, e clicar em salvar (sem sequer alterar o código) costuma ser o suficiente para forçar a remoção da lista de afluentes (funcionou com Gramática inglesa estrutural/Imprimir e Alfabeto para crianças/Imprimir, por exemplo). Fiz isso com as páginas que faltavam, então não há mais transclusões.

Helder.wiki (Discussão)10h27min de 24 de janeiro de 2014

Massa... Comecei a página de ajuda para documentarmos.

Ajudem-me!

Raylton P. Sousa qualquer coisa estou aqui! =D15h58min de 24 de janeiro de 2014
 

A propósito, o mw:Manual:Pywikibot/touch.py pode ser útil caso apareça uma quantidade maior de páginas para atualizar futuramente...

Helder.wiki (Discussão)17h52min de 28 de janeiro de 2014
 
 

Para mim do jeito que está está bom. O único bug aparece nas cores de código de livro de linguagem de programação: velho, novo. Mas é melhor do que manter páginas '/imprimir'.

Abacaxi (Discussão)15h31min de 25 de janeiro de 2014

Suspeito que o problema seja o mesmo do bugzilla:39049, e que não podemos fazer nada a respeito localmente...

Helder.wiki (Discussão)15h51min de 25 de janeiro de 2014
 
 

Uma pergunta, se a cor e aparência da navegação de livros específicos é definida pelo CSS, seria possível colocar um script que lê informações de páginas editáveis por usuários comuns para gerar o CSS? Da mesma forma que um script lê a coleção para fazer a navegação.

Abacaxi (Discussão)23h02min de 24 de janeiro de 2014

CSS não é nem deve ser editável por usuários comuns por questões de segurança.

Helder.wiki (Discussão)13h43min de 25 de janeiro de 2014

O que eu tinha falado era deixar o usuário colocar a informação na página da coleção, como cor de bordo e de preenchimento, e então o script lê a cor e faz a navegação ter essa cor. Poderia ser criado também múltiplos estilos de navegação e o usuário por na coleção qual estilo ele prefere.

Abacaxi (Discussão)14h50min de 25 de janeiro de 2014
 

Curiosidade.

Sobre Citação: Helder escreveu: «CSS não é nem deve ser editável por usuários comuns por questões de segurança.»

Você fala no sentido de alguém mudar o visual de algum elemento para se passar por outro para pode fazer alguma coisa mal intencionada?

Pelo que me lembro do CSS, e pelo pouco que sei sobre ele (uso só os recursos básicos... rs), sei que ele não tem muitos recursos para permitir vazamento de informação e outras coisas...

Ou você também está se referindo a estabilidade do projeto, ex.: "estragar" o visual (acessibilidade também) seja por vândalos, seja por pessoas que não entendam muito de CSS... ?

Finalizando, acredito que possamos permitir, mas só a usuários cadastrados com um número mínimo de edições (assim como se faz para ser revisor, etc.).

Guiwp (Discussão)15h42min de 25 de janeiro de 2014

O CSS por ser aplicável ao site todo. pode torna-lo totalmente inutilizável. Ou até mesmo tornar impossível visualizar o site inteiro. Além de inserir informações falsas/promocionais que só poderiam ser desfeitas por pessoas com conhecimento especifico etc.

Raylton P. Sousa qualquer coisa estou aqui! =D16h18min de 25 de janeiro de 2014
 

Ao contrário do CSS pessoal que cada usuário pode editar, o CSS que se aplica a todos os usuários só deve ser editável por usuários que tenham a permissão correspondente (atualmente, "editinterface"). Ver também as preocupações levantadas nos seguintes lugares:

Helder.wiki (Discussão)16h34min de 25 de janeiro de 2014
 

Ao contrário do Guiwp, minha proposta não é deixar usuários editar CSS e sim a criação de um script que leia dados que o usuário colocar na página da coleção para dar mais customização à aparência do livro, como na navegação. Isso deixa o livro com uma cara mais única em vez de genérica.

Abacaxi (Discussão)17h59min de 25 de janeiro de 2014
 

Como por gadget somos livre para usar JavaScript sem restrições (certo?), e JavaScript tem recursos para mexer com CSS através do DOM. Sim, é possível.

Guiwp (Discussão)15h46min de 25 de janeiro de 2014
 
 
 

Índice do livro e lista de módulos

Um problema que tenho encontrado ao criar e reestruturar índices, incluindo adicionar, remover, fundir ou renomear módulos, é a atualização da Predefinição:Lista de capítulos. Ao modificar o índice, seria necessário atualizar essa predefinição. Então eu imagino se teria como fazer a predefinição de lista detectar as páginas do livro automaticamente através do índice.

Existe a Predefinição:Índice, que talvez poderia ajudar de alguma forma. O problema é que cada livro tem uma formatação diferente e estilo diferente do índice, dificultando o uso de predefinições. A criação de uma predefinição flexível é difícil.

Abacaxi (Discussão)19h45min de 12 de março de 2013

Acredito que o caminho ideal é ter a lista de capítulos em um único lugar, em vez de ficar fazendo cópias:

  1. Na página principal do livro
  2. Na coleção
  3. Na lista de capítulos

Dado que não há como se livrar da lista que vai na página da coleção (bugzilla:26533 / bugzilla:26448), a única lista que deveria ser mantida é aquela. Se eu não me engano uns testes que o Raylton e eu fizemos com Lua no mediawiki.org já permitem que nos livremos das listas de capítulos (pois dá para obtê-la a partir da coleção). Se isso realmente não quebrar nada (caches?), só falta lidarmos com os índices. No entanto, não vejo como automatizá-los sem ter uma dose razoável de padronização. Mas, como isso ajudaria a manter a sanidade dos editores, não vejo essa padronização como uma coisa ruim...

Helder18h39min de 14 de março de 2013

O script lua que estavamos testando já parece estar funcional. Só não apliquei por falta de tempo. Helder... Acho que vale a pena resgatar aquele seu script que transforma os índices em coleções. Porque só vamos poder migrar quando todos os livros tiverem suas respectivas coleções.

Raylton P. Sousa qualquer coisa estou aqui! =D19h05min de 14 de março de 2013
Editado pelo autor.
Última edição: 18h40min de 18 de setembro de 2014

Por enquanto, para utilizar o script que facilita a criação de coleções, precisa copiar o seguinte para o seu common.js (e limpar o cache do seu navegador):

// [[Ficheiro:User:He7d3r/Tools/BookTools.js]] (workaround for [[bugzilla:33355]])
mw.loader.load( '//meta.wikimedia.org/w/index.php?title=User:He7d3r/Tools/BookTools.js&action=raw&ctype=text/javascript' );

Depois, quando abrir o índice de um livro, verá alguns links extras na barra lateral.

Helder20h11min de 14 de março de 2013

A página principal do livro, o índice, é o lugar mais fácil para editores editarem o índice.

O índice pode variar em formatação e ainda ter hierarquia de tópicos e subtópicos. A solução mais fácil seria o script ler o índice e pegar subpágina por subpágina à medida que for encontrando no índice e assim formar a coleção mantendo a ordem na qual encontrou as subpáginas.

Obrigatoriamente, alguns livros terão que fugir do padrão, como o Livro de receitas.

Abacaxi (Discussão)20h42min de 14 de março de 2013

O fato do índice variar em formatação é um dos motivos para não ser possível um script ler essa página para gerar a lista de forma confiável. Automação requer padronização.

Helder11h23min de 18 de março de 2013
 

Existem páginas como Matemática elementar/Imprimir, que também são feitas manualmente. Seria melhor usar a coleção para gerar página de impressão.

Ainda existem várias predefinições antigas de navegação, como Predefinição:Navegação e Predefinição:AutoNav, além de predefiinções de livro que não são mais usadas, como Predefinição:Navegação/Teoria de números. Não seria melhor eliminá-las?

Abacaxi (Discussão)16h32min de 15 de março de 2013

Terminei de converter as listas... Já podemos converter

No ainda não podemos eliminar as listas antigas ainda tenho que fazer um script para a versão para impressão

Estou pensando em fazer algumas alterações na navegação, mas pode ser feito depois de ativada. Então... Vou ativar!

Raylton P. Sousa qualquer coisa estou aqui! =D18h25min de 19 de março de 2013
 
 
 
  • Isso já foi resolvido?
  • Posso criar o índice só em um lugar?
  • O que falta para isso ser possível, quais as dificuldades do momento?
  • Atualmente, onde é recomendável colocar o índice?

Como estou revisando e organizando o livro Javascript, gostaria que ele já ficasse conforme o novo padrão. Por favor, me auxiliem para que possa aprender e aplicar também nos outros.

Obrigado.

Guiwp (Discussão)15h12min de 8 de setembro de 2013
 
Editado por 2 outros utilizadores.
Última edição: 10h35min de 23 de janeiro de 2014

Vou reorganizar o que estávamos conversando aqui sobre índices e coleções:

  1. Yes check.svg Feito Achei um bug. Módulos cujo título tem caracteres diferentes como &, ', " e :, não aparecem na navegação. Páginas: Wikilivros:Livros/Acupuntura hoje (&), Manual de urbanismo/Canalização e Retificação de Cursos D'água('), Guia para iniciantes em genealogia/Qual "software" devo usar? ("), Logística/Sistemas de procura independente: modelos determinísticos (:).
  2. O índice de um livro pode ser modificado, pode ocorrer mudança de ordem, página renomeada, página adicionada, link vermelhos renomeadas ou inserção de links vermelhos. Assim coleção precisa ser atualizada. Seria possível fazer um robô executar uma vez por mês para detectar os índices de livro que foram modificados nos últimos 30 dias e então atualizar a coleção? Desde a criação de coleções, vários livros receberam várias edições e precisam agora de atualizar a coleção. As coleções deles são mais trabalhosas de editar manualmente.
  3. Vamos decidir o que fazer com sub-índices de livros.
    1. Lista de exercícios poderiam ser exibidas na horizontal em vez de vertical mostrando só o número. Isso ocuparia menos espaço no índice. (Curso de termodinâmica)
    2. Módulos pequenos de um livro poderiam ser fundidos num módulo maior quando possível.
    3. Os livros de idiomas estão divididos entre "curso" e "gramática" (Espanhol, Inglês, Francês, Italiano, Português). Concordaria em dividir o livro do idioma em dois livros, um para o curso e outro para a gramática?
    4. Estou listando aqui os livros com sub-índices que achei:
  4. As páginas que estavam na categoria de módulos fora de coleções foram colocados uma vez aqui. Quando resolvermos os itens anteriores, seria bom atualizar essa lista para ver o que mais falta.
  5. Há livros com estilo próprio de navegação, mas vamos deixar isso para o final. No momento vou listar aqui só para não esquecer.
  6. Quando tudo estiver pronto. Poderemos apagar Predefinição:Nav, Predefinição:Lista_de_capítulos, páginas "/Imprimir", Predefinição:Versão para impressão, Predefinição:Versão para impressão automática.
Abacaxi (Discussão)20h10min de 24 de maio de 2013
Editado por outro utilizador.
Última edição: 10h36min de 23 de janeiro de 2014

Concordo plenamente com o item 3.3.

Mário Júnior (Discussão)20h59min de 24 de maio de 2013
 

Sugiro que a questão de dividir ou não os livros de idiomas seja discutida no tópico que já existia:

Lembrando de levar em conta o que já havias sido dito sobre isso em tópicos ainda mais antigos, como

Helder.wiki (Discussão)19h26min de 22 de janeiro de 2014
 

O problema com os caracteres especiais parece ter sido resolvido por esta, esta e estas edições. O problema é que em uma página chamada "*A'B&C"D" a "{{PAGENAME}}" retorna "*A'B&C"D", e o módulo precisava utilizar o nome original, sem qualquer codificação. Assim, quando defini o valor padrão do parâmetro "page" como sendo o título da página em que o módulo estiver sendo utilizado, esses títulos deixaram de ser um problema. Para o caso de ser utilizada a palavra mágica em algum lugar, também apliquei uma função de decodificação ao parâmetro "page".

Helder.wiki (Discussão)20h55min de 22 de janeiro de 2014
 

São muitos tópicos, inclusive tópicos velhos. O assunto seria 'coleções', 'índice' e 'navegação'.

Os módulos com sub-índices são aqueles que estão mais em desacordo com o padrão. Acredito que o grande problema do livro de idiomas é que pouca gente conhece o idioma e não saberia reestruturar o livro. O mesmo vale para o livro de Logística, que além de ter muitos módulos, os autores, que conhecem o livro, não editam mais.

O outro erro na navegação aparece em JavaScript/Introdução em que o próximo módulo não aparece.

Abacaxi (Discussão)22h15min de 22 de janeiro de 2014

O problema que havia na JavaScript/Introdução foi resolvido eliminando strings vazias da lista de capítulos.

Helder.wiki (Discussão)13h44min de 23 de janeiro de 2014

Ótimo. :) O próximo passo agora é discutir como resolver a redundância entre índice principal e a coleção. Seria adequado se o editor editar apenas em um lugar. O outro lugar poderia ser atualizado por um robô ou através de predefinição. Será usada {{LivroPP}} como padrão? Como ficariam a capa e o texto introdutório? Não vejo problemas em deixá-los aparecer no índice.

Para lembrar depois: esboço do Raylton. Índices grandes se beneficiariam com {{oculto}}.

Abacaxi (Discussão)17h18min de 23 de janeiro de 2014

A {{oculto}} não faz parte da sintaxe aceita pela extensão Collection.

Helder.wiki (Discussão)18h29min de 23 de janeiro de 2014
 
 
 
 
 

Propostaː Criar domínio para páginas com características em comum (Was a Reː Criação de um espaço nominal para as receitas)

Quando participei (há alguns anos) da discussão supracitada eu não tinha muita clareza para definir se deveria aceitar esse namespace. Mas hoje percebo que cada página de um namespace desse tipo teria as seguintes coisas em comumː

  1. Uma lista de materiais/ingredientes
  2. Um procedimento/passo-a-passo/modo de preparo

Por isso esse domínio incluiria uma infinidade de coisas que eventualmente poderiam não se enquadrar na estrutura de sub-páginas com a qual estamos acostumados. Ou seja vários tipos de passo-a-passo comoː "DIYs", "HowTos" "receitas culinárias" e qualquer outra coisa que se enquadrasse nos critérios dos itens 1 e 2.

Por isso sugiro a criação de um domínio para esse tipo de página.

O nome do domínio não é muito relevante. Sou a favor do domínio "Faça você mesmoː" Ou até mesmo "Façaː" mas estou aberto a outras sugestões desde que a escolha do nome não bloqueie o andamento da criação do domínio.

Note que nesse domínio as receitas culinárias poderiam ser categorizadas de forma bem parecida. Mas o índice provavelmente seria redirecionado de "Livro de receitas" para "FaçaːCulinária" ou algo do tipo.

Com carinho.

Raylton P. Sousa qualquer coisa estou aqui! =D22h59min de 3 de setembro de 2014

Minhas sugestões para o nome do domínio, por ordem de preferência:

  • Como fazer
  • Passo-a-passo
  • Faça
  • Faça você mesmo

O uso de "você" provavelmente não é boa ideia...

Helder20h15min de 9 de setembro de 2014

Eu gosto de "Como fazer", mas minha ordem de preferência seria ː

  • Como fazer
  • Faça
  • Passo-a-passo
  • Faça você mesmo

"Passo-a-passo" possivelmente seria uma seção da página, então talvez ficasse repetitivo.

Intéǃ

Raylton P. Sousa qualquer coisa estou aqui! =D22h41min de 9 de setembro de 2014

Então que seja "Como fazer".

Aparentemente este domínio também serviria para alguns outros livros: Especial:Índice por prefixo/Como.

Helder15h00min de 10 de setembro de 2014

Poderíamos pedir um 'alias' para 'faça' e 'passo-a-passo' e 'receita'?

(Talvez tbm para os americanizados 'DIY', 'DIWO' e 'HowTo'. Embora eu não bata o pé para nada dissoǃ)

Raylton P. Sousa qualquer coisa estou aqui! =D15h03min de 10 de setembro de 2014

Sim... Acho que serviria para livros com esse prefixo que tu citou sim.

Raylton P. Sousa qualquer coisa estou aqui! =D15h50min de 10 de setembro de 2014
 
 
 
 
 

Encontro Wikimedia Ibero-Americano 2014

Colegas,

O quarta edição do Encontro Wikimedia Ibero-Americano acontecerá em Buenos Aires, Argentina entre os dias 21 e 23 de novembro de 2014. O grupo brasileiro e o capítulo portugues têm cada um o direito de indicar dois participantes. A página para discussão sobre a delegação brasileira é WMBR:Encontro Wikimedia Ibero-Americano/2014. Sugiro que participe das discussões e, se tiver disponibilidade, indique seu nome como representante do nosso grupo. Há uma certa pressa na indicação dos nomes para a compra de passagens. Obrigado,

Lechatjaune msg01h20min de 4 de setembro de 2014
Primeira página
Primeira página
Página anterior
Página anterior
Última página
Última página