@Jgiannelos , yes, it is working now.

Got similar problem, but with bm.wikipedia.org
Check the output of https://bm.wikipedia.org/api/rest_v1/page/mobile-html/Bamaj%C9%9B
Actual output

Possibly fixed in https://phabricator.wikimedia.org/T327379

@cscott , could you explain distinguishes between parsoid=1 and useparsoid=1?
I noticed that you applied useparsoid for Kiwix here but this parameter doesn't seem to work as expected, I got warning Unrecognized parameter: useparsoid
Example of the request: https://en.wikipedia.org/w/api.php?action=parse&format=json&prop=modules|jsconfigvars|headhtml|text&useparsoid=1&page=Barak_Obama

@akosiaris , I've updated regexp, and now it works, thank you!

Hi there! I'm responsible for Kiwix migration to another API, but given the discussion above I'm curious whether you have plans to add MWOffliner to the allowed list to get access to /mobile-sections. And if so, how long it will be working? I assume that even though MWOffliner User-Agent was added earlier, MCS completely disabled already, because I've got 403 error page for this curl request:

curl -H "User-Agent: MWoffliner/1.13.0 (contact@kiwix.org)" https://en.wikipedia.org/api/rest_v1/page/mobile-sections

I debug Contact extension locally, and noticed that user's IP address is added to the email message title.
Here is the logic for adding IP address (link):

I set the patch to the review with the possible solution + tested this in XCode as well. Articles to test:

This ticket is blocked till we decide about ResourceLoader applying in mobileapps. Current patch provides two solutions that are not optimal.

I updated the language codes listed in lib/wikiLanguageMapping.json. As a guideline, I used ISO 15924 and ISO_3166-1.

In addition, I would recommend refactoring template inline styles, for example, moving them into ‎<templatestyles> (docs) . It will make their modification in PCS easier.

@Jgiannelos , @cscott considering https://phabricator.wikimedia.org/T117845#8576044 - does this make a blocker for me to replace sr-el / sr-cr variant codes to sr-Latn / sr-Cyrl in mobileapps service?

@matthiasmullie , it was a pleasure to collaborate with you, thanks for the assistance!

@thcipriani Hi! Pls, remove +2 rights to the SearchVue for me, since I'm not going to be a part of the project owners due to the end of my contract soon.

As I mentioned in https://phabricator.wikimedia.org/T271534#8629524, there are inline template styles that could not be overridden in PCS due to the arbitrary DOM structure of the tweet template. This might lead to the tight coupling between PCS and this template.

Upd: the reason that the first diagram in the example above is not broken on a dark theme, is probably because div tags don't have a text node inside. This might be helpful in terms of solving the issue.

There are a bunch of div elements that should have notheme class to avoid this issue on dark theme: https://de.wikipedia.org/api/rest_v1/page/mobile-html/Vorlage:Sitzverteilung?theme=dark. I'd rather apply a specific class to the template element itself and then recursively add notheme in mobile html then.

I don't think this can be fixed in PCS only by changing CSS rules and without breaking the layout. Changing z-index won't help: <sup> element isn't a positioned element. The problem was probably caused by setting the solid background to the <sup> element on the app (iOS/Android) level. I can suggest mitigating this issue by changing opacity from solid to ~30%, so the text on the left side will be visible. Here is a small standalone example:

Closed this as resolved since this issue has been fixed and fixes are currently on prod. If there are any related problems, feel free to file a new ticket for them.

@Aklapper I was about to close it as resolved but need product and web agreements first. There should be a decision about the definition of what exactly should be excluded inside parentheses.

We are going to close this task but it is blocked by https://phabricator.wikimedia.org/T91344 which is still open.

@cscott , I've tried to open the page with .js at the end of URL on the local mobileapss instance (http://localhost:8888/en.wikipedia.org/v1/page/mobile-html/User%3ACscott%2FTogetherJS.js), but got Dummy output. Parsoid does not support content model javascript. See T324711. error message. Any chances to get this page locally?

@Tsevener I've checked and realized that tweet template has a bunch of inline styles which leads to using anti-patterns in mobileapps to override them. I'd rather leave it as is till we come up with a solution for dark theme issues across Web and app wikis.

Seems that this hasn't been deployed to prod yet, local instance works for me, pls check: http://localhost:8888/en.wikipedia.org/v1/page/summary/Brandy_(You're_a_Fine_Girl)

@Tsevener a lot of lead paragraphs have some text in parentheses which is truncated. You can check my comment here for more details: https://phabricator.wikimedia.org/T259891#8542852. In your particular case, there is a ref inside parentheses that isn't filtered by regexp implemented in this patch. My solution tends to work only with italic letters. There are tons of possible cases where parentheses with the content should be kept for the preview, let's discuss.

@Asartea , could you provide a link to the protected user script page? This page, for example, is not protected and can be editable by any user both from the mobile app and a desktop.

Image attributes removal for mobile-sections has been introduced here - link.
Should we rollback the line with img: ['about', 'alt', 'resource'] to enable the alt attribute for images in mobile-section response?

Though mobileapps doesn't handle any implicit information that comes from templates, I decided to implement PoC patch which solves the problem, but in another hand adds an additional layer of complexity for the transformation module. The only information that we can manipulate here is the Parsoid HTML. For articles without short description explicitly set by wikitext it has <span> element with data-mw attribute. At the same time, this node is empty which is the signal for MobileHTML to strip it, so I've applied extra method to check whether this span was created by {{Short description|none}} wikitext and then passed this info downstream to create a mobile header. Please, let me know what you think of the approach I used in the patch.
cc: @MSantos , @Jgiannelos

(Almost ) all data inside parentheses is truncated now for the summary response, so this issue is no longer valid. Source code here.