One down side from the size of the Lead image : article Cat as the example

*The api also returns the available size in 320, 640, 800, 1024

Possible that we can the file from the info box. File

Of course loading a 11MB image would be a blocker. I would prefer to stick with the lead image determined by MW and not pull a random image from the infobox. We could consider querying the summary endpoint and merging it with everything else in useArticle(). In many cases this API will already be cached.

So far the only missing piece is the property languagecount

I think it's fine to always show the language action button on the first page and allow the user open the language setting, even the article has only one language

or another solution we prefetch the langlinks to determine showing the language action button, but I think this takes user bandwidth which is not nice.

PR https://github.com/wikimedia/wikipedia-kaios/pull/334

Do not merge this until the final confirm and there are still some need to be fixed.

This spike has been done, to answer the question (✔️better;⭕ no better or difference),

Would it help with rendering of tables, maps, etc?

⭕ Nope to the maps, same as mobile-section
✔️ partially help in table - in the table markup, there is already existing ready to use template instead of building our own; but some legacy table still exist in older markup, i would recommend hiding them .wikitable to avoid ugly table shown.

Would it help in image?

⭕ In mobile-html the image has lazy load, therefore the script need to parse the lazy load image tag then insert them into the content manually.

Would it help with the hyperlink?

⭕ the hyperlink has several things - article preview / reference preview / image preview / subcontent / external link / interwiki link

it does have slightly difference but we still handle these one by one

Other things :

⭕ Lead image problem see here https://phabricator.wikimedia.org/T272091#6895468
⭕ languagecount problem see here https://phabricator.wikimedia.org/T272091#6928161

After discussion with @SBisson , there are few more steps to try

1. Load the summary API endpoint for the lead image; load the langlinks API to get the actual language count.
2. Documentation on how we parse the mobile-html content
3. would pcs base url styling better in the app?

These are the endpoints requested during the article loading (Article Cat as the example)

Here's the summary of how the app parses the mobile-html endpoint and show it on the page

Testing:

General regression testing did not show any functional issues. Will move this for sign off.