Implement multilanguage support in the vue frontend application

[dneukirchen]

• Use the default joomla language files

Vue Plugins:

• https://github.com/kazupon/vue-i18n

[laoneo]

We can also use the Joomla way Joomla.JText._('COM_MEDIA_LANGUAGE_STRING');.

[dgrammatiko]

I will also support @laoneo way, for the default joomla language files

[yvesh]

I told you @dneukirchen :)

[dneukirchen]

With plugins like https://github.com/kazupon/vue-i18n we will also use the default joomla language files (.ini´s).

I dont like Joomla.JText and i think the technique is not ment to be used with powerful tools like vue, angular and react. It feels more like the quick and dirty solution, but i will give in to the majority.

[mbabker]

The "issue" with Joomla.JText is it requires you to preload strings on the PHP side so they can be used with a request, it's not designed for a JavaScript frontend at all like a Vue or Angular or React. Honestly, it'd be nice if we could do something similar to https://github.com/willdurand/BazingaJsTranslationBundle that creates a way to expose a language catalogue to the JS API, but that would also mean making JLanguage smart enough to be able to create a compiled catalogue with all the strings (and that's also impossible because of extensions overriding strings defined in other files so some of the JLIB_* strings have different text based on the active extension versus having a proper one key per string globally definition; funny enough I've got code to build the cached catalogue but it gets refreshed on so many page loads because of key overloading it's useless).

Though to be honest, Joomla as it is built isn't really designed to be used with a JavaScript application framework. So none of the existing tooling will just "plug" into a totally new application architecture. There's no winning solution to that issue.

[laoneo]

But are the ini files not automatically loaded on the first page request? And the ajax requests should return only translated data anyway. So why should it be a problem to use JText then from technical point of view?

I'm aware that there are better ways to bring in translations, but JText is the Joomla way and there will be a learning curve when we go with the vue approach, so when we can use existing Joomla functionality, then I think it twill make the entrance for others easier.

[dneukirchen]

I agree with @mbabker, but i think the feature (generate a compiled language string catalogue) is out of the scope of this project and could be a project on its own (especially when you have to find a clean solution for the overloading issue).

And for JText vs. vue i18n plugin:
The differences between those two techniques are not so big in our current usecase. We can go with JText::script for now, but this might have an impact on future decisions
(e.g. iframe vs. embed modals, vue for more parts of the backend, ...)

Lets discuss this in the next meeting.

[mbabker]

FWIW if there's anyone ever interested in toying with the compiled catalogue idea, this is the rough plugin code I've been playing with.

plg_system_languagecache.zip

[laoneo]

What we need to do is to encapsulate that translation stuff into one place in vue. So when we want to change it on some point, then we have one function to change.

[laoneo]

I made a first approach with a mixin which uses JText in pr #100. Later we can change it then to something more sophisticated when there is a need.

[dneukirchen]

Thanks allon.