-
Notifications
You must be signed in to change notification settings - Fork 109
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
Comments
May be there other translation projects exist (it seems I saw something like 'iitc i18n', but not sure)
Bold plans)
It is. Incredibly mixed. |
It is enough to display text as markers. For example, replace But in some parts of the code, the text is built from parts, where it will need to be reworked. |
Do we really need Anyway the most work will be prepare our text strings for this. 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. |
It's cool (really), but is it absolutely necessary? Localization plugins can be just loaded earlier.
Again, this is cool, but not absolutely necessary. Yes, I want ideally-implemented iitc localization too. BTW, I also believe that we should resolve #2 before major rewrite, otherwise old patches will not merge clean. |
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 offtopicAs 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). |
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
Yeah, although there's only change left in plugins.
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. |
Sure. And I am going to implement this anyway, as I do not like current way of extending some things, which now requires
We can delay initial page construction. |
Chinese paizi@0fa181c May be we can offer primitive string replace-based localization without any framework? |
No |
Why? |
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. |
Old iitc discussion: iitc-project/ingress-intel-total-conversion#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.
The text was updated successfully, but these errors were encountered: