Expose translation catalog to JavaScript code

[PeterNerlich]

Motivation

Translation catalogs with gettext are a neat thing. We write strings directly in our code, wrap them in the translation function, and the utilities find it and add it to the .po files directly. This is easy to translate, and when the code is run, the translation function just looks up the source string in the catalog of the selected language and returns its translation.

We currently only use this in python code, our JS is relatively primitive. In the few places where we dynamically need to set strings into the content, they are passed as values to data attributes that get rendered into the HTML by django using the translation function, and then it gets treated as a constant variable by JS.

Soon, it would be advantageous to have access to our translations in JS without needing to explicitly pass the needed strings from python – e.g. for #3745, when a preview of shortcodes should be rendered in the editor with extra hints only for the author (like when a page to be linked to was found, but no translation in the desired language).
Django offers a way to do this, as described in their documentation. What is left to do is a little research, and implementing it, it everything looks positive.

Proposed Solution

• Research: Find out…

  • whether strings need to already exist in python code in order to get picked up or whether they are also pulled into the catalog from JS files
    • or whether we can find an easy hack to have them pulled from JS files
  • whether we can easily have only a small subset be translated into many different languages
    (We want to have a few relevant strings translated essentially in all languages that municipalities use, but not the whole CMS)
  • An acceptable outcome of this research is "No, we won't use this functionality of Django"

• Make the adjustment in our code base and switch to this method wherever we currently use data attributes to pass translation strings

Screenshot

Alternatives

• Keep a separate translations catalog only for those strings and languages we need to use dynamically in the browser
  This is a bad idea because we already have a translations catalog and would ideally have all strings in there. However, the situation is a bit complicated already since the strings in question will be translated into a much larger set of languages than the rest of our system, so depending on what the research shows, this might turn out to be the better option

User Story

As a developer I want to access translations in JS the same way I do in python so that I don't have to jump through many hoops to get it done, and to keep the code readable.

As a developer I want to have all translations in one place so that I don't miss anything when introducing a new language etc.

Additional Context

Design Requirements

Related Issues

This blocks some part towards the end of #3745
(currently I'm working on the framework for defining powerful editor features for shortcodes, following it most shortcodes will get implemented based on that – their completion is blocked by this)

Summary of discussion and updates to the description