Ray Morris

I've tested it out in a bare proof-of-concept way outside of Moodle. I may very well be going all-out with it over the next few weeks, depending on the needs of the department we're assisting in this instance.

> Would we still need some kind of filter to add the multilang to the content though? (I know it could be added direct to the html, but many users will not want to do that)

That might be a nice, separate and orthogonal improvement.  The multilang spans already need "class=multilang" added to them with the existing implementation, no change to that is required or implied by this current suggestion.  We've only changed the display rules to be handled on the client (which is already handling 5,000 other display rules aka css) rather than the server. 

> I wonder if any of this is measureable, e.g. with browsers' developer tools?

1%. That's one key measurement.  The html for a quiz page, for example, is about 85KB.  Of those, about 1KB is the question and answers.  So the difference for including it in two languages is just over 1%.  Suppose the user typed something much longer, maybe 8 paragraphs like my initial post in this thread.  That's 3 KB, or about 3%-4% of the html on the page.

> Also, it is more work on the client-side for browsers, even though it is less work on the server-side.

0.005%.  The browser is already applying the ~ 5,5000 lines of CSS Moodle gives it for the page.   This adds three lines, or 0.005%. The browser ALREADY has to parse the HTML and consider the classes, etc, in order to apply the existing CSS.   We're just adding 0.005% more CSS.

The server, on the other hand, doesn't have to parse all of the html, except to apply this filter where it finds span class="multilang".  (Even if the server did separately parse it for some other reason, the multilang filter has it's own, separate parsing step which could be removed).

> How would this impact those users - ie shared PCs with no access to browser settings?

No change.  It continues to work in exactly the same way it currently does. Rather than Moodle parsing all of the HTML and changing the HTML, it just changes the CSS.  This can still be done via the drop-down selector, auto-detect if that's turned on, etc.

> Also with Tim's point about downloading all content and then just using css to hide it - some of our multilanguage content includes videos

I believe the browser generally won't play, and therefore won't download, an invisible video.  That's something to test, though.

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.

There is a new plugin available that allows you to filter your Quiz questions to see which questions have been used and which are unused.   It adds a drop down to the standard question bank view that you I use to manage questions and the one you use to add questions to a quiz.

https://moodle.org/plugins/view/local_unusedquestions