Sitelet https://github.com/NetHack/NetHack/issues/1656
Skip to content

Would you consider i18n support in the main repository? #1656

Description

@g4b0

Hello,

I would like to ask a question before writing any code, so I don't repeat what happened with #1478.

Why

People have been translating NetHack for a very long time: JNetHack (Japanese), NetzHack and NetHack-De (German), Spanish NetHack, KRNethack and NetHackKR (Korean), NetHackJP (Japanese, 5.0), and Ray Chason's "Internationalized NetHack". They keep appearing because people love this game and want to play it in their own language.

I'm Italian. I can read English fine, but after a long day I play more comfortably - more relaxed - in my own language, and I know many players who feel the same. I also played NetHack with my son, and I had to translate every message out loud as we went. He would have learned the game much faster if it had spoken Italian to him.

I understand this is not an easy task. It's not just strings: it's grammatical gender, articles, plural rules, and word order that don't work like English. That's exactly why every attempt so far has been so expensive.

Why in the main repository, and not in yet another fork

Every project in the list above is a separate fork, and almost all of them are dead. The reason looks structural rather than personal: a fork has to carry a full localized copy of the game and rebase it forever. When one maintainer runs out of free time, that language dies - and the next language starts again from zero. Eight attempts, the same outcome.

If the mechanism lived here instead, a translation would be data: one text file per language, contributed and maintained by the people who actually speak it, without touching core code. The DevTeam would never have to review a translation in a language you don't read - only the mechanism itself. That is the difference between one more abandoned fork and something the community can keep alive.

That's why I'd rather ask you first than build a ninth fork.

About #1478

I read it, and I think paxed's objections were fair. I would want to address them from the start:

  • no context for the translatable strings - context-tagged lookups, so a translator can disambiguate identical strings and can tell an informational message from a joke.
  • plural forms lacking - real plural rules per language, not a singular/plural boolean (Slavic languages need three or four forms).
  • duplication of special level lua code - no duplicated dat/*.lua. The ~990 translatable literals in the Lua levels need a lookup, not a copy of the tree.
  • LLM use - see below.

How I would want to work

Small, single-purpose, reviewable commits. Mechanism first. With no language selected the English behaviour stays byte-identical, and no translation content goes into core files.

I do use LLM assistance and I will always say so on a PR. Honestly, I think that's what makes this newly practical: the hard part was never the design, it was the sheer volume - thousands of strings plus grammar composition. But #1478 also shows the failure mode very clearly, and a 195k-line drop is not reviewable by anyone, whoever wrote it. So I would rather earn trust in small pieces than ask for it up front.

The question

Is a mechanism-only i18n contribution something you would consider at all? And if yes, what shape would you want it to have? You are the experts on this codebase, and I would much rather build something you would accept than guess and waste both our time.

If the answer is no, that is a perfectly fair answer and I'll keep the work in my own fork.

Thank you for this game.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions