On 13/07/12 20:42, Daniel Kinzler wrote:
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:
b) how ParserOptions::getUsedOptions() interacts with
the rest of the system,
and how it is or should be populated.
The used options are magically populated. You don't need to do anything.
When the popts is created, no option has been used.
Then the page is parsed, and both the parser and extensions call the
parseroptions methods and can conditionally base their output on that
result.
They MUST access the options through the ParserOptions, using eg.
$wgUser->getOption() would be a sin.
When the ParserOutput is going to be stored, the
ParserOptions::getUsedOptions() is called, which simply returns a list
of the methods -which depend on user preferences- that have been called
on the ParserOptions, which it has been dutifully tracking.
To get the user language, you want to use $popts->getUserLangObj().
Nothing more needed. Remember you need to use that object and not eg.
wfMsg()
a) how and why the "canonical" ParserOptions
are used upon save, and how that
impacts the parser cache
The "canonical" or not (WikiPage::makeParserOptions) is only used to
determine if the ParserOptions should be created with user settings or
defaults.
The page is always rendered on save with the 'canonical' options to keep
the page table links consistent (bug 14404).
Then, when the user visits the page after save, it is rerendered with
its own preferences if the just-cached general ones doesn't fit his options.
Regards