Open modos189 opened 5 years ago
May be there other translation projects exist (it seems I saw something like 'iitc i18n', but not sure)
I would like to integrate the translation into Japanese in iitc v0.31.
Bold plans)
- In IITC code and plugins, html and logic are mixed.
It is. Incredibly mixed.
Is vue.js
able to help with internalization considering our current code base?
Is vue.js able to help with internalization considering our current code base?
It is enough to display text as markers. For example, replace Redeem code…
with $t('Redeem code…')
.
But in some parts of the code, the text is built from parts, where it will need to be reworked.
For example, replace
Redeem code…
with$t('Redeem code…')
.
Do we really need vue.js
for this?
It can be done in our own code, in not more than a couple lines of code.
Anyway the most work will be prepare our text strings for this. And after we'll get this done - our code base become even more messy.
So I propose to do it in a good way from the very start. Like you said - divide code and logic.
Yes, we need vue.js because it builds a Dynamic DOM and allows to update markers after localization plugin is loaded. Also important thing - pluralization.
allows to update markers after localization plugin is loaded.
It's cool (really), but is it absolutely necessary? Localization plugins can be just loaded earlier.
Also important thing - pluralization.
Again, this is cool, but not absolutely necessary.
Yes, I want ideally-implemented iitc localization too. But I prefer to solve other iitc codebase issues first.
BTW, I also believe that we should resolve #2 before major rewrite, otherwise old patches will not merge clean.
I used Ractive, but in this case it is not suitable.
https://github.com/i18next/react-i18next?
But size increase is undesirable (if we use it for internalization only).
BTW, what is overhead using vue?
Localization plugins can be just loaded earlier.
We can? Even if this case, then the initial page construction takes place in context of extension, so part of it won't be translated
resolve #2
Yeah, although there's only change left in plugins.
i18next/react-i18next
I used ractive, not react. React, too, is not suitable for us - it, like ractive, requires creation of a template, result of which is displayed on the page. Vue allows to use an existing page as a template, making it easy to migrate applications to Vue. In compressed mode this adds 91kb for vue.min.js and 22kb for vue-i18n.min.js.
By the way, there is both an uncompressed version of Vue for development and a compressed version for production. In the compressed version some messages for developers are disabled. We will need to add a flag to our build system, whether to use a compressed version of the files, if both are present.
I do not think translating the IITC is a priority at the moment, for me the priority is to fix the existing bugs and prepare the project to receive new design. I also think that a parallel project to rewrite the IITC in another language is interesting. is something that would take many months of work, since iitc has already become a big project, the current IITC problem is the blending of the codes, the mess it makes, fixed bugs in place bringing bugs elsewhere.
We can?
Sure. And I am going to implement this anyway, as I do not like current way of extending some things, which now requires window
-constants (like in #201)
initial page construction takes place in context of extension, so part of it won't be translated
We can delay initial page construction.
May be we can offer primitive string replace-based localization without any framework?
No
Why? It's better than nothing, and can be reused later, when we'll be ready to implement it better.
Create separate IITC builds in other languages?
Yes.
In IITC-Button successfully implemented Vuejs and localization. However, Ractive was used instead of Vuejs before, so the structure is similar. I think there shouldn't be any problems with implementing Vuejs in IITC
I am not good in IITC-Button code, sorry. Could you provide sample draft PR (for small part of code) to illustrate upcoming changes?
Old iitc discussion: https://github.com/iitc-project/ingress-intel-total-conversion/issues/247
https://github.com/yohanboniface/Leaflet.i18n seems simple.
The point of the problem:
In IITC code and plugins, html and logic are mixed. This complicates code support and does not allow to implement some features.
Outside of developer community, many users have a very poor understanding of English.
The specificity of our project is the work in context of both extension and in context of page; plugins are used to extend capabilities. We need Virtual DOM to work with localization.
We cannot rewrite everything to another technology because of the size of project and presence of a large number of plugins.
In addition, there is already a project to translate IITC to Japanese. Of course, there English strings are simply replaced with Japanese ones.
The proposed solution to the problem:
I've connected Vue.js and created a test translation with the help of a plugin. I have not noticed any conflicts, it works well with jQuery and our project.
At the first stage, we can use Vue.js only for localization work, and then rewrite components into new technologies in small parts.
I would like to integrate the translation into Japanese in iitc v0.31.
The downside is that I haven't worked with Vue.js yet. I used Ractive, but in this case it is not suitable. Besides, it will increase the size by about 110kb.