Last modified: 2014-06-03 06:42:47 UTC
The MobileFrontend extension shouldn't special-case the main page. Currently a lot of the logic and infrastructure is based on a { if isMainPage() } { else ... } model, which is silly and unnecessary. The extension code should be flexible and adaptable to any page. A few tweaks might be necessary for the main page, but there doesn't need to be a completely different system in place for it.
The problem with main pages is that they have complex formatting, usually with two-column tables that will not fit into mobile devices' tiny displays. Of course, it's theoretiaclly possible to extract these tables' content - but such task would be close to telepathy.
I think pages should be allowed to special case themselves in this way. There are various other pages where things just will not work on mobile (see bug 20030 for instance) - it would be good if these pages were able to turn on this special casing to hide certain content. This would make the home page special casing more generic and useful. Thoughts?
+1 on Jon's comment We need to get to a point where an editor is able to designate mobile/non mobile content. We have this functionality on the main page but its a hyper specific example. As we move forward with moving mobile frontend into core we need to look at explicitly in wikitext saying what belongs on mobile (or vice versa) what does not.
Random idea: MediaWiki has an i18n setting "mainpage" that takes a full page name which it uses to link to the main page in the logo and other places. Maybe it would make sense to ( - instead of forcing the main page to be in a specific format and apply a fragile conversion to it for mobile - ), instead have an actual wiki page be the mobile main page. An interface message like "mobilefrontend-mainpage" (empty by default, which setup will fallback to the "mainpage" msg) would be used for it. The reason for this is that, although wmf wikis have the (arguably unfortunate) habit of creating complex main pages that uses dozens-of-level-deep nested tables with at least 2 columns, I know many (non-wmf) wikis that don't. And it is exactly these "complex mainpages" that are in need of a mobile version. The simple main pages that other wikis have don't need this conversion per se. Since (AFAIK) all complex-mainpage-having wikis use tranclusion to include the content into their main page sections, it would be fairly trivial to create a mobile version (as a wikipage) that re-uses the same content in a different, mobile-friendly, format. That way there are no requirements and wikis can make the mobile version just the way they want them to be. They could even come up with a design that would work for both desktop and mobile, if they want to. And have no limitations or restrictions if they come up with a new section that perhaps the extension doesn't recognize yet.
Seems a good idea. Moreover an empty mobile-mainpage would lead to the old one, being the perfect default.
This isn't just a problem with main pages. Portal pages and others have the exact same issues. We need a solution that doesn't duplicate all of our content work.
Also see bug 32583 which discusses the method for which titles are extracted on the main page. Whatever solution we come to should also deal with this in a satisfying way
*** Bug 32583 has been marked as a duplicate of this bug. ***
https://gerrit.wikimedia.org/r/59722 (Gerrit Change I444b061796b3e3344852327cf26b48e83381f457) | change APPROVED and MERGED [by JGonera]
rabbit hole open on alpha but nowhere near fixed :)
So many years later people are still getting confused about how to special case the homepage. Looking at the page in question I noticed it had no need for special casing. I now believe should be turned off by default and enabled on a per wiki basis where needed.
https://gerrit.wikimedia.org/r/71749 change defaults to no special casing. Let's try and reverse the trend of fixing up broken layouts and try to encourage better use of classes and non-table based layouts.
Is this ever realistically going to get fixed? I hear that most wiki projects are moving to DIV based layouts and with good use of the nomobile class there is really no excuse for not being able to optimise the main pages without us doing anything. Is it time to be more brutal and deprecate this main page special casing? I could imagine the following approach: * Add a JavaScript warning on mobile pages that are special cased saying that "This page has been special cased. We are deprecating this functionality. If you are seeing this warning, you need to act now" * Identify all special cased main pages and throw a message on the main talk page telling them to act now with a link to how to make a good mobile optimised page. Now we have useskin=minerva there is no reason why editors cannot easily fix their main page. See https://en.wikipedia.org/?useskin=minerva If we don't want to take this approach I suggest we WONTFIX this bug as this is not realistically going to happen without a brute force approach.
