Niklas brought this message 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 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?
: The April 2016 mediawiki-i18n thread: "Providing the effective
language of messages"
: My unofficial guide on how to turn something into an ArchCom-RFC: