A Wiki Of Fire And Ice

Como estruturar e manter uma wiki de conteúdo especializado sobre temas de fantasia

Manter uma wiki focada em universos de fantasia como aqueles que mesclam elementos de fogo e gelo exige planejamento técnico e editorial desde o início. A maioria dos projetos nesse nicho começa bem-intencionada e termina abandonada porque ninguém previu o volume de informações que se acumula. Um artigo principal pode se ramificar em dezenas de subpáginas em questão de semanas. O que define esse tipo de projeto é a necessidade de gerenciar múltiplas linhas narrativas, famílias de personagens, cronologias sobrepostas e mapas que precisam ser referenciados consistentemente. A estrutura padrão de plataformas como MediaWiki ou DokuWiki funciona, mas requer personalização séria. Plugins de navegação por padrão são insuficientes para navegar entre dezenas de casas nobres, regiões geográficas e eventos históricos fictícios. Eu configurei uma wiki desse tipo para uma comunidade de fãs que acabou crescendo para mais de 3.200 artigos. O problema que ninguém prevê é a consistência de nomenclatura. No terceiro mês, percebemos que o mesmo personagem aparecia com três grafias diferentes em páginas diferentes, e os links internos estavam quebrados em cerca de 40% das referências cruzadas. A solução que funcionou foi criar um script Python que varre toda a base, detecta variações de nome usando correspondência fuzzy, gera um relatório de conflitos e propõe paginações massivas via API. Levei dois dias para escrever o script, mas evitou meses de edição manual. O script roda mensalmente como parte da manutenção do sistema.

Decisões técnicas que fazem diferença

A escolha da plataforma importa menos do que a configuração inicial. MediaWiki com Extension:CirrusSearch oferece melkor melhor se você espera mais de mil artigos, mas a curvatura de aprendizado é real. Para projetos menores, DokuWiki com o plugin de tree navigation resolve rápido. O ponto crucial é decidir desde o dia um sobre a taxonomia. Você vai classificar por tipo de conteúdo, por universo canônico, por linha temporal ou por relevância temática? Misturar os critérios gera uma estrutura intransitável em poucos meses. Eu recomendo começar com uma taxonomia horizontal simples: artigo de personagem, artigo de local, artigo de evento, artigo de item, e página de desambiguação. Nada mais além disso no início. Categorias aninhadas demais criam um fenômeno chamado category sprawl, onde um único artigo pertence a doze categorias diferentes e a navegação vira um labirinto. Isso acontece porque editores adicionam categorias conforme o conteúdo cresce, sem revisar as existentes. Configurei um limite de no máximo cinco categorias por página e ativei o script de verificação automática que bloqueia edições que excedam o teto.

Pitfalls comuns e como evitar

O erro mais frequente em wikis de fantasia é a falta de critérios de notoriedade claros. Sem regras objetivas sobre o que pode ou não ter artigo próprio, a página enche de conteúdo irrelevante rapidamente. Edições de teorias de fãs não verificadas, listas de ordens secundárias, e personagens que aparecem em uma única cena acabam dominando a estrutura. Estabeleça diretamente: personagem precisa ter pelo menos uma menção substantiva em fonte canônica, evento precisa impactar a trama principal, e local precisa ter relevância narrativa documentada. Links vermelhos não são problemas a resolver urgentemente. Outro problema que vejo repetidamente é a ausência de política de citação. Artigo sem fontes em wikis de fantasia tende a se tornar terreno fértil para informação não verificada. Não precisa ser acadêmico, mas cada afirmação factual precisa de referência. Eu implementei um sistema simples onde seções sem fonte são marcadas automaticamente com uma tag visível, e artigos com mais de trinta por cento do conteúdo sem referência entram em lista de monitoramento. Isso reduziu em cerca de oitenta por cento as edições problemáticas no meu projeto.

Infraestrutura e custos

Uma wiki com mil artigos bem estruturados roda confortavelmente em um VPS de quatro GB de RAM e dois núcleos. Custa entre dez e quinze dólares por mês em hospedagem básica. O gargalo real não é o servidor, é a manutenção editorial. Wiki sem gestão ativa deleta sozinha em seis a oito meses. Editores saem, conteúdo fica desatualizado, links quebram. A solução prática é estabelecer um conselho de editores rotativo com responsabilidades definidas: um cuida da revisão de novas páginas, outro da manutenção de links, outro da padronização de formatação. Rodízio mensal evita acúmulo de poder e burnout. Backup deve ser configurado diariamente com retenção de trinta dias. Use scripts que exportam tanto o banco de dados quanto os arquivos de upload. Teste a restauração pelo menos uma vez por trimestre. Eu perdi uma semana de trabalho em 2023 porque o backup automático falhou silenciosamente devido a uma mudança de permissões no servidor. Aprendido.

Quando não fazer isso

Se o seu objetivo é apenas organizar informação sobre uma obra específica para uso próprio ou de um grupo pequeno, uma wiki completa é overkill. Um documento bem estruturado em Obsidian ou Notion resolve o mesmo problema com um décimo do esforço. Wiki vale a pena quando há colaboração de múltiplos editores, quando o conteúdo cresce além de cem artigos, ou quando você precisa de hiperligação orgânica entre tópicos que um documento linear não oferece. Fora desses cenários, a complexidade administrativa consome mais tempo do que o conteúdo gera em valor.