just to emphasize it does work on the mobile website instead of the mobile app
https://en.wikipedia.org/wiki/Wikipedia_talk:Hatnote#c-Thryduulf-20231208030800-SMcCandlish-20231208012300
just to emphasize it does work on the mobile website instead of the mobile app
I'm afraid this reproducible bug is making mobile talk-page discussions unusable. Especially when there's copy and paste involved, such as in linking to a URL. Here's another illustration of the problem, this time at https://meta.m.wikimedia.org/wiki/Talk:Wikis_World Notice how the preview becomes unsynchronized with the editing field.
Thank you! That's all I need for the moment.
Yes: how could we petition for implementing this feature in a non-English Wikipedia, please?
for the record, clearing cookies solved the problem.
I'm using Chrome.
Here's a screen recording demonstrating the issue:
https://ibb.co/V2XQskr
I'm using Chrome with Gboard on Android 13 and Pixel 7a.
If I remove the ".m" particle from the URL, it's added back automatically (via URL redirection), when browsing Wikipedia in a mobile device.
my experience is that both current Vector (2022) and legacy Vector (2010) show the pencil icon for editing the article lead only, as per screenshots attached.
I'm afraid the pencil icon next to the history link allows editing only the lead section in Vector. Unless some of my settings are interacting badly.
Got it, thanks! Any chance it might make its way into the Vector skin?
Thanks for adding this! I can't make the new edit button appear, though. I've already changed the skin from Vector 2022 to MinervaNeue and confirmed the advanced mode was selected. Am I missing something?
@DLynch: here's my screenshot showing the two links for editing the lead only (not the whole article).
I see the same as you only in an incognito browser tab.
just to emphasize the "edit lead section" currently shows up duplicated, while the "edit this page" is missing.
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 "<sup>[4]</sup>[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.
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.