Localise the HTML reporter interface

[platinumazure]

(Ditching the issue template since this is more of a meta-issue.)

Is there any interest in internationalizing and possibly localizing QUnit for other locales?

I definitely don't think this should be higher priority than any current initiatives, but I just wanted to see if it might be something that could go on the project roadmap.

Possible steps for this:

• Integrate Globalize.js or similar, ensuring it builds for HTML and Node runners
• i18n for HTML runner, Node runner (done in incremental PRs)
• Establish contribution and review process for l10n contributions for different languages

[leobalter]

I believe this is out of our scope for QUnit, as long we have a good exposed API.

The js-reporter integration should allow us to have localized versions for the reporters.

---

We can also discuss localizing the api docs, that would be great too.

[trentmwillis]

How far can folks get by just letting the browser translate? I agree that localization is great (especially from an accessibility standpoint), but the overhead of properly supporting it is quite great.

[leobalter]

How far can folks get by just letting the browser translate?

pretty bad, I can speak on my own experience.

Something I believe we might work on is bringing translations to the api docs, that's where it most shines with users and I believe the current jekyll/markdown PR will help a lot there.

[viniciussbs]

The js-reporter integration should allow us to have localized versions for the reporters.

Could you point me to some resource about how to achieve that?

[trentmwillis]

@viniciussbs sorry for the delay. I think @leobalter's idea would be to add additional reporters in this repo: https://github.com/js-reporters/js-reporters that have their output localized.

[viniciussbs]

That makes sense. Thanks!

[Krinkle]

Rough idea or strawman proposal:

• Format: Move localised strings to a JSON file per language using the Banana format.
• Contribution: Use translatewiki.net for taking contributing and reviewing translations. They will semi-automatically push pull requests for us to merge.
• Linting: banana-checker.
• Processing: (TODO) Decide which JS library to use for processing localisation strings (pluralisation, number formatting, message placeholders, etc.). Possibly Globalize, or Banana. Or perhaps native Intl in browsers captures the bare minimum we need for pluralisation and number formatting? That'd be neat. For QUnit I think we can afford to only support the latest browsers for new features. (Acknowleding that it's unfortuate that localisation is going to be a "new" feature.)

[Krinkle]

I remain open to this in the long-term, however I can't prioritise it enough to work on it myself, and there hasn't been much interest over the years from the community.

What I propose is that we focus on making the HTML Reporter as small and separate as possible (#1118). This would open the door for anyone in the wider community to create localised versions of it through a plugin. The plugin would essentially consist of a copy of the then-small reporters/html.js file, creating localised versions of it in some way, and offering them up for others to use. E.g. you would include qunit.js + qunit-reporter-html-i18n/nl.js, where nl.js would define and initialise the Dutch (nl) version of the reporter.

I'll close this for now, but if someone is interested in picking this up and encountering an obstacle of sorts, feel free to file an issue here or chat with us anytime!