660 i18n

i18n is how a Stackpress app keeps user-facing text from being locked to one language. The framework path is practical: config defines the available languages, the language plugin remembers the active locale, the view helpers pass language data into page props, and React views call useLanguage() to render translated text.

This group treats translation as app behavior, not abstract theory. A junior developer should be able to trace one label from config to the component that prints it on the page.

Previously: Email showed how app behavior can leave the current browser response. i18n comes back to the rendered page and focuses on the text the user reads inside that response.

660.1. Why i18n Needs Both Config And Views

Translations start with configuration because the app needs to know which locales and strings exist. They become visible in views because React components are where the user actually reads the text.

That split is easy to miss. A translation can be correctly configured but unused, or a view can ask for text that the configured active locale does not provide.

660.2. What This Group Covers

661 Language Config explains language.key, language.locale, and language.languages. It also explains how the language plugin stores the active locale in session data when the user chooses a valid locale.

662 useLanguage shows the view-side hook. It focuses on the common const { _ } = useLanguage() pattern used by Stackpress views and generated view output.

660.3. The Translation Flow

The flow starts in config and ends inside a component. The plugin registers the language map, request handling can update the locale, setViewProps() includes language data in server props, and LayoutProvider passes the active language and translations into R22nProvider.

When text does not translate, inspect the flow in that order. Check config first, then locale selection, then view props/provider boundaries, then the hook usage in the component.

660.4. How To Keep It Practical

Start with one visible string and one alternate locale. A small translation proves the flow without forcing the reader to design a whole translation catalog.

After that, larger apps can add naming conventions and shared translation files. Those decisions are easier once the first visible translated string works in a real Stackpress view.

Learning checkpoint: You should be able to explain why translation needs both a config surface and a view usage surface. You should also know how to inspect a missing translation from config to component.

Next course: Continue with Language Config. That course turns the translation flow into a concrete config example.