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
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add exit titles and warnings to API message response | mediawiki/extensions/ZeroBanner | master | +24 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Dbrant | T115484 Display definitions of highlighted words from Wiktionary | |||
| Resolved | • bearND | T126934 Roll out Restbase to production | |||
| Resolved | Dbrant | T120116 Better analytics for preloads and Wikipedia Zero support. | |||
| Resolved | • Mholloway | T123748 Add EventLogging in the Android App to track external link clicks per partner | |||
| Declined | Yurik | T115398 For Wikipedia Zero partners - Create ability to measure number of external link clicks per partner | |||
| Resolved | • Mholloway | T119126 Replicate custom Zero exit interstitial behavior in Android App | |||
| Resolved | • Mholloway | T119128 Replicate custom Wikipedia Zero exit interstitial behavior in iOS App | |||
| Resolved | • Mholloway | T123744 Update ApiZeroBanner to make custom partner info and exit warnings available to the apps |
@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 @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?
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
Change 264859 merged by jenkins-bot:
Add exit titles and warnings to API message response