[FEAT] Localized module keys without freezing the default structure

[wehrwolfmann]

Description

Module keys are always English — OS, Kernel, Memory, Local IP and so on. That is a deliberate and defensible default, and I am not asking to change it. What I would like to discuss is whether fastfetch could optionally supply translated default keys while leaving everything else exactly as it is.

Concretely, something along these lines:

• a per-language table mapping module type to its default key string, either embedded at build time or shipped as plain JSON next to the presets (presets/locale/ru.jsonc etc.), read with yyjson like any other config — no new dependency, nothing beyond libc and yyjson;
• opt-in and explicitly selectable, e.g. --key-language ru, or picked up from LC_MESSAGES only if the user asks for that;
• an explicit key in a user config always wins, so nothing changes for anyone who has one;
• placeholders untouched — the table would substitute only the literal part of the key, so {1} / {2} semantics stay owned by the module code.

I am aware this is not as trivial as it sounds from the outside: FF_OS_MODULE_NAME "OS" is used both as the printed key and as the module's identity in the registry (src/modules/os/os.c, .name = FF_OS_MODULE_NAME), so any translation would first require separating "name of the module" from "label shown to the user". That is exactly why I am opening a discussion rather than a pull request — the cost lands in your code, not mine, and you may well decide it is not worth it.

Motivation

Why not the Command module? Because this is not about detecting anything new. The information is already there and already correct; only its label is in the wrong language. Reimplementing os, gpu, disk, battery and the rest through Command would mean throwing away all the platform detection and formatting that makes fastfetch worth using, in order to change a handful of words.

Why not just set key per module? That does work, and it is what I do today:

{
    "modules": [
        "title",
        "separator",
        { "type": "os",      "key": "Система" },
        { "type": "host",    "key": "Устройство" },
        { "type": "kernel",  "key": "Ядро" },
        { "type": "uptime",  "key": "Время работы" },
        { "type": "display", "key": "Экран ({2})" },
        { "type": "wm",      "key": "Оконный менеджер" },
        // ... every remaining module spelled out by hand ...
        { "type": "disk",    "key": "Диск ({1})" },
        { "type": "localip", "key": "Локальный адрес ({2})" },
        { "type": "locale",  "key": "Язык" }
    ]
}

The catch is the array itself. To rename the keys I have to enumerate modules by hand, and from that moment my config is pinned to whatever the default structure was on the day I wrote it. Every later change you make to the default structure silently passes me by — I traded staying current for having readable labels. A plain localized preset in presets/ would have exactly the same problem, which is why I am asking about default keys specifically rather than about shipping more presets.

Two smaller points on top of that:

• the placeholders differ per module — {1} is the mount point for disk but the card index for gpu, and the interface name is {2} for localip — so hand-writing them is easy to get subtly wrong, and everyone rediscovers this separately;
• out of the box a non-English user gets an English fetch, and fastfetch output travels further than most program output: it is the thing people put in screenshots, forum posts and bug reports when they show their system.

Additional context

Tested on fastfetch 2.67.0 (x86_64), Linux, KDE Plasma — the config above is what I actually run, so the workaround is proven; it is only its maintenance cost I am raising.

If the idea is acceptable in principle, I am happy to prepare the first implementation along with the Russian set of labels, in whatever shape you prefer. And if the answer is "the manual key override is the intended solution and that is enough", that is a perfectly good answer too — better heard now than after a pull request.