This page can be used to raise problems with the mobile experience on Wikivoyage. Anyone should feel free to raise issues. If you are technical you can propose solutions. When at least 2-3 solutions exist, you can vote for solutions using Template:Oppose or Template:Support. When there is consensus for a particular change one of the interface admins can make the change.

When raising issues, there is no need to propose solutions if you do not have one.

Could you elaborate? I'm not quite sure what you mean by this.

• What do you mean by "edit the results"? What search are you referring to?
• Find in page ?

Please see mw:How_to_report_a_bug for guidelines on what's helpful! Jdlrobson (talk) 03:40, 13 July 2025 (UTC)[reply]

Edit the found word or phrase on the page. Yes, find on page. Ikan Kekek (talk) 04:19, 13 July 2025 (UTC)[reply]

If I'm understanding correctly the complaint here is that in desktop you can double click to edit (with the "edit pages on double click" preference) and have a sticky header which provides constant access to the edit icon. Is that correct? Or do you have additional code you are running? If not, please read mw:How_to_report_a_bug as it will save us lot of time with back and forth. How are you currently editing the found word or phrase?

If that is the complaint here, I think the issue here has nothing to do with find on page feature it's about access to the edit icon at all times. While it's true you don't have those available on mobile I'm not sure how you would make those accessible in a way that doesn't get in the way of the mobile experience and how the platform works. On desktop find in page is always open. On mobile it will close when you click another element - that's just how the browser works.

Double clicking would be accidentally triggered by the simple act of scrolling while reading which would be annoying, and having an edit icon always available would need careful implementation. A recent bug for this (phab:T328847) was declined but we could raise a more specific phab ticket to solve this issue. How would you imagine this would work? Jdlrobson (talk) 18:31, 13 July 2025 (UTC)[reply]

This is not about double clicking. Picture this: I'm trying to edit a full page and click "Edit full page". I then do a search for a word, phrase or particular set of characters. When I do that on the computer (in that case, using Command-F, or when I had an IBM clone, Ctrl-F), once that term is found, I can immediately click it and start editing. However, in mobile mode, I can't, and instead, have to go out of edit mode and back into it and scroll through until I manually find the text I had searched for and then edit it. Do you understand? Ikan Kekek (talk) 19:59, 13 July 2025 (UTC)[reply]

I can't replicate this. Could you provide some replication steps? Are you referring to the browsers back button here when you say "back arrow" or something in the user interface? Jdlrobson (talk) 03:44, 13 July 2025 (UTC)[reply]

I'll tell you when I'm spending more time editing on my phone again. Ikan Kekek (talk) 22:58, 14 July 2025 (UTC)[reply]

I think you raised this before and we've talked about this before so I'll need to find that conversation to remind myself of this. Jdlrobson (talk) 03:44, 13 July 2025 (UTC)[reply]

Are you using a different kind of rollback? I'm not a rollbacker on this project but not seeing any difference on my local version. Screenshots or even better a screencast would be super helpful.

Just to check - you have followed the guidelines on https://en.wikipedia.org/wiki/Wikipedia:Rollback#Mobile ? Jdlrobson (talk) 18:16, 13 July 2025 (UTC)[reply]

What I want to be able to do is compare two versions of the article and use the normal "undo" to change back to a previous version. I prefer to use rollback only for vandalism. However, in the mobile version, I can use the normal reversion tool in which I can type an edit summary (unlike with rollback, which doesn't allow the user to type an edit summary) for only a single new edit, not for a series of edits. Do you understand? Ikan Kekek (talk) 19:54, 13 July 2025 (UTC)[reply]

More information: https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Archive_links_invisible_in_mobile_mode

Proposed solutions

[edit]

1. Do nothing

[edit]

Leave this as is.

Votes

[edit]

Support Experience seems fine to me? Jdlrobson (talk) 22:22, 6 July 2025 (UTC)[reply]

• Oppose. Ikan Kekek (talk) 22:44, 6 July 2025 (UTC)[reply]

2. Expand it outside the "learn more"

[edit]

Pros: simple change Cons: Adds additional scroll to talk pages with lots of archive links, making them harder to navigate.

Votes

[edit]

Oppose The scroll is too significant on certain pages. Jdlrobson (talk) 22:15, 6 July 2025 (UTC)[reply]

• Support, but 3. is probably optimal. Ikan Kekek (talk) 22:44, 6 July 2025 (UTC)[reply]

3. Show archive more link

[edit]

We could achieve this by adding an ID to the archive link box and use a CSS target selector to display it when the button is clicked.

Pros: Clean and descriptive. Cons: Will need a bit of tweaking if we do not want this behaviour on desktop site too.

Votes

[edit]

• Support As proposer. Jdlrobson (talk) 22:22, 6 July 2025 (UTC)[reply]
• Support. Seems like a neat solution, as most readers won't want to read the archives most of the time, but this makes it clear that they are available to view. Ikan Kekek (talk) 22:44, 6 July 2025 (UTC)[reply]
• Support per Ikan. //shb (t | c | m) 08:32, 13 July 2025 (UTC)[reply]