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#...
[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