Thanks @Aklapper. Not sure if this kind of display should not be avoided, if possible?

the issue is also present in talk pages

screenshot 1 (mobile browser) displays the untitled link correctly, as "^[4][1]".

Understood, thank you for the clarification. For the record, the display discrepancy does not involve the desktop version, it's actually between the website mobile version and the native mobile app. Maybe the website mobile version needs to follow the same design principle, for consistency.

I'm afraid such inconsistency in display across app vs. browser might drive editors away from tables, recasting important information in the form of lists, for example.

In T327612#8550536, @Aklapper wrote:

Hi, why should long tables on small screens not be collapsed by default? What's the incentive? I don't see a bug here...

if you have any recommended changes to the pt template, I can volunteer to modify it; maybe in a test template first.

I'm afraid we're still seeing this issue at pt.wp, for example:
https://pt.wikipedia.org/wiki/Corregedor_%28Portugal%29

thanks all, I should have tested on an incognito tab.

I've tried creating a redirect "Ebc" to the existing dab "EBC":
https://en.wikipedia.org/w/index.php?title=Ebc&redirect=no
Now, searching for "Ebc" correctly produces EBC as the first hit.
However, searching for "ebc" still produces EBCDIC.
Is it a side effect of the inability to create pages with a lowercase initial?
Since lowercase is the default keyboard setting for most users,
I still think a denormalization would improve the user experience.
Would it be terribly expensive to create all-lowercase shadows of every term?
Although it'd duplicate the memory requirements, it's still the same order of magnitude.

I confirm it works well now in dark mode – thank you!

it works well in non dark mode

could this help?
https://www.wikidata.org/wiki/Wikidata:Structured_Categories

In T259622#6736621, @apaskulin wrote:

Hi @Fgnievinski, Yes the configuration can be customized for each Wikipedia language

Thanks for this. Would it be possible to apply different a configuration for each Wikipedia language?

Maybe this issue has already been fixed as part of T172686?

Would you mind elaborating why this is low priority? I looked at Trello but couldn't find any rationale. In the desktop, categories are a first-class navigational feature. Thanks.

just to emphasize that with the merger of task T87878 here, this feature request applies to both mobile website and app.

In T108761#1529863, @Krenair wrote:

WFM. What browser are you using?

Categories normally are displayed at the bottom of an article page, as in in the desktop website version.