A few messages in client are not yet marked for translation, would not be localized as of today:
To be continued..
Above mentioned strings in ctelnet.cpp sometimes have excessive space characters as in
[ INFO ] - text
as opposed to
[ INFO ] - text
like it is used elsewhere. Maybe use this opportunity to unify, as connection scroll currently alternates.
edit: Damn, github will nix the double space character after the first [INFO] and before the minus there.
Currently can't seem to find where these messages are created:

Searched this repository for "Lua module" text, but did not produce.
Thanks Vadi. Maybe there is something wrong with the search function here on github.com and I should really search the downloaded files myself. What a pity!
SlySven reported:
One place I spotted that was not been fed with tr(....)wrapped texts was the item type comboBox on the end of each trigger item - so those will never get translated into other languages...
Not sure where this is located, third party module?

@Kebap wrote:
Above mentioned strings in ctelnet.cpp sometimes have excessive space characters as in
[ INFO ] - text
as opposed to
[ INFO ] - text
like it is used elsewhere. Maybe use this opportunity to unify, as connection scroll currently alternates.
edit: Damn, github will nix the double space character after the first [INFO] and before the minus there.
The spacing in the [ WORD ] - was ~tweaked twiddled~ frobnicated such that there is either one or two spaces (depending on WORD length) between the WORD and the [ or ] (the same on BOTH sides) and then enough spaces after the ] and the - so that all the different messages have the same number of characters - if I replace spaces with # it is perhaps easier to see as they become:
[##OK##]##-#
[##LUA##]#-#
[#INFO#]##-#
[#WARN#]#-#
[#ALERT#]#-#
[#ERROR#]#-#
This was done with the desire to ensure that all the messages have the same prefix length. However the existing code is not good for translations yet (I think I have code tucked away somewhere that {on language change} did a scan through all the translated headers and worked out the spacing to use for both them and any untranslated texts - even those with a single additional untranslated message marker prefix (the Qt default is # as it happens) so that this still worked for incomplete translation cases...
... however that has not been something that Vadim found if he was rummaging around in my previous I18n code attempts, assuming I ever published it... :disappointed:
Let's move that discussion to #2005 shall we?

main.cpp around this area, research "show_splash"
Connection Popup will show "Cancel" button which stays in English and is not available for translation, yet.

Probably alike connection strings above
Trigger editor:

Code: https://github.com/Mudlet/Mudlet/blob/development/src/dlgTriggerEditor.cpp#L619
Re: Splash screen text - translation is not straightforward because the splash-screen is displayed before the main UI is constructed and the translation system is loaded.
I solved this in at least one of my versions that allowed run-time changes in the UI language without restarting Mudlet by: writing the translated strings out as a QStringList to a file in the Mudlet config directory (splashScreenTexts.dat IIRC) whenever the language was changed.
IIRC I also included a first entry being a count of the number of lines to avoid nasty problems if the number of different texts changed in later versions of Mudlet so that there was less lines in the variable than the code expected!)
On starting up Mudlet would load the default (en_US) text into a QStringList and then try to load that file and if it was present it would use it to overwrite the contents of that variable before then using whatever was then stored to generate the messages...
Connection Popup will show "Cancel" button which stays in English and is not available for translation, yet.
That is because the standard dialogue buttons are provided by the Qt library and the hackary done by Vadim to simplify my run-time UI changing code did not quite get it right.
My old code would, IIRC, allow the translation files source to be changed - so that one could change from a compiled-in set in a resource to an external set in the file-system - which could be edited on the fly and then reloaded; this meant that it had to check what translation files were available - by trying to load each one but not putting it into use - every time the dlgProfilePreferences class was used and the translation files source was changed. This code has been refactored to use a lambda function defined in (void) mudlet::loadTranslators() but it was only to do the Mudlet files - it did not load the Qt ones and the current code that tries to call the now anonymous function to do that is just plain borked... :stuck_out_tongue_closed_eyes:)
:bulb: I've got some code stashed to one side that will sort out that aspect of the Editor... :grinning:
Closing a profile without autosave - "Would you like to save this profile" will be translated, but not the options for answering: "Yes", "No", "Maybe" ah I mean "Cancel"

Headlines for columns in search pane in editor window.
edit: dlgTriggerEditor.cpp lists these texts here: https://github.com/Mudlet/Mudlet/blob/4dfafa21ca97875946d5335d8ee1e9f6141b4c39/src/dlgTriggerEditor.cpp#L602

Package exporter (experimental) dialog window

Profile creation window
Just need to update Crowdin strings to make those available!
In retrospect, we should have updated them as soon as development got merged.
I believe all of these are updated now, right?
I believe all of these are updated now, right?
I am not sure about _all_, haven't checked them in a while. For some, I am not even sure where they originate from. SlySven even mentioned some standard dialog buttons which didn't get translated at all.
So I went through and checked all of them, and the only thing left to tackle here, is the start-up splash screen.
SlySven mentioned above how this is a bit more difficult to solve, as the tr() function is not yet available during that time.
https://github.com/Mudlet/Mudlet/issues/1964#issuecomment-443542921
However it should be doable. I think I saw it done before somewhere. Just not sure spontaneously how the function is called at that time.
What about simply removing the text from the splash screen?
For most machines it starts too fast to read, and the information there is hardly useful or essential.
Fair enough, closing this then.