> **Marked Text Encoding**
>
> You don’t need to know the exact format of marked text, but it might help you understand.
>
> `"\27(T@mymod)Hello everyone!\27E"`
>
> - `\27` is the escape character - it’s used to tell Minetest to pay attention as something special is coming up. This is used for both translations and text colorisation.
> - `(T@mymod)` says that the following text is translatable using the mymod textdomain.
> - `Hello everyone!` is the translatable text in English, as passed to the translator function.
> - `\27E` is the escape character again and E, used to signal that the end has been reached.

(from https://rubenwardy.com/minetest_modding_book/en/quality/translations.html)

> > So your idea is to create an English textdomain where you translate the technical group names into readable English? This will not work: https://github.com/minetest/minetest/issues/6503
>
> Huh I'm confused by what you mean. The issue just notes issues with translating other languages to English, from what I saw anyways.

let's do what you did with the group `soft_stone` and the recipies in tech:
`"group:soft_stone="..S("Soft stone").." 2"` would result in `"group:soft_stone=\27(T@tech)Soft stone\27 2"`.
Note that the space between Soft and stone is still there. This will break the format of serialised items (https://github.com/minetest/minetest/blob/728f643ea76278dcf89f9ac066062e7b895e46c8/doc/lua_api.md?plain=1#L1969).
At the latest, you would run into problems here: https://codeberg.org/Mantar/Exile/src/commit/ef87649fbb889f816df16f0e117ff29e16e44bad/mods/crafting/api.lua#L162-L164
So you would have to go with `"group:soft_stone="..S("Soft_stone").." 2"`
But now you have an underscore in the English string. That's what I meant with the English textdomain:
You would set up a tech.en.tr file with `Soft_stone=Soft stone` and abuse translation to get rid of the underscore. (Doesn't work bc. you can't translate to English)
The update script would tell translators to translate `Soft_stone`.
Translation happens on the clients side. So you can't call `string.gsub` to get rid of the underscore. In that case the translation file is useless, bc. the needed string (`Soft stone`) cannot be translated.

Conclusion: You might be able to encode english group descriptions in the group name. But you can't collect these descriptions with a script.
IMO it's also rather bad style to not separate the description and the technical name.

> > Additionally, "group:butter="..S("Butter").." 2" will not work because S("Butter") ~= "Butter" and thus the crafting mod will break.
>
> How would it break? ;o It only displays the words, not use them for calculations?

Maybe I should have used comparisons, not calculations... I'm not a native speaker. Anyways, let's take `group:soft_stone=\27(T@tech)Soft_stone\27` again: The `soft_stone` group is defined in nodes_nature. So using `"group:soft_stone="..S("Soft_stone)` would result in `group:soft_stone=\27(T@nodes_nature)Soft_stone\27`
Thus the group names of the recipe and item definition do not match. You would have to use the same translator function for each place where the group is used.
When having groups used in many mods, you will soon end up with a huge mess of translator functions.
You might also break naming expectations from other mod's regexes... You should only break conventions like https://github.com/minetest/minetest/blob/728f643ea76278dcf89f9ac066062e7b895e46c8/doc/lua_api.md?plain=1#L291 if you have very good reasons...

Conclusion: you could probably work around this at the coasts of very bad code...

> > What you can do is to mark them as translatable to the script without actually turning them into a translation string ("group:"..NS("something")) and turn it into a translation string when building the gui. But then we would be back to what I meant with
>
> Hmm... Still confused...

I don't know what I thought when I wrote this... **This is no solution bc. we can't encode group descriptions in the group name.**
The Idea was to work around the problems of `S()` mentioned above by using `NS()` (https://github.com/minetest/minetest/blob/master/util/README_mod_translation_updater.md#how-to-use-ns)
But this approach would also lead to the script not being able to build the correct translation files.
The translation would happen under the crafting-textdomain, while the script would collect the translation strings for the textdomain in which the recipe is registered
But it's a valid point, I should have probably mentioned some of the limits of this script...