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

[gedw99]

I did this before and did it this way.

Flow:

1. Automatic machine translation done using Providers
2. Humans can review and Override the machine translation
3. Packaging
4. Server CMS

Step 1 is treated like a cache , so the whole process is idempotent and if the hash of the text is the same then you use whats already there. This also avoids the merge problem.

Step 2 is required because of mistakes but also layout in a GUI and also per locale differences that always crop up. Also machine make screwups and you can do an overide back into the file format.

When running any App, these can all be changed at runtime. Should be so that you can see where the translation came from and then override it if need. This is why Providence and Overrides become so important in the data format used.

Packing. This is tricky. It's common for apps to get bigger and bigger and the translations files can get huge too. So some like to keep the translation pace external and some dont. This is why you kind of end up with I18n CMS.

Self similar extension. Because Text is very often reused between not just apps but Orgs, you end up wanting a way to have the thing be a server of sorts. A CLI can obviously also run and expose a simple HTTP API for this later.

Storage in git is referred. Some orgs use a mono repo, some use a single repo for all their translations. This is also where Overrides comes in again, because you can then do overrides in each App without touching the Org main repos / ontology.

Images are also often per locale too. So you can use the exact same architecture for images too, and so then override per locale.

This is where git LFS is great so you can just store all the text and images in a repo, mono repo, take your pick.

Locale overrides. At runtime, it's also good like @ddkwork said, to allow users to override what locale is used. Makes UAT testing way way easier too.

By the end of it you kind of end up with a CMS that is git LFS based. With a simple bleve indexer and searcher that watches file mutations you can have simple search too. This is useful for the Orgs and Apps concept. The main thing is there its all self similar.

[kkoreilly]

Thank you for this information! We will take this into consideration when we implement internationalization as part of #9. We will do that after we finish WebGPU (#507) and GopherJS (#974) support.