Localization

The site is fully internationalized with Inlang Paraglide JS. It ships with en-US (the base locale) and es-US.

Editing messages

Every piece of text the site’s own chrome shows — the greeting, the nav labels, the schedule headings — is a message, and you can override any of them.

The GUI’s i18n tab is where you do it. It shows a grid: one row per message key, one column per locale, with the base locale marked. Type over a value to override it, Add Message to introduce a new key, and the trash button to drop an override again. Reload re-reads the files from disk.

Messages can carry variables, filled from what you set in the Website tab’s Core fields — {stream_name} and {streamer} are the two you’ll see most:

Welcome to {stream_name}
{streamer}'s Time

Overrides are saved into your config repo alongside the rest of your configuration, so they travel with it and are deployed with the site.

World names are not messages

Each world carries its own display name per locale, set in the Worlds tab next to the world’s key. That’s the only place a world is named — you won’t find world names in the message list, and adding one there does nothing.

Locale routing

Locales use a URL-prefix strategy (e.g. /es-US/...). Because GitLab Pages is static and can’t redirect on Accept-Language, first-visit language selection is done client-side in the browser, and viewers can switch languages from the header selector. A viewer’s choice is remembered on their next visit.

Adding a locale

Adding a whole new locale is a change to the site template rather than to your config: the locale has to be added to the Inlang project and given a base message file. Once a locale exists, your deployment can override its messages from the i18n tab like any other.