In Metnos, language is not a decoration applied to the interface after the product is complete. It is a property of the Metnos instance: the configured language is shared by its users, channels, requests, and responses. Changing the instance language is therefore a deliberate global configuration change, not a per-user or per-turn choice.
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 the system boundaries rather than merely its copy. The instance language is established in configuration and is retained in the execution context; every component that produces words for a person must use that same value. There is no per-user or per-turn language override.
This makes the operational rule explicit: all users and channels connected to one instance receive the same configured 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 innovation is not simply translating 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. |
| Comprehension 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. |
A missing translation should lead neither to a crash nor to invented wording. Each layer follows a deterministic fallback chain. For visible messages, for example, Metnos tries the instance language, then English, then Italian; if no version exists, it exposes a recognisable missing key. Prompts and manifests use equivalent rules suited to their own sources.
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 applies to channels. Language belongs to the Metnos instance; Telegram, the web chat, and deferred work all use the instance language and do not keep independent preferences that can silently diverge.
The distinctive idea 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 already available. It records the requested language, starts the instance temporarily in English, and queues localisation. English is therefore a safe transitional bootstrap, never a hidden per-user or per-turn choice.
The planned pipeline is incremental and idempotent. Overnight it compares source fingerprints and translates, through the dedicated language workload, the complete operational corpus: lexicons used by the proposer and understanding layer, planner and synt prompts, manifest descriptions and arguments, deterministic messages, notifications, device repertories, and resources consumed by Tutor. It does not translate labels only: it translates the material that guides reasoning and makes execution verifiable.
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.