- I understood it as this based on discussion with Brian Wolff. Page_props depends on the page to be existent first. It is better to create a field in the page table as it is a property of the page itself Kunalgrover05 (talk) 11:34, 22 May 2014 (UTC)
I suggest to avoid having to deal with any user interface consideration at first. It's fine, for instance, to create a separate special page Special:PageLanguage which does only that and is not linked from anywhere (except Special:SpecialPages of course). Further integration and refinement of UI can come later. --Nemo 15:32, 22 May 2014 (UTC)
Suggestions from Nikerabbit
- Default language should be current default
- Hooks should be able to override user selection
- Language should be stored in the database
- Should be available via relevant APIs --Kunalgrover05 (talk) 17:25, 22 May 2014 (UTC)
Discussion with Brian Wolff
- In order to not require to update all the databases, don't need to set the page language in database(keep it null) until it is different from the default wiki language.
- Have a SpecialPage until the interface is finalized.
- Using a hook for extensions to override the DB choice Kunalgrover05 (talk) 05:39, 26 May 2014 (UTC)
Review by Anomie
- Need to take care of the ContentHandler:getPageLanguage() method as well.
- Need to have a way to get page language for MW namespace.
- Extensions might be setting the PageLanguage using the hook.
Suggestion from SPQRobin
- Have the Title->getPageLanguage() as a central function that should call ContentHandler, the DB and the hook and return the correct language.
Front end suggestions from Liangent
Using ?action=info to set the page language.
Suggestion from Mark Traceur
Need to add logging for Page Language
Suggestions from Siebrand
- Need to have performance engineering approval
- This code should not break when the schema update is not yet applied. Need to find a fix for that.