Valeu pelo comentário, é o tipo de crítica que eu queria receber aqui. Vou por partes:

Sobre ser um wrapper em cima de outros serviços — procede, sim. É um agregador por definição; o valor que tentei colocar não está em ser uma fonte de dado nova, mas na camada de composição (dedup, fallback, categorização).

Sobre separar a lógica num backend dedicado com deploy gratuito — isso já existe no projeto, é justamente o item 1 do post: o Cloudflare Worker. Ele roda no plano gratuito da Cloudflare e faz exatamente isso, busca e parseia os feeds no servidor. Deixei ele como camada opcional (não obrigatória) porque queria que o projeto continuasse rodando com zero configuração pra quem só quiser subir os arquivos estáticos — o Worker é o upgrade de quem precisa de mais escala, não um requisito.

Sobre ser inseguro por rodar do lado do front-end — aqui eu preciso que você seja mais específico, porque não estou enxergando qual vulnerabilidade concreta isso introduz. Não tem segredo/API key exposta (as APIs usadas são públicas e sem chave), não tem dado de usuário, não tem autenticação. Rodar a busca no navegador tem desvantagem real (a que você já citou, cota/confiabilidade — resolvida pelo Worker), mas eu não vejo isso como "inseguro" sem um vetor de ataque concreto por trás. Qual seria o risco que você tem em mente?

Sobre não precisar de API de tradução, usar o tradutor do navegador — esse é o ponto que mais me fez pensar. É genuinamente uma alternativa mais simples, e reduz complexidade de verdade. A razão de eu ter optado por uma tradução embutida no próprio site foi querer que funcionasse com um clique só, sem depender de o visitante ter o tradutor do navegador configurado (nem todo mundo usa Chrome, ou tem a opção ativada) — mas reconheço que isso é uma escolha de UX, não uma necessidade técnica, e trocar por confiar no navegador do usuário reduziria bastante a superfície da aplicação. Vou pensar nisso com calma.