Adds the possibility to add options to the Inclusive language assessor.

[hansjovis]

Context

• We need to be able to override the shortlinks within the Inclusive language analysis from within Shopify SEO so we can determine from which platform the traffic to the website is coming from. This PR adds a method to do that.

Summary

This PR can be summarized in the following changelog entry:

• [yoastseo] Adds the possibility to change the links to the "learn more" URLs in the Inclusive language assessments.

Relevant technical choices:

• Do NOT merge trunk into this branch. This branch has been created based on the release branch, will be used in Shopify, and should not contain any unstable changes.
• Do NOT remove this branch after merging. This branch will be used in Shopify.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• For Shopify SEO, please follow the steps described in this PR. For WordPress SEO, please follow the steps described in the Impact check below.

Relevant test scenarios

• Changes should be tested with the browser console open
  • Not specifically needed, but good to do anyway in case of errors in the JavaScript code.
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Block/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

QA can test this PR by following these steps:

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

• This PR could impact the links used in the Inclusive language analysis results.
  • Make sure that the "learn more" links used within the Inclusive language assessment results are still correct:
    • For assessments about age, the link should be https://yoa.st/inclusive-language-age.
      • Example phrases: "elderly", "senile".
    • For assessments about appearance, the link should be https://yoa.st/inclusive-language-appearance.
      • Example phrases: "obesity", "midget".
    • For assessments about culture, the link should be https://yoa.st/inclusive-language-culture.
      • Example phrases: "third world country", "colored people".
    • For assessments about disability, the link should be https://yoa.st/inclusive-language-disability.
      • Example phrases: "sociopath", "addict".
    • For assessments about gender, the link should be https://yoa.st/inclusive-language-gender.
      • Example phrases: "man-made", "husband and wife".
    • For assessments about socio-economic status, the link should be https://yoa.st/inclusive-language-ses.
      • Example phrases: "poverty stricken", "illegal immigrants".
    • For other assessments, the link should be https://yoa.st/inclusive-language-other.
      • Example phrases: "felon", "minorities".

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Other environments

• This PR also affects Shopify. I have added a changelog entry starting with [shopify-seo], added test instructions for Shopify and attached the Shopify label to this PR.

Documentation

• I have written documentation for this change.

Quality assurance

• I have tested this code to the best of my abilities
• I have added unit tests to verify the code works as intended
• If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.
• I have written this PR in accordance with my team's definition of done.

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label and noted the work hours.

Fixes https://yoast.atlassian.net/browse/PC-976

[FAMarfuaty]

@hansjovis When we added additional methods in the worker like setCustomSEOAssessorClass, we also bind it inside the constructor. But we don't do it to setInclusiveLanguageOptions here. Do you know if "binding" or not "binding" it to the scope will have no difference for setInclusiveLanguageOptions?

[hansjovis]

Yes, binding it inside of the constructor would be the best option. To avoid any edge cases when calling the method.

Could you implement that? 🙂 I don't have time at the moment.

[FAMarfuaty]

I'll do that! :)

[FAMarfuaty]

CR and Acceptance test 💯