Repository navigation
[Feature]: add Spanish (Español) localization support #1551
Description
Area
Multiple areas
What are you trying to accomplish?
I would like to use OpenCodex in Spanish (Español), especially the Web Dashboard / GUI, so Spanish-speaking users can navigate providers, models, settings, usage, logs, integrations, authentication flows, warnings, and other common workflows without needing to use the English interface.
OpenCodex already has an i18n/localization system and currently registers several locales in gui/src/i18n/catalogs.ts, including English, German, Korean, Simplified Chinese, Traditional Chinese, Russian, Japanese, and Turkish. Spanish is not currently registered there.
What prevents this today?
There is currently no es / Spanish locale available in the OpenCodex GUI language selector.
As a result, Spanish-speaking users must use another supported language even though the project already has the infrastructure for locale catalogs and translation-key parity.
There also does not appear to be a Spanish documentation locale under the current docs-site content structure, so users who prefer Spanish do not have a first-party localized documentation path either.
What should OpenCodex do?
Add Spanish (es) as an officially supported locale.
Expected observable behavior:
Españolappears in the existing language selector.- Selecting Spanish translates the Dashboard / GUI navigation, forms, buttons, settings, provider/account screens, model/catalog screens, logs, usage information, errors, warnings, confirmations, and other user-facing strings covered by the existing i18n system.
- The selected locale persists using the same behavior as existing locales.
- New translation keys are kept in parity with the canonical English catalog using the project's existing locale synchronization / validation tooling.
- Dates, numbers, percentages, and other locale-sensitive formatting use the existing localization conventions where applicable.
- Existing locales remain unchanged.
If documentation localization is maintained in the same release scope, adding an es docs locale would also be valuable. If that is considered separate scope, the GUI localization alone would already satisfy the primary request.
Example usage or interface
In the OpenCodex Dashboard language selector:
English
Deutsch
한국어
中文
繁體中文
Русский
日本語
Türkçe
Español
After selecting Español, examples of common UI labels would be presented in Spanish, for example:
Providers -> Proveedores
Models -> Modelos
Settings -> Configuración
Usage -> Uso
Logs -> Registros
Accounts -> Cuentas
The exact translations should follow the terminology conventions chosen by the project and native-speaker review.
Alternatives or workarounds
- Use the English interface.
- Rely on browser machine translation, which can be inconsistent for technical terminology and dynamic UI content.
- Maintain a private/local Spanish catalog, but it would drift as OpenCodex adds new translation keys.
An official locale is preferable because it can participate in the same translation-key parity checks and maintenance workflow as the existing locales.
Additional context
The current GUI localization registry already provides a clear extension point in:
gui/src/i18n/catalogs.ts
A Spanish implementation could follow the existing locale pattern, for example an es.ts catalog registered as es with:
lang.nativeName = "Español"
It would be useful to include locale parity/regression coverage so future UI additions cannot silently fall back to copied English text.
I searched the existing issues for Spanish, Español, Castellano, localization, and i18n and did not find an existing Spanish-language request. There is precedent for adding additional localizations, including prior language requests such as Russian support.
Checks
- I searched existing issues and documentation.
- This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
- I removed secrets and personal data.
Activity
lidge-jun commentedon Aug 18, 2026
Closing as a planning item rather than a rejection. We are not scheduling a Spanish locale ourselves because every added locale must track the English source on each behavior change (the review guidelines already require translated locales not to contradict the English docs), and that maintenance load is real. That said, a community PR adding an
eslocale is welcome — if you or anyone else submits one that keeps parity with the English source, we will review and accept it. Feel free to open the PR directly againstdev.