Establish scalable pattern for translation exchange between server- and client-side

[asmecher]

We do not yet have a good, scalable way for translation contents to make their way from the .po files on the server side into the markup formulated by VueJS on the client side.

The current pattern involves identifying all the locale keys in PHP (via the template manager) and serving them to VueJS as part of state data. The PHP-side list must be manually maintained, which is a little painful.

Plugins should be considered; they can be added and removed at the will of the admin, which might mean more or less locale data needs to be provided to the VueJS environment.

Round-trips between client and server should be minimized. For example, it wouldn't be feasible for the client to be expected to fetch the .po files directly from the server and work with them client-side. Likewise, it wouldn't be feasible for each plugin to impose an additional round-trip.

[asmecher]

Proposal (thanks, @jardakotesovec!):

• During the build process for anything that includes VueJS and needs localization, a list of desired locale keys is generated and kept in the repo.
• A single cached list of locale keys is kept in the application's cache. (For example, OJS would keep a list in cache/ that lists locale keys required for ui-library, pkp-lib, OJS, and any installed plugins that required JS-based localization.) A cachebuster hash can be quickly computed from this.
• A server-side endpoint can be hit by the front end to return a list of translated content for a given locale (e.g. en). This can be cached server-side, and the cachebuster hash from above can be used to prevent client-side caching problems.

[jonasraoni]

I think the frontend should be able to require random locale keys, so in my opinion there should be some room for dynamic requests.
Possible flow:

1. First grab the "common" locale keys in a single request/embedded in the HTML.
2. Frontend requires N extra and non-existent keys.
3. A new request is made for them.
4. The full set of locale keys gets cached at the server.

Perhaps the step 1 can be removed with the help of computed fields + debouncer:

1. Localized content gets added to the interface using computed fields
2. Every translation request goes to a "debounced" function, which can accumulate all (or almost all) the keys for the current interface and fire a single request to load the translations. This would possibly decrease the amount of memory consumed by the UI (instead of holding all the possible translations, we'll keep only the used ones).

p.s. I didn't think much, just something that came into my mind 😂

[Godoy0722]

i'm thinking about if is there a way to don't need to do any requests (performance concerns because every page that is loading will fire one request for the backend to get the localized texts).

P.S.: I'm new here folks, please let me know if I'm saying things that doesn't make sense for the project! Haha

[jonasraoni]

The localization text isn't static, it's always updated at https://translate.pkp.sfu.ca, end users can also modify the texts through a plugin and add/remove languages.
Therefore, to avoid extra requests it would be needed to monitor for changes across all these possibilities to inline this data somewhere, which sounds like too much work for few gains (unless someone has other ideas).

Also, given the Vue stuff is only used at the dashboard, I think it would be ok for the user to wait a little bit on the first load, then the HTTP cache should speed up things.

[marcbria]

Sorry for asking the obvious but... do you know what similar projects are doing?
I mean, did somebody made a research on wordpress, drupal... or any other PHP based CMS?

I can't believe that we are the first to face this problem and I'm afraid that we are reliving the wheel. :-)

[jonasraoni]

@asmecher / @jardakotesovec I think this discussion can be closed with the introduction of the uiLocaleKeysBackend.json, right?

The only extra consideration that might be missing is how this thing is going to work with plugins... Can they re-use the t()? Should they compile their own uiLocaleKeysBackend.json or load missing locale keys on-the-fly? But maybe that's something for another discussion (e.g. #9116) 🙃