i18n

[ddkwork]

use this for support i18n

https://github.com/richardwilkes/toolbox/blob/master/i18n/i18n/main.go

[kkoreilly]

I will look into this more soon and hopefully resolve #9.

[ddkwork]

I will look into this more soon and hopefully resolve #9.

I can try to make a PR, but this idea changes too much, I don't know if it will break compatibility, because this logic is like this: all core source code uses strings to call the functions in the i18n package, and then we use the AST package of the go standard library to parse all the calls in the syntax tree containing the methods in the i18n package before any app initialization and save them to a map, the key value pair of the map is a translated copy of multiple Chinese, when we complete the translation, Before the main function is called, load our translated map file into memory, at this time, all GO code calls i18n will query the map key-value pair in the language file we specified in the main function, and each call will return the MAP key:English corresponding value: the text we translated.

https://github.com/richardwilkes/gcs/blob/master/ux/about.go#L57-L58

[kkoreilly]

You can see more discussion about how to do this in #9. What you said is the general concept, and the question is whether we can get away without having everyone have to call internationalization functions manually. Also, we need to figure out whether we can have this without bundling a ton of translated text for every language in each app; each user should only need one language. We also need to figure out how we can support both automatic machine-generated translations and custom translations. I think we should keep discussing this and figure out a good solution before you do a PR.

[ddkwork]

You can see more discussion about how to do this in #9. What you said is the general concept, and the question is whether we can get away without having everyone have to call internationalization functions manually. Also, we need to figure out whether we can have this without bundling a ton of translated text for every language in each app; each user should only need one language. We also need to figure out how we can support both automatic machine-generated translations and custom translations. I think we should keep discussing this and figure out a good solution before you do a PR.

In China, it is still very troublesome for the translation engine provided by the Internet, at present, Google Translate is not accessible, and it is also troublesome for other translation engines to register or something, a few months ago I tried the AI translation engine and found that if the sentence is very short, the translation result is not satisfactory. In fact, every application should not be just one language, English is used all over the world, although I only know a little English, however, if I develop a software that you are using it, then I want the language of this software to be understood by people in other countries, so English is a must, but if my colleagues are also using it, then the application should provide a menu to switch to the Chinese interface. This issue does require more communication and research