Insights / Artigos técnicos

Como operar um blog multilíngue com Sveltia CMS

Um fluxo prático para editar artigos fonte em japonês no Sveltia CMS, gerar PRs de tradução com GitHub Actions e GitHub Copilot, e publicar páginas estáticas localizadas com benefícios para busca em relação à tradução apenas na UI.

  • Tecnologia
  • GitHub Copilot
  • i18n
  • CMS
  • SEO
Como operar um blog multilíngue com Sveltia CMS
Sumário
  1. Estrutura
  2. Quando tradução na UI basta
  3. Benefícios para mecanismos de busca
  4. 1. Crawlers acessam cada idioma diretamente
  5. 2. Metadados são localizados
  6. 3. hreflang mostra a relação entre idiomas
  7. 4. RSS e sitemap ficam multilíngues
  8. Papel do Sveltia CMS
  9. Regras para Copilot
  10. Lições dos PRs
  11. Referências
  12. Resumo

O conteúdo da Acecore é editado principalmente em japonês, mas o blog é publicado em 9 idiomas. O ponto principal é que traduzir a tela e publicar conteúdo multilíngue são coisas diferentes.

Tradução do navegador ajuda o leitor naquele momento. Mas ela não cria URLs localizadas, metadados, RSS, sitemap, dados estruturados ou hreflang.

Se o objetivo inclui busca orgânica, a tradução deve ser parte do processo de publicação.

Estrutura

  • Fonte em japonês: src/content/blog/{slug}.md
  • Traduções: src/content/blog/{locale}/{slug}.md
  • URLs: /blog/{slug}/, /en/blog/{slug}/, /pt/blog/{slug}/
  • Edição: Sveltia CMS
  • Tradução: PRs do GitHub Copilot
  • Publicação: build e revisão

Sveltia CMS edita a fonte japonesa. As traduções ficam em PRs para que o time consiga revisar, testar e reverter.

Quando tradução na UI basta

Ela funciona bem para leitura interna, navegação ocasional, telas administrativas e páginas que não buscam tráfego orgânico.

O custo operacional é baixo, porque não há arquivos traduzidos. Mas também não há páginas por idioma para indexação.

Benefícios para mecanismos de busca

Buscadores, previews sociais e leitores RSS lidam com URLs e HTML.

Se só existe a página japonesa, o navegador pode traduzi-la para o usuário, mas title, description, RSS e sitemap continuam ligados à página japonesa.

Com páginas estáticas, cada idioma tem seu próprio URL.

/blog/copilot-translation-pipeline/
/en/blog/copilot-translation-pipeline/
/pt/blog/copilot-translation-pipeline/
/fr/blog/copilot-translation-pipeline/

1. Crawlers acessam cada idioma diretamente

Google processa JavaScript, mas a documentação também fala das limitações e recomenda renderização estática ou server-side como soluções mais estáveis. Para outros crawlers e leitores RSS, HTML inicial traduzido é ainda mais importante.

2. Metadados são localizados

O frontmatter também é traduzido:

title: "Como operar um blog multilíngue com Sveltia CMS"
description: "Fluxo com Sveltia CMS e GitHub Copilot para PRs de tradução."

Isso afeta resultados de busca, OGP, cards relacionados e RSS.

3. hreflang mostra a relação entre idiomas

Quando idiomas têm URLs diferentes, o Google recomenda hreflang. Com tradução apenas na UI, não há URL de outro idioma para conectar.

4. RSS e sitemap ficam multilíngues

Arquivos traduzidos permitem gerar /pt/rss.xml e URLs localizadas no sitemap.

Papel do Sveltia CMS

Sveltia CMS não traduz. Ele mantém simples a edição do conteúdo japonês:

  • artigos japoneses
  • autores
  • tags
  • JSON fonte em japonês
  • imagens
  • frontmatter como data, FAQ e links

A configuração do CMS está em Guia de instalação do Sveltia CMS.

Regras para Copilot

O PR de tradução deve preservar identificadores e localizar apenas texto.

Keep:

- slug
- image path
- author id
- tag ids
- external URLs
- code blocks

Localize:

- title
- description
- FAQ
- body text
- internal blog URLs when locale-specific URLs exist

Lições dos PRs

  • Artigos antigos ainda mencionavam Pages CMS mesmo após a migração para Sveltia CMS.
  • Se date fica antigo, o artigo não aparece no topo do blog.
  • O slug deve continuar igual entre idiomas.
  • Links internos devem apontar para o locale do leitor.
  • IA acelera a tradução, mas revisão continua obrigatória.

Referências

Resumo

Tradução na UI ajuda a ler. Páginas estáticas localizadas transformam cada idioma em conteúdo real do site.

Sveltia CMS cuida do japonês, GitHub Copilot cria PRs de tradução e Astro build valida o resultado antes da publicação.

Translation Workflow

Fluxo do Sveltia CMS até o PR de tradução

O japonês permanece como source of truth, e a tradução é separada no fluxo de PR do GitHub.

  1. Editar apenas o japonês

    Atualizar `src/content/blog/{slug}.md` pelo Sveltia CMS ou Markdown.

  2. Detectar o commit do CMS

    Usar o prefix `cms:` e o path alterado como contrato do lado do GitHub Actions.

  3. Criar um PR de tradução

    Fornecer ao Copilot source path, locale e regras de tradução para gerar os arquivos traduzidos.

  4. Aplicar após o build

    Integrar ao main somente PRs que passem por Astro build, Pagefind e verificação de links.

Diferença entre tradução da interface e geração de páginas específicas por idioma

Tradução da interface

  • O navegador ou widget de tradução do usuário traduz durante a exibição
  • URL, title, description e OGP tendem a permanecer no idioma de origem
  • É difícil publicar páginas específicas por idioma em sitemap, RSS e hreflang
  • O texto de URLs compartilhadas e resultados de pesquisa tende ao idioma original

Páginas multilíngues estáticas

  • É possível publicar URLs por idioma como `/{locale}/blog/{slug}/`
  • title, description, corpo, FAQ e dados estruturados podem existir por idioma
  • hreflang informa aos mecanismos de pesquisa a relação entre as versões linguísticas
  • RSS, sitemap, links internos e Search Console podem ser tratados por idioma

Decisões para a adoção

  • Tratar o artigo em japonês como fonte da tradução
  • Manter o slug dos arquivos traduzidos igual ao do artigo japonês
  • Fixar as condições de início do workflow, como commits `cms:`
  • Não quebrar URLs, path de imagens, blocos de código nem IDs de tags na tradução
  • Verificar no build a saída de hreflang, canonical, RSS e sitemap

Perguntas frequentes

Tradução na UI é suficiente?

É útil para leitura, mas não cria ativos por idioma para SEO, RSS, sitemap e links internos. Para isso, é melhor publicar páginas localizadas reais.

Tradução com IA prejudica SEO?

O risco não é usar IA; é publicar muitas páginas sem valor. Termos, fatos, links e naturalidade precisam de revisão.

Páginas traduzidas são duplicadas?

Segundo a documentação do Google, páginas localizadas só são duplicadas quando o conteúdo principal não está traduzido. Use hreflang para conectar as variantes.