IITC-CE / ingress-intel-total-conversion

intel.ingress.com total conversion user script with some new features. Should allow easier extension of the intel map.
https://iitc.app
ISC License
283 stars 109 forks source link

Localization, vuejs and future redesigned #200

Open modos189 opened 5 years ago

modos189 commented 5 years ago

The point of the problem:

  1. In IITC code and plugins, html and logic are mixed. This complicates code support and does not allow to implement some features.

  2. Outside of developer community, many users have a very poor understanding of English.

  3. 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.

  4. 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.

johnd0e commented 5 years ago

project to translate IITC to Japanese.

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)

  1. 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?

modos189 commented 5 years ago

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.

johnd0e commented 5 years ago

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.

modos189 commented 5 years ago

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.

johnd0e commented 5 years ago

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.

johnd0e commented 5 years ago

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?

More offtopic As for size: Colorpicker for draw-tools (spectrum.js) alone is 100k (uncompressed). I will look if we can replace it for something lightweight. jQuery (+UI) also takes much space, and later we perhaps may consider to use some compatible alternative (maybe jquery mobile, or zepto/cash/dabby, or i-do-not-know).
modos189 commented 5 years ago

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.

Suburbanno commented 5 years ago

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.

johnd0e commented 5 years ago

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.

johnd0e commented 5 years ago

Chinese https://github.com/paizi/ingress-intel-total-conversion/commit/0fa181c7e551b89fb9be21af03450031997e538c

May be we can offer primitive string replace-based localization without any framework?

modos189 commented 5 years ago

No

johnd0e commented 5 years ago

Why? It's better than nothing, and can be reused later, when we'll be ready to implement it better.

modos189 commented 5 years ago

Create separate IITC builds in other languages?

johnd0e commented 5 years ago

Yes.

modos189 commented 5 years ago

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

johnd0e commented 5 years ago

I am not good in IITC-Button code, sorry. Could you provide sample draft PR (for small part of code) to illustrate upcoming changes?

johnd0e commented 5 years ago

Old iitc discussion: https://github.com/iitc-project/ingress-intel-total-conversion/issues/247

johnd0e commented 5 years ago

https://github.com/yohanboniface/Leaflet.i18n seems simple.

johnd0e commented 4 years ago

https://github.com/Download/i18nline