Client-side i18n support

[cdrini]

There's currently no way to i18n messages that get rendered from the front-end javascript. We need to find a way to use our existing i18n architecture from the JS.

Stakeholders

@tfmorris @jdlrobson

[cdrini]

Created from #2551 ; note the strings in that PR will need to be i18n-ed after a solution is implemented.

[jdlrobson]

Dupe of #2353?

[jdlrobson]

See also #2190 Note this is a lot of work and I'm not sure if any of it is salvageable. I recommend coming up with a spec for translation and building that from scratch rather than trying to rescue what we have.

There is good i18n code we can pull from mediawiki if necessary.

[cdrini]

2353 is about adding documentation about how to use existing i18n syntax/infrastructure to the wiki.

I would say this could be a subtask of #2190 .

---

Note this is a lot of work and I'm not sure if any of it is salvageable.

What's a lot of work?

[jdlrobson]

Client side i18n support. We don't have it right now. We have code relating to it, but it's got fundamental problems and I don't recommend we encourage usage of it by documenting it. We should remove it and go back to the drawing board with it. I don't want to encourage adoption of this code with it in the current state it is. We should focus on improving the backend i18n first.

[cdrini]

Ah, I see what you mean. To clarify, when I say client-side i18n I mean JavaScript specific; our html server-side i18n is alright-ish. Both of these fall under frontend i18n though. Are we on the same page?

[cdrini]

Ohhh I see why you're asking. When I say "use our existing architecture" I meant "use our existing translation files"; we should try to avoid having duplicate translation files for terms (if possible).

[jdlrobson]

Thanks for the clarification. Do you want to revise the description to be less about JS - maybe pointing at some particular code examples and/or a strawman proposal of what's being suggested? The description is a little brief right now which is likely creating more work for us trying to get a shared understanding of what we're talking about.

From my perspective, I would urge us to not add or use any frontend i18n JS for the time being - instead do that on the backend via templates that can be read by JS.

I think #2353 and this are one of the same - the docs are bad because the requirements on the frontend haven't been defined. We need to build something new and document it rather than documenting something that's horribly broken.

My worry is that having 2 tasks will fragment the conversation. Could we merge this with #2353 or create a new task that meets both of these tasks needs?

[cdrini]

I think I've closed #2353 , then we can centralize the discussion here :+1:

[xayhewalo]

Assigning @cdrini per slack discussions since he's made PRs for this issue

[tfmorris]

Do we need to do more than just say "No user visible text in Javascript"?

If so, @jdlrobson @cdrini what do we need to do to close this (or at least make progress)?