In Metnos, language is a property of the whole instance, not an individual user preference. The runtime core retains one language for users, channels, and concurrent requests. Changing it is therefore a deliberate global configuration change. This is the architectural contract; some older surfaces do not yet satisfy it completely, and this page identifies those limitations.
Many systems begin in one language and are localised later. This can translate buttons and messages while leaving model instructions, tool descriptions, or request-recognition phrases in another language. Metnos starts from a different constraint: a feature is not genuinely multilingual when only its surface is.
It means that language enters system boundaries rather than merely its copy. The core reads it from signed configuration and retains it in an isolated context for each concurrent execution. A value received from a request cannot replace it. Human-facing components must use that same value: this is a verifiable requirement, not a claim that every older page has already been migrated.
Across the paths managed by the core, every user and channel connected to one instance therefore receives the same language. If two languages are needed at the same time, they require separate Metnos instances; changing the language of one instance is a global configuration change for that instance.
Language and authority stay separate. Changing the instance language does not broaden permissions, change ownership, or grant an executor new capabilities. It changes rendering and understanding, not authority.
The point is not simply to translate more text automatically. It is the recognition that an agent uses language at different points, each with a distinct purpose and risk. Metnos keeps them separate, so a gap can be found and corrected without pretending that the entire system is already ready.
| Layer | Purpose | Why the other layers cannot replace it |
|---|---|---|
| Prompts | Give models their instructions, criteria, and the instance language expected in responses. | A translated interface does not prevent a model from receiving instructions in the wrong language. |
| Executor manifests | Tell the planner which actions are available and what their arguments mean. | Translating the result is insufficient when a tool was selected from a description unsuitable for the instance language. |
| Message catalog | Renders deterministic errors, confirmations, labels, and notifications. | These texts must remain dependable even when no model is available. |
| Recognition lexicon | Recognises natural ways to express intents, objects, and parameters. | Displaying Italian words does not automatically teach the system every way an intent can be phrased in Italian. |
The action vocabulary already applies this contract end to end. Canonical
names such as run and open are not translated; the
natural forms used to recognise them live in the versioned detection lexicon,
while their semantic boundaries are i18n catalog keys. A new language must
preserve every canonical action: a partial mapping cannot pass the coverage
check, and ambiguous forms are reported for linguistic validation.
Current exception: affinity. Manifest phrases
used to bring a request closer to an executor are still stored in one list
that may mix languages. The maximum-priority AFF-I18N-001 TODO
requires analysis, comparison of alternatives, a specification, and
implementation before this layer can be called fully i18n-compliant.
A missing translation should lead neither to invented wording nor hidden behaviour. Each layer follows a deterministic rule:
<missing:KEY>;Fallback provides continuity; it does not certify linguistic quality. A language may be present in the catalog while some resources are still under review. Metnos preserves that distinction: available does not automatically mean fully supported.
A translation becomes stale when its source text changes. To keep an accurate but outdated sentence from appearing current, Metnos records fingerprints of both the present text and the source used to translate it. When one language changes, versions that are no longer aligned are marked for review. Comparison is structural and deterministic; a model may propose new wording, but it does not decide that the wording is correct.
The same principle protects customisation. Distributed catalog updates add new keys and may refresh a previous official version, but they must not blindly overwrite a locally chosen translation. Provenance participates in the update decision.
A remote executor does not own a separate language policy. It receives the context admitted by the server and a limited set of operational messages that it may need to render on the device. This set is generated from the immutable public release seed, not from the compiler's personal catalog: a local customisation therefore cannot accidentally enter a published artefact.
The same rule governs the main channel paths. Telegram, the web chat, and deferred work receive the instance language and do not retain an independent preference for each user.
Current coverage, not the ideal. Some standalone HTML pages inherited from the runtime still contain Italian text directly in code. These include the OAuth result page, the older timers view, and several standalone views. They do not all go through the i18n catalog. The chat core and template-based administration pages follow the contract, but the complete interface cannot yet be described as fully localised.
The architectural value is to treat multilingual operation as a verifiable cross-cutting property, alongside identity and provenance, rather than as a final editorial phase. This produces three concrete benefits:
This is not a promise of perfect translation. Models can still produce awkward wording, a new language can have incomplete comprehension coverage, and human review remains essential. The innovation is to make those limits part of the contract, and therefore measurable and correctable.
When installation requests a language other than Italian or English, Metnos
does not pretend that it is ready. It normalises the BCP-47 code and, after the
installation key is created, atomically records a signed request at
$METNOS_USER_STATE/i18n/localization_request.json with its date,
state, and corpus version. The instance starts temporarily in English and the
request remains pending. Installation alone does not automatically translate
the complete system.
The complete pipeline exists, but is currently started through administration
tools. materialize inventories prompts, textual manifest fields,
messages, the recognition lexicon, public documentation, the device repertoire,
and the Tutor catalog. advance translates a bounded number of
resources, records fingerprints, and submits eligible material to semantic
review. Sensitive resources, such as regular expressions and consent controls,
require human review. The affinity field is not yet part of this
inventory.
Two narrower periodic jobs also exist. By default, the service timer processes messages already pending in the i18n catalog every five minutes; the scheduler runs a six-hour fallback and also processes the recognition lexicon. These jobs drain queues that have already been materialised, but they do not replace an explicit advance of the complete pipeline. Once every required resource has passed its checks, activation rebuilds the public catalogs, checks manifests and coverage, updates the signed configuration, and can restart the service in the new language.
What remains unchanged. Translation does not alter executor names, keys, argument schemas, permissions, ownership, policy, or signatures. It changes the language Metnos uses to understand and explain; it does not change what Metnos is authorised to do.