Discussion here should be limited to the topic of how the template is functioning or not functioning properly. Please discuss proposals for how we should handle listings at Wikivoyage talk:Listings.

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 [1]" 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 "[2]" 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 [3] 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 [4]) 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) [5]. 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: [6]. 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. 

--W. Frank^email_talk 20:11, 5 October 2013 (UTC)[reply]

What does changing +1-212-123-4567 to +1 212 123 4567 accomplish? It breaks the pattern that the part joined by hyphens is what's dialled locally, but still requires we keep track of which areas are broken for seven-digit calls. K7L (talk) 12:43, 6 October 2013 (UTC)[reply]

Outside of the NANPA (and especially in territories which have open national numbering plans) it is becoming increasingly common for countries to adopt full-number dialling plans where there is no longer any possibility of using abbreviated local dialling (eg: in such disparate countries as Thailand, France, Italy, Spain, Poland, South Africa, Algeria, Ivory Coast, Portugal, Morocco, Angola, Niger, Tunisia, Norway, the Central African Republic, the Sudan, Uruguay, Mozambique, Cameroon, Burkina Faso, Belgium, Madagascar, Switzerland, Denmark, Zambia, Norway, Oman, the Czech Republic, French Guiana and Singapore. Perhaps Greece and Guyana, too?).

If you're using a "GSM" (or satellite) type of phone (again common outside of the NANPA), there has never been any possibility of using abbreviated local dialling.

If you're a traveller roaming outside of your own country network using any type of mobile phone (again common outside of the NANPA), there has never been any possibility of using abbreviated local dialling.

If you're using a special or non-geographic number (eg: an 0800 or 0508 freephone number in New Zealand or an 0333 number in the UK) outside of the NANPA there has rarely been any possibility of using abbreviated local dialling.

In world terms, what was a gloriously simple NANPA phone dialling system, has always been an (exceptionally easy and useful) minority feature that began in 1947 and started declining after the millennium. In many countries, locals are less likely to add phone numbers using hyphens. That means it's more likely that when they do see or use hyphens they will realise that hyphens have a special significance in Wikivoyage (and should not just be sprinkled around haphazardly as number group separators): a single hyphen denotes the (conjoined) part(s) that can be dialled locally using abbreviated dialling.

If we reserve hyphens for that special meaning then our advice to travellers can be gloriously simple:

"If you're using a mobile, always dial the number exactly as shown in Wikivoyage."

"If you're not using a mobile, always dial the number exactly as shown, (except that where you see a part or parts joined by hyphens, then you may be able to just dial those conjoined parts of the full number if you are in the same local area)" --W. Frank^email_talk 14:14, 6 October 2013 (UTC)[reply]

I think K7L is making more sense here. I think the pattern is much more apparent if hyphens are always used to represent the part that must be dialled locally, whether it's the last couple of groups or the whole thing. Texugo (talk) 14:51, 6 October 2013 (UTC)[reply]

That may be because you are not considering the world as a whole rather than concentrating on the situation that obtains in the NANPA and similar countries.

So, your preference, Texugo, is for me to immediately start sprinkling a whole lot of hyphens in all the countries I have listed above (plus a hell of a lot more)?

What do we do about countries like New Zealand, where there is abbreviated local dialling only where the call is a free local call within what can be a quite small localised area that is not coterminous with the trunk code? For example,the whole of the South Island has the trunk code of 03, but if I'm in Nelson I can't even call Motueka without using the full 9 digit number. Your scheme requires that we have to change ALL New Zealand numbers since from near-by Nelson we have to dial all the digits of 03 528 6699 to talk to Hot Mama's Café and Bar.

Using my scheme we indicate that it may be possible when you are reasonably local to Hot Mama's to just use 528-6699 and show her number as +64 3 528-6699 and the Air New Zealand number as 0800 747 747 (since you always have to dial all the digits and the number is not available internationally) and a mobile number as +64 21 202 4961 (since you always have to dial all the digits and the number is available internationally). Using your scheme, to keep the advice to travellers simple we have to show Hot Mama's number as +64-3-528-6699 and the Air New Zealand number as 0800-747-747 and a mobile number as +64-21-202-4961. --W. Frank^email_talk 15:21, 6 October 2013 (UTC)[reply]

No, my preference would be for you to not go making any changes until we have a consensus here. Texugo (talk) 15:23, 6 October 2013 (UTC)[reply]

The corollary of this would be that the bot should stop putting in these hyphens too, until and unless we are clear whether hyphens have a meaning (and exactly what meaning they do have) or are just semantically insignificant separators. --W. Frank^email_talk 15:33, 6 October 2013 (UTC)[reply]

What's unusual about "countries like New Zealand, where there is abbreviated local dialling only where the call is a free local call within what can be a quite small localised area that is not coterminous with the trunk code"? It's no different for a North American number. Campobello Island +1 506 to Lubec +1 207 is local, but Campobello +1 506 to Edmundston +1 506 is clear across New Brunswick and therefore quite the toll call. Good luck trying to cover all of +1 907 or +1 819 in one local calling area. They're not geographically-tiny +1-212- sized islands. K7L (talk) 00:32, 7 October 2013 (UTC)[reply]

I assume that in your NANPA example the call will still proceed even though you will be charged for it. In my NZ example the call will simply not go through at all if it is a toll call if you use abbreviated dialling from outside the local non-toll area. --W. Frank^email_talk 01:12, 7 October 2013 (UTC)[reply]

No, in Canada the call will fail. "You have dialled a number to which long distance charges apply. Please hang up, then dial 1 and the area code... this is a recording" K7L (talk) 16:38, 7 October 2013 (UTC)[reply]

Unfortunately this edit introduced hundreds of thousands of double penultimate full stops throughout our article main namespace since many "content" fields already ended with a full stop... --103.9.41.192 05:28, 11 March 2014 (UTC)[reply]

Sorry about that. It has been reverted now. -- WOSlinker (talk) 07:14, 11 March 2014 (UTC)[reply]

No harm done - that's the beauty of a wiki with lots of active editors. Good luck wielding the mop and I'll talk to you again next year... --118.93nzp (talk) 07:38, 11 March 2014 (UTC)[reply]

The French version of the listing template has the option to add a Wikipedia link. Just wondering if it would be any good to have this for the see and do listings? -- WOSlinker (talk) 23:44, 4 April 2014 (UTC)[reply]

See Wikivoyage talk:Listings#Listings tags and links to Wikipedia for a lengthy (and often heated) discussion on the subject. -- Ryan • (talk) • 23:55, 4 April 2014 (UTC)[reply]

Swept in from the pub

As highlighted on meta lounge the numbers associated to the listing with coordinates are not shown properly on the mobile version. Is anyone able to fix it? --Andyrom75 (talk) 20:24, 15 July 2014 (UTC)[reply]

Originally I combined the listing numbers with a background color. Example:  12 . This worked on all operating systems, browsers and font sizes without problems. This was modified by other users multiple times by now. Now missing on my mobile devices, the second digit in all listing numbers. And in other cases, the listing number is outside or at the edge of the colored background. - I can not understand these changes technically and therefore cannot help unfortunately. -- Joachim Mey2008 (talk) 05:09, 16 July 2014 (UTC)[reply]

As per my understanding, the second (and sometimes third) digit has not disappeared, but is located below the first one. Apparently is like the horizontal size is fixed so the text is force to go below. --Andyrom75 (talk) 15:06, 17 July 2014 (UTC)[reply]

We also have a problem in french, the number aren't shown at all: here.--Adehertogh (talk) 16:57, 17 July 2014 (UTC)[reply]

Adehertogh, I've noticed it too. Theoretically the issue on fr:voy should be easier to solve, because for sure there's something that is missing in the French configuration. While the problem in en:voy and in it:voy is different because the configuration should be aligned to the latest standard. Unfortunately Torty3 do not access since March, and for sure he's the most skilled user on this topic. --Andyrom75 (talk) 15:05, 19 July 2014 (UTC)[reply]

Could it be that we have same problem as in the PDF output? Does the new type of the mobile version recognize CSS styles? --Alexander (talk) 15:10, 19 July 2014 (UTC)[reply]

The stylesheets like Common.css etc. are not used for the mobile versions. I think the only workaround is to use number images. --RolandUnger (talk) 18:53, 19 July 2014 (UTC)[reply]

That's really bad. Do you mean that no css styles are used in the mobile version at all (that would be silly), or we have to duplicate some lines from Common.css in another *.css file that is responsible for the mobile version? Using images is not an option, because automatic numbering is essential. --Alexander (talk) 19:11, 19 July 2014 (UTC)[reply]

The file dedicated to manage the layout of the mobile devices are: MediaWiki:Mobile.css and MediaWiki:Mobile.js, I've already used for some specific fix. I'm confident that is possibile to not use the image for the numbered marker, but I've got not enough time to study the code. So I was hope in someone else's help. I think also that the PDF issue is not related with this issue. --Andyrom75 (talk) 19:18, 19 July 2014 (UTC)[reply]

I agree. It should be the problem of the box size and paddings. --Alexander (talk) 19:30, 19 July 2014 (UTC)[reply]

I don't know if there's a more elegant solution, however at the moment on it:voy I've patched it:MediaWiki:Mobile.css (well... it:MediaWiki:Listing-map.mobile.css) changing width: 12px; height: 13px; into width: 25px; height: 20px,

In the absence of better ideas an admin can patch MediaWiki:Mobile.css in the same way.

Note: for articles with more than 100 listing width: 25px; is not enough and it's necessary to use at least width: 29px; jointly with padding: 0px 0px 3px 1px;. However, three digits are not shown correctly in desktop mode as well. --Andyrom75 (talk) 22:24, 19 July 2014 (UTC)[reply]

Alexander I've just noticed that ru:voy has a third different problem on the mobile listing version. Instead of replicate the patched configuration file, I'd like to make some realtime test, but I need your ru:voy-admin support. Maybe we can catch each other on IRC. Just let me know (better if you contact me on my base talk page for quicker answer). I'd like to see if it's possible to find a better solution for all the languages. --Andyrom75 (talk) 06:06, 20 July 2014 (UTC)[reply]

I thought that the problem of ru:voy is essentially the empty Mobile.css file. Of course, I can do the testing, but you have to explain me your idea. I am not using IRC, and my preference would be Skype if I am to use any chat client. On the other hand, we can also discuss on-wiki, which is a bit slower, but other people could benefit from reading the discussion. --Alexander (talk) 07:07, 20 July 2014 (UTC)[reply]

To access IRC you don't need specific software, just click on top right link on my user page. I have not yet a specific idea, just a series of try, that's why I'd like to test and see the real time feedback. I'm going to connect now. --Andyrom75 (talk) 07:19, 20 July 2014 (UTC)[reply]

Sorry, not now. I have to leave for some hours. Evening (CET) would be better. --Alexander (talk) 08:03, 20 July 2014 (UTC)[reply]

Ok good to know, because I was waiting for you but I need to exit as well :-P --Andyrom75 (talk) 08:15, 20 July 2014 (UTC)[reply]

Possible solutions[edit]

Together with Andyrom75, we found a solution or even multiple solutions that rely on the way how we draw POI markers. Presently, each marker is a square box of the same size, and the number has to fit into this box. Given different fonts used in the mobile and desktop versions, paddings and other settings should be different in Common.css and Mobile.css, and one has to tweak the code in Mobile.css accordingly. Another solution is to adjust the box size to the number, as we do in ru.voy (an example is here). The drawback (although I don't consider it as a drawback) is that boxes with two-digit numbers have rectangular shape. On the other hand, we can use exactly the same code in Common.css and Mobile.css, and the whole thing is simpler and more robust.

I can modify Mobile.css in any of these fashions, but I would like to hear your opinions first. --Alexander (talk) 09:11, 21 July 2014 (UTC)[reply]

I prefer the solution of ru.voy because it is universally applicable. -- Joachim Mey2008 (talk) 09:24, 21 July 2014 (UTC)[reply]

As long as the issue is of no interest to anyone, I changed the format of POI markers to what I and Joachim prefer. Now the markers should be shown properly in both desktop and mobile versions. Please, let me know if you don't see the markers, or their position is skewed. --Alexander (talk) 17:48, 28 July 2014 (UTC)[reply]

Tested on http://www.browserstack.com/screenshots . Works on all current operating systems and browsers, both in desktop mode and mobile mode. The best solution in my opinion. -- Joachim Mey2008 (talk) 04:42, 29 July 2014 (UTC)[reply]

The #iferror statement containing #coordinates is not necessary and can be removed. Pages containing errors can be found here. --RolandUnger (talk) 13:32, 31 October 2014 (UTC)[reply]

Assuming I've understood correctly, this edit should do what you've suggested. -- Ryan • (talk) • 13:41, 31 October 2014 (UTC)[reply]

I added {{#coordinates:{{{lat|}}}|{{{long|}}}|name={{{name|}}}}} because it is important for providing Geo information. #coordinates gives no red error statements, so you cannot check it with #iferror. --RolandUnger (talk) 13:55, 31 October 2014 (UTC)[reply]

Then saving en.wikivoyage.org for offline use for Kiwix (an offline Mediawiki reader) "noprint" class in <span class="noprint plainlinks"> before {{PoiMap2 breaks creation of geo: links at listing's map number component. See Kiwix bug report for a discussion.

In the above-mentioned span I've replaced noprint class with nourlexpansion (which picks up a rule from MediaWiki:Print.css) and commented out a pairwise span: <span class="printonly listing-map" ...> ... </span>. It seems to work quite fine both in a browser's screen and in print (for example Hillerød).

A similar change was implemented in ru.wikivoyage.org a couple of months ago.

So would it be fine to keep this change? --Vadp (talk) 11:13, 4 March 2015 (UTC)[reply]

See Wikivoyage:Travellers' pub#Changes to listing templates?. If the above listing template change is reverted then this change will also need to be reverted. -- Ryan • (talk) • 18:10, 4 March 2015 (UTC)[reply]

As far as I can understand, this change should only affect print rendering, even then it shouldn't have any visual effect (let alone commented code, which shouldn't have any effect either). Anyway do you want to revert it back? Otherwise I could try tomorrow to move it back and forth to see if it's really a culprit. --Vadp (talk) 19:11, 4 March 2015 (UTC)[reply]

This change was the cause of the visual changes - I verified by reverting your changes (without saving) and then previewing an article. The CSS change above fixes the problem, but if there are other side-effects reported then both the CSS fix and the original template change would probably need to be reverted. -- Ryan • (talk) • 19:18, 4 March 2015 (UTC)[reply]

If so, then I made something wrong. Perhaps it's better to revert the change and let me think it over again. --Vadp (talk) 19:22, 4 March 2015 (UTC)[reply]

I've made a different version of this change. It seems to be fine with FF, Chrome, and IE. --Vadp (talk) 13:02, 5 March 2015 (UTC)[reply]

I'm not seeing the same issues that I saw yesterday. Thanks for the updated fix. -- Ryan • (talk) • 16:10, 5 March 2015 (UTC)[reply]

Thanks Ryan. I'm going to modify Template:Marker a similar way. -- Vadp (talk) 16:19, 5 March 2015 (UTC)[reply]

Done. See Template_talk:Marker#noprint_in_span_class_just_before_PoiMap2. -- Vadp (talk) 16:35, 5 March 2015 (UTC)[reply]

Sorry, I'm confused. Don't we want this to noprint? Powers ^(talk) 00:33, 6 March 2015 (UTC)[reply]

In this case the reason for noprint/printonly branching was to suppress printing of an URL to poimap2 map after listing's numbered box, but nourlexpansion does the same thing, so this noprint/printonly pair was merged into a single spam. If such a span needs to be styled differently on a screen and at a printout then this can be done via CSS.

Actually Ryan did make quite a right thing when he edited MediaWiki:Common.css. My fault was that I didn't changed Template:Marker at the same time when I made changes to Template:Listing, so they did look different. -- Vadp (talk) 08:30, 6 March 2015 (UTC)[reply]

Swept in from the pub

As you can see in this screenshot, some change has been made to the listing template whereby the indicator numbers for the dynamic map are rendered way too close to the beginning of the text. It's ugly. Is anyone else having this problem? If so, can it be fixed? -- AndreCarrotflower (talk) 15:50, 4 March 2015 (UTC)[reply]

→ Template talk:Listing#noprint in span class just before PoiMap2. I don't have time to look at the issue right now, but maybe someone else can. -- Ryan • (talk) • 16:32, 4 March 2015 (UTC)[reply]

I believe that Special:Diff/2733536/2739855 will resolve this issue, although I only tested on Chrome. If it causes issues on other browsers please revert. -- Ryan • (talk) • 18:09, 4 March 2015 (UTC)[reply]

BTW, since "go" is a usable type for a marker, how can I use it as a standalone listing? PrinceGloria (talk) 18:23, 4 March 2015 (UTC)[reply]

.  --Traveler100 (talk) 18:42, 4 March 2015 (UTC)[reply]

We've solved one problem and created another one: the listing templates look fine now, but in all instances of Template:Marker there's a huge gap between the indicator number and what's listed in the "name=" argument (see screenshot). I hate to be a pain, but could we fix that too? -- AndreCarrotflower (talk) 21:15, 4 March 2015 (UTC)[reply]

I reverted all recent changes, so the listing template will be back to how it was last night. -- Ryan • (talk) • 21:23, 4 March 2015 (UTC)[reply]

I've made a different version for this change. It seems to be quite fine with FF, Chrome, and IE. BTW the effect shown up here did not appear at the template's sandbox --Vadp (talk) 13:03, 5 March 2015 (UTC)[reply]

On a related issue; can someone point me to any discussion about the "last updated" addition to our listings? JuliasTravels (talk) 08:47, 5 March 2015 (UTC)[reply]

Scroll up a little in the pub Hobbitschuster (talk) 14:21, 5 March 2015 (UTC)[reply]

Even though one can have type "go" or type "city" in a listing template - using the listing editor seems to hang on submit as these types do not appear to be included in the type drop down selection box... Does anyone else have this issue? - Matroc (talk) 05:43, 2 April 2015 (UTC)[reply]

I think nobody is against adding a new property for the Wikidata identifier? Should it be named just "wikidata"? Towards the beginning, so that people don't add details before seeing the information might actually be in Wikidata? Syced (talk) 07:00, 14 May 2015 (UTC)[reply]

We use to call it 'wdid'. --Alexander (talk) 08:08, 14 May 2015 (UTC)[reply]

The name 'wikidata' is clearer, what's a 'wdid'? K7L (talk) 13:01, 14 May 2015 (UTC)[reply]

I don't see the value in adding the attribute before we've worked out what if any functionality will eventually be involved, especially given the warning we were given about not slowing down the server by using this call too many times per page. Seems a bit premature to me. Working out such functionality will probably involve a massive rewrite of the template anyway, so if we're going to be experimenting, it would seem wiser to start a separate experimental template for the time being, and then move its contents here once we've worked out what we're actually trying to do and ensured that connecting listings to WD won't be slowing down pageloads, etc. Texugo (talk) 13:24, 14 May 2015 (UTC)[reply]

Why don't we copy this template to an experimental template at Template:wdlisting or something and then choose one huge city like Paris, replace the various see/do/eat/sleep listings on all that city's pages with the substituted listing forms, and then replace the "listing" call with a "wdlisting" call. They we'd have a good experimental setup with plenty of likely existing WD listings with which to experiment, without affecting the whole site. Texugo (talk) 13:40, 14 May 2015 (UTC)[reply]

The idea is to get the data into the wiki "page source", even if the template isn't displaying it or using it to look up anything else yet. That makes the information available to re-users of our content, such as WikiSherpa-style mashups (which link WV listings to OSM and WP data) or other-language Wikivoyages (which often have listing fields we don't, like Facebook, local-language WP and mobile telephone - many of which could be populated from Wikidata information). Certainly, the Wikivoyage: Listing editor needs to change to stop surreptitiously removing every field from {{listing}}s that it doesn't recognise, so that the data stays put until we decide how we are going to use it. The end use might end up being a listing template that pulls name, address, phone, lat/long, image and URL from Wikidata in the rare cases where a Wikidata item exists but the other fields are missing data. It might also be used to provide the Wikidata item to a robot script which fills in the missing fields (so that it's done once, and doesn't burden the servers beyond that). It might also be used by a listings editor, if an option were provided in the future where clicking a button automagically populates the standard contact information from the Wikidata record. Get the data into the template now, even if we're not using it yet. Once we (or a third-party re-using our content) comes up with the specifics of how or if to pull the other data from Wikidata into the listings, the link will be there. K7L (talk) 14:34, 14 May 2015 (UTC)[reply]

The main reason for adding Wikidata IDs as soon as possible is that they are the only way to identify a listing. Listings without identifiers are just stand-alone listings. Listings with identifiers can be re-used in many different ways, including those that K7L mentioned. This does not require any explicit link from Wikivoyage to Wikidata. This is simply the method to tag Wikivoyage listings, and proper tags are needed for any massive work.

'wdid' is an acronym for 'Wikidata ID'. --Alexander (talk) 15:22, 14 May 2015 (UTC)[reply]

External re-use? That can't be right; I was explicitly told that we shouldn't worry about what other people are doing with our data. Powers ^(talk) 17:37, 14 May 2015 (UTC)[reply]

Well, if you don't care about Wikivoyage in other languages, you essentially ruin the idea that triggered the creation of all these language versions back in the WT times. I am not entirely surprised by this attitude, but it can't be appreciated. --Alexander (talk) 18:11, 14 May 2015 (UTC)[reply]

Wait, what? Powers ^(talk) 01:00, 15 May 2015 (UTC)[reply]

Bot-filling of fields missing in one language but present in another language was mentioned before. I added thousands of coordinates to listings in Russian Wikivoyage, and most of them are missing for example in English Wikivoyage, but I do not have time to scan all language editions and add the coordinated. This should be a bot work, and the only way to make it functional is to add the Wikidata parameter (whatever it would be called) into the listing template.--Ymblanter (talk) 10:47, 17 May 2015 (UTC)[reply]

It's inaccurate to say that reuse on another language version is external reuse. I don't think anyone is advocating against cooperation between language versions. However, for it to work that way, to the extent that it would even be worth using a bot, there would have to be massive item creation on WD for every little hotel/motel/b&b; restaurant/diner/fast food joint, souvenir shop, internet cafe, etc etc etc that we list here, all subject to the same maintenance that we fall behind on here regarding continued existence, website/hour changes, not to mention the fact that language versions are not bound to choose the same listings, any listings we choose to delist here will be essentially left unmaintained on WD, and there would inevitably be a great many duplicates as existing listings across the various versions have inevitably titled the same place slightly differently, and it takes pretty sharp vigilance to make sure "London Hyatt", "Hyatt London", "Hyatt Londres", "Hyatt de Londres", and ハイアットロンドン all get assigned to the same item and not different ones (also note that there would need to be a constant mechanism to automatically re-update the item numbers here on WV as they get corrected and merged there).

I'm sure proponents here might be just fine with all of the above, but would Wikidata actually be okay with it? Does WD actually want an item for every random kind of establishment we might recommend to a tourist and are they willing to work with us to overcome all the complex issues that will undoubtedly arise?

Another point is that I don't quite understand how a bot could be all that helpful in establishing the connections needed for it to pull data from WD in the first place. Even for things which already have a WD item, presumably the WD item number would still have to be entered manually on each language version before the bot would make the correct associations and be able to follow along pulling coordinates from WD, and if you're already sitting there cross-referencing WV and WD manually, why wouldn't you just go ahead and put the coordinates in then? Texugo (talk) 15:25, 17 May 2015 (UTC)[reply]

Other language versions of Wikivoyage are not external, so no, I wasn't referring to them when I was talking about "external re-use". K7L mentioned "re-users of our content", and I was responding to that by pointing out that I've been told in the past that we should only format our data for our use and not consider external re-users. Powers ^(talk) 15:55, 17 May 2015 (UTC)[reply]

I'd presume we'd identify which are the same listing/different language by matching fields such as telephone numbers and Internet addresses; we wouldn't rely on name alone. Certainly, one major advantage of WV over WT is that it can be easily downloaded for re-use; I don't know of anything requiring that we either consider or ignore other uses for the data, beyond the standard "the print version matters" disclaimer. K7L (talk) 16:09, 17 May 2015 (UTC)[reply]

I don't want to inflame what has been a tense subject of discussion in the past, but with regards to re-use of data I think that it is important to clarify that there has never (to my knowledge) been a blanket statement made that we "should not consider external re-users". We definitely should consider external re-users, but in a discussion that ranged through several threads regarding a specific subject the point was made that there are limits to our responsibility to potential re-users. The statement that I think is being referenced earlier in this thread was "We do not have some duty to expend the extra effort to ensure our data is technically perfect enough for it to be used for any other imaginable tertiary purpose that someone might want to data-mine our site for" (Special:Diff/2522003/2522013). -- Ryan • (talk) • 16:41, 17 May 2015 (UTC)[reply]

(Edit conflict -responding to K7L above) That partially answers one of my lesser concerns, but it still appears to me that there would be a pretty extreme amount of manual work needed to get this set up properly. What of my other concerns expressed above? Texugo (talk) 16:45, 17 May 2015 (UTC)[reply]

I kind of see ALL OR NOTHINGn attitude in this thread. Sure, there are problems with keeping all hotels and restaurants on Wikidata - though it is possible after a proper discussion, I accidentally happen to be an admin and a crat there. However, even if at the first stage we do not care about hotels and restaurants, we certainly can propagate coordinated of the sites between different Wikivoyage language versions. Most of the sights can be uncontroversially kept on Wikidata, and many of them do not have coordinated in Wikivoyage listings. If it is done by bot (and Alexander gives good arguments why it should be done by bot rather than read directly from Wikidata), different format of listings in different language versions is not a big problem, but the Wikidata parameter is imperative.--Ymblanter (talk) 17:14, 17 May 2015 (UTC)[reply]

Adding hotels and restaurants to Wikidata is irrelevant now. Of course, we can go to Wikidata and discuss this, but we first need a good proposal and a clear understanding of what we do with this information. So far there is no understanding, and some "scattered" opinions about many different things including re-using of the content by external users, which is by all means irrelevant here. The point is that Wikidata IDs that already exist are a good identifier for some of the Wikivoyage listings. The moment these identifiers are added, they can be applied to many interesting things, and we can see how to synchronize the data between different languages. Last but not least, editors (at least regular editors) will get used to the fact that listings have identifiers and will learn to add them wherever possible. This is the very first step to any synchronization between the listings. If we fail to do this, we won't be able to go any further.

Regarding the bots and applications, Texugo can try to copy coordinates, images and other fields from any other language version (I would suggest Russian, Ukranian, Hebrew or Chinese, though; for obvious reasons) and see at which point this job will become boring. I don't think you will make more than 20. This is a massive work, and any massive work should be done by bot. Wikidata IDs are easy to add because you can find them through Wikipedia in your favorite language instead of dealing with foreign scripts. --Alexander (talk) 17:31, 17 May 2015 (UTC)[reply]

I'm just trying to establish how useful this will actually be and what the process would be, i.e. how much of it could actually be done by a bot. If it's going to end up applying to only 20% of our total listings and then come in handy in for those in a random 10% of cases, I question whether our effort will be worth it, particularly if there are steps which bots won't be able to handle effectively. What is the process we are talking about here? Say we start a wv:ja version and someone adds only ルーヴル美術館 and an address in Japanese. What is the logical process that will allow a bot to recognize and add more information to that without manual work? Texugo (talk) 17:46, 17 May 2015 (UTC)[reply]

The wikidata ID should be added manually to every listing, I do not see any current workaround. However, once they have been added manually, a bot can do a lot of things.--Ymblanter (talk) 18:00, 17 May 2015 (UTC)[reply]

Some of the IDs can be guessed from fields like phone numbers, but this is not a universal mechanism that can be relied upon. --Alexander (talk) 18:05, 17 May 2015 (UTC)[reply]

The bot will need the wdid= of wikidata= field in order to identify the listing. When this field is present, and the bot sees another empty field, which is not empty in another language version, it will fill the empty field with the content taken from the other language version. Later bot can also compare content in different languages and inform editors (by posting a message on the talk page) about changes that will be considered important enough to deserve human attention. --Alexander (talk) 18:05, 17 May 2015 (UTC)[reply]

And if you're going to manually get on WD for every listing, search for existing items, and copy the item number across, why not just copy the missing data across instead? It seems like adding more manual work than the bot would actually save you in the end. Texugo (talk) 18:19, 17 May 2015 (UTC)[reply]

Because the missing data can be just not there yet. They may sit in Chinese Wikivoyage waiting for a bot, or just come in a year from now.--Ymblanter (talk) 18:25, 17 May 2015 (UTC)[reply]

And because it is additional work that should not be done manually. It may seem very easy to copy all fields for 1-2-10 listings, but copying information for every listing is not possible. Just give it a try. --Alexander (talk) 18:28, 17 May 2015 (UTC)[reply]

"All fields" is just barely more than one field in many cases, because the only fields that could really be done automatically are the number-based fields: phone and coordinates and, if we can work out a functional and properly robust encoding/decoding mechanism, hours. For all practical purposes, at present you are talking about copying one number field instead of two, since to include hours will require quite a bit of future development to get a working system. Texugo (talk) 18:36, 17 May 2015 (UTC)[reply]

lat=, long=, image=, phone=, url=, fax=, email=. Not to mention that unique identifiers, such as Wikidata IDs, facilitate any type of automatic processing that can be developed in the future. Having no identifiers means that no synchronization between the listings in different language versions will be possible ever. --Alexander (talk)