[Discussion] Support multiple languages

[Flavsditz]

Context
The idea here is to allow more people to use the application by translating to several languages and reach a wider audience who might not have a full grasp of the english language and thus feel more comfortable in their native language.

Solution idea

• Add 1..N JSON files (alternative using YAML) with language codes
  • These will contain all strings that are used in the UI
• Add an language menu that will get generated from the list of those JSON files (so it dynamically reacts to additions of languages)
• A class would take care of receiving the word/phrases keys and return the corresponding values of the currently selected language
  • If the key is not available or empty on the requested language we should fallback to the default english case
• I would go through the whole project and replace the sentences with calls to the aforementioned class with the corresponding key.

Notes/Questions:

• Contributions for translations could be done by other people such as the user in issue #212
• There are existing solutions but I would study them to see if it is not just simpler to DIY and keep the code as lean as possible.
  • python itself has (internationalisation options)[https://docs.python.org/3/library/i18n.html]
  • there are also other packages such as python-i18n
• By going through the code I've noticed a lot of ENUMS being handled as strings. While this would work even with the solution above I would be willing to refactor that (could be in a separate MR) into a proper ENUM usage and just on the UI touching parts use the translations. These are used through the code for comparisons too
  • Example of this situation: When adding a grain there is an option dropdown with the values Neither/Top/Bottom/Both
• I see a lot of comments about performance. Was there a code analysis done? If so which tool? I would love to take a look into this (just curious)

I'm glad to hear opinions and to have a nice discussion

[reilleya]

This would be awesome! It might be worth it to investigate if Qt has localization support as well. Either way, I think you have already found the biggest issue, which was that I was pretty sloppy when designing the file format and used UI strings as keys instead of proper enum keys. That was also what caused #193 to stall out, so I think it would be a great issue to tackle first, maybe prior to full localization. It'll likely need a migration to adapt old files to whatever new format we decide on.

[Flavsditz]

Ok that sounds like a plan!
I'll start by tackling the ENUM topic (I really enjoy refactoring :) ) and we can move on from there.

I was thinking and just want to put the idea out here for future me: that the best solution for the internationalisation would be something where adding a key to the default or a "master/main file" would copy to all others. This would guarantee that all files are always in sync.
I would look if this is a feature on another existing library or at least add it to the compilation pipeline (and maybe add some info output of missing translations and where help could be given)

[reilleya]

That would be super useful to help them stay up to date. And maybe if the value for a key is empty, it falls back to the default english value?

[Flavsditz]

Yes! This was what I proposed in the original idea! It is a must otherwise gaps would appear everywhere!

[Flavsditz]

I've finally finished the ENUM refactor (sorry for the delay but life got in the way).
I have also raised a couple of ideas that I would be glad to take on and I wanted to hear your thoughts or if you think it is ok if I do it @reilleya. A lot of them are really low-hanging fruits [LHF] but would touch the whole project.
Each could be its own PR so it is easier to review. Here are the ideas:

1. [LHF] Cleanup and organize imports - there are so many unused imports throughout the files and it would be a quick clean
2. [LHF] Organize the code to respect the PEP-8 - i.e. blank lines, remove redundant parenthesis, etc. (my IDE points to over 1000 warnings due to this)
3. Make code "python conform" by following the PEP-8 guidelines: For example, variables should use snake_case instead of camelCase
4. [LHF] Make file names also PEP-8 conform
5. [LHF] Remove local imports such as motorlib.XYZ.method_name in favor of regular imports
6. [LHF] Improve variables that are single letters such as the ones in the propellant.py which are "a", "n", etc...
7. [LHF] Correct spelling mistakes and typos in docs (currently my IDE can find 350 typos and 24 grammar errors)
8. [LHF] Fix the dependencies to give more control - This seems to be in the pyqt6 branch already per this message
9. All dictionaries, especially the props used in files such as propellant.py or nozzle.py should make use of constants for keys or be elevated to an object which can have a dict inside but hide the access through functions to avoid misspelling and other unintended access mistakes.
10. The simulation output details message is cut (using the ellipsis) due to space which makes the message impossible to read. It is worth it to make it multiline...

Ok, that was all my notes on the easy stuff. There are probably other discussions to be had on how to best organize code, too many classes in the same file, etc. but the above would not make changes to the code logic itself (especially 1-8) and would make it cleaner or at least match the python way of doing things.
If you are interested in any of the above I would be glad to keep contributing. I am also glad to jump into a call (discord or whatever) to discuss anything.
This has been quite fun to work with so I am glad to continue to contribute a bit