Remove unneccessary strings from translation

[Kebap]

Brief summary of issue / Description of requested feature:

This is collecting strings found by translation teams in Crowdin which should rather stay English

Expected result of feature

Remove .tr() function in source, so strings do not get sent to translation teams anymore

List of issues in this issue

• • command line options
    • • These were included twice, once for the popup, and once for the call via command line - removed by PR 1998
    • • They may not need translation at all as discussed in Crowdin here for example
    • Maybe only translate texts, but definitely not the options themselves. This needs comments for translators
    • Maybe split these into multiple lines? Also there is the random "keyboard" line, as seen in crowdin. Does it get merged back in ok when translated?
• • debug messages

[Kebap]

Mudlet's command line options as found in main.cpp starting around this area don't need translation as discussed in Crowdin here for example

[vadi2]

loadMap: NULL Host pointer {in TConsole::importMap(...)} - something is wrong!
loadMap: unable to initialise mapper {in TConsole::importMap(...)} - something is wrong!

These should not be translated - if they come to us in Chinese (and they will), we'll have no idea what is going on.

[SlySven]

The particular example that @Kebap shows has gone away as those dialogue boxes (for --help and --version ONLY on WINDOWS) have being removed by #1998 - OTOH the command line output should be in the user's locale if it has previously been set - though that can be awkward if the translator loading is only being loaded for the GUI case... 🤷‍♂️

Oh, I just checked the reference and I see that the same sort of thing will crop up in the text used for all OSes now - the text is presented as large blocks of writing but the parts that are the actual command line arguments (the --Xxxx bits) in the help text must not be translated - and there is not documentation/comment about that... sigh

What you are saying @vadi2 about (bool) TConsole::importMap(const QString& location, QString* errMsg) does make sense - when it is being called from TLuaInterpreter::loadMap() and the second argument is NOT a nullptr then the string should not be translated as you point out...

[SlySven]

OTH I think they are not messages that should be encountered unless something has gone seriously wrong in the rest of the application - so a foreign error message will just be the 🍒 on the 🍰 ,,,

[Kebap]

1. I don't understand @SlySven comments about the command line arguments and their descriptions. These texts would be the same, no matter if shown in dialogue boxes or command line window, right? So then, they should remain English, right? So then we still want to remove them from translation, as described above.

It seems like the PR mentioned does remove dialogue boxes from existence. The decision stays unchanged: Remove these texts from translation. So for example a German Mudlet will still be (only) usable with English command line arguments, and receive English explanation thereof.

It also seems like the discussion in Crowdin I linked above is gone, as the strings from the dialogue boxes are gone. Which is unfortunate. This has implications for other discussions and decisions arived at in Crowdin. They may need to be backed up outside for future reference.

2. Yes, we already have Chinese translations for those, and yes I agree these don't need translation neither.

[SlySven]

I mean when localised the text presented on the command line needs to be in the user's selected locale but the actual command line options displayed within the output for the -h/--help option do need translation to the language concerned. It is not acceptable IMHO for a application running in a German locale to give an explanation on how to invoke itself with an English text...

... OTOH Vadim has not seen code I prototyped (but then mislaid) to detect the user's/system's locale and load the appropriate translation automagically - the main niggle with examining/using QStringList QLocale::uiLanguages() const to select the best translation automatically from the user/system settings (on *nix systems the LANG environmental variable) is that the Qt library will not report which locale it has found and used if multiple ones are validly specified (e.g. something like LANG=de_DE.utf8,fr_FR.utf8 for someone bilingual in French and German) - see the four year old QTBUG-36608!

[vadi2]

Is this still a problem?