@Jhernandez I've created a subtask to separate the pagelib CSS. This will probably happen in three stages:

1. Add pagelib CSS endpoint to MCS
2. Expose pagelib CSS in RESTBase
3. Remove pagelib CSS from base CSS

TBH the test pages above won't help much and seem redundant tome. Pages are constantly changing

The Android app is consuming the https://en.wikipedia.org/api/rest_v1/data/css/mobile/base endpoint now.
Before that it used the same list of modules we currently have in the base CSS endpoint. In fact we got that list from the apps code.

Do you mean exposing another CSS endpoint? Something like /data/css/mobile/pagelib?

Added these pages to our list of summary test pages.

@Jhernandez The lists of allowed wikis for the Chrome/FF ext. and the Safari ext. have the details of projects you could try.

We didn't change any summary code. The changes were made on-wiki, wrapping the extra strings with <span class="noexcerpt">:

• https://en.wikipedia.org/w/index.php?title=Louisiana&diff=next&oldid=851051478
• https://en.wikipedia.org/w/index.php?title=Scythian_languages&type=revision&diff=851806658&oldid=851365772

I think the iOS app would not switch to using mobile-sections. Instead they would go directly to mobile-html, but after Android has switched. IOW, I think it's going to take a while.

Makes sense now. Thanks!

Purged the following endpoints from Varnish:
https://en.wikipedia.org/api/rest_v1/feed/announcements
https://de.wikipedia.org/api/rest_v1/feed/announcements
https://ru.wikipedia.org/api/rest_v1/feed/announcements
https://zh.wikipedia.org/api/rest_v1/feed/announcements

I thought we were not storing media and feed before anyways, as was mentioned in the Platform/Audiences sync a few minutes ago.

In T201103#4491186, @mobrovac wrote:

Current status:

• pre-generation for mobile end points is enabled only for WPs

If all goes well we can try these times on Thursday:

Here are screenshots of all the localized announcements:

@Dbrant Thanks for updating the yellow image. This looks good now:
Light theme:

Thank you for the update. The yellow image is still not working. It's still showing the same default image. I'm not sure why that is. I think an Android dev would have to look into this more.

@Dbrant and @RHo, sorry, it doesn't look like the 1px image actually works. For some reason I don't understand it's falling back to the default globe image instead.

@RHo Ok, sounds good. Do we want to skip the image for the upgrade prompt announcement or are you planning to provide me a URL for that?

^ is just a WIP patch for now. Once the missing URLs are provided we can wrap this up.

@RHo @Dbrant I also need a URL for the positive action CTA to update the app in the Play Store.

@RHo The Android app only allows for an image URL, not for a color code. I think a single pixel image should probably suffice but I would still have to test this with the app.

@RHo do you have an image for the update app prompt (colored background only in #FFCC33)?

@Jhernandez I think the easiest way to get useful output from this tool is to clone the Restbase repo and target individual spec files under v1/*.yaml. (combine with the common_schema.yaml, see my comment in T199101#4466668 for command line examples).

@RHo Sorry, I had not noticed that you changed the countries for Chinese. With the update that should work for most users.
I was earlier referring to that the app allows a user to specify in the language selection which Chinese language variant the user wants to use. So, there could be some cases where someone set Traditional Chinese as the primary language but visits mainland China, and then gets the Simplified Chinese announcement instead. But ok, that should be the exception rather than the rule. IOW, I think that's fine.

@RHo Thanks, but I still don't know how to tell the app which language variant to use for Chinese for which text. I don't think we have encountered this requirement for announcements before.

@Dbrant @RHo The text for Chinese is for Traditional Chinese. How do we ensure that this is not displayed for users that selected Simplified Chinese as their primary language? Should we skip the Chinese announcement?

@TheDJ The problem is that this causes a horizontal scrollbar for the infobox. I've updated the task description to add a better screenshot.

Should we separate pagelib CSS from base CSS? It might be easier to come up with version strings for the pagelib by itself by using the version of the wikimedia-page-library.

@Mholloway I've fixed the issues in the media endpoint.
But it's unclear what the other issues are:

• I don't think the summary endpoint deals with audio at all.
• anchorPopupMediaTransform (used for the mobile-sections endpoints) deals with video only. It's using a selector of *[typeof^=mw:Video] video, which still should be fine.

We definitely need to change the media endpoint implementation.

TypeError: Cannot read property 'source' of undefined
at _.uniq.elem (/Users/besi/de/wmf/mobileapps/lib/media.js:163:65)
at Function._.uniq._.unique (/Users/besi/de/wmf/mobileapps/node_modules/underscore/underscore.js:581:33)
at Object.getMediaItemInfoFromPage (/Users/besi/de/wmf/mobileapps/lib/media.js:163:14)
at BBPromise.join (/Users/besi/de/wmf/mobileapps/routes/page/media.js:23:39)

Looks good in the Android app as well. Thank you for the quick fix!

I'd say Thursday sounds more realistic. Adding to our Kanban board.

@RHo when and how long should the announcement last?

It's definitely not an ideal situation right now. I found some special handling done in the Popups extension popups.js. This link is from T192571. There is some special handling there depending on if the image is in portrait mode (tall) or landscape mode (wide). But it probably doesn't matter for full screen gallery images. Just FYI.

@Dbrant @cooltey The Android app code base has a ImageUrlUtil.getUrlForSize() which can be used to request a different sized thumbnail image. Just pass in the thumbnail.source URL and the desired size. Once T66214: Define an official thumb API is done we should use that instead.

@cooltey

1. Have you considered using the thumbnail field instead? There's already code in the Android app to resize the image if necessary if you have a thumbnail URL.

@Jhernandez The specs are updated in prod. Unfortunately, I get the same error message as when I run it locally just for the definition.yaml file, which seems misleading to me. It looks like it cannot open the file:

Error: ENOENT: no such file or directory,

This is done.

This is not valid anymore. The media endpoint has been significantly changed. Now the description is an object with a text and html property. The client can chose the one best suited.

FWIW, bswiki has also been added since then due to some help from a volunteer.

In T199101#4466689, @Pchelolo wrote:

Looks like the JSON output in https://en.wikipedia.org/api/rest_v1/?spec doesn't include any of the definitions.

It does include them all.

Ah, I see you're getting the spec from RESTBase and in JSON format. I was trying the one from MCS locally (the YAML file). That explains the difference. (It's also better to not install the tool globally.)

I'm not sure whether PCS should be running this transform, even if we split up a portion that could run server-side. This seems like a UI decision and would go counter to us providing more content vs UI. It would also require some I18N on the server for three labels (infobox/other table label, footer label), or at least run a bigger portion of this transform on the client.

Updated the German column in the above spreadsheet. FYI, I copied the wording for "Got it" and "Edit languages" from the Android values-de/strings.xml file for consistency. The autotranslation of "Got it" seemed too literal to me.

Renamed content-html -> mobile-html to reflect reality.

@Jhernandez I just tried running this but I'm getting different results. I'm using the CLI.

@Mholloway That's a great find. Looks like worker death have come down lately.

@Mholloway. Thank you for your investigation.

Ok, going to rename things from content-html to mobile-html.

The Parsoid output as it is right now is for editing. But ok, I guess mobile could work, too.
How about /page/mobile/html/{title}?
/page/html/{title}?mobile=true is another option but might be confused with plain Parsoid.
/page/mobile-html/{title} would be my third option.

Hmm, I thought we wanted to avoid the name mobile. How about something with read in the name?

it would be good to have a followup task with a proposal to unify the format across platforms

This is the same in the corresponding Parsoid HTML when running in Chrome: https://en.wikipedia.org/api/rest_v1/page/html/United_States. (It acts better in FF, but that doesn't help the Android app experience).