Wikivoyage talk:Listing editor

Active discussions


Listings editor draft

I have added a mock up of what a listings form editor could/should look like.

I left out some of the fields we currently have, because most of the time they shouldn't be added (e.g., fax, checkin/checkout). They still would be editable via the wiki markup, but since the listings editor is above all for the use of people who are less familiar with how the site works, I think it's best to leave off the more obscure fields from the visual editor. I also left off lat and long, because I think that those fields will need to be filled automatically, not manually.

I included the 1-10 star rating as with the listings review editor, since, why not.

One thing we should keep in mind is that this form editor will need to be mobile-editing friendly.

Thoughts? --Peter Talk 20:24, 1 February 2013 (UTC)

I should add that this visualization is for new listings, but all listings should have an "edit" link after them that pulls this up with the information already populated. --Peter Talk 20:47, 1 February 2013 (UTC)
Proposed addition of currency drop-down list.
Looks good overall. One thing I would like to see added is the automatic addition of currency symbols beside the price range. So, if you were adding a listing to Chicago/Loop, automatically a "$" symbol would be added to the side. If adding to Kolkata, then ? would be added. If the user wants to quote prices in a foreign currency (say US$ in Luang Prabang, instead of kip), then the currency symbol can be clicked and a drop-down list would appear with common currencies. This could be quite complex to implement, but I believe it would fix a lot of issues we have with consistency between currency symbols. One issue I foresee is how to add symbols that should appear on the right, like '100 taka' in Dhaka.
By the way, although we should eventually develop a listing editor for mobile devices, I see it as low-priority. Most people who use Wikivoyage mobile are viewers, not editors. And people who do want to edit are usually experienced editors anyway who appreciate that these things take time. JamesA >talk 03:29, 2 February 2013 (UTC)
Note: I've made a crappy mockup in PNG format on the right, to demonstrate what I'm on about. JamesA >talk 03:42, 2 February 2013 (UTC)
I definitely think having a pull down menu for currency signs makes sense.
For mobile editing, I don't think people will be writing articles, but updating hours information, noting closed businesses, fixing address typos, or just adding a line to a description are all things editors could do from their phones while traveling—while using our guides. Presumably they could also upload geocoordinates based on their location at the time of editing. --Peter Talk 17:56, 2 February 2013 (UTC)
You're correct about the mobile stuff, although I foresee it as taking a very long time to develop, as it already took the WMF forever to release the 'read-only' mobile skin that we use now. While adding geocoordinates based on location of editing is a fantastic idea, I think it would also be highly difficult to implement through a web browser. Possibly it could be done much easier through an app. JamesA >talk 01:33, 3 February 2013 (UTC)
Any chance WMF would develop an official app that would allow this? Maybe even with a grant? The big issue would be supporting all OSs. Adding geocoordinates to an edit wouldn't be good at all. While you could assume an edit is being made at the location of a restaurant, etc., it could just as like be made in a hotel room or even a private residence. That could constitute private info (per WMF policy) if you connect a user/IP address, time, and a location like their grandma's house, where a user is updating a restaurant listing where they ate the day before. AHeneen (talk) 04:21, 14 February 2013 (UTC)
I think having a button that says "I'm here now" with a confirmation message that explains that they are sharing their current location with the world would take care of those concerns. The who and how questions regarding mobile editing will, I think, come after we develop a listings editor for desktop editing. Basically, if we have a shiny looking popup editor, developers will be more likely to get excited about extending its use into mobile. --Peter Talk 03:40, 22 February 2013 (UTC)

I created a feature request for this on the MediaWiki bug tracker. It's number 46225. This talk of new features and mobile is nice, but I think it's more important that something gets done quickly. In many pages like this one compared to this wikitravel one, people have started removing the tags. It's crazy they migrated all the data before this was in place. If something isn't done soon, this is going to be a major issue. —The preceding comment was added by Slacka123 (talkcontribs)

Have you taken a look at HotCat? HotCat is a JavaScript program that helps registered users easily remove, change and add categories to Wikipedia pages. This is very similar to the functionality that we need for the Listing Editor.Slacka123 (talk) 11:26, 19 June 2013 (UTC)

HotCat is quite an engineering marvel, but is really ancient in terms of web design. -- torty3 (talk) 05:12, 28 July 2013 (UTC)

Notification of IdeaLab proposal for a new Listing EditorEdit

Swept in from the pub

Hi all. As per the original discussion here, I've made a new proposal on the Meta-Wiki IdeaLab for a Listing Editor. I've proposed that it'd have to be built and funded by the WMF. If you could provide input, comments and/or support on that page, it'd be appreciated. Please comment on why you think the listing editor is such an integral part of our wiki, and how we are severely disadvantaged when we lack it and other "free" travel wikis have it. Comment here: meta:Grants:IEG/Listing editor for Wikivoyage. JamesA >talk 01:58, 14 February 2013 (UTC)

I think Wikidata Phase II (currently in development) will eventually include an editor like this. It might be a good idea to ask the Wikidata devs about this. —Ruud 18:26, 15 February 2013 (UTC)
The proposal will need to be modified to match m:Grants:IEG#ieg-learn. It's currently worded as if new or existing WMF staff are to do the programming; this needs to be changed to estimate time and monetary cost for a non-WMF programmer (or programmers) to implement this entirely as a client-side script or gadget (so no MediaWiki extensions or code to be installed server-side, and no WMF "engineering" involvement either to write or to evaluate the code). K7L (talk) 21:03, 18 February 2013 (UTC)

Listing editorEdit

Swept in from the pub

Well just in time to make use of Ryan's excellent bot work on templates, I've done up a listing editor at User:Torty3/editor.js, and to test it out, add importScript('User:Torty3/editor.js'); to your common.js. Now, I'm not a Javascript expert by any means and looked over at the other projects for examples (all the coders seem to be at Wikidata :), so a quick review would be great. Had a look at the Visual Editor and I think it could be problematic because it doesn't really process templates all that well.

Known bugs: cannot process nested templates and pipes, which might be problematic for ru.voy, but I don't think they're quite prevalent here. City/park/airport/district article state templates will need to be slightly tweaked in order to add the [add listing] button. The editor could also be implemented as a beta gadget to make testing easier. Further features could include geolocation, but I'm still contemplating how that would work out. -- torty3 (talk) 10:28, 23 July 2013 (UTC)

Wow! It's a great start! After a very quick few tests, here are a few comments/bugs:
  • Newly added listings seem to be uneditable - I copied a few existing listings to a new page (graffiti wall), then tried to edit. The buttons did nothing.
  • I think having more fields/less fields is unnecessary, as some of those hidden fields are very common. There seems to be plenty of room to have it simply open up everything by default, so why not?
  • Place name should be editable
  • Sleep listings need to have checkin/checkout fields instead of an hours field
  • The edit buttons should be hidden when looking at a non-current version of the page, so as not to inadvertently edit an old version
  • The "image" field is not currently part of the listing template, and is quite buggy: When the image field is filled in for one item, it appears in that field for all items in the section. If a second one is added, random other listings get deleted. I think this field should be simply removed from the editor, as the template doesn't do anything with it currently and we do not encourage having an image for every listing (and restaurant/shop/hotel listings are actively discouraged from having their own image).
Problems aside, this is a very exciting development, and I'm really looking forward to getting the kinks ironed out and getting it rolling! By the way, what kind of changes to the article templates would be needed? Texugo (talk) 11:26, 23 July 2013 (UTC)
  1. Hmm, unexpected use case. It's based on editing sections, so it needs at least one heading to make an edit. Will try to fix.
  2. Wasn't too sure about more/less fields, was just trying to balance the visual load.
  3. Will fix the place names/sleep listings and edit buttons.
  4. Just added in the image field because the dynamic maps are using them, see Soltau, though that's more of a de.voy preference still. Could probably hide it. I think the big deletion may have been due to the equal signs in the website url, which is pretty bad.
  5. Article status templates - eg outline city, guide district, usable airport, will need a unique identifier like <div id="#root_location"></div> to load the [add listing] button, because countries/regions/travel topics shouldn't get the [add listing] buttons. Should the [add listing] buttons show up next to Understand/Get in/Get around? Because we could still add a tourism bureau listing for example. Also should there be no [add listing] buttons in main huge city articles?
It was easier than I thought to set up, but the niggly part will be getting it to work perfectly. By the way, the only code needed in common.js is
then I can keep updating it separately. -- torty3 (talk) 12:09, 23 July 2013 (UTC)
Great work! I think this is crucial for the project, and can't wait to see it implemented. When testing it, I got a similar bug as Texugo [1]. Globe-trotter (talk) 13:28, 23 July 2013 (UTC)
Another thought: You might want to make the "type" field a drop-down selector so that only valid types can be chosen. Otherwise we may get people changing it to "hotel" or "museum" or "mexican food"... Texugo (talk) 14:36, 23 July 2013 (UTC)
Oh yeah. Was being lazy by making it read-only :D Type will be automatically selected when adding listings, though a dropdown menu will of course be more flexible. A text input is for some other languages in mind, hence why I was leaning towards extensible code. Which is a little bit of the drawback with the templates compared to the tags. -- torty3 (talk) 15:30, 23 July 2013 (UTC)
I was just thinking that a drop-down type selector would make it easier to correct existing cases where the wrong type has been used, but there is no reason for it to accept free text input, which just results in a red template link for any non-legitimate type entered. Texugo (talk) 15:49, 23 July 2013 (UTC)

Fabulous! Here we go:

  1. Per Wikivoyage:Accommodation listings checkin/checkout are rarely supposed to be filled out, so it's probably best to just leave them off the editor. I recommend the same for fax. I can't for the life of me find the discussions where we planned to leave these off the form based listings editor, but I swear we had them ;) Marketers always add useless info for these sections, and we also don't want to give editors the notion that it's worth their time to add fax numbers for nightclubs.
  2. The editor doesn't pop up for the listings at Valle de Cocora#Do, presumably because they don't have all the standard fields in the wikitext. I did that to get listings to show up on the dynamic map, and this will also be an issue for other itineraries where the "listings" need to go on the map, but are in the middle of narrative, like The Wire Tour. The solution there might be to have a separate POI-tag for use in general prose, rather than a fix to the editor. It wouldn't be desirable for the form editor to add those fields when updating the ones already present.
  3. I think it's best to add the [add listing] button only to traditional listings headings: see, do, buy, eat, drink, sleep, and connect. While they occasionally see use in other sections, like fax and checkin times, they're rare enough where we don't want to encourage their use on the level that an [add listing] button would suggest.
  4. The editor gets confused by listings that lack an item in the name= field, e.g., restaurante anonymous in La Macarena#Eat. In that same section, for reasons much less clear, the form editor won't appear when clicking [edit]. My best guess is that there is an extra space in the name= field.

I'll find more stuff as I keep testing. --Peter Talk 18:10, 23 July 2013 (UTC)

Wow, this is BRILLIANT! Editing listings is a blast now!
That said, I have an issue in Dresden, where there are both a Holiday Inn and Holiday Inn Express in the same section, and it won't let me edit the former, opening the window for the Express whenever I try the regular Holiday Inn (the Express is first on the list).
It would also be good to have at least the more popular currency signs (€, $, £) next to the "price" field, as copying them in is a bit of a chore and defies the streamlining/timesaving aspect of the editor a bit.
If you were thinking of expanding the editor further, an "add listing" button would be brilliant, and it would be good if we could simply drag-and-drop listings between sections, as well as automatically arrange them alphabetically inside a section.
Thanks a lot for that and have fun further developing the editor! PrinceGloria (talk) 03:34, 24 July 2013 (UTC)
Another helpful idea: When a URL is added, have it check that it starts with http:// and if not, add it before saving. I just finished correcting about 1300-1500 wrongly inserted URLs, so obviously this is a problem that the listing editor could help avoid. Texugo (talk) 23:00, 24 July 2013 (UTC)
Think I've added most of the features asked and fixed bugs, except for how it looks. Will expand more over at Wikivoyage:Roadmap/Improved_editing_interface. -- torty3 (talk) 04:46, 28 July 2013 (UTC)

Ready for deploymentEdit

The listing editor is quite done. It adds an [add listing] button next to headings and a small edit button next to templated listings, to enable quick insertion and editing of listings. Is it ok if I activate it sometime this weekend, also in conjunction with the new listing/sandbox? Any bugs found should be reported to Wikivoyage talk:Roadmap/Improved_editing_interface. This may also require increased patrolling, depending on whether it gets more people to edit. -- torty3 (talk) 08:18, 8 August 2013 (UTC)

Looking great! I think it's ready. And we should probably move all the help and discussion to WV:Listing editor, as you have suggested. Texugo (talk) 11:12, 8 August 2013 (UTC)
Activated. I've changed both the Mediawiki:ListingEditor.js and Mediawiki:ListingEditor.css so you might want to look at both. Added note about using a geo microformat span to aid in the GeoMap. Thanks everyone for testing, and the code for importScript(User:Torty3/editor.js) can be removed now. -- torty3 (talk) 05:22, 14 August 2013 (UTC)

New listing editorEdit

Before opening listing editor
After clicking the edit button for a listing

Alright, so I fixed the inline editing of listings such that it will only use non-empty fields, compared to indented listings which will still include the empty ones. Listings must have a minimum of a name, address or alt field. Listings with ampersands and pipes in content sections now work. Will need to look further into the regular expression again to fix the issue with similar names.

I ended up adding the [add listing] button where there weren't any Cities or Other destinations headings, but a few still slip through the gaps like Gili Islands and County Kerry, so maybe it's still best to use a unique identifier in the article status templates.

Should I remove the more fields/less fields entirely? -- torty3 (talk) 05:12, 28 July 2013 (UTC)

I think the more fields/less fields are good. Better not to overload the user with fields that only few will need or want to use.
I have also accounted a few other things. When adding a listing, it will place it at the bottom of a section. This can be confusing, as a listing might be added to a wrong subsection, like when I added a microbrewery here [2], it automatically added it to a section with coffeeshops. I think new listings are better placed after the introductory prose, but before other subsections.
Then there's attribution. I'm not sure if this is really an issue, but there is no message that writers agree to publish their content under a CC BY-SA 3.0 license. Maybe that should be added somewhere? Globe-trotter (talk) 11:33, 28 July 2013 (UTC)
Done. I suppose ideally each third level heading will have an [add listing] button, but the Mediawiki structure is a pain to work around. Your suggestion is a lot easier to implement. -- torty3 (talk) 16:32, 28 July 2013 (UTC)
I cracked it! Third level headings now have an [add listing] button. I stumbled across some old pages about the old editor, and it says a lot about ease of use/development when Mediawiki has a great open API system. Also fixed the issue with the similarly named listings, but haven't been able to replicate any problems with umlauts. Is there an example I can look at? -- torty3 (talk) 10:44, 30 July 2013 (UTC)
Fabulous! I have a few more suggestions:
  • Change Tollfree example from "1800 100 1000" to "+1 800 100 1000"
  • Link Geomap from Latitude & Longitude terms? Or link to Geomap and Geobatcher next to the fields?
  • Make currency symbols insertable
And of course it would be great for listings to be sorted alphabetically automatically, rather than tacked on to the bottom. But I realize that may be out of reach. --Peter Talk 20:10, 30 July 2013 (UTC)

It's coming along! A couple more things:

  • I see in the screenshot at right that the add listing button matches the regular edit button, but in my browser (Chrome, Win 7) the add listing button text is much larger and bolder than that of the edit button. Does not look good.
  • I know Globe-trotter says no, but I feel very strongly that you need to get rid of the "more/less text" thing and have it just open everything, with the content box extended across the full width of the bottom. Listings in many countries almost always have an alt field, the day is coming when there will be massive efforts to get lat/longs in as many listings as possible to work with dynamic maps, and the extra click every time gets old pretty quick. Plus I would think we would want to encourage people to fill in as many of the fields as possible, particularly those lat/longs.

Texugo (talk) 22:18, 30 July 2013 (UTC)

How long do we think before this goes live? Travel Doc James (talk · contribs · email) 01:25, 31 July 2013 (UTC)
Your comment just reminded me that it's not yet live! I think it's ready, but I'll let Torty3 make the call. --Peter Talk 21:18, 31 July 2013 (UTC)

Here's another issue (which was also the case for our old listings editor): after clicking the submit button, all fields will be added to the wiki markup, even if they weren't there before, and were not filled in when using the form editor. See example. Maybe the better solution there, though, is to have a different way of adding coordinates to an in-line POI that needs to appear on the map as a listing. --Peter Talk 01:00, 2 August 2013 (UTC)

That was actually one of the first things I fixed, but I missed a single line that actually tested whether it was inline.
Regarding making it live: I think it needs a little bit more testing, although the WMF seem happy enough to release a barely beta version in the name of accessibility. I'm working on another implementation that will work with nested templates like those in Brooklyn/Williamsburg, which is still a little sketchy and I gather is causing most of the problems with the Visual Editor as well. There are some bugs PrinceGloria reported, though they don't happen consistently, and is probably a rogue regex match gone wrong. Nothing really destructive (I hope). Plus as you can see it doesn't work with the listing/sandbox, so just trying to get that and the dynamic maps out of the gate first. If I get enough time, next weekend is quite optimistic.
I'm pretty swayed by Texugo's reasoning, but the current one works for now and a change will require a bit more time. I've tested Chrome/Win 7 and there doesn't seem to be any size problems. And it has the same CSS properties as the edit button, so if it was a user preference, then both the edit button and add listing buttons would appear the same.-- torty3 (talk) 02:35, 2 August 2013 (UTC)
PS yep alphabet sorting is pretty much out of the question. Too many things can go wrong.
Talk pages also show [add listing], see for example Talk:New York City#Eat. You might want to exclude Talk pages from the editor. Globe-trotter (talk) 17:50, 6 August 2013 (UTC)
Ok, I reckon it's about ready to be rolled out as I've adjusted the find/replace function, although I still can't guarantee that there aren't any bugs. I also need to sort one more thing out with the GeoMap. Not entirely happy with the loading times, though it's partly due to the use of jQuery dialogs. If any one can optimise it further, that would be great.
I want to move all this over to the talk page, and perhaps rename this page Wikivoyage:Listing editor for documentation and make it easier for others to find and report bugs. Is that alright with everyone? -- torty3 (talk) 13:12, 7 August 2013 (UTC)
That makes sense, I'm all for it. Globe-trotter (talk) 17:43, 8 August 2013 (UTC)
Just used it. Easy and works great. Travel Doc James (talk · contribs · email) 07:09, 16 August 2013 (UTC)

User experiences with the listings editorEdit

Some issues I encountered

  1. The editor seems to get confused when there are subsections in a section. E.g. I filled in a few fields, but nothing was saved.
  2. Special characters, like umlauted vowels or the ß, when used in the POI's name, make editing impossible - the window either won't open or the edits won't save.
  3. Same happens if any part of the name is either italicized or (unnecessairly) bolded using apostrophes
  4. There is a problem is there are similar names consisting of separate words, e.g. "Holiday Inn" and "Holiday Inn Express". The editor would only access the Holiday Inn Express, which was first on the list (clicking on "EDIT" next to Holiday Inn also opened the Holiday Inn Express listing).
  5. If a listing is in the wrong section (e.g. a "Do" one in the "See" section) the editor does not seem to save the edits

Those were not major problems for me, I just edited listings the "traditional" way, and the editor as still a blast for the majority of the listings, but for a rookie user this may prove frustrating and confusing. I am sorry I did not put down the exact listings I had problem with, I edited quite a few over the last few days being so excited about the editor. I hope this helps, PrinceGloria (talk) 10:39, 30 July 2013 (UTC)

Yes that helps tremendously. I'm happy it spurred you on an editing spree :) I have fixed 3 and 4, but will need to look into the rest. I suspect there are some Unicode issues for the umlauts. I will need to check whether this is the same for special characters like Russian and other languages. Also, how is it speed-wise, on both popup and saving? It's faster for me than going to the direct editor, which now reminds me to go check how it works on long pages. -- torty3 (talk) 12:04, 30 July 2013 (UTC)
Whoops my fix for 4 overrode 3. -- torty3 (talk) 12:08, 30 July 2013 (UTC)
Happy to hear you're happy! For me, editing with the editor is obviously faster and more convenient. No problems with long pages thus far. PrinceGloria (talk) 14:12, 30 July 2013 (UTC)

The editor doesn't know when it is not on a main namespace page. Talk pages often have sections called Sleep or Eat or whatever which discuss the corresponding section, and the editor adds an [Add listing] button even there on the talk page. See Talk:Gothic architecture. Texugo (talk) 11:38, 6 August 2013 (UTC)

  • I see no instructions on how to enable this for test purposes. It's not in Special:Gadgets and MediaWiki:Gadgets-definition and Wikivoyage:Listing editor seems just to be a piece of the same discussion that's on this talk page. I do have two question — does [add listing] insert the new listing in its proper (alphabetical) position in a subsection of an article or does it just append to what's already there? and is there a [mark venue as closed] to flag outdated listings? K7L (talk) 14:25, 11 August 2013 (UTC)
There are instructions in the thread on the pub. Add the following code to your User:Username/Common.js :
And no, it just adds them to the bottom of the section. Automatically keeping them in order is considered pretty complicated for now. And when something is closed we just remove the whole listing, like we always have. Texugo (talk) 15:38, 11 August 2013 (UTC)
I added some listings by hand into Dresden#Buy, and they prove uneditable in Friefox unless more fields than just "name" are filled. It seems the editor requires the "content" field to be present/filled to function properly, which is not very helpful when I want to just add listings quickly to edit them later using the editor. PrinceGloria (talk) 19:12, 11 August 2013 (UTC)
I tested a bit. They don't have to be filled, but something apparently needs to be present (even if empty). But I do have to wonder what led you to go out of your way to add listings with no other fields present, with only like {{buy|name=Blah}}. That means you used neither the listing editor nor the convenient buttons above the edit window, nor did you copy and paste. I agree that it should work even like that, but I don't think it is something we have a lot of. Texugo (talk) 20:23, 11 August 2013 (UTC)
It is a lot quicker to just type {{buy|name=Blah}}, albeit hard to account for. The ability to do that was removed because it conflicted with listings with nested templates and listings with similar names, but I should be able to code around it. I'm in the middle of a long and boring but necessary review and documentation, which have brought up similar edge cases and possible changes to be made, inevitably pushing back the optimistic weekend projection. I was thinking of an intermediate beta gadget stage for editors only, but am confident that it works well enough and is of high priority. I will post up what I've written for now. -- torty3 (talk) 02:11, 12 August 2013 (UTC)
It is not quicker to type that than to click the   icon, but anyway... Texugo (talk) 02:42, 12 August 2013 (UTC)
Texugo, to me it is quicker to open the edit window, position my cursor and start typing with my both hands not moving them from the keyboard. I am a fast typer and I like it this way, I love keyboard shortcuts and everything that does not require me to move my attention or hands from the keyboard. Clicking the icon does not only require an interruption of that, but also inserts the whole template with all the fields, and also has it indented several times, which makes the block of text I am inserting the templates into quite unreadable and unmanageable to me. Just to explain to you that not ALL people think and act as you do, so do not assume that please.
Torty, your work on the editor is invaluable, the community owes you a lot for all the time and effort spent on it, as well as taking the time to listen to all of our requests and suggestions and act upon them.
As a sidenote, pertaining more to the templates themselves than the editor - the template ALWAYS inserts a full stop after the "name" field value, even if all other fields are empty. This does not help including templates with latlongs in the body of the text, which is sometimes desirable (there is little point in providing WWW, email or telephone for a railway station, bus stop etc., but it is good for it to have an icon on the map if it is mentioned in the article).
Kindest, PrinceGloria (talk) 05:35, 12 August 2013 (UTC)
I'm not exactly encouraging the practice :) as it does complicate matters. And I just remembered why I didn't fix it the first time round, so still needs a rethink. Same for the listings with exact same names, I'm not too keen to fix that since people shouldn't really be adding multiple branches but it has to be accounted for.
Thanks Texugo for going ahead on pt:voy, it's reassuring that it works nicely as planned. I'm not really going to change much of the code, but will add a link to this help page before moving it to Mediawiki namespace. -- torty3 (talk) 07:11, 12 August 2013 (UTC)
Also, for the listings formatting, Russian Wikivoyage has implemented a parameter 'format=inline' to remove the full stop, and we should probably do the same. In a tick. -- torty3 (talk) 07:24, 12 August 2013 (UTC)
I don't think consensus has sanctioned use of the listing template in-line in prose like that. There have been some objections and suggestions that we should create a different template for in-line use which doesn't show the edit button after, doesn't contain all the fields, etc., so I don't currently see a reason to remove the period. Moreover, I'm not really sure we really want to encourage insertion of templates without all the fields present, as it makes things tougher on the next manual editor, and potentially precludes some things that might be done with bots, etc. I think we should be inserting the whole template with all the fields, every time. Texugo (talk) 14:42, 12 August 2013 (UTC)
I think Bangkok/Rattanakosin#See shows a good example why there should be an option to remove the full stop. It reads badly now. Joachim changed the prose into bulleted lists, but I think then lively prose is dumbed down just to make it appear on the map, while I think the map should facilitate the content. Globe-trotter (talk) 14:53, 12 August 2013 (UTC)

I didn't mean to imply that I would go and change it immediately, as it certainly is a big issue to be discussed at Wikivoyage:Listings. I recognise we're having a bit of a feature creep, especially with regards to templates in general since it's tempting to leverage on their flexibility even as that flexibility brings added complexity. But it's not a problem to do with coordinates alone, since I remember earlier questions about including phone numbers and addresses in-line. I want to get the editor up and running before even starting a discussion though, unless someone else wants to start it earlier. -- torty3 (talk) 15:14, 12 August 2013 (UTC)

Having difficulty with the mapEdit

I am struggling to get map co-ordinates and icons working consistently.

  1. The address often shows at the wrong part of the street for the street number, but that might just be Cape Town.
  2. It is not clear which template I should select from the list.
  3. What does "click and mark text" mean? I click at the correct position, and a balloon appears, what next?
  4. I copy and paste the coordinates to the listing editor and save. when I view the map by clicking on the green rectangle, the map displays, but no icon to show the POI.
  5. When I triple click as instructed (not sure what I should triple click on), and copy paste the coordinates, sometimes I get an icon on the map, sometimes not, and there is no obvious pattern yet, except that I more often get it to work on the second try.
  6. I have no idea of what modifications should be made to the marked text.

This is a great feature, and I think it will be a great step forward in user friendliness once the instructions are clear, because I am sure that I am simply not understanding the instructions. • • • Peter (Southwood) (talk): 08:26, 14 August 2013 (UTC)

  1. For many places street numbers not yet in OSM. Then just the street is found.
  2. Lat|Long is for listings, Geo is for the {{geo| tag at the bottom of every article, Mapframe inserts a map in article text. All other templates are for other language versions.
  3. What next? Highlight the required text. Lat = 12.34567 | long = 89.78675 and copy it to the clipboard. For the listing editor you need to copy the values ​​individually. Therefore, they are again listed after "or ...".
  4. It depends on your browser's settings. Usually helps 'reload' map twice. Otherwise, browser shows you the old cache content.
  5. With a triple-click (3 x left mouse button), you can mark any text that is under the mouse pointer.
  6. Thus, only the red marked text is meant. It happens only in other language versions. For example: Template Poi.
Please help for better formulations in the dynamic maps. I know how bad my English. -- Joachim Mey2008 (talk) 14:16, 14 August 2013 (UTC)

Closed to RemoveEdit

I would say the "Closed?" option in the listing editor should be changed to "Remove?".--Saqib (talk) 08:39, 6 September 2013 (UTC)

In It:voy I've substitute it with the equivalent of "Delete?", because is an action that should occur after the confirmation. However, I think it would be more intuitive to use a button "Delete" instead of a checkbox+"Save button". And it would be a good idea to have a second confirmation pop up "Delete -name of listing-?" with two buttons "OK" "Cancel" --Andyrom75 (talk) 08:48, 6 September 2013 (UTC)
I've considered it but I don't like the idea. First reason is that it makes deletion of the listing equally prominent to editing the listing, when most of the time a user will only be changing the details (50-50 versus 90-10?). When the button is 'Delete', it puts people in the mindset of deleting the listing for kicks. Second reason is that the only time a listing should be unquestionably removed is if it's closed. If a user wants to remove it outright for another reason, a proper edit summary should be entered - just manually edit it, otherwise it's unclear why it's been removed. For this reason, I was going to change the auto edit summary to 'Closed listing for ...'. Thoughts? -- torty3 (talk) 09:58, 7 September 2013 (UTC)
Now I've understood why you have put "closed" :-) However, although from one side I agree with you that >95% of the time we add/modify listing instead of deleting, from the other side I'm not sure if the closing option is the only reason to delete one listing. The owner could have changed and the hotel/resturant has a quiality decreased so it's not anymore recommended. Although from one certain point of view you can add this in the description, from another POV ad a traveller, I'm not interested on reading what is bad to discard it, I want to know what is good to select it. At least that's how I use the Lonely Planet guide .... even if sometimes they fail their jugde.... as we'll fail for sure ;-)
Maybe a listing has been wrongly inserted (I've found a lot of city in the wrong country, so I wouldn't be surprised to find a listing in the wrong place :-)), so it's not properly correct to clasify as closed.
I would also remove listing from an article (e.g. city) to insert them into sub-article (e.g. district). Personally I would go for a cut&paste inside the wikitext because is definitely quicker, but maybe a newbie could elect this tool for this task. --Andyrom75 (talk) 07:19, 13 September 2013 (UTC)
Moving things to another article needs to be done manually as there needs to be some sort of trail for attribution (the BY in CC-BY-SA); these shouldn't be done with the listings editor as they usually involve multiple listings moved (with attribution) across multiple pages. Just plain "closed permanently" is a reasonable task for the listing editor, but "the Coral Court Motel in St. Louis was bulldozed in 1995" is more clear-cut than "Lac-Mégantic Marina is temporarily inaccessible for the entire 2013 season" or "the Tradewinds Motor Inn in Clinton (Oklahoma) lost its Best Western membership and received a string of negative reviews after long-time proprietor Walter 'Doc' Mason sold it in 2003; 'Doc' died in 2007 after a long battle with Alzheimer's". Of this lot:
  • The listing moved to a sub-article needs its origin identified for CC-BY attribution, so is manual.
  • The bulldozed motel can simply be marked 'closed 1993' and removed. Simple.
  • The temporary closure stays in the article, but we really need something like Wikipedia's {{as of}} to ensure the 'closed' status (and the warning box on the town itself) is removed once outdated.
  • The establishment which is still operating but no longer meets standards needs some sort of explanation as to why it was removed. That may require a note on the talk page or a link to reviews or news off-site.
Not all of these make a good task for the listings editor. K7L (talk) 15:48, 15 September 2013 (UTC)

Edit phone number on saveEdit

Would it be possible after user presses Submit (to save) that spaces are replaced with dashes on phone numbers? This would help with formatting of hyperlinks on mobile smart phones. --Traveler100 (talk) 19:10, 28 September 2013 (UTC)

Until we have sorted out our phone number formatting, this would not be a correct behaviour.
Hyphens/dashes are not just separators between numbers - in Wikivoyage articles they have a semantic significance too! --W. Frankemailtalk 21:35, 11 October 2013 (UTC)

Getting cursor back in price field after clicking currency symbolEdit

Would it be possible to get the cursor to come back to the price field automatically, after clicking the € or $ sign? Now, when I click the symbol and then want to type (the price), I'm away from the field and the editor as a whole, needing to scroll the page to find it back. This is not a big deal, but if it's trivial to fix it would be nice :-) Thanks! —The preceding comment was added by JuliasTravels (talkcontribs)

Surprisingly non-trivial, but will look further into it (at some point!). -- torty3 (talk) 01:45, 29 October 2013 (UTC)
While I have your attention, Torty3, please would you add the
₹ ₪ ₱ Kč
symbols as per the recommendations at Wikivoyage:$#Universally_known_currency_notation_exceptions (for Indian rupees, Israeli new shekels, Philippines pesos and Czech crowns).
(It might also be worthwhile adding the RM, Rp and Rs notations, but that's not so pressing). -- 02:06, 29 October 2013 (UTC)

CAPTCHA broken for IP'sEdit

I firmly believe that for a Wiki like this to grow vastly in readership and authority it needs to encourage casual editors that, perhaps at first and while they are feeling their way (not my case, I hasten to add as I've edited loads of other websites that use MediaWiki software), or wish to remain anonymous (perhaps not wishing to cross swords with the block-happy admins here or join in the thrilling and long-running is it Alice-Frank-Tony or Ypsilon soap or whose employers don't allow them to have a public profile, etc).

The listings editor is a great tool for this - if it actually worked for IP's.

Today I tried (and failed) more than 20 CAPTCHA challenges when trying to correct the spelling of a listing using the tiny, gray listing "edit" button. When I just use the section edit button, I succeed first time, every time... -- 20:26, 3 November 2013 (UTC) [3] Just want to +1 this. If you get the CAPTCHA right the first time then it works, but if you get it wrong, then it will always say you got it wrong afterwords.

User:SomeIrishPerson and anon, thank you for your bug report. It will be my highest priority but I currently do not have enough time to code and test. Would you recommend that the listing editor be disabled for anonymous users until I fix this? -- torty3 (talk) 23:37, 3 November 2013 (UTC) SomeIrishPerson (talk) 20:16, 3 November 2013 (UTC)

Well you only get one chance to get the CAPTCHA right. If you get it wrong then you lose all your edits. I've stopped using it myself, unless I was making only very minor changes. SomeIrishPerson (talk) 23:52, 3 November 2013 (UTC)
Torty3: I really appreciate your offer to try and fix it and you seem to be a very quick and active coder so I guess disablement may not be for a long period. The answer to your question is pretty finely balanced and depends partly on whether you could make the (quick?) fix to the currency symbols (requested in the section above) and your estimated duration of disablement. If the period before the anticipated fix is short, would it be possible to "dial back" the difficulty of the CAPTCHA challenge (or even remove it entirely) since we don't have too many vandals or spam artists utilising the listings editor right now?
SomeIrishPerson: I see that you've registered an account now. Are you saying that this CAPTCHA problem is not just limited to anon editors like me? (Since I've never risked registering an account at either Wikitravel or Wikivoyage, I've no way of testing that personally...) -- 11:14, 4 November 2013 (UTC)
The CAPTCHA applies to anonymous and maybe non-autoconfirmed users, and I will not be able to remove it because it is a security feature of WMF to add CAPTCHAs for those users who add external links, as you do in the normal editor? For the currencies, I need to check the formatting on different browsers so it's still a bit of work. I may leave it up for now, because at least some edits are getting through. For the record, WV edits per month for mainspace articles mostly equals those of WT, and sometimes even surpasses it, for all their SEO dominance. -- torty3 (talk) 13:09, 4 November 2013 (UTC)
A note to say that I just realised the addition of tel: links to phone numbers worsened the CAPTCHA problem, even if you only use the normal editor because they are considered external links. Unfortunately it doesn't seem like there's a way to except them. -- torty3 (talk) 05:13, 15 November 2013 (UTC)
CAPTCHA is done by an extension, mw:Extension:ConfirmEdit. Would it be worth reporting the CAPTCHA on numeric tel: links as a bug in that extension on Bugzilla? K7L (talk) 17:35, 15 November 2013 (UTC)
Worth a try? There's a whitelist, but unsurprisingly it's hard coded to HTTP/HTTPS protocols. -- torty3 (talk) 09:36, 17 November 2013 (UTC)
Luckily someone had also reported it at, so there was a bit of a headstart in fixing it. Should be merged in next week. Can't figure why my own code isn't working though. -- torty3 (talk) 07:17, 27 November 2013 (UTC)
I hope it isn't too infuriating. What are the chances of adding the
₹ ₪ ₱ Kč
symbols as per the recommendations at Wikivoyage:$#Universally_known_currency_notation_exceptions (for Indian rupees, Israeli new shekels, Philippines pesos and Czech crowns), please?
(It might also be worthwhile adding the RM, Rp and Rs notations, but that's not so pressing). --118.93nzp (talk) 07:44, 27 November 2013 (UTC)
Patch for whitelisting protocols will come into effect on 17 Dec, so any admin could add tel: <noprotocol> to the MediaWiki:Captcha-addurl-whitelist. Regarding currencies, it's just very low down on the list, there are still outstanding bugs on other Wikivoyages that I also have not the time to get to. -- torty3 (talk) 17:58, 11 December 2013 (UTC)
Regarding currency symbols: in your own good time and thanks for considering the request - it's just that I thought it would be a relatively quick thing to do while helping to reduce the amount of copy editing that has to be done. The other thing that leaps to mind would be introducing 24h time format examples, since the AM/PM format is going to be inappropriate for most of the world. --118.93nzp (talk) 00:17, 12 December 2013 (UTC)

The above bug still exists: "If you get the CAPTCHA right the first time then it works, but if you get it wrong, then it will always say you got it wrong afterwords." It would be great if that could be fixed. 23:53, 26 July 2015 (UTC)

Add Listing strangenessEdit

Apparently, for whatever reason, when adding a new Eat listing, using the Add Listing widget, instead of manually adding from Edit mode for the section - Any Pricerange listed in dollar signs will come out as $$, regardless of the number of them used. L. Challenger (talk) 21:53, 16 November 2013 (UTC)

Well, its working fine for me at-least. --Saqib (talk) 21:58, 16 November 2013 (UTC)
Confirmed. Yay more bugs. Copying over to Wikivoyage_talk:Listing editor. -- torty3 (talk) 10:20, 17 November 2013 (UTC)

The need for Edit ConflictEdit

Swept in from the pub

That Subject/headline probably got some attention, but please know that I am referring to the technical problem where several editors try to edit the same page at once, leading to a conflict the software cannot resolve automatically, as defined by w:Help:Edit conflict in Wikipedia. I am not referring to editing disagreements between editors, as defined in Wikivoyage:Edit war.

I guess this is a known issue, as I found it listed under Wikivoyage:Listing editor#Caching and conflicts. I encountered it yesterday on the Template talk:Okina, when some editors (myself included) inadvertently overwrote other editors' input. My two concerns are that fellow editors may see this as intentionally deleting their work when it is really a problem with the configuration of the MediaWiki implementation. Please see Wikivoyage:Technical details & w:MediaWiki for more on MediaWiki.

I would like to see the capability for detecting, preventing, & warning about simultaneous edit conflicts implemented in Wikivoyage as it is in en.Wikipedia & other Wikimedia projects. I am hoping that the Traveller's Pub is the appropriate place for this discussion. If it is not, perhaps an administrator or experienced Wikivoyager can move this to a more appropriate forum & using a Template:Cautionbox to note the location to which s/he has transferred the discussion.

Aloha, Peaceray (talk) 20:40, 9 November 2013 (UTC)

Functionality for detecting edit conflicts and either attempting to reconcile them or of warning the user and asking the user to manually reconcile the differences is a core piece of the Mediawiki software and is enabled on all Mediawiki wikis, including Wikivoyage. There have been a few reports lately of edits being overwritten without an edit conflict notification, which may be a bug in the latest configuration of the software used here (WMF pushes out updates on a regular basis). If the problem occurs repeatedly then a bug report should be made via Bugzilla, but my guess is that if there is a problem in the latest version of the software that the Mediawiki developers are probably already aware of it and working on a fix. -- Ryan • (talk) • 20:49, 9 November 2013 (UTC)
Is there a Wikivoyage page that lists which version of MediaWiki we are using? I was over at & searched for "lock" & "conflict", but did not discover anything obviously related to this problem. Peaceray (talk) 21:22, 9 November 2013 (UTC)
I think I just found the MediaWiki ver. # that Wikivoyage uses at WikiStats by S23 - List of largest (Media)wikis. I looks like as of 2013-11-09 14:04:43 Wikivoyage is using version # 1.13.1. Peaceray (talk) 21:29, 9 November 2013 (UTC)
That list is pretty outdated actually. Version is 1.23wmf2, see Special:Version. Wikivoyage is usually one version ahead of Wikipedia and one version behind -- torty3 (talk) 00:13, 10 November 2013 (UTC)
Mahalo, torty3! I am also noticing a different behavior in my Wikivoyage watchlist compared to my watchlists else where. Elsewhere, my watchlists put multiple edits for a page for each day into a collapsed listing, & puts the list of editors on a single line until one expands the list. Currently on my Wikivoyage watchlist, I only see the most recent edit. Peaceray (talk) 00:59, 10 November 2013 (UTC)
A feature I have wanted for some time and never got round to asking for is finer granularity. Suppose I am editing #Get in and meanwhile someone else adds a listing in #Sleep. Ideally, the software should recognise that we are changing different sections and accept my edit without a conflict notice & of course leave the other user's change intact as well. I think that if this could be implemented, it would avoid a significant fraction of all conflict notices.
I know it is possible; some source code management systems work at function level rather than whole file. However, I suspect implementing it might be tricky. Pashley (talk) 21:01, 9 November 2013 (UTC)
This does work in some code management systems, albeit with an additional 'conflict resolution' tool that shows the differences. It would be great to have something like this, although Pashley is very correct to say it is really tricky to implement.
I can't say that I find edit conflicts a big problem. I often just type what I need in NotePad.exe, edit the WV section and save within a few seconds. Andrewssi2 (talk) 01:12, 10 November 2013 (UTC)
Simultaneous editing has been allowed in Wikimedia projects for some time. Only if the engine can't resolve the edits is an edit conflict generated. If they're to two different sections entirely, then there should be no edit conflict at all. LtPowers (talk) 18:37, 10 November 2013 (UTC)
Yes, this was changed recently, I believe. I know the WMF wants to allow simultaneous live editing, but of course that requires people to adopt VisualEditor... which hasn't been going so well. --Rschen7754 00:47, 11 November 2013 (UTC)


Hello, I fixed knowns issues at fa.voy:

  • "Listings with the same name"
  • "When a name contains (but not starts with) some italic text, the listing windows doesn't appear (because of a JS error)"

Here is how to fix it: Add a specific class to all listing items (vcards) and add all possible templates and redirects for listing items (var listingTypesRegex) and make it index based not regex based to find the template in a section. Mjbmr (talk) 03:15, 7 March 2015 (UTC)

Mjbmr, here where? Could you link (or write here) the exact fixing code? --Andyrom75 (talk) 09:30, 14 March 2015 (UTC)
@Andyrom75: fa.voy I said, here. I have listed all listing templates in a variable called listingTypesRegex and check out function getListingWikitextBraces. Mjbmr (talk) 12:24, 14 March 2015 (UTC)
Mjbmr, I was asking if you can link/write only the modified code, to speed up its recognition. --Andyrom75 (talk) 15:16, 14 March 2015 (UTC)
@Andyrom75: no I cannot, I made a lot of modification on the original code, but I'm sure you can develop your forked code using js console. Mjbmr (talk) 17:36, 14 March 2015 (UTC)
Mjbmr thanks anyway. --Andyrom75 (talk) 08:41, 15 March 2015 (UTC)


@Mjbmr: thank you for the fixes - I've applied them to our listing editor in Special:Diff/2750058/2750076. Since the listing types are the same patterns we would use in the regex I didn't create a listingTypesRegex variable, but instead just built the regex using the listing types directly. Seems to work, thanks! -- Ryan • (talk) • 03:18, 19 March 2015 (UTC)

@Wrh2: Glad to hear that, thank you. Actually the idea of using listingTypesRegex was because there are redirect templates like in de.voy {{vCard}} and {{listing}} are same and I had to list those kind of redirects in listingTypesRegex. And creating new redirects for listing templates will make listing gadget not detecting them so I made a filter for that at fa:Special:AbuseFilter/20 to avoid creating new redirects for them. Mjbmr (talk) 21:44, 22 March 2015 (UTC)

Error adding listingEdit

Swept in from the pub

I just spent a good amount of time entering all the information to add a sleep listing and when I clicked Submit I got:

Error: API returned error code "badtoken": Invalid token

and all the information I entered was lost. Gee, thanks. What's the deal? I try and help the site and this is how I'm rewarded? At the very least, if the listing is not accepted, it should leave you in the listing editor so everything is not lost. —The preceding comment was added by TokyoJimu (talkcontribs) 05:09, 24 March 2014‎ (UTC)

@Unknown user **: This error occurs when URL could not be detected correctly [4]. What article do you want to edit? -- Joachim Mey2008 (talk) 07:13, 24 March 2014 (UTC) ** Please sign your post by appending four tildes (~~~~)
This has also happened to me a number of times. Usually when taking too much time, there is a timeout. So if you go for coffee while editing a listing, better save it, even if it is incomplete, and then click "edit" again. Not losing input would be a nice enhancement indeed. Nicolas1981 (talk) 07:37, 24 March 2014 (UTC)
Having worked on other wikis, timeouts were an issue and the above suggestion to save is great... My motto was "Save and Save Often". In addition, I have often written small data input GUI programs for Windows to gather basic information and write output files to my desktop (I think something external for starting various listings could be accomplished fairly easily) ... simple copy and paste to a Wiki article page and complete editorial work later. I also run MediaWiki on my desktop and use that for basic page creation as well - again copy and paste - edit later. It was also not uncommon to actually dump a wiki and rebuild it onto a USB stick and work from that... (This would entail quite a bit of work to accomplish something like that with Wikivoyage)... Matroc (talk) 15:53, 24 March 2014 (UTC) Cheers!
@Syced: I've been working on a 2.0 version of the listing editor that uses the mv.Api().postWithToken() function, and thus should not generate the error you've described. Additionally, if there is an error the new version should re-display the listing editor dialog so that you don't lose any work. If you (or anyone else) are interested in trying out the new listing editor and potentially confirming whether the token expiration bug is fixed I'd be grateful. To enable the new listing editor go to "Preferences" → "Gadgets" and then un-select the existing "ListingEditor" in the "General" section (required - both old & new listing editors cannot be active at the same time) and then select "ListingEditor2 (beta)" from the "Experimental" section. Other changes in the new version are called out at Wikivoyage:Listing editor#Changelog. I'm still testing this new version out and will be making additional changes to the code (mainly to make it easier for the new script to be used in other languages), but the new version should be reasonably stable. -- Ryan • (talk) • 18:30, 8 July 2015 (UTC)

Error with {{marker}} templatesEdit

When there is a {{marker}} template in the content of a {{listing}} template, then the content is not fully shown in the textarea of the listings editor:

  • Example. Content not fully shown after this Marker. This text is not shown in the listings editor.

A real example can be found here: Edinburgh/Old_Town#See "Greyfriars Kirkyard". Could anyone please have a look into that? 00:06, 27 July 2015 (UTC)

Please see Wikivoyage:Listing editor#Bugs and feedback for the list of known issues with the listing editor. The problem with pipes and equal signs within listing fields is not an easy one to fix. -- Ryan • (talk) • 00:10, 27 July 2015 (UTC)

Listing edit links bugEdit

Swept in from the pub

When I go to Okinawa_Island#See each listing ends with "edit | edit". Two edit links instead of just one. At the first listing, the second link edits the listing below. At the second listing, the edit links edit listings 3 and 4, etc. Syced (talk) 13:51, 31 August 2015 (UTC)

I only see one. Can anyone else reproduce this? WhatamIdoing (talk) 21:45, 6 September 2015 (UTC)

How does one avoid having the [Add listing] link added to articles that aren't about destinations?Edit

Swept in from the pub

As of now the [add listing] link is added to all of the Hebvoy articles, including Phrasebook articles, and Travel topics articles.

Is there any trick to disabling the appearance of this link on certain articles? ויקיג'אנקי (talk) 17:48, 21 September 2015 (UTC)

he:מדיה ויקי:Gadget-ListingEditor.js has been deleted so I'm not sure what your listing editor code is doing, but in MediaWiki:Gadget-ListingEditor.js if the DISALLOW_ADD_LISTING_IF_PRESENT pattern matches a heading in the article then no "add listing" links are added to any headers. That prevents display on region, travel topic and itinerary articles. -- Ryan • (talk) • 18:28, 21 September 2015 (UTC)

URL prefix handlingEdit

To clarify a discussion with the programmers, on my talk page, I think the Listing Editor handles URL prefixes almost perfectly: if "http://" is present in the template, that is stripped off of the URL string that is displayed to the user, and it's added back when saving to the template; and if "https://" is present, it is displayed and saved. All of my problems with URL processing are with the Listing template (as described in its talk page), not an issue with the listing editor. There is one small Listing Editor bug, which doesn't really matter now but will become annoying if the template is fixed: what happens when the user attempts to blank the URL field by typing a single space. An example can be seen in the first bulleted item in this version of my Sandbox. Peter Chastain (talk) 00:44, 29 December 2015 (UTC)

The first two examples in your sandbox are not well formatted, that's why the output is wrong. IMHO all the URL must be inserted in the complete format, so to best thing we can do is to add an URL format checker to avoid the other cases. --Andyrom75 (talk) 10:48, 12 January 2016 (UTC)

Feature request: Preview buttonEdit

I wish there were a Preview button in the listing editor, allowing the user to see what the listing will look like. It is true that mistakes noticed after clicking Submit can be easily corrected, but it is also true that the user could for some reason become distracted and not fix the problem. We should regard Submit as a commitment, IMO, and not as the easiest way to do edit testing. And while it may be true (I don't know) that a large string of minor changes is computationally inexpensive, I find looking at them in a history display to be slightly annoying and time-consuming. Thanks. Peter Chastain (talk) 00:40, 29 December 2015 (UTC)

Feature request: punctuationEdit

OK, this is very low-priority, but it is probably an easy fix... For proper punctuation, the user needs to put a period at the end of the text in some fields but should not do so in others. For example, in this revision of a page, in the Lake County Museum listing under "See", I terminated the Hours field with a period, and the listing editor added another. On the other hand, a period will appear after the Content field only if the user puts one there. It would be nice if the listing editor could always make sure that each field ends with exactly one terminating punctuation mark. Peter Chastain (talk) 02:17, 31 December 2015 (UTC)

I agree, this should be easy and useful. --Andyrom75 (talk) 10:49, 12 January 2016 (UTC)

Feature request: telephone number parsingEdit

Here is another low-priority wish, but I'll toss it out, anyway... Can the listing editor put phone numbers into a standard format (e.g., +1 (555) 555-5555 for the USA)? Currently, we take whatever the user types, e.g., 555-555-5555, 555.555.5555, etc. I realize this could be very tricky, with the listing editor needing to be aware of which country the phone number is for, and with the possibility of extensions. Peter Chastain (talk) 02:26, 31 December 2015 (UTC)

I'm not sure how to implement this functionality given that massive variations in phone numbers around the world. Perhaps if the existing request to do a country lookup to determine currency was implemented we could also automatically populate telephone country code, but I'm not confident the change would be doable. Perhaps others can comment with ideas or suggestions - I think User:Matroc has done a lot of work with automated phone number parsing and might have ideas. -- Ryan • (talk) • 03:00, 31 December 2015 (UTC)

Feature request: Enforce edit-summary limitsEdit

The standard editor (and, I would guess, the MediaWiki database structure) has a 255-character limit for edit summaries. If I try to enter a summary longer than that, the edit-summary text field stops accepting input. The corresponding field in the listing editor lets me keep typing, and then truncates my input, so that the total length of the edit summary, including the "→‎Listing: Updated listing for xxxx - " that the listing editor inserts, seems to be about 225 (not 255) characters. (See this edit for an example.) It would be nice if the listing editor's edit-summary window would work like the standard editor, not allowing me to type too many characters. Actually, I see a potential problem with that, since the user could also be increasing the size of the Name field, which is included in the edit summary. Anyway, if you could at least allow the entire edit summary to use all 255 characters, that would be helpful to those of us who sometimes like to provide a detailed explanation of what we're doing. Thanks. Peter Chastain (talk) 23:11, 16 January 2016 (UTC)

Bug report archiveEdit

Moved from Wikivoyage:Listing editor#Bugs and feedback

  • Price range bug Adding $$$$$ signs to the price returns dollar signs in multiples of twos.
    Does this bug still exist? I don't think I've ever encountered it. -- Ryan • (talk) • 05:27, 29 October 2015 (UTC)
  • Template contents are mangled with small or null edit This change occurred when I used the listing editor to make a small change at the end of the content field. This change occurred when I invoked the listing editor, made no changes, left the edit summary blank, and clicked Submit. This happens with either Chrome or Internet Explorer.
Per communication from Ryan, this is probably a duplicate of "Equal signs in listing values", above. Peter Chastain (talk) 13:36, 16 January 2016 (UTC)
It is very, very rare that a listing on English Wikivoyage contains the syntax that triggers this bug, and so far I haven't come up with a good way to fix it. However, since it's a serious problem when it does occur since it mangles the existing content, it's probably something that needs to be bumped up the priority list... -- Ryan • (talk) • 19:39, 16 January 2016 (UTC)
This highlights one of the reasons I would like to see a Preview button: if I can see there's a problem, I probably won't save it. But yes, especially for less experienced editors, this would still be frustrating. Peter Chastain (talk) 20:23, 16 January 2016 (UTC)
This issue is also due to the "Equal signs in listing values" bug, so archiving it as a duplicate. -- Ryan • (talk) • 12:17, 29 January 2016 (UTC)

Deleting a listing results in a 'Closed' commentEdit

A user recently removed a listing using the editor because they believed it was not worth listing a chain store. : LINK here

This action will prefix the words "Closed listing for" in the related change comment.

Can we change the Change Comment to say "Listing deleted", since it may not always be because of business closure reasons. --Andrewssi2 (talk) 01:19, 22 February 2016 (UTC)

  Done: Special:Diff/2935500/2945102. -- Ryan • (talk) • 02:58, 22 February 2016 (UTC)
Thanks! --Andrewssi2 (talk) 09:24, 22 February 2016 (UTC)
If someone's deleting listings, wouldn't we want the edit comment to explain why? A business closure is somewhat straightforward, a venue that has let standards slip to the point where the rooms are bug-infested and the food is greasy is less so. K7L (talk) 16:03, 22 February 2016 (UTC)
We don't delete businesses just because one person has a bad experience. In any case the comment is visible, and typically we would restore a business deletion where no comment was given. --Andrewssi2 (talk) 19:31, 22 February 2016 (UTC)

adding an image for a listingEdit

Swept in from the pub

I click on "add listing" for a place or restaurant or whatever and a box , "edit existing business" with a bunch of fields to fill in shows up:
Name Type
Alt Email
Website Latitude

If I want to add an image that will show up when I click on icon on map, I have to type


in the "content" box after a description of the place, and it sometimes works and it sometimes doesn't. Sometimes it works for me and not for others so they revert the edit.

If it does work, then a field in the "edit existing business" box called "Image" shows up.

Why is this so complicated? Why can't the field "Image" just be there from the start, and work every time? I've been editing wikipedia and uploading images to commons for 6 years. I'm not some useless newbie. Please fix the #### software. Roseohioresident (talk) 21:56, 5 February 2016 (UTC)

I was unaware that we had enabled pictures for listings... For several reasons (offline usability being one of them) there is such a thing as too many pictures here on WV. As to the technical details... I don't know. The problem does sound bizarre and is surely not what was intended... Hobbitschuster (talk) 22:07, 5 February 2016 (UTC)
The problem of "too many images" doesn't really apply, because the image only shows up if you click on the icon on the map. Roseohioresident (talk) 22:21, 5 February 2016 (UTC)
Ah. I see. Hobbitschuster (talk) 22:24, 5 February 2016 (UTC)
Go to Magnolia_(Ohio) and click on one of the restaurants to bring up the map, then click on one of the icons on the map and you will see how the feature is supposed to work. It works for restaurant #1, but not #2 on the map, but the coding is identical as far as I can tell. Roseohioresident (talk) 22:29, 5 February 2016 (UTC)
That's strange. Hobbitschuster (talk) 22:36, 5 February 2016 (UTC)
I've fixed the listing template syntax in the Magnolia (Ohio) article, and the images now appear on the map as expected. -- Ryan • (talk) • 22:46, 5 February 2016 (UTC)
Thanks. It seems "image" is case sensitive, (who knew?), still seems way too complicated Roseohioresident (talk) 22:58, 5 February 2016 (UTC)
(edit conflict) Populating the "image" param for listings for new images via the listing editor isn't supported because the ability to add listing images was added after the listing editor was created, and no one ever asked for the feature to be added. If you can add a note to WV:Listing editor#Bugs and feedback then I'll try to get something in place when I have time to work on the listing editor again. -- Ryan • (talk) • 22:11, 5 February 2016 (UTC)
That's just weird, because the field shows up in the listing editor box, after the above procedure works for the first time. Roseohioresident (talk) 22:46, 5 February 2016 (UTC)
The editor doesn't display fields that aren't in common usage by default, unless they have a value, so fields like "fax" and "image" are only displayed if there is a value. The reasoning is that there was concern about the box being too large, particularly for small screens. It shouldn't be hard to add something like "show additional fields" or something like that so that those fields can be added when desired, but still hidden in the default view. -- Ryan • (talk) • 22:51, 5 February 2016 (UTC)
"The editor doesn't display fields that aren't in common usage by default", is kind of a self-fulfilling. If you have to add parameters manually, stumble on the syntax somewhere, (where?), and get it correct, those won't be common usage. It seems we live in a visual age. Pictures and thousands of words and so on. If this site wants to be relevant, it has to be easier to use and visual. I think adding images for a place that pop up on a map should be default. I hope this paragraph does not sound harsh, it is meant to be constructive.Roseohioresident (talk) 23:37, 5 February 2016 (UTC)
You might want to suggest new default fields at Wikivoyage talk:Listings, so that there's a better record of the discussions. Actually, this discussion might well be swept there, eventually. Ikan Kekek (talk) 23:40, 5 February 2016 (UTC)
The issue is with the listing editor, not the listing template. A request for an update was already made at WV:Listing editor#Bugs and feedback. -- Ryan • (talk) • 00:28, 6 February 2016 (UTC)
Sound like a good idea. More fundamentally, I think the maps feature could be a lot more like google maps. There, you click on the icon of a place, (which has a name and not just a number), and it brings up an infobox about the place, including editable information, add a review, a picture (street view or other), and an "add an image" button. All on a 2 by 3 inch screen of a $40 android phone. Two thoughts: 1) listing the name of a place on a map instead of a number seems straight forward. Something about "pointers", if i correctly remember programming. 2) A link-back to the listing editor, or to the listing, for a place icon would be a straight forward way to add a lot of utility to the map. Roseohioresident (talk) 01:01, 6 February 2016 (UTC)
This is excellent feedback, though I fear it's actually considerably more complicated than it sounds. =) Powers (talk) 01:53, 6 February 2016 (UTC)
Actually, all the information is already there. To generate the map each colored circle with a number inside already has these parameters associated with it:
{{city name}}, {{listing name}}, {{type}}, {{latitude}}, {{longitude}} and {{image}}.
When you click on the number, a little thumbnail with photo and listing name comes up. I haven't looked at the source code, (I wouldn't know where to look for it), but it seems it would have a snippet of code something like:

[[image:{{image}}|thumb|50px|{{listing name}}]]

to have it link back to the listing would involve this code:

[[image:{{image}}|thumb|50px|[[{{city name}}#{{type}}|{{listing name}}]]]]

The appearance would be the same, but if you click on the listing name, it sends you back to the section of the article that has the listing for that place. For big places that have lots of listings for each type, there must be a way to point to the actual listing. Of course, I could be all wrong. Roseohioresident (talk) 17:56, 6 February 2016 (UTC)
The link-back would probably not be a huge problem, as you note. I was more concerned with adding icon labels to the dynamic maps. The code currently accounts for POIs that are very close together by combining them into a '+' icon. With labels we'd have to create some sort of collision detection code to avoid overlapping text... and even then we'd have to decide how to handle potentially overlapping text. Google Maps handles it by simply omitting some of the icon labels; I don't think that's a practical or acceptable route for us. Powers (talk) 19:45, 6 February 2016 (UTC)
On one day's reflection, icon labels on the map are not a big deal, since when you place the cursor over the number, the listing name shows up, and when you click on the label, the above actions occur. I concur it is not worth the programming hassle, or loss of functionality.
Getting back to the heading for this section, I think whatever changes to Template:Listing or the listing editor to make the parameter (image=) a default field are crucial. If I click on an icon on a map, and no photo appears, I feel something between pity and anger for the developers.
On a related note why does the documentation, (and the source code), for Template:Listing and it's offspring Template:Eat not even mention the parameter |image= ? I thought I understood how Templates work. I am really stumped how I managed to add that parameter manually. More weirdness. Roseohioresident (talk) 20:50, 6 February 2016 (UTC)
My guess is that "image=" is a recent addition (last year or two) and so rarely used around here that no one's bothered putting much effort into documenting it. Often, we're glad just to have a {{mapframe}} and a {{pagebanner}} at all on many destinations. K7L (talk) 22:34, 6 February 2016 (UTC)
Comment - I believe it was discussed in Oct of 2014 to add the image parameter to the listing editor... Template Marker is only template that mentions that image is optional though it works in other templates and does not seem to be mentioned... When I add images to various listings, I edit listings by editing the entire section rather than try to use the listing editor individually to do so and have added hundreds to various India associated articles... The image parameter came into being sometime after the listing editor was up and running... Matroc (talk) 22:58, 6 February 2016 (UTC)
This conversation seems to meander a little, so, in that vein, most photos on commons seem to have geo-coordinates associated with them. If a photo were linked to image=, could not the latitude and longitude be extracted from the Metadata of a photo, and entered in the lat= and long= parameters if they are blank? Kills two birds with one stone, and removes a lot of the grunt work of creating a listing. Roseohioresident (talk) 23:39, 6 February 2016 (UTC)
Most of those metadata coordinates represent the location of the camera, not the photograph's subject. Powers (talk) 01:30, 9 February 2016 (UTC)

counter parameterEdit

Using the listing editor removed the parameter counter used to allow the new mapping method used by mapframe to work similar to the original one used by geo. Can someone update the code to at least keep the counter parameter the same, better still add field to UI. --Traveler100 (talk) 08:14, 16 July 2016 (UTC)

The listing editor will only remove unrecognized fields that do not have a value. Thus "counter=" would be removed, but "counter=3" would be retained. -- Ryan • (talk) • 08:16, 16 July 2016 (UTC)
I was advised that "counter=" was a valid input. Guess I could change the pages so they have a value. The new mapframe is poorly documented. Is there a way to do a mass replace on an article, i.e. change "counter=" to "counter=r" over 100 times on a page. --Traveler100 (talk) 08:19, 16 July 2016 (UTC)

Integration of WikidataEdit

Please have a look at phab:T141345 and Template:Listing/test. We have now a module which can load data for listings from Wikidata. It would be great if this tool would be able to edit Wikidata directly in a way that users without any technical background are able to do it. What is the current stage of development? -- T.seppelt (talk) 06:11, 28 July 2016 (UTC)

Wikidata lookupEdit

I see that entering a Wikidata item number will get (lat, long), Wikipedia and URL - but what about going the other way? Why can't a Wikipedia article name be used to get the Wikidata item number? If the soon-to-be-closed w:Trump Taj Mahal in Atlantis is d:Q3541146, then shouldn't it be possible to use the Wikipedia page name to get the Wikidata Q-number, then use the Wikidata entry to get at (39.3587, -74.4198)? K7L (talk) 17:23, 4 August 2016 (UTC)

Example tollfree numberEdit

Just wondering if the example tollfree number could be changed from +1 800 100 1000 to +1-800-100-1000 so that it matches the format mentioned at Wikivoyage:Phone numbers. -- WOSlinker (talk) 06:31, 13 August 2016 (UTC)

  Done -- Ryan • (talk) • 06:56, 13 August 2016 (UTC)

Unable to open Listing editor when template was added using Visual editorEdit

In order to replicate the issue: open Visual editor, select Insert->Template, select Do template, press "Add template", enter dummy values including name, url, email, address and description. Save. Try to open Listing Editor for this listing. You'll get the following JS error "TypeError: null is not an object (evaluating 'regexResult.index')". Test case can be found here.--Kiaora (talk) 11:19, 13 August 2016 (UTC)

Thanks for the bug report. That appears to be a longstanding issue, not one introduced by last night's changes, but it should be fixed by this change. Please let me know if you still encounter any problems. -- Ryan • (talk) • 17:03, 13 August 2016 (UTC)
Cool, thanks, it works now! --Kiaora (talk) 04:20, 15 August 2016 (UTC)

Adding latitude / longitude improvementsEdit

When adding coords, sometimes I'm copying them from Wikipedia and it would be nice if when I paste in something such as 52.4242°N, it would automatically remove the °N when saving the changes. Also, if pasting 2.643°W or 52.4242°S then as well as removing the °W or °S, it could also add a minus sign to the start of the number.

As an added bonus, if it would be possible to handle coords such in the format such as 34°45′11″S 149°42′57″E and convert them into a decimal number then it would be fantastic. -- WOSlinker (talk) 12:22, 13 August 2016 (UTC)

Two suggestions how do to this now. 1) from the Wikipedia page click on wikidata, copy paste the code number into the listing editor then press "Update shared fields using values from Wikidata". 2) click on the coordinates on the Wikipedia page to get the GeoHack page then copy paste the decimal format from there. --Traveler100 (talk) 13:44, 13 August 2016 (UTC)

Updated listing editor with Wikidata & Wikipedia supportEdit

Swept in from the pub
Newly updated listing editor.
The old listing editor.

Per Wikivoyage talk:External links#Implementation_2, listings now have support for linking to Wikidata and Wikipedia, and I've just pushed a large update to the listing editor to support these new fields. Changes from the previous version of the listing editor include:

  • Wikidata & Wikipedia fields have been added to the listing editor.
  • The Wikidata, image, and Wikipedia fields will now autocomplete as you type, with lookups done by searching the relevant site. So if you start typing "Eiff" in the Wikipedia field you will get suggestions based on Wikipedia article titles that will include "Eiffel Tower".
  • Latitude, longitude, official link, wikipedia link, and image can be populated with the values stored at Wikidata by clicking on the "Update shared fields using values from Wikidata" link.
  • The "image" field was previously hidden in the listing editor if there was no pre-existing "image" value; now it is always shown.
  • Several cleanups to the underlying code have also been made.

Several people have been using the beta version of the listing editor successfully, but it's now live for everyone so please report any bugs. Feature requests can be added to this thread or left at Wikivoyage:Listing editor#Feature requests. -- Ryan • (talk) • 04:57, 13 August 2016 (UTC)

Thank you for your effort. I know that I didn't participate in the discussions which directly led to these changed but nevertheless I'd like to point out that the "Update shared fields using values from Wikidata" function is in my eyes a step in the wrong direction. Instead of copying data from Wikidata and storing it hard-coded in our articles we should transclude it dynamically using plain templates and lua modules. The aim is to maintain data centrally in cooperation with all sister projects and not to create local clones. Instead of "Update shared fields using values from Wikidata" we need "Update shared fields on Wikidata".
Secondly, many more fields (address, url, phone numbers etc.) are available on Wikidata. Please have a look at Wikidata:Wikivoyage/Resources#Properties_for_listings. Again, thank you very much for working on this. I really appreciate this advancement. -- T.seppelt (talk) 07:00, 13 August 2016 (UTC)
While I would agree that it would be better to use data directly from Wikidata and only support overrides when needed, Wikidata has performance and other limitations when retrieving arbitrary Wikidata items - see the comments from User:Matroc at Wikivoyage talk:External links#Implementation_2 when this was discussed previously. I would assume that current limitations will be addressed as Wikidata matures, but in its current state I think copied data is the only solution that will be viable. Update - phab:T93885 seems to indicate that we would encounter limits at 250 arbitrary accesses ({{#property:P856|from=Q3699364}}), plus the performance overhead of parsing each record, although anyone more familiar with Wikidata could hopefully provide further insight. -- Ryan • (talk) • 07:19, 13 August 2016 (UTC)
Have tested the editor! - fits in nicely with some of the things that I have been doing lately - Cheers! -- Matroc (talk) 07:35, 13 August 2016 (UTC)
Just a quick note: In some cases it is best to double check the Wikidata ID, name, latitude and longitude when updating listings etc. In several cases, when I did a lookup by name in Wikidata for example; there was no match available (the name in Wikidata, Wikipedia and Wikivoyage listings were totally different). Looking up a few items I found 2 airports in India with a latitude and longitude which placed them in the United States. In other cases; the Wikidata ID was incorrect or Wikidata entry was not found. I have on occasion edited Wikidata entries to rectify a few of these situations. Image availability in Wikidata is hit or miss. Overall, the editor is very useful and I appreciate the amount of work that went into it as it has saved me some definite listing editorial time.
I also had taken an extra step by querying Wikidata for IDs pertaining to India and instance of field (and Wikipedia) in order to produce various lists of Wikidata IDs in order to create reference tables or Wikivoyage style listings or <mapframes> for mapping groups (all this provided some useful information as to possible future listing candidates for various articles, lookups and data checks such as the example found in Mosques etc. - even these queries produced some false positives. -- The editor works fine and again, Thanks! -- Matroc (talk) 03:21, 23 August 2016 (UTC)
Ryan: Wonderful!!! This implementation with "Update shared fields using values from Wikidata" is the most pragmatic thing we can do right now, and it is well executed. When we switch to reading from Wikidata in real-time, we can first run a script that replaces all values that are identical to their Wikidata counterpart with the appropriate expression, so it's not like we are losing much information.
In one week, the number of Wikidata fields on the English Wikivoyage has jumped from 67 to 592!
That number may be incorrect if you are counting listings from other than Main Page (ns:0) articles - I know I have a few hundred on my User and Talk pages -- Matroc (talk) 04:01, 24 August 2016 (UTC)
That number is correct, I count only mainspace articles. Syced (talk) 04:23, 24 August 2016 (UTC)
Then we are making progress :) -- Matroc (talk) 05:20, 24 August 2016 (UTC)
Problem report 1: Try looking for Beijing's "Guanghua Temple". Two "Guanghua Temple" appears and it is very difficult to tell which one is the right one. How about showing the English Wikipedia article's name instead? That way there will be no duplicate names.
Not all Wikidata entries have enwikivoyage counterparts ... Updating shared fields will show in pop up box the related Wikipedia title - click on Cancel button if it is incorrect and start looking around for the correct Wikidata ID -- Matroc (talk) 04:01, 24 August 2016 (UTC)
I found 3, one of which is a disambiguation entry - Guanghua Temple (Putian) - Q1552743 -- Guanghua Temple (Beijing) - Q379381 -- In the case of duplicate Wikidata labels (Guanghua Temple) go to Wikipedia and get the Wikidata ID from there and enter the Wikidata ID directly in the listing editor - Entering a name is a convenient way to get a Wikidata ID; however, you can use the Wikidata ID directly -- There are plenty of duplicate labels - just have to double check -- Matroc (talk) 04:01, 24 August 2016 (UTC)
Our ultimate goal is to hide Wikidata. Hence this report :-) Syced (talk) 04:23, 24 August 2016 (UTC)
I am in agreement and it is good to raise these issues -- Matroc (talk) 05:20, 24 August 2016 (UTC)
Problem report 2: Nothing is found for "Guo Moruo Residence", presumably because the Wikidata item has a different page from the Wikipedia page.
Wikipedia Home of Guomoruo redirects to Wikipedia Guo Moruo Residence - Wikidata ID Q4165193 (Home of Guomoruo)-- Matroc (talk) 04:01, 24 August 2016 (UTC)
A casual editor might not be able to find that. It could be done automatically, which would be a further improvement. Syced (talk) 04:23, 24 August 2016 (UTC)
Yes; however, when a problem arises some help or guidelines should probably be developed to assist them -- Matroc (talk) 05:20, 24 August 2016 (UTC)
Enhancement suggestion: In Yokohama there is a building called "Landmark Tower", so in its Wikidata box I entered "Landmark Tower", and clicked the single item that appeared. This item had no description, just "Landmark Tower" (many Wikidata items still lack metadata). Only when I checked further did I notice that it is actually another Landmark Tower in the USA. The risk of mistaken item is very real, especially for POIs that do not have a Wikidata item. Many users will be tricked. To solve that problem, I suggest this: Get the latitude/longitude of each proposition, and only show the proposition if it is within 100 kilometers of the article's coordinates. Does that sound implementable? Cheers! Syced (talk) 08:22, 23 August 2016 (UTC)
Yokohama Landmark Tower (Q587108) and Landmark Tower (Q19361336) located in Texas (both have Wikidata label Landmark Tower) - Again this is why I mentioned issues earlier and to double check!
As far as checking to see if an entry is within 100 km, that would be interesting; however, as some wish to have all kinds of listings in Wikidata (which I oppose except, for relatively important sites/locations) - imagine Coffee Day (India) or some other chain all within the same lat/long info? -- Matroc (talk) 04:01, 24 August 2016 (UTC)
Can you elaborate on the "Coffee Day" example? Are you talking about two listings with the same name that are within 100km of each other? Syced (talk) 04:23, 24 August 2016 (UTC)
Yes, multiple listings with the same name within less than 100km of one another. -- Matroc (talk) 05:20, 24 August 2016 (UTC)
Problem report 3: "Zhongnanhai" has two images on Wikidata, but pressing "Update shared fields using values from Wikidata" does not import any. Syced (talk) 04:23, 24 August 2016 (UTC)
Appears to be working at this time -- Matroc (talk) 05:20, 24 August 2016 (UTC)
  1. I can definitely investigate ways to make it more obvious what the Wikidata article actually represents - using the linked Wikipedia article title (if there is one) sounds like a good idea, although I won't have time to work on it right away. In the mean time note that after you select a value there is a link in the listing editor that will take you to the Wikidata page so that you can verify your selection is correct.
  2. I'm not sure how to resolve the issue with searches not returning expected results - the listing editor is using the same search algorithm that is in use on Wikidata, so if it's not finding a result that's an issue with the Wikidata search algorithm. A geographic search based on lat/long is an interesting idea and would definitely be useful, but I don't know if it's technically possible. If someone else can create a proof of concept then I can help to integrate it into the listing editor, but it's not something I'm likely to pursue on my own.
  3. The issue of records with multiple images not returning an image should now be fixed.
Thanks as always for the feedback! -- Ryan • (talk) • 04:40, 24 August 2016 (UTC)
Strange, "Zhongnanhai" still does not get any image. Syced (talk) 05:06, 24 August 2016 (UTC)
If I search for "Zhongnanhai" it gives me record "d:Q197889", and when I then click on "Update shared fields using values from Wikidata" I get "Victory banquet for the distinguished officers and soldiers at the Ziguangge (Hall of Purple Glaze).jpg". Have you reloaded your browser? Sometimes it takes a bit for gadget JS to update in the cache. -- Ryan • (talk) • 05:11, 24 August 2016 (UTC)
After restarting my browser and pressing CTRL+R (instead of just f5) it worked, thanks for the fix :-) Syced (talk) 06:06, 24 August 2016 (UTC)

Listing editor testing requestedEdit

Swept in from the pub

There is a longstanding bug in the listing editor where listings can be mangled if any field of the listing contains a pipe character ("|"). In practice this means that many listings containing embedded templates, wikilinks, or images are not editable by the listing editor.

I think I've finally fixed that bug, but the change is not completely straightforward, so I would appreciate help in testing it. For those willing to help, can you install the beta listing editor and report any failures in this thread? To install the beta listing editor:

  1. Go to your user preferences and click on the "Gadgets" tab.
  2. De-select the existing "ListingEditor" in the "General" section (required - both old & new listing editors cannot be active at the same time).
  3. Select "ListingEditor2 (beta)" from the "Experimental" section.
  4. Click "Save" at the bottom of the preferences page.
  5. You may need to wait a several minutes for the change to take effect as there is sometimes a lag in enabling gadgets.

The only difference between the current listing editor and the beta is the change for dealing with pipe characters in listings, so you should not see any changes from the normal listing editor, aside from the fact that a nasty bug should be eliminated. In addition to failure reports, if you use the beta listing editor for a significant number of edits without issue then reporting success would also be helpful. -- Ryan • (talk) • 15:45, 4 October 2016 (UTC)

Since no issues have been reported I've pushed the changes live, so everyone using the listing editor should now be able to edit listings containing embedded templates or wikilinks without error. -- Ryan • (talk) • 17:11, 6 October 2016 (UTC)

Listing Editor in other languagesEdit

Swept in from the pub

So I have been looking around other language editions recently. Is it true that de-WV is the only other language edition not to have the listing editor? An editor at de-WV recently posted to my talk page that he does not intend to implement the listing editor because he considers it the technologically wrong thing to do and he does not want to saddle the community with a maintenance task that might prove untenable. Why is it then used on so many other wikis? Are there good reasons for not having the listing editor (please keep in mind that I know nothing about the technology and code behind all this)? Is the basic code behind it the same for all language editions or does it have to be ported locally every single time? Would it be feasible to have one for all language editions? Is that what is already happening? I just find the vcards on de-WV way too complicated and surely not what I want to have to contend with when I just want to add a restaurant I like. Hobbitschuster (talk) 17:59, 12 April 2017 (UTC)

I am the editor at WV/de who was mentioned above. And I want to point out, that its just a very personal opinion, not the opinion of the WV/de community. I think that local software developments are the wrong way to become a stable feature in future. I think the listing editor has two big problems. It is just useful for the "WV freaks" like us (I am not a fluent speaker - can I use it that way?) - users who edit at home and on their desktop computers. But we need information from travellers around the world, travellers who sit in a cafe in Bangkok or Pretoria and want to add the cafe they currently sit in. But the listing editor does not work in the visual editor and on any smartphone or tablet computer - it's a feature for "us" not a feature for "them" to attract all the travellers on their way around the world. I think we should focus on a better solution that works properly on all devices - and it should fetch data from WD directly, like our listing template. I am want to talk with the WD guys to get a feature to edit WD directly from the local wiki without being directed to WD. .... just talking about editing WV when sitting in a pub in..... Montreal.... any chance for a WV-meeting in Montreal?
Sorry for being silent. I am going to drop a message about the Wikimania here at Easter weekend and ask for needs, wishes, ideas... Hopefully some of your wishes will come true... see ya soon.. -- DerFussi 19:56, 12 April 2017 (UTC)
@DerFussi: Your perspective is valuable and your English is perfectly fine. —Justin (koavf)TCM 22:11, 12 April 2017 (UTC)
Just to ask, what is the purpose of discussing this here on the English WV pub? Surely this only impacts German WV? --Andrewssi2 (talk) 22:44, 12 April 2017 (UTC)
@Andrewssi2: If there are good reasons to not use the Listing Editor then it is certainly worth thinking about that here. —Justin (koavf)TCM 00:02, 13 April 2017 (UTC)
User:Koavf - if there is any suggestion that we may remove the listing editor on English WV then frankly you need to make this topic explicit. You can probably expect a strong reaction though. Andrewssi2 (talk) 00:49, 13 April 2017 (UTC)
@Andrewssi2: Okay. I am not suggesting that. —Justin (koavf)TCM 05:48, 13 April 2017 (UTC)
I can appreciate the limitations of the Listings Editor raised. Useful on large screen devices and I've not tried it on small screens but I can appreciate the value of having somebody sitting at a bar submitting new listings through their Smartphone. And it made me wonder about the potential for a vCard interface. New functionality (and I've no idea what de-WV do) but a means/button to add a listing through uploading a vCard AND, an option for a reader to export a listing as a vCard (and download it to their computer in a similar manner to the .gpx export for destination pages that have geo coordinates. i.e. each listing has a vCard button at the end and user clicks it and listing exported and downloads a vCard they can save/add to their contacts/whatever. Authors/users would not need to know technical details of a vCard, just export and submit from their contacts or export and download from WV. vCards are a well established standard and most contact system recognise and import and export them. PsamatheM (talk) 22:51, 12 April 2017 (UTC)
So how does the VCARD work on the German page? I am not seeing any icons to help input the format (not even the icons we have here for see and sleep) apart from by hand in my browser. --Traveler100 (talk) 06:02, 13 April 2017 (UTC)
We have no different listings for see and sleep. They are similar anyway. We just choose a type as an additional parameter. Check Nanxun. Maybe the section sleep ("Unterkunft") is a good example. No phone number, coordinates, Chinese names and adress in the listing. All fetched from directly Wikidata. The Infobox is empty as well, even the tourist information is on WD. Everything is delivered from WD there. In the edit window just put your cursor into the vcard template and press {T}. This button opens the template in the "Template Master" - works with all templates, not only the vcard. An empty vcard can by added via the edit tools. Can you see it? Not as comfortable as your listing editor. We have some tools but and maybe that's why we were too lazy to setup your listing editor (and due to my limited time I have no time for feature requests after starting it). If somebody else want to add it WV/de, just do it. And i still hope for a better solution as part of the VE and mobile editor. -- DerFussi 10:55, 13 April 2017 (UTC)
You are correct that the listing editor doesn't work "in" the visual editor, but it also doesn't work "in" any of the old wikitext editors, either. The visual editor should not interfere with using the listing editor (and vice versa). Whatamidoing (WMF) (talk) 21:00, 13 April 2017 (UTC)
Well the upsides of vcards and the listing editor are relatively independent of the language edition, aren't they? and if de-WV has good reasons for doing what they do, we should at least hear them. As a writer, I think the listing editor is far superior to vcards, but they do seem to have some functions our listing editor currently doesn't have. Of course we'll always have to weigh functions on one hand and usability on the other. Very often some gimicky function makes stuff needlessly complicated and discourages editing. Hobbitschuster (talk) 21:35, 13 April 2017 (UTC)
Don't compare the listing editor and the vcard. You can't do. One is an edit feature the other one is a mediawiki template. You can compare your listings (see, do, eat...) with our VCard (they work similar, there is almost no difference, we just fetch information from Wikidata, and we even intentionally use the same parameters as you). And you can compare your listing editor with our template master to get a form to fill out the template (do not forget, we had the vcard and the old template master for six years already when you joined Wikivoyage in 2012). So i do not understand the importance of the discussion here and on WV/de. Both edit features work in the "classic wiki" only. Thats the issue. And thats why my intention is to focus on talks with Wikidata and VE guys to get easy to use features. Maybe a template favourite list of templates (not called "template favourites") that can easily added when editing an article ("add sight"). The template list could be setup in every local wiki. Travellers sitting in a cafe and not knowing about wikis, don't know abut the existence of templates, and even if they don't know the name of the suitable template. Thats the disadvantage of the VE and template master but the huge advantage of your listing editor. And thats why I will be in Montreal, also for technical talks (what is possible, what not). Maybe we can draft a proper long term feature request for the developing team. I am going to write down some thoughts on meta this weekend and send a mass message to the lounges to join the discussion. -- DerFussi 05:53, 14 April 2017 (UTC)
I repeat: The listing editor does not use "the classic editor". Click here to see what the listing editor looks like. It does not look like a regular wikitext editing window. The listing editor calls the API directly (as far as I can tell from the documentation, anyway). You reach the listing editor by clicking the link that says [Add listing]. If you click an 'Edit' button first, then you are not using the listing editor. Whatamidoing (WMF) (talk) 16:03, 14 April 2017 (UTC)
Of course, I am aware of that. Thats why I wrote above "classic wiki", not classic wiki editor. Maybe i did not talk clearly. Maybe I should have said desktop version. -- DerFussi 17:04, 14 April 2017 (UTC)
But something like the listing editor should become a part of the VE and mobile editor. This would be really cool. -- DerFussi 17:09, 14 April 2017 (UTC)
When phab:T96710 is addressed, then we might get fairly close to that. (However, right now, the visual editor on mobile is rather limited. For example, it can't insert templates unless you have memorized the keyboard shortcut.) Whatamidoing (WMF) (talk) 18:22, 15 April 2017 (UTC)

Yes, a mobile compliant listing editor would be a great idea for the future. Hobbitschuster (talk) 17:52, 14 April 2017 (UTC)


  1. Still working on Nanxun. I've added all information about sights and hotels to Wikidata. Is it possible to extend the listing editor features? It should fetch information about address, phone number, email, website from Wikidata as well.
  2. On WV/de the listing template itself takes its information directly from WD. So we give our listings just the Wikidata-ID, not more, no addresses, no phone numbers... . Any plans to improve your listings as well? -- DerFussi 17:33, 3 June 2017 (UTC)
Just a reminder. Are there any plans to improve your listing editor? I maintain all listings on Wikidata (incl. phonen umbers, bilingual addresses ...) Its a lot of work to type it in here as well. Even your copy button doesn't fetch all the necessary information. -- DerFussi 11:20, 24 June 2018 (UTC)

Listing editor broken?Edit

Swept in from the pub

Is it broken for anyone else? Tried using current and beta version. When I’m on the page for Asbury Park, clicking edit under the food section works find however under the drinks section it selects wrong info. What’s wrong? @Ryan: – Craig Davison (talk) 23:15, 17 April 2018 (UTC)

It's working for me. Maybe try again? WhatamIdoing (talk) 03:53, 18 April 2018 (UTC)
Ok, I've just tried it out on Chrome and it turns out it works. It must be a bug with Safari on macOS. Will submit a bug report. – Craig Davison (talk) 06:38, 18 April 2018 (UTC)
Actually, seems to have the same problem there. I get "Error: An unknown error has been encountered while attempting to save the listing, please try again: invalidsection" when trying to save. – Craig Davison (talk) 08:28, 18 April 2018 (UTC)

Problem with listings editor?Edit

Swept in from the pub

Does anyone have an idea what went wrong in this edit? I used the listings editor to add some text to the "content" of the listing, but a lot of different parts were affected in the surrounding section that I didn't even touch. Please also look at the resulting page [5]. Xsobev (talk) 09:25, 4 May 2018 (UTC)

I think the listings editor doesn't handle line breaks. Looks like in the edit you linked, there was an addition of two paragraph tags without their corresponding closing tags. I think I've had to add paragraphs to listings by hand before. Good luck! --ButteBag (talk) 23:10, 6 May 2018 (UTC)
The listing editor was written to convert newlines to paragraph tags, but in your example the airport was an inline listing, so the listing content should not have contained newlines (and now shouldn't contain paragraph tags). For a non-inline listing, newlines must be converted to paragraph tags for the listing to render properly in the lists used on Wikivoyage - leaving a newline in the listing would close the list and cause the content to appear as paragraphs following the list. See the following example::
  • listing content with newlines

content following a newline more content following a newline

...versus the following, which replaces newlines with paragraph tags:
  • listing content with paragraph tags

    content following a newline

    more content following a newline

-- Ryan • (talk) • 02:31, 7 May 2018 (UTC)
Thanks for your explanations. So if a section is edited with "edit source", then a regular line break (by hitting enter) in the "content" field of the listings template will cause problems both with rendering and with the listings editor later on. Only that in the linked edit the rendering problems were not visible, because the listing was not part of an itemized list. So the only way to manually (with "edit source") add a correct line break in the "content" field of a listing template is to use "<p>" (or "<br>"?) instead. Is that correct? If using the listings editor and adding a regular line break (by hitting enter) in the "content" field, then the listings editor will automatically turn that into "<p>" when saving, and turn "<p>" into regular line breaks when showing the content. Is that also correct? So there seems to be a case, which isn't handled correctly: if the listings editor encounters regular line breaks that are already in the wiki source text. It should just convert them to "<p>" when saving, but somehow that doesn't happen.
I now also saw another use of the p-tag, which also seems to cause problems when using the listings editor: the first listing for Rome/Vatican#St._Peter's_Basilica. It replaces the "<p>", but not the (incorrect?) "</p>". Also the first "<p>" seems to cause two regular line breaks in the listings editor. Xsobev (talk) 08:49, 8 May 2018 (UTC)
I tried to "fix" the line breaks in the airport listing in Edinburgh#Get in by replacing them with "<p>", but the preview shows the same display errors (all following line breaks in the section are screwed up) as they can be seen here. Xsobev (talk) 08:09, 11 May 2018 (UTC)

Changes to the ListingEditorEdit

Swept in from the pub

I've been making some changes to the ListingEditor gadget in my userspace. I'm looking for feedback. If anyone is interested in testing the changes with me, you can disable your listing editor gadget and copy my common.js and common.css to switch over. Any feedback on the alterations to the appearance of the editor, including changes to the text, and on bugs/glitches would be appreciated. Even if not testing, I'm looking for some other feedback, so please read on if you use the listing editor.

I've copied over the preview functionality from the German version, which is very useful. I've also added the automatic updating/addition of IATA codes for airports, and trimming of a trailing period in the price box (as you sometimes see new users writing, resulting in a double period). The significant-ish thing I've written in are lock checkboxes to prevent certain fields from updating from Wikidata, specifically the URL, coordinates, and image.

I've added tooltip text to warn users against using it if the Wikidata information is inaccurate, as a way to avoid fixing the information there, and instead suggesting some "acceptable" use cases. The ones I thought of are listed below:

  • Lock URL: Use this only if Wikidata links to a non-English website, and we have the English version set.
  • Lock coords: Use this only in case of the wrong coordinates being selected. For example, if the listing is for a river, and the Wikidata coordinates show the mouth of the river, while we want a point on the river.
  • Lock image: Use this only if we have a better image that we cannot put on Commons
  • Lock image: or if we have a subjectively better photo set here, and we have been prevented from changing the one in Wikidata to match
  • Lock image: or if we do not want an image here at all.

Can anyone think of any other use cases to write into the tooltip? Maybe some of these should be fixed on Wikidata's end? Alternately, should I remove the tooltip completely, and assume all editors know the appropriate times not to update from Wikidata?

Should I add lock checkboxes for any other fields? I couldn't think of any use cases for the others. Alternately, are the checkboxes useless and should I remove them completely? I ask this question also of the other changes, and of this endeavor as a whole.

Finally, one question for the community: would we consider switching to the RFC3966 standard for phone numbers? It is very similar to what we use now; the only difference is the addition of a dash after the country code and the area code equivalent. Doing so would allow use to use Wikidata phone and fax numbers. Example here

ARR8 (talk) 00:45, 2 October 2018 (UTC)

Sounds good, but I suppose usability folks would be afraid the interface could feel too complex with the lock boxes. One could have a box to activate them, with them otherwise greyed, I do not know whether that helps or makes it worse.
There are a few more reasons to lock our versions, mostly pertaining to our wanting visitor information while Wikidata may have general information. This concerns images as well as URLs. I think the tooltips are a good tool to standardise use. I think only the editors who spend time at the pub automatically get to know our reasoning.
Our current phone number standard is counter-intuitive for me and probably many others, but it tells what part of the number can be used when dialling locally (traditional phones do not allow dialling the +xx... global number). The RFC3966 standard does not provide an obvious way to do that ("." characters are allowed, should those be used? probably there is some other common use for them).
--LPfi (talk) 06:27, 2 October 2018 (UTC)
You might be able to get around that complexity by not using checkboxes, and instead offering "get all from Wikidata" (what we have now) followed by a little "Advanced" button, which gives you a new form with all the checkboxes.
On the phone numbers, I've long wondered why we use different formats for regular and toll-free phone numbers. I'd support making them match any sensible system. WhatamIdoing (talk) 15:44, 2 October 2018 (UTC)
The checkboxes are hopefully unobtrusive. They have no text next to them, just a lock icon. I would post a screenshot if I knew how. The "advanced" button is an option, though. Greying out, I'm not sure about, for a couple of reasons, one of them technical. However, in the meantime, I think I'll at least modify it to only show the checkboxes if there is a Wikidata ID set, much like the update link itself. That should simplify things at least for users adding new listings. ARR8 (talk) 16:14, 2 October 2018 (UTC)
One alternative to the checkboxes would be to import the Wikidata only into fields which are currently blank. If the local and Wikidata fields are both populated, but with different info, one line of static text somewhere could be displayed to indicate the mismatch - with the local data left intact unless the user manually removes or replaces it. K7L (talk) 16:38, 2 October 2018 (UTC)
  Support: I think this makes most sense. Just extend the text to "Update empty shared fields...". The added benefit is that users that are not knowledgable/read enough won't overwrite stuff by accident...-- 08:32, 6 October 2018 (UTC)
I have to admit, I don't really like this option. It seems like it adds a lot of time-consuming copy-pasting if the editor actually does want to overwrite the values, which I find myself doing more often than not. Still, it's possible, though a little challenging to figure out a good place to put the static text in a way that makes the intent obvious and still looks okay. ARR8 (talk) 18:56, 2 October 2018 (UTC)
w:en:WP:WPSHOT has directions for uploading a screenshot. WhatamIdoing (talk) 17:26, 3 October 2018 (UTC)
It wouldn't involve "a lot of time-consuming copy-pasting if the editor actually does want to overwrite the values"; all they'd have to do is blank the existing field and click "import from Wikidata". K7L (talk) 17:52, 3 October 2018 (UTC)
You're right, I don't know why I didn't think of that. It's still not my favorite option, but I won't dismiss it out of hand; if there's a consensus that this is the direction we want to take the listing editor (and that we want to change it at all...), I'll do my best to implement that.
I'll also look into making that screenshot. ARR8 (talk) 02:16, 4 October 2018 (UTC)


Here's a screenshot. Hopefully this clarifies things. ARR8 (talk) 01:46, 5 October 2018 (UTC)
I've just changed it to show a tooltip and the preview. I doubt anyone's seen the screenshot yet, but I don't want to change things without notice. ARR8 (talk) 01:54, 5 October 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Another update to the ListingEditor. Added a button to get the Wikidata ID from an entered Wikipedia article. I find that the Wikipedia autocomplete is much more intuitive than the Wikidata autocomplete. The button is just the letters "WP" next to the Wikidata box. Any thoughts are welcome.

I feel like I should mention that if anyone has any feature requests for tweaks to the editor, I would appreciate hearing them. I will obviously ask in the near future for this to be moved out of my userspace, once no one has any more input or objections. It would be nice if this update could address others' gripes with the editor, not just mine.

By the way, still no consensus on what to do with the checkboxes, or importing phone numbers from Wikidata. I'm leaving both as-is for now. If we don't reach a consensus, I'd like to revisit this in the future, perhaps after rolling out the uncontroversial changes (preview, etc.). Thanks to everyone who did respond so far. ARR8 (talk) 00:30, 7 October 2018 (UTC)

If making changes to the listing editor, can a mobile number field be added? There was a discussion ages ago which I thought came to the conclusion it wasca good idea but ascwith many things, somebody with knowledge, etc. needs to to make those changes. But I have no idea about finding those discussions PsamatheM (talk) 18:59, 20 October 2018 (UTC)

Sorry, that's not related to the listing editor. That's the template itself, {{listing}}. So while I could add a field, it wouldn't actually put the number anywhere on the page without matching template changes. ARR8 (talk) 19:58, 20 October 2018 (UTC)
Isn't it nowadays possible to have several comma separated numbers in the phone field, with comments in parenthesis: "phone=+358 9 123-456 (office), +358 40-123-456 (mobile)"? --LPfi (talk) 16:19, 21 October 2018 (UTC)
As far as the listing editor goes, yes. It only validates e-mail, Wikipedia, and Image fields. ARR8 (talk) 16:25, 21 October 2018 (UTC)
And the result is working phone number links (i.e. the template handles them), and the ErrorHighlighter does not warn about them. --LPfi (talk) 12:13, 22 October 2018 (UTC)

New changesEdit

Hi all. I'll keep this short; following the last discussion, I have made some changes to the listing editor. There is a changelog, but of note is a new bidirectional Wikidata Sync window to complement the "update values" function; screenshot attached. This allows comparison of local and remote values and selecting the better of the two. The lock checkboxes are gone in favor of this. Being able to compare the values was suggested by User:K7L and supported by

It also has links to quickly compare coordinates on a map. This should help address common grievances about editors overwriting good coordinates with worse ones (ping User:Ceever).


Unless anyone opposes, I'd like this to be linked to the Listing Editor Beta gadget, which currently is exactly the same as the regular listing editor. Only an admin can do this. I think this can be done now, as that gadget is explicitly said to be a testing feature.

Any feedback on anything is very welcome. Having tried the editor is not necessary to leave feedback. If requested, I can upload more screenshots. Feature requests are also welcome. If you're reading this, please comment.

ARR8 (talk) 02:10, 24 November 2018 (UTC)


I'll add some more notes here. Since I think the length of the last post was a reason it did not generate much discussion, I'll say it's unnecessary to read further.

I'll use this space to also ping User:LPfi and User:WhatamIdoing, who also participated in the earlier discussion, which I greatly appreciated. Some questions I'd like some consensus on at some point, to drive the discussion: 1) The editor now has two modes for coordinate sync available in the settings. The first copies the coordinates from Wikidata when so requested; the other just removes them and let's them be auto-fetched from the Wikidata ID by the template. This was discussed here, and the community seemed to lean toward the first option, so I have set that for now. 2) the phone number question from the first discussion. Doesn't need to be addressed here; I'll open a discussion at the relevant policy page in the future. 3) Edits are now made on Wikidata. The API allows text to be appended to the edit summary; should we do that? E.g. Listing Editor. 4) Phrasing of the sync instructions visible in the screenshot.

A note on usability: I've added a few quality-of-life features, like the auto-select link, the clickable column headers, the clear all link, expanding the clickable area on links to the full width, etc. I would like to add as many of these as possible to make working with the editor easy for any given workflow/HID setup.

ARR8 (talk) 02:10, 24 November 2018 (UTC)

ARR8, I've updated the Beta gadget.
Just looking at the section of code below, the spans between the fieldset tags are not balanced.
					ListingEditor.Config.TRANSLATIONS.wikidataSyncBlurb +
					'<p>' +
					'<fieldset style="border:none;padding:0">' +
						'<span class="listing-span_1_of_2">' +
							'<span class="wikidata-update" />' +
							'<a href="javascript:" class="syncSelect" name="wd" title="' + ListingEditor.Config.TRANSLATIONS.selectAll + '">Wikidata</a>' +
						'</span>' +
						'<span class="listing-span_1_of_2">' +
						'<a href="javascript:" class="syncSelect" name="wv" title="' + ListingEditor.Config.TRANSLATIONS.selectAll + '">Wikivoyage</a>' +
						'<span class="wikivoyage-update">' +
					'</fieldset><a href="javascript:" id="autoSelect" class="listing-tooltip" title="Select all values where the alternative is empty.">Auto</a>';
Should it be changed to?
					ListingEditor.Config.TRANSLATIONS.wikidataSyncBlurb +
					'<p>' +
					'<fieldset style="border:none;padding:0">' +
						'<span class="listing-span_1_of_2">' +
							'<span class="wikidata-update" />' +
							'<a href="javascript:" class="syncSelect" name="wd" title="' + ListingEditor.Config.TRANSLATIONS.selectAll + '">Wikidata</a>' +
						'</span>' +
						'<span class="listing-span_1_of_2">' +
							'<a href="javascript:" class="syncSelect" name="wv" title="' + ListingEditor.Config.TRANSLATIONS.selectAll + '">Wikivoyage</a>' +
							'<span class="wikivoyage-update" />' +
						'</span>' +
					'</fieldset><a href="javascript:" id="autoSelect" class="listing-tooltip" title="Select all values where the alternative is empty.">Auto</a>';
-- WOSlinker (talk) 07:33, 24 November 2018 (UTC)
@WOSlinker: Yes, good catch, and thank you for noticing and for uploading. Could you make the change? ARR8 (talk) 15:13, 24 November 2018 (UTC)
@WOSlinker: Sorry, one thing I forgot to mention: could you add the new dependency (mediawiki.user) to the gadget definitions? Also, I seem to be having some trouble disabling my common.js and common.css files... ARR8 (talk) 15:21, 24 November 2018 (UTC)
I've made those changes. Might just be caching causing issues for your common.js file. You may just need to wait a little while. -- WOSlinker (talk) 17:05, 24 November 2018 (UTC)
Thanks you. Any thoughts on the changes, incidentally? ARR8 (talk) 17:20, 24 November 2018 (UTC)
Not tried them yet but will do over the next day or two. -- WOSlinker (talk) 18:47, 24 November 2018 (UTC)
Have tried them out and all looks good to me. No issues. -- WOSlinker (talk) 12:04, 27 November 2018 (UTC)
Looks quite good already, just two notes:
  • I'd replace "Submit" button text with "OK" or something like that - to not suggest that after I press the button, the changes will be uploaded...
  • Maybe the tool could pre-select the radio buttons - if there is WV data, choose that; otherwise choose WD if non-empty.
-- 09:40, 24 November 2018 (UTC) Thanks for the feedback. For point one: Actually, after you press the button, the changes do get uploaded. To Wikidata, that is; the local changes still need the edit summary put in, maybe some more edits, etc., so the listing editor itself also has the Submit button.
For point two, this is something I was thinking about. I did set up a naive auto-select, which can be accessed with the 'Auto' link under the headers. It's more conservative than what you were suggesting, but same idea. I was considering running it automatically when the dialog opened, but I thought that might be confusing for new editors, who might assume having some values pre-selected meant they were already in sync. If I'm being overly cautious, I'll happily set that up.
May I ask: have you tried out the new editor? If so, was the Auto-select not noticeable? Or maybe it was, but the description wasn't very good? Or maybe it's not in a convenient location to use every time? ARR8 (talk) 15:13, 24 November 2018 (UTC)
Oh, ooooooooh.... Well, I'm inclined to say that I quite like the upload-to-wikidata feature. However seeing that it deletes data from wikidata if one doesn't select anything, that looks quite dangerous (I'd say this operation is needed very sparsely). For sure wikidata may need different image or coordinates than wikivoyage, as we discussed in pub and elsewhere. I think if we want to mainline this, the interface should be made a big clearer to show what's going where, and when. Right off the bat, I'd say some buttons (like "Update wikidata entry", "Choose for the listing", "Cancel") would be better than the current solution ("whatever is selected goes right into wikidata, and will update the listing preview"). -- 14:23, 9 December 2018 (UTC) I think I see what you're getting at, but I'm not sure. I'll point out, first, that it doesn't delete the data if nothing is selected; if nothing is selected, it skips the field. It deletes from Wikidata if a blank space is selected (so, if we have no value in, say, the URL field, and Wikidata does, an editor can select the Wikivoyage column to delete the URL from Wikidata). If you understood correctly, that's fine, good to have this spelled out on the page in case anyone else has concerns.
Regarding the interface: If I understand correctly, you're proposing to split the "Submit" button up into two buttons? This would make it somewhat clearer what's going on, but I think there's some drawbacks: new editors would be initially confused ("where's the submit button?") and experienced editors would now have three clicks instead of one (Wikidata, Listing, Close). Additionally, people might forget to do one of those functions.
My intention was that the function would be clear from the word "Sync." The link to open it says "Sync" on it, the dialog says "Sync" on top - I believed that would imply bidirectional data transfer. If not, then, yes, we should figure out a way to make it clearer. I'm not sure about the buttons with those drawbacks I outlined, and I don't really want to add it to the top because, below, we were talking about shortening it... I could add a tooltip to the submit button outlining what it does, but that would be hidden away unless someone hovers over it. What do you think? ARR8 (talk) 15:36, 9 December 2018 (UTC)
@ARR8:, yep, you seem to have understood my points. I guess the dialog cannot be simple by design, it tries to work with 2 databases at once... I dare to consider myself a relatively advanced editor, and I was indeed confused, probably mainly by the text 'Update shared fields using values from Wikidata'. Maybe that should already state "Sync listing with wikidata"? I would say vast majority of random visitors don't even know what wikidata is (not to mention what's a "reference"), so I would say it's very much needed to be cautions and prevent destroying wikdiata (or wv for that matter) stuff by good-intentions-but-little-knowledge. The WD stuff is quite exposed, and likely quite poorly patrolled, so...
Regarding the tooltips, that likely really wouldn't help. But I think even though there's a 'push' against making the table bigger, we should really head for a clean (=obvious) UI, than nice UI. Of course, it doesn't make sense to have every functionality inside, but we should probably pick the group of people who this thing is really most useful for, and design it for them. At some point, advanced editors will just create the listings by hand - and the very beginners won't bother with WD anyway...
I can try to come up with some mockup of the layout, if you think it still makes sense. But don't mind me too much. I am usually too lazy to bother with this stuff anyway, and just add WD to the listing (because that implies fetching WD coords+image into the markers anyway). Of course, if the UI is good, it may change :-) -- 20:30, 9 December 2018 (UTC)
I'll change the link text to "Sync shared fields to/from Wikidata". I thought I already had, but apparently not.
Regarding information loss - the changes are a measure to prevent losing information already in WV. This is something that would happen a lot with the old editor with users (frequently, me) fetching Wikidata values and overwriting information that was already here that may have been better.
Hopefully, these changes also make Wikidata sync more worthwhile for all kinds of editors to use. For newer users, the Wikidata ID can now be imported from the Wikipedia link, so they do not even have to know what Wikidata is. For more advanced users, there is finer control of what data to sync. Therefore, I would definitely be interested to hear what changes you think would make the editor better to use for you and editors like you.
However, I'm really not sure about splitting the "submit" function up. I can't help but think that would make things more confusing both for those looking to simply submit their changes and those looking for a quick workflow when working with listings. I think it would be good to find a solution here, but I don't think that's it. Either way, if you can think of a change that makes the UI easier to use as the expense of "cluttering" or expanding the table, I would definitely be interested in hearing it. Perhaps new additions to the table can be intelligently hidden unless necessary, like the Wikidata information, so I wouldn't worry about clutter. ARR8 (talk) 22:33, 9 December 2018 (UTC) Sorry, forgot to ping you with that reply. Interested in hearing your thoughts. ARR8 (talk) 05:58, 11 December 2018 (UTC)
I'm watching this @ARR8:, no worries... I'm just somewhat busy in my real life :-) I'll be back soon! -- 06:22, 11 December 2018 (UTC)
Hi ARR8. Thanks very much for your effort. I feel this is a great step forward and also will help cleaning up WD.
As I understand, the GPS coordinates are linked to a map, so I can verify directly which GPS is the best, right? Furthermore, the URLs are links as well? Which would help.
You said that the GPS coordinates are copied from WV to WD if selected, but the reference is not filled, right? Here I would definitely create a generic reference like "imported from Wikimedia project: English Wikipedia" and remove the existing one. Also, maybe a link to the relevant page on WV would help, I guess. But the latter might be overload.
Otherwise, I would shorten the description of the data sync a little. Also, I would definitely put like a big "Choose the correct data - unselect will not change anything" above everything. So that even when people do not bother to read, at least nothing is messed up due to any miscomprehension about the functionality, e.g. do I choose the target or the origin.
Cheers Ceever (talk) 21:16, 26 November 2018 (UTC)
@Ceever: Thanks for the feedback and kind words. The GPS coordinates are linked to a map, yes. I have been using this to compare coordinates and have been finding it personally very helpful.
The URLs are not links, but that can be changed. There's pros and cons, but it probably makes more sense to make that change, so I think I'll do that.
The references: This is something I have been thinking about. Currently, I have been adding "Imported from English Wikivoyage" manually. Note that this doesn't apply only to coordinates, but also to any of the fields. My worry with doing it automatically is overwriting a real reference, for information like, say, a URL, because of a trivial change like correcting http:// to https://. So putting the reference in automatically has problems. Even if there were no references already, people who are adding coordinates would ideally put in the source they got their coordinates from, like OpenStreetMaps or Google Maps, which is preferred to simply writing Wikivoyage. My current thought is changing the reference if the only reference is currently "Imported from" another project or empty. How does that sound? Other than these cases, I'm not sure when we can be sure it's safe to change the reference.
You raise a good point about the instructions. I spelled everything out as a form of "fool-proofing" for new editors, but you're right that, in its current form, people may not read it. However, I think telling people to simply choose correct data can be misleading like in cases when both sites have correct data and we don't want them synced, e.g. if we have a travel website URL and WD has an official website URL.
I'd be interested in hearing your thoughts in light of this reply, and anything else you might think of. ARR8 (talk) 22:48, 26 November 2018 (UTC)
OK, great.
Regarding the reference, isn't it equally or even more fatal to leave what is on WD already? Because that is just wrong then. I guess most people will not really bother about the reference (even though they should), but leaving something like "imported from Russian Wikipedia" is far worse that a generic "imported from English Wikivoyage". And if editors really bother about the reference, they will always head over to WD and adjust the generic term. Sure, a change of http to https might not be necessary the reference change, but nevertheless this change came from WV and not somewhere else. And if WV is the source for WD, that is just the way, like many other information are sourced on other WP sites for WD.
In addition, maybe you could add a link to WD with an emphasis to maintain the reference over there in more detail.
I understand your point about my proposal regarding the short advice. But of course, this is just a proposal, if you got something more appropriate, please go ahead. I was merely pointing out the issue with long descriptions, for which we must find a solution.
Cheers Ceever (talk) 15:15, 1 December 2018 (UTC)
Good points. I'll address the easy one first: there is already a link to the WD item, in the title of the dialog window, and already a statement to maintain the references in the instructions. It is already slightly emphasized, but hopefully it'll stand out more once the instructions are shortened.
Anyway, here's my logic regarding references: Wikidata currently has a problem with the vast majority of the references being generic "imported from" some Wikimedia project. Some values have a reference that is an actual "stated in" reference, which points to something outside Wikimedia. I believe the goal for Wikidata is to maximize these.
That being said, I agree with you completely about the problem with "imported from" references being wrong (I said that above, but it maybe wasn't clear) so I've just added functionality to change the reference in case it is only an "imported from." This is somewhat of a compromise between our suggestions: the reference is changed even for minor changes like the https:// example, but it is also not changed if anything more sophisticated than "imported from" is present. Your thoughts?
I've shortened the instructions somewhat, as well.
All of these changes are in my userspace for now. I need an admin to copy them over, but I think I'll make a couple more changes before pinging and annoying admins. However if you (or anyone reading this) would like to test them, feel free to ask an admin to copy these changes over now. ARR8 (talk) 17:08, 1 December 2018 (UTC)
Just added a link to the page on WV where edits come from as part of the reference, as suggested. Here's an example. ARR8 (talk) 00:53, 4 December 2018 (UTC)
The new set of changes seems to be done. Fixes a few bugs, incorporates some requested small features, and has some minor cleanup. I'd like them to be copied over to the gadget for wider testing - @WOSlinker: if you're around, could you please do it?
Done. -- WOSlinker (talk) 20:12, 4 December 2018 (UTC)
In two weeks' time, I'll also request the changes to be finalized to the default gadget, if no one objects. ARR8 (talk) 16:16, 4 December 2018 (UTC)
The new gadget seems to change "see" listings to "listing | type=see" (example). Is this behavior desirable for some reason? —Granger (talk · contribs) 13:59, 5 December 2018 (UTC)
Yes, this is something I just added. This is a longtime to-do for the listing editor, and the old behavior was inconsistent. It had some preset listing types is would treat with the alias, like {{see}}, but others that were arbitrarily called custom types, like {{go}}, which were not supported and would cause problems for users trying to edit them. Rather than keep up the distinction, I've switched it to treat the listing type as any other parameter. I don't think there are any downsides to this change, and I think I read somewhere that the listing aliases were going to be phased out for a while, anyway. Unless you think the old behavior was better? ARR8 (talk) 14:16, 5 December 2018 (UTC)
I don't see any obvious downsides, though I do think it seems a little weird to have an inconsistent situation where some "see" listings use the "see" alias but others use "listing | type=see". I guess the current situation is already somewhat inconsistent because of "listing | type=go" and similar. I don't have much of an opinion about this, but the behavior surprised me, so I thought I'd bring it up in case others see something that I've missed. —Granger (talk · contribs) 14:29, 5 December 2018 (UTC)
I see what you mean. Hopefully this problem could work itself out over time. It may also be worth updating the insert buttons over at MediaWiki:Common.js to switch to listing|type, and incorporate the other changes, like no newline after content (for the record, that supposedly makes listings work better with screen-readers). And, if there does turn out to be a material downside, I'd be happy to revert the change.
Thanks for your thoughts. If you think anything else about the changes is unintuitive or worth commenting on, please feel free to also post it here. ARR8 (talk) 14:44, 5 December 2018 (UTC)

@ARR8: I used the Wikidata sync window when editing Shenzhen today, and overall I thought it was great. There was one problem though: because the sync window was too narrow, it was hard to tell which radio button corresponded to which value (see screenshot). I figured out that I could solve the problem by dragging the bottom right corner to make the sync window wider, but it would be better if the window's default width wasn't so narrow. —Granger (talk · contribs) 03:40, 6 December 2018 (UTC)

Thanks for testing! This is indeed a problem; the default width, for me, is the same as in my screenshot above. It's supposed to be 85% of the main listing editor window, so it seems we have a bug with the editor in your particular browsing setup. I've tested on Chromium-based and Firefox - may I assume you're using Safari? ARR8 (talk) 05:04, 6 December 2018 (UTC)
No, actually, I was using Firefox on a Mac. A moment ago I tested it on Chrome on a Windows computer and the width was fine. When I get home I can check what version of Firefox and operating system I was using when I had the problem. —Granger (talk · contribs) 05:54, 6 December 2018 (UTC)
Firefox 63.0.3 on Mac OS Mojave 10.14. The problem also occurs on Safari 12.0. —Granger (talk · contribs) 14:47, 6 December 2018 (UTC)
@Mx. Granger: Aha, I was just in the middle of replying. If it also happens in Firefox, then this might be a problem related to your resolution. Would you happen to know what that is?
I looked through the code and found a bug which might create unexpected behavior on certain resolutions. If yours was one of those, then that might be the the cause and I can get the fix implemented. ARR8 (talk) 14:52, 6 December 2018 (UTC)
I think it's 1440 x 900. —Granger (talk · contribs) 14:56, 6 December 2018 (UTC)
Thanks, that should do it. @WOSlinker: sorry to be a bother - could you patch this over? ARR8 (talk) 16:01, 6 December 2018 (UTC)
Done. -- WOSlinker (talk) 23:36, 6 December 2018 (UTC)
Thanks again. @Mx. Granger: please let me know if you still run into this bug. ARR8 (talk) 01:08, 7 December 2018 (UTC)
Thanks for the fix! Now the "Wikidata Sync" window is 100% of the width of the "Edit Existing Listing" window. I take it that this is still not the expected behavior, but since it's wide enough to tell which radio buttons go with which values, I'm happy with it. —Granger (talk · contribs) 01:38, 7 December 2018 (UTC)
Kind of expected now. It's something of a workaround; I can get the sync window to be a fraction of the main window width on all resolutions, but it makes it very difficult to drag around. On large resolutions, it will still take the 85% width. Not that this is something most editors will notice, since I imagine many only edit on one device.
Once again, I greatly appreciate the feedback. Please don't hesitate to let me know if you think of anything that could be improved, or run into any more issues. ARR8 (talk) 04:40, 7 December 2018 (UTC)
I would like to suggest that the listing created uses the {{see}} , {{eat}} etc options rather than creating listing type=see. We have a large number of check scripts that use the format to report on the status of articles. For example used in the article status statistics in region expeditions like Wikivoyage:England Expedition. A search give false results, showing Haywards Heath as having no See listing at present. I see the comments below, was actually thinking of requesting to make "go" (and maybe also "event") a full class listing type, fixing the inconsistency that way round would be more useful. --Traveler100 (talk) 07:20, 11 December 2018 (UTC)
@Traveler100: This is a problem. I frequently add listing|type templates when I convert text to listings. I'd like to talk through a couple of proposals.
First, let's say we switch to using the alias templates for every listing. It would then make sense to deprecate the listing|type parameter, since that silently breaks some background scripts. But we can't do that, because, on the backend, this powers the alias templates. Plus, it's not really sustainable; even if we make {{go}} a full alias now, we would still have this problem for any other listing types, since it requires kludgy code in the listing editor. We know this is true because editing {{go}} has never worked with it. But this is a minor point, since adding listing types may be a rare event.
Either way, we need to fix the inconsistency. You say it would be more useful to fix it by making aliases. However, this would leave listing|type as a working method of entry, which we can't fully deprecate. Let's say instead we figure out a way to switch away from the aliases, and only to listing|type (bear with me). That meant we would be able to fully deprecate the aliases in the future, and allow everything and everyone to work with one method of entry. Do I understand things correctly so far?
So, if we can make all the petscans work with listing|type listings, all problems would be solved.
So, here's my proposal, which would take a little bit of work: fix the petscan parameters; allow them to detect listing|type in addition to aliases, with this process:
  1. Edit the listing template, adding a category Category:Has See listing, for listings of the main types (see, do, etc.). This would actually be very simple to add to Module:Map, which gets called for every listing regardless of whether the map is used, and already adds Category:See listing with no coordinates and suchlike.
  2. Edit the petscan parameter scripts to look for this category instead of the alias templates. This would catch both alias listings and template|type listings.
I know this is a departure from the current process, and I don't want to dictate the way we should do things, but I am proposing these changes in good faith and think they would fix some minor problems we have here. Luckily, it's not much work; most of the petscan links are in {{RegionStats}} or {{RegionTasks}}, which is great!
Please, let me know if I am understanding things correctly, and what you think of this proposal in general. Thanks, ARR8 (talk) 14:39, 11 December 2018 (UTC)
@ARR8: The category proposal and modification of the petscans solution you proposed would work. I have no problem with this, not a big effort I think. --Traveler100 (talk) 16:44, 11 December 2018 (UTC)
@Traveler100: Great! I've added the category change over at User:ARR8/Module:Map and have tested it with the template sandbox. As far as I can tell, it doesn't create any errors and the categories are added as needed. I'd like this to be implemented before editing those expedition templates, to minimize breakage. As you know, I don't have the permissions to edit Module:Map, so, if the change meets your approval, would you mind copying it over? ARR8 (talk) 23:01, 11 December 2018 (UTC)
Sure will do. I am travelling at the moment with only occasional internet access so will be a day or two before I can get round to it. But if someone else reading this can do the update please do. --Traveler100 (talk) 04:22, 12 December 2018 (UTC)
I've updated Module:Map. -- WOSlinker (talk) 13:40, 12 December 2018 (UTC)
@WOSlinker:. Thanks. If I am reading it correctly though the "do" is missing. @ARR8: do you want to be consider for admin status? If not we can give you edit access to protected templates now without being and administrator. --Traveler100 (talk) 17:14, 12 December 2018 (UTC)
@WOSlinker: Thanks from me, too. @Traveler100: Thanks for the vote of confidence. Too early for me to consider adminship, I think, but would greatly appreciate template editor status. It would help with this and other changes I have planned. For example, I was asked over at Wikidata to make a tweak to our quickbar module. I wouldn't break functionality without checking with the community first, of course.
"Do" listings were excluded from the other categories (without coordinates) for some reason, but I'll add them in to just these ones. ARR8 (talk) 21:33, 12 December 2018 (UTC)
@Traveler100: I've now noticed the problem you've noticed, which is that petscan doesn't support "any of" for categories, as it does for templates. I tried a workaround by testing pages that "link to any of" Category:Has see listing || Category:Has do listing, but that returns no results, so we'll, unfortunately, likely have to abandon one. I noticed in your test edit to the sandbox that you replaced (see OR do) with (see). Is that what we should do for all the petscan links? ARR8 (talk) 05:02, 15 December 2018 (UTC)
That was one of the reasons for the pause in edit. Other was just busy in another domain. I was thinking about creating some parent categories over the existing ones that could somehow simulate or and add lists. Need to think about it a little more. BTW thanks for spotting the problem with the petscan link. I may undo your edits though and add the language parameter globally to the call as is used in a number of other pages too. --Traveler100 (talk) 06:23, 15 December 2018 (UTC)
Sounds good. ARR8 (talk) 06:26, 15 December 2018 (UTC)
@ARR8: I have updated sandbox versions of RegionStats and RegionTasks. Needs to be check to see if I have the logic correct, takes a bit of getting your head around. --Traveler100 (talk) 08:15, 15 December 2018 (UTC)
Initial checks look good. Main different is now the listings checks also takes in to account markers with relevant types which it did not before. I have also changed the no listing option to be really no listings were as before it ignored drink and buy. --Traveler100 (talk) 14:23, 15 December 2018 (UTC)
@Traveler100: Looks good to me. A couple nitpicky things I noticed, which I thought I'd bring to your attention:
  • When filled in, the numbers wouldn't add up, because the green 'check' box looks for see/do, so 'needs only see' and 'needs only do' won't all be accounted for. This is true of the original version of the template, too, though, and could be intentional. Not a major problem, either way.
  • You changed(?) half of RegionStats to look for article status by Category:Outline cities, and the other half, and RegionTasks, still look for {{outlinecity}}/{{usablecity}}. Either template or category should get the same result here, but, just in case they don't, thought I'd mention it.
  • Technically, some of the calls, which only look for the region categories, have &comb as a redundant parameter, since there's nothing to combine. I don't think this can adversely affect the calls in any way, though.
Otherwise, seems like we're done. Including markers with the appropriate type would, in retrospect, obviously happen, since we edited the module that controls both, but I hadn't realized. Seems like an unintended beneficial side effect, but we could technically exclude them if needed. ARR8 (talk) 16:04, 15 December 2018 (UTC)

I just have some assorted comments, mostly visual feedback about the UI.

  • If it's going to be columnar, it should have better or more obvious labels for the columns. The labels for "Wikidata" and "Wikivoyage" don't really stand out to me, which makes it a bit hard to understand at first glance.
  • Rather than radio buttons on the far outside, what if they were adjacent to each other on the inside, between the two text columns? You could then add a third radio button in the middle for "no change", and get rid of the "clear" link/button. I think that would be a lot easier to comprehend: each row would look like
    <data from Wikidata>   ( )  (*)  ( )   <data from Wikivoyage>
and you choose the the left radio button to choose WD, the right radio button to choose WV, or the middle one to choose "no action".
  • While I'm thinking of it, it's unclear which direction the data will go. When you select a radio button, are you choosing to keep that data, or to replace it?
  • The explanation at the top mentions that sometimes WV intentionally keeps different data than WD. If that's the case, shouldn't we have some way of marking that? Maybe a flag (or better yet a date) in the listing that indicates "someone has already looked at this listing's coords/website/image/whatever [on xxx date] and confirmed that we shouldn't sync it to WD or vice versa", and the editor would no longer ask about it unless the data on one or the other changes.
  • Wikidata has a field for "directions"? Weird. Seems like a strange thing to put there.

--Bigpeteb (talk) 17:27, 17 December 2018 (UTC)

@Bigpeteb: Thanks for the feedback!
  • I'll emphasize the headings more.
  • Good idea. I'll look into making a version with the inner radio buttons for comparison, sometime over the next few days. If anyone else is following this thread: would you prefer the current or the suggested layout?
  • I'm not sure how to make this clearer. It's already written at the top, and I think it's probably more intuitive, to select the data to keep.
  • That would be a good change, but it would require editing {{listing}} to accept a new field. I'm trying to avoid doing that in this round of changes, but maybe in the future.
  • It's a very underused field. It's probably only good for keeping that kind of info in sync between WV and various monuments projects, but I've already used it to copy directions from a listing which was (unbeknownst to me) in two destinations. ARR8 (talk) 00:32, 18 December 2018 (UTC)
@Bigpeteb: It occurs to me that I didn't inform you when I implemented your suggested UI changes a short while ago. Have you seen them, and, if so, do you have any further thoughts or suggestions? They are part of the Listing Editor Beta gadget. I have kept the old UI disabled in the code but I will very likely remove it and keep this one. ARR8 (talk | contribs) 17:00, 27 January 2019 (UTC)

More proposed changes based on the Hebrew Wikivoyage's EditorEdit

In hewikivoyage, we made several additions to the editor, and I thought you might want to adopt them as well:

  • Automatic text direction for "name", "alt" and "address" fields (changes from LTR to RTL as the user types). (Example 2 in Red)
  • ClockPicker for checkin & checkout fields. (Example 4 in Red)
  • Related color sample for the type fields (based on dewikivoyage version). (Example 1 in Red)
  • Checkboxs for Additional Features according to the listing type: (Example 3 in Red)
    • UNESCO World Heritage Sites checkbox for see & do listings.
    • Kosher, Vegetarian and Halal for eat listings.
    • Gay Friendly for drink listings.
    • Campfire for do listings.
    • Accessibility, WiFi and Tripadvisor's featured for all the types.

Feel free to comment and leave feedback :) Best Regards, DL3222 (talk) 08:59, 18 December 2018 (UTC)

@DL3222: Thanks a lot for the suggestions! The checkboxes would require edits to the {{listing}} template, unfortunately, and so couldn't be part of this set of changes. The RTL text conversion is also probably not applicable to en.voy. However, the clockpicker and color preview for type are very interesting for me, and I'll look into those.
I also want to add - I hope you guys over at hevoy will implement the listing editor changes from here, once they go through. Part of the benefit for increased Wikidata sync is that it's a way to share info across all language editions of WV. If you end up having any questions about the changes, please do let me know. ARR8 (talk) 01:35, 20 December 2018 (UTC)
@DL3222: I've implemented the color sample in my development version here. It gets the color for each type dynamically, by invoking Module:TypeToColor with an AJAX call, rather than having the colors predefined. You may want to take a look at it for your listing editor, if you're interested. Best, ARR8 (talk | contribs) 19:30, 21 December 2018 (UTC)
@ARR8:Thank for your feedback! We will sure implement the new editor changes once they go through. I think he-voy is the only edition that uses version 2.1 of the editor properly except the en=voy and de-voy. Thanks for implementing the color sample in your development version. However, it seems that it takes about a second for my computer to switch between colors when I'm changing the type of the listing. Is there a possibility to make it work faster?
About the auto-direcion text converting (LTR to RTL), I think it may be useful to en-voy for the alt field. For example, as you can see here, there are a lot of see listings that consist arabic or hebrew alternative name, and it seems a little bit strange and annoying for those who understand the languages when the text is LTR instead of RTL. Best Regards, DL3222 (talk) 21:26, 21 December 2018 (UTC)
@DL3222: Great! The color lookups are pretty quick for me; it should only take as long as refreshing the preview does. It may technically be possible to cache the results; I'll look into it.
If having RTL conversions is useful for contributors as you say, then I'll add it in to the alt field. ARR8 (talk | contribs) 05:25, 22 December 2018 (UTC)
  Done. Slightly more complicated than the original version, but has the benefit of dynamically getting colors and should be just as fast. Note to self: all that's left is to look at the clock picker, which will need some cooperation from the interface admins, and, overall, trying out the interface suggestions above and whatever Andree will suggest, and that should be it for implementation. ARR8 (talk | contribs) 07:41, 22 December 2018 (UTC)

Started discussion on Listing EditorEdit

Swept in from the pub

At Wikivoyage talk:Listing editor#New changes. Please take a look over there and reply.

To any admin: I've requested that the changes be linked to the Listing Editor Beta gadget, which is currently useless, prior to discussion, so that others could test the new editor without creating JS files. Hopefully this can be done; since the gadget currently doesn't do anything, I can't think of a reason not to do it. ARR8 (talk) 04:34, 24 November 2018 (UTC)

Listings editor again..Edit

Swept in from the pub

You can't put P inside BDI, otherwise you get document structuring issues, and LintErrors, the Listing template cannot cope with multi-line content unless it's been substantially updated since I last used it.

Can someone repair the Listings Editor so it doesn't generate "badly structured" HTML, which the contributor claims is the output from the Listings editor? ShakespeareFan00 (talk) 09:58, 27 November 2018 (UTC)

I do not really understand the problem. HTML makes a difference between two levels of elements: you cannot put a <div> in a paragraph, but have to use <span> instead – and you cannot have a paragraph in a paragraph. Our listings are formatted as paragraphs, so it is natural they cannot contain paragraphs. Newlines (<br>) in the "content" are a workaround that works most of the time. Where you really want several paragraphs, our style guide recommends a subsection instead of trying to shoehorn them into a listing. Are there some problems with those solutions? --LPfi (talk) 14:01, 28 November 2018 (UTC)
I know that, in the edit above the contributor concerned reverted my conversion of P tags to BR claiming that was the "editor default". Perhaps you can convince them just because it's the editor default doesn't make it the correct approach? ShakespeareFan00 (talk) 20:47, 28 November 2018 (UTC)
I said roughly the same thing here - User_talk:Ceever#P_breaks_in_listings... but the contributor hasn't yet responded to this. ShakespeareFan00 (talk) 20:49, 28 November 2018 (UTC)
So the editor treats a double newline as <P>? That should be fixed, yes. People entering <P> by hand probably understand the issue by your just telling about it (and with the "editor default" changed, there should be no conflict). --LPfi (talk) 11:56, 30 November 2018 (UTC)
I think it's that they are using the listing editor, which is generating <P> automatically, and not understanding why these where converted to <br /><br />, Perhaps you could explain it to them better than I could? ShakespeareFan00 (talk) 15:06, 30 November 2018 (UTC)
Unless they take the time to answer (or ask for more information) I suppose it is not worth trying to explain more than what we have written here. --LPfi (talk) 20:02, 30 November 2018 (UTC)
It's only entries they have which are now holding up mainspace being relatively free from LintErrors.. I am not going to attempt to fix talk pages as I lack the skill to handle that. ShakespeareFan00 (talk) 20:08, 30 November 2018 (UTC)
Hi @ShakespeareFan00: I've changed the default newline from
<br /><br />
in my userspace listing editor, per your request. I'm currently holding a discussion on changes to the listing editor over at Wikivoyage talk:Listing editor, which I mentioned above. This particular change is currently in my userspace, like I said, but it will be part of the ListingEditor Beta gadget, where many other changes already are, pretty soon. After a period of testing, it will hopefully be the new default, along with the rest of the changes made so far.
If you have any other suggestions for or thoughts on the listing editor, please post them there. This applies to everyone reading this. ARR8 (talk) 00:36, 4 December 2018 (UTC)

Listing Editor testingEdit

Swept in from the pub

It's occurred to me that I haven't actually announced here that the changes to the listing editor can be tested with the Listing Editor2 Beta gadget. So, the listing editor changes can be tested with the Listing Editor2 Beta gadget, in the WV preferences.

Feedback, especially complaints or inconveniences, would be critical now, because, unless anyone complains, in two weeks, I will request it to be set as the new sitewide default. Since I have implemented, in some form, everything that has been suggested to me for the editor, and some things that haven't, and have received no further feedback, that should mean that either the changes are perfect and no one would have any reason to oppose them, or they're not perfect and some people haven't looked at it it.

Since I'm not enough of an egotist to think my work is perfect, I'll put out another call here for people, in addition to the three of you who enabled the gadget, to test the changes and leave some feedback. Even a quick statement of "sure, looks fine" would be helpful for me to get a picture of whether people implicitly support the changes or just don't know about them. Thanks, ARR8 (talk) 21:17, 4 December 2018 (UTC)

@ARR8: Another bug/concern: take a look at this screenshot. Because of the formatting and the fact that there are no values on Wikidata, I think it's not obvious what the different radio buttons mean. —Granger (talk · contribs) 03:08, 2 February 2019 (UTC)
@Mx. Granger: Thanks for pointing this out. I've pushed a change that should make this clearer. ARR8 (talk | contribs) 19:45, 2 February 2019 (UTC)
@ARR8: Let me say, if I haven't already, that everything looks fine to me. Since generally it's all fairly similar in design, etc. to the original, with additions but really nothing removed, I would be standing in the way to oppose.
One thing I believe is new is the color that shows next to "type"; there is a minor design issue where if you select "listing", it barely fits into the space given to it. "Sleep" is similar. Otherwise, looks fine. --Comment by Selfie City (talk | contributions) 19:53, 2 February 2019 (UTC)
@SelfieCity: Thanks. That is indeed new, but I'm not too concerned about that, because you can read the type without the color in the dropdown box, so the selection is visible. ARR8 (talk | contribs) 19:58, 2 February 2019 (UTC)
Yes, as I said in the pub, I'm fine with the version going live, and this issue is a very minor one. If nothing was changed, it certainly would not be the end of the world. --Comment by Selfie City (talk | contributions) 20:12, 2 February 2019 (UTC)

Updating the listing editorEdit

Swept in from the pub

Hello all,

I have posted several times about the changes to the listing editor, discussed here and testable through the ListingEditor2 Beta gadget. There are several improvements, which are described at the link. However, the screenshot there is outdated, and I encourage everyone who hasn't seen the last iteration to try the gadget for themselves.

I have made several calls for feedback and have received many helpful comments. Many of the suggestions were implemented, though some are planned for future iterations, and every bug or problem pointed out has been fixed. Due to this, and wide discussion on many aspects of the changes, especially as they apply to other parts of the site, I am concluding that there is a consensus to implement the changes into the default listing editor for all users.

Is anyone opposed? Particularly, there are some new changes that may merit discussion. One change is that images in listings, when they match the image in Wikidata, are, upon sync by a contributor, removed from the source and left to auto-acquire. This is behavior I added relatively recently, due to instances when listing images were nominated for deletion and had to be replaced, while the ones on Wikidata were fine. It may also be of interest to some that I have reinstated the old behavior of putting }} on its own line, due to a discussion above.

Other than that, if nobody has any problems with the new editor, I will remove debug code and request that an interface administrator copy over the changes soon. ARR8 (talk | contribs) 00:26, 28 January 2019 (UTC)

I really don't yet know how it would look and work. Personally, I'd like to see a one-month trial period so I can see how it is. Probably, that would convince me to support it. --Comment by Selfie City (talk | contributions) 00:52, 28 January 2019 (UTC)
@SelfieCity: We have! The beta gadget was enabled and announced in the pub two months ago. I encourage you to try it now, if you haven't already. ARR8 (talk | contribs) 01:09, 28 January 2019 (UTC)
Which one is it? I'd really like to try it. (The only beta gadget I have enabled at the moment is called "visual editor differences".) --Comment by Selfie City (talk | contributions) 02:03, 28 January 2019 (UTC)
It's listed under "Gadgets," under "Experimental." ListingEditor2 (beta). ARR8 (talk | contribs) 02:49, 28 January 2019 (UTC)
I have just tried the beta ListingEditor2, and I got a "no data from wikidata" error when I tried it on Corgarff Castle in Ballater, but going back to the old listing editor worked ok.
It did work with another listing but there was a message about the directions differing from Wikidata - as directions are text, and depend on where you are starting from I don't see how they belong in WD - if we are going to have then there must be a link to a help page which defines what WD expect directions to be.
I am not keen on removing the images from listings. Unless there are full explanation popups this is going to confuse occasional users. If we are doing anything with the images, my preference would be for displaying a small thumbnail of the image (75px?). When it goes live we should have a one month trial period, because it will only be clear what the problems are when new users try it, unless a "conference room pilot" can be set up where 20 people are invited off the street to use it. AlasdairW (talk) 15:42, 28 January 2019 (UTC)
@AlasdairW: Thanks for the feedback.
  1. That's no error; it means the data is already up-to-date. I guess I should make the message clearer.
  2. Eh, I don't really see how they belong, either, but that's more a question for the Wikidata community. I've found it useful in some cases already. For most listings, unambiguously located in one location, the usage is pretty clear.
  3. It shouldn't be too confusing; when you sync the image it displays the name of the image in the field.
  4. Post-rollout, I'll be fixing problems new users report as they come up. ARR8 (talk | contribs) 17:30, 28 January 2019 (UTC)
By the way - no reason to switch back to the old one. The old behavior is still available as "quick fetch," and I won't be removing it, for editors who preferred it. ARR8 (talk | contribs) 17:37, 28 January 2019 (UTC)
@ARR8:, Thanks for the reply.
  1. Fine, maybe something like "No update required, listing matches Wikidata"
  2. As they are text, directions will be different in other languages. Also directions often assume a starting point - "10 miles north of the city centre" only makes sense if you know what city the listing is in. I think that in this case the pop-up should suggest that no change is the preferred option if you are unsure.
  3. The "images in listings ...are... removed from the source and left to auto-acquire" suggests that the image is removed from the listing and that the image box in the editor will become empty. Please explain if something different happens.
  4. Fine
Thanks for the hard word on this useful feature. AlasdairW (talk) 21:38, 28 January 2019 (UTC)
  1. I changed it after your first message to "No differences found between local and Wikidata values." The change hasn't been pushed to the beta yet, though.
  2. The directions property stores each language individually, so no need to worry there. See this item, which has directions in English, Portuguese, and Esperanto. Regarding instructions, I used to provide considerations for individual fields, but was advised to shorten the text, because people might not read it. I guess not uploading that text for listings accessible from multiple destinations is common sense. If you think it's very important to have instructions per field, I can probably find a way to put it in a tooltip.
  3. They are removed from the wikicode, but the filename stays in the editor, grayed out, until the changes are submitted. Try it yourself: modify the text in the image field for any listing which has a wikidata image and sync the values; you'll see what I mean.
And thank you for thinking about usability. ARR8 (talk | contribs) 00:30, 29 January 2019 (UTC)
Is it fair to assume that "one-month trial" in these comments means "Let's turn it on now, and in a month (or later), we'll talk about whether we think we should turn it off again"? WhatamIdoing (talk) 18:49, 28 January 2019 (UTC)
Yes, but we also stop at any point within the month if significant problems are reported. AlasdairW (talk) 19:27, 28 January 2019 (UTC)
Could easily be rolled back if there are any signifiant problems. Shall I make it live then? -- WOSlinker (talk) 09:58, 2 February 2019 (UTC)
@WOSlinker: Yes, let's! I won't take the debug code out quite yet; if there are any problems, I may ask for console logs. It can be taken out later. Also, please copy over the userspace version; I've changed a minor aspect of the table appearance over there by request. Glad to be wrapping this up (hopefully). ARR8 (talk | contribs) 19:51, 2 February 2019 (UTC)
I'm good with it going live now. --Comment by Selfie City (talk | contributions) 19:54, 2 February 2019 (UTC)
The updated version is now live. -- WOSlinker (talk) 20:09, 2 February 2019 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────When I look in the "Gadgets" section, though, it still shows up as "Experimental". Does it perhaps take a while to update? --Comment by Selfie City (talk | contributions) 20:13, 2 February 2019 (UTC)

@SelfieCity: It's been copied in place of the other one, so the experimental and non-experimental versions are currently identical. You can switch to whichever one you want. If there are to be more changes, they would be tested as part of the experimental one first. It's up to every editor whether they'd want to test those changes if and when they come. ARR8 (talk | contribs) 21:08, 2 February 2019 (UTC)
Thanks for the information! I plan now to switch to the non-experimental version. --Comment by Selfie City (talk | contributions) 21:48, 2 February 2019 (UTC)

Not working correctlyEdit

@WOSlinker:, @ARR8: currently the tool is not picking up Wikipedia page name when retrieving information from Wikidata. --Traveler100 (talk) 07:25, 25 May 2019 (UTC)

@Traveler100: This is intentional, and something I just changed. The Wikipedia link is auto-acquired in the listing template, and no longer necessary to specify. When syncing, a message appears saying "wikipedia synchronized." I'll work on making this more apparent; any suggestions? ARR8 (talk | contribs) 14:54, 25 May 2019 (UTC)
Depends... the feature is still not useful for exported GPX etc., because there the auto-generated stuff isn't "used". -- 05:30, 26 May 2019 (UTC)
True in the case of coords, but it doesn't seem the Wikipedia field is used in the GPX output either way.
In any case, the code generating the GPX files could be modified to get Wikidata values when needed. ARR8 (talk | contribs) 05:49, 26 May 2019 (UTC)
cannot say I like the idea. First on edit of a listing it looks like no data is available people will think need to fill it in again. But I also do not like the idea of the information not being in the source of the article. I think the information should be there as bots checking wiki source will not see that this data is available. Also the case when editing source in basic mode. --Traveler100 (talk) 06:44, 26 May 2019 (UTC)
We already do this for |image= because of the various upsides. The upside here is that doing this protects us from having an outdated link due to page movies/merges/deletions. I think we should have the same approach; if remotely syncing a field causes problems, we should fix those. I'm working on the first; currently, running a sync will show the remote value of the Wikipedia link on the field. For the second, we could have the listing editor hide the Wikipedia field in source, like we do for the fax field, so people aren't tempted to fill it in. Regarding bots, there is an automated way to see if the Wikipedia link is being remotely fetched: in the page information on the sidebar, it can be seen which Wikidata items are using sitelinks, and this information is available with the API. ARR8 (talk | contribs) 14:21, 26 May 2019 (UTC)

Listing editor showing currencies instead of contentEdit

Swept in from the pub
  1. Go to Wakayama#By_bus
  2. Click "edit" on the Willer Express listing
  3. Observe that the content is "USD EUR GBP AUD CAD CHF KRW", instead of the content you would see by editing the source.

Reproduced everytime on Firefox 68.0.1 Ubuntu. Thanks! Syced (talk) 11:09, 18 August 2019 (UTC)

Syced, could you confirm if the issue still occurs or not? --Andyrom75 (talk) 07:04, 28 July 2020 (UTC)
Andyrom75: It is working fine now, thanks :-) Syced (talk) 08:02, 28 July 2020 (UTC)

ID "(no element found)" is unknown to the system.Edit

Swept in from the pub

The relatively new OV-chipkaart article is generating the following message in bold red letters:

The ID "(no element found)" is unknown to the system. Please use a valid entity ID.

Clicking on the message provides the messages "script error" and "No further details are available." The problem occurs for both IE and Chrome browsers. Removing the page banner tag causes the message to disappear. No other page having a banner seems to have this problem. I think this problem arose a few days after adding a banner. Would anyone have a solution? Thanks. TheTrolleyPole (talk) 21:12, 29 October 2019 (UTC)

I saw this on another article earlier. @WOSlinker: I have undone the update of {{pagebanner}} from yesterday until the source of the error is identified. --Traveler100 (talk) 22:00, 29 October 2019 (UTC)
@Andyrom75: can you explain what CountryData is intended to do? I think the error is because the code assumes the article has a wikidata record, that is not always the case. (I have now added OV-chipkaart to wikidata, but you can still see the error in newly created articles). I cannot find anywhere explanation of an edit that changes every mainpage article. --Traveler100 (talk) 22:15, 29 October 2019 (UTC)
@Traveler100: is for a new release of Listing Editor currently in beta version of both en:voy and it:voy. When available, it stores data inside the page that will be used afterwards. I thought to have already manage the case of new page, but I'll check again. --Andyrom75 (talk) 23:21, 29 October 2019 (UTC)
Thanks. The problem has now gone away. TheTrolleyPole (talk) 23:44, 29 October 2019 (UTC)
@Andyrom75: thanks for the explanation. An interesting idea, look forward to seeing the improvements. --Traveler100 (talk) 06:02, 30 October 2019 (UTC)
@Traveler100:, @WOSlinker:, please apply this patch to Module:Wikibase and restore Template:CountryData2HTML in Template:Pagebanner.
As said is something that I've already managed in it:voy but I forgot to tell WOSlinker to update this module here as well. Sorry for the inconvenience. --Andyrom75 (talk) 07:07, 30 October 2019 (UTC)
@Traveler100:, @WOSlinker:, I've just changed approach and I don't need Module:Wikibasea anymore, so you can directly revert the last change in Template:Pagebanner. Thanks, --Andyrom75 (talk) 22:49, 30 October 2019 (UTC)

Listing Editor 2.4Edit

Swept in from the pub

I've just updated the Listing Editor Beta (that can be found in the Gadgets tab of the personal Preferences) with the latest version of the script that is already available for any user in it:voy.

All the changes can be found in Wikivoyage:Listing_editor#v2.4 Changes (see the script for technical details).

I've adapted it for en:voy and I've already personally tested the script, but before injecting the code in Listing Editor (the main version not the beta) for any user, I would prefer to have a broader test/feedback.

Since I'll be away for the whole August, any feedback before the end of the month would be highly appreciated. --Andyrom75 (talk) 08:04, 24 July 2020 (UTC)

Looks good. Only spotted one small issue. The "localizza su geomap" text could do with updating. -- WOSlinker (talk) 10:44, 24 July 2020 (UTC)
Thanks! Just fixed. --Andyrom75 (talk) 12:04, 24 July 2020 (UTC)
Since no other issue has been spotted, I've implemented the v2.4 for all users. In this way I'll be available for few more days before leaving, in case of need. --Andyrom75 (talk) 05:19, 28 July 2020 (UTC)
@Andyrom75: Thank you and buon viaggio. Going anywhere nice? --ThunderingTyphoons! (talk) 09:38, 28 July 2020 (UTC)
Thanks @ThunderingTyphoons!: :-) I'll roam "conscientiously" around the Schengen Area visiting some of the Countries I've never been before :-) --Andyrom75 (talk) 17:46, 28 July 2020 (UTC)

Listing formatEdit

Swept in from the pub

Working on Listing Editor v2.4 I've noticed that here in en:voy has been changed the listing format from the original format:

* {{see
| name= | alt= | url= | email=

into this format

* {{listing | type=see
| name= | alt= | url= | email=

Personally I've found a 2017 bug record on Wikivoyage:Listing editor#Bugs and feedback that maybe has originated this change, but that bug it's not anymore present. It can be tested on the first listing of Cleveland#By plane.

@Wrh2: highlighted me a Decembre 5th conversation in Wikivoyage talk:Listing editor#New changes between @ARR8: and @Mx. Granger: where they briefly discussed about it. ARR8, unfortunately miss from en:voy since 1 year ago, and since March 2020 from any wiki, so I don't know if he can provide further background information.

From my point of view the only benefit I see is to create potentially an endless series of listings without creating the relevant templates, because type is just a parameter, but since the set of listing is almost constant over the time, I think that this advantage do not compensate this more "verbose title".

Which is the preferred approach that the en:voy would like to follow?

Furthermore another note. I've noticed that the buttons on top of the standard editor pages (e.g.  ) generate the following listing code:

* {{listing | type=see
| name= | alt= | url= | email=
| address= | lat= | long= | directions=
| phone= | tollfree=
| hours= | price=
| wikipedia= | wikidata=
| lastedit=2020-07-29
| content=

I strongly discourage to propose the "wikipedia" parameter because it expose the listing to have an inconsistent link to Wikipedia when the page is move without any redirect in Wikipedia itself. This information should be obtained transparently providing the "wikidata" parameter. That's the way the Listing Editor works during sync phase (i.e. deleting "wikipedia" and "image" information from the listing). Note that when also "wikidata" is present, a category can find and list these errors, but when is missing only a bot can find and list them.

Also in this case let me know which is the desired approach. --Andyrom75 (talk) 07:17, 29 July 2020 (UTC)

I think I understand your reason for excluding the Wikipedia and Image parameters from the generated template, but does that also result in the corresponding fields vanishing from the listing editor? It's not a huge thing, but it does require an extra step or two of edits if the Wikipedia article is incorrect or the image hosted on Wikidata is not suitable for Wikivoyage, or if there isn't an image hosted on Wikidata at all. There is also the occasion (not that often, but it happens) where there is no Wikidata item, but there is a Wikipedia article.--ThunderingTyphoons! (talk) 12:31, 29 July 2020 (UTC)
ThunderingTyphoons!, the modification of the template will not affect anything else so all the mechanism will remain unchanged. For example, any editor will be still free to add it manually overriding the value stored in Wikidata (although is possibile, generally is not a good approach, but in few cases it could make sense), and also listing editor will still have the wikipedia field that can be sync with Wikidata or manually customized.
Think about the image parameter; it's not currently present in the generated template but everything works.
Regarding the existence of a Wikipedia page without a Wikidata instance, well, this is an error that should be corrected creating a new Wikidata instance or connecting it to the right existing one. Take a look at this en:voy special page that tracks all the en:voy articles that have the same issue.
I hope it clarify your doubts. --Andyrom75 (talk) 12:47, 29 July 2020 (UTC)
Yes, it does. Thank you :-) --ThunderingTyphoons! (talk) 16:20, 29 July 2020 (UTC)
Since today is my last day in front of a laptop, I've applied the above two changes but in case the community would decide differently is enough to rollback the followings:
PS I should be still available for chat but not for programming. --Andyrom75 (talk) 11:51, 30 July 2020 (UTC)
What about markers including links to Wikipedia? Do you think we should keep the marker template as-is, or make the same change we made to the listing template? --Comment by Selfie City (talk | contributions) 12:06, 30 July 2020 (UTC)
I suppose it is not too uncommon that there is a Wikipedia article that touches the subject while the Wikidata item is more precise but lacks article in English. How should one handle that situation? --LPfi (talk) 14:22, 30 July 2020 (UTC)
(edit conflict)SelfieCity, as far as I recall, Template:marker has born this way. No "type" means generic listing, while when "type" is present, the nature of the listing is changed accordingly.
Without a "good idea" or a real need I would leave it as it is. Using the same template (e.g. {{marker|type=city| -> {{marker|city|) we would get a neglectable benefit, and changing template or (e.g. {{marker|type=city ->{{city) we would force editor to learn & use a new one.
Maybe (I repeat maybe), if it's easy to recognize if a toponym is a city (or village, town, metropolis, etc.) we could avoid to specify the type parameter at all, but this would require an analysis of Wikidata and to build an easy tool to put anyone in the condition to fix the hopefully few cases where this specification is missing, without relying only on Wikidata expert. --Andyrom75 (talk) 14:32, 30 July 2020 (UTC)
Thanks for the explanation, but I'm speaking specifically of links to Wikidata, not how the template itself functions. --Comment by Selfie City (talk | contributions) 14:34, 30 July 2020 (UTC)
SelfieCity, sorry, my fault. Are you talking of showing the Wikipedia link when the Wikivoyage article is missing? In the affirmative case I think is a good and useful idea, because readers can find information within "Wiki-world" and editors can find a first source of information to develop a Wikivoyage article. Showing Wikipedia link, is only possible if it's present a Wikidata parameter, that for sure is an optional parameter.
LPfi, as anticipated, if you want to specify a different Wikipedia article you can anytime, nothing from this point of view has changed. Changing the preset template is just a "mental approach", that suggest to provide Wikidata instance instead of Wikipedia article. I don't if I've answered to your doubt. --Andyrom75 (talk) 14:48, 30 July 2020 (UTC)
No, any explanation regarding this is helpful. If we're agreed that using WP links in markers is good, then that's all I'm really concerned about. --Comment by Selfie City (talk | contributions) 14:49, 30 July 2020 (UTC)
Yes, I understand. I suppose we think that those who are able to make a judgement call on using a WP article different from that of the WD item also know how to do it manually. I have no problem with that. --LPfi (talk) 10:29, 31 July 2020 (UTC)

@Andyrom75: There seems to be a bug – see this edit, which I made with the listing editor and which changed Template:listing to the nonexistent Template:purple. —Granger (talk · contribs) 13:52, 28 August 2020 (UTC)

I prefer the listing|type format as it is easier to fit new types into this as needed and probably it is easier to maintain one template than several... Hobbitschuster (talk) 15:09, 28 August 2020 (UTC)

Granger, I've just got back from holiday. Please give me few more days to fix it. In these very first days I need to get back on track with my job :-P --Andyrom75 (talk) 21:44, 30 August 2020 (UTC)
Sure, no rush. Thanks for helping with this! —Granger (talk · contribs) 06:34, 31 August 2020 (UTC)
Granger, I've just applied the patch. Once the previous cached script will be replaced by the new one (within few minutes I suppose) you can try to update a couple of listings (customized and standard). Please let me know if now everything works or not. Thanks, --Andyrom75 (talk) 17:43, 1 September 2020 (UTC)
@Andyrom75: I just tried [6] Looks like it still doesn't work, unfortunately. Should I wait longer and try again? —Granger (talk · contribs) 18:36, 1 September 2020 (UTC)
Granger, initially I've updated only the main Listing Editor, now I've aligned also the beta version. Could you confirm me that you are using the main one (see your preferences)? In few minutes also the beta one will behave in the same way, but the main one should already work. In any case, try again :-) --Andyrom75 (talk) 18:57, 1 September 2020 (UTC)
You're right, I was using the beta version. I've switched to the main one, and it seems to be working. Thanks! —Granger (talk · contribs) 19:07, 1 September 2020 (UTC)
Granger, good! In any case, now both main and beta versions are working. Feel free to test it. Thanks for your testing time :-) --Andyrom75 (talk) 19:10, 1 September 2020 (UTC)

<br/> instead of <br/><br/>Edit

@Andyrom75: Was this discussed before? Unfortunately, <br/> twice makes the text of the following paragraph look like it does not belong to the listing anymore and nowhere else in the article are gaps generally that large. Cheers Ceever (talk) 14:06, 13 September 2020 (UTC)

Ceever, could you show me an example (i.e. a permalink) to understand better the issue? PS I've seen that something similar has been discussed above. --Andyrom75 (talk) 14:20, 13 September 2020 (UTC)
Ups, sorry, my explanation was more than tight. :-D If you insert a break (by hitting ENTER) in the content field of the listing editor, it actually adds <br/><br/>. This can be seen when going into the Source Editor afterwards. However, this <br/><br/> is breaking structure and readability. Cheers Ceever (talk) 14:35, 13 September 2020 (UTC)
Ceever, no problem, the important is to understand each other before the end of the discussion :-)
Coming back to the point, I've noticed time ago that in en:voy has been decided to add this rule (new line->BR tag or two I have no idea). This is something not used in it:voy. We use another a different approach (we use ":" before each new line) but since it has other downsides I've never proposed here.
Time by time, I try to find the solution that will reach the following goals:
  1. no lint error generation
  2. use the same wikicode inside listing editor and inside standard editor
  3. no use of HTML
  4. show the content with the correct indentation based on where the listing is used (in a bulleted/numbered list or inline)
but actually I never found any solution :-( ...I'm trying right now again, but I'm not optimistic... --Andyrom75 (talk) 15:06, 13 September 2020 (UTC)
Aaahhh, I didn't know there were issues. Otherwise, I can just stick with correcting it manually. But if you come up with something, I am open to hear it. Cheers Ceever (talk) 15:42, 13 September 2020 (UTC)
FYI 3 years ago I've opened a ticket on Phabricator hoping to solve this issue on server side but I got zero replies. I've just inserted a new comment hoping that someone would be interested on working on it. If other from en:voy would be interested on adding more comments to this ticket maybe the priority would increase. --Andyrom75 (talk) 15:49, 13 September 2020 (UTC)
Many thanks. Could it be a temporary fix to fire a replace of <br/><br/> by <br/> after the update by the Listing editor? Cheers Ceever (talk) 17:20, 13 September 2020 (UTC)
Ceever, just to avoid misunderstanding, I've created two listings with few lines separated by 1 and 2 BR tags. Before apply any change, could you tell me what do you mean exactly with "look like it does not belong to the listing anymore"?
  • Listing 1. Line1: text, text, text, text, text, text, text, text
    Line2: text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text

    Line3: text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text
    Line4: text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text

    Line5: text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text.
  • Listing 2. Line1: text, text, text, text, text, text, text, text
    Line2: text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text

    Line3: text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text
    Line4: text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text

    Line5: text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text.
PS When you reply, ping me ;-) --Andyrom75 (talk) 21:34, 15 September 2020 (UTC)
@Andyrom75: I believe they are the same listing, they look the same, and both content fields contain the same text, right? Was this intended. The double breaks just create an amount of space that is larger than anz other space, e.g. between two listings itself or between paragraphs. See gfx: Cheers Ceever (talk) 20:52, 17 September 2020 (UTC)
Ceever, so if I understand correctly it’s not a matter that the text seems to be “outside” the listing but just because it’s anti aesthetic, right? --Andyrom75 (talk) 16:28, 18 September 2020 (UTC)
@Andyrom75: Well, this is actually the point, "the text seems 'outside' the listing" ... when reading the article. This is inconsistent to the rest of the article, meaning in a way it is not adherent to the manual of style. 🤷‍♂️ Cheers Ceever (talk) 05:33, 19 September 2020 (UTC)
Done. In few minutes the script will be ready for any user. Please test it and let me know if now it's better. --Andyrom75 (talk) 11:39, 19 September 2020 (UTC)
@Andyrom75: Works very well ... 👍 Many Thanks Ceever (talk) 16:45, 21 September 2020 (UTC)

Bug: Name not fetched from WD label when enwiki is missingEdit

Hi, I suggest we fill the name with the en:label from WD if it is empty. I get an error for e.g. Q96463309 saying "Please enter a name or adress", but the item already has an en:label. I tested adding a name-property but that did not help, so this is a bug IMO. WDYT?--So9q (talk) 17:34, 23 September 2020 (UTC)

I took a look at he code and it seems we already do use the label somehow, not sure why I get the annoying alertbox then. I'm using the palemoon browser:

	// parse the wikidata display label from the wikidata response
		var _wikidataLabel = function(jsonObj, value) {
			var entityObj = _wikidataEntity(jsonObj, value);
			if (!entityObj || !entityObj.labels || !entityObj.labels.en) {
				return null;
			return entityObj.labels.en.value;

--So9q (talk) 18:11, 23 September 2020 (UTC)

If I understand correctly, you're suggesting that the listing editor should allow users to import the name of the POI from Wikidata when they click the "Sync shared fields to/from Wikidata" link. Is that right? —Granger (talk · contribs) 18:23, 23 September 2020 (UTC)
Return to the project page "Listing editor".