How to Run a Multilingual Blog with Sveltia CMS

Once a site has Sveltia CMS, an AI contact chat, and service-to-contact flows, the next operational question is multilingual publishing.

This site is edited primarily in Japanese, but the public blog is available in nine languages. The important distinction is that translating text in the UI and publishing real localized pages are different things.

Browser translation, extensions, and translation widgets are helpful when a reader wants to understand the current page. They do not automatically create localized URLs, localized metadata, RSS feeds, sitemap entries, hreflang clusters, or locale-aware internal links.

This article describes a practical workflow: edit the Japanese source in Sveltia CMS, create translation pull requests with GitHub Actions and GitHub Copilot, and publish static localized HTML that search engines can crawl directly.

The Short Version

If multilingual content is part of your search strategy, treat translation as content generation before publishing, not as a display-time UI feature.

The site uses this structure:

• Japanese source: src/content/blog/{slug}.md
• Translated content: src/content/blog/{locale}/{slug}.md
• Public URLs: /blog/{slug}/, /en/blog/{slug}/, /zh-cn/blog/{slug}/, and so on
• Source of truth: Japanese Markdown
• Translation work: GitHub Copilot PRs
• Publishing gate: Astro build and review

Sveltia CMS is the editing surface for the Japanese source. Translation is handled in GitHub so every localized change is reviewable.

Where UI Translation Works

UI translation is not wrong. It is enough for many cases:

• Internal reading
• One-off browsing by overseas users
• Admin or help screens
• Pages that do not target search traffic
• Content where translation quality is not part of the publishing workflow

In that model, translation happens in the reader’s environment. The site owner does not store translated files.

That is lightweight, but it does not create multilingual content assets.

Where UI Translation Falls Short

For blog articles and service pages, search engines and social previews mostly work with URLs and HTML.

If only the Japanese page exists and English is produced by a browser translator, the indexable URL, title, description, structured data, RSS item, and sitemap entry still point to the Japanese page.

The reader may understand the page, but the site has not published an English page.

With static localized pages, each language has its own route:

/blog/copilot-translation-pipeline/
/en/blog/copilot-translation-pipeline/
/zh-cn/blog/copilot-translation-pipeline/
/es/blog/copilot-translation-pipeline/
/pt/blog/copilot-translation-pipeline/
/fr/blog/copilot-translation-pipeline/
/ko/blog/copilot-translation-pipeline/
/de/blog/copilot-translation-pipeline/
/ru/blog/copilot-translation-pipeline/

Those pages can each carry localized titles, descriptions, body text, FAQ content, JSON-LD, and internal links.

Search Benefits

The core benefit is not that static translation is more fashionable. It is that the signals sent to crawlers are clearer.

1. Crawlers Can Fetch Each Language URL

Google can process JavaScript, but Google Search Central still documents limitations around JavaScript and recommends server-side rendering, static rendering, or hydration over dynamic rendering workarounds.

Other crawlers, RSS readers, link preview tools, and search integrations may be less capable than Googlebot. Putting translated text in the initial HTML is the robust option.

2. Metadata Can Be Localized

Search snippets and social previews depend on more than body text.

With localized Markdown, the frontmatter can be translated too:

title: 'How to Run a Multilingual Blog with Sveltia CMS'
description: 'A workflow for editing Japanese source articles and publishing localized static pages.'

That affects search results, OGP previews, related cards, and RSS.

3. hreflang Can Connect Language Variants

Google recommends using hreflang when different URLs serve different languages or regions.

This site outputs alternate URLs from the layout and sitemap:

<link
  rel="alternate"
  hreflang="en"
  href="https://acecore.net/en/blog/copilot-translation-pipeline/"
/>

With UI-only translation, there is no English URL to connect.

4. RSS and Sitemaps Become Language-Aware

Static translated files allow the site to publish feeds such as /en/rss.xml and /fr/rss.xml, and to include localized URLs in the sitemap.

That is useful not only for Google, but also for feed readers, search indexes, and external services.

5. Internal Links Stay in the Reader’s Locale

Multilingual sites often break when a translated article links back to the source language.

Translation PRs should preserve the user’s locale where possible:

• /blog/foo/ becomes /en/blog/foo/ in the English article
• External URLs stay unchanged
• Image paths stay unchanged
• Tag IDs stay unchanged
• Code blocks are not casually rewritten

What Sveltia CMS Owns

Sveltia CMS is not the translation engine in this workflow. It owns the Japanese source editing experience.

Use it for:

• Japanese blog articles
• Authors
• Tags
• Japanese source JSON
• Uploaded images
• Frontmatter such as date, FAQ, related links, and descriptions

The CMS setup itself is covered in Sveltia CMS Setup Guide. This article focuses on what happens after that: translation PRs.

Why Translation Belongs in Pull Requests

Putting every language into the CMS can work if editors actively maintain every locale. For a small team that writes in Japanese, it makes the CMS heavy and easy to misuse.

Acecore splits responsibilities:

• Sveltia CMS updates the Japanese source
• GitHub Actions detects CMS commits or changed paths
• GitHub Copilot creates translation PRs
• Pull requests make translation diffs reviewable
• Astro build catches broken routes, frontmatter, and links

That gives you history, review, rollback, and CI around translation work.

Commit Subjects as Workflow Contracts

The translation workflow should not run for every Markdown change.

Date-only fixes, tag tweaks, and link corrections should not necessarily create eight translation PRs. Use commit subjects as an explicit contract:

cms: create blog "new-article-slug"
cms: update blog "copilot-translation-pipeline"

This makes it clear when translation automation should run.

Rules Passed to Copilot

Do not ask the agent to “just translate the article.” The task needs explicit constraints:

Translate the Japanese source article into the target locale.

Keep:

- slug
- image path
- author id
- tag ids
- internal code tokens
- external URLs
- code blocks unless comments are natural language

Localize:

- title
- description
- callout
- FAQ
- link card title and description
- body text
- internal blog URLs when locale-specific URLs exist

The distinction matters because Markdown mixes prose, frontmatter, URLs, images, tags, and code in one file.

Lessons From the Recent PRs

There were a few practical lessons worth documenting.

Old CMS Names Linger

The implementation moved to Sveltia CMS, but older articles still mentioned Pages CMS. When a content tool changes, update the related articles, screenshots, alt text, and internal link labels together.

Date Controls Blog Visibility

The article can be rewritten completely and still not appear on the blog top if date remains old. In this site, blog lists sort by date, while lastUpdated is only update metadata.

Slugs Must Stay Stable

Translated files should share the base slug:

src/content/blog/copilot-translation-pipeline.md
src/content/blog/en/copilot-translation-pipeline.md
src/content/blog/fr/copilot-translation-pipeline.md

That keeps locale resolution simple.

Generated Content Still Needs Review

Google’s spam policies focus on manipulative or low-value mass generation. AI translation is useful, but each localized article should still be reviewed for terminology, links, facts, and usefulness.

References

• Google Search Central: Localized Versions of your Pages
• Google Search Central: Managing Multi-Regional and Multilingual Sites
• Google Search Central: JavaScript SEO Basics
• Google Search Central: Dynamic Rendering
• Google Search Central: Spam Policies
• Sveltia CMS Setup Guide
• Astro Multilingual Architecture

Summary

UI translation helps readers understand a page.

Localized static pages help the site publish language-specific URLs, metadata, internal links, RSS feeds, sitemaps, and hreflang relationships.

For a small team, the clean split is: edit Japanese in Sveltia CMS, generate translations through GitHub Copilot PRs, and only publish translated files after build and review.

The real work is not just translation. It is deciding how translated content lives inside the site architecture.