Make rules l10n aware about doc-linter-rules

[MatonAnthony]

I don't have the URL when I run the tests, so without further refactoring, I can't tell if the page is in English or not.

I think it would be easier to deal with this on the Webextension by not running this test if the language is different than English.

[SebastianZ]

I don't have the URL when I run the tests

Really? Is window.location not accessible?

Sebastian

[MatonAnthony]

Oh, this is a good question, it's executed in a browser so I guess it should be.

I didn't thought about that one.

[MatonAnthony]

I can make the test pass for l10n pages but it would still be irrelevant.

So I think it would be more appropriate to not run the tests on locale pages rather than run it and see it displayed even as SUCCESS it would still be irrelevant for the user.

It could also be interesting to make some of those tests l10n aware, but it would require a way to add the locales to the rules either with a mechanism such as Pontoon and webpack to pack the translation into the bundle or directly by adding them to the test with a PR.

[SebastianZ]

Sorry for the delay! My initial idea was to add the translations directly to the test. Later on we can think of a way to improve this by allowing the translations to be changed via Pontoon or something else.

Sebastian

[MatonAnthony]

I would like to divide this issues into two separate actions to take:

• Run the tests only for relevant locales
• Make tests locale aware

For the first part, I'm thinking about adding a new type of Message IRRELEVANT that would indicate that the test has not been run because it's irrelevant in the situation.

It would allow us to treat it easily on the WebExtensions and in any further project using the ruleset we provide.

[SebastianZ]

For the first part, I'm thinking about adding a new type of Message IRRELEVANT that would indicate that the test has not been run because it's irrelevant in the situation.

Not sure how that would work and whether that provides the best UX.

I think the best UX is to not execute and also not show those tests at all in that case.

Probably this could be done by introducing a whitelist or blacklist for locales, or both, i.e. for example a property locales or excludeLocales for including or excluding them.
The tests mentioned earlier are all restricted to en-US, so those would be covered by a whitelist. Though there may also be cases, which apply to all languages except a specific (group of) language(s), for which we'd need a blacklist.

Sebastian

[MatonAnthony]

What I had in mind was starting the test with a check for allowed locales for those tests.
if it doesn't match return an IRRELEVANT message.

And on the webextension, to simply not display it, they would not be visible and not really run but it seems easier that to maintain one whitelist / blacklist per locale.