Improve developer tools for localization on the client side

[WebVPF]

At this stage, translations for the plugin are useless. It is controlled from javascript. Here are all the script lines that need to be localized:

https://github.com/wintercms/wn-notes-plugin/blob/f9937edf69e078127276d2ee5aca1a9cca59337f/formwidgets/notes/assets/js/notes.js#L314

https://github.com/wintercms/wn-notes-plugin/blob/f9937edf69e078127276d2ee5aca1a9cca59337f/formwidgets/notes/assets/js/notes.js#L401

https://github.com/wintercms/wn-notes-plugin/blob/f9937edf69e078127276d2ee5aca1a9cca59337f/formwidgets/notes/assets/js/notes.js#L453

https://github.com/wintercms/wn-notes-plugin/blob/f9937edf69e078127276d2ee5aca1a9cca59337f/formwidgets/notes/assets/js/notes.js#L459

https://github.com/wintercms/wn-notes-plugin/blob/f9937edf69e078127276d2ee5aca1a9cca59337f/formwidgets/notes/assets/js/notes.js#L496

https://github.com/wintercms/wn-notes-plugin/blob/f9937edf69e078127276d2ee5aca1a9cca59337f/formwidgets/notes/assets/js/notes.js#L565

https://github.com/wintercms/wn-notes-plugin/blob/f9937edf69e078127276d2ee5aca1a9cca59337f/formwidgets/notes/assets/js/notes.js#L683

https://github.com/wintercms/wn-notes-plugin/blob/f9937edf69e078127276d2ee5aca1a9cca59337f/formwidgets/notes/assets/js/notes.js#L731

[LukeTowers]

@WebVPF I appreciate the help; however I was thinking of making it easier to deal with client side translations in Winter CMS in general. One idea I was thinking up was building upon Vue I18n and providing it as a Snowboard plugin with a layer of niceties to make it more similar to dealing with localizations on the serverside with the per plugin / theme / module namespacing as well as having it able to be powered behind the scenes with JS files compile with winter:util compile lang ?package or something like that.

@bennothommo @jaxwilko @mjauvin @datune any thoughts?

[mjauvin]

@LukeTowers do you mean making AJAX call from JS to the serverside which would return translations dynamically or something different?

[WebVPF]

Why compiling files with translations is bad:

• because we will remove the ability for the user to redefine the translation as he needs https://wintercms.com/docs/plugin/localization#overriding

[bennothommo]

I reckon we can do this without necessarily tying it to Vue I18n - I do like that library, but it is intrinsically tied to Vue, and I'd rather keep Snowboard agnostic.

I did originally think that we could just use AJAX to load in translations dynamically, but I worry about having to hit the server every page with an AJAX request.

At the moment, the most graceful idea I've come up with is to introduce the concept of "scopes" in the Lang class on the PHP side, and basically get everything that will be loading in the current page (ie. components, theme) to request a scope when required. As part of the page rendering, we would then collate all requested scopes for the selected language and include them in the page content as some form of meta (perhaps a data bag in a script tag at the bottom of the page). Only issue with this is it'll potentially increase the page size.

[LukeTowers]

Personally I still like the idea of compiling the language files, support for the project level overriding of language strings is easily achieved by calling Lang::get($groupCode) rather than loading the file content directly as that will pass it through the translation system first which will apply the project overrides for us. Asking users to run a single command after populating their custom language overrides isn't that big of a deal, we'd probably just want to make sure that instructions for tracking the compiled files in git are included in the documentation so they can more easily make the change of how to handle the deployment strategy for those files.

Compiling the language files has several benefits, namely that they can then be located on a CDN and cached which is much better for performance than making API calls over AJAX or even pregenerating the data to embed in each rendered response. It also means that they can be loaded only when actually needed as the client itself can handle loading the specific compiled files for the language that it is actively using.

[bennothommo]

Wouldn't precompiling it to a file still require it to be brought in through AJAX? Or are you talking about generating a file somewhere and loading that in a link tag or something?

[LukeTowers]

I'm talking about generating a file somewhere and loading that in a link tag yes. We could potentially look at leveraging the Asset Compiler functionality to add support for loading combined localization files in somewhat the same way we do for existing JS / CSS files. We could also look at revising that functionality somewhat to bring it more in line with the ImageResizer's deferred compilation / compiling to static serveable asset files.

[bennothommo]

I'd prefer if it were something we could do without a command. I think with most of our command usage at the moment, it's been something for actual development on Winter itself (although I'll give that Snowboard / the mix commands will blur this line).

I'd be happy with the Asset Combiner handling it if it does the compilation in a way similar to the CSS / JS compilation - compiling it on the first use as required, then using the cache for all subsequent requests.

[LukeTowers]

Brain dump for reviewing later:

Some options out there:

• https://kazupon.github.io/vue-i18n/
• https://stackoverflow.com/questions/55957319/how-to-call-vue-i18n-from-non-vue-class
• https://phrase.com/blog/posts/the-best-javascript-i18n-libraries/
• https://github.com/airbnb/polyglot.js
• https://airbnb.io/polyglot.js/
• https://github.com/globalizejs/globalize
• https://medium.com/@jamuhl/vue-js-from-internationalization-i18n-to-localization-l10n-and-back-again-c3e5f7cc5e71

[bennothommo]

Oooo, I like Polyglot. Might be worth wrapping that for Snowboard.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 60 days. If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue. If this issue is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in this issue for the last 6 months. If this issue is still relevant or you would like to see it actioned, please respond within 3 days. If this issue is critical for your business, please reach out to us at wintercms@luketowers.ca.

[joseph-sm]

@LukeTowers We are most likely be looking at this shortly, in past projects we using packages that compiled a json file from the laravel translation files which was then added to webpacked javascript and vue-i18n, this does increase the bundle size but at least makes all the translations available in javascript, I can see how this would get messy with plugins and modules.

Not all the plugins use webpack.mix so the above way would not be possible very easily, so basically if a plugin / module has a lang folder would it just make a json / javascript file and combine that in asset generation per plugin / module?

[LukeTowers]

That's the general idea @joseph-sm, although the idea is for the language files to not be bundled with anything else, just be their own separate cacheable files.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in this issue for the last 6 months. If this issue is still relevant or you would like to see it actioned, please respond within 3 days. If this issue is critical for your business, please reach out to us at wintercms@luketowers.ca.