The Language Switcher Just Prefixes /en, It Doesn't Translate Slugs

Plenty of bilingual sites keep a slug-mapping table to translate URLs between languages — a database entry saying /blog/pindah-ke-astro in Indonesian equals /en/blog/moving-to-astro in English. This site doesn’t have anything like that, and that’s a deliberate decision, not a limitation.

How it works

localePath and alternateLocalePath in src/lib/i18n-url.ts just prefix or strip /en from the current path. That’s it — no lookup table, no query. Combined with Astro’s built-in i18n routing (defaultLocale: 'id', prefixDefaultLocale: false), that’s the entire language-switching logic on this site. A dozen-odd lines, total.

The consequence

Every content collection entry has to use the exact same filename in the id/ and en/ folders. src/content/blog/id/pindah-ke-astro.md and src/content/blog/en/pindah-ke-astro.md have to match, or the switcher links straight to a 404. I’ve felt this firsthand: while writing one of the npm-incident posts, I got the idea to rename the English file to something more descriptive, forgetting that would misalign it against the Indonesian version. The language switcher 404’d the moment I tested it, and it took me a minute to figure out why — not a bug in the code, just a naming discipline I’d broken myself.

Why I still accept that trade-off

Simplicity. No separate mapping table to maintain, no database query, no API call just to figure out the equivalent URL. Just filename discipline, and that’s something I can enforce myself without extra tooling — no dedicated CI check for this, just habit.

The downside I’m aware of and haven’t fixed

If I ever want a different English slug for local SEO keywords — Indonesian slug using an Indonesian term, English slug using the term people actually search for — I’d have to refactor this into an explicit mapping. That’s not a small change, since it means adding a URL-resolution layer that’s deliberately absent right now. Not needed yet at this blog’s scale, and I’d rather keep the consistency than optimize prematurely for something that might never matter.

A constraint as small as “filenames must match” looks trivial, but it’s exactly why i18n-url.ts is a dozen-odd lines of code with zero extra dependencies. If this blog ever genuinely needs different SEO slugs per language, I already know exactly what has to change — but until that’s an actual problem, I’m not going to rush in complexity that isn’t earning its keep yet.