User Details
- User Since
- Nov 20 2020, 1:35 PM (221 w, 14 h)
- Availability
- Available
- LDAP User
- Vadim Kovalenko
- MediaWiki User
- Unknown
Nov 20 2023
@Jgiannelos , yes, it is working now.
Oct 31 2023
Oct 19 2023
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
Oct 11 2023
Oct 10 2023
Oct 6 2023
Oct 3 2023
Sep 21 2023
Possibly fixed in https://phabricator.wikimedia.org/T327379
Sep 4 2023
@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
Aug 22 2023
@akosiaris , I've updated regexp, and now it works, thank you!
Aug 2 2023
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
Jun 22 2023
Jun 14 2023
Jun 7 2023
May 29 2023
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):
May 26 2023
May 23 2023
I set the patch to the review with the possible solution + tested this in XCode as well. Articles to test:
May 19 2023
May 18 2023
This ticket is blocked till we decide about ResourceLoader applying in mobileapps. Current patch provides two solutions that are not optimal.
May 12 2023
I updated the language codes listed in lib/wikiLanguageMapping.json. As a guideline, I used ISO 15924 and ISO_3166-1.
May 11 2023
Apr 26 2023
In addition, I would recommend refactoring template inline styles, for example, moving them into <templatestyles> (docs) . It will make their modification in PCS easier.
Apr 24 2023
Apr 19 2023
@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?
Apr 17 2023
Apr 11 2023
@matthiasmullie , it was a pleasure to collaborate with you, thanks for the assistance!
Apr 10 2023
@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.
Apr 3 2023
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.
Mar 29 2023
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.
Mar 28 2023
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.
Mar 23 2023
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:
Mar 20 2023
Mar 15 2023
Mar 9 2023
Mar 8 2023
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.
Mar 7 2023
@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.
Mar 6 2023
We are going to close this task but it is blocked by https://phabricator.wikimedia.org/T91344 which is still open.
Mar 2 2023
Feb 28 2023
@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?
Feb 27 2023
Feb 20 2023
@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.
Feb 16 2023
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.
Feb 15 2023
Feb 10 2023
Feb 9 2023
Feb 7 2023
Feb 6 2023
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?
Feb 3 2023
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
Jan 30 2023
Jan 27 2023
Jan 26 2023
Jan 25 2023
Jan 20 2023
(Almost ) all data inside parentheses is truncated now for the summary response, so this issue is no longer valid. Source code here.