Support simple-language variants of the same locale (e.g. German Leichte/Einfache Sprache)

[apermo]

Summary

Add first-class support for offering a "simple language" variant of the same
base language alongside the standard variant — primarily German Leichte
Sprache / Einfache Sprache, but the same shape applies to any
accessibility-driven simplified register.

Background

German public-sector and many private sites are required or strongly
encouraged to provide content in Leichte Sprache (Easy Language) and/or
Einfache Sprache (Plain Language) for accessibility reasons (BITV 2.0,
BFSG / EU Accessibility Act). In a WordPress multisite this is naturally
modelled as an extra blog whose content mirrors the standard German blog at
a simpler reading level.

The blocker today: both blogs use the WordPress locale de_DE. MSLS keys
blogs and translation links by locale string, so two blogs sharing de_DE
cannot both participate in the same translation group — only the first match
wins.

Relation to #112

This is the same underlying limitation reported in #112 (multiple Canadian
provinces all using en_CA). #623 is the German accessibility instance of
that pattern. Whatever mechanism resolves #112 — e.g. a per-blog
language-variant suffix, a blog-id-based key, or a configurable
"discriminator" alongside the locale — should also unblock this case.

Listing them as separate tickets so the accessibility use case stays
discoverable, but they should be solved together.

Desired behaviour

1. Two (or more) blogs in the same multisite can declare locale de_DE
   while being distinguishable to MSLS — e.g. via an additional
   "variant"/"flavour" setting per blog (standard, leichte-sprache,
   einfache-sprache, …).
2. Translation links connect a post on the standard-German blog to its
   counterpart on the Leichte-Sprache blog (and vice versa) without
   collisions.
3. The language switcher / hreflang output represents the variant
   sensibly. There is no IETF BCP 47 tag for Leichte Sprache; reasonable
   options are a private-use subtag (de-DE-x-easy) or a documented
   non-standard label — to be decided as part of the implementation.

Notes for implementation

Relevant entry points (no change proposed here, just orientation):

• MslsBlogCollection::get_blog_language() and get_blog() /
  get_blog_id() in includes/MslsBlogCollection.php — currently assume
  one blog per locale.
• Translation link storage as locale => post_id in
  includes/MslsLanguageArray.php; admin field naming
  (msls_input_<LOCALE>) parsed in includes/MslsMain.php.
• Existing filters that may help: msls_blog_collection_get_blog,
  msls_blog_collection_get_blog_id, msls_input_select_name.

Out of scope

• Generating or auto-translating simple-language content.
• Editorial workflow for keeping the simple-language version in sync.

[apermo]

@threadi as discussed it would be valuable if you'd add your insights.

[threadi]

Ok, my 2 cent about this :)

My Background:
In June 2023, I released the Easy Language plugin: https://wordpress.org/plugins/easy-language/
This release was preceded by the realization that, in the context of the "Barrierefreiheitsstärkungsgesetz", more websites would likely want to incorporate both "Simple Language" and "Easy Language" content. This assumption was later tempered by the fact that there are currently no statutory requirements mandating this - except for the websites of government institutions; however, due to long-standing contracts with other market providers, these institutions do not use WordPress.

Nevertheless, in collaboration with the Munich-based startup SUMM AI, I developed a plugin that enables the simplification of content on WordPress websites into either Simple Language or Easy Language. To achieve this, my plugin extracts content from text-based widgets across - now more than a dozen different page builders - and passes this data to the SUMM AI API for simplification. The API's response contains the simplified texts, which the plugin then inserts back into the content, replacing the original text.

I - perhaps unwisely - designed the plugin to support the use of different APIs for these simplification tasks. With Capito from Austria, we identified a second provider offering text simplification via API. My research also revealed similar API services offered by FC St. Pauli (though this has not yet been implemented due to the scope of effort involved) and Fair Text (where the concept of an API exists, but the actual service has yet to be made available).

However, these APIs also differ in their methodological approaches. In Germany, Leichte Sprache is defined by the Leichte Sprache e.V. association (I once met them on the Leipzig Book Fair) and is governed by stricter rules than "Einfache Sprache". SUMM AI offers both options; moreover, all texts processed through their system undergo quality assurance checks by a team comprising actual users with relevant lived experience, resulting in a very high level of quality in the API's responses. Capito, conversely, utilizes the internationally recognized and widely adopted language proficiency levels (A1 through C2) for text simplification. None of these levels fully meet the specific requirements for Leichte Sprache although level B1 can be roughly equated with Einfache Sprache.

In search of further possibilities, I also incorporated support for simplified variants in other languages. In English, terms such as "Easy to Read" or "Plain Language" exist, though even here, there are no clear definitions regarding how such texts must be written. The French variant, known as FALC, is the most developed to date - yet even within its own country, it lacks true standardization.

These discrepancies clearly demonstrate that no standardization exists - particularly not on an international level.

The "Multisite Language Switcher" plugin utilizes the languages ​​provided by WordPress itself as its foundation. While this represents a highly effective and modern approach, it unfortunately limits the available options in this specific context.

Implementation Options within WordPress:
Based on my experience with the "Easy Language" plugin, I currently identify the following potential solutions within WordPress for enabling these non-standardized language variants in a manner that is intuitive for the end user:

a) The get_available_languages hook allows for the modification of the list of languages ​​that WordPress presents as options. During my testing with this hook, I was indeed able to add "Leichte Sprache" to the selection list; however, because this variant is not recognized as a distinct language by wordpress.org, the functionality proved unreliable. This approach may warrant further, more in-depth investigation, albeit with an open-ended outcome.
b) One could petition wordpress.org to officially register Einfache Sprache and Leichte Sprache as additional German language variants. This would immediately resolve all associated issues within WordPress, though it would simultaneously create new challenges. One such challenge is the fact that these variants lack standardization - they do not even possess an entry within the IETF BCP 47 registry. It should be possible to assemble a group of advocates willing to champion this cause. However, one would then also need to determine how to effectively integrate "Leichte Sprache" into various WordPress components. Extensive explanatory texts, for instance, would require entirely different formatting for output - a requirement that is not always practically feasible within the constraints of the graphical user interface (GUI).
c) Create a secondary language selection interface specifically designed for choosing language variations. This approach would unlock new possibilities, including the ability to represent regional dialects (e.g., Saxon, Bavarian, Braj (a Hindi dialect), etc.). It remains to be clarified how this can be output in the frontend - specifically to ensure that, when the "Saxon" variation is selected, screen readers should not read the texts aloud in Standard German. To the best of my knowledge, there is currently no established standard for this either.

Implementation Options using "Easy Language":
My plugin extends all post types and taxonomies to include the capability to store their respective records in "Einfache Sprache" or "Leichte Sprache" (provided that the page builder currently in use is supported). On the front end, the standard language is output for screen readers, thereby ensuring that no issues arise during text-to-speech playback.
If Polylang or WPML are being used, my plugin adds "Einfache Sprache" and "Leichte Sprache" to their respective language selection menus. However, this simultaneously excludes the use of an API for text simplification, as these plugins do not support such third-party APIs for this specific purpose in their free versions and/or Pro versions.
For the reasons mentioned above, I never fully completed the implementation of these two languages ​​within WordPress itself.

What does this mean, then, for "Multisite Language Switcher"?
I believe the "get_available_languages" hook warrants a closer look. I have attempted this previously but was ultimately stymied by the language files required for both WordPress core and every individual plugin. To the best of my knowledge, a fallback to German language files was not possible - though a fresh second look at the matter could prove helpful. From my current perspective, this would represent the best approach for adding these languages. However, this situation could certainly evolve over time - much in the same way that legislative requirements are subject to change.

Alternatively, any user on a multisite installation can also use my Easy Language plugin, which includes automatic simplification as well. :)

Note:
The attribute responsible for screen readers in the frontend is the lang attribute within the html element. This can be influenced via the language_attributes hook—this particular aspect is the least of my concerns.