Template talk:Listing Voyage Tips and guide

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.

Contents

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

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) 18:52, 17 May 2015 (UTC)Reply

It looks like there is an existing Wikidata record for pretty much every topic in the encyclopaedia, mostly created by bot scripts which pull the co-ordinates, the page categories and the data from the infoboxes. This is true even if the text was never translated to any non-English wiki. K7L (talk) 19:01, 17 May 2015 (UTC)Reply

For what it's worth, I'd be in favor of adding IDs to listings since I don't see any harm and can imagine cases where it would be useful, although I share some of Texugo's concerns about how a Wikidata property will actually be used in practice, and how we would sync IDs across language versions. This seems like a case where it would be worthwhile putting some IDs in place and seeing how bot writers utilize them, and if at some point in the future we find that they are unused or that a different implementation would have been better then it would be easy to run an automated tool to remove them. -- Ryan • (talk) • 19:04, 17 May 2015 (UTC)Reply

If we do try to link same-venue listings across languages, the telephone and URL are somewhat unique identifiers, but we'd have to be cautious... +1-800-HOLIDAY and the like are on a lot of listings and would have to be excluded as two members of the same chain in the same city might list these. A bot could detect that +1-800-325-3535 is on a huge number of Sheraton hotels, while "PEnnsylvania 6-5000" (+1-212-736-5000) appears exactly once in all of Wikivoyage - but this would require extra effort to implement. Wikidata is useful as an identifier because it's unique. They don't exist for every country motel and B&B listed in en.voy, but they do exist for museums, major landmarks, sites on national historic registers and a few other key venues. K7L (talk) 19:09, 17 May 2015 (UTC)Reply

(edit conflict about three times in a row) You all might be thinking that I am against this whole idea, and I assure you that is really not the case. I actually just want us to fully examine and appreciate the complexity of what we're getting ourselves into here, so that we can figure out what approach is actually going to be most useful in the long run. I don't want to see us get too excited and take an overly simplistic and ultimately overambitious approach that will eventually be abandoned, nor any piecemeal approach that may not ultimately be a useful component of a more comprehensive future solution, thereby putting us on the path for much future rework. At this point I don't see any problem with sticking wd item numbers in there for purposes of experimentation with types of bots, though I would still urge us to, rather than haphazardly start filling in wdid fields across the site, choose a single test city or region to concentrate our efforts on first, so we can start working out the functional and technical issues before spreading our energies all over the place. I do think there are lots of interesting ideas here, some of which have promise, but I also think some questions remain about the manual work vs. payoff, about the manner in which we can best use bots to fill things in, and, when a change is made in one place, how to best ensure that it then gets reflected in WD and the other language versions, and a number of other issues as well. So let's take baby steps and focus on developing the functionality first before we commit ourselves to loads of arduous groundwork. Texugo (talk) 19:17, 17 May 2015 (UTC)Reply

Sounds like a good idea.--Ymblanter (talk) 19:47, 17 May 2015 (UTC)Reply

Creating the 'wikidata=' field is harmless. It would mean stopping the listing editor from covertly removing any field it doesn't recognise, and it would mean ending the manual removal of the wikidata field. That's about all it would affect, unless and until the template (or some external piece of code) changes to actually act on what's there, it has no effect. I don't believe there's any uncertainty or controversy as to what goes in the field (it can only be one thing, 'wikidata=Q...' with the number of the wikidata item). That's a completely separate matter from Wikivoyage:Bot policy and any bot script which populates the field from external sources still couldn't be launched site-wide unless and until it gets approval. The template, as it stands now, will safely ignore the field, so its existence will create no visible effect on the wiki itself. K7L (talk) 03:23, 18 May 2015 (UTC)Reply

That is already understood, but if we ultimately end up doing nothing much with that attribute, it will have been a waste of effort to have spread them all over the site. And conversely, we may end up finding ways to fill in a lot of those wdid's by bot, in which case efforts to fill them in manually across the site will also prove to have been unnecessarily premature. I see no compelling reason to diffuse our efforts sitewide until we have figured out what if anything we will be doing with them in practice. We need to choose a city or region and make it a focal point for everyone's efforts until we have a better idea of what we're doing. Texugo (talk) 12:22, 18 May 2015 (UTC)Reply

No. We had the "lat=, long=" fields long before anyone thought of plotting the info on a dynamic map. They weren't being used for much of anything, but at the same time they were doing no harm and the data was left well enough alone instead of being the target of sneaky attempts to remove it. I see no reason why doing the same here would harm anything. K7L (talk) 15:20, 18 May 2015 (UTC)Reply

It's almost as if you didn't even read my last post. Texugo (talk) 15:49, 18 May 2015 (UTC)Reply

I am afraid you are talking of two different things here. The first ios whether there should be the wdid (or wikidata, or whatever) field. It can be easily added by bot across the project, and it seems that everybody in this discussion either support or at least do not object adding the field. The second issue is whether and how much effort should be made to manually fill in this field in the listings. In this respect, the suggestion of Texugo seems reasonable to me: without prohibiting anybody to fill anything, just decide to concentrate on some piece or pieces everybody would be somewhat familiar with (London? NYC?) and see what actually could be done, formulate bot tasks, add the Wikidata index to the field, coordinate it with other language projects and with Wikidata etc).--Ymblanter (talk) 19:23, 18 May 2015 (UTC)Reply

In the template manual is written that only the "name" parameter is mandatory, but technically is possible to add a listing without that parameter and it works correctly (see below example) and there's no maintainance category to collect these occurrences.

• . Maybe wierd but working. (updated Jun 2015)

So my question is, do we want to keep the current technical asset and change the manual with "name is strongly recommended" or do we want to keep it mandatory and change the template? --Andyrom75 (talk) 06:55, 29 June 2015 (UTC)Reply

See WV:Listings#Complex attractions and WV:Listings#Multiple locations for two common use cases in which the name parameter might be skipped. -- Ryan • (talk) • 14:09, 29 June 2015 (UTC)Reply

Ryan, I'm not sure to have understood the example, but in WV:Listings#Multiple locations each listing has a name: Harold's Chicken Shack, #40 and #7. --Andyrom75 (talk) 14:17, 29 June 2015 (UTC)Reply

The examples don't show nameless listings, but those are the use cases in which one might find them. Powers ^(talk) 19:14, 29 June 2015 (UTC)Reply

Ok, but the original question is: can a listing be nameless? If the answer is yes, the manual must be change, if the answer is no, the template must be change to avoid that it would happen. Which is the right thing to do? --Andyrom75 (talk) 21:48, 29 June 2015 (UTC)Reply

What Powers is saying is that yes, a template can be nameless, as in the two use-cases for complex attractions or multiple locations. While the multiple locations example isn't nameless on WV:Listings#Multiple locations, in most such cases there would be nothing to include for the name since the name would have already been specified in the parent listing tag. -- Ryan • (talk) • 22:06, 29 June 2015 (UTC)Reply

Got it. So the manual can be change from "Only name is mandatory" to "There's no mandatory field, but it strongly recommended to insert at least the name". Is it ok? --Andyrom75 (talk) 22:30, 29 June 2015 (UTC)Reply

At least one field must be filled in; otherwise you end up with just a period. But it doesn't have to the be the name field. Powers ^(talk) 20:54, 30 June 2015 (UTC)Reply

Got it. I've change the manual accordingly. --Andyrom75 (talk) 21:18, 30 June 2015 (UTC)Reply

Swept in from the pub

I've been spending some time in recent weeks on a rewrite of the listing editor, and it's now at the point where wider feedback and testing would be very helpful.

Update 8-Aug: changes are now live for all users, no configuration is required

Any logged-in user who is interested can test out the new listing editor by doing the following:

1. Click on the "Preferences" link at the top right of any page.
2. Click on the "Gadgets" tab on the preferences page.
3. Uncheck the "ListingEditor" box under the "General" heading (do not skip this step - the old & new listing editor cannot be run at the same time).
4. Check the "ListingEditor2 (beta)" box under the "Experimental" heading.
5. Click the "Save" button at the bottom of the page to save your gadget settings.
6. Go to any article and add or edit a listing using the new listing editor.

Changes in the new version:

UI Changes:

• The listing editor dialog box and its fields will now expand to fill up more of the available screen space, allowing listing fields to be edited without the need for scrolling.
• The listing editor dialog box will now more cleanly collapse from two columns to a single column on very narrow screens.
• Standard fields that have pre-existing values will now always be displayed. As an example, when editing a "sleep" listing that has existing "hours" data, "hours" will appear as an editable field in addition to the standard "checkin" and "checkout" fields.
• The current listing editor suppresses the "fax" field in the listing editor dialog since it is seldom used; the new version additionally suppresses "alt" in order to make better use of screen space. Note that if either field has a pre-existing value then it will not be suppressed.

Functional Changes

• When editing a listing, users can now enter an edit summary and mark an edit as minor.
• The listing editor will no longer automatically delete unrecognized attributes like "phoneextra" or "wikipedia". See MediaWiki talk:Gadget-ListingEditor.js#Extra fields.

Fixes

• Multi-paragraph listings are now editable, and newlines will be automatically converted to <p> tags so that the listing displays properly per mw:Help:Lists#Paragraphs in lists.
• If there is a failure that prevents saving the listing, the listing editor dialog will re-display with all of the user's changes intact so that no work is lost. Additionally, submissions should no longer fail if the user's session expires (due to the use of mw.Api#postWithToken). See Wikivoyage talk:Listing editor#Error adding listing.
• Other minor fixes.

Feedback and bug reports would be much appreciated - if you don't like something, want to see additional changes, etc please comment. If you are reporting a bug, please be sure to state what browser and OS you're using and how to reproduce the problem (article & listing you tried to edit, what action you took, etc) since if I can't reproduce the issue it will be much harder to fix. There is some work remaining to make the code easier to customize for other language versions, and a few bugs that exist with the current listing editor still exist with the new listing editor (example: User:Wrh2/Sandbox#Content field & equal sign), but I think that this version is close to being ready for widespread use. Thanks in advance to anyone willing to provide feedback. -- Ryan • (talk) • 05:09, 21 July 2015 (UTC)Reply

Just wondering if price could also have the $ symbol listed as well? I know that it's easy to find on a keyboard but just thinking it would be nice to have it included along with the others. -- WOSlinker (talk) 10:31, 21 July 2015 (UTC)Reply

Is it technologically possible to have some things that are the same for huge geographical areas or just one city automatically appear in a listing? E.g. the national currency (e.g. any listing whose breadcrumbs is within the US automatically gives USD for the price) the local area code (I have to only enter the local number without the local area code) or the country code (e.g. all listings in Nicaragua automatically give +505 at the beginning of their phone number whereas all those in Germany automatically give +49). Furthermore something that may (or may not) be an issue is that in Germany for example some cities have more than one ZIP code. The ZIP code is needed as part of the address, but currently addresses only include street name and number. Wouldn't it be a good idea to have a field to enter (non default) ZIP-codes? After all, some GPS devices work better with them and the postal service requires them. Hobbitschuster (talk) 12:33, 21 July 2015 (UTC)Reply

There is no such thing as a "German ZIP code", short of resuming a US military occupation there. Zone Improvement Program™, ZIP™ and ZIP+4™ are (or were) trademarks of the US Postal Service.™ K7L (talk) 13:21, 22 July 2015 (UTC)Reply

I know, but most non-Germans don't know what the hell a "Postleitzahl" is. And it is functionally the same thing as a ZIP-code. I was (trying to) use it as a generic term, just like not everybody requesting a "Kleenex" will be outraged when getting the generic knock-off... Hobbitschuster (talk) 14:31, 23 July 2015 (UTC)Reply

"Post(al) code" will be an uncontroversial generic term, I think. :-) Ikan Kekek (talk) 18:08, 23 July 2015 (UTC)Reply

I shall keep that in mind for future reference... Hobbitschuster (talk) 18:55, 23 July 2015 (UTC)Reply

Wondering if it would be useful to also store this type of data on Wikidata? Or store it entirely their and then all languages of Wikivoyage could pull from a single source? We could have a bot initially move it over. Travel Doc James (talk · contribs · email) 15:52, 21 July 2015 (UTC)Reply

That might run into compatibility issues. While de-WV is currently wondering about a similar issues, over there they don't use listings but rather "vcards" which work differently (and confuse my humble self to no end). While I do think that having listings (or most of the information contained in them) stored in Wikidata is a good idea and should be the end goal, some cross-language compatibility seem to be more pressing. But as I am not a technical expert of any kind, I may well be much mistaken... Hobbitschuster (talk) 16:00, 21 July 2015 (UTC)Reply

I would imagine that each place would be stored as an item. These items would then have multiple properties. These properties would than be individually pulled from Wikidata and presented by each language how they wish. Thus if en likes a certain 8 properties in a certain format and de likes 10 properties in a certain format both languages could get what they wish while still using wikidata. At least that is my understanding. Travel Doc James (talk · contribs · email) 16:13, 21 July 2015 (UTC)Reply

@Jmh649: Regarding wikidata, see meta:Wikivoyage/Lounge#Wikidata for listings! for current status on efforts to move listing information to wikidata. There are a lot of issues to resolve, both from a technical and a process standpoint, so sharing listing information remains something that is unlikely to happen in the near future.

@WOSlinker: Regarding adding the "$" symbol, that should be easy enough if it is something people would like to see. Ideally we should have more currency symbols available, but there is limited space in the dialog UI, so suggestions/mockups for implementing a drop-down or similar UI element might be useful.

@Hobbitschuster: Regarding automatically loading country-specific data like country codes, that would be a great feature but isn't straightforward to implement - determining the country requires traversing the category hierarchy, which would make the listing editor much slower, and would also require a lot of additional logic. It's an excellent idea, but in the interest of getting the current updates live without having to do significantly more development work it is probably something that is better handled as a future feature request instead of in the current update.

Regarding adding zip code as a listing editor field, that would require a consensus to add that field to the listing template - if the template is changed then it would be easy to add support in the listing editor, but if it's OK I would ask that changes to the template be moved to a separate discussion so that this discussion can stay focused on the current updates to the listing editor. -- Ryan • (talk) • 16:20, 21 July 2015 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Sure. I wanted to just raise those points as "nice to have" for the next upgrade/update... And as I sadi, my technical understanding of these matters is limited at best. If any of them can be done without too much work or wasting resources, I am all for them. Otherwise, there are bigger marine vertebrates that harken the pan ;-) Hobbitschuster (talk) 17:43, 21 July 2015 (UTC)Reply

Always bigger fish to fry! ;) - Matroc (talk) 03:46, 23 July 2015 (UTC)Reply

Just wondering if the country could be determined with code as below (with some added error checking and a little more code to work when on the actual country page as the code below only works on subpages of the country)? Anyway, it would be better as a feature for v3 rather than delaying v2.-- WOSlinker (talk) 22:07, 21 July 2015 (UTC)Reply

var level1 = $("#contentSub a:nth-child(1)").html();
var level2 = $("#contentSub a:nth-child(2)").html();
var level3 = $("#contentSub a:nth-child(3)").html();
var country;
if (level1 == 'Asia') country=level3;
if (level1 == 'Africa') country=level3;
if (level1 == 'Europe') country=level3;
if (level1 == 'Oceania') country=level2;
if (level1 == 'North America') country=level2;
if (level1 == 'North America' && level2 == 'Central America') country=level3;
if (level1 == 'South America') country=level2;

Possible future reference if data is in Wikidata then one should be able to retrieve Calling Code from there or go to actual Wikidata country record and retrieve it as well (may be a long way off yet) - as usual there may be an issue with timing/parsing that might present a problem - Matroc (talk) 03:46, 23 July 2015 (UTC)Reply

I use the 'alt' field very frequently; is there any way we can retain it? Powers ^(talk) 00:07, 22 July 2015 (UTC)Reply

This edit restores the alt tag - the only downsides are that the listing editor will take up slightly more vertical space, and it may be more daunting for new users who see more fields to fill out. I don't feel strongly either way as there are good arguments both for displaying or suppressing the lesser-used fields. -- Ryan • (talk) • 01:00, 22 July 2015 (UTC)Reply

I, too, am strongly in favor of retaining "alt". -- AndreCarrotflower (talk) 03:13, 22 July 2015 (UTC)Reply

The "alt" field is probably more often misused to repeat the name of a hotel or insert some promotional text about it than it is used correctly, such as by giving the Chinese, Japanese, Korean, Russian, or Arabic name (for example) for a hotel or restaurant or its former name, but it is a useful field sometimes and is probably better to retain. Ikan Kekek (talk) 20:53, 22 July 2015 (UTC)Reply

Keep the alt field - Matroc (talk) 03:46, 23 July 2015 (UTC)Reply

Since there is a lot of work and discussion about Wikidata - For future version? - I believe that a Wikidata ID field could be added - Matroc (talk) 03:46, 23 July 2015 (UTC)Reply

I think alt is useful for displaying the names of POIs in both English and the local language; the first so the reader understands what it is, and the second for sign and conversation reference. James A ▪ talk 13:11, 23 July 2015 (UTC)Reply

Some extra requests:

1. Can we make Name a mandatory field?
2. Can we apply a Regular Expression checker on the Email field?
3. Can we reduce the width of the Latitude and Longitude fields?
4. Can we have a regular expression to recommend keeping the length of the values of Latitude and Longitude fields to 4 decimals?
5. Can Type be the first field on the form?

Andrewssi2 (talk) 03:57, 23 July 2015 (UTC)Reply

Thanks for the feedback. Name isn't actually a required field in all cases (see Template talk:Listing#Name is mandatory or not?), but the current listing editor does require that at least one of name, alt or address be non-null. Similarly, for very small places lat/long coordinates of up to 6-7 significant digits (within a foot) might be appropriate, and many GPS databases and mapping services (including http://maps.wikivoyage-ev.org/) return data at higher precisions, so I think we should be cautious about being too prescriptive (see also w:Wikipedia:WikiProject Geographical coordinates#Precision guidelines). A checker on email makes sense and I'll add that to the TODO list. As to moving the "type" field, if others want to see it moved it's an easy change, although personally I would think we might want to de-emphasize it since it is something that is set automatically based on section type and unlikely to change. -- Ryan • (talk) • 04:40, 23 July 2015 (UTC)Reply

Simple email address validation has now been added - invalid emails can still get through, but it will catch common errors, which I think is better than trying to get too fancy and accidentally blocking a valid email. The current validator just looks for "[email protected]", with the only stipulation being that "something" must not be an "@" or whitespace - this means that an email address like ".@..." would get through, but again, I think letting a bad email through is preferable to accidentally blocking good emails. Feedback and testing appreciated as always. -- Ryan • (talk) • 05:09, 23 July 2015 (UTC)Reply

I tried the new editor yesterday and today, it is Wonderful! Especially great to see that it fixes the session issue, no more losing carefully written text in an old browser tab :-) What else to ask... link to Wikidata item and pre-filling of lat/long/name/alt/website/image from this Wikidata item? :-) (National Art Center sample) Syced (talk) 02:44, 24 July 2015 (UTC)Reply

First, thanks to everyone who took time to provide testing & feedback. I think most of the above comments have been addressed, with a few items moved to WV:Listing editor#Feature requests to be considered in the future, but there are (I think) two remaining suggestions from the thread above that would benefit from additional comment:

1. Should the list of currency symbols also include "$"?
2. Should the "type" drop-down be the first field on the form?

Regarding #1, there is limited space for currency symbols, so while adding just one more is probably fine, it would be good to get an idea of whether people want to use the limited space for the "$" symbol or if we should just leave things as they are. If anyone has an idea for a UI that would allow more symbols to be included as options, via a drop-down or other UI, and is willing to create a mock-up then I can look into making a bigger change. Longer term, Hobbitschuster's suggestion about figuring out how to display the currency symbol appropriate for the country being edited is a good one.

Regarding #2, making the listing "type" field the first item in the editor is an easy change to make, but since listing tag type should almost always match the section type it seems like an equally valid argument could be made for leaving the listing type drop-down where it is, or even suppressing it altogether. Comments would be appreciated.

If I've missed something, or there are additional bug fixes or changes to make, please add them below. Thanks in advance! -- Ryan • (talk) • 17:45, 25 July 2015 (UTC)Reply

I have to add, that in some countries there is a "parallel currency" (usually the dollar, but in some cases the Euro) that is used for the price of many high value goods, such as hotels geared towards international visitors, whereas other things (say food) are (at least officially) priced in the national currency. As those countries tend to have high inflation and prices in the parallel currency are more stable, it might make sense to treat them as if their inofficial currency was in fact the official one. Hobbitschuster (talk) 23:54, 25 July 2015 (UTC)Reply

It does make sense, and we do :-) See Wikivoyage:Currency for the relevant policy. JuliasTravels (talk) 09:53, 29 July 2015 (UTC)Reply

@Ryan; thanks for all this work, it works perfectly well for me. As for your questions: 1) I don't mind the "$" sign to be included. The real issue remains of course that our selection of currencies there is almost random, and the listing editor has no link to all the other symbols one would need. Not that I know how to improve that :-) Hobbitschusters long term idea to display per destination is a good one indeed. 2) I would leave the type-dropdown exactly where it is. It's handy to have to fix wrong listings, but it's not something you want people to directly mess with if they open a listing in the right section. I imagine that >95% of the time, it should not be used. JuliasTravels (talk) 10:03, 29 July 2015 (UTC)Reply

Thanks for the feedback. Given that there is at least lukewarm support and no objection I've added the dollar sign to the list of currency symbols. I've got a bit more work to do to support some features used in other language versions, after which the new listing editor should hopefully be ready to go live. Further feedback and bug reports are of course still much appreciated. -- Ryan • (talk) • 03:28, 30 July 2015 (UTC)Reply

I agree with the addition of the dollar sign, simply because not everyone uses an American-style keyboard that has the dollar symbol at easy access. While I'm happy to leave it at that, you could say we're missing a few other important ones, such as the Indian rupee (₹), but let's await another solution first. Furthermore, I think the type field sits nice where it currently is, for the reasons mentioned above. James A ▪ talk 11:00, 30 July 2015 (UTC)Reply

The new version of the listing editor is now live for all users, and I've made additional changes so that captcha validation should be more reliable for anonymous users. Bug reports and feedback appreciated. -- Ryan • (talk) • 16:24, 8 August 2015 (UTC)Reply

There is a chunk of a code which is common between Template:Listing and Template:Marker. I'd suggest to create another Template:Marker-common to contain this common code. This way the both templates could be managed more easily as their common function and style will be kept at a single place, so you wouldn't need to make a same change twice and possibly introduce an inconsistency. Here is a proposed new code for the templates: User:Vadp/Marker-common, User:Vadp/Marker, User:Vadp/Listing. And a couple of test pages which use them: User:Vadp/Marker_Test, User:Vadp/Test2 --Vadim Shlyakhov (talk) 10:42, 31 December 2015 (UTC)Reply

The only real difference is that the marker template has an additional span tag. Rather than split marker into marker and marker-common, could probably just make listing call the marker template as the extra span is fine. The #coordinates should probably be added to the marker template as well. -- WOSlinker (talk) 11:05, 31 December 2015 (UTC)Reply

Well, you're quite right: an extra span would not make any harm! So this way Template:Listing simply calls Template:Marker. It looks quite fine at the test pages: User:Vadp/Marker_Test, User:Vadp/Test2 --Vadim Shlyakhov (talk) 12:04, 31 December 2015 (UTC)Reply

Always best to reuse code. Powers ^(talk) 01:46, 2 January 2016 (UTC)Reply

This change was implemented. Cheers! --Vadim Shlyakhov (talk) 10:16, 2 January 2016 (UTC)Reply

See Wikivoyage talk:Listings#Again_address_and_hCard_microformat

• Parameter counter= -- being implemented so that if you have for example an itinerary that contains multiple types such as see, do or eat etc. and you want them to be numbered consecutively while retaining the distinct colors for each type -- use new parameter counter= to do so. Can assign a distinct counter name: counter=mycounter. (When finally implemented I think should be added to parameter list) -- Matroc (talk) 09:26, 14 June 2016 (UTC)Reply

It seems like the addition of a url combined with an internally linked name in a See-listing somehow breaks the capitalization of the name, and moves the url icon in front of the name. Or am I overlooking something? Compare:

• 55.41575-1.706071 Alnwick Castle. The "poison garden" tour is entertaining. Seeing the castle might be a thrill for people who are really big fans of Rowan Atkinson's "Black Adder" or the Harry Potter films.  

and:

• 55.41575-1.706072 Alnwick Castle. The "poison garden" tour is entertaining. Seeing the castle might be a thrill for people who are really big fans of Rowan Atkinson's "Black Adder" or the Harry Potter films.  

Using the linked name without the url seems to work fine:

• 55.41575-1.706073 Alnwick Castle. The "poison garden" tour is entertaining. Seeing the castle might be a thrill for people who are really big fans of Rowan Atkinson's "Black Adder" or the Harry Potter films.  

Any ideas? JuliasTravels (talk) 11:10, 19 December 2016 (UTC)Reply

* {{see | name=[[Alnwick|Alnwick Castle]] | alt= | url=http://www.alnwickcastle.com/ | email= | address= | lat=55.41575 | long=-1.70607 | directions= | phone= | tollfree= | fax= | hours= | price= | wikipedia=Alnwick Castle | content=The "poison garden" tour is entertaining. Seeing the castle might be a thrill for people who are really big fans of Rowan Atkinson's "Black Adder" or the Harry Potter films. }}

The second example tries to have the same link point to two different places, a WV destination [[Alnwick|Alnwick Castle]] and an external site http://www.alnwickcastle.com/? I see no way the same link can point to two places at once, so no easy 'fix'. K7L (talk) 14:43, 19 December 2016 (UTC)Reply

Well, actually, the link itself works as good as it could be, with the name linking internally and the icon linking externally. The capitalization is the real issue, as it breaks the layout in a list (like here). I suppose this is only a problem in travel topics, where we have see listings in different destinations. How do we best handle such cases then? JuliasTravels (talk) 15:08, 19 December 2016 (UTC)Reply

Short of repeating the venue or town name just to get an anchor for the link text? Dunno: K7L (talk) 15:40, 19 December 2016 (UTC)Reply

• 55.41575-1.706074 Alnwick Castle. The "poison garden" tour is entertaining. Seeing Alnwick Castle might be a thrill for people who are really big fans of Rowan Atkinson's "Black Adder" or the Harry Potter films.  
• 55.41575-1.706075 Alnwick Castle, Alnwick. The "poison garden" tour is entertaining. Seeing the castle might be a thrill for people who are really big fans of Rowan Atkinson's "Black Adder" or the Harry Potter films.  

If there is an internal link then I would think an external link should be omitted, assuming that the linked article would include the external link as the official link and that it would always be preferable to use an internal link rather than an external one. I'm not entirely sure how to "fix" the listing template in this case - suppress the external link? display both? - but in general if I find a listing that includes both an internal and external link I remove the external link. -- Ryan • (talk) • 16:05, 19 December 2016 (UTC)Reply

I'd expect only a narrow portion of itinerary would use these sort of listings; something like fiction tourism would be prone to call out individual venues in various towns at which a story takes place. It might work in Radiator Springs or Harry Potter, but to do this to Trans-Siberian Highway would make no sense as 11000km of "there's a Rusburger stand at the roadside in Moscow" would quickly become too large and unwieldly. K7L (talk) 16:40, 19 December 2016 (UTC)Reply

Looking around a bit, fiction tourism doesn't seem the only kind of travel topic where listings (could) exist. Actually, our travel topics all have different approaches, sometimes even within the article. In Lighthouses, the same issue exists and was solved by linking internally in the address parameter. The downside is that a visitor still needs to click through (either internally or externally) to get address info, but that is acceptable, perhaps. Military_museums_and_sites_in_Australia only opts for the external links, and simply has no internal links to the places the listings are in. Finnish_National_Parks links to both, but uses a plain text list instead of listings... JuliasTravels (talk) 17:41, 19 December 2016 (UTC)Reply

I noticed that... Route 66 seems to list the cities and towns in the main article body, then save the POI list until the very end. The Disney version of the same road copies entire listings from local destination articles verbatim into the itinerary, then uses the paragraph body text between {{listing}}s to link the actual destination articles for the towns. If either article were recreated from scratch today? They might end up done some completely different way, perhaps with the destination city/village articles linked from each individual listing... who knows? K7L (talk) 18:01, 19 December 2016 (UTC)Reply

(edit conflict) Based on the examples cited, I think the right solution is the following:

1. If Wikivoyage has an article on the exact same subject then use an internal link and exclude the external link. In your example of Finnish National Parks none of the listings should include an external link since there is either an article or a red link to a Wikivoyage article about each park.
2. If Wikivoyage only has an article about the city or region that contains the destination, and no article specifically about the destination, include the external link and put the link to the destination article in the address field. In the Lighthouses example the external link would go to the lighthouse's external link, while the internal link in the address field would point to the article about the place where the lighthouse is located.

Having both an internal and external link should probably be flagged in a maintenance category as something that needs cleanup, and code should be added to the listing template to suppress the external link, but we likely need some agreement that doing so is the correct solution, and then someone with technical know-how would need to attempt an implementation. -- Ryan • (talk) • 17:57, 19 December 2016 (UTC)Reply

I'm inclined to suggest that we should avoid having a full listing for any POI in two different spots, even if one spot is an itinerary. Then we could fairly say that only the "real" full listing should carry an external link. But I also don't like wikilinks within the name field of a listing; it's confusing because only the tiny icon distinguishes an internal link from an external one, and having the two mixed in one list can be very confusing. Powers ^(talk) 18:46, 19 December 2016 (UTC)Reply

I doubt there is a one-size-fits-all answer. Certainly the WV city/destination article could be linked from the address (instead of the name) if that makes it easer to distinguish from a fully external site. Nonetheless, some itineraries will have POI's at a local/individual level of detail. For instance, an itinerary like Kentucky Bourbon Distilleries Tours ends up looking like a "pub crawl" of visits to individual POI's, much like fiction tourism generates itinerary of real places and POI's visited as research to create a fictional work, or directly mentioned and depicted in that work. A wine tour is a list of individual vineyards, a Trans-Canada Highway itinerary is an 8050km (5000 mile) list of major cities. Entirely different scale. K7L (talk) 18:57, 19 December 2016 (UTC)Reply

Just for the completeness of the discussion; the downside of avoiding any full listings of a POI in two separate articles would be that such itinerary articles can no longer be used on their own then (or printed, for that matter - although that's an ever smaller issue). For an itinerary with many POI's in different destinations, we'd basically require users to also comb through all of those destination articles. I don't know if that's a major objection though. JuliasTravels (talk) 13:51, 20 December 2016 (UTC)Reply

That's a fair argument. Perhaps we should include a field in Template:Listing for an internal wikilink, only to be used in such cases where the "real" listing is elsewhere? Powers ^(talk) 21:08, 27 December 2016 (UTC)Reply

{{Marker}} has an image= parameter that, if filled with an image from commons, makes that image appear on the mini map when clicking on the marker icon. It is possible to use this in listings by just adding something like image=File:foo.jpg to one of the listing templates such as {{see}}. Works like a charm, but as far as I can see, this feature/parameter is not documented on any of the listing-type template pages. Is there a specific reason for that (like "we don't want people to use that because …") or is it just because nobody has done it so far? Cheers, --El Grafo (talk) 13:41, 8 February 2017 (UTC)Reply

Now I saw this option is explained in Wikivoyage:Image_policy#Photos_of_businesses, so I guess it's really just a lack of documentation. I'd try to fix it myself but if there's anything I'm less familiar with mediawiki-wise than writing templates it's probably writing template documentations :-/ --El Grafo (talk) 14:13, 8 February 2017 (UTC)Reply

Swept in from the pub

This template seems to be the cause of a LOT of the Lint Errrors, and it seems in part due to the fact that it's being called with multi paragraph sections for listings, despite looking at the coding, not technically having been designed with this in mind.

The current 'live' version, uses SPAN tags, which is fine provided that the content inside such tag is a single paragraph's worth of text, (or what the HTML spec calls 'phrasing content' (https://html.spec.whatwg.org/multipage/dom.html#phrasing-content-2). However in some places, and may well be what is leading to the missing end (span) tag errors being generated is that in places so termed 'flow content' (https://html.spec.whatwg.org/multipage/dom.html#flow-content-2) is being placed inside the span concerned (as a result of it being supplied in a paramater.) This naturally confuses Mediawiki, which attempts to tidy up the resultant mal-formed HTML, and doesn't quite to do it, as it's being asked to do something that is bad HTML structuring (and should not technically work) to start with.

The two relevant SPAN's should under ideal circumstances be replaced with an Equivalent DIV, which should eliminate many of the reported 'missing-end' tag errors.

Some slight-re-ordering of how the remaining SPAN's are handled would also be recommended.

I strongly feel, these may also be the issue with a few other templates as well. Namely that you can't put flow-content where HTML5 (and thus the parser) expects to find 'phrasing-content'.

Can someone PLEASE take the time to examine and repair all relevant templates soon? ShakespeareFan00 (talk) 17:13, 25 April 2017 (UTC)Reply

Does this mean that Mantralayam#See is appearing in Special:LintErrors/missing-end-tag because there's a six-paragraph description in the listing? WhatamIdoing (talk) 04:55, 26 April 2017 (UTC)Reply

Yes ShakespeareFan00 (talk) 11:47, 26 April 2017 (UTC)Reply

Thanks. I spent a while looking at that article the other day, and I never figured out the problem.

Do we want to have six-paragraph-long descriptions in listings? Or even two-paragraph-long listings? WhatamIdoing (talk) 15:08, 26 April 2017 (UTC)Reply

I think that two paragraph long listings are quite desirable for cases where two different attractions are combined at the one address and with the one entry ticket e.g. "palace and gardens", a castle with a museum inside (particularly if the museum is not about the castle's history), or a river that is good for both fishing and canoeing. AlasdairW (talk) 19:47, 26 April 2017 (UTC)Reply

Would the issue disappear if one used <br> between paragraphs instead of newlines? -- Matroc (talk) 00:49, 27 April 2017 (UTC)Reply

You mean two line breaks. Only if you are using simple text and line breaks. The real solution would be to overhaul the listing template so you can supply multi-paragraph content in the relevant parameter, also I'd suggest carefully examining where it thinks the italics/bold formatting should be, I've had some listings where due to a combination of formatting the parser ended up with mismatched/striped <b></b> or <i></i> tags.ShakespeareFan00 (talk) 07:36, 27 April 2017 (UTC)Reply

ShakespeareFan00, WhatamIdoing, Matroc I've modified this template to reduce the "missing end tag lint error" from 176K to 2K (on top on other issues but definitely but in a minor quantity). I would remove all the BDI HTML tags added by Verdy p (I don't have them in it:voy and I think we show properly all the info) but since I'm not enough skilled on that tag so I've left it.

Remains to solve the multiline issue but I think the problem is server side, and we should open a bug on Phabricator.

Because of this issue I've changed also the main SPAN into DIV to allow DL to be nested (as correctly suggested and done in the past by ShakespeareFan00) because SPAN do not allow the creation of block inside it, while DIV does.

The problem is that a newline inserted with a wiki-syntax (two blank lines or a colon ad a first char of the line) it generates a DL HTML tag that instead of being nested inside the DIV tag of the listing it goes out ... apparently with no reason.

In this page I've created a basic example to see issue. Feel free to use it to open the Phabricator bug.

PS I've modified also Template:Marker code not avoid the introduction of a useless SPAN, even if this won't cause any lint errors. --Andyrom75 (talk) 22:07, 22 July 2017 (UTC)Reply

Once again, the choice between span and div is not simple because they are either restricting to inline only contents, or will infer block breaks. They do not allow mixed content types, and that's a main difference with BDI that does not have this problem at all (and also fixes the many issues related to international text mixing for example English and Arabic). I don't see what BDI can break, but its absence is clearly a bug in many pages where it create completely incorrect layouts. Verdy p (talk) 00:15, 24 July 2017 (UTC)Reply

Also I note that you (@Andyrom75:) have dropped many classes only based on false "Lint" reports, thinking they were unused or "unneeded": they were actually used by microformats (i.e. to be parsed by external parsers, even if they have no assigned CSS on this wiki). Anyway, microfotmats should have been converted to "microformats2" (i.e. using prefixes like "h-" for containers, and "p-", "dt-", "u-" for properties). You should read the specifications on "http://microformats.org/wiki/microformats2"... Almost properties in the "vcard" container are no longer detected by microformat parsers because you dropped them: they were tagged as classes, but not for CSS only). Dropping things you don't understand and without asking is a really bad practice. The usage of microformats was discussed multiple times and documented (partly). Though it's true that they should have been migrated to version 2 and not kept in their old legacy classes, i.e. the "vcard" class for µF objects should have become "h-card", and classes for µF properties like "note" should have become "p-note".

Verdy p (talk) 00:22, 24 July 2017 (UTC)Reply

If you want to look at what microformat parsers can do, just go to http://pin13.net/mf2/ and give an URL of a wiki page cointaining some listing entries

For example with this wikicode for an external URL opening the parser http://pin13.net/mf2/?url={{URLENCODE:{{CANONICALURL:Aachen}}|query}}, you'll get this parsed JSON data: there are now many missing properties, the "hcard" objects detected are very incomplete now, keeping only a "name" property (duplicated now in the "org" property) ang a geolocalisation, but not the many other properties (which where properly tagged in µF v1, still parsable in µF2, but not converted to plain µF v2).

I've restored the class names, to get back the following properties: "nickname, tel, fax, email, adr, note". However they should really be remapped to µF v2 and more precisely (because we still have some missing properties and badly replacements in parsers which will just concatenate multiple subproperties in fake "name" properties; notably for "geo" and "adr" subobjects, still incorrectly matched in µF1 but that would work better in µF2).

Note also that class names "listing-*" are not for microformats but apparently for internal use in this wiki for the properties editor or some local debugging. But they are not properly documented. In my opinion the µF2 classes should be enough for both usages (and the µF2 specification is much more versatile than the legacy µF1 class names). Verdy p (talk) 01:01, 24 July 2017 (UTC)Reply

Could you show me in a test page the effect of bdi when there is a field (e.g. address) or part of a field (e.g. content) that has some Arabic? As explained I'm not skilled with this tag. PS While SPAN cannot contain DIV, DIV can contain SPAN, so the use of DIV is always allowed; is just a matter of layout design. --Andyrom75 (talk) 07:06, 24 July 2017 (UTC)Reply

As you said, the DIV cannot be part of an inline content, so now we can no longer include a Listing within a paragraph or in the middle of a list item without breaking it. So an outer DIV cannot be always used. DIV enforces a block content model, while SPAN enforces an inline content model, so both are restricted. With MediaWiki the only existing HTML element allowed that has a mixed content model is BDI.

Note however that BDI we used inside this template, for subitems for another reason: allow also correct isolation of elements that are not necessarily in English and can include non-Latin text: place names, organizations, people names, addresses. BDI in that cases allows their "isolation" so that their direction inside will not affect the direction of text outside of them, both before or after, the whole BDI being handled itself as if it was a symbol with neutral directionality that preserves the general direction and will avoid undesired mirroring of various characters (notably punctuation).

So BDI is the most useful and universal HTML element, the most transparent, more important than DIV and SPAN, it solves many problems notably in templates where you cannot predict the contents of template parameters. And in fact it is often the only existing safe element you can use that will not break the layout when you want to add semantic tags (such as those for microformats). HTML5 has added a few other elements: they are not presentational but structural (relative to the document), but not semantic, and unfortunately there's still not semantic element, and MediaWiki rejects lot of standard HTML elements for obscure reasons (absolutely not for security reasons or compatiblity reasons with old browsers). Verdy p (talk) 07:24, 24 July 2017 (UTC)Reply

Tracked in Phabricator ^(?)
Task T171457

Verdy p, thanks for the explanation. BDI seems to be very useful. Could you show me a couple of example where its used affected the text layout in the two cases I've mentioned before? PS In the meanwhile I've opened the bug T171457. --Andyrom75 (talk) 10:09, 24 July 2017 (UTC)Reply

Hi Verdy p, it's me again. If you cannot find the examples that I've requested inside a real article, can you create some just to show how listing differently works with or without the BDI tag? It would be useful and interesting maybe also for other context. Thanks, --Andyrom75 (talk) 06:35, 25 July 2017 (UTC)Reply

Swept in from the pub

Hello,

I've noticed that adding an Arabic name to the alt-section of a listing messes up formatting. The brackets supposed around the alt-name and the phone symbol switches places. I am guessing the same problems appear with other langues that is read right-to-left. A good example can be seen at Tanta#Sleep which I recently edited. But I have noticed the same issue on many other pages. Would be great if this could be addressed. --Jonte-- (talk) 10:52, 3 July 2017 (UTC)Reply

It is browser dependent. In MS IE it is OK, in Firefox it is OK, but in Chrome there is this problem. --FredTC (talk) 13:09, 3 July 2017 (UTC)Reply

It indeed seems to be browser dependent. On my Mac the Sleep listings you mentioned look normal in Firefox, however in Safari, Opera and Dooble those listings read like this: "1 New Arafa Hotel (فندق عرفة الجديد), ☎ +20 40 3336954. (updated Jul 2017 | edit)". Those three browsers and Chrome are all based on some software component called WebKit. --ϒpsilon (talk) 13:52, 3 July 2017 (UTC)Reply

I wonder if adding <bdi>...</bdi> tags would solve this problem. User:Verdy p will know how to fix this. WhatamIdoing (talk) 17:52, 3 July 2017 (UTC)Reply

Yes, integrating the bdi tags to surround the "alt" text (shown in parentheses after name) fixes that. I could do that in the Template:Sleep, but I could not edit Template:Listing which is locked. And further tests are needed to generate the correctly ordered layout for possibly other fields.

Note that I had to include a test to see if "alt" is empty in order to not pass the bdi tags around an empty value, because Template:Listing will detect a non-empty "alt" text and will then add the parentheses adound them, producing a dummy "()" after the displayed name.

Note also that some wikivoyage pages may also use only an Arabic/Hebrew "name" and no alt: this could also break the layout.

Note finally that MediaWiki supports the "bdi" tags but still not their recursive inclusion: if the "alt" text already contains some bdi elements, surrounding the whole with "bdi" will break the Mediawiki parser: to avoid that, the alternative is to use "span" with "unicode-bidi:" styles.

The "bdi" element normally maps to an "unicode-bidi:isolate" in HTML5, but older browsers that do not understand "isolate" (and the updated Unicode standard defining isolates and the related Bidi controls) in their Bidi implementation, will need to recognize "unicode-bidi:embed" instead (which must then be specified in CSS before the "unicode-bidi:isolate" style that will override it), the same old browsers also recongnizing "bdi" in "embed" mode, but not "isolate", the difference being not visible inside the embedded/isolated element but on the text after this element which will inherit the Bidi context from the last child within the embedded element).

Verdy p (talk) 02:21, 4 July 2017 (UTC)Reply

Because Template:Listing was finally unlocked, I could integrate the "bdi" changes for other fields and restored Template:Sleep. Verdy p (talk) 02:48, 4 July 2017 (UTC)Reply

If you change

[[File:Wikidata-logo.svg|16px|class=listing-sister|link=d:{{{wikidata|}}}|{{{wikidata|}}} on Wikidata]]

to

[[File:Wikidata-logo.svg|16px|class=listing-sister|link=d:{{{wikidata|}}}|{{#invoke:Wikibase | label | {{{wikidata|}}} }} ({{{wikidata|}}}) on Wikidata]]

this would display the label of the item at Wikidata when hovering over the icon. The use would also signal Wikidata that Wikivoyage is using the item. This can avoid that it gets deleted as unused. Jura1 (talk) 11:14, 4 July 2017 (UTC)Reply

It seems to work. I wonder if the listing editor didn't work before or if this change (or another one) broke it.

@Verdy p: did it work after your change? Jura1 (talk) 18:30, 5 July 2017 (UTC)Reply

I did not change that part of the code, I just made the template work with bidirectional text. The suggestion above just adds a description, but it's fun if it also signals to Wikidata that the item is referenced by Wikivoyage (because Wikivoyage queries that item directly). Note however that this query could impact the page loading time if it's not parsed in the cache, or if the Wikivoyage's own cache for Wikibase does not have info about that item (which will most often rarely be queried, so missing in all caches each time the Wikivoyage page is parsed). I just hope that Wikidata is fast enough for Wikivoyage in the WM wiki farms: Wikidata is now very responsive and fails more rarely than Wikivoyage itself (which is still a much smaller wiki that Wikidata). Verdy p (talk) 11:11, 6 July 2017 (UTC)Reply

Apparently, the listing editor tool doesn't work anymore.

If the inclusion of the Wikidata label gets problematic, don't hesitate to remove it. Currently it only loads the label. I think the code is optimized to load this with less resources than the entire item (e.g. when statements are used). Jura1 (talk) 19:25, 6 July 2017 (UTC)Reply

That's not what I see, the editor was and is still working. Verdy p (talk) 00:35, 24 July 2017 (UTC)Reply

I think the edits you made afterwards fixed it. Please make sure to test before and after a change. It seems your edit may have broken the entire site for 57 hours. Jura1 (talk) 09:20, 24 July 2017 (UTC)Reply

Your citation is wrong, you hide your own broken edits in that period by spanning multiple edits (not just from me when I fixed yours), including this individual edit by you. There was another problem but not for 57 hours and not for the entire site, but for some unrelated feature that was not documented at all before I added myself the necessary documentation (and which had nothing to do with the Wikidata label described in this section). Verdy p (talk) 15:59, 24 July 2017 (UTC)Reply

I think you had misunderstood my question. I had asked if the editor still worked after this edit of yours. And no it didn't (no relation Wikidata, and yes, editing was broken for 57 hours). My change hadn't any impact which is probably why it's still there. Jura1 (talk) 17:18, 24 July 2017 (UTC)Reply

But is there still something that does not work? Why do you repost a new request now for something that was possibly not working but was already corrected (and documented afterwards because this was the cause of a missing feature that was really completely invisible and did not cause any kind of error)? I took the time to fix it and correctly document this invisible feature. Verdy p (talk) 07:15, 25 July 2017 (UTC)Reply

I don't understand what you mean with "repost a new request". It's you who comment in an old thread. But yes, it's still partially broken from your edits: Wikivoyage:Travellers'_pub#Embassy_and_consulate_formatting. Jura1 (talk) 11:10, 25 July 2017 (UTC)Reply

Swept in from the pub

For some reason the appearance of embassy and consulate listings seems to have changed—before, the flag and the name of the country appeared right next to each other, but now the flag appears on its own line and the name of the country and other information appear on the next line. I don't think this is a good change—it makes the listings take up extra space with no benefit that I can see. Was it caused by the recent edits to Template:Listing? —Granger (talk · contribs) 14:43, 24 July 2017 (UTC)Reply

@Verdy p: changing <span> to <div> probably broke it. Jura1 (talk) 11:07, 25 July 2017 (UTC)Reply

@Andyrom75: could you check? it seems to be this edit. Jura1 (talk) 11:36, 25 July 2017 (UTC)Reply

@Mx. Granger:, @Jura1:, thanks for alert. There are work in progress to eliminate lint errors that may cause minor glitches like in this case. I should have fixed the problem using a different tag suggested by @Verdy p:. Purge the pages if you don't see them yet correctly. --Andyrom75 (talk) 12:50, 25 July 2017 (UTC)Reply

Thank you for the fix! —Granger (talk · contribs) 13:13, 25 July 2017 (UTC)Reply

Looks fine on Ulaanbaatar#Embassies. Thx. Jura1 (talk) 14:29, 25 July 2017 (UTC)Reply

I confirm, my suggestion to change "span" NOT to "div" (like what Adyrom did) but "bdi" was the thing to do, because this is the only HTML tag MediaWiki supports that has a *mixed* content display type, not enforcing a "block" or "inline" display type, so not breaking other block containers like lists and paragraphs, but still allowing the inner content to contain block elements if needed (though the parameters of Template:T should avoid using any block element, they should all be inline and that's why the initial setting using "span" only was working in lists before it was changed by Andyrom75 to a "div" only because a few listings contain multiple lines instead of just "br" elements) but there are some listing entries that need to use multiple paragraphs for example to add further details: if these parameters contain lists or multiple paragraphs, the listing type itself will be OK, but this will still break a container list containing multiple listing occurences, if they don't properly use the appropriate number of leading ":" or "*" or ";" to not break those lists and get the expected indentations. There's possibly a way to fix that, but this would require atting the CSS attribute "display:inline-block" to the englobing "bdi" elemement which is used now, in order to preserve the margins. This would then not require counting the independation levels, and any content could be used more freely in the listing attributes, including multiple paragraphs, but I fear that MediaWik will still break by incorrectly splitting the bdi content. I know that Mediawiki is about to deprecate the old code that was infering which closing tags were "missing" and automatically generated: this old code causes now more problem than what they were initially useful for to fix bad old practices (and anyway we have now many useful templates to generate layouts in pages and preserve accessibility of pages, so that users will need much less tweaking things in CSS or tricky HTML tags, in addition Mediawiki will soon introduce stylesheets for templates or pages, that will help cleaning up the too frequent use of CSS style attributes (in pages containing tabular data, this requires using complex templates that generate even more complex HTML code with too much repeated CSS styles, cuaing giants pages that are slow to download and render, and that fail to render on many small mobile devices).

So in summary, this a good step in the right direction. Even HTML5 is now abandoning the former "inline" vs. "block" content models in favor of a more semantic content model detached from the presentation. And we should favor stylesheets to inline CSS attributes: they are more powerful and easier to tune at lower cost for every one. I hope that someday MediaWiki will add support for the missing HTML5 elements (even if it adds restrictions for security, notably in javascripts and event-handlers): it's still difficult to understand why basic HTML elements are forbidden like "colgroup", "col", "thead", "tbody's" and "tfoot" in tables and why new semantic elements are still rejected... Verdy p (talk) 16:52, 29 July 2017 (UTC)Reply

Swept in from the pub

Right now in the standard edit box there is a one-click listing maker shortcut for all existing types of listing (including the "listing" listing) except "go". Can this be changed? And I would suggest a charming little steam engine (like so) or maybe a EMU coming right at you (like so) as the symbol. Hobbitschuster (talk) 10:22, 5 October 2017 (UTC)Reply

Swept in from the pub

This template is broken somehow, given the disproportionate number of LintError pages that seem to be caused by it.

Can someone PLEASE repair it so that a vast number of LintError's can be eliminated very quickly?

The precise reasons for it's failure, have me head-scratching, and a template this important should be re-written so it can be maintained by normal users, and not a template genius. I am of the view it should be converted to Lua as soon as possible. ShakespeareFan00 (talk) 21:08, 16 December 2017 (UTC)Reply

@ShakespeareFan00: Tell me if this fixed it. —Justin (koavf)❤T☮C☺M☯ 04:53, 17 December 2017 (UTC)Reply

Well it fixed some of the problems I'd been seeing. It's not a complete answer, as I am seeing some different issues now. I noted a few other concerns on your talk page, or in edit summaries when i found temporary soloutions.ShakespeareFan00 (talk) 17:19, 17 December 2017 (UTC)Reply

E.g. London/Bloomsbury#Q2893581 seems to cause the 'edit' button to not do anything (probably because of the directions field) - I see some errors logged in the javascript console too. Is this "by design", or could it be fixed? Perhaps don't waste too much time on it yet, since it may be fixed in de:Vorlage:VCard already... Andree.sk (talk) 18:34, 4 March 2018 (UTC)Reply

The listing editor cannot work with nested templates like {{station|Tottenham Court Road|{{rint|london|central}} {{rint|london|northern}}}}. I have no idea if we ever can solve this low-priority editor problem. --RolandUnger (talk) 08:45, 8 March 2018 (UTC)Reply

Swept in from the pub

I unfortunately cannot recall who wrote the "inline=yes" parameter for listings, so I am asking here in the pub why it does not seem to work in the Erlangen article. Hobbitschuster (talk) 23:50, 11 April 2018 (UTC)Reply

(raises hand) I only added it for {{listing}}, it isn't done/forwarded from {{see}}, {{do}} etc. Since nobody protested against it (inline=yes) yet, we can probably extend the latter templates... Andree.sk (talk) 06:53, 12 April 2018 (UTC)Reply

Ah, I see. That makes sense. We should however have the debate at some point whether all those templates should be consolidated into the template listing with the type parameter. Hobbitschuster (talk) 15:42, 12 April 2018 (UTC)Reply

Such thing was already hinted/discussed above ("all Wikivoyage listing templates other than {{listing}} are going to be unsupported very soon")... I guess we could decide against, but there's no reason IMO too. Andree.sk (talk)

I have changed the protection of this template and the building blocks it uses. As it is used extensively on almost all pages it was open to abuse. Also some of the building blocks were referencing sandbox pages not published code, I have revered these edits. Would be good if someone could double check what I have done. Also do we need to re-evaluate the access level or give more people edit rights? --Traveler100 (talk) 09:06, 9 June 2018 (UTC)Reply

Swept in from the pub

After an absence of about a year, I am back—basically just visiting, but trying to upgrade information for Lake County, Oregon. In Lakeview (Oregon)#Buy, there's a listing for BLM. (The question of whether BLM should be under "Buy" is irrelevant here.) When I click the Edit link after the listing, I get an edit box for the MC Chuckwagon exhibit (under See). If I click the edit link after the Goose Lake State Recreation Area (under Camping), the same thing happens. The one common factor that I can see is that all three of these listings have a number 1 (different colors) map link. I have never been a fan of WYSIWIG editors on Wikimedia projects and would prefer just to edit the whole article in source text, but when I try that, I get into an endless loop where pushing "Publish changes" endlessly asks me for an edit summary. Somehow, my editing environment here is not what I am used to (on Wikipedia, e.g.) where there is an edit-summary box below everything, and no toolbar at the top. Any suggestions? Thanks. Peter Chastain (talk) 07:47, 4 August 2018 (UTC)Reply

This is not the common behaviour. I sometimes get the wrong listing/section either because of an edit between loading the page and hitting edit or because of the wrong type used in some section (a Do listing in See can confuse the tools). Something like the latter could explain what you see (but I get the right listing). You can also choose to edit the wikitext like on Wikipedia, and there should be no such problems (except the edit conflict one). --LPfi (talk) 09:31, 4 August 2018 (UTC)Reply

Well, yes, I can choose to edit the wikitext, and there are no problems except that I cannot save my edit. Clicking "Publish changes", I get a dialog where I am asked for an edit summary, which I supply and then attempt to save, and I get thrown right back into the dialog where it asks me for an edit summary. Of the two mechanisms that I know about, for editing Lakeview (Oregon), I have been successful with zero of them. :( Peter Chastain (talk) 06:08, 5 August 2018 (UTC)Reply

Hi, Peter Chastain, and welcome back. I think I can help you get back to the mw:2010 wikitext editor that is probably more familiar to you.

• Go to Special:Preferences#mw-prefsection-betafeatures and turn off the "new wikitext mode". (If that works, you're done; stop there.)
• If it's not turned on, then check for the "Automatically enable all new beta features" option at the top, and turn that off. (Then turn on, and turn off, the "new wikitext mode" to make sure that it noticed that should be turned off.)
• If neither of those are turned on, then go to Special:GlobalPreferences#mw-prefsection-betafeatures and repeat all of that.
• Also, please tell me, just because I'd like to know if I'm the only person getting this bug: when you hit the endless loop of it asking you for an edit summary, and then nothing happens, if you cancel out of edit summary box and check the history page in a new tab, did it actually save your changes already? WhatamIdoing (talk) 06:34, 6 August 2018 (UTC)Reply

Swept in from the pub

This sometimes happens in listings because the system automatically adds a period after the address, and if someone adds "St." at the end of the address, it automatically adds another period to get "St.." I saw this on the Waukegan article; notice this revision and this one.

Is there anything that could be done about this? Any possible solutions? It's not important, just that if anyone has input, feel free to add it. --Comment by Selfie City (talk | contributions) 17:13, 8 December 2018 (UTC)Reply

Yes. I will add it to my changed listing editor. This was already done with price. ARR8 (talk) 21:57, 8 December 2018 (UTC)Reply

Done ARR8 (talk) 02:53, 9 December 2018 (UTC)Reply

Wow, great news! Thanks! --Comment by Selfie City (talk | contributions) 05:43, 9 December 2018 (UTC)Reply

Swept in from the pub

• Edited pages with unicode characters in listings - anyone available to check further - Remaining articles are:
  • Khorramabad - 1 alt=‎‎دژ 2 شاپورخواست‎, 3 Shāpūr-Khwāst"‎
  • Latakia - 1 اللاذقية‎ 2 alt=أُوجَارِيت‎
  • Sarajevo - 1 (خانقاه‎‎, 2 (شاذروان‎‎
• Notation above is general textual area where they are located. Probable issue is the keyboard being used. -- Thanks! Matroc (talk) 10:50, 30 December 2018 (UTC)Reply

Two of these edits are by me, what is the issue? I have copied the text from English Wikipedia. Is there formatting that is needed to be done? --Jonte-- (talk) 10:48, 7 January 2019 (UTC)Reply

Those listings were identified as having a hidden unicode character in them. If all looks good then I would say nothing needs to be done. -- Matroc (talk) 20:26, 22 January 2019 (UTC)Reply

Hi all,

I've made some changes to the sandbox version of this template. Specifically, I've changed the Wikipedia field to auto-acquire from Wikidata if no link is provided and one exists. To do this, I've had to make one cosmetic change: the order of the site icons has been reversed. Additionally, I've used this opportunity to change the Wikipedia icon to one that has a background, so that it will work for readers with dark themes. The changes can be viewed at special:permanentlink/3743727 (wv:Graffiti wall).

Is anyone opposed to these changes? If not, I will make the sandbox version live. ARR8 (talk | contribs) 00:13, 15 March 2019 (UTC)Reply

There was this discussion in the past... Probably not too relevant though, if region articles use markers mostly. -- andree.sk(talk) 09:05, 15 March 2019 (UTC)Reply

Interestingly, it may have just become relevant. ARR8 (talk | contribs) 16:22, 15 March 2019 (UTC)Reply

Done ARR8 (talk | contribs) 16:13, 22 March 2019 (UTC)Reply

This edit produced the text * {{listing | type=listing. Is that the expected behavior of the listing editor? It seems weird to me, so I thought I'd call attention to it. If it is the intended behavior, it's fine by me, just seems a little odd. —Granger (talk · contribs) 14:03, 12 April 2019 (UTC)Reply

@Mx. Granger: In a way. The change to the listing editor was to spell out the type in the type field rather than using alias templates. Technically, the same applies here, as a {{listing}} with no type given is actually of |type=listing internally. So this was a kind of side effect. I could add a new check to suppress the type if it would be listing, but didn't feel it made much of a difference. I can still do so if requested. ARR8 (talk | contribs) 16:40, 14 April 2019 (UTC)Reply

No need, I have no particular feelings about this. Just wanted to bring it to someone's attention in case it was a bug. —Granger (talk · contribs) 01:01, 15 April 2019 (UTC)Reply

And thank you for doing it. Not a bug in this case, but it could have been. ARR8 (talk | contribs) 01:07, 15 April 2019 (UTC)Reply

Currently listings show email address with the word email: in front of it. Should this be changed with the Unicode U+2709 dingbat - ✉  ? I think the emails address format is known well enough and phone entries currently use a symbol. I would also like to propose the format of inline email references to be standardize in the sane format if they cannot be added to a listing. --Traveler100 (talk) 16:05, 8 May 2019 (UTC)Reply

There's also U+1F4E7 📧 to consider. -- WOSlinker (talk) 17:08, 8 May 2019 (UTC)Reply

I did think about that one but though the simple black outlined envelope was crisper and would not distract too much in the listings with a number of other icons. --Traveler100 (talk) 18:13, 8 May 2019 (UTC)Reply

I agree, the plain outline symbol will look better in running text than an emoji. However, does it really need a symbol or text at all? Email addresses are very recognizable as such without needing to be told "This next bit is the email address!!!", yes? --Bigpeteb (talk) 18:23, 8 May 2019 (UTC)Reply

Both symbols could equally be used for regular paper mail. What benefit does a symbol have over text, or just the address alone? AlasdairW (talk) 20:02, 8 May 2019 (UTC)Reply

I was thinking of just shorting the listings, actually like the idea of no text or symbol, just the address. --Traveler100 (talk) 20:56, 8 May 2019 (UTC)Reply

Would support removal. ARR8 (talk | contribs) 00:57, 9 May 2019 (UTC)Reply

Have change from word to symbol, see how that looks. --Traveler100 (talk) 05:09, 24 May 2019 (UTC)Reply

FWIW, I think the symbol looks good and makes it easier to quickly find the email adress among all the text. And it is consistent with the use of U+260E (☎) in {{Phone}} (although that one's a bit too heavy for my taste, maybe U+260F (☏) would harmonize better with the letter symbol) --El Grafo (talk) 13:56, 29 May 2019 (UTC)Reply

Toning down the phone icon is not a bad idea. --Traveler100 (talk) 19:11, 29 May 2019 (UTC)Reply

I have changed the symbol of the phone. See how people react to it. Can easily be undone if more negative reactions than positive ones.

My initial impression is that scanning a page to see what phone numbers are there is not so easy but display and reading of individual listings is better as the symbol does not shout at you. And looks better on mobile. --Traveler100 (talk) 06:58, 30 May 2019 (UTC)Reply

I personally am less keen on the outline phone symbol U+260F (☏) and prefer the original U+260E (☎) as it's clearer for me to see particularly at body text size. Inferno986return (talk) 13:20, 31 May 2019 (UTC)Reply

+1 -- andree.sk(talk) 20:27, 31 May 2019 (UTC)Reply

User:Matroc expressed a similar sentiment at Wikivoyage:Travellers' pub#icons in listings, and I think I agree. On my screen it's hard to tell what the new icon is supposed to be. The old one was clearer. —Granger (talk · contribs) 06:51, 5 June 2019 (UTC)Reply

Change of something that has been fixed for some time always get an initial negative reaction. The lighted phone icon has now been active for a week and the feedback so far has mainly been put back to the darker symbol. Any one more positive of the light version? Should we trial a little longer or set back now to the previous style? --Traveler100 (talk) 06:09, 7 June 2019 (UTC)Reply

At least on my computer, adding font-size:small (or x-small) toghether with the original symbol seems to look better - it's also the same size as email symbol then. Or there are other symbols too..:

• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, ☏ +66 2 590-4012, ✉ [email protected]
• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, ☏ +66 2 590-4012, ✉ [email protected]
• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, ☎ +66 2 590-4012, ✉ [email protected]
• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, ☎ +66 2 590-4012, ✉ [email protected]
• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, ☎ +66 2 590-4012, ✉ [email protected]
• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, ✆ +66 2 590-4012, ✉ [email protected]
• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, ✆ +66 2 590-4012, ✉ [email protected]
• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, 📞 +66 2 590-4012, ✉ [email protected]
• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, 📞 +66 2 590-4012, ✉ [email protected]
• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, 📱 +66 2 590-4012, ✉ [email protected]
• Argentina, Prommitr Villa, 20/85 Sukhumvit Soi 49/1, 📱 +66 2 590-4012, ✉ [email protected]

-- andree.sk(talk) 10:47, 7 June 2019 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Wow, the telephone receiver symbol 📞 (U+1F4DE) looks great! It's visually much simpler than an entire telephone, and I think it's immediately recognizable when it precedes a bunch of digits. Personally, I vote for using that symbol. I don't think the size needs to be adjusted; regular size will help it stand out, and it's such a simple symbol that it doesn't hurt anything that it's a bit on the large size. --Bigpeteb (talk) 17:28, 7 June 2019 (UTC)Reply

I don't agree. The largest full telephone icon is by far the clearest of them all. Ikan Kekek (talk) 18:26, 7 June 2019 (UTC)Reply

All agree on that - the question is, if it's the best in regards of overall design. Phone numbers are probably not that important (perhaps even most communication these days occurs via email/messengers) that they should break the text flow so much... ? -- andree.sk(talk) 08:51, 10 June 2019 (UTC)Reply

I prefer a more subtle symbol like ☏. I expect that I will only want to find the phone symbol when I am reading the particular listing. Unlike sights on a particular metro line, I doubt that I will be looking for the listings that have phone numbers. 20 years ago it would have been different, as I would have had to write a letter to book a hotel that the guidebook didn't give a phone number for. Have any checks been done with screen reading software to see what symbols are "read" sensibly? AlasdairW (talk) 22:16, 10 June 2019 (UTC)Reply

Swept in from the pub

Apparently, listings with multiple emails cannot be easily resolved by using parenthesis and commas. It is probably a bug. Anyone knows how to fix it? SmileKat40 (talk) 17:44, 4 May 2019 (UTC)Reply

I have just fixed it. ARR8 (talk | contribs) 17:48, 4 May 2019 (UTC)Reply

If anyone is interested in the edits: these and this. ARR8 (talk | contribs) 17:58, 4 May 2019 (UTC)Reply

How common is it anymore for businesses to use email to communicate with their customers? Aren't most non-phone inquiries handled through social media nowadays? Is it time to deprecate the email parameter as we did some time ago with fax? -- AndreCarrotflower (talk) 18:06, 4 May 2019 (UTC)Reply

Oh, that reminds me, I need to e-mail a company about the package that just arrived. So, no, I think that e-mail's still a valid channel for most purposes. WhatamIdoing (talk) 23:28, 4 May 2019 (UTC)Reply

A valid channel for most purposes relevant to travellers, though? We don't have listings for package delivery businesses on Wikivoyage. Is anybody really out there e-mailing a restaurant to set up dinner reservations, e-mailing a concert venue to see if they host all-ages shows, e-mailing a store to verify opening hours? No. They either call, check their website, or reach out on social media. -- AndreCarrotflower (talk) 02:20, 5 May 2019 (UTC)Reply

I would say that if we have an establishment's website, there is no need to include an email address. Readers will go to the website first for additional info before emailing. Ground Zero (talk) 02:28, 5 May 2019 (UTC)Reply

I find emailing hotels, particularly in other countries, a good method to change bookings or arrange transport to/from. Dates and times in another language often a point of misunderstanding on the phone. Embassies also have different emails for different tasks. --Traveler100 (talk) 05:19, 5 May 2019 (UTC)Reply

I think email is useful—maybe not for the majority of travelers, but for a variety of not-that-uncommon situations. Some travelers have no local phone or don't speak the local language well enough for a phone call. The destination country may use different social media sites than the home country (how many Americans have a VK or WeChat account? Or even WhatsApp?). The business may have no social media presence or may not monitor their social media messages. The destination country's social media site of choice may be blocked by the home country's government. And so on.

Even if we link to the website, email is still worth including. Some websites are difficult to use, load slowly on slow connections, or are blocked in other countries (that last one is a more common situation than you might expect—sometimes they're blocked by the reader's country's government, other times by the website itself based on the reader's IP address. I've encountered this problem both in Uruguay and in China). Also, if the email address is at a different domain than the website, it may still be usable even if the website becomes a dead link. —Granger (talk · contribs) 06:39, 5 May 2019 (UTC)Reply

Should the Category:Listing with multiple email addresses tracking be removed now? -- WOSlinker (talk) 14:11, 5 May 2019 (UTC)Reply

Not quite yet. Many multiple-email sets are not formatted correctly. This is a useful tracking category for finding and fixing those. It could be removed if/when something similar to Category:Listing with phone format issue is created for emails. ARR8 (talk | contribs) 16:51, 5 May 2019 (UTC)Reply

ARR8, I've added some basic checking and created Category:Listing with email format issue. -- WOSlinker (talk) 21:32, 5 May 2019 (UTC)Reply

@WOSlinker: Great! And I see you've also added support for other delimiters. Once the checking is expanded a bit, we could deprecate Module:EmailTracking. ARR8 (talk | contribs) 23:58, 5 May 2019 (UTC)Reply

I think e-mail is a reasonable approach when you're making plans well in advance. For dinner tonight, I wouldn't want to risk it. For "Dear conference hotel concierge, can you suggest..." or "Hello, little bed and breakfast, do you have a room on...", it's great. WhatamIdoing (talk) 20:47, 5 May 2019 (UTC)Reply

Swept in from the pub

Liverpool - Where in the listings IS the stripped tag the LintErrors report generating?

I've gone over the actual usages in the first of the listings to detect the problem and cannot find an error in the inputs to the template. Thus it must be the template itself generating the problem.

Can someone take a sledgehammer to the listings templates and remove the tag that shouldn't be there forthwith? ShakespeareFan00 (talk) 21:35, 22 May 2019 (UTC)Reply

How can you see the exact error message given for a specific page? Not really keen on clicking though all the pages in the full list. --Traveler100 (talk) 05:25, 23 May 2019 (UTC)Reply

https://en.wikivoyage.org/w/index.php?title=Liverpool&action=edit&lintid=687546 will link to the portion of the page where Linter found the concern. The error message is not given in any more detail than that in the Special:LintErrors reporting. In the Liverpool instance the problem seems to be with a spurious span being generated inside the {{Listing}} template. ShakespeareFan00 (talk) 08:42, 23 May 2019 (UTC)Reply

User:SSastry (WMF): Would you please take a look at this, if you have a few minutes? I think that ShakespeareFan00's probably right about the problem being in the template rather than directly in the article. The "Liverpool" examples are on the last page of Special:LintErrors. There are approximately the same number of errors as |alt= fields on the page, so maybe that's the first thing to consider. WhatamIdoing (talk) 16:13, 23 May 2019 (UTC)Reply

Fixing this will solve over 22,000 LintErrors given that Listing is a key template on Wikivoyage.ShakespeareFan00 (talk) 19:14, 23 May 2019 (UTC)Reply

I think the problem has been solved. Pages have updated but not sure when the Special page listing errors is updated. --Traveler100 (talk) 05:13, 24 May 2019 (UTC)Reply

Swept in from the pub

{{Listing}} is designed to show wikipedia icon/link (if existing) when wikidata field is filled, but I've noticed a weird behavior on Legazpi: listing #1 (by plane) works corretly, but listing #3 (by train), don't. Any idea on why it happens and how it can be fixed? --Andyrom75 (talk) 09:39, 7 April 2020 (UTC)Reply

I’m not sure what caused the issue, but I’ve added the “Wikipedia” parameter that links to the desired article. Let me know if I’ve made a mistake. --Comment by Selfie City (talk | contributions) 10:39, 7 April 2020 (UTC)Reply

There is an ongoing problem, see phabricator. I don't understand exactly what is going on, but it seems some table (cache?) was lost causing all kinds of weirdness. --LPfi (talk) 10:53, 7 April 2020 (UTC)Reply

Well, that’s unfortunate, but at least there is a workaround. --Comment by Selfie City (talk | contributions) 13:45, 7 April 2020 (UTC)Reply

LPfi, I'm not skilled enough to understand if this is the problem, but since they are working on it, it should be closed soon and we can check again later.

SelfieCity, technically it's not a mistake what you have done, but I would revert your change in order to check immediately if the issue will persist when the ticket will be closed on phabricator. If persist we have to focus on how to solve the problem. --Andyrom75 (talk) 14:30, 7 April 2020 (UTC)Reply

Okay, I understand. --Comment by Selfie City (talk | contributions) 16:51, 7 April 2020 (UTC)Reply

Although that bug is still open, the issue has disappeared. Luckly it was just temporary bug. --Andyrom75 (talk) 16:53, 8 April 2020 (UTC)Reply

Yes. They seem to be handling the aftermath on the servers, and there may still be issues left in some caches. --LPfi (talk) 17:15, 8 April 2020 (UTC)Reply

Prices have stopped displaying on Go listings. For examples, please see Caldas da Rainha#TOMA and Yonkers#Get_around. For dummy examples, see difference in output of Go vs. See at User:Nricardo/Sandbox2 --Nricardo (talk) 10:19, 28 November 2020 (UTC)Reply

I've found a workaround, but it would be good to fix this. —Granger (talk · contribs) 10:57, 28 November 2020 (UTC)Reply

Thank you! Yes, a fix is preferable, as using the listing editor now produces {{go}} rather than {{listing | type=go}} and editing existing listings with the listing editor converts the 2nd format to the 1st. Just earlier today, I had searched-and-replaced on Caldas da Rainha to what looked like the new "standard" (before noticing the issue). --Nricardo (talk) 11:14, 28 November 2020 (UTC)Reply

User:Andyrom75 might be able to help. —Granger (talk · contribs) 16:02, 28 November 2020 (UTC)Reply

Granger, thanks for pinging.

Nricardo, I've just fixed the Go template that was created in a wrong way (or in any case differently from the others). --Andyrom75 (talk) 18:30, 28 November 2020 (UTC)Reply

Much thanks, Andyrom75! --Nricardo (talk) 20:52, 28 November 2020 (UTC)Reply

Is there a way to not display an image in a listing that has an associated Wikidata item?

Here is a use case: suppose I add a listing for a chain restaurant in San Francisco. However, the image used on the Wikidata item is of the company's headquarters in Seattle, and there are no other images on file. In this case, it might be better to not show the image at all so as to avoid confusing readers. How do I go about doing this? --Ixfd64 (talk) 18:36, 11 April 2021 (UTC)Reply

In a case like this, I think that you shouldn't link to the Wikidata item. I don't think that our policy on Wikipedia links encourages links for chains, and the lat/long would also be wrong for the chain. It is a different matter if the chain restaurant is in a historic building which has its own Wikidata item. AlasdairW (talk) 22:08, 11 April 2021 (UTC)Reply

Thanks for the response. I think simply not linking to Wikidata is a good solution. --Ixfd64 (talk) 22:37, 11 April 2021 (UTC)Reply

Hi everyone, any reason why "fuel" has to come under "other". Nearly every town has a servo (fuel/gas station) and I think these should stand out. What do you think?

SHB2000 (talk) 22:23, 11 April 2021 (UTC)Reply

Yes, in one-horse (one-car?) towns with one gas station, list it, but we wouldn't want listings of them in big cities where there are dozens or more. Ikan Kekek (talk) 22:27, 11 April 2021 (UTC)Reply

Except in remote places, they aren't hard to find, are they? In remote places like Quebec Route 389 or the Dempster Highway, planning for a fuel stop can be a matter of life and death. Elsewhere, they are usually easy to find at the side of a road. Ground Zero (talk) 22:30, 11 April 2021 (UTC)Reply

Not in Australia, fuel can sometimes mean, driving 40 mins-3 hours away as most towns don't have fuel (especially in the New England (New South Wales) Region). I've also found it fairly difficult to find fuel in Arizona but not as hard as it is here. SHB2000 (talk) 22:34, 11 April 2021 (UTC)Reply

@Ground Zero: - definitely on the James Dalton Highway as well. SHB2000 (talk) 23:21, 11 April 2021 (UTC)Reply

Can we mention that "type" can also do colours e.g. like this? 001 .  After some quick tests, it seems like you can use the names of any HTML colour. 82.3.185.12 15:21, 24 April 2021 (UTC)Reply

You have to be very careful: The color maroon is used for the type vicinity. That's why you cannot distinguish between them, and they have sometimes the same numbers: maroon #2: 112 .  vicinity #1: 331 .  --RolandUnger (talk) 06:18, 25 April 2021 (UTC)Reply

@RolandUnger: However you can type the name of any HTML colour e.g. 221 .  82.3.185.12 09:37, 25 April 2021 (UTC)Reply

@82.3.185.12: The main reason why you cannot use additional colors (better to say: types) except those of Module:TypeToColor is that they are not accepted by the {{Mapframe}} template as you can see from the map beside. It was not intended to use other types but it is difficult with template parser functions to make a complete parameter check. And if you look at the marker: it is not shown in aliceblue but grey, the fallback color (#C0C0C0). --RolandUnger (talk) 04:32, 26 April 2021 (UTC)Reply

By the way, you cannot only type any color but any other word link nonsense, too: 221 .  --RolandUnger (talk) 04:35, 26 April 2021 (UTC)Reply

@RolandUnger: Although aliceblue works like this 001 .  82.3.185.12 15:19, 4 May 2021 (UTC)Reply

Oh, never mind. 001 .  produces green, in the listing template the word "learn" is not recognised. 82.3.185.12 15:22, 4 May 2021 (UTC)Reply

@82.3.185.12: I think you are not familiar with the templates: Your aliceblue is not aliceblue but gray which is the fallback color/type. {{learn}} is not a color but a redirect to {{listing}} which is associated with forestgreen by default. It means that it is impossible to change colors. --RolandUnger (talk) 04:40, 5 May 2021 (UTC)Reply

The listing template (and in general templates) is not intended to be used for "random stuff". IMO the main point of templates is to separate form and content. If you start assigning colors of your liking to random listings, it's going to be a mess because even the bordering regions may have different meaning for the ones you picked. God forbid WV decides to change color scheme (see {{StdColor}}, or use dark mode - and suddenly your colors will be all over place. So in short - unless you really really really need to, just don't change visual style locally in a page. If you think you have a good point/use case, start general discussion about adding new listing types... My 5c. -- andree.sk(talk) 18:53, 4 May 2021 (UTC)Reply

Andree.sk is true. Readers are confused with random colors. The colors defined are used in the same manner in all Wikivoyages. Changing colors should be discussed by all international communities. --RolandUnger (talk) 04:40, 5 May 2021 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Here is a list of things you can put in the 'type' field (taken from Module:TypeToColor):

• around = '800080',
• buy = '008080',
• city = '0000FF',
• do = '808080',
• drink = '000000',
• eat = 'D2691E',
• go = 'A52A2A',
• launchsite = 'FF8C00',
• listing = '228B22',
• other = '228B22',
• see = '4682B4',
• sleep = '000080',
• vicinity = '800000',
• view = '4169E1',
• black = '000000',
• blue = '0000FF',
• brown = 'A52A2A',
• chocolate = 'D2691E',
• forestgreen = '228B22',
• gold = 'FFD700',
• gray = '808080',
• grey = '808080',
• lime = 'BFFF00',
• magenta = 'FF00FF',
• maroon = '800000',
• mediumaquamarine = '66CDAA',
• navy = '000080',
• orange = 'FFA500',
• plum = 'DDA0DD',
• purple = '800080',
• red = 'FF0000',
• royalblue = '4169E1',
• silver = 'C0C0C0',
• steelblue = '4682B4',
• teal = '008080', 82.3.185.12 15:46, 11 May 2021 (UTC)Reply

Swept in from the pub

I was wondering if we should include Facebook and Insta icons right next to listings which would link to the location's facebook or insta page, very similar to the Wikidata and Wikipedia variable on {{listing}} and its subtemplates. As some travellers purely go based on fb and insta pages, making it:

1. Easier for the traveller
2. Useful
3. Someone who just wants to know about the business or the people who look at Facebook pages will find how the place is. This would be especially useful for eat, drink and sleep but is also handy for certain see like a museum and do like kayaking as an example.

From what I know, society has sort of been changing that now more and more people tend to see FB and Insta pages, and I've noticed that newer places (especially restaurants) often don't have websites, and just use social media. 5 years ago, this wasn't exactly the case.

(And I think File:Instagram_logo_2016.svg and File:Facebook icon 2013.svg are pretty good logos and wouldn't look quite odd. )

What do you all think?

--SHB2000 (talk | contribs | en.wikipedia) 10:11, 2 July 2021 (UTC)Reply

The url of a listing can be their social media account if they don't have a website. Usually Facebook but could be Instagram or Twitter too. If a restaurant e.g. has both its own website and Facebook page, I don't see why we need to include both. The main website would have more information in nearly all cases. If the main website is not as well updated as the Facebook, then Facebook page can replace it in the url. On the other hand, having a share button to various social media sites at the bottom of the page would in my opinion be useful. It will increase the outreach of Wikivoyage content to the wider community. Gizza ^(roam) 11:30, 2 July 2021 (UTC)Reply

I would support a template parameter linking to Facebook or Instagram when a website does not exist. The trend has already begun to emerge in business listings where no URL exists, and this would legitimize it. --Comment by Selfie City (talk | contributions) 11:44, 2 July 2021 (UTC)Reply

Like DaGizza says, a social media link can be used as URL. But I think the trend not to register a domain and use a page on social media instead is quite old, and there is a counter-trend, where more and more people feel uncomfortable interacting with Facebook & al, and to help those people, and not to support the former trend, I hope we can continue to prefer the proper websites unless they are abandoned. The social media pages often have more updates, because of the logic on such sites, but often basic information is still available at the own domain, and there should be links there to the social media pages for those wanting to read the latest greetings. –LPfi (talk) 14:25, 2 July 2021 (UTC)Reply

I support the status quo in listings, which allows Facebook listings and such for entities without their own superior websites, but I don't think we should go further and do something that has the effect of actively promoting social media businesses that have had extremely harmful effects on the human race. Ikan Kekek (talk) 15:45, 2 July 2021 (UTC)Reply

I agree that one URL per listing is generally enough and we don't need social media icons in addition. —Granger (talk · contribs) 16:46, 2 July 2021 (UTC)Reply

About @DaGizza's idea to have a share button to various social media sites at the bottom of the page: This is do-able, but there's a particular way that it's supposed to be set up. If you use the fancy scripts that the companies recommend, then they can use that code to track readers. Instead, you want to set it up so that it's a "regular" link (i.e., not Javascript). If it's set up right, it minimizes privacy problems. WhatamIdoing (talk) 02:19, 3 July 2021 (UTC)Reply

The icon in itself is an advertisements for those sites, and readers cannot know that we haven't used their javascript. Some do trust us and some know how to check, but I don't like joining their ecosystem by using share links, and I think those put off by our using the icons might very well outweigh the visibility the links might get us on social media. –LPfi (talk) 07:10, 3 July 2021 (UTC)Reply

I doubt that it would make that much difference. 80% of US adults have a Facebook account. 70% of US teens use Instagram. I don't do social media myself, but I don't think that we should make a decision based on the tiny percentage of us that care. People who actually care are going to be blocking those sites anyway (as I do). WhatamIdoing (talk) 17:28, 3 July 2021 (UTC)Reply

I do not support adding icons or creating separate fields for social media. I myself resort to putting the a Facebook page in a listing's Website field only when I don't find a valid non-FB site for the business. Nelson Ricardo (talk) 20:33, 3 July 2021 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Those exist at de-wv. If they are wanted here, we should contact de-wv for advice on how to do it. Hobbitschuster (talk) 20:35, 3 July 2021 (UTC)Reply

I strongly oppose adding the icons. I am here because I am part of the free content movement, trying to fight the lock-in by commercial oligopolies. Adding free advertisements of Facebook would be destroying one of the few havens where I don't have to put up my own defences, making it even more difficult to argue against Facebook linking on sites that don't have the strong support we have by being part of the WMF family. –LPfi (talk) 13:15, 9 July 2021 (UTC)Reply

Swept in from the pub

Hi, everyone. Constantly, when I try to save a new item, the following information appears: "Error: An unknown error has been encountered while attempting to save the listing, please try again: invalidsection". Does anyone know the possible source of this error? Sanjorgepinho (talk) 19:37, 10 July 2021 (UTC)Reply

Can you describe an example of what you are doing and in which article more specifically? I assume you're not adding or deleting any fields from any listing templates or trying to create new listing templates that don't exist? What browser are you using? I may not be able to help you (and probably won't be able to), but someone might if you're very specific. Ikan Kekek (talk) 20:12, 10 July 2021 (UTC)Reply

@Ikan Kekek: For example in Palmela, in the "See" section, when adding an item in [add listing], trying to save it gave that message. The browsers that gave errors were Google Chrome, Version 91.0.4472.124 (Official build) (64-bit), Firefox Browser 89.0.2 (64-bit), Microsoft Edge Version 91.0.864.64 (Official build) (64-bit) and Internet Explorer version 21H1 (OS build 19043.1081). The solution he had in these cases was to edit by source code and so he already accepted the editing. However, after an hour, I tried writing again by the traditional method [add listing] and it went back to letting me record. This is not the first time this has happened. Sanjorgepinho (talk) 23:18, 10 July 2021 (UTC)Reply

I'll try adding a dummy listing and see whether it works. Ikan Kekek (talk) 23:35, 10 July 2021 (UTC)Reply

I wasn't able to duplicate the problem in Firefox 89.0.2 in a Windows 8.1 environment. I'm wondering if there was any maintenance being done to the site earlier. Could you try again and see if you get the error again? I'm wondering if it's possible you were somehow tripping an abuse filter by mistake, but I don't think you'd get "invalidsection" as the error message. I don't recognize that error message in the first place or have any idea what would cause it. Ikan Kekek (talk) 23:41, 10 July 2021 (UTC)Reply

Now everything is working fine. When this error comes back, I'll let you know. Thanks. Sanjorgepinho (talk) 23:46, 10 July 2021 (UTC)Reply

Definitely do that, but hopefully, the problem won't recur. Ikan Kekek (talk) 23:56, 10 July 2021 (UTC)Reply

I’ve often had these sorts of issues lately, most often when trying to load recent changes, but also when trying to save edits (about 30-50% of the time, it feels). If I’ve clicked (or pressed) the “publish” button and nothing happens after a few seconds, I reload and find the edit has indeed been saved. However, every so often it doesn’t save, particularly when trying to leave a comment, which is frustrating and requires rewriting it. But I’m not sure if you’re experiencing a related problem or something completely different. (I just added this comment to my clipboard so nothing happens.) --Comment by Selfie City (talk | contributions) 00:35, 11 July 2021 (UTC)Reply

This also happens to me. There's another weird thing that happens to me a lot. When I edit an item, for example from the "Eat" section, I get another item from another section, for example from the "See" section. Sanjorgepinho (talk) 15:49, 11 July 2021 (UTC)Reply

When the text column is narrow, e.g. because of a {{mapframe}} or large image and relatively narrow browser window, the listings do not behave optimally. For me, the first see listing in Varkaus was split with just one word per line until "Mechanical" which did not fit, so the rest of the listing was below the image. I tried to fix it with {{nowrap}}, but now the marker number is on a line of its own and the rest below the image.

Would it be sensible to have all of the marker template inside a nowrap, perhaps preceded by a zero-width no breaking space? That would mean the name wouldn't be word wrapped, but names so long that they need a split are probably uncommon. Perhaps a wrap=yes could be used for those cases. Would it be better to force a general minimum width of the column with CSS?

–LPfi (talk) 15:33, 12 November 2021 (UTC)Reply

Swept in from the pub

Is it a known issue that when you sync coordinates or other data from the Wikivoyage editor for templates that corresponding statements are 1. being removed when they should be deprecated 2. not creating a new statement in Wikidata where an existing statement value should not be changed due to the reference being different. For instance a Wikidata Q may have geocoordinates that are off of the building which Wikivoyage may have more accurate coordinates. The wikidata statement has a reference sourced from GNIS or other database. Syncing Wikivoyage to Wikidata replaces the coors for the GNIS or other database, but leaves the database as the source and does not indicate Wikivoyage was the source of the new coords thus incorrectly leaving a conflated statement in Wikidata that cannot be traced to Wikivoyage and and incorrect statement that the database provided a value which may be inconsistent with the database's stored value. Wolfgang8741 (talk) 14:52, 30 March 2022 (UTC)Reply

Example data sync issue of the coord from Wikivoyage to Wikidata resulting in overwriting the value, but not changing the reference for the value with corresponding edit. Wolfgang8741 (talk) 16:19, 30 March 2022 (UTC)Reply

If so, this is very problematic. We can be pragmatic, but when people on Wikipedias check statements on Wikidata, they should not differ from what is said in the cited source. The simplest solution is to never sync to Wikidata when there already is a non-deprecated value with a reference. To be able to sync even then, we'd need to provide a reason for deprecating the existing value or a modifier saying how our value is different from it. I assume it is very difficult to implement sensibly in the general case and probably not worth the trouble.

It would be nice to be able to deprecate or remove the former coordinates when they are erroneous, or add our owns (with a modifier) but perhaps it is better to just fail and provide a link: "Wikidata coordinates have a reference. Go to Wikidata for checking and correcting as appropriate (instructions)". The instructions would explain the difference between Wikidata and Wikivoyage coordinates, things to check before changing, and common modifiers and reasons for deprecating.

–LPfi (talk) 07:09, 31 March 2022 (UTC)Reply

The never syncing to Wikidata for non-deprecated values should only be a stop gap measure and ideally the Listing editor could be corrected to include the proper logic to handle existing statements. There are many coordinates on Wikivoyage which are more precise to the location of the object than those from the database. I am bringing this to the community's attention so corrective action can be taken to mitigate further damage and remediate the changes that have overwritten Wikidata values with references. I only recently found the tool's name after posting the initial inquiry above. Relying on people reading instructions would help, but not prevent the root of the issue which is the tool lacks necessary checks to prevent introducing issues on a large scale (and should be fool proof once fixed).

1. Get a fix to stop any further perpetuation this issue by the Wikivoyage:Listing editor as soon as possible.

2. Start to identify what sync actions have affected Wikidata coordinates.

3. Revert wikidata edits for coordinates synced from Wikivoyage to the original referenced values. A challenge to this is the lack of a "tool tag" on edits to Wikidata to identify changes made by the Listing Editor's sync action or a consistent change comments that would identify the listing editor as being the source. One or both of these approaches should be added to the Listing Editor when syncing to help with identifying edits by this tool.

I would lean to adding a new statement with Wikivoyage value and reference and deprecating the existing statement and offer in the listing editor confirmation box a set of reasons from typical reasons for depreciation. This would allow others relying on Wikidata to detect and make a decision on how to handle the value change. Wolfgang8741 (talk) 13:30, 31 March 2022 (UTC)Reply

I mostly agree with these points. However, making the tool handle deprecating or replacing values on Wikidata properly is difficult.

1. We want inexperienced editors to easily use the tool. Thus we cannot require reading instructions (unless we offer different features to different groups).
2. Wikidata uses properties differently from e.g. Wikipedias. If we overwrite coordinates for the source and mouth of a river with a point where you conveniently can get down to it, people at Wikipedias will be furious. Changing midpoint to entry point is not hat bad, but still contentious.
3. Replacing a value with reference with one without reference is a degradation. Wikipedia in Swedish generally does not show such values in infoboxes.
4. I considered suggesting a list of reasons for deprecating, containing at least "erroneous". The problem is that the user interface isn't well versed for seeing whether the coordinates (or any other properties) really are wrong. If the coordinates are for the office, not for a park itself, how can the tool show that they make sense after all? It does not show the extent of the listed object, nor does it show enough of other context. I ended up thinking that to judge the case properly, you have to check the item proper at Wikidata. Thus we should provide that link, and a link to instructions, including common reasons to deprecate etc.

A separate property for Wikivoyage coordinates would solve the conflict. We wouldn't need a reference and wouldn't get into conflict with the Wikipedias or other third parties.

–LPfi (talk) 15:45, 31 March 2022 (UTC)Reply

Lets focus on preventing continued data corruption and remediate what has been done then look to a solution to how to fix the Listing editor.

I don't recommend going the new property route as it doesn't solve the root of the issue and I doubt a WikiVoyage specific coord property would be accepted since the issue can be solved with a precise and formatted statement in the existing coordinate property. Either with a new property or existing property the coordinates from Wikivoyage would still require a reference else the Wikivoyage value should not be transferred to Wikidata as a statement is unreliable without a source.

The Listing editor would be better off to make sure the statement is correctly added without overwriting existing data if the values do not match and reference Wikivoyage while marking the Wikivoyage as preferred rank with the qualifier as more precise and not touch existing statements or at most mark a preferred statement as normal if not deprecated. An additional qualifier might be warranted if a specific part of a location should be the coordinate value rather than center of a building as is handled for the dual coordinates of head and mouth, main entrance to a building, etc. The editor would need to load all normal and preferred coordinates and qualifiers associated to make an informed decision to sync to Wikidata or not. Wolfgang8741 (talk) 20:13, 31 March 2022 (UTC)Reply

Sorry if I missed some of your points in my previous response, but I agree with much of what you are saying. I'm not suggesting to implement a good UI and set of controls for a corrected function would be easy. I've been studying issues in design as part of my degrees for some time now. Can we agree to pin the "fix" discussion and focus on preventing further corruption and identifying the scope of the issue? Wolfgang8741 (talk) 20:27, 31 March 2022 (UTC)Reply

I agree. I assume adding an edit summary to the Wikidata edits would be an easy first fix, allowing us to later fix any breakage we cause. The next step, I think, is to fail if a Wikidata item with reference would be overwritten; a crude version first, special cases can be added later. Then a discussion on what cases we should allow and what to do about them. –LPfi (talk) 16:06, 1 April 2022 (UTC)Reply

Looking at the Wikivoyage edit you linked above, it seems we do have edit summaries our side: "→‎Connect: Updated listing for Troy-Miami County Public Library - link to wikidata and sync". We could check for all edits on Wikidata with matching user and timestamp. But first the two first steps. –LPfi (talk) 16:11, 1 April 2022 (UTC)Reply

Yes, failing if a reference exists will stop further corruption and effective first step. Do you know how to do this? If not, who and how do we get that implemented? The identification and cleanup is going to be more complicated and probably needs coding to go over Wikidata and Wikivoyage histories.

The "link to wikidata and sync" is what I write on Wikivoyage, it is not generated by the tool and the problem is looking at the change comment on Wikidata which only includes "Set a claim value: coordinate location (P625): 40°2'30"N, 84°12'26"W" and looks like a manual edit without a comment. I write these comments to help track when I'm syncing, any other user sync action isn't noted and is hidden.

Tracking down all possible errors for as long as this issue has existed in the Listing editor will require a systematic programmatic approach as there is a significant burden to correlate edits that may be syncing. We have to look at which WikiVoyage listings currently have or previously had coordinates on all pages. Look at the corresponding Wikidata item linked or ever linked since the bug began and check all Wikidata items that had a coordinate value with reference since the bug originated. If a change ever occurred to the coordinate on Wikidata when a reference was present a comparison would be needed to any coordinate combination for the listing item(s) that are associated if that value ever matched Wikivoyage at the same time. This would give an probable source that we could have humans review or just revert to the value of the reference Wolfgang8741 (talk) 01:39, 2 April 2022 (UTC)Reply

OK. The edit summary looked like it could have been from the script. I think it does create edit summaries if you don't provide any, which would be the case for most edits by non-regulars. The page to edit is probably MediaWiki:Gadget-ListingEditor.js and the most recent editor is Andyrom75, who might be able to tweak it as needed. I haven't coded javascript or anything for the Wikidata API myself. I will take a look for possible obvious tweaks, but I'm afraid there needs to be non-trivial functionality added. –LPfi (talk) 14:31, 2 April 2022 (UTC)Reply

Wikidata usually supports multiple values, so instead of failing to sync, it might be possible to keep the old (ref'd) data value and add a second (unref'd, from Wikivoyage) value. RolandUnger and Ryan know the code and might be able to help when they're around. Alternatively, there are tech-savvy folks at WMDE and Wikidata who might be willing to help us out. WhatamIdoing (talk) 16:30, 2 April 2022 (UTC)Reply

Multiple values are possible, but they should not have the same rank, unless there are qualifiers making them distinct. The added value should have a suitable qualifier for it to be chosen for Wikivoyage use, and there probably isn't any that fits. Otherwise there are two conflicting values, being randomly chosen for Wikivoyage and Wikipedias (except those that check references etc. like sv-wp does). I don't think fixing this properly is much more difficult than fixing it as a hack that causes problems. Overwriting values without reference is no big deal, they shouldn't be there in the first place, but if there is a properly sourced one already, we should have a rationale for adding ours at the same (non-deprecated) rank. That can be done with a qualifier, if we find suitable ones to choose from, in cases where the former value doesn't have it. In most cases it must be done manually, after having studied the item. –LPfi (talk) 18:58, 2 April 2022 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I am wondering that this issue is discussed only now. And I know that I will draw ire presenting my proposal: You should remove the sync tool. This quick-and-dirty tool is useless. On the one hand, it is not necessary to make a sync into the wiki: this can be done by the listing script itself (or the author can overwrite it). And the sync into Wikidata causes many difficulties which cannot be solved easily by a/the current script. In most cases the tool cannot make a well-founded decision. That's why such a tool was not implemented at the German Wikivoyage (by the way, German Wikivoyage analyses about 50 Wikidata properties, not only five)! I am sure that there will be no programmer doing this job, at least neither Ryan nor me. Doing that takes a lot of time which should be spent for more important tasks.

Of course you can add a second value to a property in Wikidata but this is senseless because nobody will use it. Why sync? We will upset the people of the Wikidata community who has to clean up the entries. Of cause we need a better in-wiki integration of Wikidata but this should be done by Wikidata programmers. And by the way, maybe a lot of inexperienced authors will not understand why to sync.

Maybe you should think about the future of the listing template, too. In the current state it is really outdated going back to Wikitravel times or prehistoric digital age without Instagram and booking.com. There are so many data stored at Wikidata -- but they aren't used in English Wikivoyage. --RolandUnger (talk) 06:51, 3 April 2022 (UTC)Reply

• Secondary values, if I am not mistaken from assisting on a cyclone template years ago (Wikipedia); these are used in tracking cyclones, hurricanes positions over a period of time already... Not sure if same property -- Matroc (talk) 03:41, 5 April 2022 (UTC)Reply
  • I suppose those coordinates have a date qualifier. The same would apply to a business that has moved, and it should be easy to use only values valid for the current date. Without qualifiers, there should be only one value at the highest rank; for duplicates there is no way for the listing to know which one is relevant to Wikivoyage. –LPfi (talk) 07:48, 8 April 2022 (UTC)Reply

On syncing in general: I think it makes sense for an editor to check values fetched from Wikidata, so a manual sync to Wikivoyage makes sense. The other way around, perhaps naïvely, I don't see why syncing is a bad thing – in cases where the values are lacking at Wikidata, given that the Wikidata item is the right one in the first place. If we add a reference to the article on Wikivoyage, any Wikidata editor or third party (such as Wikipedia editors) can judge whether it is trustworthy enough for their purposes. –LPfi (talk) 07:59, 8 April 2022 (UTC)Reply

Given that I personally only update the wikidata coords if it's really broken, would it make sense to always store reference:WV to the updated data? WD editors can always revert it, if it turns out to be incorrect for some reason. -- andree 08:21, 10 April 2022 (UTC)Reply

It would be a great improvement. The question is what property to use for that reference. A reference to the edited page, preferable with a permanent link, would make that even better.

The issue on how to treat a previous value remains. If it is kept, then we have duplicate values. If it is replaced by the listing editor, the question is how to make sure the editing user has made sure the previous values really were erroneous (and they should properly be deprecated with that very reason, if they have a reference or source).

–LPfi (talk) 08:55, 11 April 2022 (UTC)Reply

When linking a listing from the name parameter, the space between the marker and the name disappears. This is hardly intended, but I cannot find the code that causes this. A workaround is to write name=[[City#Listing| Venue]], with the space in the link text. The space should of course be added automatically regardless of links in the parameter. –LPfi (talk) 08:11, 12 January 2023 (UTC)Reply

Swept in from the pub

Anyone else getting the same view? Both are screenshots of Fox Glacier, for reference. --SHB2000 (talk | contribs | meta) 07:45, 18 April 2023 (UTC)Reply

Yes, I see the same. On Fox Glacier, and also most/every page on my watchlist (e.g. Toronto/Harbourfront) Gregsmi11 (talk) 08:04, 18 April 2023 (UTC)Reply

It looks really bad for the Clemson SC page. Lazarus1255 (talk) 08:08, 18 April 2023 (UTC)Reply

What's strange is everything was fine just a few minutes ago on Normandy, which I was using as a reference in making a static map, but every other page was acting up. SHB2000 (talk | contribs | meta) 08:17, 18 April 2023 (UTC)Reply

And just as I hit the reply button, everything seems to be fine again. SHB2000 (talk | contribs | meta) 08:18, 18 April 2023 (UTC)Reply

@SHB2000 Same thing happened in Jakarta/Central, or is it just me? Veracious (talk) 03:18, 19 April 2023 (UTC)Reply

@Veracious: this issue seems to have happened sitewide, so it's not just you. SHB2000 (talk | contribs | meta) 03:28, 19 April 2023 (UTC)Reply

The |wikidata= parameter is preferred over the |wikipedia= parameter for editors, but for readers, I think they'll be a lot more interested in the Wikipedia article. I'd suggest having the icon for the Wikipedia article display before (or even instead of) the Wikidata icon. Sdkb (talk) 15:02, 26 October 2023 (UTC)Reply

Courtesy pinging @LPfi as I see you're active above and you have the permissions to change this. Sdkb (talk) 15:03, 26 October 2023 (UTC)Reply

I don't think the order matters; I assume people will recognise the Wikipedia "W". While I probably am authorised to change the order, the code of the templates and the module is complicated, I have no wish to interfere with it. –LPfi (talk) 15:49, 26 October 2023 (UTC)Reply

On hiding the Wikimedia link: we don't know who is a "reader". E.g. Wikidata folks may very well visit without logging in. –LPfi (talk) 15:52, 26 October 2023 (UTC)Reply