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