Module talk:Marker

Special characters

It seems the name parameter needs some escaping. In the mapframe of Budva, L&M Restaurant shows up as "L&M Restaurant". I assume this is a problem affecting many more cases. It might break some links – we avoid special characters in article names, but if we cannot get this module to handle them, the problem should be discussed in Wikivoyage:Naming conventions (I added a note). How does geoJson handle special characters? –LPfi (talk) 06:30, 5 October 2022 (UTC)

Wikipedia icons

Today I noticed Wikipedia icons are now showing up in marker templates connected to Wikidata icons, even when the template has a blue link to the Wikivoyage article connected to the same Wikidata element. For example, see Marin County#Cities. @Andyrom75: Could this be caused by your recent changes to the module? I think the past consensus is that these bluelinked markers shouldn't have Wikipedia icons (we should encourage readers to read our article about the destination first, before sending them off to a sister site). —Granger (talk · contribs) 04:44, 8 December 2025 (UTC)

@Mx. Granger, I'm doing some code enhancements, but the intent is to keep the same behavior. Thanks for highlight it. Just fixed. Andyrom75 (talk) 09:23, 8 December 2025 (UTC)

Thank you! —Granger (talk · contribs) 02:46, 9 December 2025 (UTC)

Mistaken 'NOT EXISTING IMAGE' error

Hi, e.g. in Ruzomberok main train station shows the error, but the image in fact is there and works... Anyone has ideas?

Another related topic is, when I googled for 'hrabovo valley wiki', I saw this text in the search results:

Ruzomberok – Travel guide at Wikivoyage
...
49.0708 19.2726 9NOT EXISTING IMAGE Hrabovo valley . Relaxation and walking in the valley/forests around, as well as zorbing, ziplining and wellness.

So somehow the coords and error get into the google text. I can imagine it breaks SEO a bit? OTOH I don't see this in the anonymous mode wiki page, so I'm not sure how google gets it - maybe they use some wiki account when downloading the pages?

-- andree 07:40, 7 March 2026 (UTC)

@Andyrom75:-) -- andree 06:53, 10 March 2026 (UTC)

@Andree.sk, currently I've written the file name without URL encoding, so the alert disappeared. I'll evaluate the possibility to accept also this alternative syntax. Andyrom75 (talk) 09:26, 11 March 2026 (UTC)

@Andree.sk, I've developed a code variant to accept the URL encoded filename (to be further improved and by now only on it:voy), but I'm skeptic on its definitive implementation. Let's talk about it.

Let's take for example the following two links to the same file:

• Regular filename: Древнерусская ладья "Анна Ярославна". Морской фестиваль Брест 2012.jpg
• URL encoded file name: %D0%94%D1%80%D0%B5%D0%B2%D0%BD%D0%B5%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B0%D1%8F_%D0%BB%D0%B0%D0%B4%D1%8C%D1%8F_%22%D0%90%D0%BD%D0%BD%D0%B0_%D0%AF%D1%80%D0%BE%D1%81%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%22._%D0%9C%D0%BE%D1%80%D1%81%D0%BA%D0%BE%D0%B9_%D1%84%D0%B5%D1%81%D1%82%D0%B8%D0%B2%D0%B0%D0%BB%D1%8C_%D0%91%D1%80%D0%B5%D1%81%D1%82_2012.jpg

Accepting the second version would simplify the life of the "lazy editor" that will paste this filename (thanks to the more flexible code), but on the other side, this will complicate the life of the following editors because this filename in unreadable.

Let me know what you and the other thinks about it. Andyrom75 (talk) 11:06, 11 March 2026 (UTC)

@Andyrom75, the picture obviously exists and works even with non-URL-encoded image (if I click the marker, it normally displays the image). So your solution is probably okay. I'd just simplify the code using something like

image = mw.title.new(args[par.image], 'Media');
    if (!image) { image = mw.title.new(decode(args[par.image]), 'Media'); }
    if (!image) { ...error }

-- andree 11:19, 11 March 2026 (UTC)

@Andree.sk, I'm not referring to the code itself, I already have an idea on how to improve it, my doubt is more from a policy point of view: do we want to accept URL encoded filename or do we want to encourage/force the editors to use readable filenames? Andyrom75 (talk) 11:46, 11 March 2026 (UTC)

@Andyrom75, I'd say the above were automagically created by the listing editor back in 2016. Maybe now it doesn't do it? No idea... Nevertheless, "we" probably don't want to fix all the issues in XYZ articles? So I'd say it's easier to have the url decoding fallback in place. -- andree 15:25, 11 March 2026 (UTC)

I can place a temporary category to check how many occurrences exist for such kind of "error". In fr:voy I've corrected many thousands of mistakes within the last months, so, if not excessive, I can do the same here in en:voy.

PS I haven't got the point about the listing editor. Andyrom75 (talk) 23:15, 11 March 2026 (UTC)

Only 67 occurrences. I've already patched them all. I'm keeping for a while this temporary category just to see if any occurrence is not yet caught because of cache update. Andyrom75 (talk) 08:13, 12 March 2026 (UTC)

cool, thanks for doing it! :-) -- andree 08:25, 12 March 2026 (UTC)

@Andree.sk, no problem. However, I'll drop a message in the lounge to understand what the community would prefer to do for the future. Andyrom75 (talk) 09:29, 12 March 2026 (UTC)

In the meanwhile I've improved the code in it:voy, waiting for the final outcome of the discussion on en:voy. I'd like to keep all the codes fully aligned. Andyrom75 (talk) 12:02, 12 March 2026 (UTC)