I Built Multilingual Blog Publishing Into My Personal Site — Here's How the Stack Works

As of today, every post on mynameisfeng.com publishes across 23+ languages from a single Next.js codebase. No separate sites. No translation agency. No copy-paste.

This post is the technical story of how I built it — and the one architectural decision that made everything else easier.

Why Multilingual Publishing, and Why Now

I write for developers and founders. But the most interesting builders I know aren't all in Silicon Valley. They're in Tokyo, São Paulo, Berlin, Seoul, and dozens of other cities where English isn't the first language.

For the first year of this blog, I was implicitly writing only for an English-speaking audience. That bothered me. Not just because it limits reach — but because a blog about building globally should work globally.

So I built the i18n pipeline. Here's what the final architecture looks like.

The Stack

Routing: next-intl

I use next-intl for locale-aware routing in Next.js 14+. Every page lives at a locale-prefixed path: /en/blog/post-slug, /ja/blog/post-slug, /zh-CN/blog/post-slug, and so on. The locale is resolved from the URL, not from browser detection — which makes it predictable for SEO.

The 23+ supported locales are declared in a single config file. Adding a new language is one line.

Translation Pipeline: Claude API

This is where most custom i18n setups fall apart. Machine translation (Google Translate, DeepL) produces technically correct text that feels like nobody wrote it. Particularly bad for technical writing, where word choice carries real meaning.

My pipeline sends each post's markdown to Claude Sonnet with a structured prompt:

• Preserve all markdown formatting, code blocks, and heading structure
• Match the register of the original (conversational technical writing, not academic prose)
• Flag any terms that should stay in English (API, Next.js, LLM, etc.)
• For Chinese: use simplified or traditional depending on locale

The output is reviewed for the high-traffic languages (zh-CN, ja, es) and auto-published for the long tail. Not perfect — but meaningfully better than raw machine translation.

Content Storage: MDX files + locale map

Each post is an MDX file. The locale-specific translation lives alongside it in a locales/ directory. The file naming convention: post-slug.en.mdx, post-slug.ja.mdx, etc.

If a translation doesn't exist yet, the page falls back to English — a single config flag controls this behavior. No 404s.

SEO: hreflang tags + sitemap generation

Every page generates hreflang alternate links for all available locales. The sitemap includes every locale variant. This is the part most people skip — and the part that actually matters for search.

If you ship multilingual without hreflang, Google has no idea which version to serve to which audience. You'll rank fine in English and nowhere else.

The One Decision That Made Everything Easier

I initially tried to store translations in a database, with a CMS-style workflow. It was a mistake.

Files are better. They version with the post. They're diffable. You can grep them. Rollbacks are a git revert. The translation pipeline writes directly to the filesystem; the deployment pipeline picks them up.

Simple systems win.

What's Live

As of May 11, 2026:

• 23+ languages supported
• All new posts go through the translation pipeline automatically
• Existing posts are being backfilled in batches
• High-traffic locales (zh-CN, ja, es, pt-BR, de, fr, ko) are prioritized

If you're reading this in Japanese or Portuguese — hi. The pipeline worked.

Is This Worth Building for Your Blog?

Honestly, it depends. If you're a solo founder writing 1 post a week and your audience is purely English-speaking, this is overkill. The Claude API costs are real, and so is the maintenance surface.

But if you're building a personal brand that you want to survive past your current market, or if your product targets non-English markets, then yes — the compounding SEO value alone is worth it. Long-tail keyword volume in Japanese and Spanish is enormous, and almost nobody is competing in those niches in 2026.

The full i18n Next.js setup is something I documented in detail in an earlier post. If you want to dig into the implementation specifics — the next-intl config, the Claude prompts, the hreflang generation — that's a good starting point.

For now: the site is live, the pipeline runs, and the blog is finally as global as the audience I'm writing for.