On 12.07.2012 20:33, Platonides wrote:
* the parser
cache, containing the HTML for every page's content. This cache
uses keys based on the ParserOptions, which includes a field for specifying the
language. However, currently only a "canonical" version of the rendered page
is
cached, disregarding the user language.
That's not true. You are confusing content language (which is what you
usually want inside a page, with interface language). If you have German
as your language preference in English, you will see pages cached with
lang=de (as soon as they have language-specific content, such a TOC or
edit links), and sharing that parser cache only with other
German-speaking users.
Are you sure? That's how I THOUGHT this works, but looking through the code,
this doesn't seem to be the case, at least not when editing. in
WikiPage::doEdit, the ParserOptions are created with the "canonical" keyword,
not the user object, at least...
I didn't *quite* figure out how this works though, or why this is done. Can you
explain? See my question at the very bottom for more detailed questions.
b) generating
HTML from Wikidata objects (which are JSON-like array structures)
is much quicker than generating HTML from wikitext
c) Wikidata will have relatively view direct page view, it will mainly be used
via Wikipedia pages or the API.
I'm not sure what you mean by this. Are you talking about
a) sites with a "wikidata widget" (such as an infobox)?
b) A special page showing wikidata items?
c) A wiki for storing wikidata information.
a) will be viewed very frequently, while b) and c) will be used rarely.
If (a), it makes no sense to have the infobox in your
native language
and eg. the sidebar labels still in the content language.
(even then you could do that without partitioning theparser cache, see
the code for edit links)
Right. For rendering infoboxes, an entirely different rendering mechanism will
be used, based on parser functions. This will always use the content language.
If (b), special pages don't use the parser
cache...
Items are page content. They are shown as page ontent, on regular wiki pages. No
special page required.
But the rendering of these data-content wiki pages will depend on the user
interface language.
If (c), see below.
Right, that's what wikidata is and what we are talking about.
The parser cache already supports per-language
splitting. You MAY want
to ignore the anon language cookie for "normal" wikis, in anticipation
for a smaller cache hit. But it SHOULD be used on multilingual wikis.
absolutely.
Specially for Commons, where there's a huge use of
in-page language
customization, and the parser cache is already very splitted anyway.
Incubator will probably benefit a lot from allowing anons to view the
skin in their own language. Not sure about meta.
For Wikidata, I expect the same cross-wiki usage as Wikimedia Commons,
so the anon cookie should be obeyed too.
Yes.
But it's my impression that the mechanism for user-language specific parser
cache keys is currently broken. Or we did something wrong to break it. Is there
some documentation on this? I'm especially interested in:
a) how and why the "canonical" ParserOptions are used upon save, and how that
impacts the parser cache
b) how ParserOptions::getUsedOptions() interacts with the rest of the system,
and how it is or should be populated.
thanks!
-- daniel