Add new gettext entries for game settings

[alrito28]

add parameter to translate minetest_games

Add compact, short information about your PR for easier understanding:

• Goal of the PR
• How does the PR work?
• Does it resolve any reported issue?
• Does this relate to a goal in the roadmap?
• If not a bug fix, why is this PR needed? What usecases does it solve?
• If you have used an LLM/AI to help with code or assets, you must disclose this.

To do

This PR is a Work in Progress / Ready for Review.

• List
• Things
• To do

How to test

[y5nw]

MTG translations do not belong in engine .po files.

[alrito28]

"MTG translations do not belong in engine .po files."

Do you have any ideas ?

Because for me, that's the solution that works :)

[y5nw]

Please explain why removing the separation between the engine and mods/games is a justifiable solution to begin with. If you can't explain this then I maintain my rejection on this PR.

[alrito28]

The part circled in red is in French. Can you explain it to me ?

[y5nw]

The part circled in red is in French. Can you explain it to me ?

I know that this approach works, but I did not question that to begin with.

What I did question was why your current approach is justifiable, which you so far failed to explain. In particular, you did not justify the consequences of your approach, i.e. that it effectively removes the separation between engine translations and translations for mods/games. This leads to a number of problems:

• The engine and every mod/game would have to be kept in sync in order for the translation of the settings to be visible, which complicates automated management of translation strings. In particular:
  • Translations for mods/games would only be visible in the next engine update (not the next update of the mods/subgames in question), and these would not be visible in engine versions released before the introduction of the game/mod-specific settings;
  • It would not be possible to remove old/unused translation strings immediately, as it is possible that players continue to use older versions of mods/games (for whatever reason), and such old translations would also need to be tracked in some way.
• Translations for mods/games would be split across different places and would have to be managed at different places for no other logical reason.
• Everything would share the same text domain (i.e. the one used by the engine). In particular:
  • It would be impossible to differentiate between the same term in different contexts (e.g. between different mods/games);
  • Contributors working on engine translations would have to be aware of the mechanics of different games and mods, even if these are less (if at all) relevant for the engine itself.

These problems can be avoided entirely be addressing #9070 properly.

Not to mention that src/setting_translation_file.cpp is auto-generated and should not be edited manually.

[y5nw]

My approach is as follows: let luanti be translated :)

In case #16862 (comment) was not clear enough: I can see the issue you are trying to solve, and I do not question the goal of supporting translations; what I asked you to explain is why you chose to do so by directly adding game-/mod-related strings into the engine and why you consider this to be acceptable from the perspective of maintenance (among other things). In my previous comment, I have listed a number of issues that would be created by your PR; these issues would not exist if we chose to implement #9070 (comment) instead, which is what I am trying to do in #16865.

So please explain why you consider it acceptable to have the follow-up issues I mentioned in #16862 (comment); and the answer should be more than "this PR works".

[y5nw]

"what I asked you to explain is why you chose to do so by directly adding game-/mod-related strings into the engine"

To keep it simple

As I explained in #16862 (comment), this "simple" solution has the problem that it introduces maintenance burden in the future for everyone:

• We as engine developers would become responsible for updating content that we are not responsible for.
• Content developers would need to separate settings strings from other parts of the mod/game and report these to us.
• Translators contributing to mods would have to do so by working on two places.
• Translators contributing to the engine would also need to help translate strings without knowing the context of these strings.
• Players must wait for the next engine update (not just the mod update) to see translations for mods.

This burden is unwarranted in that this can be entirely avoided by properly allowing mods and games to provide their own translations for settings, as suggested in #9070 (comment).

The question is why you consider your "simple" PR acceptable given the above issues.

Every problem has a solution.

Then please provide a solution to what I wrote above.

Discuss it with your colleagues to get an informed opinion. Are we in agreement ?

If you believe my current opinion is uninformed you can write that out explicitly.

[alrito28]

I don't have a solution, and you're right. I may be rushing, but I understand as time goes by. Do what you have to do, but in the meantime, I don't see my language in the settings :(