Wikivoyage talk:Listing editor/Archive 2013-2017

Mockup

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 (talk • contribs)

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 Editor

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 editor

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

importScript('User:Torty3/editor.js');

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 . 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 deployment

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 editor

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 , 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 editor

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 :

importScript('User:Torty3/editor.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 map

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 Remove

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 save

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. Frank^email_talk 21:35, 11 October 2013 (UTC)

Getting cursor back in price field after clicking currency symbol

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 (talk • contribs)

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). --118.93.47.31 02:06, 29 October 2013 (UTC)

CAPTCHA broken for IP's

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... --118.93.67.66 20:26, 3 November 2013 (UTC) 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...) --118.93.67.66 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 en.wiki, 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. 89.241.174.168 23:53, 26 July 2015 (UTC)

Add Listing strangeness

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 Conflict

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 bugzilla.wikimedia.org & 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 Mediawiki.org. -- 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)

Fixes

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 listing

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 (talk • contribs) 05:09, 24 March 2014‎ (UTC)

@Unknown user **: This error occurs when URL could not be detected correctly . 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}} templates

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? 89.241.174.168 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 bug

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?

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 handling

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 button

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: punctuation

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 parsing

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 limits

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 archive

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)

• When content of listing contains a {{Marker}}, the Listing editor improperly inserts elements of the Marker template into its editing fields. For an example, see User:Peter Chastain/Testcase/MarkerInListing. Peter Chastain (talk) 21:34, 28 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' comment

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 listing

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
etc.

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

|Image:filename.jpg

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 parameter

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 Wikidata

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 lookup

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 www.trumptaj.com at (39.3587, -74.4198)? K7L (talk) 17:23, 4 August 2016 (UTC)

Example tollfree number

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 editor

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 improvements

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 support

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)

Responses:

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 requested

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 languages

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)❤T☮C☺M☯ 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)❤T☮C☺M☯ 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)❤T☮C☺M☯ 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)