Tagging language and directionality on fallback entries sounds reasonable, and not a huge addition.

I'm not sure why the fallbacks are cached in the main body instead of letting them through to the backing language's cache, but if that's a necessary or useful choice I've no reason to hop in and change it. I also am a bit mystified why we moved from a filesystem-backed database to a giant in-memory cache that requires deserializing the entire language cache on every request (if I'm reading correctly) but apparently that performs better than I think it should, so take me with a grain of salt... :)

I would recommend getting someone from Performance to weigh in on this to confirm the proposed solution has no surprises. Probably best to have at least a preliminary patch which can be run through some paces...

More generally, we should capture the other note in the mediawiki-i18n thread about having the templating system pick up language and directionality and fill out the necessary buts for tagging and isolation on the HTML end.

We may want to think about a class to represent a bit of text or HTML that's tagged with a language and an isolation factor (not sure if necessary), which can be mixed and matched with Message objects and passed into Html class generators or template things. And of course, equivalent on the JS side.

-- brion

Hi everyone,

Niklas brought this message[1] to my attention as something that
probably deserves more attention than it has gotten, and I trust he's
correct.  What he said back in April: "I added
wikitech-l to CC in hopes that people who have worked on localisation
cache more recently would comment on whether [Adrian's proposed option
to not merge
messages in LocalisationCache] would make more sense nowadays."

Adrian: assuming Niklas and I are correct, my suggestion for moving
this forward would be to turn your design thoughts into an
ArchCom-RFC[2] for more explicit consideration by ArchCom.  My attempt
at abstract for those who haven't followed this:

Adrian was trying to figure out how to output pages that need to have
multiple languages in a single page, which becomes difficult when
fallbacks are missing.  It results in some oddball behavior where
placeholder text is output with incorrect i18n attributes in the
surrounding div.  He provided several alternatives for how to solve
the problem in his mail to mediawiki-i18n.  Niklas replied, providing
the "if we stick with the status quo" answer (tag message strings in
LocalisationCache with the correct language), and then is trying to
figure out if the status quo makes the right space vs speed tradeoff
given the quantity of languages and messages we have in 2016.

Adrian & Niklas: did I get the gist of it?

Rob

[1]: The April 2016 mediawiki-i18n thread: "Providing the effective
language of messages"
 <https://lists.wikimedia.org/pipermail/mediawiki-i18n/2016-April/thread.html#1059>
[2]: My unofficial guide on how to turn something into an ArchCom-RFC:
<https://www.mediawiki.org/wiki/User:RobLa-WMF/ArchCom-RFC>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l