The multilang filter is nice in that it allows users to enter text in multiple languages at once. However, it's slow and rather limited. I just tested a VERY simple solution that makes multilang:
- Much faster
- More comprehensive (it works _anywhere_ on the page)
- More flexible (even use images, such as <img class="multilang" lang="en" src="stop_sign.en.jpg">)
The documentation warns that enabling the multilang filter for headers makes your site slower.
In fact, enabling it for content requires the server to do a lot of work, slowing things down. As some of us know, it also doesn't work everywhere- there are plenty of tracker issues about "multilang doesn't work here, and there, and it was forgotten over here". I'm sure there are plenty more remaining.
It occurs to me that since IE7 (in 2006), browsers have been able to handle multilang tags in the same form Moodle uses, without Moodle needing to process every bit of text. Moodle now requires IE9 or above, so we can use the functionality of "modern" browsers to make this far more efficient and flexible. Users don't really need to do anything different. By changing the PHP code a bit we could just make it much, much faster by letting the browser do it's job - and the browser won't forget to handle it in names of things or the other dozens of places where multilang support is missing in Moodle.
Leveraging the fact that it's 2015 and we don't have to support browsers from 1997 anymore, just those made in the last ten years or so, multilang doesn't need to be limited to just span, either. The browser can easily handle div class="multilang" or img class="multilang", to show images of signs or other images that include language. This could be achieved by simply having Moodle emit small bit of CSS:
.multilang[lang]{visibility: hidden; height: 0px; width: 0px; }
.multilang[lang~="en-us"],.multilang[lang~="en"]{visibility: visible; height: auto; width: auto; }
That's it, to completely replace almost all of the multilang filter. Just tell the browser to not display any multilang chunks other than the current language. All that parsing and processing replaced by one CSS statement.
To replace the bit of multilang that allows for either a specific language dialect like "en-us" OR the parent type "en", we place the most specific first and add this line to hide the more general version if the specific version is already present:
.multilang[lang~="en-us"] ~ .multilang{visibility: hidden; height: 0px; width: 0px; }
What are your thoughts on doing this in this much faster, more efficient, and more flexible way eventually? The one tradeoff I can think of is that as the old multilang which parses all of the html is deprecated, we'd add an instruction to put the most specific language first (the en-us version would come before the generic en version, unless they are one and the same).
I started to post this in the language support forum, but it occurred to me that wouldn't give a representative sample of opinions. Those users and devs focused on language support may well be more willing to sacrifice much performance in order to avoid the slight change of having the most specific listed first. Moodle users and devs in general may be more supportive of the increased performance and flexibility, and less concerned about the "cost" of needing to put the en-uk version before the generic en version.
