For MediaWiki (recent comments | status changes | tags | authors | states | release notes | statistics)
I'm not convinced about this, since that requires a much bigger knowledge at the parser side. Setting the getPageLanguage() to the ParserOptions seems a better alternative IMHO.
It's a temporary fix/improvement, because as I said in an earlier commit, there should probably be a better way but I don't know enough about MediaWiki core (and certainly not the parser) to find the best way. See also bugzilla:6100#c49.
Move the code from getPageLanguage to getFunctionLang? Move getPageLanguage to OutputPage? Something else?
It should at least be easy to define the page content language in extensions.
Also, what do you mean with "that requires a much bigger knowledge at the parser side"?
It makes the parser integrate more tightly with the titles.
I'm actually kind of inclined to do it robin's way; the content direction is a property of the page, and having to explicitly set it _separately_ from other page metadata like the page title feels a bit odd. Every bit of code that calls the parser would have to know to check the page's directionality and pass it in if we have to add it to ParserOptions, which feels worse to me.
Alternatively, ParserOptions could be initialized from both a user and a title, but a) that still requires changing all the existing code and b) I'm not sure that fits with the theory of ParserOptions. Since page metadata like title and revision ID aren't passed through ParserOptions either, I kinda feel like it should come along with the title.
In the next-gen parser interface, we may want to have separate notions of 'general environment info' and 'this-page info', where this-page includes the title, revision id, and any other such metadata that's related to what you're parsing rather than who is parsing it.
This will cause breakages when the Parser doesn't have a title context. r94680 exposed it.
Isn't the parser supposed to always have a title context? Pretty sure I've seen other things break in this circumstance and it seems like it violates basic assumptions.
You'd think so, but it might not. In r94680, we exploded on the Magic Words tests.
It's not necessary a bad thing to explode on missing context.
Exploding sanely, sure. But an E_FATAL is never nice :)
Does this still need to be marked fixme?
I was thinking to perhaps check if we have a $this->mTitle object, and if not, either give an error or fallback to $wgContLang however that would give different output for e.g. magic words.
You could throw an exception. Like Brion said, it probably makes the most sense to die in scenarios where we don't have a title. An exception avoids the E_FATAL and provides a nice usable stack trace.
Done in r96405
