About multi-lang support

[xiaozhikang0916]

This issue is not only about current repo, please also consider the Chinese-ver 74EO and the original one

I am opening issue in this repo because it's more active project than other two currently

Found that all the displaying strings are hard-coded in code, and this project is using if-else to support multi-lang displaying ( and replacing all jp string to cn in Chinese-ver 74EO ). Is there other way to implement this feature?

As an Android developer, I am considering if it can be done like what Android does ( for short: get the string you want to display by id from a resource manager, and the manager loads different resource file according to user settings ) but I am not sure if there is any disadvantage. And I am not sure if the Resource in C# is designed for this purpoes because I am not thar familier to C# programming.

[RadarNyan]

It's intended.

I don't like the resource file approach as it has very very bad readability, and it can be very frustrating when it comes to word order difference across languages.

Using inline switch approach allows me to see all the locales while updating the code, so I don't need to mess with resource every time I add/remove something. Using inline approach also grant me the power of String Interpolation, which helps code readability soooo much.

Also it's very easy to find all the locals (just do a full-folder text search for case "zh": with any modern text editor and everything would come up) comparing to resource file approach which I had to jump across different files.

I'm going to use this approach in my fork of 74EO in the future so I can avoid having so many merge conflicts.

[xiaozhikang0916]

In current situation, you need to handle all the language issue, or the translation volunteer, if any, needs to open the whole project, change the string and open a pull request to apply his/her translation.

But with resource files, volunteers can easily dispatch a new language style in a form of language pack, without dealing issue of code or release a new version, and it can have a more light weight to fix text issue. (Though it needs support of the author of original repo)

[RadarNyan]

It's true that having all the locale strings stored in a language file is far more easy for translators to work with as they require any build environment. They are more popular because they don't require the software source code to be available.

However, from the experience I had before doing translation for other programs, it's really frustrating to figure out which string response to which part of the program, I often need to launch a program several times just to figure out where (and how) the strings are used.

To support that kind of approach, all the strings in the program would need to be replaced with variables - it might be acceptable for English programs as there's a good chance that the original string could be used as variable name without hurting the code readability too much, however it's a very different story when it comes to Asian language - there's no way, NO WAY I'd allow non-English variable names in the code, PERIOD.

And finally, the sole purpose of this project was to create a Chromium based browser for ElectronicObserver - which itself doesn't have any kind of i18n support at all. I only added this multi language support (I didn't call it i18n support deliberately) so I don't have to maintenance two separate versions (for original and my translated fork)

Off topic, but now it seems that ElectronicObserver is gonna using Cef as well instead of something with Edge, which makes this project kind of obsolete. Not sure if I'm gonna continue this project, there's a good chance I won't if the original version works good enough.