Wikipédia:Esplanada/propostas/Mudança em WP:O que é um artigo em destaque? (6abr2012)
![]() |
Mudança em WP:O que é um artigo em destaque? (6abr2012)
Proponho mudanças em WP:O que é um artigo em destaque?, mais especificamente na parte 8.6 que diz: - Artigos com tamanho superior a 190kb deverão ser desmembrados, a fim de evitar falhas e demoras de carregamento em determinados servidores.. Pois acho que não deve ter limites de tamanho nenhum artigo, pois a Wiki não é uma enciclopédia impressa logo essa regra viola as regras do próprio projeto. Mas também acho que não deve haver abusos em tamanho, pois quando for possível fazer desmembramentos, é altamente que o faça. E também, há artigos que não podem ser eleitos por causa dessa regra. Espero a opinião dos outros. Vitor Mazuco Msg 19h01min de 6 de abril de 2012 (UTC)
Proponho de:
8.6 - Artigos com tamanho superior a 190kb deverão ser desmembrados, a fim de evitar falhas e demoras de carregamento em determinados servidores
para:
8.6 - Não há tamanho máximo em artigos, porém algumas partes deles poderão ser desmembrados e colocados em um artigo específico, caso tenham conteúdo suficiente e que sejam notórias.
O que acham? Vitor Mazuco Msg 19h09min de 6 de abril de 2012 (UTC)
Concordo com a proposta. Eu estou passando por esse problema com o artigo Born This Way, que tem 270 Kb. Bad_Boy97 (discussão) • (contribuições) as 21:16:19 de sexta-feira, 6 de abril de 2012 (UTC+2)
A princípio Discordo. O limite dos 190k tem uma justificação. Não foi apresentado qualquer argumento que inviabilizasse a justificação existente. Também não está claro na argumentação do proponente, ou não percebi, em que sentido é que o tamanho máximo interfere com a eleição de artigos destacados. A argumentação da wikipédia impressa também não tem cabimento: pode não haver um limite de volumes impressos, como numa wikipédia convencional, mas qualquer página web tem um limite razoável de bytes de modo a manter-se funcional. A diferença é que a wikipédia permite imensos desdobramentos e sub-artigos que teriam de ser cortados numa enciclopédia convencional. Agora, ir buscar esse argumento para defender páginas únicas sem limite de tamanho não faz nenhum sentido. Polyethylen (discussão) 19h37min de 6 de abril de 2012 (UTC)
- Discordo. Isso foi levantado em 2010 q não teve consenso para aumentar, pelo contrário. Sigo a fala do Otávio por lá Citação: Otavio escreveu: «190Kb é muito grande e demora uma eternidade para visualizar. De casa, não consigo ler boa parte dos artigos candidatos a destaque devido ao tamanho. Um verbete de enciclopédia é um resumo de informação e não devemos supor que cobrirá por extenso a maioria dos assuntos. Sou contra aumentar este limite e favorável a sua redução.» O artigo é um resumo, se 190 kb não dá para colocar o resumo então o artigo não é um resumo, ou ele tem detalhes desnecessários ou partes q precisa desmembrar e as duas alternativas significam q ele não tem alta qualidade.
- Poly, lá na seção de "Wiki não é de papel" fala Citação: Isso significa que preocupações referentes a textos impressos como tamanho do texto, estilo ou composição não são necessariamente preocupações prioritárias por aqui. Então de certo modo faz sentido usar esse argumento, lá mesmo diz "tamanho do texto", seria +- o tamanho em kb. Lá fala em necessariamente e prioritária mas não q seja proibido / errado ter alguma limitação, é desaconselhado mas ter um limite fica em aberto pra comunidade decidir.
- Rjclaudio msg 21h48min de 6 de abril de 2012 (UTC)
- [conflito de edições]Eu acrescentaria que "se 190 kb não dá para colocar o resumo então..." talvez haja código wiki demais ou sendo usado desnecessariamente, já que formatação, predefinições e os nomes de seus parâmetros também consomem alguns desses bytes (que não são "o tamanho" do texto/resumo). Por exemplo, pra que tantos {{|tl|mdash}}? (O uso na enwiki é desencorajado). Helder 22h42min de 6 de abril de 2012 (UTC)
Tem certos assuntos(artigos) que 190kb é pouco. O Otavio disse que demora muito pra abrir, mas na minha, por exemplo não. Logo não há um consenso se dá ou não prolema pra todos os servidores, apenas para alguns. E tem artigos que é um resumo, não dá pra desmembrar nada, ou quase nada. Acho que não dá pra aplicar esse conceito a todos os 700 mil artigos. Vitor Mazuco Msg 22h06min de 6 de abril de 2012 (UTC)
- Não é por dar problema para todos, é por dar problema para alguns. A wiki não é para ser acessível apenas para quem tem o computador de última geração e internet de altíssima velocidade, é para ser acessível a qualquer um com acesso a internet. Eu considero o meu pc e internet boa / na média e fica lento pra mim, considerando q tem mt gente com menos recursos q eu, uma grande parcela da população vai ter dificuldade em acessar os artigos destacados.
- Q artigo q é impossível de resumir / desmembrar? Se passa dos 190 kb e não há como desmembrar então provavelmente a informação é um fancruft (só vai interessar a especialistas / fãs / super interessados no assunto).
- Rjclaudio msg 22h15min de 6 de abril de 2012 (UTC)
Discordo porque um artigo excedendo o limite de tamanho já dito pelas regras normalmente passa do quesito de objetividade no texto para um nível de informações enfadonhas; como o Rjclaudio mencionou acima, vira fancruft. — Lucas Rossi Discussão 22h20min de 6 de abril de 2012 (UTC)
(conflito de edições)
- Discordo Infelizmente a maioria da população tem acessos lentos à internete. Que se façam links tipo "Ver artigo principal" , "Ver anexo XXXX" , etc. Pessoalmente, discordo da existência de artigos destacados, pois só são destacados os artigos sobre assuntos que interessam ao proponente (nós não estamos aqui para destacar assuntos do nosso interesse mas sim, para possibilitar o acesso fácil à informação à maioria da população). Gostaria que, em vez de artigos destacados, se melhorasse a qualidade da wikipédia duma forma geral. --João Carvalho deixar mensagem 22h27min de 6 de abril de 2012 (UTC)
Aproveito para sugerir mudarmos a documentação sobre o tamanho das páginas, q diz q Páginas longas são páginas com mais de 32kb, trocando o 32kb para 190kb. Se um AD de 190kb não é considerado longo demais, uma página normal de 190kb tb não pode ser considerada longa. Atualizar Ajuda:Guia de edição/Tamanho de páginas. E tb o aviso q aparece qnd se vê o histórico das páginas. Rjclaudio msg 23h06min de 6 de abril de 2012 (UTC)
- Acho que a questão dos 32kb era uma questão técnica com alguns navegadores que cortavam o texto excedente a 32kb da caixa de edição. Se o problema não for mais relevante faz sentido essa mudança. Chico Venancio (discussão) 23h12min de 6 de abril de 2012 (UTC)
- Se o problema ainda se manter ao menos complementa a documentação, falando q é longo por questões técnicas mas q é permitido (não é um problema) ultrapassar esse tamanho, e q o limite que consideramos é 190 kb (critério para AD). Já vi artigos de 100k marcados com a tag
{{Artigo longo}}
e isso não pode ocorrer (colocar isso tb na documentação, todo artigo com mais de 190k pode ter a tag, mas se tiver menos não deve. ou recomendar ao invés de deve). Rjclaudio msg 23h19min de 6 de abril de 2012 (UTC)
- Se o problema ainda se manter ao menos complementa a documentação, falando q é longo por questões técnicas mas q é permitido (não é um problema) ultrapassar esse tamanho, e q o limite que consideramos é 190 kb (critério para AD). Já vi artigos de 100k marcados com a tag
Para os leitores, que em sua maioria não são editores, e para os quais, portanto, o tamanho do código wiki não tem a menor importância, o que importa é o tempo total que a página leva para carregar. Isso é afetado significativamente por vários fatores (exemplos), que não necessariamente dependem do tamanho do código wiki. A quantidade e o tamanho das imagens, o tamanho do HTML depois de compactado com gzip, o tamanho dos scripts, folhas de estilos e gadgets que estão ativados por padrão para todos os leitores e editores, se já visitaram a mesma página anteriormente (pois nesse caso pode haver uma cópia em cache), etc... influenciam, e apesar de os editores terem certo controle sobre essas variáveis, todas elas juntas podem ter bem menos efeito na performance do site do que os fatores que são controlados por quem cuida dos servidores e do código-fonte.
Por exemplo, o tempo que o artigo mencionado acima (Born This Way) leva para ser processada pelo parser do MediaWiki (antes de poder ser enviada ao (primeiro) leitor da página) se não houver uma cópia nos caches dos servidores é de cerca de 30 segundos (ver código-fonte da página usando "action=purge"). Além disso, ele pode até ter 270kb de código wiki, mas isso não tem muita relação com os dados do terceiro item abaixo (obtidos no Google Chrome), que é o que realmente importa para a maioria dos leitores:
- Born This Way?action=purge (e desabilitando também o cache do navegador): 186 requests ❘ 595.27KB transferred ❘ 1.2min (onload: 1.2min, DOMContentLoaded: 52.85s)
- Born This Way?action=purge: 183 requests ❘ 130.78KB transferred ❘ 31.15s (onload: 31.19s, DOMContentLoaded: 28.24s)
- Born This Way: 152 requests ❘ 72.54KB transferred ❘ 24.24s (onload: 24.24s, DOMContentLoaded: 15.18s)
Mais vale usar o bom senso do que esperar que o número "190kb" (ou qualquer outro que se escolha) represente precisamente o ponto a partir do qual a página "passou dos limites aceitáveis", pois páginas com código wiki gigante podem resultar em HTML compactado mínimo e páginas com código wiki mínimo podem resultar em um HTML gigante, e há uma imensidão de valores/casos intermediários entre esses extremos (e que podem estar fora do controle dos editores). Helder 23h56min de 6 de abril de 2012 (UTC)
- Aliás, um outro motivo para não ver o tamanho do código wiki como sinônimo da demora no carregamento do artigo para os leitores é que dependendo de como implementarem o (novo projeto) Wikidata, os dados das infoboxes e das referências poderão deixar de ser parte dos artigos. Então o tamanho do HTML das páginas continuaria essencialmente o mesmo (pois os dados continuariam nos artigos) mas o código wiki seria bem menor, pois os dados só estariam sendo obtidos a partir de uma wiki centralizada por meio de alguma sintaxe específica. Helder 00h13min de 7 de abril de 2012 (UTC)
Uma alternativa é então adaptar em alguns artigos pra que mantenham o mesmo tamanho e diminuísse seu Kbytes, por exemplo o artigo Getúlio Vargas tem 257 Kbytes e o que fazer com esse artigo? Tirar muitas seções do artigo? Apagar partes do artigo com ref e tudo? Passar pra um outro artigo(qual artigo? Ele seria notório pra ter um artigo independente? Cumpriria os critérios de notoriedade?) Vitor Mazuco Msg 00h54min de 7 de abril de 2012 (UTC)
- [conflito de edição]Note que esse artigo tem menos código wiki do que o anterior, mas resulta em uma página bem maior:
- 168 requests ❘ 1.71MB transferred ❘ 1.7min (onload: 1.7min, DOMContentLoaded: 18.35s)
- Eu sinceramente não acho que o número de bytes seja um bom parâmetro para dizer, sem levar em conta outros aspectos, se o artigo está com uma abrangência (tamanho?) adequada. O que tem que ser levado em conta é o que há para ser falado sobre o assunto e a qualidade da redação do mesmo. Se há informações repetitivas, ou desnecessárias, ou que podem ser sintetizadas em menos palavras ou de forma mais clara, é isso que deve ser aprimorado, não o número de bytes de código (que depende fortemente da representação escolhida - wikitexto, HTML, compactação, etc...). É análogo ao problema discutido em relação à avaliação automática dos artigos "pequenos": a qualidade depende do que há para ser dito sobre o assunto e não de um ou dois números que medem "algo" no artigo. Helder 01h29min de 7 de abril de 2012 (UTC)
Discordo da remoção do limite pois embora seja um parâmetro técnico e pelo que entendi do comentário do Helder não seja necessariamente ligado a demora para carregar uma página, devemos nos lembrar sempre que estamos criando uma enciclopédia. Os artigos devem ser um ponto de partida para que o leitor, através das fontes possa adequadamente se aprofundar no assunto, e não uma dissertação de 140 páginas. Admito que alguns temas são imensamente vastos para aprofundar mas é para isso que é duplamente importante citar as fontes pois serão a porta de saída da enciclopédia para uma pesquisa aprofundada do assunto.OTAVIO1981 (discussão) 01h07min de 7 de abril de 2012 (UTC)
Mazuco, não tenho tantos conhecimentos sobre o Getúlio Vargas mas biografias de políticos em geral, principalmente líderes de países, costumam se misturar com os artigos da história do país. Getúlio Vargas#Período Ditatorial: Estado Novo (1937 - 1945) tem link para Estado Novo (Brasil). Se já tem um artigo principal realmente precisa de toda aquela informação para falar do Estado Novo? Quanto daquele texto fala sobre o Getúlio Vargas e não é algo mais apropriado para o artigo da história do país? Não teria nada a remover ali naquela seção, q seja algo mais específico q alguém q se interesse vá para o artigo específico ler, deixando um resumo melhor só das coisas q afetam ele em si, principalmente o futuro dele? Quase todas as seções principais desse artigo tem um artigo principal então isso é válido para quase tudo ali, impossível não ter nada a resumir.
Helder, o critério de tamanho não é único, não é isso q diz q está com abrangência boa, mas é um critério para se avaliar se está ruim, se precisa resumir mais. Talvez o tamanho em bytes possa não refletir diretamente isso e poderia ser melhor mudar para o tamanho do texto em si, excluindo-se o código wiki / imagens. Mas o tamanho dos 190k me parece razoável, vendo a média, a maioria das páginas, isso reflete bem o critério subjetivo do resumo. Qnd aparecer um artigo com mais de 190k q esteja perfeitamente resumido / objetivo então concordarei em remover o critério mas até lá ele serve bem o suficiente. Rjclaudio msg 01h41min de 7 de abril de 2012 (UTC)
- Citação: Rjclaudio escreveu: «Qnd aparecer um artigo com mais de 190k q esteja perfeitamente resumido / objetivo então concordarei em remover o critério mas até lá ele serve bem o suficiente.» É justamente isso que vai acontecer/aparecer, mais cedo ou mais tarde. Por isso que eu já estou adiantando em reformular/atualizar nossa enciclopédia. Vide na Wiki-en, eles já estão nos 400Kbytes que pode ser considerado longo. E tenho certeza que vai ter artigos prejudicados com essa limitações. Vitor Mazuco Msg 10h29min de 7 de abril de 2012 (UTC)
- Tem algum AD na wiki.en ou wiki.es q tenha mais q 190 kb? Pode indicar alguns? Rjclaudio msg 12h27min de 7 de abril de 2012 (UTC)
- Pois é, mas a forma como a restrição dos 190kb foi justificada no item 8.6 não faz o menor sentido!
- Artigos cujo código wiki tenha tamanho superior a 190kb deverão ser desmembrados, a fim de evitar falhas e demoras de carregamento em determinados servidores.
- Como mostrei acima:
- Desmembrar um artigo não necessariamente melhorará o tempo de carregamento (quando há, a melhora é ínfima)
- O tamanho do código wiki não influencia diretamente a demora no carregamento das páginas a ponto de se poder dizer que a partir de N kb há passam a existir "falhas e demoras".
- Se for para se preocupar com a performance, o melhor é levar em conta a en:Wikipedia:Don't worry about performance#Editors still have a role to play. Para "evitar falhas e demoras" seria muito mais eficiente/útil proibir a alteração do tamanho padrão das miniaturas das imagens, como acontece em alguns dos destacados atualmente, do que considerar que um artigo com 193kb não pode ser destacado. Isso teria impacto tanto na velocidade quanto na acessibilidade das páginas destacadas! É triste que nem sequer mencionem a acessibilidade dos artigos nas regras que destacam os "melhores" da Wikipédia.
- Se for para continuar mencionando o tamanho do código wiki, ainda assim seria muito melhor colocar algo como
- O tamanho do código wiki dos artigos destacados varia entre 10kb e 192kb (dados obtidos em abril de 2012). Os artigos com um tamanho muito acima da média (cerca de 75kb) talvez precisem ser desmembrados, pois podem conter mais informações do que é aceitável em um único artigo.
- Notem que nem mencionei a velocidade no carregamento, pois não há medições indicando que o tamanho do código fonte influencie significativamente. Além disso, seria tapar o sol com a peneira, uma vez que entre as regras está "7.4 – Não há limite máximo de referências" e que as predefinições "cite" estão entre as mais caras para os servidores... Helder 12h31min de 7 de abril de 2012 (UTC)
Mais uma coisa: não faz sentido inverter o sentido da regra e mover parte do conteúdo do artigo para uma predefinição, como fizeram aqui, sob a justificativa de que estão fazendo "cumprir" o critério 8.6: o conteúdo continuará sendo enviado para os leitores, então se antes prejudicava a velocidade, depois continuará igual. Helder 12h51min de 7 de abril de 2012 (UTC)
Sobre os 32k: conforme já disse no tópico Ex-artigo longo, por padrão o aviso sobre os 32k não aparece mais desde 2010 (rev:77148), pois as limitações técnicas dos navegadores antigos (Netscape 4, Opera 6) já não são relevantes, dado que eles não fazem parte da lista de navegadores compatíveis com o MediaWiki (ninguém os utiliza hoje em dia). Os detalhes estão no bugzilla:21911. Helder 15h15min de 7 de abril de 2012 (UTC)
Como podem ver nesta tabela que mostra o número de bytes (em código wiki e em HTML) para cada um dos artigos destacados, há 16 artigos que passam dos 500000 bytes em HTML, um dos quais (Estados Unidos) também passa dos 190000. Campinas também está nessa lista (612141 bytes de HTML), apesar de ter "só" 150220 bytes de código wiki. Há também artigos (como Avril Lavigne e Acordo Ortográfico de 1990), que excedem os 190000 bytes no código wiki mas que estão abaixo dos 500000 bytes de HTML. Esses dados não levam em conta o tamanho das imagens. Helder 17h46min de 7 de abril de 2012 (UTC)
- Discordo da proposta, por tudo o que já disseram acima. Tiago Abreu, TFDA msg 18h09min de 7 de abril de 2012 (UTC)
Que se faça minha as palavras do Helder. Eu sugeria algo intermediário, que ainda obrigue a fazer um artigo objetivo e conciso, mas remova a exigência explícita de tamanho (pelos motivos já discutidos):
8.6 - Artigos demasiadamente longos deverão ser desmembrados, a fim de evitar falhas e demoras no carregamento pelos usuários.
Assim, caso seja possível, e factível, o artigo deve ser resumido e desmembrado; a página de votação para AD parece ser o local adequado para discutir se isso foi ou pode ser feito.
É bom ficar claro que são as imagens, os links, e scripts os fatores que mais pesam no carregamento dos artigos (e não o texto "plano" em si) -- e qualquer um percebe isso ao editar algum artigo: o texto a ser editado carrega rapidamente, e o resto do carregamento da página é o que toma mais tempo. Dentre os principais problemas que podem minimizar a questão do tamanho do artigo destaco:
- a mesma ligação interna repetida várias num mesmo artigo (ou num mesmo parágrafo); links para artigos de datas que nada contribuem para a compreensão do artigo em si; link para datas nas referências; imagens fotográficas em formato png ao invés do jpg (e isso é crítico); imagens panorâmicas, desnecessárias ou que não auxiliam para a compreensão do artigo; links para o artigo de língua portuguesa em ligações externas que estão com título em português. Giro720msg 19h17min de 7 de abril de 2012 (UTC)
- Apoio essa proposta do Giro. É melhor fazer algo intermediário do que restrições apenas. Vitor Mazuco Msg 22h03min de 7 de abril de 2012 (UTC)
- O que eu não gosto nesse texto é que "desmembrar um artigo" não garante qualquer redução nas falhas (que falhas?) nem no tempo de carregamento (cadê as medições de desempenho que justificariam isso? Se não há dados, não se preocupe com a performance ). Então "a fim de evitar falhas e demoras no carregamento" serve como explicação para o desmembramento. Isso só deve ser feito se o artigo for "demasiadamente longo", mas isso não tem um significado absoluto/exato, pois é algo que varia caso a caso, já que deve levar em conta o que há para ser dito sobre cada assunto. Helder 18h15min de 9 de abril de 2012 (UTC)
E seguindo a lógica do Helder, o que demora no carregamento não é o tamanho em código Wiki, mas sim o de HTML. O que pode ser desmembrados pra que possam diminuir seu tempo de carregamento. Vitor Mazuco Msg 22h08min de 7 de abril de 2012 (UTC)
- Desta forma, não seria melhor haver um guia com estas características dos artigos que tornam o tamanho pesado mencionadas pelo Giro720? Realmente, se os editores evitassem "enfeitar" os artigos (um layout bom é aceitável, agora há páginas que parecem desenhos) com ligações internas para informações comuns, além de imagens em tamanhos enormes (quando 200px é o padrão), dentre outras coisas. — Lucas Rossi Discussão 22h42min de 7 de abril de 2012 (UTC)
Duas perguntas:1) Como reduzir o tempo de carregamento destes artigos? Pelo que calculei na tabela indicada pelo Helder alguns artigos tem uma relação de 1 para 8 de código wiki / HTML enquanto a média é de 1 para 2,6. Se for possível, seria bom incorporar as predefinições mais utilizadas alguma boa prática mais econômica. 2) Embora considere que as votações de EAD são o local indicado para avaliar se um artigo está longo demais, pergunto: qual o artigo que motivou a presente proposta, isto é, precisa ser expandido mas o requisito técnico impede que seja feito? Abs, OTAVIO1981 (discussão) 11h46min de 9 de abril de 2012 (UTC)
- Imagino que a melhora na velocidade de carramento estava sendo pensada no sentido de beneficiar os leitores, que em sua maioria não são "usuários" (registrados). Para os usuários registrados, um fator decisivo no tempo de carregamento das páginas é o conjunto de escolhas que fez em suas preferências, já que algumas delas forçam o software ignorar a cópia que fica guardada no cache do servidor e, isso toma mais tempo do que se conseguiria economizar com qualquer "desmembramento razoável" do artigo. Ver também o bug 19262 (páginas com um grande número de predefinições demoram muito para os usuários registrados).
- No que diz respeito ao processamento realizado no lado do servidor, o tempo gasto para gerar a página aparece no código fonte em HTML, em um comentário do tipo
- <!-- Served by mw33 in 25.770 secs. --> (exemplo tirado do artigo Born This Way)
- Deduzo que quanto mais perto dos limites das predefinições uma página estiver, maior será o seu tempo de processamento no lado do servidor. No link anterior há algumas dicas (técnicas/para quem faz manutenção das predefinições) de como evitar chegar perto dos limites. Os limites também são mostrados no HTML das páginas, em um trecho como este (também do artigo Born This Way, que pelo visto ainda está bem longe de chegar nos limites):
- <!--
- NewPP limit report
- Preprocessor node count: 162522/1000000
- Post-expand include size: 790204/2048000 bytes
- Template argument size: 320800/2048000 bytes
- Expensive parser function count: 2/500
- -->
- O uso das predefinições do tipo "cite" também pode aumentar a lerdeza. Mas isso infelizmente não tem muito jeito por enquanto. Pode ser que um dia criem uma extensão que faça o trabalho que hoje é feito por essas predefinições (bug 26786), ou talvez quando as predefinições passarem a ser programadas em Lua (ver detalhes) a eficiência aumente o suficiente para que elas influenciem menos a performance das páginas.
- Fora isso, tem a questão das imagens em miniatura, cujo tamanho padrão não deveria ser alterado (exceto se houver algum bom motivo), tanto por questão de eficiência quanto por causa da acessibilidade. Não tenho dados em relação a isso, mas não me espantaria se as imagens fizessem mais diferença do que o HTML e os possíveis desmembramentos dos artigos.
- Uma foram de reduzir o tamanho do HTML é priorizar o uso de classes CSS (como indicado no "guia de acessibilidade") em vez de repetir a mesma formatação em zilhões de linhas consecutivas. Para ver péssimos exemplos, confiram as tabelas dos artigos sobre o carnaval, como GRES Unidos da Tijuca (não deixe de olhar o código fonte!). Além de aumentar o tamanho da página sem trazer qualquer vantagem à enciclopédia, a maioria dessas tabelas não deve nem cumprir os requerimentos básicos de acessibilidade como "o uso de um contraste adequado entre a cor do texto e a do fundo". Helder 18h15min de 9 de abril de 2012 (UTC)
- Encontrei mais exemplos de subutilização de CSS em um tópico criado no café dos programadores: Predefinição:Lista de faixas e seus 4211 afluentes.
- E sobre essas tabelas em que as linhas tem cores alternadas, ver
- Helder 12h11min de 3 de maio de 2012 (UTC)
Discordo Não pelos motivos técnicos apresentados, mas porque estamos a fazer enciclopédia - não obras de referência, nem teses... Vamos ao dicionário e, onde usamos a palavra artigo para definir nossas páginas, em verdade estamos a usar a acepção deste termo que é sinônima de verbete (palavra que é já um diminutivo!): "Na organização dum dicionário, glossário, ou enciclopédia, o conjunto das acepções e exemplos respeitantes a um vocábulo. [Sin., ant., nesta acepç.: artigo.] "
Se era algo "ant" (antigo), modernizamos; e, desavisados, imaginam que artigo é algo prolixo, enfadonho, que "esgote" um tema!
Este, a meu ver, um dos grandes desvios que assistimos aqui; especialmente lá, nas EADs! Quem as frequenta sabe de votos onde o editor declarou, sem pudor algum: "o tema pode ser ampliado"... Como se não estivéssemos aqui para fazer enciclopédia...
Vou adiante, citar um exemplo. Tenho aqui um manual médico, editado pelo MS do Brasil; são verbetes de doenças infecciosas. Aqui temos muito, mas muito mesmo, mais a falar da raiva do que lá; mas, o que é bastante para orientar profissionais de saúde, sequer seria considerado bom numa votação de EAD... (por isso nem cogitei em levar).
Desviamo-nos do rumo, do propósito mesmo. A impressão que me fica, com o devido perdão, é de que o Mazuco - e outros com tais opiniões - jamais viram uma enciclopédia "de verdade"! he, he... Ao invés de artigo=verbete, escrevemos laudas, usamos e abusamos de encheção de linguiça (tenho aqui uns "destacados" que são mesmo exemplo disso - e faço o mea culpa por ter produzido alguns, levado por esta "sanha" de escrita infindável)...
Sei, contudo, que pude "resistir" a ela em alguns casos, e fui bem aceito (claro, sempre com a oposição dos que não compreendem o que é um verbete).
Este o motivo, Mazuco, pelo qual sou contra tua proposta. O limite máximo é extenso, excede em muito aquilo que de ordinário encontramos nas enciclopédias "reais", é mais que suficiente para que se fale sobre algo, sem que nada fique de fora.
Se é verdade que não somos de papel e por isso podemos nos estender ad infinitum, esta afirmação em si se contradiz, quando sabemos que o "infinito" se resolve com algo chamado hipertexto. André Koehne (discussão) 12h32min de 3 de maio de 2012 (UTC)
- Acho que a discussão central aqui não é essa. Todos concordam que deve haver um limite de tamanho para o texto do artigo. Só não há consenso se limitar o tamanho do artigo em kbs equivale a limitar o tamanho do texto. Dá para fazer textos mt pequenos com mts kbs, e textos mt grandes com poucos kbs.
- Um lado prefere os kbs, pela história, por ser algo mais objetivo, e por ser razoavelmente bem para os ADs. O outro lado prefere uma análise mais subjetiva, sendo avaliado na votação se o texto está extenso de mais ou não, e não por um número mágico, ainda mais um número mágico q não reflete exatamente o quão grande o artigo é. Rjclaudio msg 12h41min de 3 de maio de 2012 (UTC)
- Continua, então, o problema... se não for para limitar em kb, vai se limitar em quê? Votações não podem se pautar em crivos subjetivos! Já é uma zona com as normativas objetivas, imagine se deixarmos isso para cada votante! André Koehne (discussão) 12h55min de 3 de maio de 2012 (UTC)
- Pois que não se usem votações então (se elas tem que ser objetivas), já que os "melhores artigos da Wikipédia" são determinados pela noção subjetiva do que é "melhor". Qual seria a lógica de se tentar avaliar objetivamente algo que é, por definição, subjetivo?
- Esses "números mágicos" realmente viram mania por aqui (N bytes de código wiki definem se um artigo é "longo", N edições definem se alguém está "apto" para pedir ferramentas administrativas, N minutos garantiriam que textos ruins não fossem mostrado aos leitores...). Helder 13h31min de 3 de maio de 2012 (UTC)
- Continua, então, o problema... se não for para limitar em kb, vai se limitar em quê? Votações não podem se pautar em crivos subjetivos! Já é uma zona com as normativas objetivas, imagine se deixarmos isso para cada votante! André Koehne (discussão) 12h55min de 3 de maio de 2012 (UTC)
- O problema de não haver um "número mágico" é que é demasiado frequente que na prática não se possa evocar bom senso como argumento. Uma caricatura disso é que atualmente há uma EAD dum artigo com quase 300k. Concordo que o nº de bytes não é um critério ideal, nomeadamente pelas razões apresentadas pelo Helder, mas sem ser esse só me ocorre outro: o nº de páginas da versão em PDF produzida pelo link respetivo.
- Apesar disso me complicar de sobremaneira a vida caso queira levar a destaque mais algum artigo sobre cidades ou países, em teoria acho que o limite devia ser ainda menor, pois não é nada prático ler um artigo com 190k. Se o critério fosse tempo de carregamento, tenho a sensação que o limite tinha que ficar abaixo de 100k para a maior parte dos casos (admitindo que o nº de bytes tem uma relação direta, ainda que variável, com esse tempo).
- Mas como o André aflora no que escreveu, creio que o tamanho dos artigos destacados tem muito a ver com os critérios (escritos, como no caso de países e cidades, ou não) e/ou a obsessão com "completitude" que artigos destacados e até bons que muito editores têm. E isso é algo que é contagioso... E o pior é que (falo por mim) muitas das secções cheias de dados (prinicpalmente estatísticos) são as partes mais complicadas e aborrecidas de escrever e duvido que interessem a muito mais consulentes do que aqueles que usam os artigos como uma base de dados. Já para não falar na parcialidade ou peso indevido disfarçada e involuntária que a obrigatoriedade de certas secções acarreta, pois se se se encontram poucas fontes, essas secções são escritas com aquilo que se descobre que em muitos casos pode ser pouco relevante.
- Apesar disso, talvez fosse interessante ponderar que as secções de referências, bibliografia e iw não contassem para a avaliação da dimensão máxima do artigo, pois não é raro que essas secções sejam uma parte considerável do tamanho em bytes (pelo menos comigo, que preencho muitos campos das predefs citar, coloco versões arquivadas com urls quilométricos em quase todos os citar web e faço questão de incluir mais do que uma fonte para um trecho quando me parece que, apesar de bastar uma, as outras podem ser importantes para quem queira expandir os seus conhecimentos). --Stegop (discussão) 20h07min de 3 de maio de 2012 (UTC)
Apoio Stegop, acho que não deveria contar as ref, interwikis, categorias, etc como conteúdo do artigo, nem pra colocar como critérios. Acho que isso deve ser desconsiderado. Vitor Mazuco Msg 00h48min de 15 de maio de 2012 (UTC)
- A título de curiosidade, mas talvez relevante: no último artigo que coloquei em EAD (Bilbau), os bytes dessas partes são praticamente metade do total do artigo, apesar de algumas das tabelas estarem em predefs. Possivelmente se isso não acontecesse, o "corpo de texto" ocuparia menos de metade do nº de bytes total. --Stegop (discussão) 01h18min de 15 de maio de 2012 (UTC)