Angband 4.2.6 in Spanish

**Nick** · March 13, 2026, 20:11

This is wonderful, I have always thought this should be possible - but a lot of work. Some questions:
- Many of the data files, and some others like list-mon-message.h, have many text strings - are you just making Spanish versions of these files?
- Do you think it would be possible to organise the code so that all the text that needs translation is in such files, so that the translation job would become just translating those files (and adjusting the files that process them like obj-desc.c)?

**backwardsEric** · March 14, 2026, 16:07

To avoid conflicts between changes for the translations and changes to other data in the data files, I would have a structure so that there is a file (or files, if one wants to break things up) with the strings for one localization. Something like monster.txt would still have "name" lines for each entry but those would just hold a code name that would be used to look up the localized name, description, plural, messages, .... The "desc", "plural", .... lines would either not be present in monster.txt or they would hold fallback text if there was not an appropriate localized string.

For grammatical gender, the current game uses monster race flags, "MALE" and "FEMALE", to specify the gender of monsters. That likely does not work if multiple localizations are supported (a given monster could have different genders in different localizations). Grammatical gender for monsters and objects should then be a separate, localizable, field which is then used in mon-desc.c and obj-desc.c to choose pronouns and articles (heaven forbid there's a language that requires verb conjugations to match the subject's gender - that would further complicate how Angband builds messages about objects or monsters).

**hernaldog** · March 20, 2026, 19:10

Originally posted by Nick

This is wonderful, I have always thought this should be possible - but a lot of work. Some questions:
- Many of the data files, and some others like list-mon-message.h, have many text strings - are you just making Spanish versions of these files?
- Do you think it would be possible to organise the code so that all the text that needs translation is in such files, so that the translation job would become just translating those files (and adjusting the files that process them like obj-desc.c)?

I'll answer each point:
- For now, I'm in an experimental version, where I'm translating the files directly from English. Once I understand how everything works and have an "alpha" version, we'll need to study how to make a configurable system...

- I've worked on other projects where, from the beginning, we use "Resource" systems where each resource is a text file for a specific area or event... In this case, it's much more complex since all the text in the .c or .h source code is designed to be output in English. We'd have to create (or rewrite) a multi-language text output engine to support more languages. This is outside my skill set

I'm not very good at C.

**iggy_hunter** · June 11, 2026, 19:46

I'm quite interested in making AngbandOS multi-language capable. As Nick has suggested, there are Elvish and other names that are built from syllables, so there is coding in some places that is needed. Also there are numerous areas, like monster knowledge that would need to be recoded.

I do not have any Spanish fluency, but a partnership would work. Hernaldog, is this something you would help me with?

**hernaldog** · June 13, 2026, 22:19

Originally posted by iggy_hunter

I'm quite interested in making AngbandOS multi-language capable. As Nick has suggested, there are Elvish and other names that are built from syllables, so there is coding in some places that is needed. Also there are numerous areas, like monster knowledge that would need to be recoded.

I do not have any Spanish fluency, but a partnership would work. Hernaldog, is this something you would help me with?

Hi iggy_hunter, I'd love to help with your AngbandOS project. I saw that it's in .NET Core 6, a language I use daily (it would be great to migrate it to .NET Core 10). The problem is time; I've been working on Angband for a few months now and I'm almost finished. I estimate I'll finish in about two months. It's a standalone version 4.2.6 in Spanish. I don't know if Nick or the Angband team will ask me for help to integrate it into the core of the game, at least in two languages for now: Spanish and English. Anyway, to sum it up, once I finish that project, I can help you with yours.

**iggy_hunter** · June 13, 2026, 23:27

Awesome ... look forward to it. I'm on .NET 6 because the game was using the BinaryObjectSerializer for game save and restore. I've written a completely new polymorphic game save and restore system and I'm trying to finalize it. In the meantime, I'm comparing the saves from the BInaryObjectSerializer to the new polymorpic version using a deep compare. Once I finish getting everything into the gamepack and I'm confident the save is 100% accurate, I'll drop the BinaryObjectSerializer and move to NET 10. The BinaryObjectSerializer is not available in NET 7 and later.

**hernaldog** · July 9, 2026, 23:29

Hi everyone, I managed to create a system to translate the game while maintaining both Spanish and English. Here are the details. The system will allow for future expansion to other languages.

It's 98% complete (committed) and I just need to test it extensively, both in English and Spanish. I'll be submitting a pull request soon, let's see if they accept it

Translation system for this Angband fork:

The system has three independent layers, each designed for a different type of content. It's not the standard GNU gettext (it doesn't use compiled .mo files or libintl) — it's a simpler, custom-made reimplementation specifically for this project.

1. lib/locale/es.po — string dictionary for the interface (src/*.c, *.h)
This is the main mechanism for all the text in the C code: combat messages, menus, prompts, command names, etc.

How it works:

In any .c file, English text is wrapped like this: _("You miss %s.").
_() is a macro (lang.h:36) that expands lang_get(str).
lang_get() searches for the literal string in an in-memory table loaded at startup from es.po, and returns the translation if it finds it. If it doesn't find it, it returns the key unchanged—that's why playing in English doesn't need any .po file: lang_init("en", ...) doesn't even try to open it.

es.po is a plain text file with pairs:

msgid "You miss %s."

msgstr "You miss %s."

Angband parses it with its own very simple reader (lang.c:246), not with a real gettext—it only understands msgid "..." followed by msgstr "...", ignores comments (#), and supports basic escapes (\n, \t, ", \\). The keys (msgid) are the English text exactly as it appears in the code—by convention, always the original English string, never an abstract ID like MSG_001. A golden rule we follow throughout the project: if a Spanish string appears hardcoded directly in a .c file (without _() around it) and is also seen in English, it's a bug—the fix is to wrap it in _(), restore the original English there, and add the translation in es.po.

2. The lang_current system—for grammar that the simple dictionary cannot resolve.
lang_current (lang.h:31) is a global string ("en" or "es") that indicates the active language at any given time. es.po works perfectly when there is a one-to-one correspondence between a phrase in English and its translation—but Spanish sometimes needs different logic, not just different words:

Gender agreement (el/la, un/una) based on whether the noun is feminine or masculine—doesn't exist in English, so there's no natural "msgid" for this. Example: mon-desc.c, function monster_name_is_feminine_es(), decides "el Kobold" vs. "la Serpiente" using a heuristic based on the monster's name ending.
Different word order: in English "hits {target}", in Spanish "{target} golpes"—the pronoun comes before the verb. See mon-blows.c.
Date/units format: lib/locale/units.ini (also loaded by lang_init) defines whether weight is displayed in pounds or kg, height in feet or cm, etc.—it's not translatable text, but rather numerical conversion formulas for each language.
Grammatical contractions ("a" + "el"? "al"): Implemented as a centralized post-processing function in message.c, applied to any formatted message only if lang_current == "es".

The code pattern is always the same:

if (streq(lang_current, "es")) {
/* Spanish-specific logic or text */
} else {
/* original English behavior, untouched */
}
This is the "escape hatch" for when _() is insufficient because the problem is not vocabulary-related but grammatical structure-related.

3. lib/gamedata/*.txt — game data (monsters, objects, artifacts, terrain, etc.)
These files do not pass through es.po or _(). They are the content definition files (monster.txt, object.txt, artifact.txt, object_property.txt, terrain.txt, etc.) that the Angband parser reads directly into structures (name:, desc:, adjective:, etc.) — The message engine never accesses them, so a string dictionary doesn't fit well there.

Instead, each file has up to three versions:

lib/gamedata/archivo.txt — base/default version.

lib/gamedata/en/archivo.txt — override for English.

lib/gamedata/es/archivo.txt — override for Spanish.

On startup, main-win.c redirects ANGBAND_DIR_GAMEDATA to the active language subdirectory if one exists (the same mechanism applies to lib/screens/). That's why, for example, blow_methods.txt in Spanish says "{target} golpes" and in English says "hits {target}" — they are completely different files, not an automatic translation from one to the other.

------------- in spanish ---------

Hola a todos, logr? inventar un sistema para traducir el juego y mantener los dos idioma, Espaol e Ingl?s. Ac? el detalle. El sistema permitir?a crecer a otros futuros idiomas.

Lo tengo al 98% (commiteado) y solo me queda probar y probar, tanto en ingl?s como en espaol.
Voy pronto hacer un pull request, a ver si me lo aceptan

Sistema de traducci?n de este fork de Angband:

El sistema tiene tres capas independientes, cada una pensada para un tipo distinto de contenido. No es el gettext est?ndar de GNU (no usa .mo compilados ni libintl) — es una reimplementaci?n propia, m?s simple, hecha a medida para este proyecto.

1. lib/locale/es.po — diccionario de strings de la interfaz (src/*.c, *.h)
Es el mecanismo principal para todo el texto que vive en el c?digo C: mensajes de combate, men?s, prompts, nombres de comandos, etc.

C?mo funciona:

En cualquier archivo .c, el texto en ingl?s se envuelve as?: _("You miss %s.").
_() es una macro (lang.h:36) que expande a lang_get(str).
lang_get() busca la cadena literal en una tabla en memoria cargada al inicio desde es.po, y devuelve la traducci?n si la encuentra. Si no la encuentra, devuelve la clave sin cambios — por eso jugar en ingl?s no necesita ning?n archivo .po: lang_init("en", ...) ni siquiera intenta abrirlo.
es.po es un archivo de texto plano con pares:

msgid "You miss %s."
msgstr "Fallas contra %s."
Angband lo parsea con un lector propio muy simple (lang.c:246), no con gettext real — solo entiende msgid "..." seguido de msgstr "...", ignora comentarios (#), y soporta los escapes b?sicos (\n, \t, ", \\).
Las claves (msgid) son el texto en ingl?s tal cual aparece en el c?digo — por convenci?n, siempre el string original en ingl?s, nunca un ID abstracto tipo MSG_001.
Regla de oro que seguimos todo el trabajo: si una cadena en espaol aparece hardcodeada directamente en un .c (sin _() alrededor) y tambi?n se ve en ingl?s, es un bug — el fix es envolverla en _(), restaurar el ingl?s original ah?, y agregar la traducci?n en es.po.

2. El sistema lang_current — para gram?tica que el diccionario simple no puede resolver
lang_current (lang.h:31) es un string global ("en" o "es") que indica el idioma activo en todo momento. es.po funciona perfecto cuando hay una correspondencia 1 a 1 entre una frase en ingl?s y su traducci?n — pero el espaol a veces necesita l?gica distinta, no solo palabras distintas:

Concordancia de g?nero (el/la, un/una) seg?n si el sustantivo es femenino o masculino — no existe en ingl?s, as? que no hay ning?n "msgid" natural para esto. Ejemplo: mon-desc.c, funci?n monster_name_is_feminine_es(), decide "el Kobold" vs. "la Serpiente" on una heur?stica basada en la terminaci?n del nombre del monstruo.
Orden de palabras distinto: en ingl?s "hits {target}", en espaol "{target} golpea" — el pronombre va antes del verbo. Ver mon-blows.c.
Formato de fecha/unidades: lib/locale/units.ini (cargado tambi?n por lang_init) define si el peso se muestra en libras o kg, altura en pies o cm, etc. — no es texto traducible, son f?rmulas de conversi?n num?rica por idioma.
Contracciones gramaticales ("a" + "el" ? "al"): implementado como un post-proceso centralizado en message.c que se aplica a cualquier mensaje formateado, solo si lang_current == "es".
El patr?n en c?digo siempre es el mismo:

if (streq(lang_current, "es")) {
/* l?gica o texto espec?fico de espaol */
} else {
/* comportamiento original en ingl?s, sin tocar */
}
Esto es el "escape hatch" para cuando _() no alcanza porque el problema no es de vocabulario sino de estructura gramatical.

3. lib/gamedata/*.txt — datos del juego (monstruos, objetos, artefactos, terreno...)
Estos archivos no pasan por es.po ni por _(). Son los archivos de definici?n de contenido (monster.txt, object.txt, artifact.txt, object_property.txt, terrain.txt, etc.) que el parser de Angband lee directamente a estructuras (name:, desc:, adjective:, etc.) — el motor de mensajes nunca los toca, as? que un diccionario de strings no encaja bien ah?.

En vez de eso, cada archivo tiene hasta tres versiones:

lib/gamedata/archivo.txt — versi?n base/default.
lib/gamedata/en/archivo.txt — override para ingl?s.
lib/gamedata/es/archivo.txt — override para espaol.
Al arrancar, main-win.c redirige ANGBAND_DIR_GAMEDATA al subdirectorio del idioma activo si existe (mismo mecanismo para lib/screens/). Por eso, por ejemplo, blow_methods.txt en espaol dice "{target} golpea" y en ingl?s dice "hits {target}" — son archivos completamente distintos, no una traducci?n autom?tica de uno al otro.

**Nick** · July 10, 2026, 07:48

This looks super impressive. I've only read it quickly and haven't taken it all in (there's a lot!), but I can't think of any immediate pitfalls. Well done!

Angband 4.2.6 in Spanish

Angband 4.2.6 in Spanish

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment