@Tacsipacsi , thank you for the extra info!

What does your patch affect? It’s in a repo named mobileapps, while the original report was about Page Previews, a desktop browser feature.

Page Previews extension relies on the response of the /summary endpoint which is handled inside mobileapps service.

I've uploaded the patch to resolve flagged revisions (only for the German wiki for now). Useful links:

Hi @LGoto!
Patch with the fix has been deployed to prod.
cc: @Tsevener

Hi @Theklan ! Could you provide an example of the issue? Seems that articles with galleries are converted fine at the moment.

@Aklapper, this has been fixed. Could you recheck?

I reverted these changes here
Revised issue from the description using Xcode for multiple iPads (see the shots), was unable to reproduce overflow of the parent element.
iPad Pro (12.9 inch)

Yes, it's the same issue. For some reason, arbitrary sections nested into the previous section. Set this task in progress.

For some reason, the horizontal scroll disappears and works fine after scrolling down the article.

Hi @Tsevener ! Do you mean this bug?

This issue happened because the template utilizes .plainlinks a { padding: 0 !important } rule from base.css. I explicitly set !important for paddings of the touch target links.
@MSantos , @Jgiannelos

Considering Flagged Revision description (link - https://en.wikipedia.org/wiki/Wikipedia:Flagged_revisions) not all wikis use it.
For those wikis, that have FlaggedRevs, related API helps to retrieve more information for current and stable revisions. Example for German wiki:
https://de.wikipedia.org/w/api.php?action=query&prop=info|flagged&titles=sandbox

Hi @cooltey . Please, take a look at the screenshot:

Not sure if we can override messages directly in mobileapps/i18n since the Translation updater bot does this automatically. @MSantos, what do you think?

@MSantos , @Jgiannelos pls take a look at this patch:
https://gerrit.wikimedia.org/r/c/mediawiki/services/mobileapps/+/805336

@cooltey , I'm going to refactor i18n plural rules for messages for zh-hant here and zh-hans here in mobileapps. Could you suggest the right translation for both variants (zh-hant and zh-hans) when it comes to translating these words: Updated today, Updated yesterday, Updated N days ago ?

Hi @Nikerabbit , thank you for the additional info about the banana-i18n library. I will provide more details. Please, install banana-i18n in isolated environment and check this code snippet for zh-hant:

const Banana = require('banana-i18n')
const banana = new Banana('lzh')

Hi @cooltey ! I suspect that happens when you try to set the talk page icon before all other HTML has been rendered. In the current implementation, this button is configured inside the onBodyEnd() function here and this is expected because we need the header to render first to append the icon to it. I have a few questions that might help me to reduce the scope of the problem:

1. Do all articles throw an error when you try to set talkPageButton: true or the only these two mentioned in your comment?
2. Do you try to set it before HTML has been loaded? In that case, it won't work.
3. Maybe you could explain how you wire the button in the app itself so I can also be able to reproduce this issue?

I've implemented View edit history functionality and added i18n tests for Arabic. As for zh languages, they won't work properly till zh-hans and zh-hant (along with some others) be introduced in the banana-i18n package (full list of supported languages here). @Nikerabbit , what do you think? You've mentioned zh and mk languages in https://phabricator.wikimedia.org/T249541#7569365 but mobileapps has 134 predefined language variants compared with banana-i18n which has only ~12 corresponding langs and some fallbacks.

Thank you @cscott, I've added a fix for parsing the legacy HTML output and set the patch to the code review.

The patch above is intended to test a possible solution. Seems that Parsoid propagates already encoded id values and I'm able to decode them on mobile apps (only for zh wiki). Parsoid output - https://zh.wikipedia.org/api/rest_v1/page/html/%E5%BC%80%E5%B9%B3%E5%B8%82/71986109 (see the shot as well).

This problem can be fixed by adding the background-color: initial rule to the pie chart divs which represent sectors.

This might be an issue on the Anroid devices only. I reproduced this issue with these steps:

1. Check the explore feed on the Android app. Feature feed triggers this endpoint - https://en.wikipedia.org/api/rest_v1/feed/featured/2022/04/08 where onthisday property contains the page that we need to view when clicking to More on this day →link.
2. Click More on this day →. From this point, I suspect that Android app invokes https://en.wikipedia.org/api/rest_v1/feed/onthisday/events/4/8 instead of https://en.wikipedia.org/api/rest_v1/feed/onthisday/selected/4/8 ( If you check selected API, you'll be able to find The Knights Hospitaller … Mamluk sultan Baibars. which was mentioned in the description )

A similar issue was mentioned here: T249541. After additional research, I've found that View edit history functionality had not been implemented at all. Check PCS here - https://github.com/wikimedia/mobileapps/blob/master/pagelib/src/pcs/c1/DemoMode.js#L23. The value of editedDaysAgo is hardcoded and was intended to be replaced by upcoming (?) functionality. I checked example of the summary endpoint of one of the article, but it seems that there is no explicit property editedDaysAgo there. However, I can calculate it inside PCS using the timestamp property and then render it on the footer.
@MSantos, @Jgiannelos , what do you think?

After additional research and testing, I've found that attempting to add body.pcs-platform-ios didn't make any changes. But instead, font overriding applied for wikipedia-ios.
Here is a screenshot that compares wikipedia-ios updated font | current font (which is actual now) | mobileapps updated font via body.pcs-platform-ios class:

I will try to test both variants. I already have some results with overridden styleoverrides.css but will test with PSC as well.

These cc rules affect the output of mobile devices. I disabled them to quickly check if it helps.

@MattCleinman CSS rules came from load.php for parsoid output and from https://ar.wikipedia.org/api/rest_v1/data/css/mobile/site for mobileapps ( even for local instance ). Check the shot:

Styles of the template Autres_projets break layout in this particular article. I suggest refactoring template styles or re-editing the article. I've checked other articles with this template on mobile-html (see the list of them here - https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Pages_li%C3%A9es/Mod%C3%A8le:Autres_projets). Though most of them don't look quite well on mobile viewport, no similar issues have been found.

Created first MR here - https://gitlab.wikimedia.org/jgiannelos/mobileapps-a11y-tests/-/merge_requests/1

@Jgiannelos It should be closed because PR has been merged.

Fixed regression caused by patch for May 5. Pls, check the updated one.
cc: @MSantos , @Jgiannelos

Hi @cooltey . Sure, I'll take a look.

Hi @Tsevener ! I've restored previous functionality and kept fixes from the T294899 at the same time. The issue was in the in sGalleryImage method which was intended to parse all images instead of only nested in the unordered list with typeof = mw:Extension/gallery attribute. Pls, check.
cc: @Jgiannelos

@Kelson I've just asked a question about this in the template discussion thread. I'll keep you posted if get any updates.

@Titore Thank you for your attention to this problem. I will take into consideration your case while working on the patch which is currently in progress.

Related repo with analytics functionality - https://github.com/VadimKovalenkoSNF/wmf-theme-issues-analytics
cc: @Jgiannelos

Hi @Tsevener ! I was unable to reproduce the issue on my Android device (see the version on the shot). Could you please provide some more screenshots or videos of the current gallery behavior?

@Kelson As per docs for this template the tip should not be rendered on the mobile app. And it actually doesn't - see the shot. Not sure whether we need to do extra actions here.

@Brycehughes cases with Barcelona and Tokyo also have been fixed in the patch above, I've just checked them. Once this patch goes to the beta cluster it will be more convenient to test other cases where this issue might happen.

@Brycehughes could you specify which exactly article did you test? I suspect that this might be a cache issue but not sure. I also found another article with exactly the same problem ( go to https://en.wikivoyage.org/wiki/Auschwitz-Birkenau, hover Oświęcim), so I put additional fixes in the follow-up patch above.
cc: @Arlolra , @MSantos

@MattCleinman Patch above is ready for review.
cc: @MSantos , @Jgiannelos

No, it isn't. I'm closing it.

This issue happens because /summary endpoint receives wrong extract and extract_html properties. Similar problem has been resolved in this task: https://phabricator.wikimedia.org/T295255
However, this particular case happens because mobileapps removes necessary data from the tag attribute.
Here is the problem part of the Parsoid output that is received by processing module (lib/processing.js):