Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Localization, vuejs and future redesigned #200

Open
modos189 opened this issue May 15, 2019 · 19 comments
Open

Localization, vuejs and future redesigned #200

modos189 opened this issue May 15, 2019 · 19 comments
Labels
development general development issue enhancement New feature or request

Comments

@modos189
Copy link
Contributor

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
Copy link
Contributor

johnd0e commented May 15, 2019

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
Copy link
Contributor Author

modos189 commented May 15, 2019

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
Copy link
Contributor

johnd0e commented May 15, 2019

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
Copy link
Contributor Author

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
Copy link
Contributor

johnd0e commented May 15, 2019

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
Copy link
Contributor

johnd0e commented May 15, 2019

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

johnd0e commented May 16, 2019

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
Copy link
Contributor

johnd0e commented Jun 30, 2019

Chinese paizi@0fa181c

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

@modos189
Copy link
Contributor Author

No

@johnd0e
Copy link
Contributor

johnd0e commented Jun 30, 2019

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

@modos189
Copy link
Contributor Author

Create separate IITC builds in other languages?

@johnd0e
Copy link
Contributor

johnd0e commented Jun 30, 2019

Yes.

@modos189
Copy link
Contributor Author

modos189 commented Jul 7, 2019

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
Copy link
Contributor

johnd0e commented Jul 7, 2019

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 johnd0e added development general development issue enhancement New feature or request labels Jul 12, 2019
@johnd0e
Copy link
Contributor

johnd0e commented Jul 25, 2019

Old iitc discussion: iitc-project/ingress-intel-total-conversion#247

@johnd0e
Copy link
Contributor

johnd0e commented Sep 12, 2019

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

@johnd0e
Copy link
Contributor

johnd0e commented Feb 11, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development general development issue enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants