Page MenuHomePhabricator

Update ApiZeroBanner to make custom partner info and exit warnings available to the apps
Closed, ResolvedPublic2 Story Points

Description

This card is to estimate and track the work updating the API (via ApiZeroBanner.php in the ZeroBanner extension) to provide custom information from the following partner configuration fields to the apps:

*exitTitles
*exitWarnings
*partnerInfoText
*partnerInfoUrl

Event Timeline

Mholloway claimed this task.
Mholloway raised the priority of this task from to Needs Triage.
Mholloway updated the task description. (Show Details)
Mholloway moved this task to Needs Triage on the Wikipedia-Android-App-Backlog board.
Mholloway added subscribers: Dbrant, dr0ptp4kt.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptJan 15 2016, 3:33 PM
MBinder_WMF set Security to None.Jan 15 2016, 9:07 PM
MBinder_WMF edited a custom field.

@Dbrant, @Mholloway, I'll mark this as High priority to signify it as fast approaching and get it out of the needs-triage section of dashboard 125.

dr0ptp4kt triaged this task as High priority.Jan 16 2016, 9:22 PM

@dr0ptp4kt @jhobs This is almost done but I have a couple of questions about the web implementation, which I was using as a reference. Looking at getJsConfigBlock in PageRendering.php, it uses pickLocalizedString to get fallback strings in some cases (e.g., exitTitle) but not others (exitWarning, partnerInfoText). Why is this?

I'd like to be as consistent as possible with the web behavior, but it seems more important still for the API to be internally consistent. So what I'm thinking of doing is adding two parameters: one allowing the consumer to optionally specify a target language (otherwise falling back to the existing behavior, which uses the target wiki language), and another to allow the consumer to specify whether to look for and return a fallback string for each field if no string in the target language is found. My reasoning is that some consumers might prefer any custom fallback available, while others might prefer to use a single catchall fallback.

The language selection piece is working fine, but I wanted to solicit your comments on the language fallback behavior before getting too far along on that. @Dbrant, what would this look like in your ideal world?

jhobs added a subscriber: DFoy.EditedJan 18 2016, 6:50 PM

@dr0ptp4kt @jhobs This is almost done but I have a couple of questions about the web implementation, which I was using as a reference. Looking at getJsConfigBlock in PageRendering.php, it uses pickLocalizedString to get fallback strings in some cases (e.g., exitTitle) but not others (exitWarning, partnerInfoText). Why is this?

Because it was written by two different people at two different times, and then the team was disbanded. Because I am dumb. It should always use pickLocalizedString.

I'd like to be as consistent as possible with the web behavior, but it seems more important still for the API to be internally consistent. So what I'm thinking of doing is adding two parameters: one allowing the consumer to optionally specify a target language (otherwise falling back to the existing behavior, which uses the target wiki language), and another to allow the consumer to specify whether to look for and return a fallback string for each field if no string in the target language is found. My reasoning is that some consumers might prefer any custom fallback available, while others might prefer to use a single catchall fallback.

This is something you'd really have to talk with @DFoy about. In my experience, asking more of the partners is not the ideal solution, but he'll know more and is a good point of contact to have for the Partnerships team. (I'm not sure how religiously he checks Phabricator, so you may want to try email.)

If always falling back via pickLocalizedString is the correct behavior,* then maybe it makes more sense to do the same in the API too rather than adding a 'fallback' parameter, and leave it up to the app or other client to decide what to do in the case that a language parameter is given but the returned string is in a fallback language instead.

*@jhobs, I'll make that change too as we discussed on IRC.

Change 264859 had a related patch set uploaded (by Mholloway):
Add exit titles and warnings to API message response

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

Change 264859 merged by jenkins-bot:
Add exit titles and warnings to API message response

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

Dbrant closed this task as Resolved.Feb 1 2016, 3:28 PM