Running Korean, English, and Japanese Pages with Next.js 15 and next-intl

The portal is not only a Korean site. It has Korean, English, and Japanese routes, and that means every public page must be understandable to both users and crawlers in the selected locale.

Why this matters for GRAXEL

Internationalization can create thin-content problems if only the navigation is translated. A reviewer who opens the English or Japanese blog should see real posts, canonical URLs, and metadata that match the page they are reading.

GRAXEL uses locale-aware routes, localized message files, canonical URLs, and per-locale blog arrays. The latest AdSense work also checks that sitemap entries do not advertise blog URLs that do not exist in a locale.

Operational notes

• Keep the user-facing promise narrow enough that the service can be verified in a browser.
• Document the boundary between automated AI output and source-backed data so reviewers can understand the workflow.
• Link the implementation back to the public trust pages: About GRAXEL, Contact, and the platform overview.

For a small SaaS portfolio, trust comes from showing the real operating system behind the product: what runs, why it exists, and how it is maintained.

What changed in practice

This makes the site more consistent for search engines and for real visitors who arrive through non-Korean routes. The same pattern now influences how the portal presents public services: planned ideas stay out of the main catalog, while usable beta services and documented operating notes receive stronger internal links.

When this article is read together with the monorepo operations note and the zero-cost infrastructure note, it gives a more complete view of how GRAXEL turns small service ideas into maintained products.

Official references

• Next.js internationalization docs
• next-intl documentation

How I verify a trilingual route before publishing

For a multilingual portal, the hard part is not translating labels; it is making sure search engines and users land on the right equivalent page. I check each public route in Korean, English, and Japanese, then confirm that the canonical URL points to the current locale while hreflang alternates point to the sibling pages. I also keep locale detection conservative, because automatic redirects can confuse crawlers and create duplicate-looking URLs when a page is shared in a different language.

My manual QA flow is simple: open the Korean default path, switch to English and Japanese, inspect the rendered links, and then confirm that the sitemap contains the same relationship. Navigation links must remain crawlable anchors, not only client-side buttons. For content pages, I avoid translating only the title while leaving the body shallow; thin localized pages are worse than no localization because they create low-value indexed URLs. The preferred pattern is a complete localized page with its own title, description, canonical, and visible internal links back to related guides. This is slower than string-by-string translation, but it produces pages that reviewers and search crawlers can actually understand.

Extra review step

Before I consider a locale finished, I also test how it behaves without JavaScript. The main navigation, footer, language alternatives, and article archive should still expose useful links in plain HTML. This catches a common multilingual mistake: the page looks correct for a human tester, but crawlers cannot discover the localized equivalent because the only path is hidden behind client state.