Localization & i18n

InterGenOS is built entirely from source, and that extends to how the system handles language, region, and translation. This page describes how localization works in the current release and how contributors can help expand it.

The project is at version 1.0-dev (build id v1.0-dev1). Today the desktop is GNOME 49 on Wayland, which carries its own mature internationalization stack. The notes below distinguish what ships today from what is open for contribution.

How localization works today

Localization in InterGenOS rides on the standard components that the from-source toolchain produces and the desktop consumes:

Locale data comes from the C library’s locale definitions, generated at build time. Region, date, number, and currency formatting all derive from the active locale.
The desktop environment is GNOME 49, which uses gettext message catalogs for its translations. Most user-visible GNOME strings are already translated upstream by the GNOME translation community.
Per-application translations ship with each application package, in the catalogs that upstream provides.

Because the system is assembled package by package, the set of available languages reflects what the included packages carry. As the package set grows across the six tiers (toolchain, core, base, desktop, ai, and extra), so does the breadth of available translations.

InterGenOS-authored components

A few components are written for InterGenOS rather than pulled from upstream. These are where project-specific localization matters most:

pkm — the package manager
Forge — the installer
InterGen — the tiered, hardware-detected, offline-first local assistant (built on Qwen models, with zero telemetry)
InterGen Sentinel — the pluggable security scanner, which defaults to Local-Rules plus Local-Qwen and offers six opt-in cloud providers, including the Phone-A-Friend (Frontier/Cloud Escalation) path

User-facing text in these components is the highest-value target for translation work, because it is unique to the project and not covered by any upstream translation community.

Contributing translations

There is no separate translation submission process. Translation contributions follow the same path as any other code contribution, and the general workflow from the project’s contributing guidelines applies.

Open an issue first to discuss the language or component you want to work on. InterGenOS is maintained by a single developer, so coordinating up front avoids duplicated effort.
Fork the repository and create a branch.
Follow the existing code style. No surprises, no restructuring beyond the change at hand.
Test your changes. If you cannot verify that a translation renders correctly, do not submit it. The build must remain reproducible.
Submit a pull request with a clear description of what you translated and how you verified it.

Every commit must carry a Signed-off-by: trailer certifying the Developer Certificate of Origin (DCO) 1.1. Add it with:

git commit -s

Pull requests whose commits are not all signed off will fail the audit workflow and cannot merge.

Translations and packages

For applications pulled from upstream, translations live with the package and are updated when the package is updated. Package templates are the most impactful contribution to the project, and each one lives under packages/<tier>/<name>/ with two files:

package.yml — metadata: source URL, SHA256, dependencies, and build style
build.sh — the bash functions configure(), build(), check(), and do_install()

If a package’s upstream catalogs are out of date or missing a language, the right fix is usually upstream. Coordinate through an issue before changing how a package handles its own translations, so the build stays reproducible and the package stays close to its source.

The public-content audit

Every pull request to master is scanned by an automated public-content audit. Translation contributions are no exception: keep host-specific paths, internal file references, and credential-like strings out of message catalogs and commit messages. If the audit flags a file, amend it and push again. Legitimate public content that happens to match a flagged pattern can be added to the audit allowlist.

What we value

The same standards that govern all contributions govern translations:

Transparency — no hidden behavior, no surprising defaults.
Simplicity over cleverness — if there is a simpler way to handle a string or a locale, use it.
Tested changes — verify that text renders correctly before you submit.

These standards exist because the project’s purpose is a machine you understand, can modify, and can trust. In that posture, security is not first. It is only: translation work must never weaken the system’s integrity, and the audit and review gates apply to localized strings exactly as they apply to code.

InterGenOS Wiki