Page MenuHomePhabricator

Return title's namespace in action=mobileview response
Closed, ResolvedPublic1 Estimated Story Points

Description

Problem statement

There are a few scenarios on the client where knowing a title's namespace is important. For example, Android has special rules for File: and Special: pages, and the iOS app has issues rendering titles outside the main namespace (T119010) and wants to exclude them from it's "Explore" feed (T123577).

Suggested solution

Returning this information as part of the mobileview action is a backwards-compatible way to give us this information. action=query already returns a ns field which contains an enum for the title's namespace. Adding a similar field to the mobileview response would satisfy the needs listed above and allow for removal of hard-coded prefixes for multiple languages.

Event Timeline

BGerstle-WMF renamed this task from Return namespace in action=mobileview response to Return title's namespace in action=mobileview response.Jan 13 2016, 10:20 PM
BGerstle-WMF set Security to None.
BGerstle-WMF moved this task from Needs Triage to Tracking on the Wikipedia-iOS-App-Backlog board.

Note, the proposed workaround to detect namespace via colon prefix will have false positives, e.g. https://en.wikipedia.org/wiki/UFC_Fight_Night:_Dillashaw_vs._Cruz

and 13_Hours:_The_Secret_Soldiers_of_Benghazi

[[Star_Wars:_The_Force_Awakens]]

bd808 triaged this task as Medium priority.Jan 20 2016, 6:18 PM
bd808 added a subscriber: bd808.

Change 267861 had a related patch set uploaded (by Phuedx):
Return page namespace when requested in API

https://gerrit.wikimedia.org/r/267861

@BGerstle-WMF, @Dbrant: I've opted to only add the ns property to the response when it's explicitly requested, e.g. /w/api.php?action=mobileview&format=json&page=Star_Wars%3AThe_Force_Awakens&prop=namespace. This is more inline with the current state of the mobileview module. If you object, then it'll be trivial for me to add it to the response by default.

@phuedx I don't think it makes much difference either way. Clients who get the ns property w/o explicitly asking for it would just ignore it, and the extra data on the wire is negligible (e.g. ns: 0).

If you ask me, from an API / information-architecture standpoint, clients should always get the namespace and be highly encouraged to handle them differently. Same with pageid (since "Foo_bar" is the same page as "Foo bar" and "Foo%20bar"), but that's besides the point.

@phuedx I don't think it makes much difference either way. Clients who get the ns property w/o explicitly asking for it would just ignore it, and the extra data on the wire is negligible (e.g. ns: 0).

If you ask me, from an API / information-architecture standpoint, clients should always get the namespace and be highly encouraged to handle them differently. Same with pageid (since "Foo_bar" is the same page as "Foo bar" and "Foo%20bar"), but that's besides the point.

While I agree that it should be provided by default (imo all the fields should be made available by default!) I worry this might be confusing since its inconsistent with current expectations so I'd rather we discussed that point separately and submit a follow up if we want to change that behaviour.

If you ask me, from an API / information-architecture standpoint, clients should always get the namespace and be highly encouraged to handle them differently.

I agree. That being said, if the ns property were returned by default, then the response would be interesting…

{
    "mobileview": {
        "normalizedtitle": "Star Wars:The Force Awakens",
        "sections": [
            {
                "id": 0
            }
        ]
    }
}

I'd be more than happy to talk about default properties/parameter usage with y'all though!

Readers-Web-Backlog: Alright. I think that this is ready for review!

@phuedx I don't think it makes much difference either way. Clients who get the ns property w/o explicitly asking for it would just ignore it, and the extra data on the wire is negligible (e.g. ns: 0).

If you ask me, from an API / information-architecture standpoint, clients should always get the namespace and be highly encouraged to handle them differently. Same with pageid (since "Foo_bar" is the same page as "Foo bar" and "Foo%20bar"), but that's besides the point.

I don't think, that this is a good idea. mobileview implies (for me), that we get a response that is as small als possible, so I would suggest to return only the data, which was requested, especially if I can't turn the ns property off :) Also: mobileview isn't targeted to expose information, that is already available with other modules, isn't it?

Instead of putting more and more functionality into mobileview, I would welcome to deprecate it and merge the functionality in a new query module, which would allow you to request the ns property already :P

Change 267861 merged by jenkins-bot:
Return page namespace when requested in API

https://gerrit.wikimedia.org/r/267861