utf-8 Support and Enhancements on Internationalization

I do really appreciate your work on this, but this pull request has the same issue as the previous one, as it is undoing all my most recent changes.
I think what must have happened, is that you copied a previous version of the program, made your changes, fast-forwarded to the newest version of MH, and then copied your changes over top. In order to fix it, you'd have to rewind to the old commit, add your changes in, and then merge in the new commits.
I don't think it's possible for me to fix this without also removing your authorship over these commits, so I think it'd be better if it were fixed on your end.

I also gave your changes a quick test, and they do mostly work, which is really exciting, but unfortunately found that the graphics for most of the changed apps are slightly slower (in English it's slight. They are much slower in the other languages), and I was also getting lots of KeyErrors in different apps.

I think it might be a good idea to rethink the approach and simplify what we're doing here. I'd like to keep your translations, but I think it'd be good to redo the implementation somewhat.

For example, I think it would be a lot simpler for the translations to affect only the graphical text, and not change the underlying keys used by in every dictionary inside a given app. Currently, a lot is being done to try to ensure the keys are always translated, and this adds a lot of unnecessary steps to each cycle. I think it would make more sense to only add the translations into the 'drawing' functions.

The I18N class could also be modified for speed and memory usage, I think.
Currently, it is storing every translation as a dictionary inside a list, and every time a new translation is retrieved, it must scan through each dictionary one-by-one, searching through all of the values for the existence of a given string, and then finally returns the translated version of that string normally, by using the language string as a key for the dictionary. This feels sub-optimal, as not only are we having to blindly search for the appropriate item, but we also are mostly using the dictionaries in reverse (searching for values, not keys).

I think it would make a lot more sense to take the translations, and a "key" language ("en" for the current built-in apps), and convert the list of dictionaries into a single dictionary or key/values.
e.g.:

I18N = I18n(
    [
        {"en": "Enabling wifi...", "zh": "正在启用wifi...", "ja": "WiFiを有効にしています..."},
        {"en": "Connected!", "zh": "已连接！", "ja": "接続されました！"},
    ],
    key="en",
    target="zh",
)

# result:
I18N.translations = {
    "Enabling wifi...": "正在启用wifi...",
    "Connected!": "已连接！",
}

This would mean that, in order to retrieve the translated text, all you would need is one dictionary lookup.

Final note:
The changes to st7789.py make a lot of sense, but I think they need to be Viperized for speed, and ideally shrunken a bit (for memory reasons). I haven't played around with this yet, so I'm not sure what these changes might look like. I could probably make these changes myself, but I'm not sure how quick I'll get to it :)

Final FInal note:
I also would much rather the language setting be a dropdown menu. Unfortunately that's not implemented yet, but I'm happy to make that change myself!

Anyways, I hope these critiques don't scare you off of this idea, haha. I just have a lot to say about MicroHydra 😊

echo-lalia / MicroHydra

utf-8 Support and Enhancements on Internationalization #120