What about coordinates? these should be displayed, and link to link Special:Mapsources, thus:

• Doxey Marshes (52.816, 2.137 ), ...

an emit a Geo microformat (see source code of the above example). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 19 November 2012 (UTC)Reply

The external link in the listing's name is a bug in the current extension, known as "frontlinking". Our current external links policy advocates "Doxey Marshes " and not "Doxey Marshes". The geohack link should likely instead be a wikilink to Special:Mapsources/52.816N,2.137W,scale=2000. The current listings extension has fields for lat= and long= but they're not currently in use. K7L (talk) 15:43, 19 November 2012 (UTC)Reply

That's just an illustrative example. The key point here is the display of the coordinates. That said, a link like "" has poorer accessibility than "Doxey Marshes". I've proposed elsewhere that we share geohack rather than maintaining a separate service. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:57, 19 November 2012 (UTC)Reply

I notice some changes have been made, including the use of a globe icon for coordinates. We should display the coordinates as text; and they should be available on printed copies of our entries. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:04, 2 January 2013 (UTC)Reply

I don't agree that all printed copies should contain the coordinates. I think they're only useful in a limited set of circumstances, while they can be confusing and cluttering to people who don't need them. LtPowers (talk) 20:23, 3 January 2013 (UTC)Reply

What about a Wikipedia link? We could put this after the subject:

• Doxey Marshes (52.816, 2.137 ), Wikipedia:Doxey Marshes ...

or we could link the subject name, and follow that with the URL, displayed in full view:

• Doxey Marshes (52.816, 2.137 ), URL: http://www.staffs-wildlife.org.uk/page/doxey-marshes , ...

Thoughts? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 19 November 2012 (UTC)Reply

It may be useful, just so long as a link to WP doesn't become a substitute for including the most basic of info in the article itself. K7L (talk) 15:43, 19 November 2012 (UTC)Reply

Agreed but I don't see any reason why it should; and if there is a case where it does, it provides a quick link to a source, and citations of other sources. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:03, 19 November 2012 (UTC)Reply

There are four fields in the listings extension which aren't documented in the blurb displayed under the edit box: tollfree, lat, long and tag. The tag is unused, lat/long were intended for co-ordinates (but are not yet active), tollfree is in active use in many listings to indicate a second telephone number for a listing. Usually these are numbers which only work in-region, but which may be dialled from a 'phone booth or a landline at no cost (an outbound mobile call still incurs airtime charges, though). Because their availability for international calls is hit-and-miss at best, we usually list both this and the standard number. K7L (talk) 15:43, 19 November 2012 (UTC)Reply

We should also have a 'textphone' parameter for services for people who have a hearing or speech disability. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:59, 19 November 2012 (UTC)Reply

I'd suspect that very few places with listings provide direct TTY/TDD connections and publish the numbers. Most do, however, provide an Internet presence at some varying level of accessibility - which we already list (even though printing e-mail addresses just feeds them to spammers). K7L (talk) 16:10, 19 November 2012 (UTC)Reply

TDD numbers are quite common around my area -- or were, until recently at least. LtPowers (talk) 20:12, 25 November 2012 (UTC)Reply

This site has one but it's the same as their main number. K7L (talk) 20:19, 25 November 2012 (UTC)Reply

Is there a need for |type= (eat, drink, see, do, buy, sleep) as a parameter? I realise we currently have tags under each of these names and all are merely aliases of <listing> - the PHP extension code doesn't even look at what tag was used. If we do generate .kml files from listings in the future, though, it might be good to give a hôtel a different icon from a museum or a restaurant (assuming the file format supports this). K7L (talk) 03:32, 26 November 2012 (UTC)Reply

Yes, almost certainly. Indeed, we may even decide that the format of the listing should change based on type. LtPowers (talk) 16:33, 26 November 2012 (UTC)Reply

I suppose the globe icon for the external link could be replaceable with something more specific:

• Get in
• Get around
• See
• Do
• Buy
• Eat
• Drink
• Sleep

One thing to watch with these... there are many specialised tourism icons (such as the comedy/tragedy masks for live theatre), so it may be best to allow an editor to directly select a specific icon type instead of simply "see" or "do". A vineyard might not get the same icon as a beer hall. K7L (talk) 18:56, 26 November 2012 (UTC)Reply

I'm not sure you'll find much support for rampant use of iconography. Our image policy explicitly requests that we keep the number of images to a minimum to remain as accessible as possible. LtPowers (talk) 19:32, 26 November 2012 (UTC)Reply

As noted elsewhere, that;s about file sizes and bandwidth. A few small, repeated and cacheable icons won't hurt accessibility. Indeed, used well, they may aid it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:29, 2 January 2013 (UTC)Reply

Monochrome icons may work best; we should check how the various options appear on monochrome printed pages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:31, 2 January 2013 (UTC)Reply

Wikipedia links must currently be entered as just the article title (so "example"; not "http://en.wikipedia.org/wiki/example", which renders as a link to "w:example". How will we deal with cases where there is, say a French article, but not an English one? Will entering "fr:example" work? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:27, 2 January 2013 (UTC)Reply

• [[w:exemple]] link to the another project, same language. (s=source, b=book, v=versity, w=pedia, wikt=tionary, n=news)
• [[fr:exemple]] link to the another language, same project. (de=deutch, es=spanish, ca=catalan)
• [[w:fr:exemple]] change the project and the language.

Crochet.david (talk) 21:47, 2 January 2013 (UTC)Reply

Currently "wp". Should we use "wikipedia" for clarity? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:34, 2 January 2013 (UTC)Reply

Should we include parameters for, say, a venue's official Twitter profile and Facebook page? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:48, 2 January 2013 (UTC)Reply

If a business has an official website URL, that site will already link to pages on Facebook or other external sites controlled by the same people. In most cases, the link adds little as the business will post the same self-promotional fluff on the external site as on their own site. I would link to Facebook if it were the only web presence for some small venue (usually a local restaurant) but then the link goes in the existing URL field. K7L (talk) 23:43, 2 January 2013 (UTC)Reply

Swept in from the pub

Tags like <br> don't usually convey information in the sense that <see> does here. I'm geninuely curious as to why <see> is being maintained when it seems more appropriate to use a template. (For the record, I've created an experimental template). --Member (talk) 02:26, 16 January 2013 (UTC)Reply

Custom code was used before. Users could click on an "add listing" link next to the "edit" link, and a pop-up would come up, in which they could fill in a name, address, pricing info, description, etc of a particular listing. Then they could press OK and the listing was added to the wiki. However, that function is not available anymore, and I think in the near future these will be converted to regular templates. See Wikivoyage talk:Listings for the discussion. Globe-trotter (talk) 02:42, 16 January 2013 (UTC)Reply

(edit conflict) There is a proposal for a template {{listing}} and a proposed patch bugzilla:43220 which would redirect mw:extension:listings output to a template. I believe these were originally tags as there used to be an "add a listing" button which used this; the German Wikivoyage has gone to a template vorlage:vCard but replacing these now would require a 'bot edit every page. K7L (talk) 02:47, 16 January 2013 (UTC)Reply

A switch over to templates is probably necessary to be compatible with the visual editor that is under development at the Foundation. (I'll pester someone on the VisualEditor team to weigh in.) —Tom Morris (talk) 02:45, 16 January 2013 (UTC)Reply

A move to templates is probably inevitable. Just need the right code, and the right timing. --Inas (talk) 03:12, 16 January 2013 (UTC)Reply

The VE doesn't require moving to templates, but it will probably mean you get to use it for these items sooner - see my comments on MediaWiki.org for a little more (as this is a general question not specific to Wikivoyage). Jdforrester (WMF) (talk) 20:05, 16 January 2013 (UTC)Reply

Swept in from the pub

When using the listing templates (for restaurants, attractions etc) there's an error with links; they don't not appear the way they should (i.e as ) but instead as the listing name becomes a link. It's a small bug but a bit annoying. Would be great if somebody could have a look into it! --Jonte-- (talk) 17:46, 17 January 2013 (UTC)Reply

Link doesn't work. However, in listings, the name is supposed to become the link. Example:

• <see name="Legoland Florida" alt="" address="1 Legoland Way" directions="Located off Cypress Gardens Blv. just east of Winter Haven" phone="" email="" fax="" url="http://florida.legoland.com/" hours="Hours vary throughout year." price="$65 (Ages 13-59), $55 (Ages 3-12, 60+)">The second Legoland park in the US in addition to Legoland in California. yada...yada </see>

Is that what you're referring to? AHeneen (talk) 18:14, 17 January 2013 (UTC)Reply

Ah, a small typo in the link I provided. But it was the format that I wanted to point at. Since the introduction of listing templates the formatting have been:

• Legoland Florida 1 Legoland Way (Located off Cypress Gardens Blv. just east of Winter Haven) . Hours vary throughout year.. $65 (Ages 13-59), $55 (Ages 3-12, 60+). The second Legoland park in the US in addition to Legoland in California. yada...yada

See example on WT here: . This is in line on how all other links are displayed. --Jonte-- (talk) 18:26, 17 January 2013 (UTC)Reply

That is a known bug, bugzilla:43220, for which a fix has been proposed but not yet deployed. That fix, once enabled, will give:

• Legoland Florida, 1 Legoland Way (Located off Cypress Gardens Blv. just east of Winter Haven). Hours vary throughout year. The second Legoland park in the US in addition to Legoland in California. yada...yada $65 (Ages 13-59), $55 (Ages 3-12, 60+). 

It might be a good idea to look at {{listing}} to verify it matches the desired format while it's still an unprotected experimental template which can be changed without affecting much of anything. I presume the globe icon for the URL should change to either the old '[1]' style external link or to an icon without any distracting colo(u)rs. K7L (talk) 20:47, 17 January 2013 (UTC)Reply

Swept in from the pub

It would appear, with today's upgrade to MediaWiki 1.21wmf9, that we should be able to change the manner in which the individual listings are displayed by directing mw:extension:listings to a template like {{listing}}. That could get rid of the front-linking of external URL's in our individual listings, something which has been an annoyance for a few months now.

MediaWiki:listings-template needs to be created and set to the base name of a template (ie: "listing" for the {{listing}} template). See bugzilla:43220. K7L (talk) 00:01, 7 February 2013 (UTC)Reply

I tried this on Russian Wikivoyage, and it worked quite well. Have you tested the new {{listing}} template here on :en? I can create the MediaWiki page, but I may not have time to resolve bugs and problems... at least not until today's evening (European time). --Alexander (talk) 07:08, 7 February 2013 (UTC)Reply

Now I did it, and it seems to work quite well. What next? --Alexander (talk) 14:10, 7 February 2013 (UTC)Reply

Some things are good about this new template now being non-experimental and activated. The fact that "lat" and "long" now do something useful after so many years is great. (I have reservations about hiding the co-ordinates under a cutesy symbol. The geo data is actually usually more compact than an e-mail address and even more likely to be needed when only a printed hard copy is available - when, I presume, the needed co-ordinates won't show?

I would prefer to return to the old format where those listings with a primary url displayed the listing title in blue as a clear signal that the title itself is a hyperlink. Now businesses have a perverse incentive not to use XML listings since that way they get to retain an obviously clickable blue symbol and the (baffling) incremental number (rather than get the puzzling and non intuitive grey globe). The old method of display is both shorter and more intuitive. -- Alice^✉ 04:04, 8 February 2013 (UTC)

Displaying "the listing title in blue as a clear signal that the title itself is a hyperlink" to an external site is called frontlinking here and is/was a bug. Wikivoyage talk:Listings#Frontlinks post-import is a clear consensus that these aren't wanted as a matter of policy. K7L (talk) 04:14, 8 February 2013 (UTC)Reply

Frankly, I think both the old version and the new have problems. The old had an obvious blue link, which was nice, but it was numbered, which was weird. The new gray globe, while I like the fact that it is an icon, is really faint and not very intuitive. What if we used the little arrow icon you see after a link? PerryPlanet (talk) 17:21, 8 February 2013 (UTC)Reply

The template adds a comma and space after every name, followed by a period, even when there is nothing in the address, phone, url, etc. fields. Thus a very basic listing with only name and description looks like this:

• <see name="Tiny volcano" alt="" address="" directions="" phone="" email="" fax="" url="" hours="" price="">You'll have to lean in close to see it, but don't get too close!</see>

See Churchill#See for some examples. --Peter ^Talk 04:47, 8 February 2013 (UTC)Reply

I think it's assuming that there is at least a name and an address. Leaving the others blank should be fine.

* <see name="Huge volcano" alt="" address="Montserrat" directions="" phone="" email="" fax="" url="" hours="" price="">Maybe it just looks big because [[Montserrat]] is so tiny!</see>

• <see name="Huge volcano" alt="" address="Montserrat" directions="" phone="" email="" fax="" url="" hours="" price="">Maybe it just looks big because Montserrat is so tiny!</see>

Might be worth looking at the address field in the template if that's a field you want to make optional? K7L (talk) 04:55, 8 February 2013 (UTC)Reply

I think ideally everything should be optional, to leave this as flexible as an editor might want. MV Ithaca, for example, is a ruined boat in tidal flats on the edge of tundra. There's no road, there's no one there, and directions don't make sense—coordinates and its plotting on the map are the only useful details to include. --Peter ^Talk 05:04, 8 February 2013 (UTC)Reply

By "everything optional", would that include no name, ie: * <see name="" alt="" address="10 Downing Street" directions="" phone="" email="" fax="" url="" hours="" price="">A famous London address which needs no name.</see> That much is still broken, although I did check for no address. K7L (talk) 05:23, 8 February 2013 (UTC)Reply

The thing is, "10 Downing Street" is both the name and the address. For the purposes of tagging and metadata, it would be nice to include both properties, but maybe have a special way of hiding them. For instance, {{listing |name= 10 Downing Street |address= 10 Downing Street |addressdisplay= none |A famous [[London]] address which needs no name.}}
might give

• 10 Downing Street. A famous London address which needs no name.

but would include the address as hidden text for microformatting. Bigpeteb (talk) 19:35, 12 April 2013 (UTC)Reply

Is there any chance we could get the listings template to suppress the comma + space when the name field is empty? I found an example in the wild (naturally, a kind of weird example that I wrote). Not necessarily a super high priority, but it would be nice to have the extra flexibility. A way of hiding display as Bigpeteb suggests would also do the trick. --Peter ^Talk 20:52, 25 May 2013 (UTC)Reply

I probably shouldn't say this, since I've done similar things (Rochester (New York)#Budget), but we should think carefully about the semantics of a nameless listing. Part of the reason for using listings templates (as opposed to hand-coding them) is to make them machine-readable. (The benefits of doing so are illustrated by the nascent dynamic map implementations.) Without anything in the name field, parsers will be left unsure how to handle the listing. Is there any way you can re-word it without losing the snappiness of the prose? LtPowers (talk) 02:26, 26 May 2013 (UTC)Reply

Sorry, but the icons are really bad. I think we should switch back to plain text until we can find/get some decent icons. This, that and the other (talk) 06:14, 8 February 2013 (UTC)Reply

Yes, it looks terrible. The old WT-format was fine. Globe-trotter (talk) 17:24, 8 February 2013 (UTC)Reply

This same discussion is occurring in several places, so please see Wikivoyage talk:Listings#backward step, which appears to be the most active discussion. -- Ryan • (talk) • 17:27, 8 February 2013 (UTC)Reply

At present we have:

name, url-icon address

and

name (alt-name), url-icon address.

I think these should be:

name url-icon, address

and

name (alt-name) url-icon, address.

I think the bit of code:

#if:{{{address|}}}|,

should be moved from the end of the Name section of code to the end of the URL section of code. Nurg (talk) 02:43, 10 February 2013 (UTC)Reply

Assuming that you write what I suspect you actually meant to write by way of examples, I agree that if we are going to have our own icon (rather than use the universal convention of having the name itself as a clickable hypertext anchor) then your order is by far the better way of deviating form world wide web norms. -- Alice^✉ 03:06, 10 February 2013 (UTC)

I think we should have a space following the colon in "toll-free:" because:

1. It is conventional English.
2. We have a space following "fax:" and following the phone symbol.
3. We had a following space for tollfree until this edit, where it was removed in what I took to be an error (no mention was made of the space in the edit summary). Nurg (talk) 06:30, 12 February 2013 (UTC)Reply

I understood that we were trying to make listings as compact as humanly possible without reducing legibility or comprehension too much.

I agree that all 3 should be the same - ie all with, or all without. Personally I favour the latter, but it's obviously a judgement call and yours is usually sound, Nurg.

PS: I assume that I was the guilty party with this edit...] -- Alice^✉ 08:37, 12 February 2013 (UTC)

I think that the best choice would be the space after the colon for all three options. It's the same as many other punctuation symbols, which are pretty much all followed/preceded by a space. JamesA ^>talk 08:46, 12 February 2013 (UTC)Reply

Done. Nurg (talk) 23:19, 22 February 2013 (UTC)Reply

If you put directions into a listing without an address:

<listing name="Some place" directions="directions to that place"></listing>

the directions do not appear. At Crowden-in-Longdendale#See and Edale#Drink I wanted to do this, but found I had to add an address attribute before the directions would appear. What I expected was:

Some place (directions to that place)

Is this deliberate, or could the template be changed to allow directions where there is no address? In many countryside, mountain or wilderness contexts, where destinations may not have formal addresses, I can see this being a fairly common situation. Dave.Dunford (talk) 09:48, 12 February 2013 (UTC)Reply

Seems to have been fixed now. Thanks to User:K7L. Dave.Dunford (talk) 09:45, 13 February 2013 (UTC)Reply

On the Pub, Alice seemed adamant that we should not link email addresses using the mailto: protocol, but I can't fathom why. Copying and pasting is often tricky, especially on mobile devices; why make it harder on our readers? LtPowers (talk) 03:55, 17 February 2013 (UTC)Reply

To make it easier on the vast majority - including those using mobile devices not using Mickysoft progamming. -- Alice^✉ 05:15, 17 February 2013 (UTC)

I think Wikivoyage talk:Listings#Not helping e-mail spammers covers the same subject. -- Ryan • (talk) • 04:17, 17 February 2013 (UTC)Reply

No, that's a completely different topic, Ryan.

At the pub topic section of "Problems with new XML listings format I blew my top and stated: "...The real fuck-up though is that both the latter two are hotlinked to the "mailto:" call which was strongly deprecated in this discussion:Wikivoyage_talk:Listings#Mailto:". A relevant part of the latter link is

"I think two issues are being confused here: whether we ought to give email addresses, and how we should present them. I certainly wasn't suggesting not including email addresses; I was questioning the presentation of email addresses in mailto: format, for the reasons I indicated. Another reason I could mention is that the mailto: function is widely detested on the internet, since if you don't use Outlook Express some other PC-based email system, but instead do all your emailing on a web site mailer like gmail, then it's irritating that whenever you click on a mailto: link, your system freezes while it chugs along bringing up Outlook Express, which you then have to close before you can do anything else. (This often happens because the mailto: tag is hidden behind some link like Contact Us.) It's surprisingly difficult to get your system not to do this, especially with Firefox, and when I say it's widely detested I'm not just claiming that: do a Google search on something like Firefox default email to see how many people are irritated by this and how complicated the suggested solutions are -- and so far I haven't been able to get any of them to work!" "...Put mailto: in the Wikivoyage search box to see how ugly it can get."

Now the good lieutenant didn't seem to understand this objection to the mailto: link then, so I do admire both his consistency together with his invincible ignorance over the course of the intervening 4 years in not following (WT-en) Sailsetter's suggestion to Google this widely know and protested problem.

I'm also a bit baffled as to why it seems OK to have mailto:links in blue (I bloody well hope, as the conventional warning that it is a link) but NOT alright to have anchor text appear in blue. Why the inconsistency? -- Alice^✉ 05:07, 17 February 2013 (UTC)

I remember how irritating it used to be to click on "Contact Us" links and get dodgy Outlook programs opened. But for email addresses that are hyperlinked, I assume that they are mailto links so know not to click on them. Some browsers like Chrome actually have a fancy feature that allows you to right-click on mailto:-linked email addresses and "Copy email address". It saves the annoyance of having to try and copy every character of the address without clicking the link. Also, browsers like Firefox and Chrome have extensions that modify mailto: links to point to web mail severs rather than computer applications. I've modified mine to point to Outlook.com, so now I no longer fear mailto:. It will also make a comeback as Windows 8 grows and it opens the fairly bare-bones Mail app rather than some irritating program from the '90s. So all in all, I say keep mailto: JamesA ^>talk 05:15, 17 February 2013 (UTC)Reply

If anyone expects me to continue in this ridiculous discussion, then the expletives and insults need to be toned down, pronto. Until people can be civil, I'm restoring the mailto: link. LtPowers (talk) 16:20, 17 February 2013 (UTC)Reply

I was unaware that the mailto: link had been removed from the template and would like to go on record as strongly supporting keeping it. I don't see any agreement in Wikivoyage_talk:Listings#Mailto: that mailto is "strongly deprecated" (only one user seems to be arguing against it in that discussion), and I don't think the argument that clicking on the link might open Outlook for some non-Outlook users is a valid reason for inconveniencing all the users who are on mobile phones or have properly-configured systems. -- Ryan • (talk) • 16:48, 17 February 2013 (UTC)Reply

This template should definitely be protected, as changing it can change every listing in every article. Any objection to making it admin only? Any changes should generally be discussed on the talk page first, so hopefully this won't be too much of an inconvenience. -- Ryan • (talk) • 15:15, 18 February 2013 (UTC)Reply

I'd say start at autoconfirmed unless we have a particular issue. --Inas (talk) 03:44, 19 February 2013 (UTC)Reply

I have gone ahead and admin-protected it. I really don't think we'd want to see the ramifications of a "particular issue". Any changes, even minor like adding a space, should be discussed anyway. We've seen at Wikivoyage talk:Listings how contentious changes to this template are. Any users who would like to make a change to this template should propose it on the talk page first, with reasoning, and notify an admin if there is minimal discussion. JamesA ^>talk 03:56, 23 February 2013 (UTC)Reply

I've seen no evidence at all that autoconfirmed users go around vandalising things.

You seem to be saying that we should be protecting this page because changes may be contentious. If so, that's certainly a new development, and quite undesirable. --Inas (talk) 04:08, 23 February 2013 (UTC)Reply

There is no evidence, nor would we want evidence. If an autoconfirmed user (it's not that hard to become one) was to have a bad day, have someone else use their account while logged in (not uncommon either) or become frustrated with the wiki and want to go out with a bang, then it's truly not that hard. Simply add something like "penis" to this template and already our reputation is permanently tainted. We don't have trusted users patrolling 24 hours a day, 7 days a week. I've seen vandalism slip through the cracks. This is one of those circumstances where we just can't let it happen. As the saying goes, prevention is better than a cure, so let's try and prevent vandalism rather than waiting for it to happen. JamesA ^>talk 04:25, 23 February 2013 (UTC)Reply

Is there a level between Autoconfirmed and Admin that could be allowed editing? -- Alice^✉ 07:42, 23 February 2013 (UTC)

And changes being contentious didn't come into the protection decision. I was simply saying that any users who may wish to add something to the template and now can't should've had to have requested the change regardless of its protection. Just like User:Nurg recently discussed such a trivial matter such as adding a space after the colon. I'd further like to see permanent protection extended to templates like Template:Geo, Template:IsPartOf and Template:Stub, which are all very high usage (but that's a discussion for the Pub). I'd say just those 4 is a very conservative approach, considering Wikipedia goes crazy protecting hundreds of templates. JamesA ^>talk 04:25, 23 February 2013 (UTC)Reply

{{Stub}} is used on fewer than sixty pages, none of them worth keeping. K7L (talk) 05:13, 23 February 2013 (UTC)Reply

My mistake. I meant Template:Outline and the like, although even those are not a major issue and could be semi-protected instead. JamesA ^>talk 05:39, 23 February 2013 (UTC)Reply

The danger of protection (to turn this around) is that most of the edits to this template have been made by non-admins. If we are going to go the route of protecting ever more templates (and this is probably the highest risk template on our site), we should establish an obvious way for users to sandbox them (and then poke an admin to make the change). How do other wikis do this? --Peter ^Talk 07:36, 23 February 2013 (UTC)Reply

Excellent point. -- Alice^✉ 07:42, 23 February 2013 (UTC)

The very first time this is vandalised by an autoconfirmed user I'm happy for sysop protection. I really don't think the site is that badly patrolled that it presents that big a risk. After all, the change could be reverted by anyone. I really think my assessment is right, and vandalism isn't the target here, it is people wanting to make changes to the template without discussion and subsequent admin permission. And I think that's a big change for us. --Inas (talk) 10:30, 23 February 2013 (UTC)Reply

Agree with Peter and in principle with Inas too. For now, this wiki is a lot more welcoming and open to editors than e.g. English Wikipedia. Let's try to keep it that way as long as possible. It's not so much that I mind asking an admin to change something for me, but it should remain a real exception and indeed a clear hint on how to request such changes should be visible on the particular page. The listings template is a good example, as vandalism will not only get huge visibility but site use can also be severely disturbed. Even if just for a very short time, since any user can revert. The "outline" one is already different. It's at the bottom of the page, not that big, and if it would be vandalized other users would see it in no time and revert. It's not that big a risk. Unabling normal users making changes to such templates is, I agree, an undesirable road. Maybe we should just discuss it per template? I would say yes to the listings-template, but I'd agree with Inas for the outline one. JuliasTravels (talk) 11:35, 23 February 2013 (UTC)Reply

While I agree this template should probably protected at some point (not protecting this template makes it too easy to vandalize each and every page on this wiki with a single edit), I'm probably going to need to make a few more small adjustments in order to get the listing editor to round-trip correctly. —Ruud 14:17, 23 February 2013 (UTC)Reply

This template doesn't like multi-paragraph descriptions very much. See e.g. "Sri Krishna Temple and Mutt" at Udupi#See (The four paragraphs that fail to be indented do belong to the <see>.) Has this always been the case, or are multi-paragraph descriptions forbidden anyways? —Ruud 22:08, 25 February 2013 (UTC)Reply

They are discouraged/not used. Complex attractions can/should get multiple paragraphs, but should then get their own subsection, instead of a standard listing bullet. --Peter ^Talk 23:16, 25 February 2013 (UTC)Reply

The use of the bullet (*) character as wiki markup (instead of HTML's <li> and </li> tags) infers that the bulleted list item ends at the first newline character. Wrapping that text in a tag or template changes nothing. Lose the bullet and use <li><see name="whatever">...lengthy description...</see></li>; the indentation will be retained for the whole text, which will be displayed as one long paragraph unless broken with <br/> or <p/> tags.

Then again, Peter's right - just create a subsection for a complex attraction and take the space you need. Much easier. K7L (talk) 01:37, 26 February 2013 (UTC)Reply

The template doesn't appear to handle pipe characters gracefully:

* <see name="360 | 365 Film Festival" alt="" address="123 Address Rd." directions="Left at Albuquerque"  lat="" long="" phone="+1 555-555-5555" tollfree="" email="" fax="" url="http://360365.com/"  hours="Mar 1-25" price="$123">Film festival description.</see>

produces:

• <see name="360 | 365 Film Festival" alt="" address="123 Address Rd." directions="Left at Albuquerque" lat="" long="" phone="+1 555-555-5555" tollfree="" email="" fax="" url="http://360365.com/" hours="Mar 1-25" price="$123">Film festival description.</see>

-- LtPowers (talk) 22:46, 13 March 2013 (UTC)Reply

I'm not positive if there is a workaround in the template code as the behavior may be inherent in how Mediawiki handles pipes. As a workaround in the calling code we can use {{!}} for now:

• <see name="360 | 365 Film Festival" alt="" address="123 Address Rd." directions="Left at Albuquerque" lat="" long="" phone="+1 555-555-5555" tollfree="" email="" fax="" url="http://360365.com/" hours="Mar 1-25" price="$123">Film festival description.</see>

-- Ryan • (talk) • 22:49, 13 March 2013 (UTC)Reply

I was aware of the workaround, but fortunately this particular item changed its name and no longer needs the pipe. Nonetheless, I wanted to alert others to this hopefully rare failure case. It seems like there ought to be some sort of workaround elegant solution. (On the bright side, the equal sign seems a-okay, which I'm mildly surprised at.) LtPowers (talk) 01:06, 14 March 2013 (UTC)Reply

I've never been happy with the change that moved the price information from the end of a listing to the beginning. More generally, I've never been happy with how italics have been used in our listings.

(See also some mockups I created at User:Bigpeteb/Listing template revision possibilities.)

Consider this entry:

• Keeneland Race Course, 4201 Versailles Rd (at Man o' War Blvd, 1 mile west of New Circle Rd). Live races April and October; museum open most of the year. Admission $5 during race meets, but if you don't put some money on your favorite horse or jockey, you're missing the point. The tradition at Keeneland is to dress-up a bit; no jeans or T-shirts. Enjoy horse racing in a "days-gone-by" setting. Keeneland hosts live races only twice a year, with the Spring meet in April and Fall meet in October, but they welcome visitors year round. The feature race of the Spring meet is the Toyota Bluegrass Stakes, a prep race for the Kentucky Derby. When its live races are not in session, you can still watch other races broadcast from around the world or attend events like the yearling horse sales, where many young stallions command price tags in the millions. Buyers include local horse farms and bidders from Europe, Saudi Arabia, and Dubai. Recent movies Seabiscuit, Dreamer and Secretariat have been filmed at Keeneland.

Compared to other guidebooks I've seen (online and print), this is hard to read. It's difficult to know where to look for the hours, or price, or description, because they all blend together.

Now here's a slight reformatting:

• Keeneland Race Course, 4201 Versailles Rd (at Man o' War Blvd, 1 mile west of New Circle Rd). Live races April and October; museum open most of the year. Enjoy horse racing in a "days-gone-by" setting. Keeneland hosts live races only twice a year, with the Spring meet in April and Fall meet in October, but they welcome visitors year round. The feature race of the Spring meet is the Toyota Bluegrass Stakes, a prep race for the Kentucky Derby. When its live races are not in session, you can still watch other races broadcast from around the world or attend events like the yearling horse sales, where many young stallions command price tags in the millions. Buyers include local horse farms and bidders from Europe, Saudi Arabia, and Dubai. Recent movies Seabiscuit, Dreamer and Secretariat have been filmed at Keeneland. Admission $5 during race meets, but if you don't put some money on your favorite horse or jockey, you're missing the point. The tradition at Keeneland is to dress-up a bit; no jeans or T-shirts.

It only changes two things: the "price" is moved to the end, and everything except the descriptions is set in italics. But I think the readability is greatly improved. The use of italics makes a clear differentiation between the description and everything else. And moving the price and other info to the end makes it easy to find, and an obvious place for taking on extra information about reservations, dress, etc.

Here's another example I grabbed:

• Gazala Place, 709 9th Ave (Between 48th and 49th Sts.), ☎ +1 212 245-0709. Sun-Fri: 11am-11pm Sat: 11am-midnight. Mezes: $5-$9.95; Soups: $4.50; Salads: $7.50-8:50; Breads and savory pies: $4.50-$5.50; Sandwiches: $3.50-6.00; Entrees: $8.95-$17.95; Desserts: $5.50-9.50. Dependably delicious Israeli Druze cuisine. Their babaganush is categorically better than at most other places, with great smokiness. Their special meze platter, which is not on the menu but seems to always be available, is a fair deal at $20-something. The restaurant is a bit cramped, especially when you have to walk through the kitchen to the restroom, but for food this good at these kinds of prices this close to Times Square and helpful service, it's really worthwhile.

versus

• Gazala Place, 709 9th Ave (Between 48th and 49th Sts.), ☎ +1 212 245-0709. Sun-Fri: 11am-11pm Sat: 11am-midnight. Dependably delicious Israeli Druze cuisine. Their babaganush is categorically better than at most other places, with great smokiness. Their special meze platter, which is not on the menu but seems to always be available, is a fair deal at $20-something. The restaurant is a bit cramped, especially when you have to walk through the kitchen to the restroom, but for food this good at these kinds of prices this close to Times Square and helpful service, it's really worthwhile. Mezes: $5-$9.95; Soups: $4.50; Salads: $7.50-8:50; Breads and savory pies: $4.50-$5.50; Sandwiches: $3.50-6.00; Entrees: $8.95-$17.95; Desserts: $5.50-9.50.

Now, personally I think this is much better. But what I really want to know is whether it would be possible, with the new Template:Listing, to make this a user choice, so we can offer a handful of formats, and users can choose their favorite just as they can mediawiki skins. --Bigpeteb (talk) 14:43, 15 April 2013 (UTC)Reply

I agree completely on the price. But I don't like the italics on anything but the directions (and maybe the hours). It just looks weird. LtPowers (talk) 16:53, 15 April 2013 (UTC)Reply

Same here, yes on moving the price but no on the change in use of italics. Also, your examples do not include the alt field, which is another of our uses of italics, and would be another just blurred into what I think is a little too much italics. Texugo (talk) 16:58, 15 April 2013 (UTC)Reply

However, the idea of providing some preferential alternatives to viewing listings is interesting. I don't know about the feasibility though. Texugo (talk) 16:59, 15 April 2013 (UTC)Reply

I'd love to revisit this discussion, and seriously consider doing something along the lines of User:Texugo/Mock layout. I think moving hours and pricing to a line below the description would greatly improve readability. The icons in Texugo's mockup were more controversial, but perhaps we could agree on separating the description and details by carriage returns? --Peter ^Talk 19:44, 15 April 2013 (UTC)Reply

Okay, so what would it take to move the price to the end of the listings? I could do it myself, since the template isn't protected, but is there any more discussion/approval to be done first? --Bigpeteb (talk) 15:55, 19 April 2013 (UTC)Reply

I would support italicised opening/hours information and prices being moved (keeping that order, with prices last) to the end of listings but, otherwise, no increased italicisation.

Far more important for the clarity to our readers, is to ditch the ghostly soccer ball (that most casual readers think will be a link to a Google or Bing map) and restore the (almost universally) understood convention of a blue hyperlink (that is underlined when hovered over) in the default skin! -- Alice^✉ 02:26, 20 April 2013 (UTC)

That is already being taken care of at Wikivoyage_talk:External links#Front linking (hear me out). To Bigpeteb, it would be good to get more input. Could you edit the template in a sandbox, so we could have a visualization to look at while discussing? Then adding this discussion to Wikivoyage:Requests for comment should do the trick. --Peter ^Talk 18:37, 20 April 2013 (UTC)Reply

Customisable listings are very doable, with the following CSS in userspace or probably Mediawiki gadgets if enough people want them. -- torty3 (talk) 10:48, 4 July 2013 (UTC)Reply

span.listing-address { font-style:italic; } span.listing-phone { font-style:italic; } span.listing-hours { font-style:italic; } span.listing-price { font-style:italic; } 

moved from several other template discussion pages

Why should it still be necessary to add the http:// in front of the URL?

Surely the code should be smart enough to cope with both its absence or its inclusion? -- Alice^✉ 16:46, 21 June 2013 (UTC)

MediaWiki template code does not do text parsing very well. It's computationally expensive and requires some ugly spaghetti code. If we ever re-write this as a Lua module, we could address this, but until then I don't think it's worth the considerable hassle. LtPowers (talk) 02:10, 24 June 2013 (UTC)Reply

Where there is just a name and a content, there is 2 much space between the 2 --W. Frank^e-mail_talk 19:26, 3 July 2013 (UTC)Reply

Template:Listing was not designed for use with our one-liner listings. They have their own format, as detailed at Wikivoyage:One-liner listings. LtPowers (talk) 20:24, 3 July 2013 (UTC)Reply

It is nevertheless something that needs to be fixed, as I am certain there are plenty of other see/do/eat/etc. listings out there which will happen to thus far have only name and description. There shouldn't be a space before the period. Texugo (talk) 20:29, 3 July 2013 (UTC)Reply

Right you are. I've fixed it; see user:LtPowers/Sandbox for proof. LtPowers (talk) 02:14, 4 July 2013 (UTC)Reply

Err, I'm not sure if this has to do with what you just did, but it looks like we just lost the space between the name and the address for those listings that do have addresses. PerryPlanet (talk) 04:15, 4 July 2013 (UTC)Reply

I also would like to use this template with a listing in prose, like I have done here with the Grand Palace and Wat Pho. Now there's still a dot after the phone number which breaks the sentence. If that would be changed to a comma, the template would look better in prose. Globe-trotter (talk) 06:16, 4 July 2013 (UTC)Reply

If we change it to a comma then normal listings won't have a period before the description starts, thus putting a capital letter in the middle of a sentence. LtPowers (talk) 14:52, 4 July 2013 (UTC)Reply

Non-Latin scripts, like Thai, are now using an italicized font in the alt field. Does anyone know how to change this in the template? Thai is already difficult enough to read without italics :-) Globe-trotter (talk) 14:28, 1 July 2013 (UTC)Reply

It's not a new complaint... I remember seeing that mentioned years ago on WT. I know that WP has templates like w:Template:Nihongo that use <span> tags to mark the foreign text with a lang="" tag, and also add CSS that forces it to be upright. That would be the ideal solution, IMO; using templates like those make everything more consistent, the lang= tag means search engines and screen readers will deal with the foreign text appropriately (particularly if it's foreign text written in a Latin alphabet, like Spanish, French, or German), and the formatting would work correctly whether the text is upright (normal body text), boldfaced, or italicized (such as in a listing alt= tag). But, of course, it's a big project to convert all non-templated foreign text on WV to use templates. Bigpeteb (talk) 19:13, 1 July 2013 (UTC)Reply

Yikes. This is a new problem, though—non-Latin text was not italicized in listings before we moved to the templatized version (or at least before we moved to the WMF). It makes reading and recognizing the Russian names in articles like Staraya Russa much more difficult for people who don't have a decent command of Russian (see this chart). --Peter ^Talk 19:44, 1 July 2013 (UTC)Reply

Ah, found the old discussion. Apparently the hack was to have the <listing> tag un-italicize characters above Ux02FF. I have no idea whether that's something that MediaWiki templates can handle. Bigpeteb (talk) 13:46, 2 July 2013 (UTC)Reply

If there's no other fix, we should add an additional "altlang=" field or something like that. Having Russian in italics is not really a tolerable problem for a travel guide. It would be a bit of a pain to make the changes in articles, though. --Peter ^Talk 19:46, 2 July 2013 (UTC)Reply

A search says Lua modules like w:module:string could be used, anyone with more knowledge or maybe ask over at w:Wikipedia:Lua_requests? -- torty3 (talk) 10:58, 4 July 2013 (UTC)Reply

[crickets]—time to ask at Wikipedia ;) --Peter ^Talk 18:34, 9 July 2013 (UTC)Reply

Not sure if it's quite ready for prime time but I've done a function at Module:IsLatin. -- WOSlinker (talk) 22:24, 21 July 2013 (UTC)Reply

Can we test this? (You're not dealing with a tech-savvy editor.) ;) --Peter ^Talk 20:05, 23 July 2013 (UTC)Reply

It all works as far as I can see & test. It was mainly that I was hoping for someone else to take a look & see if they had anything to make the code better. Anyway, there's been a response on Wikipedia:Lua requests now and we may as well use it. I've updated the listing template. -- WOSlinker (talk) 06:32, 24 July 2013 (UTC)Reply

Checked out a few pages and appears to be working... I believe that "directions" in the "listing template" was also to be updated if I remember correctly??? - (if not please ignore this note/comment) - Matroc (talk) 20:33, 24 July 2013 (UTC)Reply

Non-Latin characters would only appear in the directions field if also accompanied by English text. Would it be possible in such instances to keep the Latin characters italicized, while leaving the non-Latin characters unitalicized? If not, let's just leave the field wholly italicized—this is a rare instance to worry about, anyway. --Peter ^Talk 20:58, 24 July 2013 (UTC)Reply

This modification unitalicizes the entire field if there are any non-Latin characters. is that what was wanted, or should it switch between italics and upright if there's a mix of Latin and non-Latin characters? Bigpeteb (talk) 15:25, 25 July 2013 (UTC)Reply

Recent changes to the template appear to have made everything bold in any listings that lack content in the name= field. La Macarena#Eat provides an example at what I've dubbed "Restaurante Anonymous"—a restaurant that doesn't have a name. --Peter ^Talk 18:36, 9 July 2013 (UTC)Reply

Bold and italic; see Rochester (New York)#Eat. LtPowers (talk) 20:44, 9 July 2013 (UTC)Reply

And it looks like it's once again putting the "' ," combination in these listings (see Saint Petersburg/Petrograd Side#Budget for an example. Does anyone know how to fix this? --Peter ^Talk 18:06, 21 July 2013 (UTC)Reply

I think I've fixed the issue, but attempting to do so with Mediawiki syntax is a bit hairy, so please revert if I've broken things elsewhere. -- Ryan • (talk) • 18:31, 21 July 2013 (UTC)Reply

Nice! I checked all the above past issues, and they seem to still be fine. All that's left right now, I think, is to get non-Latin scripts de-italicized. --Peter ^Talk 19:14, 21 July 2013 (UTC)Reply

The doc of the {{listing}} template says that

This template is used for implementing generic business listings. In general this template should not be used directly, and the corresponding attraction-specific type template should be used instead

Yet it seems used quite a lot for other things, for instance in the Paris article it is used for listing airlines and embassies. Should we make additional derivatives of it or should we change the doc to undeprecate its direct use? Fractal (talk) 08:47, 26 July 2013 (UTC)Reply

Neither. It should only be used if there's no more specific template available. LtPowers (talk) 13:11, 26 July 2013 (UTC)Reply

I wouldn't mind clarifying the policy to state that it is used for listings in sections not covered by the other tags. It does strike me as odd to say that in general it shouldn't be used, when it is actually quite often used for airlines, taxi/car rental, ferries, bus stations, tourist information centers, embassies and consulates, laundromats, places of worship, hospitals, and other stuff. Texugo (talk) 13:28, 26 July 2013 (UTC)Reply

I changed the two sentences by "This template is used for implementing generic business listings. There are a few attraction-specific type template which should be used instead, if applicable:" Fractal (talk) 14:10, 26 July 2013 (UTC)Reply

I noticed that fr: has one extra wrapper, "aller" (go), for use in "get in" and "get around" listings. That doesn't catch all of the instances where "listing" might otherwise need to be invoked directly, but does hit quite a few of them. K7L (talk) 19:19, 12 August 2013 (UTC)Reply

Hello: After testing the isLatin module earlier created by WOSlinker, looking at various listings for the italics issue in the alt field and reading this talk page, I created a Lua Module for Template:Listing... An example of output from that Module can be seen here... Matroc (talk) 23:36, 27 July 2013 (UTC)Reply

This is now out of date because of maps (PoiMap2) and recent changes to template Listing - Code in the Module will at least give someone an idea or 2 maybe? Cheers! Matroc (talk) 04:11, 12 August 2013 (UTC)Reply

I keep meaning to reply to this... Thanks a lot for the module code, it does work as a nice base and I wonder whether it will be more efficient. Is it possible to test the speed? As it is, editors already aren't inclined to touch the template code, so moving it to Lua would hopefully not prevent the ones who already do. There's also a little bit more discussion about adding another parameter to the template again. -- torty3 (talk) 07:31, 12 August 2013 (UTC)Reply

I am not sure about speed (am on Windows7), there would still be a template (with the same parameters & without ParserFunctions) to call the Module - I put the Module and template on wikivoyage as an EXPERIMENT only (should not be used period as it does not completely conform to existing standards) - "Module:ExListing & Template:ExListing" - using "Module_talk:ExListing for testing purposes. This is to experiment to see what can be done with a Module (have not figured out how to implement the new maps in it though - might not be able to without expert help?) - Matroc (talk) 09:23, 15 August 2013 (UTC)Reply

Does anyone know how we can automatically change all spaces in phone and fax numbers into the &npsp; character? So that numbers don't split when they're at the end of a line. There's the REPLACE function, but it's deactivated. Tamuz (talk) 12:05, 15 August 2013 (UTC)Reply

This can be done with CSS. Just mark it white-space: nowrap. I see that all 3 numbers (phone, toll-free, fax) all have a tel class applied, so it should just be a one-line change to the appropriate stylesheet. But I don't know where to edit that, or who has permissions to.

In lieu of changing the stylesheet, you could add style="white-space: nowrap" to each of the <span> tags. But that's really just a hack until the proper stylesheet can be changed. Bigpeteb (talk) 13:30, 15 August 2013 (UTC)Reply

I suppose the style sheet would be Mediawiki:Common.css, which I can edit, but I don't know a lot about css so I don't know exactly what to put in there. Texugo (talk) 13:42, 15 August 2013 (UTC)Reply

Oh, and now that I look at the code... hmm... I think the   between the comma and each phone listing should go away, since that is a natural place to break the line. But I think the phone icon and the number it proceeds should not be broken. So maybe it is appropriate to change it to

Mediawiki:Common.css: add

listing-tel-display: { white-space: nowrap; }

Template:Listing: modify each telephone number to be like (changes underlined for your visibility):

{{#if:……stuff here……|,&#32;}}<span class="listing-tel-display"><abbr title="phone">☎</abbr> <span class="tel listing-phone">{{{phone}}}</span></span>

Although someone more in tune with WV/WMF standards might want to suggest better naming for that CSS class. Bigpeteb (talk) 13:53, 15 August 2013 (UTC)Reply

That would probably require a Lua module. Mediawiki alone won't be able to do that. Texugo (talk) 13:30, 16 August 2013 (UTC)Reply

Are we sure it's necessary to no-wrap phone numbers? They can be kind of long. Are there any style guides that recommend it? LtPowers (talk) 15:17, 15 August 2013 (UTC)Reply

No style guides on WV, but it should be common sense; after all, phone numbers are never going to be longer than 16 characters long excluding spaces and extensions. --W. Frank^e-mail_talk 16:58, 15 August 2013 (UTC)Reply

I thought it common sense too, but LtPowers may have a point - I do think there are some places where we have multiple numbers or other info in the tel field, like "+55 55 5555-5555 or +55 66 6666-6666" or "+55 55 5555-5555 during business hours, +55 55 5555-6666 after business hours". Of course, that may not be how it is supposed to be done, but I do think it exists currently in some listings, and I don't think we'd necessarily want to nbsp all of those. Texugo (talk) 17:37, 15 August 2013 (UTC)Reply

No, even if it is only 16 characters, I don't think it's a problem to break them across lines. It's not at all like measurements, where a bare "km" or "mi" at the beginning of a line might cause the reader to stumble. I seem to recall, in fact, seeing phone numbers broken across lines in actual professional publications. LtPowers (talk) 19:06, 15 August 2013 (UTC)Reply

This is not that important either way, but since this is going to be formatted automatically using this template and editors are never going to see the non breaking space HTML and any multiple instances of phone numbers are likely to be grouped together (and so unlikely to force more than one line break) it's marginally better to do it - especially now we've spent this much time discussing it. --W. Frank^e-mail_talk 19:12, 15 August 2013 (UTC)Reply

I take the opposite view; given where phone numbers appear in our listings format, it's unlikely that they'll be at the end of a line, and the situation Texugo suggested is a bigger concern to me than the possibility that a phone number would break over two lines. LtPowers (talk) 23:41, 15 August 2013 (UTC)Reply

Good point Texugo, I haven't thought about it. How about this instead: create some template that takes one string of text and replaces all spaces inside it with nbsp, so that users can write in the PHONE field: phone={{NoWrap|+55 555 555}} or {{NoWrap|+55 555 666}}. Whatcha think? Tamuz (talk) 06:55, 16 August 2013 (UTC)Reply

A bit complicated, I think. Casual users won't know to do that, regular patrollers have better things to do than go around inserting such things, and it rather defeats the listing editor's point of not having to mess with templates. Texugo (talk) 11:28, 16 August 2013 (UTC)Reply

Agree. Better solution might be to have the listing template check if the phone number contains only 0-9, spaces, and punctuation; if so, no-wrap it, otherwise, that must mean it contains letters or words, so assume that means it's wordy and leave it be. Bigpeteb (talk) 13:03, 16 August 2013 (UTC)Reply

Please don't forget to include the plus sign (+) in the check (since it should be right at the start of every correctly formatted phone number). --W. Frank^e-mail_talk 14:56, 16 August 2013 (UTC)Reply

Again, though, I'm not convinced this is a desirable change, let alone necessary. All we have so far is an assertion that it's needed. LtPowers (talk) 15:24, 16 August 2013 (UTC)Reply

Well, I can only say that in my opinion it is desirable, since it is confusing when a phone number is broken in the middle. Especially in the listings, that potentially contain a great heap of numbers, you might mix them up if they're broken between lines. However, I don't know how to make the change or how much work it would take to do so. If anyone thinks they're up to it, I think it would be great. In my opinion, we want to turn spaces into nbsp whenever they're surrounded in both sides by either a digit, a plus sign or the phone icon. If RegEx and substitution patterns can be used, it should be pretty simple to substitute the first group in any occurrence of [\d+☎]( )\d with an  . Do you think that such a change is possible and desirable? Tamuz (talk) 08:01, 18 August 2013 (UTC)Reply

I still think it's moderately desirable. --W. Frank^e-mail_talk 23:55, 30 August 2013 (UTC)Reply

How long have listings with the lat and long fields filled in been automatically displaying numbered boxes? These numbers are distracting and confusing, particularly in articles without dynamic maps. LtPowers (talk) 12:45, 17 August 2013 (UTC)Reply

I agree with this objection. And the previous map icon was more intuitive. Globe-trotter (talk) 12:49, 17 August 2013 (UTC)Reply

Several days already. I too think that the boxes are at least 40% too large - however, their size and shape are currently under discussion and I expect reduction in size shortly. Wherever you see them, if you click on them a dynamic map is displayed (centred on the numbered icon you clicked on) with the other numbered points of interest also displayed. Globe-trotter: what "previous map icon" are you referring to? --W. Frank^e-mail_talk 15:12, 17 August 2013 (UTC)Reply

Before an icon was displayed beside the listing that the user could click on. That version was better because it also worked with static maps, and with articles that only had a few listings with lat/long information. Globe-trotter (talk) 15:31, 17 August 2013 (UTC)Reply

Any article with {{geo}} has a dynamic map (and destination guide is supposed to have such a template), with numbered icons corresponding to those in-article. The expectation is for {{mapframe}} to be rolled out in most, if not all articles, so these will be pretty straightforwardly useful. I could see clickable icons directing to poimap being useful, though. --Peter ^Talk 18:21, 17 August 2013 (UTC)Reply

Or wait, they already are. --Peter ^Talk 18:22, 17 August 2013 (UTC)Reply

The way it's done now is confusing. For example, Venice (California) only has a few Sleep listings with geo information, so the numbers 1 and 2 seem to appear quite randomly for the unknowing reader. Bangkok/Rattanakosin has a static map, so the numbers used in the article don't match with the numbers on the static map. The current implementation only works for articles that use a dynamic map and where all listings have lat/long information added to them. The map icon, as done before, was fine in all situations. Globe-trotter (talk) 19:22, 17 August 2013 (UTC)Reply

Right. Honestly, I didn't realize they were clickable, nor that the map icon in the upper right corner incorporated them. But Globe-trotter is right about how the appearance in-article leaves much to be desired. Unless every listing is numbered, it looks weird to have some listings numbered, and it's downright misleading when the map displayed in the article uses different numbers entirely. LtPowers (talk) 15:45, 18 August 2013 (UTC)Reply

I would think static map keys should be harmonized to the numbered listings, so that the dynamic map and static maps match. And I actually think it's better that listings be distinguished by whether they appear on the map—I've always thought it would be confusing to look at a drink section, see the listing you want, and then look for it on the map, but not find it. It gives the impression that the map is incorrect/not up-to-date (when it's likely that there is overlap in listings content, noted in directions= fields, or because it is indeed incorrect/not up-to-date).

That it's not immediately obvious that you can get a full screen dynamic map from the top right icon, or that you can click the numbered icons to see them plotted on a full-screen map, are problems that arise as our site becomes more feature rich. I think we really need to move forward with the site tour idea, either using the extension or just an embedded video, to show readers how to get the most out of the site, and to help new editors get started. --Peter ^Talk 18:13, 18 August 2013 (UTC)Reply

It won't be easy to harmonise the Points of Interest (POI) numbers on static and dynamic maps. One reason they're called dynamic is that each time a listing in the article is added or removed (or geographical co-ordinates in an existing listing added or removed), these numbers will change.

I do agree that their intuitive "clickability" should be enhanced; my suggestion would be the universal web symbolism of giving each of them a wee blue line underneath. --W. Frank^e-mail_talk 18:23, 18 August 2013 (UTC)Reply

Site tours are nice, but the interface needs to be intuitive even without it; we can't expect everyone to view it. As for synchronizing the static map with the numbered listings, I don't see any practical way to do that, because the numbers can change at any time. (And that's without even getting into edge cases like multiple locations of an establishment (which usually only get one number on a static map) and co-located establishments (which may be listed in two different places in the article but with only enough room for one icon on the map).) LtPowers (talk) 18:31, 18 August 2013 (UTC)Reply

So wait, are you getting on board with the dynamic maps, then? Since they stay up-to-date, in sync with the article, instead of getting an update hopefully once a year? :P The other advantage to syncing them, though (and this mostly has to do with splitting see & do listings, which is probably something we always should have done anyway), is maintainability of the static map. It's infinitely easier to keep track of numbering on a dynamic map than a static map like this one, which has something like 109 icons to keep in order, i.e., in sync with its own map.

In any rate, it seems very clearly desirable to be able to print out the map and article, while having the article itself serve as a key. --Peter ^Talk

I don't know why my comment appears below W.Frank's; when I wrote it his wasn't there. Anyway, while it's certainly a bit of effort to update a map, it's infinitely better to have the map omitting a listing than it is to have it numbered completely wrong. LtPowers (talk) 01:46, 19 August 2013 (UTC)Reply

I wasn't too sure about the numbered listings myself, but they have grown on me. I do like the numbered key of the listings if not the colour, and I don't think they are entirely unintuitive. Looking at recent edits, I count at least 5 non-regular, non-expedition users who have added coordinates to listings, perhaps after noticing the stray numbers and clicking on them. I also don't agree that all listings need to be numbered, and they might look strange not because of the numbers, but because not enough prose/quality control is carried out to break up the listings.

The situation with static/dynamic maps is regrettable. There are pros and cons to both. I find outdated maps more irksome though. Sometimes the listings have closed and aren't removed from the map, or that new listings are not added. That is just as big a factor towards the quality of a map other than its looks, particularly for big cities. -- torty3 (talk) 13:43, 21 August 2013 (UTC)Reply

I don't understand what you mean by "not enough prose/quality control is carried out to break up the listings". Can you explain? I'm looking at Rochester (New York)#Drink, and it looks really weird to have a few listings numbered while most are not. LtPowers (talk) 20:34, 21 August 2013 (UTC)Reply

I hate to harp on this but I still think it's a problem. We should go back to the generic map icon for coordinates rather than trying to number listings that a) won't sync with the existing maps in the article; b) unfairly highlight listings that have coordinates over those that do not; and c) don't work well with listings with multiple locations or multiple listings at the same location. LtPowers (talk) 01:10, 2 September 2013 (UTC)Reply

The new feature to edit listings is great, but does now result in an intrusive "edit" hypertext label interrupting body text when the listing template is used "in-line" (such as Cologne#By_train).

May we have a switch to turn it off in these cases, please? --W. Frank^e-mail_talk 12:45, 25 August 2013 (UTC)Reply

The listing template should not be used in-line. LtPowers (talk) 15:31, 25 August 2013 (UTC)Reply

What should be used to preserve the geo co-ordinates and produce the (too large and obtrusive) consecutively numbered, hyperlinked, coloured square, please? --W. Frank^e-mail_talk 15:55, 25 August 2013 (UTC)Reply

The colored square should not appear in-line. The example you linked is not what I consider in-line usage, though; in this case, simply removing the word "and" is sufficient. The train station listings should have directions, addresses, and phone numbers, though. LtPowers (talk) 01:43, 26 August 2013 (UTC)Reply

Take a look at Erie Region#Do. Something's screwy. LtPowers (talk) 14:28, 27 August 2013 (UTC)Reply

Latitude and longitude MUST be specified in proper decimal format and no other - no minutes, no seconds, no spaces, no extraneous punctuation. :The new pop-up listings editor should be making that MUCH clearer!

--W. Frank^e-mail_talk 14:48, 27 August 2013 (UTC)Reply

Should this template display the phoneextra field, and if so, how?

Phoneextra is a long-standing attribute from our XML-listing days, and a number of articles use it to display alternative phone numbers. It may not be needed often, but it's really good to have on those occasions when it's needed.

-- LtPowers (talk) 01:01, 30 August 2013 (UTC)Reply

What sort of things did you have in mind for "really needed"? Skimming through a handful of articles, I can see several places where they're used as an undifferentiated secondary phone number (Warsaw in particular has many), but out of the first twenty or so, the only unique one I see is an automated line to give movie times for a theater in Philadelphia/Old City separate from the live-human contact number. Could most of the content in these fields be added as second entries to the phone= stanza instead? Am I overlooking more interesting cases? -- D. Guillaume (talk) 01:22, 30 August 2013 (UTC)Reply

Adding more than one number in the phone field is semantically difficult, especially upon data migration to Wikidata. TTY/TDD is the main alternative use that comes to mind. LtPowers (talk) 17:26, 30 August 2013 (UTC)Reply

Going through phone number formats I am coming across a number of listings were more than one phone number is given. Either providing extra numbers, a mobile number or using letters (short word) instead of numbers (typical in USA). I think it would be useful to provide an extra phone parameter, can then use the phone parameter for standard (smart phone dialable) format. --Traveler100 (talk) 08:03, 3 October 2013 (UTC)Reply

You could do the following:

|phone = +1 234 567 8900 |phonetype = Reservations |phone2 = +1 234 567 8901 |phonetype2 = Enquiries 

which would then produce ☎ +1 234 567 8900 (Reservations), +1 234 567 8901 (Enquiries) -- WOSlinker (talk) 09:47, 3 October 2013 (UTC)Reply

yes that could be useful. I assume the phonetype parameters could be left blank as it is not always clear why there are two numbers on some existing listings. --Traveler100 (talk) 10:10, 3 October 2013 (UTC)Reply

Suggest no syntax check for phone2 to allow for letter based numbers and other special cases. --Traveler100 (talk) 10:11, 3 October 2013 (UTC)Reply

Yes, if phonetype was blank then it would just be ☎ +1 234 567 8900, +1 234 567 8901. I'll get a sandbox version of the template done soon. -- WOSlinker (talk) 11:22, 3 October 2013 (UTC)Reply

Ok, I've done the sandbox and there's a few samples below. If you set phone2 but have not set phone then phone2 will not be shown. -- WOSlinker (talk) 12:12, 3 October 2013 (UTC)Reply

• Template:Marker/sandbox, ☏ +1 234 567 8900. 
• Template:Marker/sandbox, ☏ +1 234 567 8900. 
• Template:Marker/sandbox. 
• Template:Marker/sandbox, ☏ +1 234 567 8900, toll-free: +1 234 567 8902. 
• Template:Marker/sandbox, ☏ +1 234 567 8900, toll-free: +1 234 567 8902. 
• Template:Marker/sandbox, toll-free: +1 234 567 8902. 
• Template:Marker/sandbox, ☏ +1 234 567 8900. 
• Template:Marker/sandbox, ☏ +1 234 567 8900. 
• Template:Marker/sandbox, ☏ +1 234 567 8900. 
• Template:Marker/sandbox, ☏ +1 234 567 8900. 
• Template:Marker/sandbox, ☏ +1 234 567 8900, toll-free: +1 234 567 8902. 
• Template:Marker/sandbox, ☏ +1 234 567 8900, toll-free: +1 234 567 8902. 
• Template:Marker/sandbox, ☏ +1 234 567 8900, toll-free: +1 234 567 8902. 
• Template:Marker/sandbox, ☏ +1 234 567 8900, toll-free: +1 234 567 8902. 
• Template:Marker/sandbox, ☏ +1 234 567 8900, toll-free: +1 234 567 8902. 
• Template:Marker/sandbox, ☏ +1 734 668-8397. 

I'm not sure where the discussion is, but in the past we've been pretty skeptical of the value of multiple phone numbers for a listing. Is this something we really want to support, or would people be OK with saying that a listing gets a phone number, potentially a toll-free number, and that's it? If you really can't get what you need by calling the business's main number, that reflects pretty poorly on that business. -- Ryan • (talk) • 14:05, 3 October 2013 (UTC)Reply

Take for example Michigan Theater in Ann Arbor, it has the numbers : +1 734 668-8397 and +1 734 668-TIME (8463). Should we just delete entries that have words and numbers, or not allow direct dial from these listings? --Traveler100 (talk) 14:25, 3 October 2013 (UTC)Reply

My preference would be to just include the first phone number and to then delete the second - as noted earlier, any business that actually needs multiple numbers should be able to transfer a caller to the correct line, and in most cases I've seen where a listing has two numbers it appears that a business simply has multiple phone lines and lists them all. Hopefully others can comment in case there is some value to listing multiple numbers that I'm overlooking. -- Ryan • (talk) • 23:15, 3 October 2013 (UTC)Reply

I would echo Ryan's comments. They are almost always useless. Texugo (talk) 23:32, 3 October 2013 (UTC)Reply

I really like the multiple phone numbers with type in the listing. If the second number is useless, we can always delete it. A direct reservations number can save time being transferred - if you are global roaming, its significant. As for 'word' numbers. I don't have an opinion. I don't use them, but with the amount they are used in the U.S., you'd think they had some value. --Inas (talk) 00:05, 4 October 2013 (UTC)Reply

As others have pointed out some use cases where multiple phone numbers would be beneficial I don't want to get in the way of a change being made, but it would be nice if the documentation reflected that multiple phone numbers in a listing should only be included when the phone numbers have different "type" values so that it is clear there is no value in listing multiple numbers if a business just has multiple phone lines. -- Ryan • (talk) • 15:32, 5 October 2013 (UTC)Reply

I concur. Since I doubt that anyone will object to better documentation, why don't you go ahead and make the necessary change (the change can always be reverted if it proves to be controversial). However, I would also point out that some countries phone systems are so retarded that the caller is not automatically directed to the next available line in a cascade or hunt group and there may only be just one speech circuit associated with each number so that you have to manually re-dial alternative numbers when you get the engaged tone! (Burma, the Gambia and Uzbekistan leap to mind). --W. Frank^email_talk 15:51, 5 October 2013 (UTC)Reply

A hotel on a golf course could have a direct number for the restaurant and another to the pro shop or the reservation desk. A seasonal business may need to send off-season enquiries elsewhere (Chicken AK is inaccessible by road in winter) or one site may be reachable through different telephone exchanges (Haskell Library is in +1 819- and +1 802 as it's literally on a boundary). A bus station might devote a line to automatic schedule announcements. There are also countries where a mobile 'phone that can be called inexpensively from another mobile costs a premium from landline, so both are listed. It's the minority of listings, but exceptions happen often enough. K7L (talk) 04:03, 4 October 2013 (UTC)Reply

Another reason for multiple numbers with text information; identifying service charge numbers. Manchester#Tourist Information telephone number is very expensive to call from mobile or internationally. Would be good to have a standard way of highlighting such practices. --Traveler100 (talk) 13:10, 5 October 2013 (UTC)Reply

You make some very significant points, Traveler100 and may I take this opportunity to thank you for all the boring and laborious edits your bot is saving us.

While I've got your attention, may I raise a few little points?

It was a good idea to set the bot loose on one country at a time, because many countries have their own local phone peculiarities. For example, I would suggest that for the +44 country code, your bot should not touch any numbers that start with the "08" trunk code. This is because, unlike many US "1-800" numbers, these can invariably NOT be called from outwith the +44 country code. This is also true to a lesser extent of 0871 and 0843 numbers which are often very much more expensive for locally registered mobiles and (those landlines not using BT as their phone company). The same sort of thing is true of "13" numbers in Australia, etc.

More generally, your bot seems to be introducing an extraneous and unnecessary space both before and after the "equals" sign in "phone=+nnn".

The other general suggestion I would make is to prohibit it making any change where the number has less than 4 digits as these are likely to be special numbers. A while back (I forget where, but it was just before I was blocked) it changed an emergency number from something like ☎ 191 to ☎ +nn 191.

The additional phone fields are useful in some territories - for example, the Philippines is probably the texting capital of the world and many businesses will want to display a mobile number and a landline number for just that reason. Some territories actually have businesses with two phone numbers from separate countries with different country codes - and there are also different numbers for different languages in some countries. --W. Frank^email_talk 13:47, 5 October 2013 (UTC)Reply

thanks for the useful input. Currently working on a more secure logic to handle when listing syntaxes are not standard. Will see if I can incorporate the suggestions you have. Spacing is a challenge though, with the unbelievable number of variants people have input phone numbers in. --Traveler100 (talk) 14:50, 5 October 2013 (UTC)Reply

I can well believe that - however, making sure there is no space before the "equals" sign shouldn't be too much of a "challenge, eh? ie "phone=+nn" rather than "phone = +nn" ? --W. Frank^email_talk 15:10, 5 October 2013 (UTC)Reply

It looks like this mess https://www.nationalnanpa.com/enas/npasRequiring10DigitReport.do has gotten to the point where only a 'bot could keep track of it... too many numbers used to work just fine as seven digits but are now broken due to inefficient allocation of numbers and mismanagement, a problem as our existing listings need to be updated. Then there are the endless +1-800- overlays (requests for 844 numbers are now being accepted from Dec 7, largely because millions of numbers are being cybersquatted by w:Primetel phone sex spam and speculators); all of these are eleven-digit calls as there is no local calling area. For +44's and European numbers, we need to keep spurious leading (0)'s out as that's a domestic long-distance prefix and not part of the international number. There are more exceptions than rules to this game. K7L (talk) 16:10, 5 October 2013 (UTC)Reply

I don't disagree. Now that this realisation is dawning that it is a decreasing minority of the US population that continues to live in areas with access to 7 digit abbreviated dialling, I wonder if the time has come to re-visit our wv:phones formatting policy.

My suggestion remains to show, where applicable, numbers in the format they can be dialled internationally (or from a mobile phone); continue to separate the country code, area/trunk code and subscriber number parts with a single space but replace the single space with a single hyphen to denote the (conjoined) parts that can be dialled locally using abbreviated dialling.

If this rule were followed, there would be no change needed for most of the world and US numbers would be shown as follows:

11 digit dialling needed: Template:Marker/sandbox ☏ +1 234 567 8900. 

10 digit dialling needed: Template:Marker/sandbox ☏ +1 234-567-8900. 

7 digit dialling still available: Template:Marker/sandbox ☏ +1 234 567-8900.