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.