Wikivoyage talk:Listings/Archive 2006–2013

Templates for listings

Moved from Project:Using Mediawiki templates by (WT-en) Evan

So, I think one of the great lessons of ja: is that it's easy for users to contribute listings using templates, and that the output can look quite fantastic. I'd like to see if we can start moving to using templates for listings on en: and other languages.

I realize that moving entirely to templates for listing would be a huge amount of effort, but I think we can make it work, and I think the payoff could be humongous. I think it will make it easier to have structured listings, and I think it will make it possible to store tags and other metadata about listings and use that data to enhance search ("Where are there Chinese restaurants in or near Marseille which cost around €15 per meal?"). We could start putting GPS coordinates in for individual listings rather than cities as a whole, and use that data for making maps or for coordinating with geo-aware Web sites like http://www.semapedia.org/ .

And, also, I think we can help new users input listings information. I think the following is as easy or easier to figure out and use than our current formatting.


 {{resto|name=Ouzeri|address=4690 Rue St. Denis|directions=one block north of Avenue Mont Royal
        |phone=845-1336|web=http://example.org/|hours=Tu-Th 5PM-1AM, F-Sa 12PM-2AM
        |price=$25-$35|extra=prix fixe on Fr and Sa
        |desc=Fine Greek dining, great selection of ouzos and Greek wines. Stylish and modern.
              Try the flambé cheese hors d'oeuvre -- it's dramatic.
        |geo=45.5253,-73.5857
        |tags=greek,modern,wine,ouzo,popular,mid-range,plateau}}

(The last two entries would be invisibly rendered as RDF.) We could also look into enhancing our interface with e.g. the Inputbox extension to make adding a new listing (or editing one...?) easier. We'd also need to have parameter defaults working so that incomplete listings like:


 {{resto|name=Ouzeri|address=4690 Rue St. Denis|phone=845-1336}}

...do the right thing. Another benefit of using structured data is that we can start using bots more often for things like geocoding addresses or fixing common formatting mistakes.

The big problem here is not technical but social and organizational. Can and should we do this? Is it worth the effort to get structured listings? Bots and other automation may be able to handle some percentage of the existing listings (...30%? 60%?), but there will be a lot of gruntwork -- I think our experience with removing External links sections, or adding isIn data, is probablly representative.

Of course, if we want to do this, it's not going to get easier later.

I'd like to start talking about this and maybe work up some sample templates that render, more or less, to our current formatting. Comments? Questions? Ideas? --(WT-en) Evan 10:58, 4 March 2006 (EST)

Hell yeah, I've been agitating for this for a long time (you can blame me for doing it in ja: in the first place!) and would be behind this all the way. However, I still think that it's too much to ask for users to be able to edit the raw templates, so enabling/extending Inputbox or equivalent is essential. And sure, there's gruntwork, but there's already a lot of continual gruntwork just in whipping entries into MoS shape and templating would do away with this once and for all. (WT-en) Jpatokal 11:08, 4 March 2006 (EST)e

I think this is a super-great idea! I think we've proven with the +isin -ext links our ability to do site-wide cheanges (heck, I think it's a great way to get people working on pages they otherwise never would have seen). Anyway, I think structured data is going to open up a lot of neat stuff and is 100% the way to go. (WT-en) Majnoona 11:48, 4 March 2006 (EST)

What jpatokal said. We should make it structured without making articles ugly to look at or forbidding to edit. Someone visiting for the first time should be able to add or edit listings without the experience turning negative for him. I just had a look at ja: and I think they've got it right. --(WT-en) Ravikiran 11:31, 4 March 2006 (EST)

And while we are at it, I'd like to revive the idea of using a wizard while creating a new page - a simple one which asks if it is a smallcity, bigcity, region, itinerary, traveltopic etc. and simply inserts a template to edit. --(WT-en) Ravikiran 11:56, 4 March 2006 (EST)

I'd like to volunteer to convert Singapore (and for time being only Singapore) to use templates, and work out any bugs in the process. Any objections? (WT-en) Jpatokal 10:32, 2 April 2006 (EDT)

I wouldn't be opposed, but can any templates that are created be given names that are obvious English words? Someone seeing "resto" wouldn't necessarily know what that's for. Also, are separate templates going to be created for hotels, bars, restaurants and attractions, or is one template sufficient? -- (WT-en) Ryan 15:07, 2 April 2006 (EDT)

I think a lot of it is common, but what about doing Template:Eat for restaurant listings, Template:Drink for bars and clubs, Template:Sleep for hotels and Template:See and Template:Do for attractions? I think they're going to be a lot the same, if not identical.

On top of this -- I'd like to develop extended wiki markup for Wikivoyage listings so that a) listings can be rendered as hcard HTML and b) we can save out the listings on the back end into a database, which could then be searched/reviewed/updated/shared/etc. I think getting these templates started is key... at some point we'd just swap the custom tags into the template. I'll put up some examples at User:(WT-en) Evan/hcard examples. --(WT-en) Evan 15:39, 3 April 2006 (EDT)

Agreed with using the verbs for the template names, that's how it's done in ja: and it seems to work fine. I even experimented a little with doing a meta-template which is included into other templates to make the formatting consistent, but I don't think this level of complexity is necessary in the English version.

But Evan, are you saying I should plunge forward with just plain vanilla templates, and the hcard conversion can then be done at some point in the future? I don't really see the big difference between Wikimedia templates and hcard, both are structured forms of information that can be post-processed easily with nothing more than a string parser.

I do think the DB idea is key though: it would be really spiffy-keen to have a shared database accessible across all Wikivoyage versions, so (eg.) changing the telephone number in French version would automagically change the number in Japanese one too. (WT-en) Jpatokal 09:52, 4 April 2006 (EDT)

Yes, I think that's one big use; we might even make that database available separately.

So, I had hoped that we could do this: make templates that contained (vanilla) wiki markup, and then later replace the vanilla wiki markup with listings tags, so that Template:Eat would start off as * '''{{{name}}}''', {{{address}}}, ... but eventually change to * <hcard name="{{{name}}}" address="{{{address}}}" ... >. But custom tags don't work very well with template parameters, so I guess I'd ask either a) plunge forward and be prepared to pull back or b) don't plunge forward for a day or so. -- (WT-en) Evan

A day, as in a single 24-hour period? Egads! I think I can restrain myself that long... (WT-en) Jpatokal 12:54, 4 April 2006 (EDT)

Yep. I've already started work on the custom tags, and I'll get them rolled out on wikivoyage.org by 1PM EDT tomorrow. We can experiment a bit to make sure they look right (I could probably use some CSS2 help on them...) and then start doing a run-ahead on Singapore and its districts. --(WT-en) Evan 13:51, 4 April 2006 (EDT)

Listings tags

So, there are now 5 custom tags to start experimenting with for listings. They are <eat>, <drink>, <sleep>, <see>, and <do>, and all of them have the following attributes:

name
address
directions
phone
email
fax
url
hours
price

None of these are mandatory technically (although things get screwy if you don't use a name). The contents of the tag become the description of the listed attraction. An example:

* <sleep name="Auberge de la Fontaine" address="1301 rue Rachel est" phone="+1-800-597-0597" 
fax="+514-597-0496" url="http://www.aubergedelafontaine.com/" price="$100-$280">Fun B&B with 25 rooms. 
Located on the Plateau and across the street from Parc Lafontaine. </sleep>

This becomes:

<sleep name="Auberge de la Fontaine" address="1301 rue Rachel est" phone="+1-800-597-0597" fax="+514-597-0496" url="http://www.aubergedelafontaine.com/" price="$100-$280">Fun B&B with 25 rooms. Located on the Plateau and across the street from Parc Lafontaine. </sleep>

Note that I haven't yet integrated listings into the list format. I'm going to try to re-style these listings to look more like ja:'s listings, although I'm not sure we want to do that yet. Should we try to convert listings to use this structured format first, then change the look and feel? Or do it first as an incentive to change over? --(WT-en) Evan 13:24, 5 April 2006 (EDT)

P.S. Those of you who use tails will note that these listings are valid (if imperfect) hcard listings. --(WT-en) Evan 13:26, 5 April 2006 (EDT)

Incentive. I'd like to change the stuff and see that I really changed it. Although the editor would certainly have to change the entire set of listings in one swoop or it'll look awfully funny. Anyway, if we waited, we may wait forever. It would be like looking at a Christmas present wrapped under the tree. -- (WT-en) Ilkirk 15:05, 5 April 2006 (EDT)

Another question: I'm making the names of the tags (<eat>, <sleep> ..) and the names of the attributes (address, phone, ...) configurable in each language version. Any reason not to? --(WT-en) Evan 11:14, 6 April 2006 (EDT)

Yes, languge-configurability is good (ja: already has localized names). Trying these out in Singapore/Sentosa now, and some comments: (WT-en) Jpatokal 11:18, 6 April 2006 (EDT)

URLs should be automatically enclosed in [], so they show up correctly. Now you get the full path visible.
A single blank line after a listing turns into an excessive amount of blank space.
A <buy> tag would also be useful.
If the address is missing, the phone number is also swallowed:

A couple of responses. First, it's actually kind of a pain in the keester to tap into that link-numbering mechanism, so I skipped it for now and I'll try to get back to it later. It's not merely a matter of wrapping things in [] since the processing goes tag → HTML, not tag → Wikitext → HTML. I'll see if I can figure out a way to do it.

I don't think the numbers are necessary or even desirable, they're pointless and rather weird. IMHO just "web" and the arrow would be much better! (WT-en) Jpatokal 13:00, 6 April 2006 (EDT)

Not sure I understand about the blank line but I'll look into it. MediaWiki doesn't handle custom tags very well if the contents are split over more than one line (gar), so Don't Do That. I'll figure out if there's another way to do it soon.

What I mean is that if you leave a blank line after any entry, then instead of ignoring the line (as currently) it turns it into about 2 blank lines' worth of space. See infobox to the right. (Or is it just Mozilla?) (WT-en) Jpatokal 13:00, 6 April 2006 (EDT)

The buy tag is a good idea.

The attribute is actually phone, not tel. viz.

<sleep name="Sijori Resort" phone="+65-6271-2002" url="http://www.sijoriresort.com.sg" price="S$120-">Blah blah</sleep>

This brings up a design question: should we have lots of synonyms for these attributes (phone: tel, voice, ph, telephone), which makes it easy for someone guessing to get it right, or should we have just one name for each, which makes it easier for third-party processors to keep up? I favor the latter. --(WT-en) Evan 12:11, 6 April 2006 (EDT)

Oops! One name each is enough -- as said, for a long-term solution there has to be a way to enter the templates with a friendly wizard, so people never have to guess at the names. (WT-en) Jpatokal 13:00, 6 April 2006 (EDT)

Any progress on fixing these issues? Singapore/Sentosa is now 100% listingfied, but the two bugs that still bug me are 1) the display of links as URLs instead of just "web" [arrow-icon], and 2) the extra white space if I leave empty lines after the listing. (WT-en) Jpatokal 13:26, 8 April 2006 (EDT)

I like just the word "web" (or "website"? or a localized version of same?) for the link. About the whitespace: ugh. I'm going to see what I can do about it; but MediaWiki seems to insist on sticking a " " into pages for no good reason. The last thing I want to do is figure out a good way to render "geo" and "tags". Eventually I'd like to have a Special:Tag that has links to every page and listing that matches the tag (tagcloud, eh?), but I'm going to have to build that out. And I'm not sure how to make it look good (although I think hiding it in the print stylesheet will be good).

Even the word "web" seems superfluous to me; it carries no information. Online, all you need is the box-and-out-arrow graphic in click-me blue (no localization required). Offline, just "http://" is a dead give-away that you're looking at a Web URL. - (WT-en) Todd VerBeek 21:01, 23 April 2006 (EDT)

Here's what I'd like to do next: let's convert 2-3 other big pages and see if we run into anything that we can't handle with the listing format. Then, if we're OK with it, let's change the MoS (Project:restaurant listings, ...) pages to use this format. --(WT-en) Evan 00:02, 9 April 2006 (EDT)

So, I'd be happy to convert all of Singapore, but I'd like to see the extlink formatting changes — I'm fine with either web-arrow or just plain arrow as suggested by Todd. The extra space after the entries is also a bit bothersome. (WT-en) Jpatokal 00:48, 24 April 2006 (EDT)

One more thing: can we add an optional "map" value that just prints out "Map X."? This could be used to point either to a map grid ("A5") or a listing number ("7"). (WT-en) Jpatokal 22:33, 24 April 2006 (EDT)

One additional request: it would be good if it was made policy that when using a tag to create a listing that ALL fields for that tag should be included, even if some are empty. This policy would be similar to the article template policies - we always include the "Sleep" heading, even if there is no content, to encourage people to fill out the section. Similarly, we should also make it policy to always include (for example) the "phone" field in a listing to encourage people to add that information if it is missing. Thus a listing might look like:

<sleep name="Test Listing" address="" phone="" fax="" url="" price="">Description.</sleep>

This is probably a minor point, but I think making it explicit policy that fields MUST always be included, even if blank, is important. Also note that if we make this policy it makes the question of whether or not to allow synonyms (phone/tel/etc) a non-issue since people won't need to guess at values. -- (WT-en) Ryan 22:18, 9 April 2006 (EDT)

How about the GPS coordinates? I think it would be most useful to have the coordinates of the restaurants, hotels etc. listed as well. You could do interesting mashups with Google Maps or if you would have a GPS equipped mobile phone you could query Wikivoyage where to find a restaurant nearby (my problem always with the new cities! :). Street address is a good start but it is not always possible to convert the street address to a correct GPS coordinates. --Timo 18:15, 5 August 2006 (EDT)

Pictures in listings implemented on Japanese Wikivoyage

Just a little heads up: there's now some template magic on ja: to include pictures into the listings, and display a gray default image if undefined. Take a look at eg. Manila. (WT-en) Jpatokal 05:13, 14 April 2006 (EDT)

That's pretty cool. So, I'd like to do that with the tags, but just have nothing if there's no photo. --(WT-en) Evan 08:23, 14 April 2006 (EDT)

Now implemented! (WT-en) Jpatokal 07:09, 30 April 2006 (EDT)

List or not list?

One more thing I'd like to get sorted out: is it really necessary to place the '*' in front of every listing? I think it would be more flexible to enter just <see> and then do the processing under the hood. (WT-en) Jpatokal 07:09, 30 April 2006

In some situations it might be desireable to number listings instead of just bulleting them, to match the numbers used on the corresponding map. (I did this with campsite listings for Isle Royale.) -(WT-en) Todd VerBeek 12:19, 15 May 2006 (EDT)

That's quite brittle though. I've been thinking about doing some sort of automated overlay where you could feed the listings data directly into the map, but creating this would get a bit kinky. (WT-en) Jpatokal 12:56, 15 May 2006 (EDT)

After a week at the Where 2.0 conference, I think this is a huge benefit we could create with Wikivoyage. I think if we served information about listings as a WFS and/or KML service, we could let people include Wikivoyage data in lots of fancy mapping mashups -- some innovative stuff is going on out there. --(WT-en) Evan 15:48, 17 June 2006 (EDT)

The big problem with doing the <li> tag under the hood is that there's no way to generate valid XHTML that way; you can't tell when the list started or ended. I much prefer the ja: style of one table or div per listing. --(WT-en) Evan 15:48, 17 June 2006 (EDT)

Doesn't using the closing </li> tag after every list item make it valid XHTML? --(WT-en) Rogerhc 15:56, 11 June 2007 (EDT)

Additional attributes and tags

So the following attributes would come in handy:

"alt=Blah", for giving a secondary name, esp. in another language. Should be parenthesized and printed in italics after the main name: Sultan Mosque (Masjid Sultan).
"map=A1". Reference to a map page/grid.

Also, a "contact" tag for netcafes etc would be handy. (WT-en) Jpatokal 05:12, 14 May 2006 (EDT)

Just a bump for at least the 'alt' tag -- secondary names look really ugly without this. But if you want to be really high-tech, it'd be nice to italicize only Latin scripts (Ux0000-02FF) and leave anything else untouched. (WT-en) Jpatokal 15:43, 17 June 2006 (EDT)

Tag name redundancy

Do I understand correctly that <see>, <do>, <eat>, <drink>, and <sleep> all have the same attributes? If so, do we really need multiple tags, rather than just a generic custom <item> tag? After all, we place and format all of these attributes the same regardless of whether the item they're describing is a nightclub or a museum or a hostel. The only exception I'm aware of is that the Japanese WT uses color coding for the different types (which is nice), but can't that be done with a CSS attribute attached (via a class?) to the section rather than on each item? Another benefit of a generic tag is that it could also be applied to Get in/Get around/Contact items when those call for compatibly-formatted lists. - (WT-en) Todd VerBeek 18:49, 15 May 2006 (EDT)

Yes, they all have the same attributes. I kind of like having the type of the item in the tagname. Would it be good to add an extra <item> tag (or maybe <listing>...) as a "catchall"? --(WT-en) Evan 22:08, 15 May 2006 (EDT)

Yes, it would be good, and <listing> is the better name of the two. I've already run into the problem of not having a 'type' for eg. netcafes, tourist information offices, laundromats, gyms... (WT-en) Jpatokal 22:21, 15 May 2006 (EDT)

Why couldn't listing tags figure out their own type from the context in which they appear in the file? Didn't somebody figure out a way to do that with the old style listings even? -- (WT-en) Mark 01:05, 16 May 2006 (EDT)

Automated conversion script

So I hacked up a couple of lines of Ruby to convert Manual of Style listings to the tagged format, the source is now available at User:(WT-en) Jpatokal/listing.rb. Basically it works by tokenizing each listing on "," and ".", then using regexps to figure out which piece is which -- so you need to follow the MoS pretty closely, but it does seem to handle most permutations pretty well. The tag name to use is figured out from the previous header. (WT-en) Jpatokal 03:41, 4 June 2006 (EDT)

Where are we on this?

I have a bunch of listings I want to add to the Bombay pages. Does it make sense to wait?

No, it's a good idea to start with these listings now. There are a couple of technical fixes that need to be done, but they'll get added soon. --(WT-en) Evan 14:27, 17 June 2006 (EDT)

Can I add tags for future RDF implementation? — (WT-en) Ravikiran 14:43, 17 June 2006 (EDT)

Yes! All the parts of the listing element can be used. However, one point to note: the list item format is probably going to change to work more like the listings on ja:, so be prepared to get rid of the initial * in the future. I think this will just mean a regexp-replace of '^* <' with '<'. --(WT-en) Evan 15:21, 17 June 2006 (EDT)

I'd like to reiterate my whinge that it would be really, really nice to get the wizard-type pages for adding and editing listings created before we plunge too far forward with this. (WT-en) Jpatokal 15:47, 17 June 2006 (EDT)

Are listing tags approved for use now, or are there still outstanding issues? If so, what are those issues? -- (WT-en) Ryan 23:52, 1 November 2006 (EST)

Bumpity-bump. I think there are now stable and so widely used that it's time to officially make them official, officially-like (that is, rewrite the MoS to recommend them). Can or not? (WT-en) Jpatokal 00:44, 10 June 2007 (EDT)

I think so, is there any reason not to? What's the wizard-type thingy for adding listings that you refer to above? That sounds potentially amazing. – (WT-en) cacahuate ^talk 01:12, 10 June 2007 (EDT)

I recall Evan mentioning that the wizard was up for testing on review, but I wasn't able to find it...? (WT-en) Jpatokal 01:21, 10 June 2007 (EDT)

Try your beloved hometown . (WT-en) Maj 08:50, 11 June 2007 (EDT)

Yep. Just click on the [little gray] "edit" link [at the end of each list item]. It's not finished yet (doesn't save, not all fields) but it will be working RSN. --(WT-en) Evan 08:53, 11 June 2007 (EDT)

Spiffy-keen! Now can you conjure up a button for adding new entries like that as well? (WT-en) Jpatokal 11:19, 11 June 2007 (EDT)

The text fields in the wizard need to be longer. Maybe use a in the Wizard after each input text field to create room for that. --(WT-en) Rogerhc 16:10, 11 June 2007 (EDT)

Wow! That is an excellent piece of work. (WT-en) Gorilla Jones 16:32, 11 June 2007 (EDT)

Holy ravioli, that's a work of pure genius, sent down from the heavens above. Hallelujah. Indeed, a button for adding new entries like that would be at least as useful. Yay! – (WT-en) cacahuate ^talk 01:24, 12 June 2007 (EDT)

How will we convert existing listings to be editable in that way? By templating them the way we already are? Is it worth continuing to implement the tags that we have now? – (WT-en) cacahuate ^talk 01:57, 12 June 2007 (EDT)

Should we continue implementing the tags we've got now? If they're going to be convertible then great, otherwise is it a waste of time? – (WT-en) cacahuate ^talk 02:55, 20 June 2007 (EDT)

Sometimes on long road trips I pee in a bottle so that I don't have to pull over. Then if someone's tailgaiting me I launch a piss-bomb out the sunroof... keeps me amused – (WT-en) cacahuate ^talk 05:04, 23 June 2007 (EDT)

In an effort to head off whatever will be the next attention-getter before I have another such visual burned into my brain, you may want to leave a note on Evan's talk page to get his comments, since he's really the only person who can answer this one. -- (WT-en) Ryan • (talk) • 14:34, 23 June 2007 (EDT)

Any chance you're related to this chick? -- (WT-en) Sapphire • (Talk) • 14:46, 23 June 2007 (EDT)

Ha! First time I've ever been compared to a lesbian in adult diapers. – (WT-en) cacahuate ^talk 15:19, 23 June 2007 (EDT)

cacahuate: I'm not sure I understand exactly what you're asking. I don't think it makes sense to do any templates ({{sleep}}, {{eat}}, {{drink}}) to replicate what these custom tags (<sleep>, <do>, <buy>, etc.) are doing. The form-based editor currently on review: uses the same custom tags we're implementing here. You should be able to edit the listings on review either in "form mode" or using wiki text. Ideally there wouldn't be much difference. --(WT-en) Evan 09:25, 25 June 2007 (EDT)

That's what I was asking, I was just using the wrong word... should have said "tags". Wanted to make sure those tags are going to be readable by the new form-based editor, and it seems you're saying yes. So, great! – (WT-en) cacahuate ^talk 05:20, 1 July 2007 (EDT)

Structured tags render with extra paragraph break [was: Possible bug]

The following seems not to format well:

* Here's a bunch of attractions I want to list under some '''common idea''':
 ** <see name="some attraction">Some details</see>
 ** <see name="some other attraction">Some other details</see>

Here's the output, and the last bullet point is doubling:

Here's a bunch of attractions I want to list under some common idea:
- <see name="some attraction">Some details</see>
- <see name="some other attraction">Some other details</see>

(WT-en) Hypatia 23:00, 23 June 2006 (EDT)

Actually, in general there seem to be some whitespace issues. If I follow the common convention of leaving a blank line after all the entries of a section, I end up with an extra line of whitespace in the output. (WT-en) Hypatia 23:13, 23 June 2006 (EDT)

I just encountered the same problem. In my case, in Columbia River Plateau#Other destinations, I had text like:

* <see name="Waitsburg Horse Track" alt="" address="blah" phone="+1-etc."></see>, in [[Waitsburg]]

And it renders with the text after the </see> pushed to a new line, i.e.

<see name="Waitsburg Horse Track" alt="" address="blah" phone="+1-etc."></see>, in Waitsburg

I'd like to see the structured tags render as if they have no paragraph break at the end. I'd like to be able to use them in a second-level list context, outside of a list, and be able to use text in the paragraph after the listing. (WT-en) JimDeLaHunt 03:21, 7 August 2007 (EDT)

Feature or bug?

<eat name = "Britannia and Co" address = "Sprott Road, Ballard Estate, Fort, Mumbai" directions = "next to New Custom House." phone = "+91-22-2261-5264" email= "" fax = "" url = "" hours = "10 am to 3:30 pm (''Open only for lunch'')" price="Rs. 180 will buy you a good lunch.">This rundown restaurant run by a partnership of geriatric brothers (by the name Kohinoor) is a South Bombay institution, having been in existence since 1923. The signature dish is '''Berry Pulav''' the recipe for which the Late Mrs. Kohinoor found in [[Teheran]] while she was working with Iranian Airways. The Parsi favourite '''Dhansak''' is of course available and tastes great. Try the '''Caramel Custard''' for dessert. The waiter may con you to try the Raspberry soda — the first sip is sweet, but the whole bottle is cloying. </eat>

Renders as:

<eat name = "Britannia and Co" address = "Sprott Road, Ballard Estate, Fort, Mumbai" directions = "next to New Custom House." phone = "+91-22-2261-5264" email= "" fax = "" url = "" hours = "10 am to 3:30 pm (Open only for lunch)" price="Rs. 180 will buy you a good lunch.">This rundown restaurant run by a partnership of geriatric brothers (by the name Kohinoor) is a South Bombay institution, having been in existence since 1923. The signature dish is Berry Pulav the recipe for which the Late Mrs. Kohinoor found in Teheran while she was working with Iranian Airways. The Parsi favourite Dhansak is of course available and tastes great. Try the Caramel Custard for dessert. The waiter may con you to try the Raspberry soda — the first sip is sweet, but the whole bottle is cloying. </eat>

Note that single quotes in ''Open only for lunch'' have been converted to "Open only for lunch" and I cannot get to show it in italics.

Bug. Not all tags support markup. (WT-en) Jpatokal 11:31, 9 July 2006 (EDT)

I'd like to keep the contents of the different attributes as easy as possible to edit, and have meaningful separations. How would you feel about an "hours-extra" field for comments about the hours? In fact, most of the different attributes have an italicized extra element that comes after them... --(WT-en) Evan 12:11, 3 November 2006 (EST)

For those of us who are visual learners

Swept in from the Pub:

Has anyone discussed the possiblity of creating some standard icons for various systematic information, such as hours of operation, admission charge, telephone number, guided tours available, photography not allowed, handicap access, restaurant or cafe at the location, etc? Perhaps a small section behind each location description that would include the icons and the related information? I can provide a Photoshopped proof-of-concept if anyone is interested. - (WT-en) Cybjorg 12:37, 15 May 2006 (EDT)

A little bit of that may be coming with a current project to develop custom tags to format listings. You can see an experimental example of a little telephone icon at Singapore/Sentosa#Sleep. I'm not sure that all of the things you mention would be practical, however. For example, handicap accessibility is mandated by law in the U.S., so that icon would have to be added to pretty much every hotel, restaurant, etc. in the country. - (WT-en) Todd VerBeek 15:07, 15 May 2006 (EDT)

I like the idea of tags for various subsets of information. I can't, however, see the telephone icon in your example. My browser (Firefox) simply displays a question mark in place of the icon. Here is a basic sketch of what I had in mind, although it far from refined. - (WT-en) Cybjorg 02:13, 16 May 2006 (EDT)

If you're not seeing the phone, that's probably a font issue; this is using a font character rather than a font image, and the font in use on your system probably doesn't include one. I do like the idea of using icons like this in the listings. It helps break them up visually, making it easier to find information quickly. - (WT-en) Todd VerBeek 08:04, 16 May 2006 (EDT)

(WT-en) Mark's new stylesheets automatically use a section-appropriate icon instead of the usual bullet for the "bulleted list" -- this was part of his style redesign which was done as his entry to the new logo contest. It's a bit of a mystery to me why Evan hasn't implemented it. See his demo site -- (WT-en) Colin 15:42, 17 May 2006 (EDT)

It's a nice looking redesign. I would like to see a full page option, as well as a refined print style sheet, but I like Mark's ideas. I especially like the Table of Contents floated to the right-hand side. - (WT-en) Cybjorg 01:16, 18 May 2006 (EDT)

If you click the arrow in the upper-right of the page, it will widen to full-width. -- (WT-en) Colin 01:32, 18 May 2006 (EDT)

Now that I've explored the page a bit more in depth, I also notice that he placed links to various style sheets, including one for print. Very clever. - (WT-en) Cybjorg 02:27, 18 May 2006 (EDT)

Colin: sorry about the mystery. I think there are some great features in the skin. I'm currently adapting some of the ideas from Mark's skin into Wikivoyage, but it will probably not be included in toto into the site. --(WT-en) Evan 10:05, 18 May 2006 (EDT)

Which ideas make the cut? Which ones don't? I wouldn't have spent quite so much time on it or worked so hard to satisfy Niels' requirements if I'd known that it was only ever going to be a demo. -- (WT-en) Mark 16:47, 18 May 2006 (EDT)

I like the sharp edges and the colors as well as moving the table of contents. I like the stylesheet switcher -- it's elegantly executed. I'm not so hot on the per-section listing icons, since we've already got so many images loaded per page. I understand the motivation, but I'd rather reduce than increase the number of files that need to be loaded to see any one page. (See for some points about optimizing our pages.)

I also think it might be possible to do the per-item icons using CSS2 rather than by reparsing the HTML output; Maybe with a CSS selector like: h3#Eat + ul li, but that would require changing how headers are generated (a good thing, in my opinion). I'm not sure how well the "+" in a CSS selector works.

Do you have some key parts that you think are vital to include? --(WT-en) Evan 17:13, 18 May 2006 (EDT)

The one-column style is emotionally important to me since it took the most time, and since I made it directly in response to a user's (Neils') requirement. Do you really think that the listing icons are so heavy? They are less than 1k eeach after all, and should get cached anyhow.

As for the method for delineating the sections, there's a comment right there in the PHP code begging for a better way to do it. -- (WT-en) Mark 17:54, 18 May 2006 (EDT)

Considering the size and repetition of the wee icons, I can't see them adding substantially to the "weight" of Wikivoyage's pages. I developed a web site 10 years ago that used several images that size in much the same way, and even at 19.2 or 33.6kbps it didn't noticeably affect page-load times, even on the entry page. (Of course all of my HTML was lovingly and optimally hand-coded with height and width attributes, but still...) - (WT-en) Todd VerBeek 18:16, 18 May 2006 (EDT)

I'd like..

I'd like to create a new listing tag, which I guess would be called <event> or what have you. The idea of the tag is to provide the information needed for large festivals or events, but is not covered with the other tags. Something like this:

* <event name = "Oktoberfest" location = "Address or location of event" directions = "directions" transportation = "Bus and subway routes" parking = "Where to park and cost" url = "http://www.fakeurl.com" hours = "9 pm -5:30 pm" admission="Rs. 50 for entrance">Stuff about the event. </event>

How would I go about creating this? -- (WT-en) Sapphire 05:41, 13 August 2006 (EDT)

My take on tags

As someone who has done his share of MoS edits, I feel entitled to put my two cents worth in. I can see the obvious DB benefits to all this, but I really see the method as burdensome to those creating and editing listings. Adding the labels adds a lot of work which will fall on those who are not too lazy to just stick down the name of a place and it's URL. Seems to me like it will work against contributors unless a way is found to translate via some "listing maker" script or something. (WT-en) OldPine 13:15, 22 August 2006 (EDT)

The reason I like these listings is because users seem to provide more information than they normally would with these new listings. Here's my evidence that they seem to provide more information with these listings. -- (WT-en) Andrew Haggard (Sapphire) 14:57, 22 August 2006 (EDT)

I appreciate this note, David. One major goal with these tags is to make a popup form for editing, so that you don't have to remember all the fields. There may be some other ways to make them work better, though. --(WT-en) Evan 21:38, 22 August 2006 (EDT)

I am with David on this. A lot of my editing is cut and paste from other sites, then editing to MoS or as close as a hillbilly can get. It seems to me this will be a lot of work for those of us who scour the pages and do MoS edits. Now if there is a script that will go out and do it, then great! But I am thinking this will take me extra time to use. The rigid format is nice, but will it really help to get the job done? Everytime I bring it up, I go ick! I'm not spending that time. -- (WT-en) Tom Holland (xltel) 10:40, 23 September 2006 (EDT)

Non-latin alphabets

I'd like to start using these tags on the Dalian article I've been working on, but as things stand I can't because there's no way to properly handle Chinese names. For example, the Shagri-la hotel listing currently looks like this:

Shangri-la (香格里拉大饭店 xiānggélǐlā dàfàndiàn), 66 Renmin Lu, +86 411 8252 5000 . Blah Blah Blah. 880-1,900 RMB

Now, if I were to change that to use tags using the following code:

*<sleep name = "Shangri-la (香格里拉大饭店 ''xiānggélǐlā dàfàndiàn'')" address = "66 Renmin Lu" directions = "" phone = "+86 411 8252 5000" email= "" fax = "" url = "http://www.shangri-la.com/dalian" hours = "" price="880-1,900 RMB">Blah Blah Blah.</sleep>

it would come out as follows:

<sleep name = "Shangri-la (香格里拉大饭店 xiānggélǐlā dàfàndiàn)" address = "66 Renmin Lu" directions = "" phone = "+86 411 8252 5000" email= "" fax = "" url = "http://www.shangri-la.com/dalian" hours = "" price="880-1,900 RMB">Blah Blah Blah.</sleep>

With the characters in bold and no way to italicise the pinyin (which is what Project:Romanization recommends). The only way I see around it would be to create two extra fields, one for non-latin characters and another for romaised pronunciation guides. A pain in the arse, I know, but until that's done these tags aren't going to be much use for articles relating to countries with different writing systems.

On an unrelated note, I was thinking about the phone/fax number field and was wondering whether or not it'd be an idea to add separate fields for country/area codes. That way any distributers of printed/CD versions could easily ommit the codes if their guides are limited to one country or area. I realise it'd create even more fiddly work for editors, which is why I'm somewhat ambivalent about it. Having said that it might, perhaps, be theoretically possible to automate the codes by checking what country/city the article belongs to. I know it could be done, albeit in a long winded way, through meta-templates but I'm not sure exactly how these tags work. --(WT-en) Paul. 10:17, 9 September 2006 (EDT)

Yeah, I was already suggesting this above in Additional attributes and tags, so the listing above would be name="Shangri-la" alt="香格里拉大饭店 xiānggélǐlā dàfàndiàn". This is absolutely critical for Japanese and Korean too. (WT-en) Jpatokal 10:47, 9 September 2006 (EDT)

Agreed. I'm going to hunker down and get all the outstanding feature requests and bug fixes done for listings next week. --(WT-en) Evan 11:42, 9 September 2006 (EDT)

Hi, how is it going? I bumped into the same problem with the Guangzhou page. I converted the eat/sleep parts to listings, but the bolded Chinese characters look like a mess (especially with anti-aliased fonts). --(WT-en) Trsqr 16:45, 16 September 2006 (EET)

Nitpicking

The example given changes the standard time indicators from AM and PM (in the old listing examples) to am and pm. Is this done purposely? Are we tossing out the italicizing of the optional part of phone numbers? Maybe I care too much about standardization? (WT-en) OldPine 18:45, 17 October 2006 (EDT)

No, that's fine. I'll fix the AM/PM thing.

For the optional parts of phone numbers, I'd like to consider some other options, as discussed with Andrew and Mary in IRC. Namely: guides can have a special RDF tag, {{phoneCode|123}}, which sets the phone code for that destination to 123 (or whatever). The default phone code is prefixed to all the phone numbers in listings.

The prefixes are strung together geographically according to the IsIn hierarchy. That way, if the phoneCode for United States of America is 1, and the phoneCode for Santa Monica is 310, then the phone numbers prefixes will be automatically prefixed with +1-310- . If there's a funky phone code situation, then you can add an override at the guide level with {{fullPhoneCode|4-333}}</nowiki>, or at the listing level with a phonecode attribute.

No matter what the phone code is, it will be formatted in italics just in front of the phone number. Does this sound OK? --(WT-en) Evan 15:36, 2 November 2006 (EST)

Yep! Sounds good! (WT-en) OldPine 16:46, 2 November 2006 (EST)

That clever scheme won't work. A hotel open only in winter is going to have a reservations number in a different city with a potentially different area code. In the US, some hotels have only tollfree numbers and no alternative. Or maybe a hotel will be part of a chain, and the chain takes care of running the reservations lines but has a single central number even though the hotels are scattered about several area codes. And once you step outside of the US, I'm pretty sure you can get multiple phone carriers in some areas each with different prefixes. I think you need a different plan for how to cope with the italics. -- (WT-en) Colin 16:49, 16 November 2006 (EST)

Oh, absolutely. If a listing has a phone number that doesn't match the default phone code for the destination, it can have the full international dialing version. If a phone number in a listing tag starts with a plus ("+"), it will be rendered verbatim, without any of the other phone codes prepended. So <sleep name="Some Hotel" phone="555-1234" tollfree="+1-866-555-5678" .... I'll need to do some phone-number-parsing to determine which parts are prefixes and which parts aren't, but I'm sure that's a tractable problem. --(WT-en) Evan 10:01, 12 December 2006 (EST)

This sounds an excellent idea. One big plus is that it would make it easier for others (either mirrors or printers) creating tailored guides to individual areas to customise what the phone listings look like. So somebody distributing a guide solely for one city wouldn't have to include the local and national code every time. --(WT-en) Paul. 11:27, 12 December 2006 (EST)

What's left?

I think there are only a few things left to do on listing tags. Here's my todo list, roughly in order:

Automatic area codes, country codes, or city codes. As described above.
HTML form editing. Each listing would show an [edit] link (maybe only if you mouse over it). When you click edit, the listing is replaced by a form, with one textbox for each attribute, and a "save" and "cancel" button. Saving will do an AJAX call to the server, and replace the contents of the page correctly.
Do something with the geo attribute. I'd like to use the Mapstraction library to make some automated mapping for listed items. I don't think this is a good replacement for real maps, but it might be helpful.
Do something with the tags attribute. My goal is for each tag foo, to make a link to Special:Tag/foo, which would list every page and listing tagged foo (maybe with fancy tag clouds and stuff).
Conversion bot. Expand Jani's script for converting listings so that it's more forgiving, and apply it to as many pages as possible.

I think that once the phone code thing is sorted out, we can start moving to this format. The other stuff doesn't require any changes to the data. Is this about right? --(WT-en) Evan 16:19, 2 November 2006 (EST)

Please don't forget the alt tag proposed above. (WT-en) Jpatokal 23:03, 2 November 2006 (EST)

It's done! --(WT-en) Evan 01:48, 3 November 2006 (EST)

Err -- could you fiddle the code so it italicizes only Latin characters (Ux0000-02FF), and not the rest? Most non-Latin scripts (see below) should never be italicized. (WT-en) Jpatokal 03:24, 3 November 2006 (EST)

<do name="Test entry" alt="해수피아 Korean 赤あかアカ Japanese 中华人民共和国 Chinese">Sniff sniff.</do>

If that's the case, can you do some work on Project:Foreign words to make that clear? As far as I can tell, they should be in italics. --(WT-en) Evan 11:10, 3 November 2006 (EST)

Edited. Basically, italics are a Latin convention and should only be used for Latin scripts (and maybe Greek, but probably not Cyrillic). (WT-en) Jpatokal 23:29, 5 November 2006 (EST)

Cool, and good to know. I'll try to fix the listings code in the next 48 hours. --(WT-en) Evan 00:01, 6 November 2006 (EST)

Any progress on this? It's still not possible to convert Chinese, Korean, Japanese etc. articles as things stand. --(WT-en) Paul. 15:20, 28 November 2006 (EST)

Yes, this is done now. You may need to do a force-reload to get the new stylesheet, but non-latin chars are now put in an extra span in the alt attribute, which should not show up italic. --(WT-en) Evan 17:38, 6 December 2006 (EST)

Is it too late for another request? How about an IATA/ICAO code attribute so I can get a little creative when I make an airport listing? -- (WT-en) Andrew H. (Sapphire) 01:53, 3 November 2006 (EST)

We don't usually do structured airport listings, though. Could you maybe start Project:Airport listings or bring it up in the Pub? I'd rather have the listings format follow the MoS rather than lead it. --(WT-en) Evan 11:10, 3 November 2006 (EST)

Maybe not the place to ask (apologies in advance), but why do external links open in the same window and not a new window? Seems counter-intuitive to me. (WT-en) OldPine 11:14, 3 November 2006 (EST)

On Safari and Firefox (and maybe the new Explorer), a middle click on a link opens it in a new tab or window. I prefer this because it lets me decide if I want a new window instead of forcing this on me. -- (WT-en) Colin 11:34, 3 November 2006 (EST)

That's my feeling too. The best place to ask this kind of question is on wts:Technical requests. --(WT-en) Evan 12:08, 3 November 2006 (EST)

Sounds right, and though I have never wished to have it in the same window, I support what you're saying. I guess there's some easy way now to log into en and shared all at once, but frankly I'm too old a dog to handle more than en. (WT-en) OldPine 16:56, 3 November 2006 (EST)

There was a request made a long while ago to have Special:Recentchanges for each language version also include changes made to shared, which would make it easier for everyone to keep track of what's happening on shared, although I can't find that discussion now. I also tend to log in to shared very seldomly, and thus miss a lot of what's going on there. -- (WT-en) Ryan 17:05, 3 November 2006 (EST)

Tags Needed

tollfree - these numbers are common in the US and are convenient if are dialing from the US.... but they are inaccessible to international callers so it would be nice to tag them differently than mere phone numbers so that international users don't have to memorize the seven different tollfree area codes in +1
toll free fax - ugh.
reservations vs. hotel main line - Sometimes a hotel lists separate numbers for calling the hotel itself vs. calling to make a reservation. I suppose the hotel should be able to refer your to the other, but maybe we should support having both
geo - are you sure (y/n)? lat and long as separate entries makes a ton more sense to me and a lot harder to get wrong, but hey I don't have to write the parser so if you're sure that's how you want it...
check-in and check-out for sleep entries. The examples suggest using hours for this, but that's going to lead to style differences in exactly how to phrase it.

-- (WT-en) Colin 16:59, 16 November 2006 (EST)

Some comments, for which I'm sorry I've taken so long. I'm a little reluctant to add attributes for every kind of phone number an establishment can have, but I'm not sure what our alternatives are. One possibility is just having phone2, phone3, phone4, ... attributes. That's pretty blecherous. Another is to have a phone-extra attribute, which renders as an italicized parentheses, which you can put alternate phone numbers or comments in, whatever. So phone="+1-514-555-1212" phone-extra="tollfree: +1-866-123-4567, reservations: +1-514-555-1111". I'm not crazy about that one either.

w/r/t geo, it's not killing me to do a single pair of comma-separated numbers, but you may be right there.

w/r/t the checkin and checkout times, well... I dunno. I think there's a tension in designing this kind of thing between having relatively large attributes with maybe some structured data in it, versus having fields broken down at the atomic level. For example, we have address, but many user interfaces have street-number, street-name, street-type (St., Rd., Blvd., ...). I think the checkin-checkout items might be a good idea, though. --(WT-en) Evan 23:26, 20 November 2006 (EST)

Totally understand about not wanting to put in lots of extra fields. But if there's only one phone number, then the US-o-centric contributors (and marketeers) are going to add the internationally unusable numbers. And that pretty much defeats the point of using internationally dialable phone numbers. -- (WT-en) Colin 23:58, 20 November 2006 (EST)

Another option, and this is probably as ugly or moreso than the existing proposals, is instead of using lots of attributes to instead use child elements which could then have their own attributes. For example:

<sleep name="hotel name">
    <phone number="+1-999-999-9999" />
    <phone number="+1-888-888-8888" label="toll-free" />
    <hours checkin="1PM" checkout="11AM" />
    This hotel is wonderful and has two phone numbers.
</sleep>

I don't know how the existing tags have been implemented, and using child elements may be technically too difficult to consider, but from a practical standpoint it seems like it might add some flexibility. -- (WT-en) Ryan 00:44, 21 November 2006 (EST)

Actually, I think that's pretty elegant; using sub-elements would actually be nicer than attributes if we have a lot of optional fields. However, I'm less concerned with complicating the markup than with complicating the ultimate form interface. Having lots of optional text boxes will make it look pretty daunting... although I guess we could do a basic interface with the most rudimentary fields, and an advanced interface with more of them. --10:18, 21 November 2006 (EST)

So, I'd like to split the difference here and limit our phone number fields to four: phone, fax, toll-free and phone-extra. The last one would be a catch-all text field in which extra phone information or extra phone numbers could be added (without any special styling). I'll add separated lat and long attributes and fall back to geo if they don't exist. Finally, it will make me sad, but I'll add the check-in and check-out attributes for sleep entries, with a fallback to hours if they don't exist. Finally, I'm going to add an hours-extra and price-extra attribute for extra price and hours info. --(WT-en) Evan 14:54, 4 December 2006 (EST)

Please also consider "textphone", as used by people with speech or hearing disabilities. Thank you. (WT-en) Andy Mabbett 09:55, 5 December 2006 (EST)

"textphone" is the kind of exceptional situation which would fit nicely in the "phoneextra" section. --(WT-en) Evan 17:41, 6 December 2006 (EST)

People who need to use such facilities also need to know which number they're available on. You might also like to note the "types" of telephone number currently catered for by hCard, based on those for vcard: home, work, pref, fax, cell, pager. (WT-en) Andy Mabbett 04:18, 7 December 2006 (EST)

OK, I've done all that I said I would just above here on 4 Dec. The only exception is that all the attributes I had hyphens in, like "check-in", don't have hyphens, so it's "checkin". It's part of the deal with MediaWiki. I've updated the main part of the listings page, but it could probably stand to propagate to each of the tag types. --(WT-en) Evan 17:41, 6 December 2006 (EST)

Whoo hoo! Too bad I have to work late tonight and can't launch the bot until late tonight. Thanks! -- (WT-en) Colin 20:52, 6 December 2006 (EST)

Bot Inserted Listings

At Ryan's suggestion, I'm having my bot insert the full set of applicable tags for the sleep listings -- even the optional ones. I'm skipping hours, geo, and tags. I guess the reasoning is that this invites editors to add the extra info. This would not be the normal way a human would do this since I think it's too much to ask of our contributors that they stick in all the fields.

Any second opinions on this? -- (WT-en) Colin 00:18, 17 November 2006 (EST)

Colin and I have already discussed this issue somewhat on his talk page, but I suspect seeing the full set of listing attributes would encourage people to "fill in the gaps", just as they do with articles having empty template sections. It would be nice if there was an easy way for Joe Average User to insert an empty listing tag complete with empty attribute tags, but I'm not sure how to handle that - I normally just copy a full tag from Project:Listings, but it's kind of a pain to do so. -- (WT-en) Ryan 00:56, 17 November 2006 (EST)

Writing a bot to add the missing tags would be kinda trivial :-) -- (WT-en) Colin 01:06, 17 November 2006 (EST)

If we need to, we can add a set of edit tools like Wikipedia:MediaWiki:Edittools. It's probably also worth noting that with form-based editing, there will be an empty box for every item that isn't filled in. So I don't know if there's much need for the empty attributes. --(WT-en) Evan 09:02, 17 November 2006 (EST)

Tagging

For properties such as "toll free", "dog friendly", "licensed", we could use the 'rel-tag' microformat, linking to pages such as http://en.wikivoyage.org/w/licensed, where there could be a definition of the term, links to other relevant pages, or whatever. (WT-en) Andy Mabbett 16:31, 25 November 2006 (EST)

Name property

The property "name" is described thus:

the name of the hotel, bar, restaurant, museum, or whatever. Recommended.

Note that it's required for hCards. (WT-en) Andy Mabbett 16:40, 25 November 2006 (EST)

Yes, but you can't require much of anything on a wiki. So, listings without names won't be valid hCards. --(WT-en) Evan 17:10, 25 November 2006 (EST)

Better to not parse them, than publish invalid hCards. (WT-en) Andy Mabbett 16:45, 26 November 2006 (EST)

Telephone number format

ITU-T Recommendation E.123, or the Notation for national and international telephone numbers Recommendation E.123, defines a standard way to write telephone numbers. It recommends the following formats (when dialling the area code is optional for local calling):

   Telephone number, national notation:      (042) 123 4567
   Telephone number, international notation: +31 42 123 4567

The parentheses are used to indicate digits that are sometimes not dialled. Parentheses should not be used in the international notation. (WT-en) Andy Mabbett 18:21, 25 November 2006 (EST)

I think that's the format we use; see Project:Phone numbers. --(WT-en) Evan 14:57, 4 December 2006 (EST)

I'm sure I've seen parentheses in numbers, but can't recall where. Sorry. (WT-en) Andy Mabbett 10:50, 5 December 2006 (EST)

More on addresses and hcard microformats

I've just added a listing for RSPB Sandwell Valley to the page on Birmingham (England). It seems that the whole address is marked up as class="street-address". I believe that it should be just "adr" (but feel free to check on the uFs wiki or mailing list). More helpful would be to mark up the postcode (or zip code) separately (class="postal-code"), as some tools then pass these to mapping sites.

Also, for UK locations, an Ordnance Survey grid reference (e.g. SP035928) would be useful as an optional attribute. (WT-en) Andy Mabbett 16:41, 26 November 2006 (EST)

The address section is only for the street address, not for post codes or other postal information. These listings are for finding restaurants, hotels, etc., not sending them postal mail. --(WT-en) Evan 14:58, 4 December 2006 (EST)

I don't see why not; but, as I said, postcodes are also useful for mapping/GPS (not to mention orientation); and class="adr" is required, for vCard addresses, so "street-address" MUST sit within such a span to be included as part of a valid hCard. (WT-en) Andy Mabbett 10:50, 5 December 2006 (EST)

Seems like it might be a good thing to add the rest of the address information to the tag and then not display it, especially since it should be possible to derive at least the city name from the breadcrumb. It should also be possible to have a bot scrape the web for postal code data and add that later. -- (WT-en) Mark 19:15, 7 December 2006 (EST)

Emboldening issue

I entered hours="'''closed throughout 2007'''" (on the entry for Aston Hall), but the apostrophes were displayed literally, and the text was not emboldened. (WT-en) Andy Mabbett 08:04, 28 November 2006 (EST)

The attributes hold plain text, not wiki text. Styled stuff like that won't work. --(WT-en) Evan 15:00, 4 December 2006 (EST)

I'd suggest that that's documented on the main listings page, then. (WT-en) Andy Mabbett 10:50, 5 December 2006 (EST)

Lat and long decimal places

User:(WT-en) Pigsonthewing added this to the lat/long info: Note: lat and long SHOULD have the same number of decimal places (using trailing zeroes if applicable). I think if we're going to support the geo microformat this is important for output, but that doesn't mean that people need to put any particular number of digits in the input. So I removed it. --(WT-en) Evan 19:23, 10 December 2006 (EST)

No. In coordinates, the number of decimal places specifies the level of precision, so 52.1200 != 52.12. I'll restore the wording.(WT-en) Andy Mabbett 06:24, 11 December 2006 (EST)

In wikis, we try not to set arbitrary rules on input, especially if they can be handled by the software (like this one can). If it's important, I can balance out the number of decimal places programmatically for the output. --(WT-en) Evan 10:27, 11 December 2006 (EST)

It's not arbitrary, and it cannot be handled programmatically, because, as I said, for coordinates, 52.1200 != 52.12. It's also a SHOULD not a MUST, which should satisfy the casual approach taken in Wikis. Incidentally, those words are usually capitalised, in such contexts, per RFC 2119. Balancing decimals certainly is important for output, when I believe MUST applies. This issue is, if you balance while creating the output, do you discard precise data from one value, or infer it, perhaps wrongly, for the other? (WT-en) Andy Mabbett 11:30, 11 December 2006 (EST)

This is a user manual, not an RFC, so in fact the context is different. We use italics for emphasis if we need to. And I'll try to remember to balance out the decimal for output here. --(WT-en) Evan 11:33, 11 December 2006 (EST)

The convention is common in user manuals also, in my experience. RFC 21109 applies to the use of the terms in any document, not just in other RFCs. Also, not that "If latitude is present, so MUST be longitude, and vice versa". (WT-en) Andy Mabbett 14:29, 11 December 2006 (EST)

I don't really see any harm in having the software balance out a user's input by padding a couple of "0" on the end of the latitude string if necessary. Am I wrong? -- (WT-en) Mark 01:41, 2 January 2007 (EST)

Yes. If you add zeros, you're adding information that isn't there - how do you know that the user didn't omit a pair of nines, or some other figure. The only acceptable way to treat mismatched figures is to truncate the one with more digits. Far better to encourage users to be more through in the first place. (WT-en) Andy Mabbett 09:22, 2 January 2007 (EST)

slight fix needed on accomodation listings

See the "check out time" on the mid-range sleep listings on the Chittagong page... needs a period and a space after, before the description... (WT-en) Cacahuate 00:52, 6 January 2007 (EST)

*BUMP* -- (WT-en) Ryan 13:42, 15 January 2007 (EST)

This is fixed now. I also fixed a problem with italicizing the "directions" field. --(WT-en) Evan 13:01, 22 January 2007 (EST)

multiple attributes of one kind per item

Is there any recommendation on having two emails for a single hotel? Using email="email1@example.com; email2@example.com" obsiously gives mailto: them both at once, which may be not supported by some email clients, and it feels better for me to provide traveller a choice which email to use even before email compose window appears. --(WT-en) DenisYurkin 18:27, 6 January 2007 (EST)

BUMP. --(WT-en) DenisYurkin 17:50, 7 August 2007 (EDT)

prices appear beyond bullet in multi-paragraph listings

For sleep tag, prices sometimes drop away from the bulleted block, appearing with no indent. I created a sandbox page demonstrating that: User:(WT-en) DenisYurkin/Sleep sandbox (note the last line on that page). --(WT-en) DenisYurkin 19:32, 6 January 2007 (EST)

You're supposed to format the stuff inside the tags as a single paragraph. Even when things are manually formatted, that's how the MoS asks for listings to be formatted. -- (WT-en) Colin 19:59, 6 January 2007 (EST)

Now we have the same problem in Budapest/Pest#See (see Budapest/Pest#Museums for just one of many examples). Unlike accommodation and places to eat, attractions have every right to have long and detailed descriptions--and they usually have indeed. How are we going to deal with cases like that? --(WT-en) DenisYurkin 17:56, 7 August 2007 (EDT)

I think you can get around this problem by filling out the template, but leaving the description blank, then writing the multi-paragraph description immediately below. I sort of did this for Gori#See, although those descriptions were not actually multi-paragraph. --(WT-en) Peter ^Talk 19:16, 7 August 2007 (EDT)

It's only a workaround, not a recommended solution, right? I mean, in my belief this solution doesn't fit well into the concept of the tags. --(WT-en) DenisYurkin 10:49, 8 August 2007 (EDT)

The example that is in your sandbox could be edited down to about 2 sentences... I don't think we should be adding 's into the listings... but I do see the problem with the museum example you gave. It's odd that the 2nd paragraph gets indented properly, but not the third... strange... maybe listings that require more than 2 paragraphs should be made into their own subsection... see San Francisco#See – (WT-en) cacahuate ^talk 01:48, 9 August 2007 (EDT)

HTML in listings?

I just noticed this on the Eger page

 * <sleep name="Senator Ház" address="Dobó tér 11." phone="+36(36)320-466 (tel/fax)" email="senator@enternet.hu"
 fax="" checkin="" checkout="" price="" url="http://www.senatorhaz.hu/"><span id="Senator_Haz"></span>Owner: András Cseh--
 very helpful in person, which is not obvious from emails until you arrive.<br>Most recommended is '''Pátria Panzió''',
 a new building just a quarter away (at Szúnyog köz 3). 
 <br><u>Details:</u> Recommends horseriding  at [[#Matyus_Udvar_Haz|Mátyus Udvar Ház]], but can't help to book with
 them.</sleep>

Which shows up as

<sleep name="Senator Ház" address="Dobó tér 11." phone="+36(36)320-466 (tel/fax)" email="senator@enternet.hu" fax="" checkin="" checkout="" price="" url="http://www.senatorhaz.hu/">Owner: András Cseh--very helpful in person, which is not obvious from emails until you arrive.
Most recommended is Pátria Panzió, a new building just a quarter away (at Szúnyog köz 3).
Details: Recommends horseriding at Mátyus Udvar Ház, but can't help to book with them.</sleep>

Am I wrong in thinking this goes against the MoS or did I miss a discussion? It really adds more complexity to it, and I don't think it looks great either . I'm also not happy with the "recommends..." wording, that's also not our usual MoS. (WT-en) Maj 23:04, 20 January 2007 (EST)

(WT-en) Maj, all HTML here is mine--and it's solely my idea to introduce it here. As I already replied in my talk page, there was no previous discussion on my usage of HTML pieces like this.

I used only 3 pieces of HTML here. First is used merely to put an anchor we can link to, both from another piece of the article (Eger#Matyus_Udvar_Haz) and from a blog (so I can list places I visited / stayed at in my personal blog, it's in Russian) while driving people to Wikivoyage for details of specific places I recommend (thus developing content at Wikivoyage). Is there a better way to attach an anchor to a specific hotel or restaurant?

Second and third are and . They are used in Senator Ház (which Patria Panzio is a part of) to introduce some structure to a soon-to-be-longer description like in Matyus Udvar Haz or Fanari Villas. You're right that right now there's not enough content for structurizing--but I will add more in a couple of days. Same for 'recommended' piece--I will add specifics and hopefully end up without recommendation clause at all, at least this will be more MoS-compliant.

Please let me know what you think. --(WT-en) DenisYurkin 02:42, 21 January 2007 (EST)

Please don't do weird-ass shit like this in templates. Listings are supposed to be short, sweet and cover one thing at a time: now you're covering what appears to be two apartments and a horseriding service in the same one!? And the hardcoded BRs, Us etc may not render well if the listing is printed, displayed on a PDA, etc. (WT-en) Jpatokal 06:13, 21 January 2007 (EST)

Is there a policy about using a lot of the internal links like Eger#Matyus_Udvar_Haz? I've been meaning to ask that lately anyway... I'm not sure they're usually all that necessary, and especially to a specific hotel or listing, I can't think of a scenario where that would really be needed... Project:Internal_links is pretty sparse at the moment... (WT-en) ::: Cacahuate 02:54, 21 January 2007 (EST)

HTML in listings is probably just a bad idea, as the articles should be editable by anyone, not just those with html skills; same goes for html in articles, except for a small number of exceptions where I think html is useful or even require; African_flora_and_fauna would not look to good without the tags.

Internal links can also sometimes be very useful, Air_travel_in_South_Africa#OR_Tambo_International from South_Africa#By_plane is one example where I think it is better to use an internal link rather than linking to the main page. Linking to a specific hotel does however seem rather silly. (WT-en) NJR_ZA 06:33, 21 January 2007 (EST)

I have just finished editing information on Senator-Haz which evoked this discussion. I managed to make it without and tags. However I have something to say on the rest of above comments.

I used tag merely to make an anchor that I needed for reason. Do we have a better way to put an anchor we can link to? Can I create an {{anchor|name}} template to allow contributors to make a tag without knowing HTML (or forcing future editors of their contribution to know it)? The reason I need to put an anchor on a specific hotel (to repeat what I wrote above) is the following. When I describe my completed journey to friends in my blog, I only list hotels, restaurants and places I tried (and not/recommend). However, for detail on every item I list there, I link to review on it at Wikivoyage--thus driving more readers to Wikivoyage, and possibly converting some of them to contributors of Wikivoyage--at least encouraging future readers to update what I've found. Isn't this a sufficient reason for allowing to attach anchors to specific hotels? Please keep in mind that Wikivoyage is not totally isolated from other Internet tools like blogs, but rather exist in a context; understanding how Wikivoyage is used can help us to make it better.
I mentioned in the earlier comment that Patria Panzio is a part of Senator Ház hotel. Now it's also clear from the listing itself. (WT-en) Jpatokal, do you have any suggestions on improving this aspect of Senator Haz listing?
As the listing read, Senator Haz hotel recommends taking horseriding with Mátyus Udvar Ház horsebackriding facility (and even its site mentions it can help with arranging horseriding). But in reality we had to arrange ourselves, with no substantial help from Senator before we arrived. (WT-en) Jpatokal, any suggestions on how this idea can be expressed in this listing item for Senator Haz?
(WT-en) Maj, does it look good overall now?

--(WT-en) DenisYurkin 15:27, 21 January 2007 (EST)

The <sleep> tag, like other listing tags, creates a span with an "id" attribute that you can use for the anchor. It's a munged-up version of the name of the establishment, with underscores for spaces. So, Montreal#Bily_Kun should work. I mostly did this so we'd have URLs to use in RDF statements, but it could work for making links if you're in a real hurry. --(WT-en) Evan 19:40, 21 January 2007 (EST)

Evan, thanks for pointing this. I just looked at the page source and found that all accented letters are removed rather than converted to their non-accented ascii counterparts--so Mátyus Udvar Ház has ID Mtyus_Udvar_Hz. Beyond link readibility, converting them so will protect from broken links when someone finds that a name recorded as non-accented (Patria Panzio) should have accents in it (Pátria Panzió)--I'd be happy if this change keep the old link working. Should I file this as a technical request? --(WT-en) DenisYurkin 00:38, 22 January 2007 (EST)

Again on cutting out accented letters from names: what if we add one more field in all listings, anchor name? This way we could (a) manually convert it to browser-readable, (b) preserve them unchanged even when attraction name change, so that old links still work. What do you think? --(WT-en) DenisYurkin 17:16, 29 January 2007 (EST)

I still don't understand why we would want to have a listing that includes what the listed business recommends.... that seems way outside of our goals. And it looks like there are other ways to achieve the anchor tag functionality you're after too, so I'd rather you reverted the listings you've done. In the future, it would be better to address the functionality you're after on the appropriate discussion page so the best technical solution can be determined, rather than starting out on your own. We're after consistency and consensus across all the guides. Thanks. (WT-en) Maj 20:29, 21 January 2007 (EST)

As for "why we would want to have a listing that includes what the listed business recommends": I can't find good arguments right now, so I changed this piece to the following:

Website says horseriding at Mátyus Udvar Ház can be arranged, but don't expect mech help from Senator--you'll need to contact them directly

Does it look better now? --(WT-en) DenisYurkin 17:35, 22 January 2007 (EST)

I'm with Evan here. Denis, regarding your specific questions, a) travelers don't really care who owns a place to stay, so Patria Panzio and Senator Haz should have separate listings, and b) if you're going to go horse-riding, isn't the default that you have to make your bookings yourself? It might be worth a mention if, say, the pension is right next to the racing track and offers packages or whatever, but it seems non-sensical to say that they can't! (WT-en) Jpatokal 21:54, 21 January 2007 (EST)

As for a): beyond owners, Patria Panzio and Senator Haz shares the same staff, reception, breakfast area and most likely, the way business is done. It's easier to consider them as 2 buildings of the same hotel, each with its own name and yes, having some differences in construction and rooms--but sharing much the same. One of the reasons I combine them is to encourage common characteristics to be placed in common part, while building-specific to go into a respective bullet. What's wrong with using approach like this? --(WT-en) DenisYurkin 00:55, 22 January 2007 (EST)

prefix for hotels, restaurants etc

I would propose to have prefix field for items like sleep, drink and eat. As long as we typically sort listings by name, it would be better to have prefixes like Pension, Hotel, Bar, Cafe to appear non-bold, so it doesn't confuse future editors on whether the item should be placed basing on prefix, or on its proper name (even if you and me know that proper name should be used). I don't think it's that important for suffixes as they don't affect sort order, however. What do you think? --(WT-en) DenisYurkin 06:09, 10 February 2007 (EST)

Actually, a better way to handle this would be to create sitewide naming policy to just use eg. "Hilton" in the Singapore article, instead of "Hotel Hilton Singapore". (WT-en) Jpatokal 07:25, 10 February 2007 (EST)

In regions with many small accomodations with similar names, it may be not enough. I can easily expect that all the following venues can exist in Istanbul, for example:

Hotel Sultanahmet
Pension Sultanahmet
Hostel Sultanahmet

Even more risk for Drink: John's Pub, John's Cafe, John's Club can be all different places in the same town. --(WT-en) DenisYurkin 07:35, 10 February 2007 (EST)

bug in hCard microformat

I have just noticed that the (templated) hCards on Birmingham (England) are marked up with . This should be  (with just a singular "d"). (WT-en) Andy Mabbett 07:14, 7 March 2007 (EST)

Got it. That's fixed, now. --(WT-en) Evan 14:18, 22 March 2007 (EDT)

Indeed it is. Thank you. (WT-en) Andy Mabbett 08:25, 26 March 2007 (EDT)

Form-based editing of listings

→ wts:WtTech:Form-based editing of listings

<drink> tags

Archived from the Pub:

Is this still an experimental feature? I notice it's used in some places (in particular, the Montreal page). The thing is, the external links are unpacked, which I know is not the intent of the Project:External links policy. I can't do anything abou this as long as the link is inside the <drink> tag. Will the display change as the feature develops? --(WT-en) Dawnview 06:33, 26 September 2006 (EDT)

Yes, it's a known bug, see wts:WtTech:Url field of listings should be autonumber or word. --(WT-en) Evan 08:16, 26 September 2006 (EDT)

I personally think it looks a lot better that way. It's a lot more useful if you have to print out the guide and take it with you, too. I still don't get the policy about packed external links (that is, why it is the way it is). (WT-en) Jordanmills 10:51, 26 September 2006 (EDT)

Good point. My thinking (from somone who never prints out the Wikivoyage pages) is that if you can get to an internet cafe to visit some website, you can just as easily get to Wikivoyage and click on the link, right? That's what I always do. I should try printing out a guide article though, I'd probably miss less. Though I think the idea of the policy is that you should be able to print out a guide and never have to look stuff up on the internet. --(WT-en) Dawnview 14:41, 26 September 2006 (EDT)

The problem with assuming that people can follow the links from Wikivoyage is that there's no guarantee that the printed version will be the same as the online version, and so no guarantee that the link will be accessible without trawling through the history. --(WT-en) Paul. 13:18, 1 October 2006 (EDT)

MediaWiki Templates

Archived from the Pub:

I posted this on the MediaWiki_talk:Sleep page but I figured I'd post here and get more coverage. I'm running into issues where lots of hotels have both local and toll free numbers. I would guess that it's most useful to the traveler to list the toll free, but it would be better to list both. Especially since (at least in the USA) toll free number holders have the option to prevent calls from the local area to reduce charges. (WT-en) Jordanmills 14:11, 30 December 2006 (EST)

Never mind, I just found the tollfree property. (WT-en) Jordanmills 14:17, 30 December 2006 (EST)

Translated item name

Swept in from the pub

In <see, do, eat, etc. > tags, use an alt="" attribute to display a translation of the item name into the local language when appropriate and helpful to travelers. This will appear normal weight, italicized and within parentheses after the bold text item name. Example: see Harbin page.

Can we please include alt="" after the name="" attribute in the click-to-insert snippets of the edit page? Something like this:

* <see name="" alt="" address="" phone="" email="" fax="" hours="" price="" url=""></see>

Maybe add a note on the edit page bellow or above the click-to-insert snippets explaining what the alt="" attribute will do and also linking to a page about the click-to-insert snippets (or whatever we call them). And what is the something-extra="" attribute for? --(WT-en) Rogerhc 19:20, 11 June 2007 (EDT)

I'm still mulling this over, but I thought I would add that it is a bad idea to render foreign names by default in italics because this can cause problems across alphabets. Cyrillic fonts, in particular, use very different characters in italics, which would make italicized Russian place names, for example, useless to anyone who doesn't speak Russian. But I definitely agree with your basic premise—that listings should give local names, especially when the local signs are in a different alphabet. --(WT-en) Peterfitzgerald ^Talk 19:28, 11 June 2007 (EDT)

Actually, the alt tag is already implemented so that only Latin scripts (Unicode Ux0000-02FF, or at least that's what I asked Evan to do) are italicized and the rest are left as is. Test:

As you can see, only the Latin word is italicized. (WT-en) Jpatokal 23:36, 11 June 2007 (EDT)

There's also a directions="" tag that can go after "address"... should we consider adding "alt" and "directions" to the template? or is that getting confusing for new editors? – (WT-en) cacahuate ^talk 01:15, 12 June 2007 (EDT)

Wow, there's a directions="" tag? I never knew that. That would be very usefulj I could have used it at least twice yesterday. And alt="" is a must for attractions with names not in Latin script. It definitely should be documented better. I see your point about it being confusing for new editors though. (WT-en) JimDeLaHunt 13:48, 12 June 2007 (EDT)

I've added the alt and directions tags to the edit tools. (WT-en) Jpatokal 23:30, 13 June 2007 (EDT)

I'm loving the directions tag. (WT-en) Gorilla Jones 23:52, 13 June 2007 (EDT)

{{no source}} and {{no license}}

I can't seem to use the {{no source}} and {{no license}] templates for images. These are pretty essential template for a wiki site. Are they called something different in Wikivoyage? (WT-en) OoishiMoe 02:07, 4 June 2007 (EDT)

Yes: {{dont know}} works for something that was uploaded without a license selected – (WT-en) cacahuate ^talk 00:00, 12 July 2007 (EDT)

web/email format

Per a conversation started in the pub, is it agreeable to think about getting rid of the [1] type of listing of websites, and do something more visually pleasing/obvious such as [web] and [email] ?? Jani suggested this should be done in MediaWiki as opposed to any user-initiated change. – (WT-en) cacahuate ^talk 00:00, 12 July 2007 (EDT)

copied in from the pub:

I'd like that, too. The escalating number-links are odd. (WT-en) Gorilla Jones 00:25, 12 July 2007 (EDT)

Another vote for [web] from me for listings; not sure it will fit links placed in the middle of regular text, though. --(WT-en) DenisYurkin 01:56, 12 July 2007 (EDT)

I would actually lean more towards using icons, if we do this. A flying envelope icon for mail is straightforward, although I admit I don't have a weblink icon in mind. --(WT-en) Peter ^Talk 02:04, 12 July 2007 (EDT)

I second the idea of using just an icon. What's wrong with the icon we already have that appears next to the number? (WT-en) Texugo 02:47, 12 July 2007 (EDT)

Absolutely nothing, I think that could work great. Should we move our discussion to Wikivoyage_talk:Listings#web/email_format? --(WT-en) Peter ^Talk 17:26, 12 July 2007 (EDT)

I wouldn't mind an icon either, but the current web one is sorta fugly. Surely someone can come up with something more obvious and beautiful. I think the email one is fine. I'd rather condense it to just that than spell out the entire email address as we've been doing... anyone disagree about that? – (WT-en) cacahuate ^talk 04:01, 13 July 2007 (EDT)

I'd vote for "web" plus the icon, which is clear, reasonably pretty and doesn't take up too much space. E-mail should be the same, just "email" and the letter icon. This is also in line with how the listings show telephone numbers. (WT-en) Jpatokal 04:24, 13 July 2007 (EDT)

I'd love to change this, as keeping the escalating number links in order is a significant pain in my keester. However, I'd really love to see front-linked listings (the name of the listing is the text of the link). Let me note that it's pretty easy for me to change this format for listings that use the listings tags; just a few hours of work. --(WT-en) Evan 14:47, 17 July 2007 (EDT)

Wouldn't the [web] idea be easier for you and me? It means we have talk about changing the Manual of Style, before we use front linked listings. On top of that, we would need to fix 14,000+/15,000+ articles because then the non-coded listings articles would not conform to MoS. -- (WT-en) Sapphire • (Talk) • 16:11, 17 July 2007 (EDT)

Arrrrrrgh! (WT-en) OldPine 16:38, 17 July 2007 (EDT)

I wouldn't be opposed to front linking, we already can do it in the body of the text, so the only MoS change is within listings. If Evan is willing to do the work to set up the tags to do that, then we don't need to spend time changing the linking style... we would just continue to do what we're already doing, which is slowly converting old style listings to the new listings tags, and the type of linking would happen automatically. So then, I think we should just discuss what we like more visually... I'd be okay with [web] or front-linking. – (WT-en) cacahuate ^talk 19:21, 17 July 2007 (EDT)

I hate frontlinking, partly because I have spent painful hours reformatting it, and partly because the MoS led me to believe it was evil(tm) and should never be done in listings. I really feel it glorifies a lack of information by "lighting up" the name text. It also de-emphasizes nearby listings simply because they either have no web site or haven't had one contributed. May I ask how we are gradually converting listings to tagged? Before I burned out and took a break there was an auto-conversion someone wrote up. That was no go? </rant> (WT-en) OldPine 19:28, 17 July 2007 (EDT)

well, lately we've just been doing it by hand. But a bot of some sort would be fairly orgasmic – (WT-en) cacahuate ^talk 01:46, 18 July 2007 (EDT)

I'd like to revive the icon idea. I agree with OldPine that frontlinking encourages contributors to leave entries as is because it so clearly points to information off our guides. I would actually oppose the [web] idea for the same reason; moreover, I would find the extra text links obtrusive—a step in the wrong direction from the "footnote" style links. The only problem I see with just using the current external link icon is that its not obvious. My two possible solutions: 1. Don't care, we want potential editors to stay here and improve our guides rather than leave for another source; 2. Come up with a more obvious icon. But when all is said and done, this is just my preference and my issues with the other formats are trivial, if others disagree I'll be glad to go along with whichever option is most popular. --(WT-en) Peter ^Talk 20:04, 17 July 2007 (EDT)

I hate front-linking too, for exactly the reasons OldPine mentioned. For an example, I think that an Eat section where half the titles are blue and the other half are black is not only ugly, but also the restaurants which happen to have a website really get an unfairly advantageous emphasis, even though many restaurants don't have or even need a website. Also, listings which happen to have longer names tend to stand out much more than those with short names so that Billy Joe Bob's Wild West Steakhouse and Saloon looks a lot more important than a place called JB's. I'm fully in favor of the icon idea, and I don't really even care what the icon looks like. Even the icon we have would be better than repeating a bit of text 50 times in every article. (WT-en) Texugo 21:52, 17 July 2007 (EDT)

If we're using listing tags, we can have front-linked listings that don't have bright-blue text. They can have whatever color we want; they can just be bold text, and show an underline when you roll the mouse over them. Or they could have an underline all the time, or be a slightly different color from non-linked listings. They also don't have to have the little external-link image doohickey. --(WT-en) Evan 12:59, 18 July 2007 (EDT)

Had a feeling people wouldn't like that idea! What about @ and (without the [12])? Or what if Todd/Ryan/Nick/someone made up some beautiful options for icons? – (WT-en) cacahuate ^talk 01:42, 18 July 2007 (EDT)

If there's maybe some way to make the front-linked listings less obvious then I wouldn't mind them anymore. Howabout we make all listing names bold except the ones with URLs, so we wind up sort of pushing the ones that rely on external links into the background? -- (WT-en) Mark

Wow, I was being really dense above, and just realized my mistake... when Evan suggested front-linking I was thinking along the lines of:

Bob's Taco Shop, 123 South St, +1 555 555 5555, bobs.com. A sweet-ass taco shop.

not:

Bob's Taco Shop, 123 South St, +1 555 555 5555. A sweet-ass taco shop.

I get it now... I do kinda lean against front-linked listings like that then. If we do start to use them front-linked like that, I don't see a huge amount of difference between bold and non-bold. Examples:

Bob's Taco Shop, 123 South St, +1 555 555 5555, www.bobs.com. A sweet-ass taco shop.
Bob's Taco Shop, 123 South St, +1 555 555 5555. A sweet-ass taco shop.
Bob's Taco Shop, 123 South St, +1 555 555 5555. A sweet-ass taco shop.

Hmmm. – (WT-en) cacahuate ^talk 11:44, 18 July 2007 (EDT)

Let's not start beating this dead horse again -- this has been discussed ad nauseam and front-linked listings are still doubleplusungood. (WT-en) Jpatokal 11:48, 18 July 2007 (EDT)

Front-linked listings are like a cut in chocolate rations. I agree with OldPine's rationale, and like [web] well enough. (WT-en) Gorilla Jones 12:25, 18 July 2007 (EDT)

Strange, Jani, I thought you were in favour of front-linked listings.

Also, let's not do any conversion of old-style hand-built listings to a different format. Once we're using listing tags, if we decide to change output formats, it's a couple of hours of work for me, and all the listings are changed.

I'm not married to front-linked listings, but I thought they were kind of popular. We actually reached a consensus on them in the past, and backed it out because they looked bad when printed. If we're using listing tags, we can control how they look when printed. --(WT-en) Evan 12:54, 18 July 2007 (EDT)

While I might be new to wikivoyage, I have been with another wiki for a number years. I am not sure if this proposal has been decided yet, but since I had brought this subject up again, on the other page, may I offer my suggestion.

I disagree with having a web site listed, because the web site will be viewed with a click on the link itself. The least amount of words, IMHO would be the best, and this is what I had started to do, when I was notified that this conversation was going on.

Instead of using a name, I suggest that the type of food served there, should be seen. After all, when traveling, we get an appetite for a type of food first, and then search the location.

This link might work as neat, short, and helpfulTaco's It would not take that much more work, and would really be more helpful . Revealing the name of the restaurant, and not necessary, as it will show, once the type of food is decided on.

(WT-en) Flowergirl 11:25, 2 August 2007 (EDT)

Everyone, please please remember that using front-linking requires we change 15844 articles to conform with a change in our front-linking policy. -- (WT-en) Sapphire • (Talk) • 12:38, 2 August 2007 (EDT)

Names don't appear

I have not tried adding these tags to a page, but when I view some pages that use them, the names don't appear. I checked and they're in the source, but not in the HTML. Here's an example from Galveston:

*<see name="Moody Gardens" address="One Hope Boulevard" directions="off 81st St." phone="800-582-4673" fax="" email="" url="http://www.moodygardens.com" hours="" price="$39.95 day pass"></see>

<ul><li><span class="vcard"><span class="adr"><span class="street-address">One Hope Boulevard</span></span> (<span class="note">off 81st St.</span>), <span class="tel"><abbr class="type" title="voice">☎</abbr> <span class="value">800-582-4673</span></span>, <a class="url external autonumber" href="http://www.moodygardens.com">[3]</a>.  <span class="price">$39.95 day pass</span>. </span></li></ul>

(WT-en) Humane Earth 15:28, 23 August 2007 (EDT)

Yeah, seems to be a funky bug... I fixed the Galveston page by clearing its cache, but this shouldn't be happening, so I filed a bug report – (WT-en) cacahuate ^talk 23:12, 23 August 2007 (EDT)

Translation section

The listings tags do not work when translated into Russian (see ru:Участник:(WT-ru) Peterfitzgerald/Listings for an example). I presume that this is not a problem specific to Russian. Perhaps the translated tags do not work in non-Latin alphabets, in which case we should note that. Or perhaps they simply do not work at all in translation, in which we should replace the content of this section with a notice that the tags do not work in other language versions for the time being. --(WT-en) Peter ^Talk 16:58, 5 September 2007 (EDT)

still experimental?

Aren't we ready yet to remove the "still experimental" banner from this article? --(WT-en) DenisYurkin 17:10, 20 October 2007 (EDT)

I think the elusive new form-based listings editor should hopefully be rolled out before too long, which will make them irrelevant. I think it's ok to add new listings using the tags, but I asked Evan if we should still be converted the old style ones to these and he said not to bother, if I recall. – (WT-en) cacahuate ^talk 17:24, 20 October 2007 (EDT)

Speaking of which, I put the first version of the listing editor up on review today. There should be edit links next to all of the listings that allow you to edit via an in page form. If the links don't show, try saving the page to update the cache. It currently doesn't handle adding items (something we'd like to do), but you can add a stub listing <see name="my attraction"> and then edit that without having to mess with all of the tags. (WT-en) KevinSours 16:59, 2 November 2007 (EDT)

Looking good! Three things jump out at me at first glance:

Lack of a "description" box
It's not possible to edit listings on an "out of date" page that have since been deleted
Editor box can sometimes cover up important information while editing—would it be possible to make it float, and to enable a click-and-drag functionality to move it around while editing?

I'm really looking forward to having this listings editor completed! Also, is there a better place to discuss the draft version? --(WT-en) Peter ^Talk 18:41, 2 November 2007 (EDT)

→ wts:WtTech:Form-based editing of listings – let's continue there so all language versions can participate... I'm glad we're moving forward on this! – (WT-en) cacahuate ^talk 19:38, 2 November 2007 (EDT)

As far as I understand, this is definitely no longer experimental. Moreover, the listings editor will only work for listings that use the tags. I think we should encourage people to either a) convert listings to the tags, or b) create a bot that would do this without human help. Any objections to removing the disclaimerbox & the exhortation to not convert to listings tags? --(WT-en) Peter ^Talk 16:12, 11 April 2008 (EDT)

Agreed, no longer experimental, OK to convert. (WT-en) JimDeLaHunt 00:15, 12 April 2008 (EDT)

section anchor is overridden by listing anchor

When article contains both listing item and a section with the same name, section anchor is overridden by the listing--see London#Eat. --(WT-en) DenisYurkin 07:16, 2 February 2008 (EST)

Listings' telephone icon

Swept in from the pub:

Huh? It's gone? Instead of the familiar old telephone icon, today I only see a question mark. But I'm using the same browser (Firefox 2), same computer, same glasses, etc. It's not happening in Internet Explorer, though. Anyone else experiencing this? --(WT-en) Peter ^Talk 17:14, 16 April 2008 (EDT)

Yep, but in my case it was after I migrated to Mac (Using Firefox, which worked when I was on a Win/XP OS). Safari still has it, though. -- (WT-en) Sapphire • (Talk) • 18:35, 16 April 2008 (EDT)

Formatting question

Swept in from the pub:

I have seen several conflicting formatting choices for the "See", "Do", and other sections of articles and I am curious to know which is correct. This is in reference to Nashville. Thanks for the help! --(WT-en) Matt ^Talk 12:06, 24 August 2008 (EDT)

Formatted using the <do> tag like this:

* <do name = "Bluebird Cafe" address = "4104 Hillsboro Pike" directions = "" phone = "615-383-1461" email= "" fax = "" url = "http://www.bluebirdcafe.com/" hours = "" price="">With its unlikely location in a strip mall in Green Hills, has long been the destination of choice for local and national songwriters, fans of songwriters, and label scouts. Expect schmoozing, sets in-the-round, and lines around the block. Keep in mind, though, that quiet is requested at all times during a performance. </do>

<do name = "Bluebird Cafe" address = "4104 Hillsboro Pike" directions = "" phone = "615-383-1461" email= "" fax = "" url = "http://www.bluebirdcafe.com/" hours = "" price="">With its unlikely location in a strip mall in Green Hills, has long been the destination of choice for local and national songwriters, fans of songwriters, and label scouts. Expect schmoozing, sets in-the-round, and lines around the block. Keep in mind, though, that quiet is requested at all times during a performance. </do>

Or formatted using general wikivoyage formatting, like this:

* '''Belle Meade Plantation''', 5025 Harding Road, ''+1 615'' 356 0501 (''group sales: 1-800-270-3991''), [http://www.bellemeadeplantation.com/]. Tours by costumed guides available M-Sa 9:30AM-4PM, Su 11:30AM-4PM. Featuring the mansion built in 1853 and restored restored, as well as the carriage house from 1890 and one of the oldest log cabins in Tennessee, built in 1790. There is a great deal of history associated with the plantation starting from before the American Civil War. Adult $11, Seniors $10, Children 6-12 $5, Children under 6, Free.

Belle Meade Plantation, 5025 Harding Road, +1 615 356 0501 (group sales: 1-800-270-3991), . Tours by costumed guides available M-Sa 9:30AM-4PM, Su 11:30AM-4PM. Featuring the mansion built in 1853 and restored restored, as well as the carriage house from 1890 and one of the oldest log cabins in Tennessee, built in 1790. There is a great deal of history associated with the plantation starting from before the American Civil War. Adult $11, Seniors $10, Children 6-12 $5, Children under 6, Free.

You should use the do tag format. See Project:Listings for details. (WT-en) Jpatokal 12:14, 24 August 2008 (EDT)

Even despite "This feature is still experimental..."? --(WT-en) Matt ^Talk 14:21, 24 August 2008 (EDT)

We should remove that disclaimer—it's no longer experimental; it's standard. --(WT-en) Peter ^Talk 15:48, 24 August 2008 (EDT)

Got it. Thanks guys. I removed the disclaimer from Project:Listings--(WT-en) Matt ^Talk 15:54, 24 August 2008 (EDT)

It may be standard, but it still has problems. I'm not sure why we use an XML-style tag instead of a MediaWiki template; the latter seems more flexible and wiki-like, though I suppose there may be some performance problems. I've also had problems formatting the data in the Listings tags -- primarily, I can't get the country code and area code to be italicized in the phone number field. (WT-en) LtPowers 19:19, 24 August 2008 (EDT)

I agree with (WT-en) LtPowers, not long ago i reported on shared about this impossibilities. -- (WT-en) Sergey kudryavtsev 02:17, 25 August 2008 (EDT)

Listings using "Do" and "See" tags etc

Is it me or is there something a bit off with the "price" section when using the tag listings format? I just noticed recently that when using this format for listings, it doesn't automatically put a space in between the description of the listing and its price info right at the end. It seems to put a space in between all the other bits like "phone" "email" "hours" etc. It kind of makes the end of the listing look cramped...especially if you do not end it with a period but a tall character like ! or ?. example:

<eat name="Solstice Restaurant and Lounge" alt="" address="2801 California St" directions="at Divisadero St" phone="+1 415 359-1222" email "info@solsticelounge.com" fax="+1 415 359-1242" url="http://www.solsticelounge.com/" hours="5PM-midnight daily" price="$8-$17">Modern well decorated restaurant and lounge that serves up tasty, yet affordable treats, like "gorgonzola mac-n-cheese" and "tempura battered fish tacos." It gets very packed in the evenings...a good sign!</eat>

(WT-en) Asterix 16:54, 31 August 2008 (EDT)

That's definitely happening, and I don't think it was that way before. I let the tech team know. --(WT-en) Peter ^Talk 23:53, 31 August 2008 (EDT)

Wikilinks in listings?

Archived from the Pub:

Hi, would it be possible to implement the ability to have wiki links inside of listing tags in any of the fields? This would really help to make a proper listing out of a location when the location has an own article and one just wants to outline it's there and why the travellers should go see it. --(WT-en) FreakRob 05:29, 8 December 2008 (EST)

Uhh, that's not what listings are for, really. Can you give an example? Why not just use a plain old paragraph? (WT-en) Jpatokal 05:49, 8 December 2008 (EST)

I'm guessing he's looking for something like: <see name="[[Walt Disney World Resort]]"></see>. The other fields in the see tag could be useful and would allow the listing for WDW to look the same as the listings for the other attractions in the list. (WT-en) LtPowers 10:29, 8 December 2008 (EST)

Implementation on other wikis

I am interested in implementing almost exactly the same thing on a gardening wiki ( http://www.plants.am ) so that I can add listings of species onto a genus page, with growing zones, watering needs, etc. Can someone please point out a resource to help me figure out how to get it onto there with the nice little "add listing" link and form?? Thanks! (WT-en) Raffikojian 13:04, 24 November 2008 (EST)

Kevin might be able to help you find this information. --(WT-en) Peter ^Talk 16:47, 24 November 2008 (EST)

I'm after the same thing. It might be useful and helpful to others if this implementation i.e. the javascript and the inputboxes was explained so others could use it on different wikis --rfahey 18:03, 13 May 2009 (EDT)

Kevin is not likely following this page. I recommend contacting him via email. --(WT-en) Peter ^Talk 21:31, 13 May 2009 (EDT)

Thanks a lot, I'll do that. Regards, Richard Fahey --212.167.5.6 07:40, 14 May 2009 (EDT)

Yes, thanks very much, I'll try that now as well. (WT-en) Raffikojian 09:05, 8 June 2009 (EDT)

Mailto:

Latest comment: 10 years ago1 comment1 person in discussion

Swept from pub:

Is there a policy about inserting mailto: tags into listings? It's done fairly often, but I think the policy should be not to use them, because it 1) adds to the impression that Wikivoyage is primarily to be used as a web site rather than as printouts, 2) it's not in the template, 3) it looks ugly printed out, 4) such links are formatted inconsistently (e.g. sometimes you see the word "email:" used with the tag, sometimes not), and 5) most people who want to email are going to go to the hotel's web site anyway, where they usually will find a mailto: tag or contact box. Simply having a policy not to use the tags would simplify everything. (WT-en) Sailsetter 19:22, 8 January 2009 (EST)

E-mail addresses appear to be made into mailto: links automatically by the listings tags, as in below:

<listing name="Sample" email="not.an.address@nowhere.com" />

Seems like a useful feature to me that doesn't take up that much room. -- (WT-en) LtPowers 20:08, 8 January 2009 (EST)

(WT-en) Sailsetter, You make a big assumption that everyone can be contacted via a contact page using their website. What if their web page contact page is not working, or they don't have one? Sure the big hotels have one, but what about the little bed and breakfast places who have a single web page/advert or those strange businesses that have an e-mail address but no website, yet? Also, in many places you can send an internet e-mail for free, but website access costs money. Having the e-mail address is a definite plus. While not using the e-mail tags would siplify things for the editors, it would make things harder for the traveller. A prime directive of Wikivoyage is The traveller comes first. Therefore, e-mail addresses should be listed, where they are available to be used. The need is to develop a policy that makes the presentation consistent. The above suggestion by (WT-en) LtPowers seems like a good way to do things to me. -- (WT-en) Huttite 03:02, 17 January 2009 (EST)

Just to be clear, it's not a suggestion; it's the way Wikivoyage works right now if you use the "email" field for listings. (WT-en) LtPowers 10:18, 17 January 2009 (EST)

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! Anyway, if people are going to use mailto: in Wikivoyage, I think they should at least do it right. Put mailto: in the Wikivoyage search box to see how ugly it can get. (WT-en) Sailsetter 10:51, 17 January 2009 (EST)

I guess I don't understand your complaint, then. The links are not hidden but are clearly e-mail addresses; anyone clicking on one should know what's going to happen. They should be formatted consistently as long as the listing tags are used correctly. And I have no idea what you mean by "It's not in the template". (WT-en) LtPowers 16:29, 17 January 2009 (EST)

It's not my complaint that the addresses are hidden, and in fact I don't see anything in my above remarks that implies that. My complaint about the appearance is that the addresses often appear on the screen like this:

        email: mailto:gm@thecabogrill.com

This is obviously wrong: the email address in question is not mailto:gm@thecabogrill.com, it is gm@thecabogrill.com. What I mean by it's not in the template is that for instance the listing template for hotels (maybe template is the wrong Wikivoyage jargon for this, but that's what it really is)has an email input area reading

       email=""

There's no indication that your email address is going to be turned into a mailto: tag, which I think as one contributor is confusing. (WT-en) Sailsetter 12:01, 18 January 2009 (EST)

Well, there's no indication that the data entered into the URL field will be turned into a link, either, but I guess I don't see that as a problem. We, as Wikivoyage, want to show e-mail addresses if they're relevant, and there's no reason not to make them into a link if we're going to show them. As for the "email: mailto:" thing, can you show me an example? (WT-en) LtPowers 16:53, 18 January 2009 (EST)

I gave what I thought were several good reasons not to make them into a mailto: link, most especially that if I click on a URL link, I go to that link, everything ok, but if I click on a mailto: link and I don't want to use Outlook Express, my system goes bonkers. And as for the formatting, I gave an example eight lines above your request for an example, which I found by typing the string mailto: into the Wikivoyage search box, as I explained a dozen lines above that. (WT-en) Sailsetter 14:58, 19 January 2009 (EST)

Sorry, by "example" I was hoping you could point to a specific article. I thought your example was just something you typed in. Doing a search, as you suggested, I see that your example comes from a page that isn't even using the listing tags. Someone hardcoded that in the wikitext markup. There's nothing we can do about that except fix it when we find it -- I'm surprised you haven't fixed it yourself, yet.

As for problems with mailto: links, I still don't see the problem. If your system doesn't handle mailto: links well, then don't click on e-mail addresses. (WT-en) LtPowers 18:27, 19 January 2009 (EST)

Before the listings tags existed, we used to type everything out manually, and it was (and technically still is) part of the MoS to build email addresses using the mailto format (though you were supposed to hide the "mail to" text). Emails are still included now in the listings tags if you use the ones in the edit tools box when editing a page... but unfortunately when the "add listings" box was created the person(s) creating it thought they would keep things to a minimum and left some fields off, email being one of them... personally I think that should be changed. I'm in favor of keeping the mailto format however, those who don't like it know how to not click on it, but those of us who do use outlook, etc, appreciate not having to copy-paste – (WT-en) cacahuate ^talk 19:38, 19 January 2009 (EST)

I'd say we should obviously insert mailto: tags for email addresses just as we use http: in web URLs. it is part of the defined format and browsers or smartphones know how to use it.

The problem of using the wrong application (Outlook on some systems, Thunderbird on mine) for mailto: tags is easily fixed. On my firefox, the menu sequence is edit-> preferences-> applications-> mailto. Not trivial, but hardly rocket science either. Pashley (talk) 01:22, 8 February 2014 (UTC)Reply

"add listing" issue

Not entirely sure if this is the place to talk about the "add listing" button, but it seems close enough...

As anyone who keeps a close eye on a huge city article knows, often an unexperienced member will add a restaurant, hotel, or some sort of listing to the main city article instead of to the district article, where it belongs. This is nothing new; there has always been confusion surrounding district articles. But then it hit me: we have those "add listing" buttons right on every article on the site, including the ones you're not supposed to add listings to (huge city articles, major regional articles, country articles, etc)!

I'm sure a lot of complex programming went into putting that little feature in, but would it be possible to add something where someone (say, admins) could remove it from articles that shouldn't have it? It just seems silly to have a button in places where no one is actually allowed to use it.

Obviously I'm not a programmer, so if what I'm asking is totally unreasonable or would just be way more trouble than it's worth, then just forget it. It's not like we're dealing with a dire matter here or anything. It's just a thought. (WT-en) PerryPlanet ^Talk 04:16, 12 January 2009 (EST)

I've seen this issue quite frequently with Chicago as well, and am also reliant upon the efforts of other for help on the programming end. (WT-en) Gorilla Jones 07:22, 12 January 2009 (EST)

It might be possible to create some sort of {{nolisting}} template, but looking at the CSS for the tags there aren't any IDs or other means that would make it easy to do. If IB could modify the code slightly so that all "add listing" links were surrounded in something like ... then we could put something together that would suppress them from appearing. Might be a good candidate for a tech request. -- (WT-en) Ryan • (talk) • 04:28, 12 January 2009 (EST)

It was mentioned briefly at wts:WtTech:"add listing" link occurence improvements, I'm noting it again there now – (WT-en) cacahuate ^talk 10:11, 12 January 2009 (EST)

Email addresses

Email is one of those fields that I wish we had left off the listings editor—so it would be used only when it's really appropriate (similar to how I feel about the directions field). It could be that I'm missing out on something, but as a traveler, I've never emailed any museum, restaurant, shop, cafe, pub, etc. The only type of listing for which I think anyone might really use the email field would be hotels, right? Even then I would just book online or call, but I've at least heard of travelers using email in this fashion (same goes for faxing).

I find emails in listings doubly unhelpful because they waste space and distract the eye from the other more important details (as we discussed above on this page). I realize that could be fixed by simply altering the listing editor to display a mail icon instead of the full email address, and that we should tailor format to content, not the other way around. But unfortunately, we don't have the tech support/access to fix these types of formatting issues.

So here's my question, when and why should we use the email field? --(WT-en) Peter ^Talk 14:14, 2 February 2010 (EST)

I'd almost go so far as to say that e-mail is only useful if the listing doesn't have a web site (there are a few). For listings that have web sites, contact information is readily available. The only disadvantage is that sometimes you can send an e-mail without having access to a web browser, like an SMS interface from your mobile phone. (WT-en) LtPowers 14:59, 2 February 2010 (EST)

For hotels, email should be kept at least when there is no website. Another case is a restaurant that is very popular but accepts reservations--or attraction (like Dali museum in Figueres) which allows reservation by email. And you are absolutely right that addresses should be collapsed on web, although it won't help in a printed guide. --(WT-en) DenisYurkin 15:43, 2 February 2010 (EST)

Hard to disagree with any of that. As the display is so ugly, some editors have stopped including them anyway. Interestingly, if you hit the "add listing" link from within an article, there is no email field in the pop-up.. It is the template from the edit screen that is the problem.--(WT-en) Burmesedays 21:23, 2 February 2010 (EST)

Translate listings

1. Tried to search around for this, but didn't find an answer. What is the preferred way to list listings that has a translatable, i.e. the Drama theatre in Komsomolsk, when a "foreign" alphabet is used?

<do name="Drama Theatre" alt="Драматический театр" address="" directions="" phone="" email="" fax="" url="" hours="" price=""></do>
<do name="Dramaticheskij Theatre" alt="Драматический театр" address="" directions="" phone="" email="" fax="" url="" hours="" price=""></do>
<do name="Drama Theatre" alt="Драматический театр, Dramaticheskij Theatre" address="" directions="" phone="" email="" fax="" url="" hours="" price=""></do>

The first one might seem like the most obvious, but if you don't have 1337 Cyrillic/Kanji/Arabic skills, it might not be obvious how to ask for directions. The 2nd one has the disadvantage of loosing clarity (maybe not in this example, but definitively in others), and the third one can get really long as evidenced by this other listing in Komsomolsk

<see name="City Museum" alt="Museum of Local lore) Городской краеведческий музей города Комсомольск-на-Амуре, Gorodskoj kraevedcheskij muzej goroda Komsomol'sk-na-Amure" address="" directions="" phone="" email="" fax="" url="" hours="" price="">bla bla bla</see>

Comments or pointers to previous discussions? --(WT-en) Stefan (sertmann) ^talk 17:53, 3 February 2010 (EST)

Streetnames in listings

Another question I've had popping up while doing work with Russian cities, is the correct approach to a street name, should a listing on Lenina Street be listed as Ulica Lenina 7, Ul Lenina 7, Lenina St 7 or Lenina St (Улица Ленина) 7? again the last and most useful onem has the potential to make some quite long and potentially confusing pages

<see name="City Museum" alt="Museum of Local lore) Городской краеведческий музей города Комсомольск-на-Амуре, Gorodskoj kraevedcheskij muzej goroda Komsomol'sk-na-Amure" address="Komsomolskaya Prospekt (Комсомольский проспект) 7" directions="" phone="Phone number is 3 lines down on my PC" email="" fax="" url="" hours="" price=""></see>

Comments or pointers to previous discussions? --(WT-en) Stefan (sertmann) ^talk 17:53, 3 February 2010 (EST)

In general, and this applies to both questions: Words that aren't proper nouns should be in English, except where no English translation exists (e.g., "teppanyaki" or "gamelan"). Proper nouns should be in English if there is a common English version of the name; otherwise, the native name should be Romanized. But that's just my opinion; I'm not sure if there is an established consensus one way or another. (WT-en) LtPowers 19:58, 3 February 2010 (EST)

I've been using just the Russian for addresses, but that's probably improper. For Yakutsk#Eat, I figure someone using the guide would either know how to read the Cyrillic, or would be better off just printing this and showing the address to their taxi driver.

<eat name="Tygyn Darkhan" alt="Тыгын Дархан" address="ул. Аммосова, 9" directions="" phone="" email="" fax="" url="" hours="8AM-10AM, noon-3PM, 6PM-11PM daily" price="~1,000 rubles">This is the best place in Yakutia (and thus likely the world) to try Yakut national cuisine. Some iconic Yakut dishes to look out for include Oiogos (Ойогос) — baked foal ribs, Salamat (Саламат) porridge, and Indigirka (Индигирка) salad — made with frozen fish.</eat>

It would probably be better, though, to also include a transliterated address. For addresses, I don't think translated proper nouns would be very helpful, aside from very famous ones, which should be included in addition to the more useful transliteration. For example:

<eat name="Tygyn Darkhan" alt="Тыгын Дархан" address="ул. Аммосова, 9" directions="ulitsa Ammosova, 9" phone="" email="" fax="" url="" hours="8AM-10AM, noon-3PM, 6PM-11PM daily" price="~1,000 rubles">This is the best place in Yakutia (and thus likely the world) to try Yakut national cuisine. Some iconic Yakut dishes to look out for include Oiogos (Ойогос) — baked foal ribs, Salamat (Саламат) porridge, and Indigirka (Индигирка) salad — made with frozen fish.</eat>
<see name="Attraction X" address="თავისუფლების მოედანი (Freedom Square)" directions="tavisuplebis moedani" phone="+X XXXXX-XX" email="" fax="" url="" hours="8AM-10AM, noon-3PM, 6PM-11PM daily" price="~1,000 lari"></see>

Am I right in thinking the directions field would be best for transliterations (especially since it will be italicized)?

And I'm not aware of previous discussions on this topic. --(WT-en) Peter ^Talk 23:40, 3 February 2010 (EST)

Lat/Long in listings

swept from pub:

I've noticed recently quite a few listings gaining 'lat="" long="" ' attributes. Many times these are happening as an edit to a listing without any of the information being changed. Should listings now have these attributes, or are they being added randomly by someone who thinks they are helping and actually should be remvoed? (WT-en) Nrms 12:28, 22 February 2010 (EST)

The reason is because our nice little pop-up listing editor includes lat and long fields but the "click-to-insert" shortcut links that appear underneath the edit window do not. Currently, I believe that the lat and long fields are nonfunctional (but harmless), but they're there in anticipation of future functionality. (WT-en) LtPowers 16:40, 22 February 2010 (EST)

A third party user of our free data, may of course find a good use for them. --(WT-en) inas 16:59, 22 February 2010 (EST)

As far as I recall (WT-en) Rezendi's iTravelWrite iPhone app mashes them up with google maps or something like that, at least that was his intention in the early posts he did. --(WT-en) Stefan (sertmann) ^talk 17:06, 22 February 2010 (EST)

Ah. Just seemed a little strange that they sometimes end up as an addition to a listing when no other change is made to the page :) (WT-en) Nrms 08:03, 23 February 2010 (EST)

That baffled me for weeks as well, until I finally figured it out :). Strange little thing that popup editor; does this lat/long business but does not have an email address field!--(WT-en) Burmesedays 08:30, 23 February 2010 (EST)

Flags at the beginning of embassy/consulate listings

I'm not really sure if this is the right place to start this discussion, so please feel free to move it to somewhere more relevant if necessary.

I don't know if there has ever been a discussion on this but by (some unwritten, I guess) convention we add small national flags at the beginning of embassy/consulate listings, which is alright and in fact is nice to add colour to otherwise very boring lists.

Citizens of European Union seem to entitle to consular help from consulates of European Union countries other than their nation's (I am not sure if that's always possible or when a consulate/embassy of their nation does not exist in that city or country; maybe someone with more knowledge can clarify that). So to avoid edits like this popping up at cope sections of major cities all over the world, how about adding European Union flags in addition to national flags (preferably, before national flags) for consulates of member countries of European Union? The Union currently has 27 members and it's likely to expand, and not every European citizen necessarily should be aware of each of them. But then, you may ask, what makes European Union special, as, for example, Australians and New Zealanders are mutually entitled to consular help from each other's representative offices, as are Brits and Canadians (I remember reading about this somewhere I cannot recall at the moment). So I'm not outright proposing small European flags at the moment, I just want to hear thoughts on this. – (WT-en) Vidimian 15:44, 16 August 2010 (EDT)

Personally, I'm not sure we should have the flags at all. Our image use policy| requests that we keep image use to a minimum out of respect for users who are traveling and may have limited bandwidth. Putting a flag aside every consulate and embassy listing on the site seems contrary to that rule. (WT-en) LtPowers 20:28, 16 August 2010 (EDT)

It's a bit hard I think, because Switzerland also takes care of consular matters for Americans in Iran. I think this happens with many other nations as well. I am not sure on EU laws on this, but I think it's not even (yet) possible for a European citizen to use the embassy of another European nation to take care of things. --(WT-en) globe-trotter 20:41, 16 August 2010 (EDT)

Yes, there are possibly many more agreements with similar effects. And if there is no such agreement between EU countries in effect yet, then my initial suggestion is nullified.

However, like I said before, I do kind of like those small flags at the consulate listings but I also understand that they can be real culprits of slow page loads when trying to access Wikivoyage while travelling. Listings that are collapsible by default (which were discussed a bit here) can be the key, although I'm not sure whether they are automatically loaded with the rest of the page when the box is indeed collapsed (which makes no difference in regard to users with limited bandwidths, then). – (WT-en) Vidimian 08:39, 17 August 2010 (EDT)

The images would be loaded with the page even if hidden with CSS. (WT-en) LtPowers 10:04, 17 August 2010 (EDT)

I like the flags, they spice up that long boring list of consulates and it's easier to find your country with them. For the few KB they take up, I don't think they substantially add to loading times, even on slow connections. --(WT-en) globe-trotter 09:37, 17 August 2010 (EDT)

Indeed - Firefox tells me those flags takes up 700-850 bytes per flag, around 15 kb for the whole section in Copenhagen, hardly excessive use of bandwidth as far as I'm concerned. --(WT-en) Stefan (sertmann) ^talk 23:35, 17 August 2010 (EDT)

In need of a substitution script for listing tags on pt:

Swept in from the pub:

I posted this on Shared a few days ago, but the pub here is busier, so I thought I'd post here too:

Listing tags were partially implemented on pt: a while back with a translation of the wizard interface but without translating the actual tag names or attributes. Now I know how to translate those and I think it would be best to do so, but the problem is now that lots of those tags have been inserted in articles-- if I make the translations on the MediaWiki attribute pages, all the existing listings will immediate stop working, and there is no way to search and change the tags manually because the search engine (apparently) ignores things within brackets <>, not to mention the fact that there are a lot of them and changing them manually would be extremely tedious. If we had a substitution script to go through all the articles and change some strings like "<eat" to "<coma", "name=" to "nome=", "address=" to "endereço=", etc. it would solve this problem and I could go ahead and complete the tag translations so that everything works in Portuguese so that users would be more likely to use tags in the future. However, I know absolutely nothing about writing and running scripts. Would anyone like to work with me to create a script for us? Or, can anyone think of a different solution to this problem (i.e. a way to make the system accept tags and their attributes in both English and Portuguese)? Any help would be greatly appreciated!! (WT-en) Texugo 10:58, 21 February 2011 (EST)

Yet another reason I'm baffled as to the implementation of our listings tags. If they'd been done with MediaWiki templates, it'd be a simple matter to wrap the English template in a Portuguese wrapper. (WT-en) LtPowers 22:08, 26 February 2011 (EST)

But they do seem to be done with MediaWiki templates-- those listed at the bottom of Project:Listings. The problem is that the English template was already implemented in lots of listings there on pt:. If I translate the template now, all those existing English ones will stop working, and finding and replacing them manually would be an inordinate pain in the arse without a script.(WT-en) texugo 02:44, 27 February 2011 (EST)

No, by "MediaWiki templates", I mean the ones in the Template: namespace. Pages in the MediaWiki: namespace are interface messages. (WT-en) LtPowers 20:17, 27 February 2011 (EST)

Ah, gotcha, but you understand my problem, right? Know how to make a substitution script? (WT-en) texugo 21:28, 27 February 2011 (EST)

No, I'm afraid not. I could probably write one, but I wouldn't know how to tell you to execute it. =) (WT-en) LtPowers 16:18, 1 March 2011 (EST)

Multiple phone numbers

Maybe this has been discussed somewhere but I don't know where to look. How do we feel about listing multiple phone number/fax numbers? My personal feeling is that it is unnecessary (and cluttery) when someone feels the need to provide 3 complete phone number and 3 complete fax numbers. What's our feeling about this? (WT-en) texugo 00:50, 27 February 2011 (EST)

Of course there may be cases where it's necessary, but in the vast majority of cases, a single phone number should be sufficient. In places where faxes are common, a fax number is of course fine. (WT-en) LtPowers 20:12, 27 February 2011 (EST)

Is this enshrined on a policy page somewhere? If not, I think it should be. What would be a valid reason for having more than one? (WT-en) texugo 20:18, 27 February 2011 (EST)

There are fields for "phone", "fax", and "tollfree", which in my opinion is plenty. If someone wants to update policy to state that use of additional phone numbers is simply clutter then I'd be 100% in support. -- (WT-en) Ryan • (talk) • 21:50, 27 February 2011 (EST)

Let's make it an official proposal then:

Numbers should be limited to one per field, for phone, fax, and toll-free. If there are multiple phone number for your listing, please choose only one.

Support, to avoid cluttered listings. (WT-en) texugo 22:58, 27 February 2011 (EST)

Adding a listing for churches/religious services/places of worship

Swept in from the pub

I have recently added a listing for the church I attend into the Golden Horseshoe page because my church is a multi-site church and I thought that any visitors to this area might be looking for a church to attend. Also, I thought it might have been helpful to put individual listings on the page for each city where there is a site for the church so visitors could easily find it if they happen to be in that area. Unfortunately, all my additions and listings got summarily deleted and each individual page got reverted back to its state prior to my last edit by one of the administrators, stating that I was proselytizing. It was by no means my intentions to force people to come to my church or tell them that my church is right and everybody else is wrong. The pages affected were: Brampton, Burlington (Ontario), Halifax (Nova Scotia), Hamilton (Ontario), Kingston (Ontario), Kitchener, London (Ontario), Oakville (Ontario), Ottawa, Parry Sound, Toronto, and Waterloo (Ontario). Now, I would like to know, how can I (if I can) add a listing for a church/place of worship/religious service without appearing to be "proselytiz-y"? I noticed that there is still a listing for religious services under "Cope" for Windsor (Ontario). Can it stay or should it be deleted as well? If it can stay, can I use that as a template? Thanks for your help. (WT-en) ElectroSpace 01:59, 17 April 2011 (EDT)

As I was one of the two people who removed many of these listings, User talk:(WT-en) ElectroSpace#Meeting House Listings has some of the reasoning. Wikivoyage isn't currently anti-religion, and as Project:Where you can stick it#C states, places of worship that aren't otherwise tourist destinations can be listed under the "Cope" section of an article, but I have concerns about listings for religious "services" being copied to more than a dozen articles. For example says to "call ahead" and that "locations vary" - to me, listing a building with an address and regular services is something helpful for travelers, but listings for "services" that vary in schedule and location crosses a line and starts us down a slippery slope. If others disagree then these listings can be easily restored, but I think some discussion definitely needs to take place first. -- (WT-en) Ryan • (talk) • 02:40, 17 April 2011 (EDT)

ElectroSpace, consider what this site would look like if we listed every church in every city in the world. We can't, and in fact one of our explicit non-goals is to be a directory listing of all the [restaurants/hotels/churches] in a given location. Now, people who travel often do need to know where they can find an appropriate house of worship, but for reasons of pure practicality, we have to limit such listings to a reasonable number. We may not have hit that target everywhere, but that's our goal. (WT-en) LtPowers 15:26, 17 April 2011 (EDT)

My specific reasons for eliminating your listings were 1) multiple listings, 2) description of the beliefs of the church, i.e. claims about the "real Jesus", and 3) extraneous details like the name of the pastor and the mention of where else the church can be found. Beyond that, I have a general sense that most Christians on vacation forego religious services, and those that don't are dedicated enough not to be shopping for a new denomination to try out. I feel that your listing was trying to appeal to people to come try out your church, and I think that is something that is outside our scope at Wikivoyage.

Incidentally, aside from User:(WT-en) Jonboy's question on the WYCSI talk page back in 2006 and User:(WT-en) Jpatokal's subsequent addition of it into the WYCSI list, I can't find any actual discussion of the appropriateness of listing non-tourist churches at all, and I think it is something that should be revisited, because this is something that is an inherently un-policeable slippery slope:

Unlike other types of listings, people general tend to stick to their own chosen denomination, so any listing we have basically serves only the fraction of the population that already belongs to that denomination. Wikivoyage has no business trying to offer descriptions of beliefs or exhortations about how welcoming the service/congregation/pastor is, because people are unlikely to change to a new type of church anyway, and we are not in the business of encouraging them do so.
We can't possibly hope to cater to even a majority of faiths without allowing a virtual phone directory of possibilities. Even within Christianity there are so many denominations: Catholic, Orthodox, Southern Baptist, Methodist, Pentecostal, Lutheran, Unitarian, Anglican, Adventist, Church of God in Christ, Church of Christ, Mormon, Jehovah's Witness, Presbyterian, many subdivisions within these, many other less populous denominations and so-called non-denominational churches, not to mention all the many denominations of Islam, Hindu, Buddhism, and other major world religions. While it hasn't become a problem in the vast majority of articles, if we allow non-tourist churches to be listed then we must, to be fair, allow all types of worship service to be added-- how can we prune a long list of churches without someone saying "Why did you cut my church? It's not fair."
There are quite often multiple churches for the same denomination within a city, even quite small ones. There is no way for Wikivoyage to recommend one over another-- obviously the people who go to each church are partial to their church for whatever reasons, and there is no good way for us to choose which one(s) to list, nor to police edits and additions in this regard.
For those who speak English well enough to utilize our guides in the first place, it is easy enough in the English-speaking world to pick up a phone book and choose one from the giant list in the phone book. For those in a non-English speaking country, if their mastery of that language is good enough to appreciate a church service in that language, they are also good enough at it to use a phone book there.
This point is rather an aside, and it would be quite difficult to come up with statistics to show it, but my gut feeling is that the majority of travellers are prepared to forego religious services during their trip anyway.

With these reasons, I would propose that non-tourist churches be disallowed, period. The only exceptions I might consider allowing are churches in non-English-speaking countries that have services in English, since that is something that would be hard for a non-speaker of the local language to track down, and since it would be fairly obvious what should or shouldn't be included and the list would likely be always short and manageable. I'd like to hear more opinions on this, and probably the discussion should be moved elsewhere, though I'm not sure where offhand. (WT-en) texugo 02:15, 18 April 2011 (EDT)

You make some good points. It does seem like listing specific churches may be a bad slippery slope (though many of the same points apply to removing listings for embassies and consulates, and I lost that argument). Certainly an overview (in the Cope section) of the types of religious services available in a destination would be appropriate, but I wouldn't mind a prohibition on individual listings. (WT-en) LtPowers 09:12, 18 April 2011 (EDT)

Support. Churches, temples etc. that fit into "see" do of course have their place here, but this isn't the Yellow Pages. And who should then decide which places should be included and which not? It will mean trouble and a lot of angry people complaining about their place of worship being removed. (WT-en) Ypsilon 10:12, 18 April 2011 (EDT)

I'd be a bit uncomfortable with a blanket ban on listing churches in the "Cope" section since many people do attend a church while on vacation, and many that I know will attend a different denomination's services if their preferred denomination isn't represented. That said, I agree that very long lists are to be avoided, so would something similar to the rule on rental car companies work, ie if there are ten or more churches in a locality that they should not be individually listed? Similarly, I'd also suggest we avoid listings for "services" where the group in question doesn't have their own, single-purpose building to avoid a plethora of non-traditional listings that most travelers would not be looking for. -- (WT-en) Ryan • (talk) • 11:02, 18 April 2011 (EDT)

Ryan, in the US at least, even tiny towns of only 10000 people usually have ten or more churches. (WT-en) texugo 11:18, 18 April 2011 (EDT)

In my hometown of Pampa, Texas, for example, population of only between 15 and 16 thousand people, I stopped counting at 50 churches when I did a Google search. How can we ever fairly choose a helpful handful of those to recommend on our guide? (WT-en) texugo 11:27, 18 April 2011 (EDT)

I don't dispute that in most cases this policy would result in the article not listing individual churches, but for out-of-the-way places, some district articles, and smaller cities it would provide a way for places of worship to be included. Additionally, just as with car rental agencies I'd suggest that we wouldn't need to do any trimming until the list begins getting excessive, so if an article only has 5-10 out of several dozen places of worship listed there would be no need for any trimming to be done. -- (WT-en) Ryan • (talk) • 11:54, 18 April 2011 (EDT)

Ten seems like a lot, I'd be tempted to go with five as a limit if we don't exclude it entirely. (WT-en) LtPowers 20:06, 18 April 2011 (EDT)

And Ryan, how would you answer to my point that there can be absolutely no fair criteria for trimming once it does get more than whatever limit we set? I'm afraid we are setting a trap for ourselves later. What's wrong with leaving them a phone book to find their church out of Los Angeles' literally thousands of places of worship? Who's going to choose which of their 566 Baptist churches to recommend? And on what criteria? (WT-en) texugo 21:49, 18 April 2011 (EDT)

I'm not proposing that we trim - I'm proposing that if there are more than 5-10 listings we remove all individual listings for the article. That's what we currently do with car rental agency listings (see the final bullet point under Project:External links#What not to link to). -- (WT-en) Ryan • (talk) • 21:54, 18 April 2011 (EDT)

With car rental agencies, most places don't have many and customers generally don't have this kind of loyalty to one company over another. We decided to not list them if there are a lot there because it should be easy enough for travellers to find one, hence the "don't link to them in places where they are common" policy you linked to. With churches, they have a much higher degree of loyalty, and the vast majority of destinations have far, far more than 5 or 10, and hence already surpass the "easy to find" and "common" thresholds. Are you just suggesting it be first-come-first-served for people to highlight their preferred church until it reaches a magic number and then we blank it? I don't think that is a very fair or comprehensive approach.(WT-en) texugo 22:20, 18 April 2011 (EDT)

I think this may be an agree-to-disagree scenario, both with respect to church listings and why the rental car policy was put in place. My opinion remains that there isn't harm in allowing a handful of churches/synagogues/mosques to be listed in articles so long as the list doesn't grow too long, but it looks like I'm in the minority on this one. I do, however, think we should avoid religious "services" that aren't in a fixed location on a fixed schedule since that starts us down a slippery slope towards some potentially questionable areas. -- (WT-en) Ryan • (talk) • 11:05, 19 April 2011 (EDT)

We dont list supermarkets, we dont list dentists, we dont list places of worship. We list tourist attractions, places and services that are useful to the traveller in general. The usefulness of listing places of worship is limited to those travellers who subscribe to the particular religion, if that. If a place of worship is a tourist attraction then it gets listed as such, and many are among the architectural and artistic treasures of the world. Most are not. Most are as aesthetically inspiring as your average strip mall. I am very much against starting a bandwagon of religions touting on Wikivoyage. That way lies disaster. If you think we have problems with car hire and apartment touting, we will look back on them with fondness as the good old days. A couple of religious fanatics starting a spam/flame war could trash the whole project. Next thing we have a fatwa, (and beware the Pastafarians http://en.wikipedia.org/wiki/Flying_Spaghetti_Monster). Religious neutrality is the only way to avoid this problem. This means no listings, all listings or only listings that are totally non-contoversial. That would mean listings that are completely acceptable to persons of all religious convictions. Listings on Wikivoyage are traditionally limited to a maximum of 9 per destination. In other words, as soon as anyone protests a place of worship or deletes its listing, or adds a 10th listing, it is gone forever. Extrapolating from historical precedent in religious agreement so far, this level of agreement between religions will never happen. Far easier to go with no listings at all. If people feel strongly that they or co-religionists need to know where their places of worship can be found, a travel topic could be the way to go. That way only people who have some interest in that particular religion are exposed to the list of addresses. There could be topics on pilgrimages, that would fit in with Itineraries, and could even be moderately interesting. There are some classic pilgrimages.• • • (WT-en) Peter (Southwood) ^Talk 02:35, 21 April 2011 (EDT)

I don't disagree with your point of view on listing places of worship, but I have indeed seen listings for supermarkets, such as in district articles within cities, and such listings can be very useful for travelers. I believe I've seen listings for dental clinics under "Cope," too, and consider such listings very useful, if they're limited to clinics that take people 24 hours or/and in emergencies, for example, or in places where there is only one or a few dental clinics in the area. (WT-en) Ikan Kekek 03:04, 21 April 2011 (EDT)

OK you got me there. "Never mind what I say, listen to what I mean". Clearly I didn't do my homework on this one. Anyway, I think the supermarkets and dental clinics can be, as you suggest, useful to the average traveller, they were just the first examples that came into my mind of things we dont really want exhaustive lists of for every destination, and they are less likely to cause trouble too, or at least the dentists are not likely to start touting on Wikivoyage. Not so sure about supermarket chains though... • • • (WT-en) Peter (Southwood) ^Talk 05:00, 21 April 2011 (EDT)

I think we should be flexible enough to take some things on a case by case basis. I actually have seen a few instances of touting by dentists, but I don't think that's a good reason to forbid listing dental clinics in any situation, and I just specified a couple of reasonable exceptions to such a blanket ban. Similarly, while we definitely don't want lists of supermarkets hundreds of items long, a few mentions of good ones in particular neighborhoods can be useful in certain cases. So, to brainstorm, I think the way this relates to listing religious institutions is that famous ones, visited by a really large number of tourists or/and pilgrims, should be listed. And sometimes, the interest is not mainly architectural but cultural. For example, the Abyssinian Baptist Church is a venerable Harlem institution, in terms of history, advocacy for civil rights and the rights of the community, and Gospel services. It amply meets any test for inclusion in the Harlem and Upper Manhattan guide, though its architectural interest is moderate at most. (WT-en) Ikan Kekek 10:17, 21 April 2011 (EDT)

Touting by dentists comes as a bit of a surprise to me, I suppose it is because in my part of the world the medical council frowns on that sort of thing. No matter, In a large enough universe many weird things will happen. The Abyssinian baptist church you refer to surely qualifies to be listed under "See", for the reasons you give. I am not against anything thet is a bona fide place or object of interest for travellers, or is of general utility to a significant proportion of travellers, but keeping religion out of destination articles is a general principle I think we should stick with as it is not so much a slippery slope as a bottomless precipice. • • • (WT-en) Peter (Southwood) ^Talk 03:27, 22 April 2011 (EDT)

We are essentially in agreement. If anything, my emphasis is slightly different, in that I'm arguing more for retaining a reasonable level of flexibility, while you're rightly pointing to the "bottomless precipice" that could suck us up. So where I come down is that a great deal of caution is needed, but that we still need to look at entries on places of worship on a case-to-case basis and resist the desire to promulgate a rule that's too rigid, but at the same time, any guideline on such listings should state that they need to be justified by cultural interest to travelers or/and historically well-established interest to pilgrims, or in cases where English-language services are unusual in a given non-English-speaking locality. Does that sound reasonable to you? (WT-en) Ikan Kekek 14:42, 22 April 2011 (EDT)

This is Wikivoyage, no rules are totally rigid. You just have to adequately justify breaking with consensus. I have no problem with listings that are of cultural interest, and pilgrimage sites would normally fall ito that category (but have no problem with them anyway, some travelling is required to make it a pilgrimage). Places where English language services are offered in non-English-speaking locality are arguable, but lets expand locality to region. • • • (WT-en) Peter (Southwood) ^Talk 08:45, 26 April 2011 (EDT)

Region or city is where I would come down. (WT-en) Ikan Kekek 15:51, 26 April 2011 (EDT)

(Coming in late, and sorry not to respond to all topics touched on above.) Travelers do often need info on availability of religious services, but listing all churches, synagogues, mosques, and what have you would just bog down our site. My experience is that travelers have one of three questions on this topic:

Where is the closest X of my denomination?
Where is the most famous X of my denomination?
Where the heck can I find anyone to worship with from my denomination?

The first, I think, we should define as out-of-scope—much as we do with barbershops, for instance—simply because we cannot reasonably do so without overwhelming our other content. The second and third questions, however, are within our capabilities. The one example that comes immediately to mind is Chicago#Religious services. That section succinctly takes care of the two travel needs that I think we can reasonably cover, and cover reasonably succinctly! This type of section would by no means be desirable for every article, but it fit well in that huge city guide. --(WT-en) Peter ^Talk 19:53, 2 June 2011 (EDT)

I ran into this. Any comments? (WT-en) Ypsilon 02:26, 3 June 2011 (EDT)

Considering the size of the place that's not bad: something for everyone, yet short and succinct with just the key info. The only thing missing might be a contact no. The only quirk is the title "Cope", which is bizarre; even "Refresh" might be better! A priority here, of course, should be English language services in non-English speaking countries; there won't be many, but they're an oasis for English-speaking holidaymakers. This article shows that a sensible balance can be struck for larger articles. In smaller articles if the one or two churches are a point of interest mentioned elsewhere, we could just add times of services and contact no, rather than repeat info in a separate paragraph. --(WT-en) SaxonWarrior 07:47, 23 June 2011 (EDT)

Churches, barbershops, rental bikes, it is the same issue. Wikivoyage is a guide to assist travellers, not a yellowpages. When the something is so common in a city, whether it be laundrette, rental bikes, churches, or convenience stores, then we step back, because the traveller doesn't need a guide anymore. If a town of 10,000 has 50 churches, then we need to carefully consider whether we need to list any. --(WT-en) inas 06:00, 8 November 2011 (EST)

Listings of individuals

SWEPT IN FROM THE PUB

Hi, everyone. I'd like you to weigh in on this. My understanding has been that we don't allow listings of individuals, such as individual language tutors, trekkers, guides, translators, or drivers. But I'd like to refer you to a discussion taking place in Talk:La Paz and another that I just started at Talk:Banaue. I think we need to have a clear and well-thought-through policy on these matters. (WT-en) Ikan Kekek 06:20, 28 January 2012 (EST)

I think we these things we're guided by the number of potential listings, and the difficulty the traveller has in finding them. If there is only one elephant driver in a town, and that's the only way to get from the station to the camp site apart from walking, then we list them. Doesn't matter if they are an individual, or a franchise of Mega-Elephant. If there are a few elephants, but the traveller needs to be able to contact them, and the method for doing so is not apparent, then may need to maintain a compact list of choices. Style of listings, capacity of the organisation, traveller recommendations, etc, guide us in choosing who to list, but we'd rather list individuals than Elephant-Back-Travel booking office. However, if there are many elephants such that they are ubiquitous, then we don't need to list. A line of prose saying the elephants are outside the station, or some such suffices.

The bottom line is the traveller comes first. We don't need to accept a business owners rationale. --(WT-en) Inas 23:59, 28 January 2012 (EST)

The issue has also turned up at Talk:Yangshuo#Tour_Guides. (WT-en) Pashley 10:10, 29 January 2012 (EST)

Templated See and Do listings

Hi there. I'm only a new 'WikiTraveler', but am a seasoned Wiki-editor with many years experience. I am hoping to make some big contributions to this site, but something has been bugging me lately. I find that the See and Do listings on some articles can get very messy and disorganised. I think if we were to organise this information into a template/table, this would be much better for viewers to decipher information from, and also improve the quality of our articles.

This has been proposed many years ago at Wikivoyage_talk:Attraction_listings, but with little discussion or progress. It seems many other language WikiTravels do it. See here for a Japanese example. I understand we use WikiCode tags, and it could take a long time to convert every article to a template format. One option is to keep the WikiCode we use, but change how the system organises the info within the tags; from a jumbled text wall, to an organised table format. This would allow for a total revamp across the board, yet with minimal effort.

Any other thoughts, ideas or comments? Thanks, (WT-en) JamesA 08:56, 11 May 2012 (EDT)

One of the reasons the wikicode tags were used was to add the "edit" links to make it easier for non-technical contributors to add and edit listings. As far as I'm aware there would be no way to achieve similar functionality using templates. -- (WT-en) Ryan • (talk) • 10:30, 11 May 2012 (EDT)

Maybe this is just me... I feel like the Japanese presentation is a bit over the top, but I'd be quite happy just to add a bit more formatting to the current presentation. Just a bit of italics here and there, that kind of stuff. Most English-language print guidebooks do this, and I think it aids readability and makes it easy to spot when a listing is missing a piece of info. --(WT-en) BigPeteB 14:18, 11 May 2012 (EDT)

Our listings already use bold and italics. (WT-en) LtPowers 18:50, 11 May 2012 (EDT)

We do have a great system for adding listings. This system can easily be kept. What would be changed is where that information goes. There has to be a page somewhere (probably a MediaWiki: page) that organises the listing into the format it currently is, with the bold font, italics, etc. From a glance at this page, it seems User:(WT-en) IBobi handles the wiki's technical stuff, so maybe he would know how to change it.

The Japanese format does take it a step overboard with all the colours and pictures. We could always have a much more toned down version. I just feel the way it is now is really messy. Look at the opening times on the first listing here; it's all over the place. A possibility could be just to add more bold/italics/underlines, or even put some information on separate lines or dot points. Does anyone want to have a go at fixing it up? (WT-en) JamesA ^>talk 04:28, 12 May 2012 (EDT)

Yes, I know they already use some bold and italics... I was saying I think they could use a little more. --(WT-en) BigPeteB 10:15, 18 May 2012 (EDT)

Well, to be honest, I wouldn't know how to change them. But a good start would be creating a mockup. Project:Listings would be a good place to discuss the mockup once you create one. (WT-en) LtPowers 19:26, 18 May 2012 (EDT)

I certainly wouldn't want to see the listings become as colorful and complex as the ones on the Japanese site and I like the tag system we have now, but I think some minor tweaking couldn't hurt - putting the opening hours and the price info in italics, to further distinguish them from the description of the place, would really tidy up the presentation (whether this can actually be done I don't know, but I'm just throwing that out there). I really wouldn't want to see any more bolded text in the listings - as of now only the name of the place is bolded, and I like that because it highlights it and makes it easier on the eye when you're scanning an article looking for a specific listing. (WT-en) PerryPlanet ^Talk 10:31, 19 May 2012 (EDT)

We could make the phone number blink! (WT-en) LtPowers 13:35, 19 May 2012 (EDT)

Moving the hours to a separate line could be really useful. I think we could make them more readable:

Current version:

<see name="International Spy Museum" alt="" address="800 F St NW" directions="" phone="+1 202 393-7798" url="http://spymuseum.org/index.php" hours="9AM-5PM or 9AM-6PM daily, last admission one hour before close" price="Adults: $20, seniors: $15, children (5-11): $15, 4 & under: Free" lat="" long="" email="" fax="">D.C.'s newest hot attraction's principal claim to fame among locals is the extraordinarily long line that usually winds out the doors (not to mention the high price tag). Its popularity, while a bit disproportionate given all the other great free museums in town, is not unwarranted—its exhibits are interesting to anyone even marginally interested in espionage and Cold War history, and it also has a great exhibit tailored specifically to kids.</see>

Another idea:

International Spy Museum, 800 F St NW, ☎ +1 202 393-7798, 1.

9AM-5PM or 9AM-6PM daily, last admission one hour before close.

D.C.'s newest hot attraction's principal claim to fame among locals is the extraordinarily long line that usually winds out the doors (not to mention the high price tag). Its popularity, while a bit disproportionate given all the other great free museums in town, is not unwarranted—its exhibits are interesting to anyone even marginally interested in espionage and Cold War history, and it also has a great exhibit tailored specifically to kids.

Price: Adults: $20, seniors: $15, children (5-11): $15, 4 & under: Free.

Good idea to take a fresh look at this. We'll have to wait until we have functional tech support, or the ability to do our own tech support, before we can implement this, but it's good to figure out what we want in the meantime. --(WT-en) Peter ^Talk 15:55, 19 May 2012 (EDT)

That's great, Peter! The separate lines makes it much easier to read the information, instead of it being a jumbled mess. Most travel guides do organise the info how we do it now, (all in one long spiel, rather than spaced out) but that's just because they need to fit all the info into a specific number of pages. We have much more room than books, so it makes sense that we make use of it and make the info easier to read for viewers. I'll do some perusing and see if I can find out how to edit the backend stuff. (WT-en) JamesA ^>talk 07:05, 21 May 2012 (EDT)

Excellent suggestion! (WT-en) Atsirlin 07:15, 21 May 2012 (EDT)

If anyone wants to have a go searching for how to modify the backend code that configures the layout, here may be a good start. That's a list of all the technical MediaWiki pages that can be tweaked. Some pages have the prefix "listing", which might be somehow relevant. But don't take my word for it; the page we need might not be there. (WT-en) JamesA ^>talk 09:02, 21 May 2012 (EDT)

Keep in mind that, despite the prevalence of mobile options in the modern era, making guides that can be easily and cheaply printed out is still one of our explicit goals. (WT-en) LtPowers 20:17, 21 May 2012 (EDT)

It is entirely possible to change the format for a printed guide, much like we do now for URL formatting. --(WT-en) Inas 20:27, 21 May 2012 (EDT)

Is that feature custom to Wikivoyage, or a feature of MediaWiki? (WT-en) LtPowers 13:35, 23 May 2012 (EDT)

The alternate formatting for printable version is a MediaWiki feature. All it does is use a different (css) stylesheet for formatting. I'm pretty sure MediaWiki allows more of these stylesheets to be configured as preferences too. So in my understanding you could easily have a different style for printing than you have for online display, so we shouldn't let the printing bit constrain our thinking too much. After all, our online display currently has no URLs, so is inherently unsuited for printing. --(WT-en) Inas 19:29, 23 May 2012 (EDT)

There's been a week of inactivity, so is everyone content with just implementing Peter's version for the time being? There's no colour or pictures, simply a few extra lines and spaces, and it should be possible to keep the Printable version as-is. After implementation, we can re-discuss if there's any issues. I did a little search around to find the code we need to edit, but it's very complicated. It looks like Ajax and CSS were used, which is only editable by site admins/IB. The Listing Editor's code is here. The formatting of the listing is here. Original discussion here. While we're at it, we should add the 'email' option to the editor, which has been long missing. I guess we should file a tech-request then? (WT-en) JamesA ^>talk 23:21, 29 May 2012 (EDT)

Given the complexity of the change and the expansiveness of its effect, I'd prefer to see more discussion before we go making major changes. (WT-en) LtPowers 13:35, 30 May 2012 (EDT)

I would also like to see some more discussion on this before making a change. Listings have a variety of completeness and length of information, so depending on what is there, the above proposal could easily produce a very lopsided-looking listing like this:

International Butt Museum, 800 F St NW, ☎ +1 202 393-7798, butt@buttmuseum.org, 1.

9AM-5PM.

Super awesome museum about butts. Great for people who have butts or would like to find out more about butts.

Price: Free.

(WT-en) texugo 15:16, 3 June 2012 (EDT)

Is there a code that we could use that would only implement the multiple-line layout when a certain character/word count is reached? Sounds complicated to implement, though. (WT-en) JamesA ^>talk 05:42, 4 June 2012 (EDT)

That would result in an ugly (I think) situation with listings appearing in a random combination of the two formats. I think we would have to either go whole-hog, as ja: has done, or just leave it alone.(WT-en) texugo 12:53, 26 June 2012 (EDT)

Looking at it more, aside from the thematic content, the butt museum example doesn't bother me aesthetically. I think it too is more digestible in that format. --Peter ^Talk 19:35, 29 September 2012 (CEST)

I dunno, I'd be concerned about how this would look with a whole series of similar listings in a row. Right now, we have a lot of articles with just-the-facts listings that only take up one line each; this would expand them significantly. And there's still the printing issue to deal with. LtPowers (talk) 00:40, 30 September 2012 (CEST)

I by myself think that the listings extensions are a deprecated feature. So, the current extension is mainly for backward compatibility. The main reasons are that all tag attributes and styles are hard-wired, and we must raise time and personal resources to code all that. I have no idea if we would be able to do this in future and if we would have access to the servers to change the extension. At least, the community has no chance to do it by itself. Therefore, I propose the use of templates instead of the see, do, eat etc. listing tags. We do it at the German branch with the vCard template since more then 5 years.

If we use templates we have all opportunities to change the layout like multiline or tabled ones. With if and switch statements several layouts could be made available.

Of course, because of the lack of editor features of the Mediawiki software we cannot offer now similar features easily to handle. In the interim we use a JavaScript-based interim solution at the German Wikivoyage to edit the template data in a form, see Editing templates with forms (in German). In future, a Visual editor would be available, and I hope it would be support entering data for templates.

We should discuss all this separately to get general consensus. --Unger (talk) 12:43, 7 October 2012 (CEST)

What if the future looked like this?

Swept from the pub:

Three separate discussions about allowing Facebook links, web/email format, and redesigning our templated listings format have got me thinking how we can update or modernize the way we present our information, and I've come up with a tentative proposal. It's really less a proposal and more just me throwing some ideas around, so I'm open to debate on any of the multiple points this will introduce, but I think the general idea is worth considering. Before I lay out the proposed changes though, I'd like to make some points and detail some reasoning behind the proposal.

Social networking as contact information - Since WT started, social networking has grown drastically in importance as a means of communication, in some cases being now more important than phone numbers or emails, and surely in all cases more relevant than ~~telegram~~ fax.
- Facebook - As the Facebook discussion points out, many establishments have only Facebook as their web presence, and consensus seems to be leaning towards allowing them in such cases. Even for those who have also a normal website, Facebook may provide a more convenient way of contact for travellers, since a huge portion of our users also have Facebook accounts.
- Twitter - Hasn't been discussed, but since Wikivoyage has started, Twitter has taken over the web, and many many establishments have a twitter account, many users are bound to have accounts, and Twitter makes a more convenient avenue of communication for some than phone calls, full emails, etc. Twitter is especially popular with smaller accommodation owners, local restaurants, bars, music venues, and recreational activity providers, and even many mainstream attractions such as museums and festivals have an account.
- Skype - Many smaller restaurants and accommodations (e.g. hostels) have Skype accounts which would provide travellers with a free international phone call or text consultation. I know that I, for one, would be far more likely to call via Skype to book a room at a foreign destination than I would to call international long-distance via landline.
Grouping all contact information - Within a listing, contact information should all be grouped together. As an aside, I will throw in the bold assumption that fax info can be eliminated as a now-outdated mode of communication unlikely to be used by travellers. For the purposes of this proposal, then, contact information will be taken to mean:
- Address, including directions, if any
- Phone number
- Official website
- Email
- Facebook business page
- Twitter
- Skype

Accepting the above definitions as reasonable and assuming we can set up the templates to do what we want, the tentative proposition is simply this:

We separate all the contact information, either into a separate column on the right or on a fresh line under the rest, leaving the lead to go directly from the name into the description, followed by hours and price.
In the contact info part, the address and phone number are written out. Everything else gets just a small linked icon unless you print the page.

Template fiddling, spacing, which icon to use, how images are incorporated into such sections, etc. can all be worked out later, but I made mock-ups of a couple of layout ideas. I tried to include examples with an assortment of information quantities to approximate how it would look with the completeness of an average article. Anyway, I'd like to call for your general comments and opinions, so... what if the future looked like this? :

(WT-en) texugo 17:39, 4 July 2012 (EDT)

I don't know how to artificially display our standard bullet points and cannot make functioning icon links, so please use your imagination. Also, if you know how, feel free to mess around with the messily-coded mock-ups and/or make new ones, but please do so on a different page so these will be here for others to look at.(WT-en) texugo 17:54, 4 July 2012 (EDT)

I think these are some good ideas. I'd support the removal of 'fax', but I notice you've also removed 'alt' phone. A lot of Asian/African countries have multiple phone numbers, due to unpredictable landline connections. Some smaller businesses also give the option of mobile or landline; whichever is cheaper, or working. Therefore, I think that should stay. Facebook, Twitter and Skype accounts are a good idea, but we'd need to be careful about linking to "official" accounts, and not someone's fanpage. I'm leaning towards something along the lines of Mock layout 1, as it separates the information into where it belongs, whereas the others shove things like trading hours, price and descriptions. Mock layout 3 could be good if the left column was widened. One option could be automatic column width, so that if the left column gets a lot of text from things like directions, it would be wide, whereas if all it had was titles, it'd be narrow. But very nice work overall. (WT-en) JamesA ^>talk 06:45, 5 July 2012 (EDT)

FWIW, I didn't intentionally leave out alt phone numbers. I just didn't think of them because they're are very rare in the vast majority of articles.(WT-en) texugo 08:42, 5 July 2012 (EDT)

I made a similar proposal at Wikivoyage/de at our lounge. Of course we implemented do, see and eat tags, but we use mainly a template named vCard. A template is more flexible and could easily be changed without programming. We use a template master to make the data entry simple but I hope that new Mediawiki versions will have its own graphical tool. By the way I prefer the first variant. --(WT-en) Unger 01:41, 5 July 2012 (EDT)

I agree with your assessment of the third mock up and have widened the left column somewhat. I also think that one would look slightly better if both the telephone number and the icons were on the same line but with the number left-aligned and the icons right-aligned (but still in the first column), instead of taking up two separate lines. (WT-en) texugo 11:39, 5 July 2012 (EDT)

I cannot speak to the prevalence of fax as means of communication in certain areas; it seems like it might still be used in some places, but I can't say for sure. Is there any harm in leaving it? Phoneextra is also useful for TDD/TTY numbers, though those are also going by the wayside. (WT-en) LtPowers 12:26, 5 July 2012 (EDT)

The only harm it does is to work against economy of space. I just have a hard time imagining that more than the rarest of travellers would even consider sending a fax to make a dinner reservation or inquire about hotel vacancies these days, especially to/in a foreign country. Even in Asian countries where they are still more common, I think they are mostly used for inter-business purposes.(WT-en) texugo 13:13, 5 July 2012 (EDT)

I work in many countries. Fax really has died over the last 5 years, so I do not think it is a problem to drop it completely. If absolutely necessary somewhere, it could be put in as part of the text. I like mock up 3! However, I am not convinced of the value of adding Twitter. There is a risk of too many icons littering a page.(WT-en) Davidbstanley 11:27, 6 July 2012 (EDT)

[de-indenting]
For fax (along with alt, checkin/checkout, and several other tags), I think we should just nix it from the listings editor, but keep it available if someone in the know wants to add it, for the relatively rare exceptions that would see them as useful.

I think adding facebook/twitter information is the right way to go, as businesses put out a lot of really useful information through both. Hopefully we could create something more generic, though, to include other microblogs and personal social networking page sites. (Evan hasn't yet dethroned Twitter, but I'm bullish on destroying Facebook .) I can't comment on skype—haven't yet worked it into my travel bag of tricks.

Texugo, I really like your first mockup—awesome stuff! It would be good to make the hours stand out even more, though, as they are arguably the most important reference information we include. Maybe italics? Or color?

Unger, does your template work with the listings editor? Keeping the listings editor will be crucial if we ever do launch into the yesteryear age of online editing... --(WT-en) Peter ^Talk 16:04, 5 July 2012 (EDT)

I'm poking around clker.com (PD icons), and found some that either would be great looking imported as is, or which I could edit a bit. For urls, is pretty nice. I could fix up one of these to make it look a little tweetier , and could try to fix one of these for social networking profiles . Our email icon is fine, but these are a bit snappier . Adding an hours icon (basically any clock) could be another good way to highlight the ever-important hours field. --(WT-en) Peter ^Talk 16:20, 5 July 2012 (EDT)

I'm also partial to mock-up 1, and I totally agree about italicizing the hours. I've gone ahead and done that on the mock-up, and it works well to set that info apart from the description. As to icons, I'll get back to you on that, but I was basically just shooting to find ones that have the same background shape (couldn't find one for Skype). I'm leaning toward making the icons for facebook, twitter, and skype clearly indicate what they are though and wouldn't really like to use a generic that doesn't at least indicate something similar to their own icon. I like the idea for a clock icon, and I considered using one to replace our little phone symbol. It would be nice to mock up some stylistically matching sets of all the necessary icons since they'd always be sitting next to each other in random combinations. Anyway, choosing specific icons would be its own discussion if consensus gets behind this idea.(WT-en) texugo 16:53, 5 July 2012 (EDT)

One thing I'm noticing is that the price info can get a little lost at the end of the hours line (which can vary wildly in length). Perhaps move it back to the end of the description, and bold it? Or we could have the price range follow a more eye-catching dollar icon? --(WT-en) Peter ^Talk 17:49, 5 July 2012 (EDT)

I like the layouts, Mock Layout 3 makes the address easy to find in a list of places, which is good in larger cities where maybe I am looking for somewhere to eat in the North side of the city. However I am not so sure about generally adding Facebook and Twitter links. If a business uses Facebook as its main internet presence then this can just go in place of a web address. I would not expect to look at Twitter as my first contact with a business, more as a way of staying in touch with somewhere that I already use. There may be the odd exception like an airport that tweets departure information, but then I think that we should take the trouble to say what is being tweeted. Unless devices are common that can only look at Facebook / Twitter and not web pages, then I think that the traveller should be directed to whatever is the best first point of contact and can then find other links from there (which helps to avoid getting fan pages added).(WT-en) AlasdairW 18:54, 5 July 2012 (EDT)

Here's a bored half hour's worth of icon work from someone who probably isn't too good at this kind of thing... Anyway, they are of even width & height, and conform in a very loose way to our usual color scheme!

Like 'em? FTS? Suggestions? Anyone want an SVG of this? --(WT-en) Peter ^Talk 19:13, 5 July 2012 (EDT)

I appreciate the effort, Peter, but I gotta admit the icons don't mean anything to me. A couple I can figure out with some concentration, but icons like these need to be immediately recognizable to be useful. (WT-en) LtPowers 22:24, 5 July 2012 (EDT)

I'd disagree with that sentiment, if not the criticism of the icons, since you can always just hover your mouse over an icon to see what it's about. In any rate, our current footnote looking things aren't immediately recognizable! --(WT-en) Peter ^Talk 23:22, 5 July 2012 (EDT)

Case in point! --(WT-en) Peter ^Talk 00:56, 27 July 2012 (EDT)

Facebook I am concerned about the concept of Facebook linking. To include Facebook potentially opens a quite large can of worms in regard to patrolling. We have had plenty enough problems with @yahoo.com, @hotmail.com and @gmail.com email addresses. Especially in the 3rd world many providers use common domain email addresses, or use them as a back up secondary email address.
In some regions (especially the Indian sub-continent) every time someone changes one of these addresses they need to be checked to ensure it is not a hijack attempt. This phenomena is particularly common in the Indian articles but appears elsewhere as well. It has occasionally been suggested we should eliminate these common domain email addresses from the articles. This is not practical as many quite legitimate and substantial providers use them. It would be unfair to a large body of providers and disadvantageous to travellers to eliminate them. Unless the provider is well known to the patrolling editor, or the common domain email address is published on the providers website or another authoritative source then it is often difficult and time consuming to determine legitimacy. Sometimes an extensive examination of edit histories is required to determine the bona-fides of the editor changing or adding the common domain contact.

☯To add Facebook listings to this mix seems to be asking for more trouble. Though it is of course understood that many traders do use Facebook accounts I have noted many Facebook accounts appear to be name holders, similar in a way to registering a common domain name email address, or a domain name similar to that of a trader or product, and then sitting on it either to block use of it or to gain some advantage by selling it or using it to divert business to someone other than the principal business.

☯Perhaps we need to consider if FB is really even accepted as a formal communication vehicle, or is it more one of tagging and maintaining existing customer connection through often vacuous self promotion. I have also noticed that for many small operators a common domain email address and a Facebook account is their only web presence. Anecdotally it appears that Facebook does not work well for many third world tourism providers. Many small operators tell me they do not believe it provides them any tangible business opportunity and it is email, SMS, Telephone, Skype and positive Tripadvisor recommendations and referral that are far more important to their activities

☯The previous discussions concerning FB seem to have hovered over the idea of 'business' Facebook accounts being linked. For those who might use a Facebook account in replacement of a business website we must consider if they are really likely to use a revenue account with FB, it seems unlikely, therefore we are setting ourselves a near impossible task of assessing the 'commercial' relevance of individual FB accounts that may be associated with a business operator. There is also the issue of inactive FB accounts. Some people tire of the medium and neglect it, so if we link to an account such as this we are potentially adding a dead end contact.

☯Perhaps our endeavours would be better applied to ensuring the existing contact methods are accurate rather having our efforts diverted into an added burden of further account verification demands arising from FB and Twitter accounts and the questionable virtues of supporting a commercial opportunity for either IB, Facebook or Twitter arising from providing such links in the articles and then patrolling them for consistency and legitimacy.

☯I am unconvinced of the benefit to the project and not at all keen to commit my own time toward refining a potential revenue stream derived from FB clicks or the data mining and correlation models operated by FB and Twitter.

☯I am raising this here as I note the Project:External links guideline on this has been modified recently. Perhaps this requires a little more scrutiny, especially in regard to the potential outcomes in regions with a history of contact hijacking and also in regard to our own participation in developing the Facebook and Twitter commercial models by facilitating WT linking.

Twitter seems to be reliant upon an always-on connectivity, this is irrelevant to much of the world, I think we should be wary of viewing the world through a lens narrowed by the hype of always-on connectivity. Also I wonder why we are allowing these 3rd party commercial links into the body of the article, we should not forget the core function of enterprises such as FB, it is to collect, collate, control and commercially disseminate data for commercial gain, it is not a benign vehicle of communication.
Skype linking is a different thing, I thoroughly support that and it would be good to see a listing field added to the standard format asap. As for adding an icon for that, great idea. Skype is a service commonly used and very popular with travellers.
Alt phone this should stay as it is essential to list more than one phone contact in some regions and PABX systems are rare in many 3rd world environments, I don't think it requires an icon though.
Fax is difficult, some still use it for payment authorities and many banks and insurance companies will insist on faxing documents and will not accept email communications, having the number readily at hand in a WT article may assist the traveller in circumstances such as these so maybe it should remain as listing text detail, but not have an icon. --(WT-en) felix 23:41, 6 July 2012 (EDT)

I certainly agree with negative sentiments regarding Facebook. But, small businesses—even those that have a real webpage—often update their personal facebook page with important information more frequently. In my endless search for details belonging in listings, I often cannot find hours information for small boutique restaurants, or current event listings for nightclubs or rock venues without looking into their Facebook page. Microblogs, such as those on Twitter, are a similar deal for finding current events. --(WT-en) Peter ^Talk 12:36, 7 July 2012 (EDT)

Frontlinks post-import

Latest comment: 11 years ago2 comments2 people in discussion

We have to get rid of all these ugly front-links generated by the listings code post-import! If we're anticipating a flood of new contributors in the quite near future, we can't have a blatant de-facto policy violation leading them to believe that such aesthetic abominations are acceptable in our distinguished community! --Peter ^Talk 04:45, 28 September 2012 (CEST)

I was wondering how that happened! Yes, I don't like it at all, and we should go about reverting it immediately. However, it seems none of us know how to edit the way listings are displayed. JamesA ^>talk 05:01, 28 September 2012 (CEST)

Someone somewhere in the wiki world must know how to change this. Nurg (talk) 22:26, 14 December 2012 (UTC)Reply

The listings are currently generated by mw:extension:listings and their format is defined by the open-source PHP code of that extension. We can't edit this directly, but do have a few possible options:

Have a robot script replace all these tags with {{listing}} templates and the issue goes away. The template has a few advantages; it replaces the front-link with a globe icon for the URL, it handles (lat,long) co-ordinates properly, it supports the hCard microformat (so that Operator can extract contact info and map locations) and it's editable instead of being hard-coded as extension code so we can extend it as needed.
Report the front-linking as a bug on bugzilla: and hope someone else (who has access to deploy code) gets around to fixing mw:extension:listings (either to change the listing format or to have the extension simply invoke a {{listing}} template - if it exists - for everything instead of forcing listings into a hard-coded format).
Install the extension and a few Wikvoyage pages on a MediaWiki test server, change the code, then post the fix to bugzilla: on the assumption this will get fixed more quickly if we post solutions and not mere questions.

Having a 'bot replace every listing tag would avoid having to request intervention from Wikimedia but would have the disadvantage of the script needing to edit every page to remove the old tags.

The current extension looks for the name of a template to handle (lat, long) and drops that template into a fixed position in the individual listing. There's no reason why the same approach couldn't be used to look for {{tl:listing}} and blindly pass the tag type (eat/drink, come/see/do/conquer) and every one of the parameters directly to a template which in future could be edited as needed.

If I go to the test {{listing}}s on Brockville#Nearby with the Firefox "operator" extension installed, menus appear for "contacts" and "locations" which invite me to download all the co-ordinates as a .kml file, view one of the locations on google/mapquest/yahoo or grab the contact info for my bookmarks or address book. Evidently, it only finds the templated listings and not the extension tags - but ultimately a hard-coded extension to do the job of a simple template is an inflexible and ugly solution. K7L (talk) 23:09, 14 December 2012 (UTC)Reply

You guys have a very strange idea as to what's ugly!

I doubt it's really the case, but in your public announcements it's as if you don't seem to understand that the world wide web
a) likes links
b) likes those links to be clearly signalled.

You really prefer the ugly system of having a numbered symbol in blue when newbies (especially if they find us from Wikipedia) waste their time searching for the (non-existent) key to the consecutively numbered links?

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 that the new Template:Listing has been implemented, 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)

Listing Templates

Latest comment: 11 years ago6 comments3 people in discussion

Swept in from the pub

Should we be using the templates at the bottom of the page for Attractions, Activities, Shops, Restaurants, Bars and clubs, Hotels and Other listings? Is that for new items only, should older formatting be changed? I am not sure what the policy is for this, Thanks. Xltel (talk) 18:40, 16 September 2012 (CEST)

Yes, those should be used for all listings. --Globe-trotter (talk) 18:47, 16 September 2012 (CEST)

Speaking of listings, the format has changed for links: right now they're all showing up as front-linked using the full the name of the listing, which isn't our old postlinked format. I assume this wasn't deliberate (it would mean updating a LOT of pages style-wise!), can this be changed to the previous markup? — D. Guillaume (talk) 03:33, 19 September 2012 (CEST)

Yes, I already raised this at the migration bugs section of the tech sub-site. The German and Italian Wikivoyage language versions have seemingly been doing it like this all along. I hope to see this changed, as using the full name as a link looks spammy. Also, the [add listings] button should return, but that probably requires a lot of work... --Globe-trotter (talk) 04:00, 19 September 2012 (CEST)

Is anyone working on this? Who can work on this? What do we need to do to get this done before we leave Beta (in about a month!)? --Peter ^Talk 02:35, 17 December 2012 (UTC)Reply

There is a bug open on this, you might want to ask there? K7L (talk) 04:03, 18 December 2012 (UTC)Reply

Looks like it was filed and completed today? Time to experiment with a template now. Should we just import :wv/de's? --Peter ^Talk

vorlage:vCard still has the front-link, so is no better. Pigsonthewing already created a {{listing}} which is almost exactly what's needed. There are some example entries on Brockville#Nearby where I'd tested this on a few real listings. K7L (talk) 23:05, 18 December 2012 (UTC)Reply

Per the bug report update it looks like the next Mediawiki update will give the ability to specify a template to override the hard-coded listings format:

When the patch is initially applied, the extension continues to operate as it always has... until Mediawiki:listings-template is created and set to the name of a template (ie: "listing" for Template:listing, which would work well with this code were the leading "* " removed from the template).

Once the listings template is defined, listingsTag() generates {{ listings-template | type= (eat, drink, sleep) | name=...and any other parameters, passed through as-is| listing $input text... }}, feeds it to the parser to expand the template to output text and then exits without doing much of anything else - effectively shutting down the hard-coded output formatting built into the extension.

The WMF support guys rock. -- Ryan • (talk) • 17:21, 19 December 2012 (UTC)Reply

Gotcha. So we just need to wait it out with the frontlinks until the next MW upgrade. --Peter ^Talk 19:33, 19 December 2012 (UTC)Reply

I may have mis-read the bug initially - a patch was submitted, but it looks like it may still be pending review. It may help to speed up the review process if people could go to bugzilla:43220 and click on the "vote" link next to "importance" in order to ensure that this patch is reviewed as soon as possible. Once it has been applied my understanding is that the change would become available on this site fairly quickly as WMF does bi-weekly software updates. -- Ryan • (talk) • 17:25, 1 January 2013 (UTC)Reply

Add Listing functionality

Swept from the pub:

Unless if I've gone insane, we've lost the [add listing] button that used to sit next to our imperative headers on destination articles. That means the listing editor is also inaccessible. I never used it, but I know it's a useful tool for new users and businesses to make use of our site. Any idea how or why this happened? JamesA ^>talk 03:27, 3 October 2012 (CEST)

I think it is custom code that is too much work for the Wikivoyage admins to work on. I think this will have to be dealt with after the migration to Wikimedia (just like the front linked headers). --Globe-trotter (talk) 04:02, 3 October 2012 (CEST)

See Templated See and Do listings above. --Unger (talk) 12:14, 7 October 2012 (CEST)

About tables.

Latest comment: 11 years ago19 comments6 people in discussion

When I tried to use some pages here, it was difficult to find the information as I wanted, because they were not grouped. I did not put the tables because of the style (alias, they are ugly), but to facilitate consultations. Moreover, it requires some organization, placing the data in the same order, and shows clearly the missing data of the object. And look at the type of table that I put, it is not any kind. (Florianopolis). Rodrigo Tetsuo Argenton^m 17:15, 21 December 2012 (UTC)Reply

I think having sortable listings is a great idea. Ideally, we wouldn't do it with tables, though, because that would make it difficult for inexperienced users to edit listings. --Peter ^Talk 18:36, 21 December 2012 (UTC)Reply

I know that, so I started a template, which I think makes editing easier. And we can put as default for city/neighbourhoods articles. So when a newbie edit/create something he will see:

==Eat==
 <!--  Don't remove -->{{Eat-xy}}
 <!-- substitute the spaces below by information of the place you want to describe. -- >  
 {{E-xy|Name|Location|Contacts|Lunch|Dinner|About|Type}}
 {{E-xy|Name|Location|Contacts|Lunch|Dinner|About|Type}}
 {{E-xy|Name|Location|Contacts|Lunch|Dinner|About|Type}}
 ... 
 <!--  Don't remove -->|}

Something like that. Rodrigo Tetsuo Argenton^m 20:56, 21 December 2012 (UTC)Reply

I think that it is a very bad idea:

Our intention was to make listings more flexible and add extra fields like skype, facebook, etc. Now everything goes back to only 7 columns, and we lose any flexibility.
Narrow columns look ugly. They probably look fine on a wide screen, but on the laptop they look ugly
Different tables have different column width. This is terrible-(
What is the advantage of tables over normal listings? Sorting option? But which criterion should we use? Not the phone number, not the street address. The only meaningful field will be the "type", but this type is vague. Maybe it works in Brazil, but in all European countries that I am familiar with, the "type" makes little sense. For example, in Germany we may have Italian or Greek places, but most of them are nothing but "cafe" or "restaurant" with essentially no difference between those two. In Russia, it is nowadays very typical to have sushi in a pizza place, so what "type" of place is it?
Honestly, I do not understand why we need this sorting option at all. The very idea of a travel guide is to provide a reasonable, but not an excessive choice of places to eat. We never have more than 10-15 places in every price category, and I think that it is fairly easy to look through the descriptions and make one's choice. In fact, the listings format stimulates people to read and experiment. Even if you want pizza, you may want to go to some other place because it has a fancy description on Wikivoyage. That's what travel is about. We write a travel guide, not a guide to restaurants.

--Alexander (talk) 21:32, 21 December 2012 (UTC)Reply

I agree with Peter Fitzgerald that sortable data would be useful, but also with his comment that tables would probably not be the best way to do it. I also agree with most of Alexander's comments about the appearance and inflexibility. Is there another alternative that can give the appearance and flexibility which are of great importance, along with a sortability improvement?

Speaking from personal experience, I find that editing tables is much more difficult to get right than a simple templated listing, and I have actually created and edited quite a number of tables on WP. For a newbie/occasional editor they are a nightmare.

Editors who struggle with or cant be bothered with formatting are more likely to produce a reasonably acceptable listing manually in a listed format, and this is easily cleaned up to a templated list by regulars. A table is more likely to end up in a mess.

Having said all that, I accept that I am not an expert on tables, and there may be a way of doing it that works. If so I would like to see it.

Maybe it is possible to produce a record input tool like in a database, which has spaces for each field, and then automatically formats the input to a readable, attractively formatted presentation in the article, but remains usefully sortable, after all, the whole wiki is on a database. • • • Peter (Southwood) ^(talk): 22:12, 21 December 2012 (UTC)Reply

Why do we need to sort anything? The listings should already either be in alphabetical or geographic order. LtPowers (talk) 03:20, 22 December 2012 (UTC)Reply

I'm starting to think that you never used the WikiVoyage, otherwise, you do not doubt the usefulness of the sort, alias, is very flexible, I made a beta version, you can put more columns, if you want. Alias, I made the template for countries, you just adapt to each situation.

Alexander, if you do not know the difference of a vegetarian restaurant to a steakhouse, that's not my fault, and we're not discussing about the content, but about the use of the table. And there are two sections with tables in the article...

Peter, thesis's not a simple table, this is a template, so is more simple to use, and I do not know how we could do without tables... How to organize things without tables? Rodrigo Tetsuo Argenton^m 14:09, 27 December 2012 (UTC)Reply

You are missing the main question, I think. Why do we need this sorting option? Most columns of your tables are not a good sorting criterion because sorting by address or phone number makes no sense. The "type" field, which is the one you want to introduce, is vague... just vague. Try to use it for Staraya Russa, for example.

Once again, we are not writing a guide to restaurants. We do not try to mention hundreds of restaurants that will indeed require additional sorting options. We only need 10-15 eateries, preferably with different profile, and we want people to read through their descriptions. --Alexander (talk) 05:00, 28 December 2012 (UTC)Reply

Look the "adress", alias, sort by "adress" and you will understand... And when I want to read, I want to be able to choose the restaurant, or the place that I go to sleep. You divide by values, I'm just giving the reader the option to select for what he wants. You are not omniscient, you do not know what all readers want. And the description is still there, as the biggest highlight. Rodrigo Tetsuo Argenton^m 16:16, 28 December 2012 (UTC)Reply

Useless. Sort by address would take the street number from the address and alphabetise it without looking at the street name, the town or district, the country or anything meaningful. A list with "1 Main Street", "10 Fifth Concession Road", "3 Main Street" would sort into that order alphabetically by number (anything with a leading 1 in the number first) without recognising that 1 and 3 Main are adjacent businesses (and both in the city centre) while the concession road is miles/km away in farm country. The same is likely true of telephone numbers, where a leading +1-212- isn't necessarily anywhere geographically near +1-213- just because they only differ by one digit. Splitting listings by district or by price range makes sense, but an alpha-sort on leading digits of an address or phone number is often pointless. K7L (talk) 17:20, 28 December 2012 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Of course it is useless sort by phone, but you want to remove this? You are talking nonsense... And it not written "address" click here to see. Rodrigo Tetsuo Argenton^m 04:15, 29 December 2012 (UTC)Reply

It's not written "address"? That could be awkward, as the information usually comes from sources that do use the street address format "139 da Silveira Street" and not district-first "Lagoa da Conceição - Rua Rita Lourenço da Silveira, 139". The information will likely be cut-and-paste from a page like hotel.example.com/contact.html and won't be "District, street name, number" unless someone manually does this to every entry. In many cases, the district isn't provided; hotels are terrible for claiming to be near every landmark in the city and a few in the next town instead of being precise. K7L (talk) 04:26, 29 December 2012 (UTC)Reply

The way I see it, there are only two fields one might reasonably want to sort on: name and price. Name is already our default sort order, and price is why we divide them up into "Budget", "Mid-range", and "Splurge". Anything else is a red herring. LtPowers (talk) 15:01, 29 December 2012 (UTC)Reply

We might also want to split them by subtype, "hotel"/"motel"/"gated resort"/"B&B"/"campground" or "café"/"pizzaria"/"Chinese buffet"/"French restaurant" or "blaring disco"/"old-style British pub"/"winery". Then again, maybe that split should be being done first, before the price comparisons. K7L (talk) 16:33, 29 December 2012 (UTC)Reply

Yes. We basically give editors some freedom to decide which subtypes are appropriate (if any). Personally, I think that only one of the splittings should be applied: we either provide 10-15 places for each price category, or 3-5 places for each subtype, without any price categories. This gives 30-45 places in total, which is close to the upper limit of a comprehensible listing. --Alexander (talk) 17:23, 29 December 2012 (UTC)Reply

As you pointed out earlier, though, "subtypes" are ambiguous and hard to apply consistently. LtPowers (talk) 17:52, 29 December 2012 (UTC)Reply

Yes, and I still think so. In my opinion, the listings in only ~10% of our destinations may be reasonably split according to their type, although it does not mean that these 10% really deserve this type of the splitting. --Alexander (talk) 20:46, 29 December 2012 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
I've traveled a little, but I really know differentiate, local food, Italian food, steakhouse, fastfood, vegan restaurant, vegetarian ... But again, one more time, we are not discussing content, but using tables. And I already said that the templates are divided by countries, and is a beta, if they want to put by district, neighborhood, love, doesn't matter, you can modify later.
The good points: is easier to read (is sortable), optimizes data organization, and makes clear the items that are missing, negative points is that it is ugly and you do not like. Rodrigo Tetsuo Argenton^m 21:52, 29 December 2012 (UTC)Reply

You claim it's easier to read, but I dispute that. Tables are good for numerical and concise data; they are absolutely horrible for long passages of multiple sentences, and for variable-length data. LtPowers (talk) 02:42, 30 December 2012 (UTC)Reply

Links to Wikipedia#Different subject

Latest comment: 12 years ago33 comments10 people in discussion

Note: This discussion (down until the page break) has been imported from Wikivoyage-old.org/gerneral. User names do not necessarily correspond to Wikivoyage users, although most are now active on WV with the same username. A full list of contributors for this content can be found here.

Existing policy: Links to Wikipedia#Different subject| Different subject Links from Wikitravel articles to Wikipedia articles which have a different subject conflict with the Wikitravel:External links guidelines. They are generally considered "secondary sources" and therefore should be avoided.

The traveller may not be on-line when they read a Wikitravel article, so a link to Wikipedia (or anywhere else) won't be of much use to them. Wikitravel articles should be as complete as possible in and of themselves. Essential information about a topic should be included in the Wikitravel article.

To make a link to a Wikipedia article that will appear in-line, put a colon in front of the "WikiPedia", like this: WikiPedia:Article title on Wikipedia. Note that this type of link is not permitted in the Main namespace.

Proposal

To change the policy on External links to different subjects to allow Wikimedia Foundation project links (probably mostly to Wikipedia, but possibly also to others):

To allow the use of {{further}} or {{see also}} type links to WMF articles which are larger than would be appropriate in the travel guide, provided that a suitable summary is included in the travel guide article.
To allow the use of in-line links to WMF articles or sections where inclusion of encyclopaedic information which is relevant to the travel guide article is inappropriate for direct inclusion.
To develop a policy and guidelines for the scope of WMF links appropriate in the travel guide. This may vary for the different article types.

Motivation

We are constrained to write articles on travel topics within a fairly narrow band which specifically excludes "attractions". Some attractions are sufficiently complex to justify a major encyclopaedic article on WP, but still do not qualify for a travel guide article. It is a disservice to the traveller not to link to the encyclopaedic article if we can not provide the information in the travel guide. It would not make sense to me to basically rewrite several Wikipedia articles inside a single destination article, or fail to provide the information on a technicality. Links to matters of interest for a destination such as the local ecology/wildlife and geology could be added for the eco-travellers amongst us - something that is missing at present. There are a large variety of attractions that are better described in detail in an encyclopaedia.
This will allow information on living people to be referred to without the need for inline citations.
We are not in competition with Wikipedia, Some material of value to the traveller is best presented in an encyclopaedic format, and this does not belong in the travel guide. Similarly there are articles on Wikipedia which is constantly being challenged for original research, which is travel related and should logically be transferred to the new travel site. A greater freedom to link between the projects will be useful to the traveller, helpful to the travel guide writer, and foster a spirit of co-operation between the projects. • • • Peter (Southwood) ^(talk): 08:22, 2 September 2012 (UTC)Reply

Examples

London Westminster travel guide attractions:

London Bloomsbury travel guide attractions:

Diving the Cape Peninsula and False Bay local geology:

Scuba diving Stay healthy:

Discussion

I think that links to Wikipedia articles are a good idea, but they should generally go to the left column. It has a lot of space and clearly distinguishes between the core travel content and auxiliary information. For example, we could place "See also" under all other toolbars, so that it does not conceal more important stuff.

It is tempting, though, to allow in-line Wikipedia links in the Understand section, where less known historical characters or geographical terms may be used. Personally, I would suggest to try this and enforce the policy in case excessive links to Wikipedia render our texts incomprehensible. Atsirlin 15:55, 2 September 2012 (UTC)Reply

I think we're all in agreement about the left-column links to Wikipedia. The problem Peter is trying to solve, though, is what to do with valuable links to Wikipedia topics that are relevant only to a small section of one of our pages. Our left-column links apply to entire articles. LtPowers 13:15, 3 September 2012 (UTC)Reply

I think that Peter has a good idea. The example he gives of Westminster Abbey is good - the Westminster travel guide has a single paragraph on the Abbey, the Wikipedia article has several pages of history - the sort of stuff that would be good to read before visiting. In this case the Abbey's website also gives the history, but with many attractions this is not the case. I think that links to Wikipedia should be allowed for places in See and Do, but should come after the link to the primary website. However we do risk the danger of too many links being added - I don't want to see every hotel entry linking to the Wikipedia entry for the hotel chain. So Wikipedia articles should only be linked to when they are specific to the place in the travel guide. We may also want to restrict the links to Wikipedia articles that are more than a couple of paragraphs long and are more than 3 months old, to stop Wikipedia articles being created just to be linked to.AlasdairW 22:24, 4 September 2012 (UTC)Reply

I was originally thinking that no links to about businesses should be allowed, but in some cases they might be useful to the traveller. Almost always not, but there should be a policy which describes what we want rather than shading around it by describing what we don't want. That way it is easier to understand, and less likely to lead to strife. Usefulness to the traveller must be the touchstone. Usefulness to an industry or business does not even reach the starting blocks. Starting from that, how do we word a policy?

For a start, the linked article (or section) must have

a) reliable, relevant information related to the subject where the link is

b) clearly useful to the traveller

c) too much to put in the travel guide.

d) The information does not have to be NPOV, but must be fair and must not be business POV.

e) Where the link is to a section, the rest of the article must not be or include a significant amount of material that can be construed to be POV of a business which is likely to profit by the exposure. (this one needs work) • • • Peter (Southwood) ^(talk): 05:56, 5 September 2012 (UTC)Reply

[unindent] Hold it, I don't get this: "I was originally thinking that no links to businesses should be allowed." Links to business sites are fine when they're primary links, such as a link to a hotel's website in a "Sleep" listing for that hotel. Where else are you contemplating a business link? Ikan Kekek 02:41, 6 September 2012 (UTC)Reply

@Ikan Kekek, I am referring to WP links here. No conflict with primary link policy as exists. • • • Peter (Southwood) ^(talk): 20:18, 7 September 2012 (UTC)Reply

I wouldn't call links to Wikipedia "links to businesses." Ikan Kekek 02:40, 8 September 2012 (UTC)Reply

You are quite correct. I should have written "links about businesses", which is what I meant. • • • Peter (Southwood) ^(talk): 04:44, 8 September 2012 (UTC)Reply

OK, I get it now, and we are in full agreement. Wikipedia links or other inter-wiki links should be about "See" or "Do" attractions for which primary links are insufficient, for instance, and some aspects of history that could be mentioned in "Understand." Wikipedia links about "Sleep," "Eat," and "Drink" links that are not also important attractions per se (such as the Chateau Frontenac in Quebec and the Raffles in Singapore), or indeed such links to "Do" listings that are mainly commercial (e.g., tours) should be expressly prohibited. The only tricky (though doable) part would be phrasing. Ikan Kekek 11:09, 8 September 2012 (UTC)Reply

I think this is a good idea. The policy should probably also include information on when a link is appropriate -- e.g., attractions and Understand sections, but like AlasdairW said above, I don't want to see links to hotel chains.

One question too -- are we only considering links to Wikipedia for this policy? I'm not sure since points a) - e) seem very general. - Shaund 15:34, 5 September 2012 (UTC)Reply

I was thinking of any appropriate Wikimedia Foundation project in general, but Wikipedia in specific, as I can't think of any examples for other WMF projects offhand. • • • Peter (Southwood) ^(talk): 21:14, 5 September 2012 (UTC)Reply

I still see a lot more harm than good to in-article links to WP. I love WP and hope that people do look for information there about subjects that they want to research, but I'm also pretty confident that they don't need much more help to find it! On the other hand, I find that non-tech-savvy folks have a tremendous amount of difficulty differentiating our project from Wikipedia, both when I show them the site, and when I try to explain in words what it is. (It shouldn't be too hard: "what Wikipedia is to encyclopedias, Wikivoyage is to travel guides," but somehow that needs repeating a dozen times.) Linking to WP articles just like we link to our own would further muddle things for people who are discovering what we are about.

My second worry is just that linking topics can encourage laziness. To really provide a value added service to mankind, we can't ride on the coattails of our bigger, older cousin—that's why we also disallow copy-pasting any significant amount of text from WP, despite it being OK per the copyleft—we need to encourage people to write. And to write for our purposes, which drive us to a significantly different format. --Peter ^Talk 18:22, 7 September 2012 (UTC)Reply

We will be part of the WMF. It seems churlish to shun them.

There are things we can do on WP which we can't do on the free travel guide and vice versa that are complimentary. If we link directly following an agreed policy, the user gets directly to the place the travel guide writer identifies as appropriate. If we can make the link an open in new tab/window, then the user gets back to the travel guide where they left without losing their place. Overall a more user friendly system to my mind. • • • Peter (Southwood) ^(talk): 20:18, 7 September 2012 (UTC)Reply

Who's shunning anyone? Even on WT, we gave a prominent left-column link to Wikipedia. Like Peter, I'm not clear on why this is needed. I guess I'd like to see a mockup of what an article would look like with these links to Wikipedia. LtPowers 20:33, 7 September 2012 (UTC)Reply

I think there needs to be a special policy topic (read:separate page from external links policy) related to in-line links to other Wikimedia projects. I don't have much to add other than to say that links to WP are very useful in cases like Westminster Abbey above. An example of linking to a WM project other than Wikipedia would be linking to appropriate books (per our read/books policy & old enough to not be under copyright) on Wikisource. Examples I could think of would be The Travels of Marco Polo for China & Asia pages , Heart of Darkness for the DRC . Additionally, there may be a few books on wikibooks that could be useful to an article, mainly history and languages (for phrasebook pages). I'm not sure of the advantages of linking to history books on wikibooks (only European, NZ, & US history books are complete) vs. articles on wikipedia, but both Wikibooks and Wikisource content can be downloaded as a PDF to take on a Kindle, iPad, or other e-reader (just expand the print/export options in the left colummn)!! Very useful for travelers who use those devices. In fact I think that would be a good feature for Wikivoyage to add! I'm not 100% sure about this, but a link to Commons (in left column, not in-line) would be useful to browse photos/media for a destination. This wouldn't for for all destinations (like "United States"), but for off-the-beaten-path ones this could be useful. It would be like heading over to Flickr and searching for "Cape Town" or "Kakadu National Park" and doing some armchair traveling/fantasizing (:D). AHeneen 21:01, 7 September 2012 (UTC)Reply

I agree with AHeneen. It makes much more sense to me to interlink different Wikimedia sites as appropriate, rather than discouraging links, and it's collegial toward what will be our sister sites. It's of course true that there are places where there is no WiFi and no cell phone signal, where links won't be accessible, and therefore, making all articles worth printing verbatim remains an important goal for the travel guide. However, in many, many places, and increasingly, websites will be accessible to travelers, and well-chosen links do not have to be mere signs of laziness, but instead, excellent citations/places to read more. I believe online referencing and links are the wave of the future, and that the move to Wikimedia should provide an impetus for an intelligent overhaul of our links policy. Ikan Kekek 02:40, 8 September 2012 (UTC)Reply

If I'm not mistaken, the other WMF projects also do not have in-article links to articles on other WMF projects too—links are kept at the bottom external links section. I'm pretty sure the reason for that is simply that it's confusing. Readers are used to navigating a single wiki via wikilinks, and are not expecting to be bounced around to other sites. --Peter ^Talk 15:02, 8 September 2012 (UTC)Reply

Occasionally, interwiki links to Wiktionary are found in Wikipedia mainspace prose, but I believe WP prefers to avoid them where possible. Commons very frequently links to en:wikipedia in image descriptions. But you're right that interwiki links are rare outside of the external links section and talk pages. LtPowers 15:18, 8 September 2012 (UTC)Reply

Let me then suggest a clarifying solution: Footnotes. Inter-wiki links should be footnotes, rather than inline links. But the fact that other wikis aren't using very many inter-wiki links within articles (whether inline or as footnotes) doesn't mean we shouldn't. We can be the pioneers. After all, aren't we the travel wiki? :-) Ikan Kekek 22:25, 8 September 2012 (UTC)Reply

As I understand it, links to Wiktionary are entirely acceptable and not discouraged in MP main space, as there are large numbers of words used which need definition but are not appropriate for a full article. A new WP policy for linking to the travel guide will have to be developed when the site is up, and it would be helpful to have our side in order.

Footnotes could be an effective way of handling inter-WMF links, and possibly other links. How do you propose linking from text to the footnotes? • • • Peter (Southwood) ^(talk): 18:54, 9 September 2012 (UTC)Reply

I would propose that footnotes work the same way they do in Wikipedia: You click the footnote, it takes you to a footnote section at the bottom of the page, and then you can click the inter-wiki link from there. So it would be a section at the bottom of the page, just one linked directly from the body of the page. Ikan Kekek 18:03, 10 September 2012 (UTC)Reply

That would be acceptable to me, but I am open to other suggestions. • • • Peter (Southwood) ^(talk): 18:44, 10 September 2012 (UTC)Reply

I'm open to other suggestions, too. Ikan Kekek 04:30, 11 September 2012 (UTC)Reply

Footnotes might be a good idea in some cases. I think the link to the article covering the same destination on Wikipedia should be in the column at left (just like at WT). A link to the category on Wikimedia Commons could also go in the left column. One option would be to use a different color for links to other wikis. This would be hard to do as I can't really think of colors that would go well without being too colorful/flashy and go well with blue. Using different shades of blue might not be enough for readers that aren't paying much attention, don't perceive subtle differences in color well (like elderly) or when accessing WV on a device with low color contrast (like a cheap cell phone or ereader) or in bright sunlight. Another option would be to put small images (like the email envelope or phone # phone on WT listings) of the Wikipedia, etc. logos next to the link. My preferred option for

Note: I'll probably move this to a different page later (like new tech features or new styling) since the following kind of goes off on a tangent. But my preferred method is part of changes to some of the templates we use, where listing templates would add the option to link to a Wikipedia page. This would mainly apply to the see/do sections. I think the templates for see/do/eat/sleep could get a makeover to make them look sleeker (if all the info is present, this could be a couple lines of text on a computer, much worse on a smartphone) by using images and hiding some of the information from being displayed. Let me give an example before explaining. For Westminster Abbey, the listing on WT Westminster begins ([6]=website):

Westminster Abbey, (tube: Westminster), ☎ +44 20 7654 4900 (info@westminster-abbey.org [email envelope], fax: +44 20 7654 4894), [6]

My idea would be for a listing that would look like this:

Westminster Abby ([tube] Westminster, [Bus] ?, [Wikipedia], [Website], [phone], [email envelope], address [Open Street Maps])

In this format, the brackets would all be small images: Tube logo, a bus symbol, Wikipedia's "W" logo, some sort of symbol that would be used for official websites(replacing the [1] arrow only in templated listings, not elsewhere in article), the (existing) phone symbol, the e-mail envelope, & OpenStreetMap logo. The only text that would show is the mass transit stop & address. When you click the phone or email images the phone #/email address would be displayed to the right of the image. The info would also be displayed by hovering the mouse over the image (on computers). It would be really great for our site's functionality if clicking on those images when using a device like a smartphone (either through the "mobile" site or an official app) would bring up a small overlaying window with the phone number (or email) and ask "Call [ph. #]?" or "Email [email address]". The Wikipedia logo would serve as a link to the corresponding WP page...opening in a new tab on a computer. On a smartphone/tablet, this would bring up a prompt (Visit [name] on Wikipedia? "Go" "Cancel") just in case it is pressed accidentally (due to charges/limits for data service on mobile networks)and then bring it up in a new window. There would be different mass transit icons for bus, (light) rail, & metro/subway. In some locations, the icons would be changed to reflect those of the official mass transit lines...like for Westminster Abbey, in London, the Tube...but ONLY if those images are not protected by copyright or otherwise permitted to be used freely (I think this was done with some of the routebox navigation). The bracketed number followed by an arrow is rather dull and, for those who might not be used to wikis, not intuitive that this means a website. So, a new website icon could be created for use in listing templates (it wouldn't be used elsewhere on the page). Clicking this would open the website in a new window (smartphone/tablet users might be prompted "Visit [website url]?" "Go" "Cancel"...again, to prevent accidental clicks). Finally the address could be displayed a combination of description ("Corner of 1st Avenue and Main Street"), physical address (which could be hidden by an image [1234] or by "Address" and displayed by clicking or hovering over it), and coordinates (hidden under a logo...maybe use same as WP...and displayed when clicking/hovering on it, see WP WikiProject Geographical Coordinates for ideas on incorporating into WV). The address/coordinates can be used to link to a mapping service/website via an image/logo (OpenStreetMaps may be best, because of licensing, when compared to commercial services) on smartphones/tablets, clicking on the image would prompt the choice of service ("OpenStreetMaps" + what the device uses...handled on the phone OS side, like if you have two programs doing the same thing on an Android device, you click an address and a window pops up for you to choose which to use...this wouldn't be for WV to know/link to other services). If a part of information is not provided in the listing, then the icon is not displayed (eg. no phone #, no phone icon shown).

To put this in perspective, the current WT attractions listing template is:

<see name="" alt="" address="" directions="" phone="" email="" fax="" url="" hours="" price=""></see>

A new template might look like this:

* <see name="" alt="" bus="" metro="" lightrail="" Wikipedia="" url="" phone="" email="" address="" directions="" coordinates="" hours="" price=""></see>

For offline electronic use (which is a topic that needs to be brought up elsewhere), the information would be fully displayed except websites which can get messy when longer than http://website.com (could be "Link" underlined). Wikibooks & Wikisource allows pages to be downloaded as a PDF (to view on computer/tablet/phone or loaded on e-reader), which is something WV should get when we move to WMF, in which case websites would need to be displayed in case printed or needed to enter in an internet cafe. We could also see if WV could get an official phone/tablet app some developer could volunteer to create that could keep the same formatting as the online website, but allow downloads for offline use.

Outside of templated listings, there's only a couple other common places where inter-wiki links would be used/appropriate. Since regional/country-level pages don't use listing, but rather paragraphs of text, WP pages could be linked by adding a template after the name of an attraction/etc. So in the middle of a paragraph you would see "Westminster Abbey [W]" (where W is the Wikipedia "W" logo) which would be done by typing "Westminster Abbey {{Wikipedia:Westminster Abbey}}" a template that could be added to the toolbox you see when editing. Links to other WMF wikis could be done similarly. AHeneen 00:35, 10 September 2012 (UTC)Reply

I see you have given this some thought. I like your suggestions for the see/do templates, and suggest that the tourist information "i" icon may be the one for the url to the official website.

Colours can be problematic for accessability reasons, I have been running into this problem on WP.

Links in the left column can only be generic to the whole topic. There would be no way to indicate that the link is specific to a particular detail. In-line or footnotes can do this, as there is an indication of relevance inherent in the placing of the link in the text. Ideally a plain link would be internal to the travel guide. External links outside of WMF would generally not be allowed in the body text. Links to WP are the most likely to be wanted. They could be handled as footnotes with the usual superscript number in square brackets, and information in the references section at the end of the article which is standard WP procedure and the software and templates already exist, or alternatively a ^[WP] indication that the link is to WP. This has the advantage that attempted links to external sites would be more obvious.

I also like the idea of a dialog box to check that the user wants to open a new site, and suggest that it should default to new tab or new window so you can find your way back easily, by closing the new tab/window. • • • Peter (Southwood) ^(talk): 05:37, 10 September 2012 (UTC)Reply

I also like the ideas for the See/Do templates and added usability for mobile phones. We already have lat and long tags (which are rarely used) so maybe those could help with the coordinates? I think I'd also prefer to display the phone number along with the address and name... it still seems pretty useful to me but I might be old-fashioned in this. As long as the information prints, I'll be happy.

I'm still not convinced about footnotes or in-line citations in Understand (or similar sections) though. Both seem (to me) to be heading down the path of verifying specific facts in our articles. Could we accomplish a similar thing by having a See also: [[Wikipedia article name]] for further information at the top of the section/sub-section (similar to the way WP calls out Main articles)? -Shaund 03:36, 11 September 2012 (UTC)Reply

Good idea. And I totally agree with you on phone numbers. It's very important to list them. Ikan Kekek 04:30, 11 September 2012 (UTC)Reply

Great proposal,AHeneenand elegantly worked out in detail. 100% support! --W. Frank^e-mail_talk 13:17, 23 September 2012 (UTC)Reply

Yes, I also agree. However, I'd also like a 'pier' option besides metro, lightrail and bus (for cities like Bangkok and Venice, which have extensive inner-city boat travel). Also, addresses and phone numbers should obviously stay. --Globe-trotter 14:19, 23 September 2012 (UTC)Reply

I'm worried that allowing in-article links to other WMF projects could lead to increased difficulty in managing the influx of brand-new WP contributors we are likely to get after moving to the WMF, and in helping them adjust to a different way of working on content. A predictable argument would be "well, if you can link the understand section to WP links, why can't you link to other external references, which might be better?" More to my main point, though, is that we are a far smaller project, and need to be able to stand on our own two feet. I think there may be ways to improve interproject navigation that doesn't entail extra in-article external links. --Peter ^Talk 18:48, 12 September 2012 (UTC)Reply

I think WP editors are much like WT/WV editors. Some are able to understand policies and consensus, others have to have the concept bludgeoned into their tiny brains. I think the potential gains outweigh the risk, which, though real, is much the same as touts, which we deal with all the time. The vast majority of Wikipedians are reasonable, civil, and constructive, and will not be a problem. They are able to recognise that they are expected to follow the local policies and that WP procedures dont apply everywhere. There will be some misunderstanding, a bit of quibbling, some efforts to change consensus, and a few persistant pests who will eventually be blocked. Then business as usual, (apart from the expected benifits of no IB involvement and better support). The answer to the predicted argument proposed above is simple: Wikimedia projects are all part of a single foundation, so we work together and support each other. Other external references are not. I think most Wikipedians will understand the point. I think we will have more trouble with non-WMF editors on this point, but still don't think it will be unmanageable.
Can you explain in more detail the other ways to improve interproject navigation without in-article links? It sounds like a very nice concept, but I have no idea of how it may be done, so can't comment on whether it would do what we are looking for.
I think you overestimate the numbers of Wikipedians flooding in. I hope I am wrong, because on average they should be more productive than the flood of touts and spammers we usually have to deal with, and which, no doubt, will follow us to WMF. • • • Peter (Southwood) ^(talk): 07:00, 13 September 2012 (UTC)Reply

I think we shouldn't link to WP in-article. It just adds to confusion, as readers will expect official links to a business or sight. Having two links (both to the sight official site and to WP) would be confusing, and contributors would just dump links to WP instead of adding relevant information about sights to Wikivoyage. --Globe-trotter 14:19, 23 September 2012 (UTC)Reply

Note: the above discussion was imported from Wikivoyage-old.org/gerneral. User names do not necessarily correspond to Wikivoyage users, although most are now active on WV with the same username. A full list of contributors for the above content can be found here.

Listings

Latest comment: 11 years ago11 comments6 people in discussion

Swept in from the pub

The admins and programmers of the Wikimedia Foundation do not like the Listings extension because it is not necessary and can easily substituted by templates.

We told them that the see, do, eat and sleep tags are heavily used. I proposed to keep the listings to stay compatible backwards. It would be one of WV's main tasks to persuade the communities to use a template in future, because with no access to the servers we have no influence to the listing tags.

Later if you would have prepared a template we could use a bot to change the tags to templates. Please have a view to vCard at the German Wikivoyage. We told the WMF staff that a turning the listings into a template by a bot right now would cause an outcry at WV/en. --Unger (talk) 07:14, 30 October 2012 (CET)

Being "raised" in the WMF-world of Wikis, I'm actually wondering why "turning the listings into a template by a bot right now would cause an outcry"? For me templates seems like an obvious thing to use over the listings, and I would assume that doing a full conversion using a bot would be rather trivial for someone, who handles bots better than me. Is there any previous history on listings/templates that I am missing out on (and can't find)? In kind regards, Henrik/Heb (talk) 10:37, 30 October 2012 (CET)

I think the long-time users here just prefer not to have to change the processes and practices that have been used since the project's inception. Templates would probably work better, as it allows for manipulation and changes by the normal users and administrators. We were previously trying to change the way listings are displayed, but were gobsmacked as how to do so. Templates would also allow for better categorisation if we needed to. It seems like a no-brainer. JamesA ^>talk 10:55, 30 October 2012 (CET)

I also don't see any problem with introducing the template during the migration, provided that we have time to test its performance. I believe that it is much easier when heavy changes are done in one run. By the way, the vCard template looks great, and it goes along the lines of the recent discussion on introducing new fields and revising our format of listings. --Atsirlin (talk) 11:01, 30 October 2012 (CET)

AFAIK, the main reason for the listings tags was to allow inline editing using the custom form Javascript. Since that's no longer available here, I'm not aware of any obstacles to using MediaWiki templates. But we'd have to ask an old-timer like Evan to be sure. LtPowers (talk) 14:14, 30 October 2012 (CET)

Wikivoyage talk:Listings has some of the background; it looks like Evan wanted to get the listings into an hCard format and was having trouble making it work with template parameters. But it's hard to tell. He started off talking about templates but ended up with the custom tags. LtPowers (talk) 14:23, 30 October 2012 (CET)

Wikipedia does generate hCard microformat from templates, template:infobox person on biographies being the most common example. K7L (talk) 17:08, 30 October 2012 (CET)

At least with the Parser functions it is possible to write complex and fast templates. The most important functions are #if and #switch. At the beginning of Wikitravel these opportunities were not available. With #titleparts you can also explode slash separated strings. To get an idea what's possible to make with templates see for instance the Location map template. There are no performance problems, for instance see Cairo embassies all made with vCard template. It is no problem to created div or table tag based layouts or to select different layout types. To make template specification easily we use the Template Master as developed by the German Wikipedian Revvar. --Unger (talk) 19:24, 30 October 2012 (CET)

Sorry if my question about the performance was confusing. I meant the correct performance of the listings-for-template replacement. Do you think it is still feasible to implement this replacement during the migration? --Atsirlin (talk) 21:31, 30 October 2012 (CET)

I think the replacement should possible because you need only a correct regex to substitute the tags by a template. I am not sure if it can be done at the migration but this would be a good time. But it would be useful to prepare the template. --Unger (talk) 12:50, 31 October 2012 (CET)

What sort of timeframe to create the templates would be necessary to do the replacement as part of the move? I thought the move was happening today. It had been my impression that switching to templates was tentatively thought of as a post-move task, so it may be too late to figure out how we want them to work that fast. (I'd be inclined to a whole set of templates - {{Eat}}, {{Sleep}}, etc. - rather than a single monolithic {{vCard}} if only for the sake of easier replacement of existing listings, though they could also all transclude one underlying formatting template.) -- D. Guillaume (talk) 01:24, 1 November 2012 (CET)

I agree with having separate templates for each category of listing. It shouldn't be any complex issue to change the listings. Couldn't we simply use a bot, or even that replace tool that we've grown to love? JamesA ^>talk 09:46, 1 November 2012 (CET)

Using ReplaceText to change "Get Out" to "Go Next" was incredibly tedious, and it will take just as long (or possibly 5 times as long, unless I can devise a regular expression that will cover all of the listings tags) to replace the listings tags in every article. It's not something I'd be keen on repeating. LtPowers (talk) 13:29, 1 November 2012 (CET)

It makes no sense to have separate templates because all the templates are nearly the same. Within one template you can make also a categorization (giving several types) to distiguish between several types of establishments/institutions which is useful for future transfer to WikiData. With regex it is not difficult to substitute them in one run. When I speak about types I do not think only about see, sleep and do, but also about campsite, hostel, guesthouse, hotel, ...

The best would be to do substitution before migration. But we have no time, and I do not know who should do it. I by myself have no bot and database experience. The advantage to do it now would be our full access to the database. Later we can do it only with a bot because we will have no database access any longer.

Maybe you should start now to program a template. You can also take vCard and make some adaptions. --Unger (talk) 11:45, 1 November 2012 (CET)

Unger, I believe it would make the most sense to have a single underlying template to represent "a listing", with wrapper templates created around it for each type of listing. (For example, create Template:Listing and have it handle display formatting and everything, then create Template:Sleep that uses Template:Listing to generate an accommodations listing.) LtPowers (talk) 13:29, 1 November 2012 (CET)

It wouldn't even need to be a wrapper, as "sleep" adds nothing not already in "listing". Redirect template:sleep to template:listing and be done with it. We do need "listing" generically in any case, as some listings (mostly transportation providers in 'get in'/'get around' or visitor information bureaux) don't fit in the six arbitrary see/do buy/sleep eat/drink categories. K7L (talk) 16:47, 1 November 2012 (CET)

Well I'm still thinking about the details, but there are elements that the different types of tags do not have in common. Listing would have to be written to accommodate all of the possible data, but there are a couple of ways to do that. LtPowers (talk) 18:01, 1 November 2012 (CET)

Actually, they are identical - even where the extra fields are not useful they do still exist. * <eat name="Cockroach Motel" address="13 Skid Row" checkin="they check in" checkout="they don't check out"></eat> gives * <eat name="Cockroach Motel" address="13 Skid Row" checkin="they check in" checkout="they don't check out"></eat> even if the check in/out times are never actually useful for anything but lodging (eateries have hours="open/close time" instead). K7L (talk) 18:30, 1 November 2012 (CET)

I'm speaking conceptually here. LtPowers (talk) 19:14, 1 November 2012 (CET)

Is there any way in which you envision eat/drink see/do buy/sleep, each provided with the same input data, giving different results as output? (For instance, will 'sleep' drop a roof-and-bed icon onto a locator map at some co-ordinate or 'drink' display a coffee cup?) If not, these are just aliases of <listing> as the fields (even if we don't use them) do exactly the same thing in all cases. K7L (talk) 20:06, 1 November 2012 (CET)

It's certainly possible; who knows where we might go with this. Certainly they could be implemented as you suggest as a start; it'd be better than nothing and redirects are easily changed into wrapper templates. My point was mainly aimed at avoiding syntax like {{vCard|type=eat ... }} appearing in articles, which is what I thought Unger was suggesting. LtPowers (talk) 20:34, 1 November 2012 (CET)

The "icon on a map" you suggest could still be achieved with a single template. It'd just be a matter of the icon changing depending on a |type= or |section= field. JamesA ^>talk 06:15, 2 November 2012 (CET)

But that would involve some sort of #if or #switch statement within the template; it would be far easier to write a wrapper template to accomplish that -- and with the added bonus of being more readable to editors. LtPowers (talk) 13:59, 2 November 2012 (CET)

Support conversion to templates, I initiated the microformats project on Wikipedia, and Wikitravel (now see Wikivoyage:Microformats, and would be happy to assist with further deployment here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:17, 18 November 2012 (UTC)Reply

Support I am a long-time user of the XML-style listings, and even wrote tools for them, but I think switching to templates would be better. At term this might even allow the Visual Editor to be deployed on Wikivoyage? Nicolas1981 (talk) 02:49, 19 November 2012 (UTC)Reply

I have written Template:Listing as a start. Do what you like with it! This, that and the other (talk) 09:48, 19 November 2012 (UTC)Reply

Thanks for your input! However, I think that we should postpone this until the cleanup is done, images are back, etc. We had at least two discussions on the format of the listings and the change in their content. We have to go back to these discussions and develop a strategy before putting things into the code. --Atsirlin (talk) 10:00, 19 November 2012 (UTC)Reply

Certainly. I just wanted to show that it is possible, and easy to do, and very flexible. This, that and the other (talk) 10:36, 19 November 2012 (UTC)Reply

Support As I was a bit annoyed by converting vcards into tags from wv:de to wv:en and back, I have written some parser for that. It also handles both directions, vcard to tag and vice versa. It eats any wiki code and looks line by line for vcards and tags in it. The parsing handles the different way of having separate phone country codes in vcards and also fixes missing http:// in links. Listing tags (eat, sleep, see, ...) are currently converted into the vcard types restaurant, hotel, ... which seemed to be common usage in wv:de, but this might need some more adjustments. E.g. it could do easily do some more educated guesses, to convert some drink tagged thingy into a cafe or bar, depending on what substrings found in thingys name. Same for sleep: guesthouse, hotel or hostel. The source code is in this github repository, and a demo for a quick try is currently online here: Wikivoyage vcard-tag converter. Automatic conversion for currency symbols (e.g. VND->dong or vice versa) could also be included easily. If there is some interest in it, I'm happy to invest more time in it. ML31415 Mail Talk 18:59, 10 February 2013 (UTC)Reply

Current status is that our tags are merely redirected to a vCard template, {{listing}}, using the patch in bugzilla:43220. That isn't going to guarantee that the fields in de:'s vcard template match those on en: or ru: — we also still have many destinations which were never converted from plaintext listings to tags (and therefore no templates). K7L (talk) 19:17, 10 February 2013 (UTC)Reply

I've updated the parser with a bunch of heuristics, so it does a quite good job now in also translating unformatted list entries into properly formatted ones. Not yet good enough for running it fully automated, but quite helpful for manual editing I guess. ML31415 Mail Talk 06:38, 15 February 2013 (UTC)Reply

Nice work, Michael and very helpful already!

One thing you might like to consider, Michael, is a switch for the English language Wikivoyage which forces the insertion of null tags like tollfree="" (in line with the recommendation here: "...If you don't know some information, just leave that field empty,somebody else can add those details later. Please do not delete any unused listing fields..." ). Thanks for listening. -- Alice^✉ 07:15, 15 February 2013 (UTC)

Done. Thanks for comment! If you find further issues, let me know! ML31415 Mail Talk 13:07, 15 February 2013 (UTC)Reply

Wow! That was quick! thank you very much, Michael!

1) I see that you've now forced the addition of the tollfree, lat, long, fax, price and hours tags (and perhaps more that I haven't noticed). However, many listing types should have directions and alt tags and some types of listings conventionally have additional tags. For example, "Sleep" listings also have checkin and checkout tags. (I see that your program is smart enough to often guess correctly whether an unformatted listing is a "sleep", "eat" of "do", etc).

2) The order of display for the reader will be handled automatically, of course, but it would be very nice from the human perspective of editors if the null content (and parsed content) template variables were inserted in the conventional order of

* <listing name="" alt="" address="" directions="" phone="" tollfree="" email="" fax="" url="" hours="" checkin="" checkout="" price="" lat="" long=""></listing>.

That way, it's a bit easier for us boring copy editors to spot the listings with missing data when copy editing, Michael.

3) Sorry to be the bearer of bad tidings, but the recent changes may have messed up the way your parser handles data it can not categorise so that it is lost. For example, your Birmingham Buddhist Centre example, when parsed to the tag type of output, is now losing "(#1, #35 or #50 bus)" -- Alice^✉ 20:04, 15 February 2013 (UTC)

Bugs fixed. It's work in progress, so I beg for some mercy, if something is not fully working as intended yet. I also added some buttons to improve the workflow with copy&paste. Now you can also just put a single (section-)edit-url into the field, and it will fetch the data and grab the listings from it. Besides that, I'd suggest to put bugreports to the issue tracker at github. ML31415 Mail Talk 22:41, 15 February 2013 (UTC)Reply

That's a great tool now, Michael and I'm using it already. These will be my last bug reports here.

1) I expected it might choke on the double tadpole (quote) symbol the US and others use for inches when sizing their TV's but there seems to be something else in this example that it doesn't like:

*<eat name="Hollyette's Restaurant & Bar" alt="" address="North Poblacion Larena" directions="in the City of Larena, close to Larena Pier" phone="+63-(0)35-377-2368" url="http://www.hollyette.com" hours="From 9AM" price="" lat="" long="">International restaurant, very clean and always well stocked. Guaranteed best food on the Island of Siquijor. Imported and local drinks. Sports bar with 32" Cable TV. Alternate room reservations at local rate. Domestic flight bookings. Aberration Dive Club. Free WiFi Internet DSL-Connection. </eat>

2)This example chews up the URL for some reason:

* '''Villa Marmarine''' Near Siquijor Town on the way to Larena. It has a decked restaurant and a clean kitchen with very good food. There are grand and unique cottages of various size and cost. All have sea views. The landscaped beach is well maintained and cleaned every morning. There are lots of hammocks and a pleasant garden with soft grass. Free WI-FI. http://www.marmarine.jp/en/index.html

-- Alice^✉ 04:49, 16 February 2013 (UTC)

Ok, I've put these examples to the test list for the next update. ML31415 Mail Talk 01:15, 19 February 2013 (UTC)Reply

Wikipedia links in special tags

Latest comment: 11 years ago37 comments8 people in discussion

This discussion has been swept in from the Travellers' pub.

I propose that we add a Wikipedia parameter to the special tags <see>...</see>, <do>...</do>, <eat>...</eat>, <drink>...</drink>, <sleep>...</sleep>, <listing>...</listing>.

For example, the "<see>" entry for Doxey Marshes on Stafford should include a link to http://en.wikipedia.org/wiki/Doxey_Marshes Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:02, 18 November 2012 (UTC)Reply

I suggest that we first replace the listings environment with a more suitable template(s) and discuss links to sister projects on the dedicated page. --Atsirlin (talk) 23:06, 18 November 2012 (UTC)Reply

If that's going to happen, in the near future, then it would be a good idea to make the addition afterwards and not first; but we can still discuss the policy in the meantime. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:12, 18 November 2012 (UTC)Reply

I'd like to see a listing format in which the name of a landmark is a link to the WP page (if it exists) and the address is a link to the Special:Mapsources co-ordinates. I do not agree with applying external link policies to interwiki WP links. Nonetheless, the listings extension will need to be fixed or replaced first, as it's currently frontlinking the name to the property's own-site URL (which is a bug) and that leaves the name unavailable to anchor the interwiki link.

Using the individual listing as the source of sibling links ensures we have the listing before we link. A printed copy of a city page remains self-contained (the basic info is here) and not merely "see Wikipedia fox X".

The sibling link to a city-level article (in WP) or category (on commons:) can stay where it is (on the sidebar) or be placed at the bottom of the page. I see no harm in the names of airports or highways interwiki linking to WP as those don't get their own articles here except in rare cases (such as Route 66 and Trans-Canada Highway, which exist at itineraries). Anything that's not a city/town, the subject of an individual see/do/eat/sleep listing or tourism infrastructure (such as airports or highways) likely should not be linked. "Good place for salmon fishing" shouldn't be a link to the biological and scientific information for every species of fish in the area, for instance, as WV is not an encyclopaedia. K7L (talk) 05:57, 19 November 2012 (UTC)Reply

I'd like to see coordinates in listings displayed on the page, so that they can be seen, copied, printed, emitted as microformat metadata and, of course, linked to Special:Mapsources. Otherwise, all agreed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:42, 19 November 2012 (UTC)Reply

I am against all external linking from within the article, except for a link to the official site of a listing. Linking to an encyclopedia does not help us reach our goals. It turns Wikivoyage into a linkdump site, discouraging users to add their own content to the articles. Articles should be self-sufficient and not rely on external sources, so all information is available when articles are printed.--Globe-trotter (talk) 13:56, 19 November 2012 (UTC)Reply

How so? If a place has no listing here, there's nothing from which to make the link. That would keep out entries like Coral Court Motel, which has a full page on WP but does not qualify for a WV listing in St. Louis or Route 66. As for including "all information"? That would mean a full page on one motel in this case, if we were to duplicate the level of information in WP. We don't need the name of the original owner and architect of this place here, even were it still open. We include basic info if you can sleep there... the details of the historic register listing on this place can stay in WP. K7L (talk) 14:11, 19 November 2012 (UTC)Reply

I think G-t's point is, if it's important to the traveler, it should be in our travel guide; if it's not important to the traveler, why bother linking to an encyclopedia? LtPowers (talk) 14:32, 19 November 2012 (UTC)Reply

Similar to GT, I think external linking should be minimal at best. There are rarely instances where it is vital. I imagine a "topics" page on WV for links of this sort would suffice, where you can offer links to the official site, wp article, commons, etc. Because choosing what to link to has great variation, a lot could hide behind a blue link if we open it up to external linking. All external links should be clearly noted to where they are taking the reader. When a reader is using our site and clicks on a link, they expect to remain on WV, not to end up at some other site. There are ways to handle this though, through the use of external site boxes (Wikipedia has an article on XXXX) that can be made "no print."

I am totally for external site linking, it is a powerful, helpful, and community building tool that benefits both the site traffic and the reader's navigation, but using a blue link is not the best way to go. - Theornamentalist (talk) 14:45, 19 November 2012 (UTC)Reply

These wouldn't be eternal links, they'd be links to sister projects; we are -thankfully - part of the Wikimedia family now. Not only that but linking is how the World Wide Web is supposed to work. Furthermore, such links serve our readers when I read Wikivoyage, I want to use such links: when I need background information. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:24, 19 November 2012 (UTC)Reply

Nothing requires a blue interwiki link to look identical to an internal link. Mediawiki puts them into their own class (extiw). A link like <a href="//en.wikipedia.org/wiki/Coral_Court_Motel" class="extiw" title="w:Coral Court Motel">Coral Court Motel</a> could be made to appear differently with one line of CSS:

a.extiw { background: url(http://upload.wikimedia.org/wikipedia/commons/thumb/c/c0/Wiki_puzzle.svg/10px-Wiki_puzzle.svg.png) center left no-repeat; padding: 0 0 0 10px; }

If this is generated by a template, the template could also be coded to format interwiki links differently.

A box is overkill. K7L (talk) 14:59, 19 November 2012 (UTC)Reply

Have a look in the discussion above concerning linking to Special:MapSources and providing geocords that are revealed when a pointer/mouse is hovered over something like this^[maplink]. The example used here is a link to a geocord supplied Special:Mapsources page. One of the propositions in the discussion in the section above is that the geocords will display with a mouse hover, a click on the link wiil go to a geocord supplied Special:MapSources page, and if the article is printed then the geocord is revealed on the printed page, maybe looking something like this^[^{8°45′26.36″S,116°16′36.03″E}^] when it is actually printed (of course that long geocord string is hidden by the^[maplink] in normal page view). The example above is a locator for an airport. The provision of geocords and a maplink to a transport hub such an airport, seaport or railway station may provide an attribute of considerable usefulness to the traveller. -- Felix (talk) 15:29, 19 November 2012 (UTC)Reply

In regard to linking to WP articles, except for the couple of examples described above we don't do travel hub articles here. Interwiki linking to WP articles on transport hubs may also provide some benefit in addition to the provision of the geocords. The WP transport hub articles are normally well patrolled and have lots of useful information for the traveller that we often don't provide in a travel article, such as full airline and destination information. -- Felix (talk) 15:29, 19 November 2012 (UTC)Reply

Coordinates should be visible on the page, not in a tooltip (not every device or browser has tooltips), not least for the reasons listed above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:43, 19 November 2012 (UTC)Reply

Comment on WP article linking - Firstly, Wikipedia does not interwiki link in their articles to sister sites. This is mostly true of the other sister sites back to wikipedia. The consensus is that it is not good practice, in general, to link externally, even to a sister site, without a clear notice that the reader is leaving the site. Use of different colors can become futile for colorblind readers, devices which only use black and white which would render a blue or green link both grey. Secondly, how do we decide on where to send them? If we only get one fragment to link, be it Route 6X, is it the encyclopedic article, the media category with images and video, a published (public domain) travellers account, or is it to the official website of said topic?

And to echo what was said by others above, doing this may in turn relieve the writing of vital information at WV when it can just simply be linked. I assure you, I fully understand the power of linking to the sisters, I've worked in many of them for years and would love to soon add a proper "Learn more about travelling in XXXXXX at Wikivoyage" to the Wikipedia article. But in handling these links, there has to be a removal of bias towards any in particular. - Theornamentalist (talk) 17:38, 19 November 2012 (UTC)Reply

Displaying coordinates for every listing in an article would look horrendous, I'm afraid. Coords have to be hidden behind a link of some sort, at least by default. Have you ever seen a professional printed travel guide that prints geocoords next to every listing?

Separately: Links to sister projects are absolutely external links and certainly fall under our Wikivoyage:External links policy. The change in hosting does not change that fact, so if we are to change how we handle them, it is that policy that must change. I don't know why the sister-links discussion keeps getting conflated with the geocoords discussion, but they are separate issues and should be discussed at Wikivoyage talk:External links and Wikivoyage talk:Geocoding, respectively. (There's also Wikivoyage talk:Sister project links.) LtPowers (talk) 20:22, 19 November 2012 (UTC)Reply

I agree about the the coordinates listed at every point of interest. I wonder if a disambiguation-type page for points of interest could be an option. - Theornamentalist (talk) 21:55, 19 November 2012 (UTC)Reply

That wouldn't help anyone. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:24, 19 November 2012 (UTC)Reply

As to displayed coordinates "looking horrendous", that's a value judgement. Comparisons with printed guides are fatuous; Wikivoyage is not a printed guide. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:24, 19 November 2012 (UTC)Reply

Yes, it is. LtPowers (talk) 00:20, 20 November 2012 (UTC)Reply

The emboldening doesn't make your assertion any less false. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:54, 23 November 2012 (UTC)Reply

Look, I don't know why you think you know this project better than I do, but I assure you that one of our explicit goals is to create travel guides that function well in printed form. We do not have a "Wikivoyage is not paper" guideline, because Wikivoyage is paper, at least in part. LtPowers (talk) 03:55, 24 November 2012 (UTC)Reply

Where dd I say I know this project better than you do? Where did I say that to create travel guides that function well in printed form is not one of our explicit goals? Where did I say that we do have a "Wikivoyage is not paper" guideline? I simply said "Wikivoyage is not a printed guide". I invite you to prove your assertion otherwise. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:43, 25 November 2012 (UTC)Reply

You're not making sense. You admit that creating printed guides is a major goal of the project, then repeat your assertion that Wikivoyage is not a printed guide. That's a clear contradiction. LtPowers (talk) 02:23, 26 November 2012 (UTC)Reply

Um, no, it isn't. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:09, 2 January 2013 (UTC)Reply

Wikipedia does link from articles to sister sites; it even has a number of templates to facilitate doing so. Links to Wikipedia could be identified with a Wikipedia: prefix, thus: Wikipedia:Doxey Marshes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:24, 19 November 2012 (UTC)Reply

They link, but they are not inline links. They appear in "External links," in boxes that say "See also.." and so on. Linking in that manner is acceptable in my mind, but inline linking to Wikipedia isn't. - Theornamentalist (talk) 03:08, 20 November 2012 (UTC)Reply

Which doesn't scan very well as prose, does it? LtPowers (talk) 00:20, 20 November 2012 (UTC)Reply

Works for me, and the same could be said of Tel: or Fax: prefixes. But if that's a concern, we could replace the prose listings with tables with cells for such things and a prose column for details. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 20 November 2012 (UTC)Reply

Would it make any sense to turn the Wikipedia link, external link (to the "official site") and lat/long co-ordinates into icons, ie:

<see name="Doxey Marshes Nature Reserve" alt="" address="Creswell Farm Drive, Staffordshire" directions="" phone="+44 1889 880100" email="" fax="" url="" hours="" price="">Wetland oasis and bird watching site.</see>

K7L (talk) 02:10, 24 November 2012 (UTC)Reply

No. Coordinates and link text should be readable, on screen, to humans, for reasons already given. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:43, 25 November 2012 (UTC)Reply

The link doesn't need to be readable on screen. If it did, it would be very cluttered and there's really no good reason for them to be readable. When a WV page is printed, the links become readable text & I would assume this also happens when placed in a PDF book. On a computer, just hover over a link and just about every web browser out there will display the link as text in a box either next to the mouse or in the bottom left/right corner.

Now, as for coordinates, I would like to see them displayed but also agree that coordinates on every listing would look cluttered. Again, hovering over the map will display the coordinates in most web browsers. What I'm more concerned about is how these will be displayed on touch devices (smartphones, tablets) which will likely be used by many travelers...especially a few years in the future as smartphones and touchscreen computers (like many new Windows8 laptops) become even more ubiquitous. Will a user be able to see the coordinates without going to the map when the icon is touched? While this may seem trivial, for a traveler data roaming charges or data use with pre-paid SIM card is expensive and/or can be very slow. Someone accessing WV on their phone in a foreign country may just want to see the coordinates and not be constantly led to a map. On the other hand, the majority of people accessing WV on their phone probably don't want to see all the coordinates and on a small 4-5 in screen, coordinates for every listing would look very cluttered! Of course, there could be the option for viewing preference in the preferences, but this would only be available for registered users when logged-in. Most people who will use WV guides won't be logging in. AHeneen (talk) 03:52, 26 November 2012 (UTC)Reply

How does a reader copy the coordinates they can see when they hover over the icon, so they can paste them into another app or web page? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:14, 2 January 2013 (UTC)Reply

I really like the icon-links and have expressed support in several places where this has come up (WT, WV general, & now here on en.WV), but this is the first time I've seen the WP icon suggested and I really like it. However, the template would look much better if the icons came after the name of the listing. In my opinion, the best order for the listing elements are: name, address, directions, external link, map/coord, Wikipedia, telephone, email, fax, hours, &prices. AHeneen (talk) 03:52, 26 November 2012 (UTC)Reply

<see name="Doxey Marshes Nature Reserve " alt="w:Doxey Marshes" address="(52.816°N, 2.137°W) Creswell Farm Drive, Staffordshire" directions="" phone="+44 1889 880100" email="" fax="" url="" hours="" price="">Wetland oasis and bird watching site. http://www.staffs-wildlife.org.uk/page/doxey-marshes</see>

That does look a bit more cluttered... is there a better way? Also, what of this info needs to be in a hard-copy (printed) version? K7L (talk) 00:25, 26 November 2012 (UTC)Reply

Not sure how to handle the Wikipedia link in printed/PDF version, but otherwise all the other information should be in the print/PDF version. External links and coordinates should be turned into text/numbers to read, instead of remaining a link. AHeneen (talk) 03:52, 26 November 2012 (UTC)Reply

I'm not sure a Wikipedia link is actually useful to someone not online. K7L (talk) 23:46, 26 November 2012 (UTC)Reply

Using tables

Latest comment: 11 years ago20 comments9 people in discussion

Swept in from the pub

I changed some things in articles, including tables, for a simple reason, we could not find what I wanted without tables. And you put a tag that I should not use tables. I do not know where it came from this rule, but I think it's worth reassessing; I think it's not worth we wasting so much time searching for informations, if we can use a table that organizes the information in the order you want to see. Rodrigo Tetsuo Argenton^m 16:51, 19 December 2012 (UTC)Reply

The {{style}} tag that was added was a way to note that your changes differ from the standard Wikivoyage:Listings format used in all other articles. It would be great if you could start a discussion at Wikivoyage talk:Listings about what you dislike about the current format and how you would suggest changing it, but in the mean time the user who flagged the Florianopolis‎‎ article was just trying to call out the fact that the format didn't conform to agreed-upon standards. -- Ryan • (talk) • 17:46, 19 December 2012 (UTC)Reply

Rodrigo, could you explain the advantages you see in the use of tables rather than the conventional style listings? • • • Peter (Southwood) ^(talk): 05:50, 20 December 2012 (UTC)Reply

Listings formats is something standard across all articles. As Ryan and Peter S point towards, though, we're happy to discuss making changes to them. Here's one new idea (of several) from Texugo, for example. --Peter ^Talk 07:01, 20 December 2012 (UTC)Reply

There's also {{listing}} and bugzilla:43220. That isn't a huge change (as listings remain listings, not sortable tables) but it does get rid of the pesky front-linked URL's in the current <listing> tag. I'm hesitant about changes that add whitespace to listings, as the print version does matter, but we do need to leave some room for small-scale experimentation instead of merely "we've always done it this way". K7L (talk) 18:18, 20 December 2012 (UTC)Reply

It's not that "we've always done it this way," it's "we do it this way." Changing how we display listings is very much something on the agenda already. That said, I agree that room for small-scale experimentation is something we really need—but I'm not sure that our destination guides are the right spot. --Peter ^Talk 18:27, 20 December 2012 (UTC)Reply

I would actually disagree somewhat. I think that a lot of the existing Wikivoyage culture was shaped by an environment where for years editors had to struggle mightily against spam and stylistic issues, pretty much to the point where little else could be done. With the new hosting situation we have stronger spam tools, a larger prospective editor community, and people doing amazing things with bots. Given that reality, I think it benefits us to err on the side of allowing new editors to try some different things without scaring them off with "that's not how we do it". It means a bit more work for experienced editors, but the danger would be that the new project gains a reputation as being too authoritarian and at the same time prevents experiments that might lead to a better site.

All that said, we don't want to turn the site into the wild west, but I don't think it hurts us to (for example) allow a new user to try a new approach with a minor article like Florianopolis‎‎ while at the same time encouraging them to explain their thinking on the relevant policy page. The user may have some good reasons for wanting to change things that might be incorporated into existing practice, and if there isn't a consensus for change then hopefully they understand and revert to standard style. In the mean time we hopefully won't be reverting someone's first contributions to the site and thus scaring them away.

This is just my opinion, obviously, but I really do think we need to change our culture to be more inviting given the reality that despite having been a community for many years this is nonetheless a new project in the eyes of those who will be joining. -- Ryan • (talk) • 19:03, 20 December 2012 (UTC)Reply

This section from w:Wikipedia:Please do not bite the newcomers does a better job of saying what I was trying to express (bolding mine):

Remember, our motto and our invitation to the newcomer is be bold. We have a set of rules, standards, and traditions, but they must not be applied in such a way as to thwart the efforts of newcomers who take that invitation at face value. A newcomer brings a wealth of ideas, creative energy, and experience from other areas that, current rules and standards aside, have the potential to better our community and Wikipedia as a whole. It may be that the rules and standards need revising or expanding; perhaps what the newcomer is doing "wrong" may ultimately improve Wikipedia. Observe for a while and, if necessary, ask what the newcomer is trying to achieve before concluding that their efforts are substandard or that they are simply "wrong".

-- Ryan • (talk) • 19:08, 20 December 2012 (UTC)Reply

Then would you say that style tags would be the best way to track experiments like this one? --Peter ^Talk 20:18, 20 December 2012 (UTC)Reply

I think either {{experimental}} (see Template:Experimental), {{style|This is what needs to be changed}} or something else that people can agree upon would suffice to tag the article/section and also point the new user to a place where the changes can be discussed. And again, it's just my opinion that allowing more style issues in low-traffic articles may be balanced against encouraging new users to experiment - I know others feel very strongly about all manner of style issues here, and if style issues become a real problem without a corresponding benefit to new users/experimentation then we would need to revisit this proposal. -- Ryan • (talk) • 20:39, 20 December 2012 (UTC)Reply

I agree we need to leave room to experiment -- even we experienced editors are forced to experiment from time to time as we encounter new things that no one anticipated before. But my fear is having a whole bunch of travel guides that all look different because people were experimenting with them. LtPowers (talk) 00:28, 21 December 2012 (UTC)Reply

How many would you consider "a whole bunch"? For example, there are currently 366 articles that include Template:Style. I would expect that the number of "experiment" tags would be far lower, but if it was a similar number to those tagged with "style", would that be a concern? And if so, do you have greater concerns about "experiments" vs. existing style issues? I think if we could figure out where people's comfort level lie that it could help to define how permissive we can be. -- Ryan • (talk) • 00:49, 21 December 2012 (UTC)Reply

I don't want to be "that guy," but I'm uncomfortable with differences in template between different articles, merely for the purposes of experimentation. It seems to me that, while absolute uniformity is neither necessary nor even desirable in a guide, differences in structure or display style (rather than, for example, prose) should all serve the content of the particular guide at issue, not things like the sense of style of particular contributors. I am very much open to any discussions of site-wide changes, but I think the volunteer patrolling editors need to know what kinds of deviations from established norms do and don't require reversions. And I can already see that this issue will be more important after launch, with influxes of highly Wiki-markup-savvy Wikimedians creating all kinds of tables and inserting them into existing articles they are interested in and new articles they create. A policy discussion is necessary in advance of launch. Ikan Kekek (talk) 01:38, 21 December 2012 (UTC)Reply

(Re-indenting) Here are some thoughts in response to the above.

Wikivoyage uses standard article templates. If a user is changing headings I think reverting and asking the user to propose changes on the template discussion page is fine. In general I don't think heading changes have chased anyone away, and I don't think changing "Understand" to "Things to Know" is an experiment that will go very far.
If a user is changing more than one article it seems fine to ask them to stick to one article and flag changes there as "experimental"; there should be a line between not scaring off new users and creating excessive cleanup work.
If a user is changing a high visibility article (a major city article, a country article, etc) then it seems fine to ask them to instead work in a sandbox. I would suspect that Wikipedia would do the same thing if someone changed a prominent article.
However, when a user creates a new article or template it seems like we could give them some leeway before adding a vfd or merge tag, subject to editorial judgement - you don't want someone using Wikivoyage to create advertisements or non-travel pages, but giving them some leeway and nudging when writing about their hometown seems reasonable.
One example where leniency might be warranted - several years ago a user was modifying UI on an article for a small Latin American town. I don't remember the original edits, but I copied the formatting and applied it to the USA and put it into my sandbox because I thought it was an interesting idea - User:Wrh2/Sandbox. We could have asked the user to move the work to a sandbox, but I'm not sure they were seeing talk page messages and at the same time it didn't seem like it would hurt to allow them to experiment and discuss what they were trying to accomplish.
Similarly, the current Florianopolis‎‎ article uses non-standard listings, but the user making the changes raises some interesting points. This is a fairly low-traffic article, so letting him work on the idea and (hopefully) engaging him in discussion seems like it would be of some value rather than simply reverting to the standard format immediately.
In addition, we've gotten a couple of articles that I don't understand - Topeka/Bikeways/Randolph Avenue and Topeka/Bikeways/Randolph Avenue/Section1/Start. It may be that these are eventually simply deleted, but letting them sit for a bit to see if the author returns and discusses his idea might also lead to an interesting travel topic about biking in Topeka.

In all of the above examples, the reviewing editor could exercise some judgement about how much leeway to provide - experiments in the USA article might be removed immediately, but I think there may be more to gain by allowing some wiggle room in lesser articles, and tagging such articles with an "experiment" tag (or something similar) also provides a way to engage the editor and track such changes without incurring much work for reviewers. Ikan - hopefully that addresses yours (and others) points. -- Ryan • (talk) • 02:20, 21 December 2012 (UTC)Reply

I predict that we'll have a lot more confusion about this after launch, but time will tell. I'll try to remember to start discussions, such as on an article's home page, before reverting, if it seems like something coherent is happening. Ikan Kekek (talk) 08:02, 21 December 2012 (UTC)Reply

I don't think that we have consensus on this point. I appreciate Ryan's arguments, but I do not understand: i) what is the time scale of the "experiments"? ii) who decides which page is appropriate for the "experiments" (I would not like to see some of these experiments in my articles, even though these articles are not of high visibility)? iii) who will clean up the mess? Yes, it starts from 5-10-20 experiments, but it will easily grow to hundreds. Our never-ending cleanup of Shared shows that it is much, much easier to keep things tidy from the very beginning.

More generally, I see the following issues: i) travel content is superior to the style; we need editors who are interested in the travel content, not in bringing their favorite style from Wikipedia. ii) different elements of the style should be congruent. We may have 10 brilliant ideas, but they will not work together, on the same page because they use different colors, different layout, and may even serve same purpose. A small group of experienced editors will do a much better job than an uncontrollable influx of new editors who have vague idea about the goals of Wikivoyage.

I believe that experiments should be restricted to personal userspace. It may be good to coordinate this activity in a kind of Wikivoyage expedition on Development (or do we already have one?), but travel guides should stay travel guides. --Alexander (talk) 09:52, 21 December 2012 (UTC)Reply

I really agree with Alexander on this, though I am willing to tolerate deviations like those in the Florianopolis article if that's what most participants in this thread want. Ikan Kekek (talk) 10:44, 21 December 2012 (UTC)Reply

I also agree with Alexander, we have the user space and the graffiti wall for experimentation. In Wikipedia, they added a link to the personal Sandbox in the upper right corner of the page. Maybe we could add such a link as well, so it's easier for new users to know where they can experiment? --Globe-trotter (talk) 12:00, 21 December 2012 (UTC)Reply

Just to be clear, I'm not suggesting we encourage user experimentation in the main article space. What I would suggest, however, is that when it does happen we give the user some guidance without resorting to an immediate revert, VFD, or other action that is likely to cause them to leave. Quoting w:Wikipedia:Please do not bite the newcomers again: "Remember, our motto and our invitation to the newcomer is be bold. We have a set of rules, standards, and traditions, but they must not be applied in such a way as to thwart the efforts of newcomers who take that invitation at face value." I think that's advice that we might be wise to adopt. -- Ryan • (talk) • 17:18, 21 December 2012 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
"should be restricted to personal userspace"
Not at all! The project is based on the Wiki system if the development is in a private area will not have interventions of others, so the construction process is not collaborative and inclusive, contradicting the model. I have not read everything, only commented that point, I thought dangerous. My views about tables: Wikivoyage talk:Listings#About tables. Rodrigo Tetsuo Argenton^m 21:19, 21 December 2012 (UTC)Reply

Listings tags and links to Wikipedia

Latest comment: 11 years ago200 comments22 people in discussion

Moved discussion from Wikivoyage:Travellers' pub.

It is possible to add links to Wikipedia from a Wikivoyage page to the equivalent on Wikipedia article, but what about from a listings entry? There are many locations in listing in the See sections, like historic buildings and museums, and sometimes hotels in the Sleep sections and events in the Do section, that have their own articles on Wikipedia. It would be useful to add an additional parameter, say wikipedia=, to the listings tags to reference this additional information, while keeping the url attribute for official external websites. --Traveler100 (talk) 10:36, 1 January 2013 (UTC)Reply

Policy to date has been to allow links only to official websites of listings, but I would be very much open to considering a policy change along the lines you suggest. We'd have to discuss its limits, however, as I don't think we want links to the Wikipedia article for Holiday Inn every time one of their hotels is listed in any "Sleep" section. Wikivoyage talk:Listings is probably the most appropriate place to have this kind of policy discussion. Ikan Kekek (talk) 12:53, 1 January 2013 (UTC)Reply

So to Traveler100 or anyone else: Would you like to propose a new policy? As an initial basis for discussion, I would suggest that Wikipedia links are fine to supplement specific "See" and "Do" listings, with the possible exception of tours listed under the criteria listed at tour (but I actually think it would be fine to link Wikipedia articles about tours that genuinely fall under those criteria), and that there should be no Wikipedia links for "Sleep" listings that are not also sights in themselves, as in the example of the Raffles Hotel in Singapore, as shown at Wikivoyage:Accommodation_listings#Avoid_using_images. I would also strongly argue that Wikipedia links should always be supplementary to, and never a substitute for links to the official URL for the listed site or activity. Ikan Kekek (talk) 13:28, 1 January 2013 (UTC)Reply

I see no issue with a 'wp' field in listings under the following conditions:

The link points to a WP article which describes only the specific site or location in the listing, not merely general description of a chain or franchisor. That may mean that the 14-room neon Route 66 w:Blue Swallow Motel qualifies (because of its listing on a national historic register) while the 100th or 150th cookie-cutter w:Journey's End Corporation site (as just another Comfort Inn) does not.
The target article must meet all existing en.Wikipedia standards, including the general notability guideline, and not be unsourced WP:SPAM or self-promotion as defined by WP's standards of neutrality. If the target belongs on WP:AfD, don't link to it.
The "wp" interwiki link is an adjunct, not a substitute for the "url" link to the official site for a landmark (if it exists). The two differ in purpose. WP should be neutral but based on reliable secondary sources, the "official" URL is blatantly promotional but a primary source. (Note: This new field depends on bugzilla:43220 as we need an editable {{listing}} template to be able to create any new fields.)
Neither the "wp" and "url" link is a substitute for including basic info (such as address, telephone, description) in the listing itself. The print version matters. If we can't determine why a listing is in the guide without going online to some other site, it doesn't belong in the guide.

Certainly, there are cases where there is no official URL but a WP article exists; a few memorial parks or statues for the RMS Titanic itinerary currently fall into this category. If WP is the only good description, link to it. Otherwise, keep the WP link but don't use it to displace the primary-source URL or use either as a substitute for getting basic information into the listing itself. K7L (talk) 17:28, 1 January 2013 (UTC)Reply

I like your proposal a lot and think it would both improve listings and help bring the two projects closer together. Strong support from me, once the bugzilla issue is resolved and we can implement this change. -- Ryan • (talk) • 17:41, 1 January 2013 (UTC)Reply

The conditions stated above sound good to me. --Traveler100 (talk) 18:24, 1 January 2013 (UTC)Reply

And to me, regarding the second point, a bot should be used (as on other projects) to remove links to deleted pages; change those to pages that are moved; and flag those that require disambiguation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:23, 2 January 2013 (UTC)Reply

outdented for readability Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:23, 2 January 2013 (UTC) For me the big question is how to display these links unobtrusively. I'm of the opinion that they're generally unnecessary, but I'm willing to tolerate them as long as they don't make our listings look hideous. LtPowers (talk) 19:28, 1 January 2013 (UTC)Reply

A simple icon with link

<see name="La Tour Eiffel" alt="The Eiffel Tower" address="" directions="Métro: Bir-Hakeim or Ecole Militiare, RER-C Champ de Mars-TourEiffel" phone="+33 1 14 52 14 90" url="" hours="" price="" lat="" long="" tags=""> A symbol of Paris and blabla ... </see>

If not the globe then Traveler100 (talk) 20:04, 1 January 2013 (UTC)Reply

A link icon needn't even be that large; something as small as the existing ☎ telephone symbol may suffice:

44.713-75.5091 Fort Wellington NHS, 370 Vankoughnet St, Prescott K0E 1T0 (at Hwy 2 / King St. E.), ☏ +1 613-925-2896, fax: +1 613-925-1536. 10am-5pm May-Oct, closed Tue+Wed except Canada Day-Labour Day. Guarded by red coated soldiers in uniform of the 1812 war era, this strategic fortress defends a key St. Lawrence River shipping route from US attack. (TDD: +1 613-925-2896) $3.90/person.

K7L (talk) 20:13, 1 January 2013 (UTC)Reply

None of those icons (except the phone, which is a character glyph) is identifiable to me at that scale. But Traveler100's proposals are far too large. LtPowers (talk) 22:11, 1 January 2013 (UTC)Reply

I also direct attention to our image use policy, which asks us to keep image use to a minimum. Having two or three png thumbnails on every listing in an article seems excessive. LtPowers (talk) 22:15, 1 January 2013 (UTC)Reply

The policy you cite appears to be discouraging the use of photos in large quantity at the point they become slow to download over a mobile or dial-up connection. Huge image galleries or animations, for instance, could be slow. Character-sized icons like

aren't going to be more than a few hundred bytes each and would only be retrieved once even if they appear in multiple listings. The question of which icons are useful will need to be decided on its own merit, but at this size time to download is really not an issue. K7L (talk) 22:52, 1 January 2013 (UTC)Reply

Why was this page swept from the pub so fast!? Isn't standard policy: "If you see an old conversation (i.e. 'three months [<-and the bold was not added by me] after the last comment in that discussion) that could or should be moved to a talk page" not "If you see a conversation that should be moved to a talk page, move it there as soon as possible". While I agree that this discussion belongs here, so does Wikipedia links in special tags, which has discussed this issue in depth, but is still in the Pub. There was also a discussion on WV-old/General that covered this issue in depth. If anyone feels like the sweeping policy needs changed, please comment on Wikivoyage_talk:Travellers'_pub (not in response to this post), there was just a discussion in July about changing the timing that didn't get much feedback. While an experienced user might know how a watchlist/history works and might be able to find where a discussion has gone, a new user might start a discussion & come back a day later only to see it gone (a "This discussion was moved to Wikivoyage talk:Listings" would have been nice). Again, if any of you disagree with this, comment at Wikivoyage_talk:Travellers'_pub. AHeneen (talk) 23:04, 1 January 2013 (UTC)Reply

Sorry if was incorrect thing to do. I am getting conflicting advice on where to place such discussions. Also apologies for starting a new topic on an existing subject but it is difficult reading through the traveller's pub page as a lot of the content appears to be about migration from an old project.--Traveler100 (talk) 08:44, 2 January 2013 (UTC)Reply

I have added the two relevant discussions from the Pub & WV-old above...have a look. AHeneen (talk) 23:20, 1 January 2013 (UTC)Reply

Back to the discussion on links to Wikipedia.

I think the listing template example shown by K7L is a good idea. A small icon should work, but maybe the Wikipedia W would be better, as LtPowers points out the others are not clear at that size if you are not familiar with what you are looking at. On the general discussion above I think most people agree a free for all linking in general page text is not a good idea, would get confusing what is in project site links and what is not. A specific link in the listing lines would be good. A clear point on connection to sister projects providing additional information that compliments this project. Like the idea of changing the listing to a template from an XML tag, will make it more acceptable to the contributor community. --Traveler100 (talk) 09:06, 2 January 2013 (UTC)Reply

Why is it a good idea? Most of the arguments I've read are like "because we're now a Wikimedia project and it makes our projects come together". Wikimedia does not equal Wikipedia. I don't think there is any coming together necessary, and if anything, we'd also have to come together with Wiktionary, Wikibooks and a range of other projects under the flag of the Wikimedia Foundation.

These links add nothing substantial for the reader looking for travel content. If the content is relevant, then it should be added to Wikivoyage itself. If it's not relevant, then the link shouldn't be placed at all. It's like the Lonely Planet guidebook to Paris starts adding references to the Encyclopedia Brittannica entry on the Eiffel Tower. These are totally different projects with different goals.--Globe-trotter (talk) 22:19, 2 January 2013 (UTC)Reply

"These links add nothing substantial for the reader looking for travel content" That simply isn't true; look at the Aston Hall example, below. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 3 January 2013 (UTC)Reply

Arbitrary break (Wikipedia)

[edit conflict] I really don't like the idea of including wp links in listings tags. It's a big move away from our Wikivoyage:External links policy of not allowing in-article links to secondary sources. I'll break down my reasoning, in addition to reasons spelled out on that page and its talk page (none of which have anything to do with thinking Wikipedia isn't a fantastic resource):

We already link to Wikipedia from every article; 10–50 links to Wikipedia per article would be excessive.
It encourages laziness—if it's already described well there, it's not so important to write about it here.
It encourages users to leave—we're less developed than Wikipedia, and potential contributors might decide to just keep browsing over there instead of working here.
It can confuse readers—our sites have a very similar look, and might not find their way back!
We need to be self-sufficient for printed use.
Readers aren't idiots, and know they can type any word into Google and get the WP result at the top.

Has the earth shifted? Am I alone?

On a slightly different note, I'd be OK with putting non-subject links to Wikipedia in the sidebar. --Peter ^Talk 22:23, 2 January 2013 (UTC)Reply

I think the guidelines laid out above by User:K7L are compelling. Regarding your specific points:

Aside from historic cities, I seriously doubt there will be many cases where there are 50 listings with a Wikipedia article. And in cases where there is a Wikipedia article, in the past we've always said that including an encyclopedic level of detail is excessive for a travel guide.
I somewhat agree, but again, we tend not to encourage anything more than a few sentences in listing descriptions, and there shouldn't be that many listings with a Wikipedia article.
That might be true, but the mantra of the site is that the traveler comes first. I think including Wikipedia links where applicable might cause some people to leave, but IMHO it also does a service to travelers who want detailed info about the Eiffel Tower history or the architecture of the White House.
This point is similar to #3, and provided the link UI is well thought out then I think it would only be a concern for a tiny minority of users.
I think the "printed use" mantra is often brought up at the expense of online use. A user who prints this guide wouldn't be able to click through to Wikipedia, but they also couldn't click through to any other (allowed) link on the page.
This same argument applies to any other link. We're doing a service to users by putting the link there if they want it.

Wikivoyage and Wikipedia are now in the same family of sites, and I think this is an easy way to share branding while also providing users with information that would be too detailed for a travel guide, but still relevant to their travels. -- Ryan • (talk) • 22:41, 2 January 2013 (UTC)Reply

I think both the supporters and opponents of Wikipedia links for listings have good arguments. My point of view would be that there are at least certain cases in which a sight merits a long, detailed Wikipedia article that would be too long and detailed to be included in a Wikivoyage guide for the city where the attraction is. It's in those kinds of cases that including a Wikipedia article would be convenient and useful for some readers who are using their laptops or cell phones and not reading printouts (or who printed out the Wikivoyage guide and the linked Wikipedia article about the attraction in advance). We don't and shouldn't have individual articles about particular sights, except when they are truly huge, like Disney World and Angkor Wat, but Wikipedia can and does have such articles. If you're concerned that there will be too many links to Wikipedia articles, perhaps we could propose that the linked article has to be above a particular length, but I think that would be time-consuming to conform to and police. Or would you all be willing to countenance links if they're only on the sidebar and not in entries? Ikan Kekek (talk) 22:54, 2 January 2013 (UTC)Reply

I'm not sure that we are even able to put more than one Wikipedia link in the sidebar; I think extension:RelatedSites just keeps the last one. That said, there is a huge amount of detail in WP which we might not want in the guide, but which might be of interest to travellers. One landmark building with an extensive history can easily merit a page of encyclopaedic description, but that's not going to fit in the individual listing. We also shouldn't try to duplicate large amounts of info already in WP. Include enough info so that we don't have a blank or unusable description, but the details of how the w:Empire State Building was the "empty state building" when it opened during the Depression are not going to fit into a one or two line listing for the building's observation deck as attraction to "see". K7L (talk) 23:34, 2 January 2013 (UTC)Reply

Ryan has it pretty spot on. Virtually none of, say, w:Aston Hall could be included in WV, and that article rightly doesn't include the kind of info (directions, public transport, phone number) that WV does. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:15, 3 January 2013 (UTC)Reply

I see good reasons to have the two websites/resources, but not necessarily reasons to add 10-50 links per page to each other. And I really do mean 10-50, which is the number of attractions on most complete articles here. Presumably WP would stick to just having one link on some of their articles (geographical points that have a corresponding page here) to ours, rather than linking to, say, :voy:Chicago at every mention of the city on Wikipedia.

To address Ryan's point about #6, a) other links are harder to find, in no small part because they are all scattered about the web, not just on Wikipedia, and b) we already have a link to Wikipedia on every page to point readers towards that resource. I guess there is some marginal value to linking WP for everything in our guides that has a page there, but not much more than linking every listing to a Google search for the term, and I think that value is outweighed by the negatives. --Peter ^Talk 00:53, 3 January 2013 (UTC)Reply

I'm not sure I understand your point about 10-50 Wikipedia links. Using my home town of Culver City, Wikipedia has articles on the w:Culver Studios, historic w:Culver Hotel, and w:Museum of Jurassic Technology. That would be three links, and in all cases the Wikipedia article has more detail than we would include in our travel guides. Obviously cities with tons of historical monuments might have more, but in general I'd be surprised if there were more than 2-5 Wikipedia articles for most average size cities. Are you envisioning this link being used differently than I've outlined? -- Ryan • (talk) • 01:06, 3 January 2013 (UTC)Reply

Re-assessing, 3-30 is a realistic number, in addition to our standard WP link. That still seems like an enormous amount of external links to a single site to have on every article here. --Peter ^Talk 01:36, 3 January 2013 (UTC)Reply

"Enormous" is a value judgement; unverifiable and arguable. The crucial question is, do 30 links - or however many - serve our readers, or harm them?". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:56, 3 January 2013 (UTC)Reply

Dare I ask how big a city would be to have thirty landmarks with both an encyclopaedia article and a Wikivoyage listing for each? (and is that across multiple pages for a huge city broken into districts?) I look at the article for my hometown and "see" appears to be the only section where there's a corresponding WP article for some of the individual listings. The listings where WP has additional info are the university and military college, a few museums and various sites on the national historic register. Nothing to do, eat/drink or buy and nowhere to sleep. K7L (talk) 02:37, 3 January 2013 (UTC)Reply

I'm working on D.C. updates, and the last three articles I've dealt with had 28, 28, and 16. Were it undistricted, the number could be vastly greater. But I think we're getting sidetracked. --Peter ^Talk 03:12, 3 January 2013 (UTC)Reply

I think that Peter is absolutely right! Links to Wikipedia are a huge change to our policy of non-linking to secondary sources. In addition to Peter's arguments, my concern would be the kind of preference for Wikipedia. I know lots of good, carefully done websites that provide detailed information on particular cities, regions, or landmarks. These websites are usually difficult to find, whereas Wikipedia is always #1 in Google. I think that we will do a very bad job by providing trivial links to Wikipedia instead of highlighting other good resources. --Alexander (talk) 04:42, 3 January 2013 (UTC)Reply

The use of Wikipedia as somewhere to place encyclopaedic-level detail on individual landmarks and cite reliable secondary sources is a where to stick it question. The one-page explanation of why some place is on a national historic register doesn't belong here. We want just a brief sentence or paragraph at best. Using an interwiki link allows editors to take information that's too lengthy and detailed for inclusion here (because we're not an encyclopaedia), cite it to reliable secondary sources and link to it as a WP article if it meets their criteria but not ours. We seem not to want free images now as commons: exists for that, we don't want a full encyclopaedia-worthy page on one individual landmark as that's what Wikipedia is for. The article there can cite as many sources as needed. K7L (talk) 05:28, 3 January 2013 (UTC)Reply

Alexander makes a very good point here: "In addition to Peter's arguments, my concern would be the kind of preference for Wikipedia. I know lots of good, carefully done websites that provide detailed information on particular cities, regions, or landmarks. These websites are usually difficult to find, whereas Wikipedia is always #1 in Google. I think that we will do a very bad job by providing trivial links to Wikipedia instead of highlighting other good resources." Is there a viable solution to this problem, as a matter of new policy? Would we want to allow links to Wikipedia or other websites that cover a listing with a treatment of encyclopedic scope or/and detailed historical or/and architectural (etc.) analysis? Would it then be up to us volunteer editors to determine whether one of the difficult-to-find sites he alludes to is better than the Wikipedia article, and delete the Wikipedia link? If so, is that or is that not a good use of our time? Or would we keep Wikipedia links to useless stubs, which as Alexander says, would disserve Wikivoyage readers? I'm beginning to think that it would be best to allow these kinds of links and not restrict them to Wikipedia. But if so, do they risk making entries "too long" (whatever that would mean), and should they therefore be put someplace other than the listings - which could mean resurrecting the "Links" section that is prohibited in our current External Links policy? At what point might it become more complicated and more trouble than it's worth to change our current policies? I would say that I continue to favor more external links, provided they are useful, but any new policy has to address Alexander's points. Ikan Kekek (talk) 07:52, 3 January 2013 (UTC)Reply

I'm hugely dismayed that this discussion has taken the turn that it has. A friend of mine in college changed my life by telling me to say "yes" to things whenever I didn't have a good reason for saying "no", which I have found to be great advice, but in this case we seem to reflexively be saying "no" to something that would be easy to do and benefit readers who want this information, while being easy for readers who don't to ignore. I won't respond to Ikan & Alexander's points about the "most useful" external link as that is a debate we've had in the past on Project talk:External links, but I would like to re-state that we are now a WMF project, many of our community members are going to be Wikipedia editors who would like to at least have an option of linking to Wikipedia articles when available, and I see absolutely no harm in having three (or even thirty) listings with a tiny icon that links to the corresponding Wikipedia article. Think about it - we're arguing about something that will take up less screen real-estate than is used by the far-less useful "fax" number, and the same amount of space as the monochrome "phone" icon. In addition, there are extremely clear guidelines on usage, so it shouldn't be subject to abuse or be difficult to patrol. Since a not-insignificant number of people would like to see it included, and it's easy to do, why aren't we quickly saying yes to this proposal?

We have been given a second chance to create a dynamic travel site with a growing and involved community, but if we're going to struggle to make a well-defined change that benefits and is supported by a not-insignificant number of our readers/editors and has basically no negative effect on everyone else then it makes me far less optimistic about our future. The project needs to be allowed to evolve and grow the community if it is going to have any chance of reaching its full potential, but if we keep saying "no" to new ideas without providing compelling reasons for that opposition then we aren't going to succeed. -- Ryan • (talk) • 16:01, 3 January 2013 (UTC)Reply

Ryan, I am sorry, but your argument will justify any link to Wikipedia in any part of a Wikivoyage article. Wikipedia is a good and reliable source, so why won't we include as many links as possible? We had some ideas on linking historical events, biographies, etc. Eventually, we can link to Wikipedia articles on individual cities and simply suspend writing the travel guide. Nothing personal, but we recently had a similar problem on Russian Wikivoyage...

Personally, I am not against the idea of extra links to Wikipedia, but I would like to avoid any hasty decisions. Linking to English Wikipedia is a very simple and straight-forward solution that may not be good for every destination. English Wikipedia does not cover everything. Russian destinations are better covered by Russian Wikipedia, while Czech destinations are better covered in... German! This is simply another aspect of the same problem: find a good external link instead of adding a trivial link to Wikipedia. --Alexander (talk) 20:15, 3 January 2013 (UTC)Reply

Please read User:K7L's original proposal for this feature. There is a very, very clear set of guidelines being proposed that address every one of your concerns. -- Ryan • (talk) • 20:33, 3 January 2013 (UTC)Reply

Yes, it is a nice policy, but I don't see how it deals with the language problem (which language version of Wikipedia to link to) and I don't see why we can't extend this policy to every part of the Wikivoyage article. As we can't write much about the biography of Winston Churchill, a link to Wikipedia in the History section will be a natural solution. Why not? --Alexander (talk) 04:23, 4 January 2013 (UTC)Reply

Ryan, I see real disadvantages to doing this, whereas the advantage seems negligible. I think there is a good reason to say no. --Peter ^Talk 22:49, 3 January 2013 (UTC)Reply

And let it get lost in all the text here, the big disadvantage is that it removes the incentive for people to describe things that they care about. A lazy link to WP does the job, but fails to provide our readers with useful printable content, and fails our goal of generating value-added content to the web—original writing. --Peter ^Talk 23:02, 3 January 2013 (UTC)Reply

Peter - as you're (hopefully) well aware, I greatly respect your opinion and that of the other longtime editors of this project, but as should be obvious by now, this is a change that I'm willing to fight tooth-and-nail for, partly because I think it's a sensible change, and partly because I think we're setting a dangerous precedent if we're too averse to making changes and are citing vague fears as the only reason for opposition. To quote the relevant section from Project:External links:

We should avoid links to other travel guides, to ensure we have travel information in Wikivoyage, not linked from Wikivoyage. This is an incentive issue; if we have lots of links to other travel guides, we lose the impetus to create our own.

Wikipedia isn't a travel guide, and most of our information won't overlap. Just as we wouldn't expect someone to use the "url" field of a listing as a substitute for a description, it's tough to imagine a listing with a "wp" field that everyone then assumes doesn't need a description, particularly since most listings won't have a corresponding Wikipedia article. Where this field will be useful is for attractions such as those listed in Paris/1st_arrondissement#Landmarks - you could write pages about each landmark (and users have tried to), but a wp link now gives readers who want more information a way to get it while we can focus on the aspects of the sights that are most relevant to travelers.

And if I'm wrong, and the "wp" field is an unmitigated disaster that threatens the very core of everything Wikivoyage stands for, we can simply remove it from the template with a single edit. The worst that happens is that a few people have made some edits to add links that are no longer displayed. This is a sensible proposal, it has well-defined usage guidelines, and little downside (IMHO, no downside) for those who don't want to use it. This project has been given a chance at a new start, with new tools and new users ready to help, so after years of struggling to stay viable I very much hope that we can now be more open to allowing the site to evolve, rather than remaining a place where most change proposals require weeks of discussion and ultimately die after being swallowed up by an unwieldy process. -- Ryan • (talk) • 23:50, 3 January 2013 (UTC)Reply

I fully agree that perhaps our biggest danger as a project is basically lazy resistance to change, a culture that seems to never allow for reconsideration of one's position after first typing it, that sees way too much time devoted to debating trivial issues, and in which lone dissenters rarely, if ever, lower their weapons of mass text in the name of moving ahead.

In this case, though, I just don't see the value. We already have a link to Wikipedia in all articles, which itself links to all the relevant articles we're proposing links to in all listings—the advantage to adding all these links is marginal. WP is more developed than us, and the temptation of contributors to simply link to the squares in Washington, D.C./East End#Public squares instead of putting in the hard work of creative writing is real (that article would have 35 WP links). We've (or at least I've) already seen this done with some regularity even without a WP field. Our previous scourge of hotel marketers was similarly defined by adding listings with almost no content beyond a link to their booking site.

I'm probably repeating myself now, so I'll hang out, read new arguments, and am still very willing to change my mind if I think there is a convincing case made for the added value of an additional 3-30 links per article. --Peter ^Talk 00:40, 4 January 2013 (UTC)Reply

There's a good reason why Wikipedia results appear do highly in Google. Wikivoyage is also now part of the same organisation as Wikipedia. AnThe advantage seems infinitesimally smalldy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:56, 3 January 2013 (UTC)Reply

One thing that I don't understand about the "there are other good sources" angle... if these independent, reliable, secondary sources are so great, why not be bold and edit the Wikipedia page to cite those sources? (WP actually *does not want* unsourced articles or pages sourced primarily to the article's subject.) That way, a WP link here would leave them just two clicks away, without opening the wider question of whether Wikivoyage articles should be directly cited to reliable external sources. We currently don't have an external links section to avoid links to spam from middlemen, travel resellers or links to other travel guides overlapping what should already be here. That much wouldn't have to change (although I would prefer that an editor that uses secondary sources to obtain info for the guide list these on the talk page if they would be useful to the next person editing the same page). K7L (talk) 16:31, 3 January 2013 (UTC)Reply

Unfortunately, it is not that simple. Wikipedia has its own policies regarding external links. For example, they may not allow links to travel blogs that often provide unique and indispensable information. Moreover, adding links to Wikipedia is kind of burying them for Wikivoyage. I don't expect our readers to make two clicks: first to Wikipedia, then to one particular travel-related external link. Here is an example: pictures are vital to a travel guide, but we are restricted to our own pictures (which are few) and to pictures from Commons (which are generally of mediocre quality). I would like to link to personal websites, where people put enormous effort into making good, professional and visually appealing pictures, including those of less known and remote landmarks. I may expect readers to access these pictures via a direct link, but getting there through Wikipedia is nearly impossible. --Alexander (talk) 19:51, 3 January 2013 (UTC)Reply

A travel blog will normally be a city-level description, not an encyclopaedia page on one landmark. As such, it's not the same animal and (were we to link) it's likely not something to link from within one individual listing. Certainly the "cite no external sources" approach is very opposite to WP (and even they would likely question whether a blog is a reliable source, awkward when some sites like route66news.com likely are credible in their one narrow area of expertise). K7L (talk) 20:20, 3 January 2013 (UTC)Reply

One problem may be that this discussion encompasses both extensively encyclopedic topics like, say, Red Square or Great Wall of China, as well as relatively ephemeral or pedestrian topics like The Bay Queen Street or Turtle Talk with Crush. In the cases of the former, there is an awful lot to say about those topics that cannot be contained in a travel guide; in the cases of the latter, though, is the background information provided by Wikipedia really useful? It may be interesting, but is it really necessary to make sure we have a link to those articles? LtPowers (talk) 20:49, 3 January 2013 (UTC)Reply

First, the current proposal is only to add a field to listing tags - the Great Wall of China may not be a good example since that is its own Wikivoyage article and not just a listing in a larger article. Second, some individuals have already cited examples where they feel that a link to Wikipedia would be useful for getting more background information, so while not everyone would use these links, they are useful to some. Third, even if some users won't use the Wikipedia links, does it do any harm to them to include them in listings, particularly when we know some people will be using them? Finally, for the cases where Wikipedia has an extensive article that contains far more detail than would ever be included in Wikivoyage, should we omit this feature from Wikivoyage listings entirely because Wikipedia articles such as w:Turtle Talk with Crush aren't (yet) very extensive? I'm struggling to understand the opposition to what seems to be a very harmless and unobtrusive change to the site, and am concerned that it is revealing deeper issues in our decision-making processes. -- Ryan • (talk) • 21:15, 3 January 2013 (UTC)Reply

I'm inclined to completely agree with Peter. I think it is a significant change. Many of the arguments that have prevented us linking to secondary sites continue to apply here. It is great to be under the WMF banner with WP, but I don't think we need to get carried away with inter-project links. Best to develop stand-alone guides and content directed at our audience. --Inas (talk) 23:27, 3 January 2013 (UTC)Reply

Ryan, I was not trying to draw a quality comparison between the Wikipedia articles I linked, but rather, a comparison of basic natures of the topics. In other words, while the point about Wikipedia links being useful for important heritage sites, which often don't have their own official web sites, yet have extensive histories worth detailing, is well taken, I believe that concern over other types of listings, of the sort I mentioned (retail stores, theme park attractions, etc.) may be inhibiting acceptance of the proposal. People who might be okay with a link to w:La Brea Tar Pits may balk at a similar link to w:Alice's Curious Labyrinth, but there's currently nothing on the table to distinguish the two.

The other factor is as Inas says: No one has yet made a strong case for why WP links should be an exception to our external links policy. The policy has worked, and worked well, for years, but the only real argument I've seen so far is that "WMF users will expect to be able to link to Wikipedia". I don't know the basis for this claim, but I also don't think it's very strong reasoning, even if it turns out to be true; WMF users may also reasonably expect to post links to secondary sources, but that's not a reason to allow them. LtPowers (talk) 00:23, 4 January 2013 (UTC)Reply

To your first point, if we have a listing and there's a Wikipedia article for that listing then I'm fine with linking to it whether it's for the Tar Pits or a ride at Disneyworld, subject to User:K7L's proposed guidelines. That seems simple, and I think most people would expect that a Wikipedia article on a historic landmark would be more informative than one on an amusement park ride. However, if others feel differently then we can discuss changing the proposed usage guidelines.

To your second point, the primary argument (there are a few others if you read through the discussion, but this has been the main one) is that Wikipedia is a sister site that is the established source for general knowledge information on the web, and thus is an obvious choice as an additional resource for detailed non-travel information for those who want it. We explicitly say that a non-goal of Wikivoyage is to "make an encyclopedia", and when people get too detailed in listing descriptions we always trim them down. Like the primary URL field, a Wikipedia icon is a quick way for users who want a level of information that is too detailed for a travel guide to find it.

All that said, the reason I'm so concerned about this discussion is that this seems like such a simple change, with such a minimal impact on the site, whose implementation and management would take almost no additional resources, that would benefit readers who want to use it, and would obviously be of value to the individuals who proposed it, but the gut reaction from established editors here seems to be to say "we won't even try it" and then list a handful of vague potential downsides such as "people won't put information in Wikivoyage" that seem to me to be little more than excuses to avoid change. If there isn't a significant downside, and there are obvious benefits, why can't we just give it a try? If it proves to be a mistake (and I don't see that it would be) we make a single edit and the links disappear from the site. -- Ryan • (talk) • 01:09, 4 January 2013 (UTC)Reply

There are a number of downsides, and they're hardly more vague than the advantages that have been mentioned. For example, why just Wikipedia? Why not link to Commons categories for every listing that has one? Or Wikinews? "Wikipedia is a sister site" just isn't all that compelling as a reason to change our long-standing External Links policy. Useful links are denied all the time because they don't suit that policy; if the only thing that makes WP links different is "they're our sister site" then I just don't see the point. LtPowers (talk) 01:41, 4 January 2013 (UTC)Reply

The commons categories which would be linked (or not) are subcategories of the category for the city. Categories aren't breadcrumbs; there are means to display and follow the tree downward. Wikinews differs in content from Wikipedia in such a way that a news report might be an isolated incident and nothing more. Odds are, we'd link neither but would link the parent Commons category for the town. As for Alice's Curious Labyrinth? We don't have a listing for it, so we wouldn't link anything other than the levels at which we *do* have listings - which would be the park itself. La Brea Tar Pits is a more borderline case as Los Angeles/Wilshire#Museums has a listing for "Page Museum at the La Brea Tar Pits, 5801 Wilshire Boulevard". If the minimum bar is that the topic be notable enough to have both a listing here and an entire encyclopaedia page there, many potential WP links are excluded by design. K7L (talk) 01:59, 4 January 2013 (UTC)Reply

It looks like we have somewhat intractable opposing parties on this issue. How does everyone feel about putting this to some kind of vote? I see the arguments on both sides, but I think Ryan's argument is ultimately stronger. Wikipedia is in fact the go-to basic encyclopedia on the web, and a major advantage of Wiki Code - in fact, what I believe I understand correctly it was created for - is to have a web of useful links in files. As long as we have a reasonably clear policy, such as the one K7L proposed above, that limits the number and placement of Wikipedia links, I think they will on balance serve the traveller, which is the fundamental point of this site in the first place. All that said, I don't see a huge problem with deliberating on this topic for another several days or a week at most, and I would ask for some patience with the deliberative process taking place here. I don't see it as a fundamental problem that policy changes are subject to deliberation on a site like this, which depends on consensus - as long as, barring a consensus, there is a possibility of putting the debate to a vote, eventually. I don't think we want to emulate the recent behavior of the US Senate, with the minority's constant resort to the filibuster rule, but I don't see that that is happening here. What I do see, though, is that the arguments are starting to repeat themselves, and that's why I am putting forth a proposal for a vote to be taken. All in favor of having a vote, regardless of how you would vote on the proposed policy change, please say Aye; those opposed, No. (I of course say Aye.) Ikan Kekek (talk) 02:15, 4 January 2013 (UTC)Reply

I'm definitely not OK with determining this (or much anything else on-wiki) by vote.

If the primary argument is "Wikipedia is a sister site that is the established source for general knowledge information on the web, and thus is an obvious choice as an additional resource for detailed non-travel information for those who want it," then here's the problem—it doesn't address this issue. I agree that it's a great additional resource. That and the fact that it is a sister site are compelling reasons to link to it. But we already do link to it on every page. The argument that's missing is why we need more links to it. --Peter ^Talk 02:55, 4 January 2013 (UTC)Reply

It is the usual deal. Those wishing to make a significant change need to build a strong consensus built on good reasoning. I don't see that emerging here. Can someone summarise the arguments in favour, because all I'm distilling from this is that Wikipedia is a useful site, and therefore we should link to it. The same argument that has been given for so many sites over the years, and that we have rejected (for good reason) time upon time. --Inas (talk) 03:12, 4 January 2013 (UTC)Reply

So how are policy changes, or even tags (what would on other project be templates), made on Wikivoyage? Is this going to work as the site goes from one run by a dedicated enthusiastic few to one created by a large number of contributors?--Traveler100 (talk) 06:22, 4 January 2013 (UTC)Reply

That's an open question for Wikivoyage talk:Consensus. --Peter ^Talk 06:58, 4 January 2013 (UTC)Reply

First, I'm copying this reply by Alexander, which will be lost in the middle of the thread, here, for the purposes of replying to it: "Yes, it is a nice policy, but I don't see how it deals with the language problem (which language version of Wikipedia to link to) and I don't see why we can't extend this policy to every part of the Wikivoyage article. As we can't write much about the biography of Winston Churchill, a link to Wikipedia in the History section will be a natural solution. Why not?" Answer to the last part: Because we would be putting a logical limit on what can be linked to, just one that allows for links to encyclopedic articles about entries ("See," "Do," and a few notable "Sleep" and such-like entries) as well as entire articles. The alternative to allowing only one link to Wikipedia doesn't have to be allowing links at any possible point in every article. Answer to the first part: Each language of Wikivoyage would link to the Wikipedia article for the same language, on the basis that most users of a given language's Wikivoyage pages will be able to read at least that language but perhaps not others. If that language's guide is not the best, that is no different from what happens at times with links to Wikipedia guides about the place the Wikivoyage article is about. As for the reason to link to encyclopedic articles about listed sights, the argument is a pretty simple one, I think: That encyclopedic articles can provide considerably more background and description than is appropriate for a travel guide (unless we decide to emulate the guides of Touring Club Italiano, which describe every building on every street of particular Italian cities, and every artwork in every church, and their guides do not list hotels, so they're specialized), and that a quick link to such encyclopedic articles is convenient for readers. If your counter-argument is that linking to Wikipedia articles about attractions will encourage laziness on the part of Wikivoyage editors, do you think the current Wikipedia linking policy has encouraged laziness? If so, maybe the solution is to have no links to Wikipedia anywhere. But if not, what's the evidence that introducing the types of links K7L has proposed will surely encourage laziness? As a secondary argument, I would suggest that deleting Wikipedia links editors are going to put up will take more of our time than allowing people to put up such links. Ikan Kekek (talk) 05:18, 4 January 2013 (UTC)Reply

Ikan sums this discussion up well, and I've added a quick summary below to clarify exactly what's being proposed. The only thing that I would add is that I'm very, very concerned that we're using far too high of a standard for allowing a change like this one to even be attempted on a trial basis - to be successful the project needs to grow and evolve, but my impression (and possibly that of those who are considering joining this community) is that we've effectively adopted a "guilty until proven innocent" mindset that is hugely unfriendly to even well-defined and well-supported proposals for change. -- Ryan • (talk) • 07:07, 4 January 2013 (UTC)Reply

I feel that we don't understand each other. Wikipedia links in the listings are likely harmless. They may be useful for some readers. Fine. The only problem is that these links ruin our long-standing policy without bringing any new concept of external links.

We add links to Wikipedia articles that are very easy to find
We do not add links to Wikipedia articles in languages other than English, even though these articles may provide additional information, which is difficult to find
We do not plan to link to Wikipedia in the text, although in-line links are more relevant and important. For example, when I read "This Moorish-style building dates back to 1905", I won't understand this sentence without knowing what the Moorish style is. A link to Wikipedia may be helpful here. But I am perfectly fine to read about Empire State Building without any additional, in-depth information that Wikipedia may provide.
We fully ignore other sources of useful information that are well worth highlighting

Altogether, I don't see the logic of the present proposal. Our existing policy follows that of printed travel guides. We link to websites of hotels and restaurants because they provide up-to-date information, booking facilities, etc. We do not give any links for "further reading". Now you suggest that we introduce such links, but only to Wikipedia and only within the listings. Why??? --Alexander (talk) 11:23, 4 January 2013 (UTC)Reply

Alexander, first, I don't oppose linking to other helpful sources of information at all; we just need to establish a standard for which such links we would allow. The standard I would propose is that all secondary links be clearly informative and that the information itself (though not necessarily the entire site) not be intended to market a specific service or product other than possibly the information itself and second-party advertising hosted on the linked site (if any). In other words, secondary links can't be to pages that also function as booking services, etc. Secondly, I don't oppose links for further reading, and the standard I'd propose is that the links be clearly relevant to the subject of the article (that is, the place itself, not some detail of content) and evidently non-commercial. Incidentally, some articles do include suggested reading in them; for example, Italy#Understand includes a "Literature" section (though I see some of the suggested reading focuses on important details like Brunelleschi's Dome, so that doesn't jibe with my remarks about "detail[s] of content" above). Thirdly, I'm in theory not opposed to the kinds of inline links you mention (such as to "Moorish-style"), but in practice, I'm having trouble seeing how to put a limit to them, and question whether we want to make Wikivoyage completely identical to Wikipedia in having Wiki links for every possibly linkable term. But I'd love to see a proposal from you on how to limit the topics of inline interwiki links, such that they serve the traveler and don't just distract the reader with lots of irrelevant links that weaken the identity of Wikivoyage as a travel guide, which I don't think would be likely to happen under the proposed new policy. I look forward to your reply because I believe your counter-arguments are well thought out and are helping us talk through this issue in a logical and constructive way. All the best, Ikan Kekek (talk) 13:46, 4 January 2013 (UTC)Reply

Ikan, I have no good solution to this problem. Ryan reasonably directs me to older discussions that I have not read in full yet. I do not suggest to reconsider the whole policy and allow links to secondary sources right away. I rather ask why we want to make a sudden change that is marginal in nature, but ruins the whole idea of avoiding any links to secondary sources. I have not yet seen a good argument other than "experiment for the sake of experiment", which I personally can't accept. As I don't understand the idea, I won't be able to explain this new policy to other editors. For example, I don't know what to say to a Wikipedian asking me why links to Wikipedia are allowed in listings but forbidden in the text.

Regarding the problem of external links in general, let's discuss it later. I have to digest earlier discussions and phrase my opinion (in case I have one). --Alexander (talk) 18:26, 4 January 2013 (UTC)Reply

I'll look forward to your further thoughts. Take your time; I don't see any reason to rush to a decision on any of this as long as people have more to say. Ikan Kekek (talk) 18:47, 4 January 2013 (UTC)Reply

Alexander - please read through Project talk:External links. There is a long history of discussions about people wanting to broaden how we use external links, but no one has yet proposed clear limits that would allow us to easily police non-primary links. That said, this discussion is meant to specifically address a new field for listing tags that link to Wikipedia. As to which language version of Wikipedia to link to, the proposal is to link to English Wikipedia since that is the only language that we know readers of this site will understand. -- Ryan • (talk) • 15:40, 4 January 2013 (UTC)Reply

Just being "well-defined" is not sufficient reason to make a major change to longstanding policy. As for "well-supported", we appear to disagree on whether that applies to this proposal. It's certainly supported, but "it's useful, and it's a sister site" is pretty weak sauce. LtPowers (talk) 14:06, 4 January 2013 (UTC)Reply

I think this is where my biggest concern comes from - this is a change that has minimal effect on those like yourself who don't plan to use it, and yet "I think it's pretty weak sauce" is essentially enough to block implementation (even on a trial basis) for those who do support such a change and have stated that they think it has great value. If we were talking about something that would require a huge amount of work or a change that would be highly visible then such objections would make more sense to me, but if we can't make a change that requires no additional work and is easily ignored by those who won't use it then I think it's an indication that the processes for evaluating site changes are very broken. -- Ryan • (talk) • 15:40, 4 January 2013 (UTC)Reply

C'mon Ryan, you know full well that, once we introduce this on a "trial basis," it's here to stay ;) And no one really has stated why adding more links (as opposed to one) is of "great value" (I've been waiting). --Peter ^Talk 19:47, 4 January 2013 (UTC)Reply

Reasons given supporting this proposal:

"I think including Wikipedia links where applicable... does a service to travelers who want detailed info about the Eiffel Tower history or the architecture of the White House." User:Wrh2
"My point of view would be that there are at least certain cases in which a sight merits a long, detailed Wikipedia article that would be too long and detailed to be included in a Wikivoyage guide for the city where the attraction is. It's in those kinds of cases that including a Wikipedia article would be convenient and useful for some readers who are using their laptops or cell phones and not reading printouts (or who printed out the Wikivoyage guide and the linked Wikipedia article about the attraction in advance). We don't and shouldn't have individual articles about particular sights, except when they are truly huge, like Disney World and Angkor Wat, but Wikipedia can and does have such articles." User:Ikan Kekek
"Virtually none of, say, w:Aston Hall could be included in WV, and that article rightly doesn't include the kind of info (directions, public transport, phone number) that WV does." User:Pigsonthewing
"That said, there is a huge amount of detail in WP which we might not want in the guide, but which might be of interest to travellers. One landmark building with an extensive history can easily merit a page of encyclopaedic description, but that's not going to fit in the individual listing. We also shouldn't try to duplicate large amounts of info already in WP. Include enough info so that we don't have a blank or unusable description, but the details of how the w:Empire State Building was the "empty state building" when it opened during the Depression are not going to fit into a one or two line listing for the building's observation deck as attraction to "see"." -- User:K7L
"The one-page explanation of why some place is on a national historic register doesn't belong here. We want just a brief sentence or paragraph at best. Using an interwiki link allows editors to take information that's too lengthy and detailed for inclusion here (because we're not an encyclopaedia), cite it to reliable secondary sources and link to it as a WP article if it meets their criteria but not ours. We seem not to want free images now as commons: exists for that, we don't want a full encyclopaedia-worthy page on one individual landmark as that's what Wikipedia is for." User:K7L
"Wikipedia is a sister site that is the established source for general knowledge information on the web, and thus is an obvious choice as an additional resource for detailed non-travel information for those who want it. We explicitly say that a non-goal of Wikivoyage is to "make an encyclopedia", and when people get too detailed in listing descriptions we always trim them down. Like the primary URL field, a Wikipedia icon is a quick way for users who want a level of information that is too detailed for a travel guide to find it." User:Wrh2
" The traveller comes first, and the argument is that this change would be helpful to the traveller, for reasons that I believe have been clearly stated." User:Ikan Kekek

And while I know you said it tongue in cheek, we have reverted changes in the past, and if your fears of users complaining about the icon being confusing since it leads to another site, or of users adding listings with nothing other than a Wikipedia link, become major concerns then I'll fully support reverting this feature. In the mean time, all I'm asking is that if we don't have a good reason to say "no" to well thought out proposals that we try to find ways to say "yes", be it through suggested changes, clarifications, or whatever, but that we don't simply default to "no" without giving actionable reasons for the opposition, and thus kill any chance of allowing changes to be implemented due to a lack of "consensus". -- Ryan • (talk) • 20:15, 4 January 2013 (UTC)Reply

Actually, not one of those points addresses the issue here: we have a link to WP, any Google search will pull up WP right away—why do we need more links? (35 more links to it in Washington, D.C./East End, for example.) --Peter ^Talk 20:41, 4 January 2013 (UTC)Reply

They all address the proposal - we're making more (non-travel) information about the listing subject immediately available to the user via a single icon link. If the argument against this is that you can just Google a subject then we should do away with all external URLs, and I don't think anyone is proposing that. Flip this around: if a user wants more detailed information about the Old Post Office Tower than is provided by our two sentence listing, having a small icon that links to w:Old Post Office Pavilion immediately tells them there is more detailed information a click away. My problem comes from the fact that this seems to be an obvious good, so what harm is done by having that icon there? Why is the article better without it? -- Ryan • (talk) • 20:51, 4 January 2013 (UTC)Reply

LtPowers, the traveller comes first, and the argument is that this change would be helpful to the traveller, for reasons that I believe have been clearly stated. How is that "weak sauce"? Ikan Kekek (talk) 15:53, 4 January 2013 (UTC)Reply

Lots of things would be helpful to the traveler, but we don't do them because they don't actually suit our mission. We don't link to blogs, even if they might be helpful to the traveler. We don't list other travel guides, even though they might be helpful to the traveler. We don't have articles on small airports, even though they might be helpful to the traveler. We don't do something just because it's helpful to the traveler; it also has to promote and improve our main goal, which is to write travel guides. LtPowers (talk) 16:38, 4 January 2013 (UTC)Reply

Linking to other guides constitutes promoting the competition, so it's directly and clearly inimical to the existence and continued viability of this guide. But anything else that could help the traveler but which we don't do should be open for discussion, in my opinion. If it helps the traveler more than not doing it, unless there is a strong countervailing argument, we should do it, or I think we've failed in our purpose. Because if a travel guide does not help the traveler, there's no reason to continue writing it, is there? We can't lose sight of the fact that the purpose of writing the guide is not just to write the guide, but to perform a service to our readers. Captain Obvious, I know, but I like to never ignore the obvious, and I know that it's possible to have too much of a worm's eye view and not enough of a bird's eye view sometimes. That's also why I find myself impatient with efforts to overstandardize abbreviations and the like. Ikan Kekek (talk) 16:53, 4 January 2013 (UTC)Reply

Peter made the argument that he feels this feature might lead to people not adding content to Wikivoyage. To him I responded that we can try this out, and if that fear proves to have merit then we can go back to how things have always been done. Alexander raised a slippery slope argument, but I think that is addressed by the limited proposal of using this in listing tags. The reason I'm concerned with other responses is that they seem to essentially be "I don't want to do it". So that means the discussion is over? We've got a feature that some users clearly believe makes the site better, that has little or no impact on those who don't like it, but our discussion process breaks down because a few people express vague opposition? If that's the case then our decision making process is broken. Decision making by consensus requires arguments that can be addressed, but "weak sauce", "we've rejected that in the past", etc aren't productive and lead me to believe that we've created a "no by default" mindset that is absolute poison for a project trying to grow its community and evolve. If I'm missing something please enumerate the arguments against, and why they outweigh the arguments in favor. -- Ryan • (talk) • 18:10, 4 January 2013 (UTC)Reply

Actually, including the link in the listing does help us avoid articles with excessive detail like w:Watertown International Airport being created here. Give us a line to a paragraph of description, but if you must write an encyclopaedia page that's what Wikipedia is for.

Watertown International Airport (ART^IATA), Dexter NY 13634, +1 315 639-6247 (43.992, -76.021). American Eagle flies twice daily to Chicago-O'Hare.

And no, the "official" site at http://www.watertowninternational.com is of no use at all in this instance so I shall not link it from the listing. K7L (talk) 17:16, 4 January 2013 (UTC)Reply

The official site is =) LtPowers (talk) 18:29, 4 January 2013 (UTC)Reply

Aha! This is the first argument I've actually seen for why we should have more links to WP: that it might encourage users to not add too much content. I'm still more worried about them not adding enough. Could any other supporters weigh in on why we need more links, seeing as we already have one per page? --Peter ^Talk 19:47, 4 January 2013 (UTC)Reply

OK, let me try to look at this problem from a different perspective. Suppose that we introduce links to Wikipedia as part of the listings template. Then I have several questions:

How do we explain that links in the listings template are allowed, while in-line links are not? I have already mentioned that the in-line links are more important because they could clarify the historical and architectural vocabulary, which is essential for understanding our texts. Moreover, Wikipedians may try to add links to Wikipedia everywhere. We need a clear reasoning as to why the links in the listings (and only these links) are acceptable.
How should we deal with in-line references to sights and attractions? For example, I write that "the Reichstag building in Berlin resembles Renaissance Italian architecture, such as St. Peter's Cathedral in Rome" (that's a bit odd, but I try to pick the well-known example). Since many of our readers have no idea about the St. Peter's Cathedral, they will definitely benefit from a link. Should we add a link to Wikipedia (because the in-line reference to St. Peter's cathedral is technically similar to its listing in the Rome article)? Or should we add a link to Rome#See on Wikivoyage?
The listing has no appropriate article in English Wikipedia, but it does have a reasonable article in another language version (for example, wikipedia:ru:Дом-музей Ф. М. Достоевского and many other sights from Peter's star article on Staraya Russa). How should we deal with that?

--Alexander (talk) 19:00, 4 January 2013 (UTC)Reply

The proposal to use wp="" as a field in a listing template is based on allowing for Wikipedia links in the same contexts where we already allow primary-source external links. A listing for the Reichstag would not link to the "official website" for St. Peter's but would link to the German government site. Just trying to be consistent here. I don't know of any existing policy on links to a site in another language; certainly the "official" website for some venues in Québec are in French-only once you leave Montréal/Hull/Estrie/Québec City and go into the boonies - Tadoussac, Chibougamau and likely Saguenay (if we have a usable article, we might not) will certainly encounter that issue on existing external links. K7L (talk) 19:13, 4 January 2013 (UTC)Reply

I would not favor linking to encyclopedic articles in languages other than English. Official websites are another matter because they may at least have recognizable phone numbers, addresses, maps, etc. But I definitely would not expect most people reading articles in English Wikivoyage to be able to read encyclopedic articles in Russian. Ikan Kekek (talk) 19:19, 4 January 2013 (UTC)Reply

(edit conflict) Responses:

Wikivoyage:Links to Wikipedia would still be relevant for inline text links. While that policy page unfortunately does not discuss reasoning, the talk page consensus was that there is a slippery slope argument - we don't have a clear guideline on what inline Wikipedia links are appropriate and which aren't, and since we aren't an encyclopedia we don't want every noun wiki-linked to Wikipedia, even if some links might be valuable. This exact same argument is why the "primary sources only" policy was put in place for external links - there are many external links that might be valuable, but no one has yet come up with a good way to define what is a "good link" versus what is a "bad link".
This proposal is solely for listing tags. For any other inline link the existing Wikivoyage:Links to Wikipedia guideline holds.
The listing tag will be set up to link to English Wikipedia only; an article in a foreign language is of very limited use to someone who doesn't speak that language. See Wikivoyage:External links#Languages for similar logic.

-- Ryan • (talk) • 19:19, 4 January 2013 (UTC)Reply

I am sorry, but your argument "these links are harmless; if you don't like them, ignore" applies to in-line links as well. Some readers will benefit from every noun wiki-linked to Wikipedia, others can simply skip this stuff. Of course, I do not suggest that we go in this direction, but the attitude "introduce not-so-useful links because they are unambiguous; ignore useful links because they are ambiguous" does not sound right.
Same as above. Optimistically, 1% of our readers will read Wikipedia after they get a comprehensive description of St. Peter's Cathedral in the Wikivoyage article on Rome. But when you see the same cathedral mentioned in a travel guide to another destination, you naturally want to know what kind of thing it is. I am pretty sure that most readers who are not familiar with the cathedral will be willing to get more information, either in Wikivoyage or in Wikipedia. But we are going to deprive them of this opportunity because in-line links are not allowed...
I disagree. Links to Wikipedia are introduced for an interested reader, who may (or even should) use Google Translate for getting what he/she wants to know. When I quickly plan my trip, I want to get concise descriptions in the language I know. When I want to know details, I find them wherever they are. Texts in foreign languages are of limited use in a travel guide, but they become indispensable whenever English texts are not available.

--Alexander (talk) 20:11, 4 January 2013 (UTC)Reply

Hi Alexander - in the interest of keeping this (very) lengthy discussion focused on the proposed change to listing tags, can you make any proposals you have for changing the policy on inline links to Wikipedia at Wikivoyage talk:Links to Wikipedia and any proposal for changing the Wikivoyage:External links#Languages at Wikivoyage talk:External links? I think the points now being raised are straying away from the listing change being discussed and might be better handled separately. -- Ryan • (talk) • 22:49, 4 January 2013 (UTC)Reply

My only proposal is that we think carefully about all relevant aspects of the external links policy before allowing any secondary links. If our goal is to have more random links to Wikipedia, your reasoning is fine. But if we want to improve our travel guides by directing the reader to relevant Wikipedia pages, the problems of: i) links in the listings and "pseudo-listings" (like public transport companies in the Get in and Get around sections); ii) in-line links; and iii) multiple languages are all intertwined. Right now I have to say that I do not support the present proposal because it changes the concept of our external links policy without any clear reasoning as to why only a limited number of links to Wikipedia is allowed. Moreover, the proposal fails to introduce those Wikipedia links that could be most useful for the reader.

Of course, I don't care to step back and let whatever consensus be formed without my opinion. Regarding your earlier comment on the decision-making, the discussion is not over. There is obviously a lot of space for further discussion if anyone is interested in it. --Alexander (talk) 06:56, 5 January 2013 (UTC)Reply

A travel wiki would complement, enhance, promote, and support other Wikimedia projects and the Wikimedia community. Cross linking between projects in both directions will help increase traffic, and hopefully contributions, to all sites. Yes you can open up a new browser tab, copy then paste into the search field and with some pages get straight to the correct page but I may have to do another click from a list of search results or disambiguous page. 3 to 7 clicks instead of one. The advantage of adding an icon to a listing is that it shows there is a Wikipedia article with additional information, prompts the reader. --Traveler100 (talk) 21:38, 4 January 2013 (UTC)Reply

I support the proposal in principle. I was wanting to suggest it myself, and was delighted to find someone else had proposed it. As to the detail, I don't have time right now to think things through (busy planning a trip for this week). Sorry this has to be so brief right now, but I did want to at least signal my support for the broad principle. Nurg (talk) 23:51, 4 January 2013 (UTC)Reply

Now what?

First, I apologize for standing on a soapbox with regards to this issue, but it has raised some red flags that I think need to be addressed.

As has happened to a massive number of discussions over the years, as far as I can tell this discussion is now stalled. Summarizing the attempt to achieve consensus:

There is a group of individuals, including many new contributors, who have said that this is a feature that they would find useful and that they believe would improve the guides. A clear set of usage guidelines has been laid out (see "Summary" below). No extra work is required of anyone to implement this functionality, we just need to say "OK".
There is another group of individuals who have essentially said they are unconvinced.

Now what? As I've stated elsewhere in this discussion, I'm at a loss to understand why we're saying "no" to this feature when it would be easy to ignore for those who don't want to use it, requires no additional work, and will obviously be of benefit to those who supported the idea. It's possible I'm not understanding the reasons for opposing this feature (if so, could someone please summarize?), it's possible that we've made "perfect" the enemy of "good", or maybe there is something else going on. However, it leaves me very worried about our ability to implement change.

In an effort to try and achieve some resolution, I'll summarize my own arguments as to why I think this should be implemented, and would appreciate any responses or summaries of reasons for opposition.

Wikipedia is the obvious recognized source on the internet for detailed factual information, and is a sister site. A non-goal of Wikivoyage is to be an encyclopedia, and we discourage encyclopedia-levels of detail from being added to listings, so an icon linking to Wikipedia articles when available is a quick and useful way for readers who want that type of information to get it. Our listings are more useful to travelers who want more detailed information with this link than without it.
The guidelines for implementing this feature have been made very, very clear. We won't have to do extra work to manage it, and a tiny icon is very easy to ignore for those who don't want to use it. If we decide it was a mistake to implement, a single edit to a template will make the icon disappear from the entire site.
To the argument that someone who wants more information could just do a Google search I'd say that argument could be used to justify removing all external links from the guide. The point is that we're making things easier for readers by putting an icon in front of them that says "if you want a level of detail that is beyond the scope of a travel guide, Wikipedia has an article on this subject that provides more information". Since most listings won't have a corresponding Wikipedia article this is a nice shortcut to quickly tell users that more detailed information is available.
To the concern that this feature might encourage readers not to write listing descriptions I would say that I don't personally think that will happen, but we won't know for sure until we try. If it ends up being a problem we can turn this feature off with one edit.
To the concern that some Wikipedia articles are of higher quality than others, I don't believe that there is any harm in linking one of our listings to a less-than-perfect Wikipedia article on the same subject (w:Turtle Talk with Crush was cited as an example), particularly since the Wikipedia article may evolve over time (it's a wiki after all), but I might be misunderstanding this argument.
To arguments about printed guides I would ask how this feature affects a printed guide? Instead it seems like a benefit to online users, and a simple "noprint" attribute can hide the icon for printing so that nothing changes for those using the dead-tree version of the guide.
In response to the points about linking to other language versions of Wikipedia or using inline Wikipedia links, we have existing policies addressing those areas at Wikivoyage:External links#Languages and Wikivoyage:Links to Wikipedia stating that we should link to English sites when available, and that inline Wikipedia links should not be included in article text. That is the current site consensus, and while those policies are of course up for discussion, this is a separate discussion. If the policies on linking to other language sites or inline Wikipedia links are changed we can revisit the Wikipedia link in listing templates, but holding up this discussion based on a desire to see other site policies change makes an already difficult consensus-building process far more difficult.
Finally, I'd simply say that the fact that a number of contributors have said that this is a feature that they feel would be useful should count for something. If someone is saying "no" because they don't personally think it's a useful idea, doesn't the fact that others have stated the opposite opinion mean that at least some people would find it useful? To cite a similar example, I don't use dmoz interwiki links, but if people find them useful I'm not opposed to them so long as I can easily ignore them.

As I've noted many times, unless I'm misunderstanding the opposition to this feature I'm very, very concerned that we've adopted a "no by default" mentality that will make it much, much more difficult for this project to evolve and grow its community. If that is indeed the case, then I'd like to push us to try to change our thinking from simply "I don't support this" to "I would support this if...", or at least change our consensus-building process so that it is a more constructive conversation rather than an unending discussion that generally stalls out without a resolution.

Again, apologies for the soapbox, but I think there is a bigger issue to deal with here, and I'd like to at least try to work through it. -- Ryan • (talk) • 18:24, 5 January 2013 (UTC)Reply

While I could respond to each, I'd just be repeating myself ;) I think your last point is actually the most persuasive. My main reason for opposing is probably similarly vague—it just seems like an awful lot of links to one place that we already link to. Ultimately, though, I'm willing to stand aside, if other contributors really want it (and we'll have plenty of new contributors from Wikipedia who will like the added convenience in getting back there).

I have some more suggestions for how to handle this:

Restrict the wp tags to the See listings, where they would be the most useful and easiest to keep track of.
Make it clear now that links to WP (or elsewhere) will not be allowed in general prose (outside of listings), because that breaks up the flow of the text, and encourages the idea of references.
Don't make me add them to all star articles, because that would be a fairly unproductive use of time ;)
In future discussions, everyone must be more concise, so that they're actually readable to anyone who doesn't follow them on a day-to-day basis.

--Peter ^Talk 18:31, 5 January 2013 (UTC)Reply

Why not on star articles? Would not in Chicago skyline guide a link to the correct Aon Center page on Wikipedia would be useful to those who want more information or see in more detail what it looks like? --Traveler100 (talk) 18:55, 5 January 2013 (UTC)Reply

He's not saying that "wp" links can't be included in star articles, he's saying that wp links shouldn't be a requirement for an article to achieve star status. I wholeheartedly support that proposal, as well as the suggestion to restrict the links to "See" listings, although I would also request they be added for "Do" listings - things like zoos and museums are often put into that section, and I've seen listings where detailed information about the history of the zoo overwhelmed the more travel-relevant information. As to the "more concise" suggestion, I'm shutting up now :) -- Ryan • (talk) • 19:04, 5 January 2013 (UTC)Reply

If we're adding links to Wikipedia, then I'd like to see blog links added as well. There are many good travel blogs out there, that actually serve useful travel content aimed at travellers. These give a lot more useful information than Wikipedia does for many attractions. --Globe-trotter (talk) 19:19, 5 January 2013 (UTC)Reply

Can you start a separate discussion with your proposal for links to blogs? As noted above, I'm concerned that one of the reasons we're often unable to make changes is that discussions can get easily derailed by covering multiple topics and policies. -- Ryan • (talk) • 19:25, 5 January 2013 (UTC)Reply

It is related to this discussion, and also discussed above. If we're adding external links anyway, I'd prefer to actually link to travel content instead of encyclopedic and other non-related content. --Globe-trotter (talk) 19:29, 5 January 2013 (UTC)Reply

So I think that kind of gets to my point about the pitfalls of our current consensus-building process. The proposal on the table is that a number of individuals have said they feel a Wikipedia link would be valuable for providing information that it out-of-scope for a travel guide, they've made their case, and proposed some specific guidelines. I'm not sure if you're suggesting we table that discussion and instead focus on linking to blogs, if you're opposed to Wikipedia links, or if you're OK with a Wikipedia link and would also like to consider links to blogs, etc. Could you clarify what you want to see done, and specifically what change you would suggest to the proposal that's been made to allow Wikipedia links? -- Ryan • (talk) • 19:37, 5 January 2013 (UTC)Reply

Is not it confusing that we discuss the change to our external links policy as a minor change in the listings format? --Alexander (talk) 20:16, 5 January 2013 (UTC)Reply

Suppose we link to attractions and "activities" in See and Do. But how to deal with external links outside the listings? For example, I want to link to w:Tallinn Airport, which a nice page that details the history and present status of this airport. How should I do that? (Ryan, please, do not suggest me to start a new discussion; this topic absolutely pertains here) --Alexander (talk) 20:16, 5 January 2013 (UTC)Reply

Yes, it is a completely pertinent point, and I think the solution is to restrict WP links not only to "See" and "Do" listings, but to any unique listing. (I say unique so as to prevent the WP article on the Holiday Inn chain from being linked to thousands of times.) Ikan Kekek (talk) 20:28, 5 January 2013 (UTC)Reply

Alexander - first, I do not mean to diminish your concerns about links to Wikipedia in article text; I think it's a valid question. As Ikan noted, if your concern is with including Wikipedia links in listings other than "See" and "Do" then let's talk about that. However, if I'm understanding you correctly, "how to deal with external links outside the listings" is a related but separate issue that has a separate discussion at Wikivoyage talk:Links to Wikipedia#Wikipedia Links. If we can keep these two issues separate it makes it much, much easier to understand what specifically is being proposed in this discussion, what concerns people have with the proposal, and simplifies the discussion by focusing on one thing at a time. If I've misunderstood you, and you are suggesting a change to the proposal made in the "Summary" section below, please clarify what you would like to see changed so that I can better understand. -- Ryan • (talk) • 00:40, 6 January 2013 (UTC)Reply

Once again, I do not have a ready solution, but I hope that someone is willing to think about it. Our current external links are not bound to listings. Now we want to introduce new external links that always require a listing. What shall we do with items that merit a link to WP but do not merit a listing (airports and transport companies are the most prominent example)? Should we introduce new listings for the sake of linking to WP? --Alexander (talk) 03:54, 6 January 2013 (UTC)Reply

My concerns are thus:

We cannot and should not get into the habit of allowing external links simply because a group of people will find them useful. (This leads to proposals like Globe-trotter's above.) The determinant of "usefulness" is highly subjective, and once everyone adds the links that they personally find useful, our articles will end up being nothing but linkfarms.
Wikipedia, specifically, already is linked extensively from Wikivoyage. And those links are in a nice, unobtrusive place. Having that link on the sidebar and 5-20+ links in the article as well seems like overkill.
I have yet to see a proposed link format for these Wikipedia links that is actually unobtrusive. Indeed, some proposed listing formats have a ridiculous-looking number of garishly colored icons that disrupt the clean look of our listings.
Other WMF "content" projects seem more circumspect in their use of interwiki links.
Overall it just feels wrong to me. We want people to stay here and read our travel guide, and providing this many links to a single other site is an invitation to stop reading us.

-- LtPowers (talk) 01:36, 6 January 2013 (UTC)Reply

In response to Alexander: Don't airports and transport companies that are mentioned in articles normally already have listings - if not formally so, by being on a particular line of text? Anyway, we wouldn't be making links to Wikipedia mandatory, only optional, so if someone wants to listify airports and transport companies that are listed in conformity to our tour and external links policies, I don't see the problem with them doing so.

LtPowers' objections are harder to address. I take them seriously, and there's no way to disprove his belief that these proposed changes would be detrimental and not beneficial to increasing readership of this site, so a decision will have to be made without knowing what the outcome will be if we make these changes or don't make them. Ikan Kekek (talk) 07:09, 6 January 2013 (UTC)Reply

I can see the concerns about being detrimental to this site, would not want it to become just a list of links. On the other hand I think you need to look at the behaviour of contributors and consumers of the site differently. Someone planning to visit a location may come to Wikivoyage first or may start at Wikipedia then click to Wikivoyage from the link there. After getting, hopefully, a good overview of attractions here at Wikivoyage they may want more detail. To do that you have to go back to the location on Wikipedia and look for a links to individual points of interest. Currently they will not come back Wikivoyage as there is only a list of places here. If there were links in the listing in a concise well organised way, that you do not always get on Wikipedia, at least the page will stay open. Readers will come back for information on where to eat, drink and sleep but what other benefits can this site bring? Yes usefulness is subjective. What I have learned after a few years working on Wikipedia is there are many irrelevant to me and ridiculously obscure topics that are very important in other peoples lives.--Traveler100 (talk) 09:16, 6 January 2013 (UTC)Reply

Normally, we do not use the listings environment for describing the airports, but of course we can change it. However, as long as Wikipedia links are inextricably bound to the listings template (which is, to my opinion, a very odd idea), we have to phrase very clearly what listings are and what they are not. Otherwise, we will immediately encounter the situation when new listings are created for the sake of linking to Wikipedia. --Alexander (talk) 09:46, 6 January 2013 (UTC)Reply

Ikan: My objections (with the exception, perhaps, of the first) are not predictive in nature; they are based on the very concrete proposal presented here and apply regardless of how the readership reacts. LtPowers (talk) 15:00, 6 January 2013 (UTC)Reply

LtPowers - to your first point, there is always a slippery slope argument to be made, but in this case Wikipedia is the recognized "go-to" site for general knowledge articles on the internet, we've linked to them since day one of the project (albeit in a more restricted fashion in recent years since we couldn't come up with a clear guideline for limiting inline links), and Wikivoyage has a relationship with that site. So long as we're not allowing an encyclopedia-level of detail in our guides, Wikipedia seems like the obvious choice to use to guide travelers to a greater level of detail on a subject.

To the point about UI, please let me know your thoughts on the proposal in the "Summary" section below. Fine tuning the UI to be more acceptable is a fairly easy task.

Finally "it just feels wrong to me" gets to my concerns about or consensus-building process. If a significant number of people have said that this is a feature they would use and find useful, shouldn't that matter? Without resorting to a vote it's impossible to know exactly what percentage of contributors want to see this implemented, but from the discussion thus far it's clear that this isn't just one person saying they think it would be a neat idea. -- Ryan • (talk) • 17:05, 6 January 2013 (UTC)Reply

I perhaps shouldn't have used that choice of words ("it feels wrong"), because it leads you to assume I have no rational basis for opposition. But I do; the reason it feels wrong is not a vague, gut-level intuition, but a reasoned analysis of the type of links we feature, and how this proposal fits in with that. Allowing these sorts of links to proliferate (again, we're talking about a handful to maybe dozens of links to a single web site that is not us) is contrary to our most basic goals and ideals, in my opinion. I may be wrong, and we may just disagree on what the basic goals and ideals are, but it's going to take a heck of a lot more than just "well some people think it will be useful" to convince me. LtPowers (talk) 18:37, 6 January 2013 (UTC)Reply

And to head off your next question, which I believe would probably be "Why do you insist on being convinced; why not just give it a shot and see what happens?": I am not opposing this proposal just because it's different, and I abhor change. I oppose it because I think it does not fit with the site's goals and ideals, and I have not yet heard reasoning sufficient to justify contravening or changing those goals and ideals. LtPowers (talk) 18:42, 6 January 2013 (UTC)Reply

Which goals specifically do you see this proposal not fitting into? Let's look at Wikivoyage:Goals and non-goals:

The mission of Wikivoyage is this:

   Wikivoyage is a project to create a free, complete, up-to-date and reliable world-wide travel guide.

Wikivoyage articles should be useful for at least the following purposes:

   For on-line use by travellers on the road, huddled in a late-night Internet café in some dark jungle, who need up-to-the-minute information on lodging, transportation, food, nightlife, and other necessities;
   For off-line use by travellers on the road sitting in a train with a subset of Wikivoyage on their PDA, laptop, mobile phone, iPod or digital camera.
   For on-line use by travellers still planning to review destinations, plan itineraries, make reservations, and get excited about their trip;
   For individual article printouts, that is, for printing a list of museums or karaoke bars and putting it in your back pocket for when you need it – or making a photocopy when someone else does;
   For ad-hoc travel guides, small fit-to-purpose travel books that match a particular itinerary;
   For inclusion in other travel books, giving up-to-date information for travel guide publishers.

There are probably hundreds of other uses for Wikivoyage articles; these are ones we try to keep in mind while authoring and editing pages.

I don't see the proposal as conflicting with Wikivoyage's mission; one could argue either way about this - that it's complementary, or that linking to Wikipedia weakens the travel focus. It doesn't seem specifically relevant to the first purpose, since encyclopedic content is not up-to-the-minute information about necessities; to be relevant to the second purpose, someone would have had to print related Wikipedia information. It is relevant to the third purpose, because in planning what to see and do, the additional information in Wikipedia articles could be quite useful. The proposal isn't so relevant to the fourth purpose but could be relevant to the fifth and sixth purposes. Ikan Kekek (talk) 19:02, 6 January 2013 (UTC)Reply

(re-indenting) If the Wikipedia content you describe is useful for travellers, then we should be having that content. In-text links serve no purpose, because we want to have all the useful content on Wikivoyage itself. If we have all relevant content ourselves, there is no need to link to third party sites or other reference works. Those links just distract from Wikivoyage becoming the best travel guide on the web, and send the reader towards third party sites (indicating they apparently do a better job as we do, else we wouldn't be linking to them in-text).

To summarize:

If Wikipedia does a good job serving travel content → we should be having this information ourselves.
If Wikipedia doesn't do a good job serving travel content → there is no reason to link to irrelevant information.

In both cases, linking doesn't help anyone, and especially not the project as a whole. --Globe-trotter (talk) 19:50, 6 January 2013 (UTC)Reply

Thanks for explaining. So let's see if I've understood you right. We should have page-long descriptions of the holdings of the National Gallery, the British Museum, the Louvre, the Uffizi, and other great museums, then? Certainly, there are readers who would be well-served by such encyclopedic descriptions, right? (I can tell you for my part that I chose to take a trip to London because my artist father detailed for me the holdings of 6 museums in London and then started talking about more museums.) But we don't want those descriptions here, do we, because they're too detailed. And your solution is not to link to such information. Correct me if I've misunderstood your position. Ikan Kekek (talk) 20:16, 6 January 2013 (UTC)Reply

I don't think we should have page-long descriptions of these, because our readers (travellers) are not interested in this content. Of course, there might be some travellers who are interested in long encyclopedic background information on historical buildings, but we shouldn't assume that, being a travel guide. Some travellers might also be interested in comic books, but we don't link to comic books in every listing. It's not what defines a traveller, and what a traveller is looking for when visiting Wikivoyage. --Globe-trotter (talk) 20:23, 6 January 2013 (UTC)Reply

Globe-trotter is fundamentally right. Travel guide is a very special writing style that entails a concise description of how to reach an attraction and what to see there, to the extent of explaining why you must go there. That's all. A detailed description of holdings is not a travel-related information. It is an information that might be interesting to some travelers. This is conservative, I know, but this is how LP and other good printed travel guides work. They may vary in the number of details, but the concept is still the same. Personally, I do not need anything else, and therefore I don't feel that links to Wikipedia may be useful. Of course, we can switch to a brand-new style of a "travel guide with links to Wikipedia". This would make sense, but we have to provide all relevant links including history, biographies and national food, because different travelers have different interests, and Wikipedia can (fortunately) provide all travel-related information. --Alexander (talk) 20:36, 6 January 2013 (UTC)Reply

There are different kinds of travel guides. I mentioned the guides of Touring Club Italiano previously in this thread. I used their guides to Florence and Environs and to Tuscany (covering the rest of the region). They were expressly sold as guides for travelers to Tuscany, and came in hardcovers with cardboard sleeves. I got those guides precisely because they told me what every artwork in every church was, and by whom, and also described every building (palazzo) on every street of cities like Siena. Now, I would say that that kind of guide is specialized and that more Italians than, say, Americans are interested in guides that detail palazzi e monumenti, but it is really not the case that every travel guide has exactly the same degree of description and emphasis as every other guide.

That said, I'd like to focus on Alexander's remarks, because I think they cut to the heart of the discussion. Alexander, it seems to me that you are presenting a binary choice: To keep the guide as it is or to open it to unlimited links to Wikipedia and perhaps other secondary sources. I see your point on this. It could easily be argued that limiting Wikipedia links to listings only is arbitrary. But isn't the decision to have a link to Wikipedia at all also arbitrary? And therefore, would it be a good idea to subtract all Wikipedia links from our articles?

I guess I would summarize my feelings this way: I believe that our guides should be readable, and therefore devoid of details that would seem excessive to most of our readers. Judging at what point this occurs is to some extent guesswork on our part, but good editing is never a bad thing. There is a but, however: I think we should help our readers by providing information about printed material (books) and links to sources of additional information on topics some of them will find relevant, but that are specialized or detailed enough for us not to want to include them here. These links should be unobtrusive to people who prefer to simply read the articles, but visible enough for those who are interested to see them. And if that doesn't mean Wikipedia links for entries (which I favor but am not dead-set on), maybe it means revisiting the decision to prohibit "Links" sections in articles. Ikan Kekek (talk) 21:05, 6 January 2013 (UTC)Reply

But that's just it -- we have a longstanding policy against sections like that. Now, we can certainly look at changing it, but don't you think we need to see some good reasons to do so? We can't just go negating those long-standing agreements because a few people think they're outdated. We implemented them for very good reasons, and any proposal to change that needs to address why those reasons no longer apply -- or why they're outweighed by other concerns. This proposal to add Wikipedia links is the same. (Ryan has done a good job of trying to address why the reasons we prohibit non-primary links don't or shouldn't apply here, but I disagree with his conclusions. I think those reasons remain valid and applicable.) LtPowers (talk) 22:16, 6 January 2013 (UTC)Reply

Ikan, these are somewhat different issues. The number of sights distinguishes a brief travel guide from its comprehensive sibling. If we decide to write about every church in Siena (which obviously makes sense), we must explain why each of these churches is worth visiting. This makes a long travel guide, but it is still a travel guide. If we start to write pages about every single attraction, we get a book about Italy, which is simply a different genre. Even a gorgeous place like Uffizi can be described in a reasonably short fashion by mentioning the artists and main highlights, only. When we do that, the reader is prepared. The rest is up to the him/her.

Regarding your second point, yes, it is a binary choice. Unfortunately. Any compromise will be frustrating. Not for me (I can live with that, after all), but for readers and Wikipedians who will fairly think that inline links are as important as links embedded in the listings template. --Alexander (talk) 22:18, 6 January 2013 (UTC)Reply

Both of you make points that are well-taken. I suppose I need to review Wikivoyage Talk:External links and consider reopening a discussion there. Ikan Kekek (talk) 22:29, 6 January 2013 (UTC)Reply

(re-indent) If I'm understanding the latest discussions then my initial fears about our consensus-building process may have been misguided, and the concerns are essentially a fundamental disagreement about allowing links to any other site from Wikivoyage? If that is the case then my argument is this:

As Ikan notes, and in contrast to the statement that "we want to have all the useful content on Wikivoyage itself", no matter how detailed our articles get, there is always going to be some point at which a level of detail is "out of scope". Whether that's detailed info about maximizing chances for a "rollback" on the w:Top Thrill Dragster at Cedar Point or a history of the construction and architecture process that created the w:J. Paul Getty Museum in Brentwood, there will ALWAYS be some level of detail that will interest some travelers but be out of scope for the types of guides we are writing.
At the point where we have essentially said "that's all Wikivoyage has to say on the subject and that Wikivoyage will have to say on the subject" it would be a huge benefit (IMHO) to those who wanted it if we could also say "...but you can find more information at XYZ".
To Alexander's point about expanding usage outside of listings, the biggest problem in the past has been in determining how to recognize a "good" external link from a mediocre or spammy one (essentially, what is "XYZ" in the "more information at XYZ" statement above). I think we've all hit problems where the current external links guidelines seemed too limited - see for example the "Mobile Magic" information at Walt Disney World#See and Do. That article passed through a successful star nomination, but to my eyes the "Mobile Magic" information is a clear violation of Project:External links; however, since it's still useful for travelers and out of scope for Wikivoyage I wouldn't suggest removing it. The key is to come up with clear guidelines that would allow an editor unfamiliar with the destination to determine whether a link is appropriate.
In the case of adding a "wp" parameter to listings, the proposal meets both the "covers information that is useful to travelers who want more detailed information but out of scope for Wikivoyage" criteria as well as the "an editor unfamiliar with the destination could clearly determine what links are appropriate" criteria - we link to the Wikipedia article that is on the exact same subject as the listing. It makes our guides more useful for those who want a level of detail that is out of scope for Wikivoyage, and has clear limits that prevent abuse.

If we didn't introduce something like this parameter, what would the alternatives be for those who want more detailed information? Saying "use Google" when we could put an icon in the listing seems like a poor way to serve that audience, particularly in the age of mobile phones (tiny keyboards + limited bandwidth). We've ruled out putting the info in Wikivoyage ("not an encyclopedia" per Project:Goals and non-goals). If there is no alternative being proposed, this seems like a sensible way to provide additional information to travelers who want it until we find something better. -- Ryan • (talk) • 22:35, 6 January 2013 (UTC)Reply

Clearly this is why we have a link to the primary source. We provide the secondary, interpretive information. Want more? Here is the link to the primary source of information. --Inas (talk) 23:09, 6 January 2013 (UTC)Reply

The primary URL (when there is one) is usually good for getting promotional/commercial information, but that is very differnt information from what one finds in a general knowledge article on Wikipedia. Using my two examples above, http://www.getty.edu/ has information about current exhibits, but none of the background on the Getty trust and museum history that is found in w:J. Paul Getty Museum. http://www.cedarpoint.com/ has a picture of the Top Thrill Dragster, but nothing about records, speeds, rollbacks, or safety history that is found in w:Top Thrill Dragster. Most historical landmarks and similar listings will have no primary URL (three of the seven entries in Paris/1st arrondissement#Landmarks have no primary URL). Personally, if I want up-to-date ticket prices or to book a reservation I'll double check the primary URL. If I want to know more detailed information about a building, park, etc. then Wikipedia is a far more valuable reference. -- Ryan • (talk) • 02:18, 7 January 2013 (UTC)Reply

Personally, my next step after WV is to check tripadvisor. Then I do a google blog search. I might then jump to skyscanner, or flightstats. They all have great information and are very useful to me. Can I have a link to those too? I can't recall personally ever personally going to WP to find information regarding to a trip.

I think all the reasoning given for linking WP is largely post-rationalised. The people who want WP links have an affinity for WP, and would like to link there. The "useful" criteria doesn't have any consistency in application. --Inas (talk) 02:44, 7 January 2013 (UTC)Reply

Could someone please kill Tripadvisor and reroute all that user generated content to a site that isn't a disgrace? I'd think we'd be experts at that sort of thing... --Peter ^Talk 05:36, 7 January 2013 (UTC)Reply

Has this issue been discussed enough? It seems really clear there are two opposing views and we're likely not going to reach a conclusion/compromise easily. How about a Vote in the style of the Rfc/voting process on meta? Two choices: allow or not allow. If the vote is to allow such links, then hopefully we can work out a compromise on the exact details of the policy (where links will be allowed, etc). There are just a couple issues: timing (would it be possible to have just a 5-7 day voting period and get this done before leaving beta?) and if not solved before leaving beta, then the results might be skewed by new editors moving here from other WMF (who might not fully understand the reasoning behind all of what's been discussed). I'm in favor of the links, so I don't really care about drawing up rules for voter eligibility...but, for the reasons given, those opposed to such links and concerned about skewing of the vote are welcome to come up with such eligibility requirements. Suggested page to be created: Wikivoyage:Requests for comment/Wikipedia links. AHeneen (talk) 08:11, 7 January 2013 (UTC)Reply

The vote will go against the consensus policy. This policy says very clearly that we do not use votes, and we do not make changes when consensus can not be built. If we want to have a vote, we should amend the Wikivoyage:Consensus policy first. --Alexander (talk) 08:47, 7 January 2013 (UTC)Reply

Consensus is an excellent method on wiki article pages. Continuous editing my many contributors should eventually lead to a reasonable compromise. However we are talking here about a xml tag that is controlled by a few and an issue of policy. So I guess we move this discussion to the policy page, then is it a vote or is there another process for policy change? Or we go for consensus method on individual pages manually adding the link, which I would be concerned would just get into an edit war in this case, which I do not think anyone wants. --Traveler100 (talk) 09:46, 7 January 2013 (UTC)Reply

The idea of building consensus applies to both individual pages and policies. We have no policy stipulating the voting procedure, eligibility of voters, etc. Therefore, we can not proceed to a vote without writing a new policy and revising most basic principles of this project. --Alexander (talk) 10:30, 7 January 2013 (UTC)Reply

We had a vote to determine whether to replace "Get out," and if so, with what. Also, unrelated point, but the additional Wikipedia links in the Glacier National Park sandbox example linked below are unobtrusive almost to the point of invisibility, so if anyone was concerned they could make the content of an article hard to read, I think they can rest easy at least on that point. Ikan Kekek (talk) 11:02, 7 January 2013 (UTC)Reply

That was not a vote; it was a straw poll to determine which option had the most widespread support. This is a binary choice, so a straw poll is not much use. A poll would likely end up with about half on each side, and the result would be determined simply by how many showed up on each side, not by quality of argument. Ryan: If the argument is that "We cannot include every bit of information a reader might want, while Wikipedia can," then that raises two questions: 1) Why isn't the single, prominent link to Wikipedia on every article page sufficient, and 2) Why an encyclopedia, and not (say) an image repository, or a news site, or a textbook, or any of a number of other types of "more information" sites we might link? LtPowers (talk) 23:50, 7 January 2013 (UTC)Reply

For me, putting a Wikipedia link in the listing is a hugely valuable convenience - it tells me immediately that there's an encyclopedia article on the subject one click away. The Wikipedia link in the left nav is great when you want an encyclopedia article on a geographic location, but to drill down from there to the level of a listing is a usability nightmare that requires significant (possibly fruitless) searching that we could avoid with a tiny icon in listings - I can honestly say I've never wanted to know more about a listing and clicked on the link in the left nav, but I would click on a Wikipedia icon if it was present. As to why not links for images or news, no one has made a reasonable proposal as to how/why we would link to those in listings, but they HAVE built a case for Wikipedia links, and have also suggested clear, workable guidelines for usage. I commented above that a criteria for any external link should be that it provide useful information relevant to travelers that is out of scope for Wikivoyage AND that there be clear guidelines to allow us to determine what to link to and what not to link to, and unlike almost every extlink proposal made in the past several years this proposal meets that bar. To respond to Inas' related comment about Tripadvisor, I would agree that access to user reviews would be hugely useful, but I suspect usage guidelines would be very difficult to finalize since, unlike Wikipedia, Tripadvisor is not clearly the dominant site to provide user reviews, and thus it would probably be much tougher to gain consensus for inclusion of links to Tripadvisor versus any one of its many rivals.

I realize that many arguing against this feature feel that it would be useless, and to that I can only say that Wikivoyage would be a better guide for me with this feature, and others have stated the same. A Wikivoyage article helps me figure out where to go and what to see, but once that decision is made I would find it very valuable if there was an easy way to get more detailed information about what I've decided to visit from Wikivoyage, rather than forcing me to simply rely on Google searches. -- Ryan • (talk) • 01:13, 8 January 2013 (UTC)Reply

Forcing you to simply rely on google searches? Google has developed into a multi-billion dollar company by developing a self-ordering algorithm to help people locate the best information. On most occasions a google search is the best way to find further information on any attraction. Often that point to WP, and where it doesn't, it usually points useful information and facts - often from official sources. Nothing wrong with a google search. I'd recommend it. --Inas (talk) 02:08, 8 January 2013 (UTC)Reply

I'm quite unconvinced a straw poll would end up with about half on each side, just for the record. Ikan Kekek (talk) 06:50, 9 January 2013 (UTC)Reply

Keeping this discussion open

My reading of the discussion above is that there are a handful of users who have made a case for adding links to Wikipedia in listings (as outlined in the proposal below), but there are also a handful of users who are opposed to including links to Wikipedia. In many cases this seems like a philosophical difference, so unless I'm misreading the arguments of those who are opposed any further discussion may not be fruitful. I suspect that we will have users asking for this feature again in the future, particularly as Wikivoyage moves out of beta, so rather than continuing to re-argue the same points it might be worthwhile for anyone who stumbles upon this discussion to simply add a line or two stating their support/opposition for this feature so that we can at least get some sense of how strong a desire there is to see this implemented. Is that an acceptable resolution to this lengthy discussion for now? -- Ryan • (talk) • 05:06, 9 January 2013 (UTC)Reply

May be a wise thing to do, no need to rush this type of change. --Traveler100 (talk) 05:23, 9 January 2013 (UTC)Reply

I support the inclusion of Wikipedia links in templated listings only for the time being. There might be exceptions elsewhere, but since this discussion is long enough, it's probably best to discuss use elsewhere after a decision is made to include Wikipedia links at all (aside from the sidebar) or not. I basically agree with everything Ryan has mentioned in several lengthy posts above, but to address a few issues:

There are going to be many cases of listings (like landmarks, buildings, & even some restaurants/hotels) for which WV readers will appreciate/desire info that lies outside the scope of Wikivoyage and Wikipedia has a detailed article. We simply don't need 3 paragraphs about the history of a landmark, despite the fact that many users will find such detailed information useful.
While WP is usually one of the top results for Google/Bing/etc searches, providing the link directly and unobtrusively in a listing will make it much easier for readers/users of our guides and also strengthen the bonds between WMF projects. Links to Wikisource/Wikibooks may be also be appropriate (like in the "Read" section) when there is a very appropriate/relevant book for a destination. For example, I think it would be very appropriate to link to Heart of Darkness (on Wikisource) when mentioning Heart of Darkness—a well-known novel about colonial Congo—in the history section of the Democratic Republic of the Congo.
A couple comments mentioned scepticism that if WP is allowed as a non-official external link on pages, why not other sites? Well, for starters, Wikipedia is a WMF project and shares the same goals as we do: providing free & freely-accessible knowledge for the greater good. It is clearly recognized as a go-to source for knowledge and, unlike sites such as TripAdvisor, it is non-commercial...we're supporting a site with a common goal, not sending readers to another site to profit from our out-traffic.

All-in-all, Wikipedia links within listings strengthens our guides by linking to relevant, quality information that complements what we have (lengthy, encyclopedic information that is a WV non-goal vs. condensed info for travelers that is a WV goal) and doesn't support any other entity (commercial websites or specific websites of universities/organizations/individuals that may construe an endorsement/support from WV) besides the WMF which we trust (at least, I hope everyone does!). AHeneen (talk) 06:47, 9 January 2013 (UTC)Reply

Yes, sure. I am looking forward to new opinions and arguments. --Alexander (talk) 07:07, 9 January 2013 (UTC)Reply

Strongly support the proposal. I agree with AHeneen, above, that there are multiple ways in which judicious addition of Wikipedia links will benefit the intended reader (i.e. somebody doing his travel planning, more or less):
1. For many articles of potential interest to travelers, e.g. most airports (e.g. w:Nizhny Novgorod International Airport), many major train stations (e.g. w:Shanghai Hongqiao Railway Station) there is a dedicated cadre of Wikipedia editors maintaining such articles fairly complete and up-to-date, including some information that both changes fairly frequently and is of interest of travelers (e.g., "what international airlines fly to airport X?"). While one can reproduce such info in a Wikivoyage article, maintaining it in synch would not be practical, and would be a ridiculous duplication of efforts, too. It is more practical to summarize the basics ("there is regular service from X to major airports throughout China, and to a few other Asian countries"), and let the interested readers follow the Wikipedia link (or the link to the Airport X's official site, which may or may not be available).
2. Quite a few Wikipedia articles on various tourist attractions, especially in non-English-speaking countries (e.g. w:Yangzhan Quarry, w:Shou Qiu w:Cemetery of Confucius) are in fact the best available online English-languages sources on the objects in question. While one can copy the gist of an article like this into the Wikivoyage article for Nanjing, Qufu, etc (within the overall article size limitations), the Wikipedia article is likely to contain quite a few useful resources including all of them into the Wikivoyage article would not be appropriate (lots more illustrations that can fit into the WV article; a link to the Commons category; the reference section with a number of annotated links, which allows the reader to find the few available English sources with further info about the object, as well as summarizes info from some important foreign-language sources).
3. Even when there are numerous English information sources about an object (e.g. w:Hagia Sophia), having a link to the Wikipedia article is good way to let the reader find them (or, of course, find the info he needs right in the Wikipedia article). -- Vmenkov (talk) 03:19, 19 January 2013 (UTC)Reply
Anything useful to travelers should be in our guides. Ancillary information (like illustrations and bibliographies) is not hard to find if a reader is interested. Do we really need to hold their hands and show them which direction the encyclopedia articles are from here? LtPowers (talk) 21:36, 19 January 2013 (UTC)Reply
We're going in circles, but there is a level of detail that we do not allow in Wikivoyage articles, so the "anything useful to travelers should be in our guides" argument is contracted by some very core site policies. With respect to a Wikipedia link being "hand holding", the whole point of links is to simplify usability - yes, you could go to Google and search, but you don't have to if the link is right there for you. In an analogous discussion you argued for inclusion of a city list precisely because the are a usability shortcut, and while the difference is one of internal vs. external link, the usability argument is the same. -- Ryan • (talk) • 21:51, 19 January 2013 (UTC)Reply
Well, yes, because one directs readers to the correct place on our Wiki; the other sends them away. I should think the difference is obvious. LtPowers (talk) 22:07, 19 January 2013 (UTC)Reply

From the experience of the launch, and the huge influx of Wikipedians, I've seen too much lazy linking without actually writing content here—confirming my worries expressed above. This is a great example of the problem. It's a great travel topic or itinerary (depending on how you want to write it), but the content just got linked to on Wikipedia—even to WP town pages! From spending virtually all of 15 January in front of Real Time Recent Changes, I can say that this was a common theme. --Peter ^Talk 05:29, 19 January 2013 (UTC)Reply

With that example, too, after I removed the links, the contributor stuck around and has been adding really high quality information to both that article and others. --Peter ^Talk 05:30, 19 January 2013 (UTC)Reply

I'll keep responding to myself. It's a similar situation we faced with business owners and marketers adding listings that contained only their name and a link—if they can just link the info, there's no point in doing the work here to describe it and fill out details. Only when we started summarily deleting such additions did they start adding meaningful content. --Peter ^Talk 05:32, 19 January 2013 (UTC)Reply

I second Peter's opinion. Please, spend some hours on patrolling this flood, and you won't think about any Wikipedia links any longer. --Alexander (talk) 08:08, 19 January 2013 (UTC)Reply

Actually, I have been watching special:newpages closely. The users who just mention the Heartbreak Hotel, Cockroach Motel and the Stagger Inn without providing address, contact info or description for any of them are abusing external links, not interwiki links. They can't misuse Wikipedia links if the venues they're promoting aren't in the encyclopaedia - which is usually the situation for the worst self-promotion, WP:AfD being what it is today. Do you propose to ban these "official" external URL's... because if any site is going to be promotional, it'll be the venue's own site, not Wikipedia. Some of these might actually be innocent cases of random users finding us, seeing their home town missing ("why do you have Jefferson but not West Jefferson?") and posting a brief stub or outline just to say their town exists. Others are hotel or CVB marketers who never did grasp that "Contact" should list "Internet café", "Wi-fi hotspot" and not "CVB which lets its summer students post entire towns worth of marketing fluff". Wikipedia has little or nothing to do with these issues; hotels and CVB's are permitted to link to themselves now, so unless you intend to ban those links, WP or no WP changes nothing. K7L (talk) 16:57, 19 January 2013 (UTC)Reply

Perhaps it's a case of seeing what I want to see, but my experience in patrolling hasn't matched Peter's. What I've seen is much confusion about how to use the existing listing tags, which hopefully will be resolved when we can switch to a template format (specific examples: people adding unsupported attributes, people deleting one or more quotation marks, mis-matched tags, and many users seemingly not realizing that the tag body is for description text and in some cases adding descriptions after the listing tag). Since the template format should be easier to understand, and after seeing far more good edits over the past several days than I expected, I remain confident that users will be likely to fill out each field including the Wikipedia link AND description. -- Ryan • (talk) • 17:41, 19 January 2013 (UTC)Reply

Having missed this whole discussion, I do want to say that I strongly support inclusion of WP-links for selected purposes. I don't see the huge problem with restricting them to the places where we /want/ them, as we also enforce other policies that newbies don't always agree with. I'm sorry to see that some consider this discussion to be about how many links WP will "give" us back. To me, that kind of competition is of no interest at all, and all that matters is the good of the traveller and the usefulness of /this/ site. The one great thing about an online travel guide (apart from the speedy updates) is that we are NOT restricted by size, and in theory we can give all the information we consider of value for a traveller. I agree that the basic version of an article should have all the basic stuff, so you'll have what you need when you print it. However, there's no reason why we wouldn't want to give additional information for those who are interested. Of course people will also find it by themselves, but why would we not want to make that easier? Fear that people will switch to the "other" site would suggest Wikivoyage wouldn't have enough value of itself. That's nonsense, in my eyes. Wikivoyage is of great interest to travellers in a way Wikipedia cannot be. But it could benefit from /more/ background information on e.g. major sights, which would strongly clutter city articles. When using Wikivoyage myself, I /always/ use Wikipedia next to it to search for background information on monuments and other sights. Having them just at hand seems like a great improvement in terms of usability, which would set us apart from any other travel guide. Especially now that both sites are included in one big family, it seems just.. a missed opportunity to not make any use of that. JuliasTravels (talk) 10:45, 25 February 2013 (UTC)Reply

Format

The format currently proposed in the Summary below is like this:

Doxey Marshes Nature Reserve , Creswell Farm Drive, Staffordshire, ☎ +44 1889 880100. Wetland oasis and bird watching site.

I don't support the argument in opposition that we don't want to be sending readers out of WV via these WP links at all, but I don't think we should invite readers to leave WV before they have read all the info on the topic in WV. So I think the link should be presented AFTER all the relevant info in WV. (Besides which, the format above has the attraction name linked to the external primary site, which is a bug that hopefully will be fixed soon.) I suggest this format:

Doxey Marshes Nature Reserve, Creswell Farm Drive, Staffordshire, ☎ +44 1889 880100, . Wetland oasis and bird watching site.

I would suggest also moving the link to the primary website to the end, as follows, but let's leave that for another discussion:

Doxey Marshes Nature Reserve, Creswell Farm Drive, Staffordshire, ☎ +44 1889 880100. Wetland oasis and bird watching site. .

Nurg (talk) 00:29, 13 January 2013 (UTC)Reply

I like your idea. Ikan Kekek (talk) 00:47, 13 January 2013 (UTC)Reply

Moving the

to the end looks good. I'm hesitant to move every link to the very end; on a small mobile touchscreen it's easy to select the wrong link by mistake if they're closely spaced together. The (lat, long) need to go somewhere too, but that's a different issue. K7L (talk) 01:05, 13 January 2013 (UTC)Reply

Ongoing feedback

Based on discussion above, those wishing to comment on the proposal to add Wikipedia links to listings and who do not have a new argument to make can express their support or opposition below. If you have a new argument, rather than simply indicating your support/opposition below please continue the lengthier discussion above. This is not a vote, but simply a way to keep this discussion alive and gather some data that might help to determine how much interest there is in implementing this feature, and conversely how much opposition there is to implementation. -- Ryan • (talk) • 04:06, 11 January 2013 (UTC)Reply

Polling is not a substitute for discussion? Why do we have so many polls all of a sudden? LtPowers (talk) 15:59, 11 January 2013 (UTC)Reply

Support

Support. For reasons outlined in the many arguments above. -- Ryan • (talk) • 04:06, 11 January 2013 (UTC)Reply
Support. An encyclopedia can describe individual sites with more detail than will fit in a city-level guide. K7L (talk) 05:20, 11 January 2013 (UTC)Reply
Support. For reasons outlined above. --Traveler100 (talk) 07:21, 11 January 2013 (UTC)Reply
Support The encyclopedic content on Wikipedia complements and enhances the more succinct amount of detail we are able to place in a travel guide. Unlike practically all commercial and even academic sites, Wikipedia is a sister project and shares the same goals of providing freely editable, freely accessible, & freely licensed content. Adding a link in the listing after all the discussion above should be a no-brainer. AHeneen (talk) 07:30, 11 January 2013 (UTC)Reply
Support. If it can enhance the interested reader's access to more in-depth information while keeping the articles themselves short, then why not? -- AndreCarrotflower (talk) 14:28, 11 January 2013 (UTC)Reply

* Support. I think some of the counter-arguments are quite reasonable, but on balance, I support this proposal and believe we can try to work within its limits. Ikan Kekek (talk) 05:08, 12 January 2013 (UTC)Reply

Support the broad principle. Nurg (talk) 00:29, 13 January 2013 (UTC)Reply
Support the broad principle Man that was a long descusion unsigned - 03:42, 17 January 2013 by 81.178.175.36
Support - I've come across numerous instances where there is a lot of background info that will serve the traveller, but including it all would just be overkill. This is a way to combat that and keep our site's focus on travel info clear. JamesA ^>talk 02:02, 3 February 2013 (UTC)Reply
Support - The assumption that the current policy is based on is unworthy of an online resource: it is, essentially, that people need to be able to access travel information off-line and can't follow interwiki links when they print out their wikivoyage papers and go tramping around. I know it has hard to generalize, but we need to accept that this is an online resource and with smart phones and wifi, it should be useable to travelers who want to access more detailed information as they travel--or prepare for travel. I confess I am one of the influx of editors from Wikipedia and so I find interwiki links not only useful but necessary to avoid adding redundant material that will end up being more lengthy than a simple hyperlink. For me context is important and wikilinks can provide that easily and concisely. Argos'Dad (talk) 04:22, 7 February 2013 (UTC)Reply
- Question How do you address the fact that there are still places with no signal, such as long stretches of California coast? Would you suggest that people print out not only Wikivoyage articles but whatever articles they are linked to, before they go? Ikan Kekek (talk) 05:28, 7 February 2013 (UTC)Reply
  - Answer We can't. But as long as the tiny symbol links are used just to add the opportunity to quickly and precisely consult additional detail that we would never add here anyway (ie there should be a policy of no-substitution), the unconnected don't lose in any shape or form but the connected do gain additional educational and time-saving possibilities. -- Alice^✉ 06:17, 7 February 2013 (UTC)
    - Reply I think that's a cogent response, although I still have misgivings. I think my big issue right now is that I don't want Wikivoyage to become de facto part of Wikipedia, and I'm wondering if it will be as easy or as easy for Wikipedian editors to accept if we limit Wikipedia links to one a listing, rather than one an article. Having inline Wikipedia links all over the place is in my opinion completely unacceptable except for a Wikipedia article, and if we allow exceptions for those, the floodgates will have been open. Ikan Kekek (talk) 06:22, 7 February 2013 (UTC)Reply
      - I share your concern Ikan Kekek. It's all very well me thinking that just one appropriate symbol link per listing only where it would add supplementary information that would otherwise be too prolix or inappropriate for the listing (eg to the history of a Georgian B&B) is acceptable because you and I can be trusted to exercise a discerning judgement, but how do we formulate a policy that makes it clear that a Motel 6 should not link to it's corporate article on Wikipedia in each of its listings? -- Alice^✉ 06:30, 7 February 2013 (UTC)
        Exactly. That's the nub of the issue, because some of the Wikipedia links that responsible editors really think would be helpful and explanatory are inline and not in listings. And that's with responsible editors who are motivated by wanting to help travelers, and not self-interested editors trying to promote their own business. Ikan Kekek (talk) 07:47, 7 February 2013 (UTC)Reply
- Argos'Dad, with his comment about "redundant material that will end up being more lengthy than a simple hyperlink," actually illustrates why I think we shouldn't allow them—they would encourage editors to simply link to information on WP, rather than develop our guides as an independent resource of original content. Regarding using mobile devices—it's often not safe to check your iPhone in public while traveling, and I don't think that reality will change even with ever wider coverage. I usually leave mine at home while traveling, since it would make me a target for crime in many of the places I visit, and wouldn't want to walk around looking at it for many places in the U.S. that I've written about. --Peter ^Talk 19:37, 7 February 2013 (UTC)Reply

Actually, we don't want an entire article about the w:CN Tower or the w:Empire State Building in WV. We want a listing for each; the rest of the info can stay in the encyclopaedia, please. K7L (talk) 14:56, 8 February 2013 (UTC)Reply

It's irrelevant information for travelers, there is no need to link to it. If people need that information, they'll consult an encyclopedia, not a travel guide... Globe-trotter (talk) 17:46, 8 February 2013 (UTC)Reply

It's not irrelevant, it's just more detail than we want within the listing itself. "If people need that information, they'll consult an encyclopedia"? Fine, then link to an encyclopaedia for the extra info. :) K7L (talk) 17:50, 8 February 2013 (UTC)Reply

Others might be looking for a dictionary, a blog item, a book or a web directory. I don't think it's a good idea adding icons for all those things, it's unrelated ballast we don't need (although travel blog entries are more relevant than encyclopedia entries). Globe-trotter (talk) 19:07, 8 February 2013 (UTC)Reply

The book and the dictionary are already linked from the WP article (the book as a reference, the Wiktionary as a sibling project). The web directory? We already link DMOZ at city level. A third-party blog? Likely not a reliable source, and this opens the question of links to rival travel guides - which are an entirely different issue from WP articles on landmarks as linking travel blogs will overlap content which should be here. Then there's the question of what to do with blogs run by the venue itself - currently I'd think it's sufficient to only link them (or Facebook, or BBCanada-style single-page directory listings) when they're the only web presence for the venue (admittedly, more restrictive than fr: or other WV languages currently allowing multiple "official" links). K7L (talk) 14:41, 23 October 2013 (UTC)Reply

Okay, so the book and the dictionary are already linked from the WP article. The same applies to WP articles on attractions; they're usually linked from the WP article on the city, to which we do provide a convenient link. LtPowers (talk) 16:30, 23 October 2013 (UTC)Reply

WP's article on the city may or may not link to the attractions. It's not a travel guide, it's a mess of w:user:rambot spam, outdated census and political info all too often. The geographic boundaries also don't match between WP's city/region and the WV article in many cases. K7L (talk) 13:25, 24 October 2013 (UTC)Reply

Support judicious use in listings (I'm undecided as yet with regard to in-line explanations as to certain terms in text) provided that HTML code similar to <a target="_blank" href="http://en.wikipedia.org/wiki/Wikivoyage example">Wikivoyage_example</a> is used to make the hyperlink open in a new window/tab -- Alice^✉ 09:12, 8 February 2013 (UTC)
Support links for selected purposes, for arguments listed above. JuliasTravels (talk) 10:47, 25 February 2013 (UTC)Reply
Support per AHenee and others. --Piotrus (talk) 05:51, 30 July 2013 (UTC)Reply
Support I read Wikivoyage to select which museum/temple/park I will visit, then I read the Wikipedia article about it while heading there. A simple Wikipedia link at the end of each POI of the See section would save me time and bandwidth. Nicolas1981 (talk) 08:14, 23 October 2013 (UTC)Reply
A simple Google search would use only a marginal amount of extra bandwidth, while avoiding the many pitfalls addressed below, as well as letting you choose what reference work to view. LtPowers (talk) 16:30, 23 October 2013 (UTC)Reply

Oppose

Oppose. Our External links policy has been the essence of keeping our site spam free, focussed, and ensuring information is added to the guide and not linked from the guide. It has been cited more than any other policy in achieving this objective. This change just adds an exception for a single site, without developing our policies in a way that is consistent, justifiable and sustainable. --Inas (talk) 04:18, 11 January 2013 (UTC)Reply
Oppose per Inas' argument. --Alexander (talk) 07:35, 11 January 2013 (UTC)Reply
Oppose per the "we already have WP links"/"too many links" argument. But if there are a ton of people clamoring for it, I won't raise a fuss. (I would if we were talking about links outside of listings, though.) --Peter ^Talk 07:44, 11 January 2013 (UTC)Reply
Strong oppose. These links in no way serves the traveller, just "some users who might like it". We should have a clear view of what our audience is, or even should be, when writing a travel guide.--Globe-trotter (talk) 12:37, 11 January 2013 (UTC)Reply
Oppose. In the degenerate case, the listings will become a set of links to Wikipedia and nothing else. --RegentsPark (talk) 14:44, 11 January 2013 (UTC)Reply
Oppose. We are being deluged with scads of inline Wikipedia links from new users. Let's get those under control before risking confusion with this new proposed policy. It made sense to me in principle, which is why I voted to support earlier, but let's revisit this in a month or two. Ikan Kekek (talk) 08:39, 15 January 2013 (UTC)Reply
- What is a scad? Could you give some examples of what you are talking about?--Traveler100 (talk) 08:43, 15 January 2013 (UTC)Reply

I think you'll find the same thing if you patrol by clicking on "Recent changes" and checking the edits people are making. I don't really have the time to link to a bunch of stuff right now. Here's another way you can find it: Look at my edits and see what I edited. Ikan Kekek (talk) 08:47, 15 January 2013 (UTC)Reply

Look through the summaries in my user contributions: . I could use a lot of help with patrolling. It's going to be a big job, so whoever is willing should please take part. Sorry for the off-topic remark, but patrolling is much more important than whether we change this policy right now or wait a couple of months, when I may change back to supporting the proposal. Ikan Kekek (talk) 09:03, 15 January 2013 (UTC)Reply

Oppose. This problem is not solved. I am against the Wikipedia links about the objects to be described in WV. Digr (talk) 13:54, 20 January 2013 (UTC)Reply
Strong oppose. I should have been part of this discussion before. Just as Wikipedia provides a single link per page to us for information that is not within their scope, we provide a single link per page to them for information that is not within ours. It is not within our scope to provide encyclopedic information, nor links to encyclopedic information. We should not provide in-article links at every mention of something with a WP page for exactly the same reason WP does not (and should not) provide in-article links at every mention of something with a WV page. Not a single one of the pro arguments in the entire discussion above does anything to change that.Texugo (talk) 10:51, 8 February 2013 (UTC)Reply
- Question What is the reasoning on Wikipedia for the one link only? Ikan Kekek (talk) 11:00, 8 February 2013 (UTC)Reply

I imagine it is basically what I just stated. Try going to WP and proposing in-article links at every mention of something with a sister project page and see what happens. I would imagine an avalanche of opposition. Texugo (talk) 11:48, 8 February 2013 (UTC)Reply

There is no Wikipedia policy limiting this to one link only. An interwiki link is legitimate anywhere that an external link may be used, with the one exception that user-editable content is not a reliable source to cite as a reference because anyone can change things. Some articles do have two {{commons category}} tags pointing to different categories. They're relegated to the "external links" section as WP mirrors often don't mirror the full set of WMF projects. As for number of links? An individual landmark can be the subject of a WP article, a whole city is the subject of a WV article. Odds are, there are multiple WP articles for one WV city... not the other way around. K7L (talk) 14:51, 8 February 2013 (UTC)Reply

That is not how it works in practice. Try it. Go to WP and find a geography or country article. Add 28 or more links back to WV. More perhaps. Invite comment. See what happens. I do not think they will support doing that to all their pages for any and all mentions of articles we have here. It is simply excess, out of scope. For us, I think this proposal is the beginning of a really greased-up, iced-over, steep slippery slope, as we can already see from the calls for in-line WP links in non-listing sections and non-WMF links to external guides with encyclopedic information. Bottom line is, it's a step toward making WV articles into a meta-directory of WP articles, liberally sprinkling our articles with invitations to leave and go read non-travel-related information elsewhere. It is a huge distraction from our goal, and I am frankly shocked to see so much support for it.Texugo (talk) 16:09, 8 February 2013 (UTC)Reply

28 links to WV would require linking to 28 different cities; 28 links to WP would be possible by linking to 28 well-known landmarks in one NYC-sized city. Huge difference. As for slippery slopes, ski aficionados are travellers too :) and might not like their favourite slopes being used as a basis for a very tiresome cliché in discussions. The proposal was quite clear and unambiguous in what is or is not included as a possible link target. K7L (talk) 16:27, 8 February 2013 (UTC)Reply

I was referring to Wikivoyage:Slippery slopes and if this proposal were accepted it would give huge justification for the other two types of proposals I have mentioned. It doesn´t matter if we are talking about cities or landmarks-- you can easily find a page on WP with mentions of 28 cities or more, and it would be excessive to link to WV for all of them, just as it would be excessive for us to link to WP 28 times in one of our articles, much less pepper all of our articles with such links. Out. Of. Scope. Texugo (talk) 16:33, 8 February 2013 (UTC)Reply

Texugo - just to make sure we're talking about the same thing, this discussion refers to the proposal to add a link to Wikipedia in listing tags only, with the restrictions outlined in #Summary. I'm not seeing the slippery slope argument in that proposal since usage guidelines are very clearly specified. -- Ryan • (talk) • 16:43, 8 February 2013 (UTC)Reply

I am aware of that. But if we let this cat out of the bag, it will in the future lend a great deal of legitimacy to the idea of allowing them in other sections, and to allowing links to other sites with similarly detailed information, via some of the exact same rationale you are presenting. As pointed out above several times, the proposal provides no particular reason for limiting them to the listings section. Texugo (talk) 16:54, 8 February 2013 (UTC)Reply

Couldn't the exact same argument be made for the primary URL, or just about any other proposal to change anything on this site? Consider: we are very restrictive with external links, but allowing them in listings hasn't led to their usage in the rest of the article text. I'm concerned that a proposal has been created that provides very, very specific usage rules designed to avoid abuse, and invoking the slippery slope argument would seem to indicate a huge amount of inflexibility on our part when it comes to making changes. Without clear usage guidelines I would agree with you, which is why I've opposed use of Wikipedia links in article text, but I'm struggling to see how this specific proposal is in a slippery slope - how could someone misinterpret it to think that inline Wikipedia links are OK? -- Ryan • (talk) • 17:08, 8 February 2013 (UTC)Reply

I´m not saying it will cause people to put links elsewhere right away. I am saying that if we accept the rationale for this change, it will greatly support those who push to officially allow such links elsewhere, straying even further from our ext links policy toward further riddling our articles with wormholes. It basically breaks the relative logical consistency of the ext links policy that has been working fine for years. All of this is secondary to the question that if the info linked to is out of our scope, why should we make linking to it so ubiquitous? Texugo (talk) 17:18, 8 February 2013 (UTC)Reply

The official link is required for booking the hotel or making a reservation for the restaurant. The WP links just provide irrelevant background information. Adding travel blog links would make more sense. Globe-trotter (talk) 17:49, 8 February 2013 (UTC)Reply

Dining reservations are made by picking up the telephone. All the external URL provides is a link to vendor-supplied pages of self-promotional text filled with words to avoid in which the establishment touts its own wares. Instead of merely irrelevant, the "official" URL contents are as biased and self-serving as it gets - as these are businesses with a product to sell. K7L (talk) 18:19, 8 February 2013 (UTC)Reply

They do let the travaller see what they are getting though, photos of rooms and additional services, booking tools, menus, maps, etc. that is too detailed for us to provide. They can tout all they want there on their sites, since they have already gotten the thumbs up from us by virtue of our listing them in the first place. They aren´t really "biased" if we are already recommending them anyway. But all this is getting off the topic. I don´t think anybody has proposed us dropping primary listing links.Texugo (talk) 18:48, 8 February 2013 (UTC)Reply

More reasons: they're much harder to find than Wikipedia articles, we only link to each domain once, and they're invaluable to editors trying to keep things current. --Peter ^Talk 18:58, 8 February 2013 (UTC)Reply

There have been plenty of recent examples of users putting inline Wikipedia links to things other than listed attractions in articles - and sometimes in dozens of places within those articles. If we decide to allow one Wikipedia link per listing, instead of per page, what is the logical explanation we can give people for restricting the links to one a listing, when there are often non-listings that could use off-site explanatory content? Ikan Kekek (talk) 21:32, 8 February 2013 (UTC)Reply

Undecided

Summary

This is what's being proposed:

The Template:Listing would include a "wp" parameter that would produce something like the following:

Doxey Marshes Nature Reserve , Creswell Farm Drive, Staffordshire, ☎ +44 1889 880100. Wetland oasis and bird watching site. Blah blah blah...

Example of how it could look like Glacier National Park/sandbox.

Guidelines for usage of the "wp" parameter would be:

The link points to a WP article which describes only the specific site or location in the listing, not merely general description of a chain or franchisor. That may mean that the 14-room neon Route 66 w:Blue Swallow Motel qualifies (because of its listing on a national historic register) while the 100th or 150th cookie-cutter w:Journey's End Corporation site (as just another Comfort Inn) does not.
The target article must meet all existing en.Wikipedia standards, including the general notability guideline, and not be unsourced WP:SPAM or self-promotion as defined by WP's standards of neutrality. If the target belongs on WP:AfD, don't link to it.
The "wp" interwiki link is an adjunct, not a substitute for the "url" link to the official site for a landmark (if it exists). The two differ in purpose. WP should be neutral but based on reliable secondary sources, the "official" URL is promotional but also primary source. (Note: This new field depends on bugzilla:43220 as we need an editable {{listing}} template to be able to create any new fields.)
Neither the "wp" and "url" link is a substitute for including basic info (such as address, telephone, description) in the listing itself. The print version matters. If we can't determine why a listing is in the guide without going online to some other site, it doesn't belong in the guide.

Bug or choice: Lat and Long missing from current listings tool

Latest comment: 11 years ago9 comments6 people in discussion

Hi folks, not sure how I should raise this, or who with, but I wanted to alert the techs / community that we've dropped lat="" long="" from the insert tools. Is this deliberate or an oversight? JimKillock (talk) 18:29, 1 January 2013 (UTC)Reply

The message for the insert tools is MediaWiki:Edittools. The lat="" long="" and tollfree="" fields look to have always been missing, at least as far back as 2006 when Evan initially added the tags. I presume we do want the fields in listings (tollfree works now, lat/long will work if and when we use the {{listing}} template). K7L (talk) 19:55, 1 January 2013 (UTC)Reply

We've never had a consensus on how to use the lat/long fields, so I believe they were left off of the edittools template so that we didn't clutter the articles with empty or unused data. We never actively discouraged their use, but I think they were only wanted if they were going to actually be filled in. LtPowers (talk) 22:10, 1 January 2013 (UTC)Reply

I've added lat/long info in some listings and would like to see this field turned on (visible). Not sure if we want the coordinates displayed or hidden behind a symbol (like a map symbol that one would click/hover on to view coordinates). It would also be nice to have a template to add in prose to look better. For example: "There is also a smaller, southern entrance to Wildlife Sanctuary (0°0'00"N, 0°0'00"E) off Wikivoyage Road, 18 km south of the Main Entrance." AHeneen (talk) 06:54, 9 January 2013 (UTC)Reply

Coordinates are, unfortunately, ugly. And they don't translate easily into a meaningful visualization for most readers. I would absolutely not support displaying them in full, at least not online. I am also reluctant to add more icons to our listings, but I'm not sure how else to hide the lat/long. LtPowers (talk) 14:00, 9 January 2013 (UTC)Reply

I think adding a globe to match the one at the top of our articles, which would serve as a link to OSM with the listing plotted, would be a great addition. Even more important, though, is to have the field filled out for the future purpose of generating maps. I agree with LtPowers, though, that displaying the coordinates themselves would be too ugly. --Peter ^Talk 17:55, 9 January 2013 (UTC)Reply

I don't think that you should try and impose your aesthetics on others where listings are concerned. Personally, I find telephone numbers and addresses "ugly" but I'd never dream of suggesting they should be hidden under a telephone symbol or an envelope symbol respectively (or even removed entirely). Please remember that this is a discussion about our listings format and should really focus on what is of most value for the traveller. Aesthetics should be a strictly secondary consideration. -- Alice^✉ 22:20, 3 February 2013 (UTC)

If we use a globe for a map link, we should avoid using a globe to signify Internet, web or URL. K7L (talk) 06:09, 11 January 2013 (UTC)Reply

I'd suggest a compass rose for maps, instead. — Coren ^(talk-enwp) 15:42, 19 January 2013 (UTC)Reply

So {{listing}} needs to replace the map

with a compass, locator or arrow pointing north (I'd prefer to avoid using just a rose as it looks too close to a competing site's logo) and

with a simpler globe like

or

if these are to be iconified. The other option is to put the external URL back to as the link format we used to use... and do what with the co-ordinates? Display them as text? Hide them?

In this size, and to avoid being a distraction from the rest of the listing, any symbols need to be simple monochrome icon or line drawings like the mail

or access symbols

- nothing elaborate.

is more colour and gradient than we need. K7L (talk) 17:17, 20 January 2013 (UTC)Reply

Suggestion for price listing and currency conversion

Latest comment: 11 years ago17 comments10 people in discussion

Swept in from the pub

I am not sure if I am putting this in the right place, I ve been trying to figure out where suggestions for the entire site should go but anyway, I thought about when people list prices of services or products in a country that they use the local currency and there could be a feature where the user could have the currency converted to their own currency, so they can better understand what the price of things are. If someone tells me a ride on a bus in kazakhstan costs 40 KZT or whatever example I saw, I would like to have some feature that could tell me how much that is in dollars or euros, etc. I think it would really help the traveler's expectations of costs.--Elektroid (talk) 02:30, 20 January 2013 (UTC)Reply

It's an excellent suggestion that's been discussed a little bit, but it would require some development work. LtPowers (talk) 15:23, 20 January 2013 (UTC)Reply

This is a good suggestion & I don't know if this is the right place or not (other good locations would be Wikivoyage talk:Currency & Wikivoyage talk:Using Mediawiki templates). There are a few ways to go about doing this:

Current practice is that exchange rates should be quoted in the "Buy" section of a country page. Most pages have an exchange rate quoted for 1-2 major currencies in the last couple of years. On Kazakhstan#Buy: "As of June 2012, the exchange rates are the following: US$ 1 = KZT 149.01 € 1 = KZT 188.30". This leaves the burden on a reader to find the current exchange rate themselves & do the math. Doing the math is ok for most travelers, but finding the current exchange rate shouldn't be.
Using a template for each time a currency is mentioned. For example, the sentence displayed as "Admission is €10." would be written as "Admission is {{10|EUR}}.". The template would allow a user to select currencies to convert in a dropdown box. While this can be useful, the downsides (IMO) outweigh the benefit. First is the difficulty of inserting the template. New users would find that adding a template each time a currency/value is mentioned overwhelming and this would be a huge burden on experienced editors to go around and clean up (even with a bot, this would be difficult to keep up with). Another reason is that it might be easy to remember/quote a price in local currency "10 cedi for a bus ride" (not 5.23 USD), "Park admission is 8 cedi" (not 4.19 USD), and so forth.
Creating a template for the "Buy" section of country pages which lists the exchange rates for major currencies. The rates would be updated by users. The box would simply have "Exchange Rates for [Name of currency]" at the top and then 5 or so lines below listing exchange rates for each currency & the day/month updated.
Creating a template which links to exchange rate websites. A modified version of w:Template:Exchange rate, using/displaying rates from openexchangerates.org instead of using links to commercial sites. The rates included could be limited to fewer currencies (like just USD, EUR, AUD, CAD, GBP) or more relevant currencies to a particular country (eg. neighboring countries). When pages are exported for print/book versions, this template would convert into a box of exchange rates accurate to the time of printing or PDF creation (either listing major currencies or adding an option to the print screen or when creating books to select which currency(-ies) to include conversions for.
Creating a template (or just modifying on of the previous two suggestions) which basically functions as a calculator. It would have a box to enter a unit, then the nation's currency named, then a dropdown list of currencies to convert to, then a results box that displays the conversion. So the template would look like: "Convert [box to enter unit] tenge (KZT) to [dropdown list of currencies]. [Result]"

My preference is to combine the last two ideas: Have a template box to insert in the "Buy" section of country pages (and other regions with their own currency, like Hong Kong, Isle of Man, etc) with a list of current exchange rates and at the bottom include a conversion calculator. I don't have the software language knowledge to create a template, so it would be awesome if someone could create such a template. AHeneen (talk) 19:11, 20 January 2013 (UTC)Reply

Also see Wikivoyage:Cooperating_with_Wikioverland#Currency_conversion. Wikioverland's currency dropdown converter is pretty cool. --Peter ^Talk 19:26, 20 January 2013 (UTC)Reply

Yes, it's cool, but how could we use it for our texts, with prices listed on every second line? --Alexander (talk) 19:47, 20 January 2013 (UTC)Reply

Wikioverland has a template which includes a dropdown box. The dropdown box could be placed at the top of the page (or in MediaWiki:Sitenotice), and the prices could be given using templates with currency codes and amounts. --Stefan2 (talk) 00:14, 21 January 2013 (UTC)Reply

I would like to see possible solutions, but I am not sure that this currency converter is of high importance for our purposes. Once you are in the country, you have to pay in local currency, and you have to develop a quick conversion scheme, so it is better that you develop this scheme in advance when preparing the travel. It is also important to have some real prices in mind, so that you are not cheated or overcharged. Displaying everything in US$ may be a disservice to the traveller. --Alexander (talk) 19:47, 20 January 2013 (UTC)Reply

It would be great for country "costs" sections though. Using this to list gas prices along with a bundle of other basic goods (accommodation, price for fast food, street food, fancy restaurant, etc.) would be very helpful. --Peter ^Talk 20:01, 20 January 2013 (UTC)Reply

The price of petrol/gas/fuel is likely more volatile than the fuel itself. Good luck trying to keep that up to date, short of launching a site like gasbuddy.com K7L (talk) 21:56, 20 January 2013 (UTC)Reply

We could try to grab the information automatically from other sources, or just datestamp the prices. --Peter ^Talk 01:43, 21 January 2013 (UTC)Reply

I think that this would be a great idea. Recently, I came across the article Freighter travel (overland travel without a car) and found that the currency rates are awfully outdated. For example, it says that 75-100 US dollars

\approx

100-120 euros, which might have been the case about 10 years ago, but today Europeans would feel scammed if they were to get that rate when travelling to the United States. These currency rates were already out of date by several years when the prices were first included in the article, so maybe someone didn't understand the difference between multiplication and division. --Stefan2 (talk) 00:14, 21 January 2013 (UTC)Reply

A template that takes the local price and gives updated conversions seems feasible and a great help to the readers. Snowolf ^{How can I help?} 01:30, 21 January 2013 (UTC)Reply

We need not have special extensions, merely a template that handles this (not impossible at all, might be worth contacting User:Varnent about this), displays the local price and has a tiny button (or maybe one can just click on the symbol/name of the local currency) and he can see the price in at least the couple of major standard currencies. The conversion rates would be updated manually or by a bot. It is feasible, it is worth doing, and it would be a great boost in usability to our users. Snowolf ^{How can I help?} 01:33, 21 January 2013 (UTC)Reply

Over at Wikivoyage talk:Cooperating with Wikioverland There is talk about how WV can co-operating with WikiOverland. Once of WO's features is a real-time currency converter for prices and units. See Wikivoyage:Cooperating with Wikioverland#Currency conversion for an example and explanation of how it works and how to use it. WikiOverlanders are happy to share the custom MediaWiki plugin. -Dangrec (talk) 22:58, 22 January 2013 (UTC)Reply

Might, I first add, I am not very savvy with all of wiki technologies and which plugins are available to do what. As my suggestion originally was to help make the site more manageable for the traveler using this site to plan a trip. I think I am in the school of thought with using the WO plugin as currency rates sometimes are quite volatile but in some countries currencies are very static as they are pegged to another currency for stability purposes. My original concern and reason for the suggestion is that I travel a lot and using guidebooks for price indications even within a year or two of being printed are already obsolete in the foreign currency where the local currency is still about the same for prices.

However, when one prepares for a trip at least in my sake until I m there and familiar with the local currency a few days of buying things, I convert to my home currency. So my main reason was to better prepare travelers on how to budget. I think once in the country at least speaking for myself I become accustom to local currency and know how much things cost no longer needing a guide. I find a guide is most valuable in planning before the trip and maybe the first few days afterwards, it isn't so much an issue during the entire trip. I guess I advocate the drop down box with 5-10 main currencies as in Eastern Europe the USD along with the local currency is used, from my experience living in Ukraine and visiting Russia, Romania, etc. USD is carried and often used for wage payments and when travelers of this country go abroad they often convert to USD in order to more easily convert to another currency where ever they may be headed. Also, like in Ukraine in Russia, they are just as aware of the value of the USD as their local currencies and often cars, flats for sale are quoted in USD. Anyway, I am sorry for my long rambling as I just woke up but anyway, 5-10 currencies available to convert the local currency somehow would work great, imho. And now I shall shut up :)--Elektroid (talk) 20:10, 26 January 2013 (UTC)Reply

That's exactly how I feel too. Especially when trying to plan a trip where you need to know the gasoline prices, reading that it's 1423 Quetzales per gallon doesn't mean anything. It's much more useful to convert it to your local currency and unit (i.e. 2.3 Euro per liter or whatever). In the planning stage, it's essential. -Dangrec (talk) 17:51, 29 January 2013 (UTC)Reply

I would strongly suggest not putting conversation rates in an article. Inflation by itself makes it difficult to keep a current view on prices, and attempting to 'add value' by providing a conversion on some arbitrary date really doesn't help. An exception might be some locations that accept US Dollars or Euros for tourist attractions. --Andrewssi2 (talk) 04:33, 25 March 2013 (UTC)Reply

AHeneen is spot on when he suggests above having a template box to insert in the "Buy" section of country pages (and other regions with their own currency, like Hong Kong, Isle of Man, etc) with a list of current exchange rates (including a conversion calculator at the bottom). What do the WMF staff think about extra server loading - minimal? - and would they create such a template? -- Alice^✉ 04:15, 21 April 2013 (UTC)

Bug: Listing tag italicizing non-Latin scripts

Latest comment: 11 years ago7 comments5 people in discussion

Italics is a Latin concept, and should not be applied to scripts like Chinese or Thai. Programmatically, anything up to U+1EFF should be Latin, and above "non-Latin". Bugzilla time? Jpatokal (talk) 02:22, 22 January 2013 (UTC)Reply

<listing name="Xilin Pagoda" alt="西林塔 Xīlíntǎ"></listing>
<listing name="Khrop Khrueang" alt="ครบเครื่อง"></listing>

Yes, unless Bugzilla:43220 will give us the ability to do it ourselves in a couple weeks. --Peter ^Talk 02:26, 22 January 2013 (UTC)Reply

Has anything come of this? I've noticed that it's a significant drawback to our listings.Travelpleb (talk) 08:07, 28 April 2013 (UTC)Reply

I don't know much about the PHP side of things, but this could be solved using templates.

Method 1) Just like WP, create templates like w:Template:Nihongo that take care of displaying a specific language with the appropriate italics and markup. These should be used within articles for all foreign text. (And there's benefit to having them for languages that use the Latin script, even... in theory, tagging Spanish words with a tag could help text-to-speech readers pronounce them correctly, search engines index the pages, etc.)

Method 2) Add a nonroman= tag to Template:Listing, and have it display it in parens next to the alt= text, but without italics.

The downside to both of these methods, of course, is that they require touching every single page. Bigpeteb (talk) 15:31, 28 April 2013 (UTC)Reply

Is there no simple way to change the listings function itself? Going through each page would be a killer job.Travelpleb (talk) 16:52, 28 April 2013 (UTC)Reply

The mw:extension:Listings is currently just blindly feeding everything to the {{listing}} template. I recall some mention of an abilility to use the w:Lua programming language in templates as something WMF was testing or had recently introduced, no idea if that could do what you're looking for? K7L (talk) 13:41, 30 April 2013 (UTC)Reply

I have no idea, but I think that this isn't a massive or complicated job for someone who knows about computers.Travelpleb (talk) 06:53, 1 May 2013 (UTC)Reply

Problems with new XML listings format

Latest comment: 11 years ago14 comments5 people in discussion

Swept in from the pub

It's great to see that the "lat" and "long" (for WGS84 coordinates) for latitude and longitude are finally working after all these years but some things are not quite right. Is there a place I can correct them?

A trivial bug is the addition of an extraneous opening quote mark when check-in times are displayed eg: the only formatted entry in the "Sleep" section of our Wanaka article displays as:

Montrose Bed & Breakfast, 120 Mount Iron Drive, ☎ +64 3 443-2289. "Check-in: 14:00, check-out: 10:00. NZ$ 80-130. Home stay

instead of:

Montrose Bed & Breakfast, 120 Mount Iron Drive, ☎ +64 3 443-2289. Check-in: 14:00, check-out: 10:00. NZ$ 80-130. Home stay

Much more serious is that the e-mail format is possibly the worst imaginable. Not only is the full e-mail address displayed in blue lettering (useful for people that want to copy and paste to the e-mail programme of their choice or carry around the printed version to an internet cafe) but the redundant word "e-mail:" is there plus an envelope symbol. Talk about prolix overkill! 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:. -- Alice^✉ 02:04, 8 February 2013 (UTC)

It looks pretty straightforward to fix. What do we want it to look like? Is there a conclusion somewhere? --Inas (talk) 02:15, 8 February 2013 (UTC)Reply

My suggestion would be to just display the e-mail address which is self evident to anyone that uses it because of the @ symbol. No word "e-mail:", no envelope symbol and certainly no hotlink to the mailto: call (which sets off the blue colour). This is inevitably ugly but shorter than the current cock-up.

Is this format directly editable somewhere or is it protected code?

You saw what I meant about the extraneous quote mark just before the capital charlie in "Check-in:", did you? -- Alice^✉ 02:24, 8 February 2013 (UTC)

Russia is using code which looks like

. That hides the address behind the envelope icon. I'm not sure I agree with the envelope appearing in the printed version (as there's no way to use it there) but otherwise it might be an option if a consensus can be formed. K7L (talk) 02:40, 8 February 2013 (UTC)Reply

Hi! Unfortunately, anything labeled as "noprint" also disappears in the mobile version. Therefore, I had to keep all web-links and the e-mail address in print. If you know how to make things invisible in the print version but still available in the mobile version, please, tell me. Thanks! --Alexander (talk) 06:46, 8 February 2013 (UTC)Reply

There are always two tensions here. Those who want the listings pretty and as compact as possible (especially for the print version) and those who see the listings as inevitably ugly but a real service to the traveller (and especially those with on-line access). In this case my suggestion is that, like telephone, fax numbers, GPS co-ordinates and street addresses, e-mail addresses should not be hidden behind cute envelope symbols since otherwise it's difficult to phone, fax, find and visit if one is carrying just the printed version until one gets on-line later. I therefore intend to remove the horrendous computer buggering (unless you're a micksoft afficiando) mailto: hotlink and the extranous verbiage. -- Alice^✉ 03:04, 8 February 2013 (UTC)

It is directly editable at Template:Listing. --Inas (talk) 02:47, 8 February 2013 (UTC)Reply

Thanks. And I see the extraneous quote mark has now been removed -- Alice^✉ 02:56, 8 February 2013 (UTC)

Can we use a Wikipedia link in listings yet or is that still being discussed? Is there any agreed format to use in listings yet, if the decision has not been made yet so as to add a bit of future-proofing? -- Alice^✉ 03:21, 8 February 2013 (UTC)

As far as I know, Wikivoyage talk:Listings#Listings tags and links to Wikipedia is still deadlocked, basically a 50:50 split for:against linking to WP if a listing here has an article there, even though discussion has been open since the beginning of the year on this. K7L (talk) 03:32, 8 February 2013 (UTC)Reply

That was my impression too. However, I'm going to be adding a lot of see listings to articles shortly, many of which have long and detailed articles about their history on WP and I would much prefer to add the appropriate XML tags now rather than go back later and do tedious addendums. If the consensus is to switch them on, they would then display correctly if I get the formatting right and (if I don't format them correctly or) if the decision is not to turn them on, then they simply won't be seen and less of my time is wasted... -- Alice^✉ 03:39, 8 February 2013 (UTC)

It doesn't look like the proponents of linking to WP have been able to build a consensus to me. Therefore, for now, we won't be linking to WP. We don't close discussions here, so that position may continue to evolve. And Alice, we all know that secretly you just love those addendums! :-) --Inas (talk) 03:51, 8 February 2013 (UTC)Reply

As users from WP find us and wander over here, it won't be so much "may continue to evolve" as "is guaranteed to be a moving target". :) K7L (talk) 03:53, 8 February 2013 (UTC)Reply

Good job it's a wiki! :-) I look forward our new contributors joining the fray. --Inas (talk) 04:08, 8 February 2013 (UTC)Reply

I must say, I feel such a peace come over me, seeing the numbered blue xl links all disappear. --Peter ^Talk 04:40, 8 February 2013 (UTC)Reply

But those annoying blue, incrementally increasing numbers haven't all disappeared. We have hundreds of thousands of listings that have not been listingified. And now with the silly little grey globes you have created a perverse incentive for business owners not to use XML listings! -- Alice^✉ 04:53, 8 February 2013 (UTC)

That's assuming both that business owners actually can be bothered to learn how everything works here (good luck...) and that they like [32] after their name for some reason. K7L (talk) 05:02, 8 February 2013 (UTC)Reply

Why remove the blue text link which is intuitive and web standard for a link to a subject and replace with an ugly grey dot that is much more difficult to select than a whole word?--Traveler100 (talk) 05:27, 8 February 2013 (UTC)Reply

Can we consolidate any such discussion. Currently there are discussions happening in Wikivoyage talk:External links, Wikivoyage talk:Listings, and probably elsewhere. Since we're not just talking about Listings here, then the former looks like the right place to me. --Inas (talk) 05:55, 8 February 2013 (UTC)Reply

I see nothing much on the "external links" page, the discussion appears to be on the template's talk page, on this page and on Wikivoyage talk:Listings. I'd suggest consolidating to Wikivoyage talk:Listings. K7L (talk) 06:47, 8 February 2013 (UTC)Reply

Front linking and the reasoning that led us to the postlinking policy, are all at Wikivoyage talk:External links. See you at Wikivoyage talk:Listings --Inas (talk) 04:58, 9 February 2013 (UTC)Reply

backward step

Latest comment: 11 years ago39 comments12 people in discussion

Why the change in style of links? A grey dot for links to web page of the subject does not look look nice and is much more difficult to select than a web standard, and intuitive, link on the name of the subject?--Traveler100 (talk) 05:21, 8 February 2013 (UTC)Reply

I love the light gray globe—it's very unintrusive, and I think people will find it easily (since its used so widely). I'd honestly like to force all external links to appear like this. --Peter ^Talk 05:32, 8 February 2013 (UTC)Reply

I would actually agree that the gray globe isn't intuitive enough. I don't like making the full listing name blue as I think that calls too much attention to it, but changing the gray to something like (or possibly something from commons:Category:External link icons) might be more user-friendly. -- Ryan • (talk) • 05:48, 8 February 2013 (UTC)Reply

I'd prefer your variant to any in that category. --Peter ^Talk 05:55, 8 February 2013 (UTC)Reply

I also prefer the grey globe over the old bracketed number sort of external links which looks like bit of code. It isn't obvious at all that it's an external link if you don't have a basic understanding of wiki editing. The issue with the grey globe is that it's too small for most people to recognise it as a globe. I think we should try and enlargen it slightly, to make its image clearer. I am also against any non-monochromatic icons; it will make the page too bright and lively, looks kiddish and also takes longer to load. JamesA ^>talk 06:00, 8 February 2013 (UTC)Reply

Yeah a grey globe icon is non-obvious and a tad small. Could we compromise by making the globe blue? Also, is there a way to move the lat-lng position into the directions space, otherwise it just looks awkward in between the phone and price. And perhaps a Maltese Cross icon.

Mr Hyde, , 11 Malop Street (just down the road from Geelong Station), ☎ +61-3 5223-1228. Cocktails $16-22, Pizzas $18. Mr Hyde is a trendy bar and restaurant with a wide variety of spirits and wines.
Mr Hyde, , 11 Malop Street (✠ just down the road from Geelong Station), ☎ +61-3 5223-1228. Cocktails $16-22, Pizzas $18. Mr Hyde is a trendy bar and restaurant with a wide variety of spirits and wines.
Mr Hyde, ✠ 11 Malop Street (just down the road from Geelong Station), ☎ +61-3 5223-1228, . Cocktails $16-22, Pizzas $18. Mr Hyde is a trendy bar and restaurant with a wide variety of spirits and wines.

I think the third looks best actually. - Torty3 (talk) 06:30, 8 February 2013 (UTC)Reply

I really am puzzled by the thought processes that have meant we are even discussing all these non obvious methods and esoteric symbols.

Surely the decision making should go along these lines:

Do we have a clear policy that dictates what external links are helpful to the traveller to have in our guides? (yes?)
Do we wish the hyperlinks to be visible and intuitive and easy to action whether using a small touch screen on (for example) a smartphone or by using tabs on primitive devices? (yes?)
Do we wish the listings to occupy as little space as possible in all versions and for non-functional parts in the print version to be hidden? (yes?)
Do we wish casual readers of our guides to have a steep learning curve with a lot of non-intuitive, non-standard navigations and symbols? (no?)

If the answers are as I suggest in brackets, then the answers seems obvious:

return to the old format where those listings with a primary URL display the listing title (or "name") in blue as the traditional clear signal that the bolded name itself is the hyperlink.
implement a bot to seek out all those non- listingified entries and convert the URL's to a display format where they are converted to display a hyperlinked www symbol (and without the baffling incremental numbers). -- Alice^✉ 08:13, 8 February 2013 (UTC)

Front-linked URLs look spammy and hideous, I'm definitely against that. But I think the old format looked better than the globes... Globe-trotter (talk) 11:13, 8 February 2013 (UTC)Reply

I also hate front-linked URLs because not only do they look spammy and ridiculous, but they excessively highlight listings which have websites over those that do not, which is not fair since having a website does not necessarily mean your establishment is more recommendable for use than one which does not have a website. I don´t particularly like this gray icon either though. I like the blue globe, the same color as other links on the page... Texugo (talk) 11:43, 8 February 2013 (UTC)Reply

Agreed with the above on why I don't want front-linking. I rather like the blue globe; blue is sort of the universal color for external links on the internet, so I think we should work with that. Gray is just too subtle and non-intuitive. Alternatively, if we don't like the globe, what if we used the little arrow icon that shows up after a link? PerryPlanet (talk) 17:42, 8 February 2013 (UTC)Reply

That arrow is good. It's a kind of universal wiki symbol for external links. Globe-trotter (talk) 17:52, 8 February 2013 (UTC)Reply

The gray globe is too small. And why a globe? I know the web was called the World Wide Web when it was first invented, but don't people just call it the web now? In a worldwide travel guide, the world is for travelling (just like the WV logo), not for linking to the web. So we could have an icon of a spider's web, but I think the arrow is quite good. Nurg (talk) 01:34, 9 February 2013 (UTC)Reply

The link used to appear after the address, phone nos etc. Now it appears straight after the name. So we are suggesting: here's the name, here's the link, off you go, come back if you want to read the rest of the info here. We should be saying: here's all our info, if you want more info, here's a link. So the link should be at the very end of the listing. If that's too radical, then revert to having it after the address, phone nos etc. Nurg (talk) 01:16, 9 February 2013 (UTC)Reply

I know that we have little chance of overturning the anti-frontlinking consensus. However, I have to say (just for the novelty of it) that I agree with Alice. If we were building the Interwebs again, we could build them how we want them, where links were all after terms, and words weren't linked, and it would be a beautiful place. However, we're not. We're a salmon swimming upstream. People expect the words to be linked, and our method isn't what editors or readers expect.

In addition to this, it takes more real estate - something that is precious.

In addition to that, it it logically separates what is being linked from the link. The idea (that google and others leverage) is the the reference text points to the link. --Inas (talk) 05:06, 9 February 2013 (UTC)Reply

But how would you sidestep the fact that front-linked listings would be so unfairly highlighted over those listings which do not happen to have a website(and may never have one). Just because a place doesn't have a website doesn't necessarily mean it is inferior enough to have only its name in a dull black color next to other spiffier listing titles in attention-grabbing blue. Small icons or even the bracketed number links we had before are more fair in terms of providing a list of recommendable places. I don't want titles of places with links to be all lit up just because they have a link while other listings don't . Texugo (talk) 07:11, 9 February 2013 (UTC)Reply

Because that blue text isn't a highlight, it is your browser's indication that there is a hyperlink in the HTML. That is what browsers do to indicate an anchor text that is linked, and HTML defines anchor text for this precise reason. In other words, it signifies that there is a website, which is exactly what we want to signify. It does this in a way that everyone already understands because this is how it is done on every other website. Making WV different is fighting for Beta against VHS - it doesn't much matter which one is better. We're different from everywhere else, so our readers don't understand what the funny numbers are for or we have to invent non-standard iconography. Our new editors invariably get it wrong. It's a mess --Inas (talk) 07:40, 9 February 2013 (UTC)Reply

I know what it's for and I know how it is used on other websites, but we are never going to have links for every listing, and in a list where some titles are glowing and some are not, it effectively highlights some listings over others. Plus it's just plain ugly to have lists where some titles are black while arbitrary titles are in blue.Texugo (talk) 14:23, 9 February 2013 (UTC)Reply

What about a compromise between the unobtrusive icon and the front-linked text? We could leave the title as plain text, but instead of an icon use text like "website", shrunk to a reasonable size (note: the icon after "website" will need to be removed with CSS, but that can be done by modifying MediaWiki:common.css with something like "div#content .listing-extlink a.external { background: none; font-size: 85%; }":

Mr Hyde, 11 Malop Street (just down the road from Geelong Station), ☎ +61-3 5223-1228, website. Cocktails $16-22, Pizzas $18. Mr Hyde is a trendy bar and restaurant with a wide variety of spirits and wines.

That should be intuitive for readers but still fairly unobtrusive. It takes up a bit of extra screen real-estate, but I think the usability trade-off makes that acceptable. -- Ryan • (talk) • 16:57, 9 February 2013 (UTC)Reply

It's likely that I hate seeing external links because of six years of patrolling their addition by spammers—I much prefer to see them emphasized less rather than more. Again, I'd rather users spend their time here, so why draw so much attention to ways to leave? Thus, I like icons. If we are going with a text link, though, could we use "web" instead of "website," and ditch the arrow icon after it? --Peter ^Talk 17:10, 9 February 2013 (UTC)Reply

For clarity I've updated MediaWiki:common.css as described above to remove the icon. -- Ryan • (talk) • 17:23, 9 February 2013 (UTC)Reply

I'm basically with Peter. I'd prefer an icon (I'd prefer the blue link color), and if we absolutely must have a text link I'd prefer it to be short like "web" with no arrow icon.Texugo (talk) 17:50, 9 February 2013 (UTC)Reply

How widespread is the problem you are identifying? In a list of attractions, hotels, etc, exactly how many wouldn't have websites? In a year's time will it be a problem any more? I'd say every single hotel, attraction, bar, etc in AU would have a website. I'd say pretty much the same would be the case for the U.S. and Canada. Surely it can't be too much longer for the rest of the world. --Inas (talk) 23:15, 9 February 2013 (UTC)Reply

I can think of plenty of cases of neighborhood landmarks that are of architectural interest but where they have no website or their website would be of little help (unless you wanted to rent space in the building), such as most of what's in Pittsburgh/Downtown#See. Or how about small, hole-in-the-wall restaurants that haven't gotten around to making a website? Or, even if you wanted to pretend that everything in the world has a website, there's the simple fact that not everyone is going to remember to add the website. So why punish them for excluding it? PerryPlanet (talk) 23:38, 9 February 2013 (UTC)Reply

Punishing them is an extremely strong term for what we are doing. Omitting the website may actually be a far greater punishment. When I look at Queenstown_(New_Zealand)#Drink it shows the problem we are discussing, but I think the missing websites could be added quite easily, and this would give us a greater incentive to do so. Neighbourhood landmarks I agree may be missing websites, but these may naturally fall into a small section of their own, where missing links may not distract from the formatting.

Even if we agree on some innocuous mark or icon for websites in listings, it is still going to be different to websites embedded in the prose, unless we're going to build some template for that too? --Inas (talk) 00:10, 10 February 2013 (UTC)Reply

At the risk of labouring what I feel as obvious I think I need to state the obvious again. Unless we make it completely hidden and secret, there will always be a difference between those listings with helpful URL's listed and those without. The question as to whether we "punish" those without URL's listed is a false one for at least two reasons:

Whatever way we mark the URL there will always be a difference between those listings with URL's and those without
If we return to the world wide hyperlink standard of either having the "name" of the listing in blue or underlined then, in some countries already and increasingly so throughout the world, it is the listings without whatever hyperlink marking we choose that will become the minority (and thus "stand out" as different). Those people proposing the "unfair punishment" ~~red herring~~ argument, better start putting forward proposals for randomly changing the order of Sleep, Eat, Drink, Do and Buy listings - our current alphabetical listing policy is unfairly "punishing" the Yankees and Zulus of this world. What about those restaurants with very long and contrived names? Shouldn't we be proposing a policy of arbitrary truncation at the 7th consonant to avoid them grabbing an "unfair" share of the limelight?

If we are truthful about putting the interests of the traveller (rather than business owner) first then no explanation or justification of having the name as anchor text is necessary - it is self-evident. Contrariwise, it is a self-defeating policy to try and think up the most obscure and non-intuitive way of showing a hyperlink. Either we keep the policy of having hyperlinks to primary URL's and use the world wide convention for these hyperlinks (sans unnecessary hickeys and meaningless incrementing numbers and obscure symbols) or we re-think the whole xl policy. -- Alice^✉ 01:06, 10 February 2013 (UTC)

The use of colour in listings is a distraction. Unless it serves some specific purpose (like {{NYCS}}, where it identifies a specific transit route) I don't see any real benefit to the traveller. K7L (talk) 01:37, 10 February 2013 (UTC)Reply

Okay, let's keep this conversation in perspective. A "red herring" is an arbitrary matter put forward for the sole purpose of diverting attention from the issue at hand, and calling someone's honest concern a red herring implies the intention to impede this conversation. Let's not go there. If it makes everyone feel better, I'll retract my "punish" comment. You guys are right, that was too strong a term. Let's just take a breather, folks. PerryPlanet (talk) 01:29, 10 February 2013 (UTC)Reply

The purpose of a blue colour would be the same purpose as it has in most of the world wide web; to signify what part of the display is a hyperlink (that can be clicked on with a mouse, tapped with a finger or stylus or tabbed to in some operating systems). Nothing more and nothing less. If colours distract one, one can look at the print version where even internal links will not have that blue colour that some sensitive souls find offensive. -- Alice^✉ 01:45, 10 February 2013 (UTC)

As I said in my original contribution, I know the anti-frontlinkers have an argument. I know it is the status-quo, and we're unlikely to reach a new consensus simply on the basis of that's the way it is done everywhere else. However, I would ask that those proposing icons, additional linked text, etc, to please propose a holistic solution here. It is simply inadequate to have one solution for links in listings, a second for links in the text, and a third for prominent pages like the Main Page where we want them to look nice and standard, and use frontlinks.

We know frontlinks will look the same everywhere. We should require a level of consistency from whatever alternative is selected --Inas (talk) 02:17, 10 February 2013 (UTC)Reply

Um, why would we be placing true-external links (frontlinked or otherwise) on the main page to external (non-WMF) sites? K7L (talk) 02:28, 10 February 2013 (UTC)Reply

We used to have some (wikitravel press, et al) that were front linked. It appears the only one currently is the licence link to CC, and that is frontlinked. No big deal there, so I guess that leaves the other two. --Inas (talk) 04:41, 10 February 2013 (UTC)Reply

I think using, say, that blue globe as a replacement for our old blue [37] sign would be great in both listings and general prose. --Peter ^Talk 05:50, 10 February 2013 (UTC)Reply

Which one,

,

or

? K7L (talk) 18:12, 10 February 2013 (UTC)Reply

If I had to choose from those three, definitely the third. We really shouldn't have bright, colourful icons, and the first two will just look out of place. JamesA ^>talk 06:20, 11 February 2013 (UTC)Reply

Definitely the third one. And Inas, what I am requiring is also consistency, in the appearance of all listing titiles.Texugo (talk) 06:52, 11 February 2013 (UTC)Reply

Yes, the third. --Peter ^Talk 21:58, 11 February 2013 (UTC)Reply

If we do replace the monochrome globe with a blue one, perhaps it should be a less bright colour (such as navy blue instead of bright blue) to be less of a distraction from the rest of the listing? K7L (talk) 23:33, 11 February 2013 (UTC)Reply

Texugo - if we want this to be consistent for templated listings, and other hyperlinks in the prose, we're going to have to develop a template like {{url|}} for this. We're going to have to replace the standard mediawiki way of indicating links with our own custom way. I'm very sceptical that it will work. To template-ise every hyperlink added by an editor is a serious patrolling job. Either that, or we resign ourselves to normal wiki formatted listings and links looking very different to xml listings. --Inas (talk) 22:29, 11 February 2013 (UTC)Reply

The most common external links (outside the individual listings) are the links to the city hall or official visitors info in the article introductions. That'd be one per page. Other than these, "In-article text links: Links within the article text should be kept to a minimum and should point only to primary sources. Examples of valid links might include airline companies, bus companies, and sites offering daily updates and warnings about a destination's condition".

We don't have an External Links section on our pages. This is by design. K7L (talk) 22:54, 11 February 2013 (UTC)Reply

In the Sydney article, for example, there are 58 links outside of xml listings and 28 within xml listings. I believe they all pretty much comply with the appropriate policies. --Inas (talk) 02:56, 12 February 2013 (UTC)Reply

This is a really hard thing. LtPowers (talk) 21:48, 16 February 2013 (UTC)Reply

LtPowers: do you mean that

a) devising a way not to give a perverse incentive to marketeers not to listingify their entries in the approved templated style "is a really hard thing" or

b) devising a way to be consistent for templated listings and other hyperlinks in the prose "is a really hard thing" or

c) devising a way to make all links (not have the annoying and misleading incremental numbers) intuitively obvious to all readers that they are clickable hyperlinks "is a really hard thing" or

d) devising a way to make a subtle visual distinction between an internal link (that remains on the WMF's servers) or an external link (that will hyperlink the reader to a newly spawned tab or window at another domain) "is a really hard thing" to do or

e) something else entirely "is a really hard thing" ? -- Alice^✉ 22:24, 16 February 2013 (UTC)

b) and d), I suppose. LtPowers (talk) 02:05, 21 February 2013 (UTC)Reply

Thanks for that clarification and I believe I have a workable solution to both.

Unfortunately, before I spend time in my "Kitchen" exemplifying a solution to concerns b) and d), I see that I now need to urgently concentrate on persuading people that should know better that my real name is not W. Frank Bucholz, I am not of German nationality, I don't live in central Glasgow, Scotland, I've never worked in the bank card industry, I am not bald, I was not born in Dresden in the closing years of the second world war, I've never driven trucks across the Sahara (but also can not write any Arabic), etc, etc. In short, that I'm not an Asian version of Sooty with an elderly German's fingers stuck up her bum. On the plus side, this is all ludicrously easy, I just have to roll up somewhere clutching (my non-German) passport, (non-German) driving licence, (non-German) credit cards, etc and get a trusted admin/Steward/Bureaucrat to inspect both me and my bona fides. The hard part is in finding someone willing to risk making Fitzgerald look like a complete plonker. -- Alice^✉ 03:15, 21 February 2013 (UTC)

Not helping e-mail spammers

Latest comment: 11 years ago8 comments7 people in discussion

I don't think we're being very good netizens by publishing all these e-mail addresses in clear text to be harvested by e-mail spammers.

Could someone design a bot to remove all the @ symbols and replace them with a small image of an @ symbol to make it a little more difficult for them? -- Alice^✉ 08:29, 8 February 2013 (UTC)

So long as the link is clickable then the spammers will grab it from the page source, no matter how it is displayed, so replacing the text with a symbol won't make it any more difficult. Spam filters work well enough these days that publishing email addresses shouldn't be a big problem, and I also suspect most businesses would be happy to trade the added publicity for a bit of spam. -- Ryan • (talk) • 16:10, 8 February 2013 (UTC)Reply

I disagree. Every spam filter will have some false-positives and false-negatives. If there's a website and an e-mail address, list just the website. Only list e-mail if it's the only means of contact provided. If the venue wants their e-mail address harvested, it can be left on their own site. K7L (talk) 16:15, 8 February 2013 (UTC)Reply

How do we marry this with our offline use requirement? --Inas (talk) 05:07, 9 February 2013 (UTC)Reply

Can email addresses be shown in the format "businessname at domainname dot com" instead of as actual email addresses? That would solve both problems, I think. Ikan Kekek (talk) 05:51, 9 February 2013 (UTC)Reply

Any standard pattern that we employed across the entire site would be a breeze for the spammers to reverse engineer. The more I think about it, the more I think that just isn't our problem. We put the email address in because it is best for the traveller to have it there. --Inas (talk) 07:44, 9 February 2013 (UTC)Reply

So if there is no way to make it spammer protected can it then be an actual active email link that you just have to click on? --Traveler100 (talk) 18:32, 10 February 2013 (UTC)Reply

Our printable versions render differently. We can just have an icon link for email in the web version, and have it spelled out in the print version. --Peter ^Talk 16:37, 9 February 2013 (UTC)Reply

I agree with Inas. If a spammer wants to scrape all the emails, whatever you do to the email display on the page, it won't be a problem for the spammer, until you start to display a captcha before every single edit-page load. And also as worse: you would have to remove all the mail addresses from the database dumps. ML31415 Mail Talk 18:25, 10 February 2013 (UTC)Reply

Conclusion: Nothing WV can do except to encourage editors not to harvest e-mail addresses from Captcha protected websites or websites where only images of e-mail addresses (as opposed to text that can be copied to a clipboard) are displayed by the webmaster in an attempt to limit spam. -- Alice^✉ 03:41, 12 February 2013 (UTC)

Sharing Options

Latest comment: 11 years ago3 comments3 people in discussion

Swept in from the pub

Hey everyone. Could someone add sharing options (such as emailing and sharing to Facebook, Twitter, etc) to each travel page so people could easily email their travel info to themselves and other people? Sharing functions aren't really needed on Wikipedia, but are probably more important for a travel site, and most websites nowadays have some basic sharing options such as AddThis and etc. It would be great if we could have some sharing options here on Wikivoyage, and I hope the community will be able to introduce this feature in the future. Thanks. —The preceding comment was added by 38.106.172.254 (talk • contribs)

We've talked about it but haven't had time to take any action on it. It's a bit low-priority at the moment. LtPowers (talk) 15:06, 15 January 2013 (UTC)Reply

Similar proposals has been discussed at Wikipedia and generally rejected on the basis of privacy concerns and on the basis of the horrible politics that would arise in choosing which sites one would put on the list of sites to share to. (Not that Wikivoyage should blindly follow Wikipedia, but it's worth contemplating the reasons why we've rejected it over on 'pedia.) —Tom Morris (talk) 16:16, 15 January 2013 (UTC)Reply

There has been some discussion at Wikivoyage talk:Listings about changes to business listings. That page is quite long, so you'll have to scan through all that to find the suggestions (sorry, I don't have time to do that). In addition to the "what sites to choose" issue, there's also the problem of fees and liscenses associated with incorporating those sites' features onto Wikivoyage. AHeneen (talk) 19:26, 15 January 2013 (UTC)Reply

Listing editor

Latest comment: 11 years ago7 comments5 people in discussion

Swept in from the pub

I've started working on a listing editor. As I can only work on this on some evenings, don't expect more than a very rough version in a week or two. —Ruud 23:39, 21 February 2013 (UTC)Reply

I think you'll have dancing in the virtual streets if we can get as far as a rough version in a week or two. LtPowers (talk) 01:31, 22 February 2013 (UTC)Reply

I've done a few turns just at hearing that you're working on it! Perhaps you'd like to take a look at Wikivoyage:Roadmap/Improved editing interface? --Peter ^Talk 02:47, 22 February 2013 (UTC)Reply

That's fantastic! A rough version in a couple of weeks would definitely lead to dancing in the streets! --Nicholasjf21 (talk) 08:57, 22 February 2013 (UTC)Reply

Beta 1

Under the motto of "release early, release often", I can announce beta 1 of the listing editor. Note that this version will corrupt and lose data, so always check the diff after testing.

You can enable the listing editor by adding the following line:

importScript( 'User:Ruud Koot/Listing editor/beta1.js' );

to your Special:MyPage/common.js.

Known issues include, but are not limited to:

not all field are handled yet
- cannot edit URLs
- 'lat' and 'long' will be lost on save
round-tripping is terribly incomplete
- e.g. Wikilinks will be turned into HTML anchors
missing (must have) features
- add additional fields to listings
- add new listings
does not fail gracefully on errors
does not remove "save" button while saving (you can accidentally press it twice)

—Ruud 15:09, 23 February 2013 (UTC)Reply

Thanks. This is wonderful work! I have started testing this, but quick comment. Is it possible for this to handle multi-paragraph listings, e.g. Udupi#See?

Multi-paragraph listings should not be a problem. You do seem to have triggered some other bugs, though. —Ruud 21:26, 25 February 2013 (UTC)Reply

Ah I see. Thanks for cleaning up after me. —Ravikiran (talk) 04:36, 26 February 2013 (UTC)Reply

Status of the UI for the edit and add buttons

Latest comment: 11 years ago1 comment1 person in discussion

Where can get get a status update on getting the UI added to MediaWiki for the Editing Tools? Is there a bug report for this feature? Is there a sandbox area where we can play with them or have they not been created yet? Slacka123 (talk) 21:35, 17 March 2013 (UTC)Reply

Create tags in other languages

Latest comment: 11 years ago3 comments3 people in discussion

I would like to create tags like <eat>, <sleep> in Vietnamese but I don't know how to do it, we already have template {{listing... Is it from meta? Thanks.--Cheers! (talk) 04:50, 4 April 2013 (UTC)Reply

If the <eat>,<sleep>, etc. xml tags have not been used on Vietnamese, I would suggest it is better to just go with the {listing}-style template-- the xml thing has to be set up behind the scenes, and from what I hear, the tech department guys are not a big fan of us using that kind of xml thing. Here on en:, the xml tags have just been made into a redirect to the mediawiki template anyway. Plus, the mediawiki template will be more customizable later down the road. Why would you need the xml one? Texugo (talk) 11:24, 4 April 2013 (UTC)Reply

The <listing> tags are generated by an extension, mw:extension:listings, which is not currently installed on Incubator or on anything outside Wikivoyage. On en: and ru: the tag data is merely fed to the {{listing}} template; de: doesn't use the tags, instead calling {{vCard}} (their version of {{listing}}) directly. The extension does nothing which couldn't already be done by using {{listing}}. K7L (talk) 00:56, 5 April 2013 (UTC)Reply

Tags to templates

Latest comment: 11 years ago76 comments11 people in discussion

Proposal

There's been a little discussion about whether to switch from listing tags to templates, but no real agreement on if it should be done, and on how to go about it. This will make no difference to readers, as the xml tags are already mapped to templates, but will have quite an impact on editors and future development from maps to a listing editor. Right now development efforts are being split between en and de, and what works for one will not work for the other. Templates offer easier expansion of fields and options, and may potentially be easier to parse and script.

The gist of it is that tags:

* <drink name="Mr Hyde" alt="" address="11 Malop St" directions="three blocks east of Geelong Station" lat="-38.1467" long="144.3589" phone="+61 3 5223-1228" tollfree="1800 123 456" email="" fax="+61 3 5223-1231" url="http://www.mrhyde.com.au" hours="Daily 11:00–03:30" price="Cocktails $16-22, pizzas $18">Mr Hyde is a trendy bar and restaurant with a wide variety of spirits and wines.</see>

should be switched to templates, perhaps through using a bot (any volunteers?)

* {{listing |type=drink |name=Mr Hyde |address=11 Malop St |directions=three blocks east of Geelong Station |phone=+61 3 5223-1228 |tollfree=1800 123 456 |fax=+61 3 5223-1231 |url=http://www.mrhyde.com.au |hours=Daily 11:00–03:30 |price=Cocktails $16-22, pizzas $18 |lat=-38.1467 |long=144.3589 |Mr Hyde is a trendy bar and restaurant with a wide variety of spirits and wines. }}

I think the bot is doable as long as the existing syntax is correct: test. --Traveler100 (talk) 18:03, 3 May 2013 (UTC)Reply

Note that if we're going to make this change we should definitely make eat, drink, sleep, etc templates that automatically pass the "type" attribute to the listing template to keep things shorter and simpler. -- Ryan • (talk) • 18:10, 3 May 2013 (UTC)Reply

Created the templates and change the bot method. Example at Mainz. We need to test these templates with more examples and variations. Also would like some page suggestions to test the bot. Only restriction so far found is that the name parameter in the old tag must be on the first same line as the tag header. --Traveler100 (talk) 09:29, 4 May 2013 (UTC)Reply

Comments

While there are workarounds, it just seems better to merge sooner rather than later, and not multiply the workload. -- torty3 (talk) 06:15, 3 May 2013 (UTC)Reply

I'd be in favor of this change since templates are better understood and the XML seems to be easy for users to mess up (such as when a quotation mark is missed or an attribute is misspelled). However, if there is agreement to switch we might want to discuss the recommended way to format these since they'll be appearing everywhere - for example, it might be easier to read if we recommend putting parameters on their own lines, such as:

* {{drink
| name=Mr Hyde
| address=11 Malop St
| directions=three blocks east of Geelong Station
| phone=+61 3 5223-1228
| tollfree=1800 123 456
| fax=+61 3 5223-1231
| url=http://www.mrhyde.com.au
| hours=Daily 11:00–03:30
| price=Cocktails $16-22, pizzas $18
| lat=-38.1467
| long=144.3589
| Mr Hyde is a trendy bar and restaurant with a wide variety of spirits and wines.
}}

-- Ryan • (talk) • 06:44, 3 May 2013 (UTC)Reply

I certainly like the idea, and I agree with Ryan that each field should have its own line. --Alexander (talk) 07:20, 3 May 2013 (UTC)Reply
It's more readable that way, but it's going to make the source of our guides extremely long. Not byte-wise, but as far as amount of scrolling goes. LtPowers (talk) 12:40, 3 May 2013 (UTC)Reply

I can't really comment on this aside from the user experience standpoint, but I think the template format would be much easier for editors. Losing the wacky problem caused by some </end> tag missing would be a relief too. Having parameters on their own lines would also make things easier for editors. To LtPowers, why would more scrolling in the edit window be a problem? --Peter ^Talk 16:03, 3 May 2013 (UTC)Reply

You've never had to scroll through the source code looking for something? It would take forever this way. It also means you can only see about 1.5 listings in the edit window at a time; that can make it hard to edit and/or compare multiple listings. I'm not saying it's a huge issue but it's an issue. LtPowers (talk) 18:49, 3 May 2013 (UTC)Reply

To your first point, I'm a big Ctrl+F guy. I get the second point—I guess that's the trade off. If we finally get our listings editor, ease of editing the code will become less of a concern. Either way, I'd be happy to see us switch (fully) to templates. --Peter ^Talk 19:27, 3 May 2013 (UTC)Reply

From my WP experience, I agree with LtPowers's 2nd point and prefer the one-line format. Agree too though that it's not a huge issue. I'm not aware that WP recommends one format over the other. I do think that if the one-line format is used we should recommend that a space be used before each bar/pipe, as in the sample above. WP now has a lot of the following format, which, in the edit box, wraps poorly and is difficult to read: "fax=+61 3 5223-1231|url=http://www.mrhyde.com.au|hours=Daily 11:00–03:30". Nurg (talk) 22:54, 3 May 2013 (UTC)Reply

I hadn't looked carefully enough—just putting those spaces before bars makes it much easier to digest. --Peter ^Talk 23:15, 3 May 2013 (UTC)Reply

Does anyone have a suggested alternate for the preferred format of these listings in articles? For example, it might be possible to combine some of these fields via something like

| latlong={{latlong|-38.1467|144.3589}}

(note: I haven't actually tried this yet, but I suspect it is possible). I agree that it's a shame to take up so much space in the editor for individual listings, but I think that disadvantage is greatly outweighed by making it much easier for non-tech-savvy folks to quickly figure out how to update an existing listing. -- Ryan • (talk) • 20:21, 3 May 2013 (UTC)Reply

I would love to switch out lat/long format to accept nothing but a comma separator e.g., "38.93431,-77.051353". That's usually how they are presented, and would make copy-pasting a lot quicker. --Peter ^Talk 23:15, 3 May 2013 (UTC)Reply

I think we'd have to parse out the comma, which might negatively affect performance given the number of listings on some pages. LtPowers (talk) 23:43, 3 May 2013 (UTC)Reply

In terms of the code formatting of the template, I'd say give each parameter their own line. I know it will make edit windows very long to scroll through, but if users edit by section rather than the entire page, it won't be that bad. I don't really understand LtPowers' second issue. I know there are cases where you need to compare 2 different listings, but the times when you can view them both in the same editing window because they are only 2-3 listings apart is rare. I don't see why you can't just duplicate the tab and have the two listings in two tabs, or side-by-side in windows. JamesA ^>talk 13:31, 4 May 2013 (UTC)Reply

I would prefer the one-liner for compactness (much easier to bulk edit listings), and since the listing editor might hopefully be finished by the end of this month, then casual editors could just use that and not even look at the template. Not too fussed either way though. -- torty3 (talk) 17:00, 4 May 2013 (UTC)Reply

What about a compromise that splits lines by functionality? For example:

* {{drink
| name=Mr Hyde | url=http://www.mrhyde.com.au | email=email@mrhyde.com.au
| address=11 Malop St | lat=-38.1467 | long=144.3589 | directions=three blocks east of Geelong Station
| phone=+61 3 5223-1228 | tollfree=1800 123 456 | fax=+61 3 5223-1231
| hours=Daily 11:00–03:30 | price=Cocktails $16-22, pizzas $18
| Mr Hyde is a trendy bar and restaurant with a wide variety of spirits and wines.
}}

That way we shrink 14 lines down to 7 while still maintaining some of the readability advantages of not having to search through a huge block of text to find each individual template parameter. "Sleep" listings would end up with an additional line for checkin/checkout, but that's still half the size of what we would have with each item on its own line while still being much, much easier to edit (IMHO). -- Ryan • (talk) • 17:43, 4 May 2013 (UTC)Reply

That would be a big improvement. LtPowers (talk) 00:37, 5 May 2013 (UTC)Reply

Sounds good to me. JamesA ^>talk 02:14, 5 May 2013 (UTC)Reply

The groupings themselves are useful independent from the handy compromise solution being offered. Yes! --Peter ^Talk 03:06, 5 May 2013 (UTC)Reply

I suppose i could live with that too. Also think that, at least in the copyable/insertable version, it should include the "description=" parameter text, since for people inserting them for the first time it is not obvious what a blank line is for. It also may help reduce that problem where people insert a template and then start the description after the closing bracket instead of before it... Texugo (talk) 12:04, 5 May 2013 (UTC)Reply

Note there currently is no description= parameter but there is a content=. Traveler100 (talk) 12:10, 5 May 2013 (UTC)Reply

Ah, you're right, but that is beside the point. "Content=" is fine, but there definitely needs to be something there.Texugo (talk) 18:19, 5 May 2013 (UTC)Reply

I've updated the examples on Template:Listing#Example and Template:See#Example to reflect the proposed usage. Does that look correct? If so, any objection to updating a couple of articles to see what this would look like when used with a number of different listing types in a live article? -- Ryan • (talk) • 19:21, 5 May 2013 (UTC)Reply

One general comment: before any massive changes are done, we should think about compatibility with the map tools developed by the German community. Current script can read 'lat' and 'long' fields directly from the {{listing}} template, but the script also needs the field 'type'. Therefore, it is better to keep this field, instead of using individual templates like {{see}}, {{eat}}, etc. --Alexander (talk) 20:31, 5 May 2013 (UTC)Reply

Template:See and Template:Eat would simply pass the "type" parameter to Template:Listing. This would actually be a boon, as it would help ensure that all listings have a type. LtPowers (talk) 02:03, 6 May 2013 (UTC)Reply

Yes, but the map script simply reads the page source. It does not know what templates are doing. --Alexander (talk) 05:30, 6 May 2013 (UTC)Reply

Oh. Yikes. That's not good. I would be extremely reluctant to hobble our own functionality because this map script relies on a particular implementation. LtPowers (talk) 13:12, 6 May 2013 (UTC)Reply

Is there any further information available about this map script? I'm also of the opinion that for templates that will be used in thousands upon thousands of places on the site it would be better to keep them as short and easy-to-use as possible, and that eliminating the need for the "type" parameter would help meet that goal. If we need to tweak a map script as a result I think that's a better option than having a single form of the listing template, provided it is possible to update the map script to still work. -- Ryan • (talk) • 14:56, 6 May 2013 (UTC)Reply

Well, the map script is also part of "our own functionality", and it is way more important than ten extra symbols in the template. Anyway, the author is here and open to any requests. --Alexander (talk) 17:42, 6 May 2013 (UTC)Reply

At this point, our default is hand-generated maps; dynamic maps of the sort to which you refer are still an experimental feature. LtPowers (talk) 17:56, 6 May 2013 (UTC)Reply

While the dynamic maps are still in the infancy period, they are the way of the future. That said, we can either develop the map script to match our listings format, or vice versa. --Peter ^Talk 17:55, 7 May 2013 (UTC)Reply

Here is a comment by the map master:

Hello, I would clearly prefer the template:Listing as in the Russian language version. The script PoiMap2 evaluates {{Poi| and {{Listing| and also {{Gps| soon. More time and effort I would not spend to this. If en.WV would have individual templates for each type of listing, then they may additionally use the template:Poi

--Alexander (talk) 20:22, 7 May 2013 (UTC)Reply

I don't understand what is meant. I remain adamant that this map tool should be fixed to work with our templates, whoever does the work. LtPowers (talk) 22:45, 7 May 2013 (UTC)Reply

Excuse me for my ignorance, but it doesn't seem that difficult to reconfigure the map script to search for {{see rather than |type=see . Is it really such an issue to change the script? JamesA ^>talk 01:51, 8 May 2013 (UTC)Reply

Easy workaround would be replacing strings, in this case replacing {{see with {{listing|type=see, and continue as per normal. It's a little annoying and hacky, but much easier than the comparatively large hurdle of the XML tags. So I think the sample that Ryan suggested is good enough. I'll try and sort it out with Joachim. -- torty3 (talk) 03:40, 8 May 2013 (UTC)Reply

I'm not sure I follow -- replacing the strings where? LtPowers (talk) 14:03, 8 May 2013 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Per it looks like the dynamic maps concern may have been addressed, so it may now be time to try updating a couple of articles with the proposed format just to make sure things look OK. -- Ryan • (talk) • 14:46, 8 May 2013 (UTC)Reply

→ Culver City has been updated, so feedback would be appreciated. User:Wrh2Bot is a work-in-progress tool for performing the conversions. -- Ryan • (talk) • 07:21, 9 May 2013 (UTC)Reply

I would propose a separate row for map related parameters.

* {{see
| name=Culver Studios | url= | email=
| address= | directions=downtown Culver City 
| lat= | long= | map= | image=  <!-- map= POI-number, image= preview picture -->
| phone= | tollfree= | fax=
| hours= | price=
| content=Founded in 1919. ... }}

-- Joachim Mey2008 (talk) 07:46, 9 May 2013 (UTC)Reply

I guess images would be nice, but I'm still not convinced about POI-numbers, they change too much and should really be handled automatically. Maybe on the map server side itself. -- torty3 (talk) 13:26, 9 May 2013 (UTC)Reply

I mean, there is no need for large renumbering. Additional listings may be added at the end of a section. No renumbering required. - You delete a listing by overwriting. Cutting off the last listing of a section. Add it to the location of the deleted listing. No renumbering required. - The markers in the map always have the same numbers as in article. An extra script for renumbering the listings? This would be possible with a PHP script (search/replace). Worth the effort? - Joachim Mey2008 (talk) 15:16, 9 May 2013 (UTC)Reply

We try to keep our listings in alphabetical order. LtPowers (talk) 17:13, 9 May 2013 (UTC)Reply

I absolutely think it is worthwhile to have an extra script to renumber listings, although I feel silly saying such things, since I don't know how to help with the effort ;) To me, one of the principal benefits of the dynamic maps is that we'll no longer have to manually renumber icons on the manually drawn maps, which takes a ton of time, and is very easy to mess up, causing all the icons to be wrong... --Peter ^Talk 19:06, 9 May 2013 (UTC)Reply

Given that we're not (yet) using the dynamic maps, for now would people be OK with leaving those parameters out of the initial bot conversion, since they will be empty for every single listing? It should be easy enough to populate them via bot once we've figured out how to roll that feature out. Alternately, if I've missed a discussion somewhere and that feature is ready to implement now please point me to it. Otherwise, my preference would be to have this initial phase just be an XML-ectomy that finally replaces the confusing and error-prone XML listings with templates that will be more familiar to wiki users and should be easier for novices to figure out. -- Ryan • (talk) • 03:06, 10 May 2013 (UTC)Reply

Any further comment on the format? I've got a bot (nearly) ready that will convert to the proposed format above - see Culver City, User:Wrh2/Listings and User:Wrh2Bot/Test for examples of converted pages (the history of User:Wrh2/Listings includes examples from many, many articles). The bot will also create logs that I'll upload here for cases where listings could not be automatically converted - they contain invalid attributes, missing end tags, etc. It isn't difficult to change the format that the bot outputs, but it would be better to raise any issues with the proposed format now than to do so after updating thousands of articles. -- Ryan • (talk) • 04:06, 14 May 2013 (UTC)Reply

I thought of another potential concern. Depending on what an editor changes, the diff might not show the name of the listing, making it hard to determine what was changed. On the other hand, subtle changes might be more visible in the diffs because there's less noise in the highlighted line. Also, a question: will your bot be maintaining the current spacing (or lack thereof) between listings? LtPowers (talk) 13:18, 14 May 2013 (UTC)Reply

Right now I've set the bot up to modify only what is between the XML tags, so it doesn't do anything with spacing - do we have a standard on spacing between listing tags? I could look into it, but it might be tricky if (for example) a listing has two levels of indentiation ("**") and we want a blank line between listings since an extra newline would break that. As to potentially not being able to see the listing name in the diff, personally that doesn't concern me - I think it's a far bigger win to have a more-easily editable listing, but perhaps others feel differently. -- Ryan • (talk) • 14:24, 14 May 2013 (UTC)Reply

For accessibility, bulleted lists should not be separated with blank lines, but we routinely include them in our articles. I just wanted to make sure the rare cases in which there is no blank line wouldn't be adjusted by your bot. =) LtPowers (talk) 15:00, 14 May 2013 (UTC)Reply

I believe that the bot is ready to go: Wikivoyage:Script nominations#User:Wrh2Bot -- Ryan • (talk) • 00:23, 16 May 2013 (UTC)Reply

It looks like the bot is leaving a space between listings items. Would it be possible to not do that? It makes for more scrolling in the edit window than necessary. --Peter ^Talk 02:07, 16 May 2013 (UTC)Reply

Can you clarify? Do you mean the " | " between each template attribute? That was done per the proposed format above. -- Ryan • (talk) • 02:13, 16 May 2013 (UTC)Reply

Sorry, that was quite vague. I meant the space between listings themselves , but I think that's something that is simply being preserved in the operation. Spaces between bulleted listings are helpful-ish in reading the crammed-together code of the xml listings, but are totally unnecessary for the clearer templated listings. Would it be possible for your bot to get rid of those spaces as it does its job? Or is that complicating things too much? --Peter ^Talk 03:43, 16 May 2013 (UTC)Reply

LtPowers mentioned this earlier. As you've noted, the bot just replaces content within the XML tag and leaves the spacing around listings as-is. Since the pattern matching is already somewhat complex in order to deal with malformed listings I would prefer not to try to change anything outside of the listing itself in this iteration, but it's worthwhile keeping a list of these types of cleanups around and I can probably write a new script to do things like fix whitespace and ensure that there is an "http://" in front of URLs (for example) in the future. -- Ryan • (talk) • 03:50, 16 May 2013 (UTC)Reply

Any final objections or concerns? If not I'll kick the bot off during the weekend. -- Ryan • (talk) • 20:07, 17 May 2013 (UTC)Reply

I'm letting it run through all articles that start with "A" at the moment, and aside from one now-corrected issue () things look OK. Once the "A"s are done I'll pause for the night and wait for any feedback. Errors are being logged at User:Wrh2Bot/ListingsToTemplate - anything listed there will need to be manually updated by anyone willing to volunteer (please remove anything you update from the list when done). -- Ryan • (talk) • 04:30, 18 May 2013 (UTC)Reply

Why is it flagging phoneextra? Did we not implement that field in Template:Listing? LtPowers (talk) 13:59, 18 May 2013 (UTC)Reply

Neither phoneextra nor priceextra are implemented in the template. Were they supposed to be? Given their apparently limited use in existing XML listings I would rather we remove them - doing so would also make it easier to implement some sort of listings editor as their would be fewer fields to keep track of. -- Ryan • (talk) • 15:23, 18 May 2013 (UTC)Reply

I've never quite understood the need for priceextra, and in fact had totally forgotten about it, but phoneextra seems to have significant, if not widespread, use. LtPowers (talk) 16:07, 18 May 2013 (UTC)Reply

The bot is running again now and adds support for the legacy "tags", "wikipedia", "phoneextra" and "hoursextra" attributes, all of which were apparently supported by the XML plugin. -- Ryan • (talk) • 21:47, 18 May 2013 (UTC)Reply

I do believe we discussed 'phoneextra' at length before, and decided that 3rd world businesses often have a secondary number due to the likelihood of one number failing. JamesA ^>talk 00:40, 19 May 2013 (UTC)Reply

Can't we put all phone numbers into the "phone" field? Some businesses have more than 2 numbers. --Alexander (talk) 06:49, 19 May 2013 (UTC)Reply

Putting multiple phone numbers in the same field is semantically weird and inhibits the machine-readability of the data. LtPowers (talk) 14:32, 19 May 2013 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Done through the "F"s. I'll restart it again tomorrow when I'm around to monitor things. -- Ryan • (talk) • 06:34, 19 May 2013 (UTC)Reply

Done through the "L"s. Will continue again tomorrow. -- Ryan • (talk) • 06:25, 20 May 2013 (UTC)Reply

I'm super-impressed with all the great work you're doing. Kudos! Ikan Kekek (talk) 07:47, 20 May 2013 (UTC)Reply

Yes, it is amazing! Thank you, Ryan! --Alexander (talk) 08:01, 20 May 2013 (UTC)Reply

Thanks for the kind words. The bot is now done through the "S"s. It should be able to finish tomorrow, barring surprises. -- Ryan • (talk) • 06:33, 21 May 2013 (UTC)Reply

The bot has finished updating every article. I'll go through the errors later tonight and try to get any remaining listings converted. -- Ryan • (talk) • 19:07, 21 May 2013 (UTC)Reply

For anyone willing to help with the remaining listing conversions that the bot could not do, User:Wrh2Bot/ListingsToTemplate‎‎ has a list of articles needing attention. You can either manually convert the XML listing to a template listing, or simply fix whatever is wrong with the XML listing (missing end tag, bad attributes, etc), and I'll re-run the bot tomorrow against the articles that still have errors and then update the list of pages needing attention. Any help is appreciated. -- Ryan • (talk) • 06:41, 22 May 2013 (UTC)Reply

For people who want to help out, this listing converter tool by Ml31415 is awfully useful and would save quite a bit of time! JamesA ^>talk 06:56, 22 May 2013 (UTC)Reply

The bot has finished converting XML listings, and all listings that were in an error state have been fixed. There may be a few stray XML listings left over if people adding listings after the bot first processed an article, but the number of such articles should be small enough that they can be cleaned up by hand as they are found. -- Ryan • (talk) • 17:50, 26 May 2013 (UTC)Reply

Fabulous! That seemed a tremendous amount of work, so a big thanks from me. --Peter ^Talk 18:25, 26 May 2013 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

I would like to draw a little dotted line between this discussion and the #Edittools for listings discussion just below, ~~where we are running up against problems in making buttons to insert templates~~

~~with line breaks~~.Texugo (talk) 13:22, 15 May 2013 (UTC)Reply

Edittools for listings

Latest comment: 11 years ago32 comments5 people in discussion

Currently our edittools display the full text of each of the listings templates, making a giant blue block of text which essentially wastes a lot of space just to show the 7 buttons. Wouldn´t it look nicer and be less intimidating to have something like this?:

Listing templates: See - Do - Buy - Eat - Drink - Sleep - Listing

where clicking on each one would insert the corresponding template into the edit window? Which brings me to my question: is it possible to make such an "insert" button that displays one text but inserts another? I tried without success to make one over on pt:, and I figure this may be useful here too, especially since we look to be changing to a new template that will default to display on several lines. Edittools is going to be a mess if the insert buttons are only capable of displaying the insert text verbatim. Texugo (talk) 11:26, 7 May 2013 (UTC)Reply

That's a great idea, although I'm also not sure if it's possible through the Edittools. It would certainly be possible if we were to make it a part of the Edit toolbar above the window, however. It may also be more visible. JamesA ^>talk 13:12, 7 May 2013 (UTC)Reply

Making it a part of the edit bar above the window would require a feature request, would it not? Does anybody have a definitive answer as to whether an abbreviated insertion button can or cannot be made without help from the tech guys? Texugo (talk) 13:32, 9 May 2013 (UTC)Reply

No, the edit toolbar can be edited by administrators, but it is complicated. I'll give it a shot over the next few days. JamesA ^>talk 13:41, 9 May 2013 (UTC)Reply

Could you show me where it can be edited, so that I can mess with it over on pt? Texugo (talk) 14:48, 9 May 2013 (UTC)Reply

Still waiting to find out where the source code of our current bar is, but I did spend a few hours fudging with my common.js page and got me some working icon-based buttons added on pt:. I have tried here too but the xml text to be inserted here contains quotation marks which break the code (pt: has gone straight to the mediawiki template which has none). I do have it currently set up where it will insert the {{listing}} syntax directly, which we appear poised to start using one of these days, but line breaks in the proposed format also break the code, so it currently inserts everything on one line.

Anyone willing to evaluate/play around/fix this idea can copy the content of User:Texugo/common.js to their own common.js file. I would be grateful.

Incidentally, the first chunk of the code inside the customize function is an attempt to remove the reference button (since we don't use ref here), but something is wrong and it doesn't work. Perhaps the tool name in the call is wrong, but without knowing where our source code is, I haven't been able to guess what it is supposed to be. If anyone can find a fix for that too, it would be awesome.

Anyway, please do have a look and let me know what you think! I really think something like this should be in our future.Texugo (talk) 11:25, 15 May 2013 (UTC)Reply

Great job! I had a go at removing the reference tool, but it's very difficult. I even tried removing the bold button like an example on their page but that failed too. I'm not sure if it's a major concern to warrant much work, though. About the listing buttons, I think it's great, but it may be worth putting them under a "Listings" tab/section so that it's clear what they are. Or possible letting them have their own named "subdivision" of the main top-layer toolbar. Then, I think it should be good enough to deploy. The spacing issue is unfortunate, but we may have to live with it. JamesA ^>talk 12:11, 15 May 2013 (UTC)Reply

If I knew how to put a label next to the icons, that would be great. I would hate to hide them in a sub-menu though. I think they should be always visible since they apply to about 75% of our article sections and many users may not even realize they are there. I also thought it would be nice to put them to the right of the link/ref buttons, but I don't know how to do that either...Texugo (talk) 12:14, 15 May 2013 (UTC)Reply

Also, by "spacing issue" are you referring to the fact that it cannot insert line breaks? Texugo (talk) 12:18, 15 May 2013 (UTC)Reply

Yep, line breaks is what I meant. If we create a new label for all of the listings, it should get it out of the middle of the insert section and put it neatly on its own. I'll have a try. JamesA ^>talk 12:25, 15 May 2013 (UTC)Reply

That would be good. Let me know if it works! Texugo (talk) 12:32, 15 May 2013 (UTC)Reply

Yes! I got the Listings to have their own section with a label. Copy my js to yours, mine is a direct copy of yours apart from the changes to make the label appear. I can't work out how to add a separator to the left of them though; I do remember seeing it somewhere! Something else to consider is whether we want to make the user's typing cursor (the blinking line) automatically move to part of the template, such as the "name=" parameter. It's just a handy hint so they know where to start, I guess. If you think that would be good, I can make the change easily through the use of "pre" (like you've got) and "post". See here for examples. JamesA ^>talk 12:37, 15 May 2013 (UTC)Reply

A clear improvement! It would be nice to have the little divider, yes. Also, yeah, the pre-post thing is a good idea. Texugo (talk) 12:45, 15 May 2013 (UTC)Reply

We have two options. We can either default it to name= which is useful for new listings, guiding users to start adding parameters. Or we can default it to content=, which helps users who are listingfying articles. All they would need to do is highlight the old listing, hit one of the buttons, and all the old text appears within the content= parameter, meaning they just need to cut and paste out the title, website, etc. Thoughts? JamesA ^>talk 13:17, 15 May 2013 (UTC)Reply

I think it would be better to go with name=. If you are listingifying, you're going to have to be doing some cutting and pasting no matter what, but at least we could save a click when adding new listings.Texugo (talk) 13:20, 15 May 2013 (UTC)Reply

Agreed. My js has the code now. Anything else you could think of that we could do, apart from the divider, ref button removal and line breaks? Apart from those three, I think it could be ready. By the way, we need to decide if we're doing {{listing |type=see or {{see. It seems above they were planning the latter, but the buttons use the former. JamesA ^>talk 13:27, 15 May 2013 (UTC)Reply

Well, as for removals, I think we need to remove the ref button, the ref section under the help tab, and the gallery button under the advanced tab. I do think the divider line is highly desirable. And yeah, this effort needs to be reconciled with the discussion above regarding both the listing text itself, and the possibility that we may not be able to make buttons that insert syntax that is divided into several lines. Texugo (talk) 13:35, 15 May 2013 (UTC)Reply

Looks really nice. Think we should be using {{see. I added newline characters \n where appropriate in User:Torty3/common.js, and it seems to work. Were you using before? -- torty3 (talk) 16:26, 15 May 2013 (UTC)Reply

Great. I knew there must be a simple solution. Do you have any insight as to how to remove the gallery button, ref button, and related help items? Or how to add a divider line before the group of listing icons? Texugo (talk) 16:56, 15 May 2013 (UTC)Reply

The ref button appears to be hidden for me now, and I haven't made any changes to my js since yesterday. Maybe it takes time, although I was refreshing my cache. Removing the other things you mention shouldn't be too difficult. JamesA ^>talk 06:39, 16 May 2013 (UTC)Reply

Cool, yeah, it has been removed for me too. I'll try to get rid of the other two things too. Texugo (talk) 15:53, 16 May 2013 (UTC)Reply

Actually no, I take that back. I was fooled, because the ref button doesn't appear when you edit talk pages, but for non-talk pages, it's still there. Gah.... Texugo (talk) 15:59, 16 May 2013 (UTC)Reply

Alas, you're right. So close! JamesA ^>talk 04:25, 17 May 2013 (UTC)Reply

Is it time to summon more eyes to look at this (and more brains to help fix the problems)? Texugo (talk) 13:10, 17 May 2013 (UTC)Reply

If there are still issues and no one else can get to it first I'll try to look at this issue over the weekend. -- Ryan • (talk) • 20:09, 17 May 2013 (UTC)Reply

Have you tried it out? Functionally, the buttons we created work fine and could be implemented before resolving the separate issue of removing unneeded buttons and adding a little divider line, but I'd be grateful if you could look at it... Texugo (talk) 20:31, 17 May 2013 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Now that the bot has updated all legacy listings it doesn't make sense to leave the old XML in MediaWiki:Edittools so I've removed it - if the Javascript toolbar could be updated with the new listing buttons soon that would be great (side note: I think the new buttons insert text that is missing a newline before the closing braces). I took a quick look at removing the "reference" button over the weekend, but didn't make much more headway than you guys did - the normal remove syntax doesn't seem to work, so something out-of-the-ordinary seems to be going on with that button. -- Ryan • (talk) • 19:11, 21 May 2013 (UTC)Reply

Thanks for the stellar work, Ryan! I ~~can fix~~ fixed the newline thing easily.

What else needs to be done before we implement this? I see the removal of the unneeded buttons as a rather separate issue, and the suggested divider line is only a suggested aesthetic improvement. We can always work that stuff out later when we figure out how, so I don't see how those issues should be an impediment to the addition of useful buttons. Since this is obviously an improvement over the nothing we now have, would it be too much to plunge forward with this? Texugo (talk) 19:39, 21 May 2013 (UTC)Reply

Incidentally, with regard to removing things, I find that it is possible to remove the simple buttons easily, like the signature button for example, but the buttons that call up an on-screen dialog (reference, link) or work from a menu (gallery, help items) won't budge. Texugo (talk) 20:00, 21 May 2013 (UTC)Reply

I'd say plunge forward on implementing the new buttons - better to have some functionality available, even if it needs to be tweaked, than not have any at all. If nobody figures it out first I'll take a look at the reference button again later - I started going through the source for the edit bar, but didn't make it far enough to figure out what's different about that particular button. -- Ryan • (talk) • 20:12, 21 May 2013 (UTC)Reply

Forgot to post it here, but I have plunged forward and added it to Mediawiki:Common.js for everyone. Let me know if there are any issues. Texugo (talk) 15:18, 22 May 2013 (UTC)Reply

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

help: xml redirection and designing the mediawiki listing template

Latest comment: 11 years ago5 comments3 people in discussion

Two pleas for help:

Can anyone point me to the presumably archived tech request for when we had the xml redirected to {{listing}}? I think we will be needing to do something very similar on pt: and I have never done such a tech request before and don't know what all needs to be included in the request.
I have modeled pt:`s mediawiki listing template on the one here. Is there anything that would be better done differently that I ought to consider before we start implementing it?

If anyone can help, I would greatly appreciate it! Thanks. Texugo (talk) 00:18, 9 May 2013 (UTC)Reply

bugzilla:43220. I think all you need to do is populate Mediawiki:listings-template to point at the corresponding template. -- Ryan • (talk) • 02:10, 9 May 2013 (UTC)Reply

Thanks Ryan, but are you saying that a new request is unnecessary? I think in our case it may be a little more complicated since we want the old xml (in English) to redirect to a new mediawiki template with different attribute names in Portuguese, so we need the various attributes to line up (name>>nome, address>>endereço, phone>>fone, etc.). Maybe it would work to have it redirect to an intermediate "converter" template which then feeds to the target listing template in Portuguese? Texugo (talk) 12:44, 9 May 2013 (UTC)Reply

Solved! I pointed the xml to an intermediate template which translates all the attribute names to Portuguese and then passes them on to our normal mediawiki listing template, and (after half an hour of fiddling) it seems to work perfectly! I could have done that months ago if I had only known... Texugo (talk) 23:41, 9 May 2013 (UTC)Reply

I'd suspect that |nome={{#if:{{{name|}}}|{{{name}}}}} could be |nome={{{nome|{{{name|}}} }}} which would take the nome em português (if present) but fall back to the English-language name if "nome" wasn't specified. That might avoid the need for two different predefiniçãoes. K7L (talk) 17:59, 18 May 2013 (UTC)Reply

Dotted line under icons

Latest comment: 11 years ago9 comments4 people in discussion

Maybe this has been asked somewhere before, but what's up with the little dotted lines under the telephone and url symbols? Have we ever tried to find a way to eliminate that? Texugo (talk) 12:02, 10 May 2013 (UTC)Reply

The dotted lines are an indication that hovertext is available. The hovertext explains what the symbols mean. LtPowers (talk) 13:07, 10 May 2013 (UTC)Reply

Really? So how is anyone supposed to know that the dotted lines indicate there is hovertext? I've never come across this convention anywhere, and if a regular long-time user like me didn't even know that, how would it be useful to a casual user? It appears to be used for only two cases: the telephone icon is already as intuitive as you could possibly get, and it is mostly redundant for the website icon since most browsers already do something to indicate when you have moused over a link. I think the potential aesthetic improvement of removing the dotted line greatly outweighs any marginal utility it might have. For the vast majority of users, if they do happen to discover that there is hovertext there, they won't ever even realize that the dotted line has anything to do with it. Texugo (talk) 13:45, 10 May 2013 (UTC)Reply

Ah, there is a third case too, of the icon for coordinates, but as I said, if no one knows that a dotted line means hovertext, what purpose can it actually serve besides making the icons look corrupted? Texugo (talk) 14:00, 10 May 2013 (UTC)Reply

You should not conflate "I didn't know that" with "No one could know that". It is a convention, even if you aren't familiar with it. For example, this is how most web browsers render the <abbr> tag: Like so!. In fact, I suspect that that is precisely the tag that our template is using. =) LtPowers (talk) 15:02, 10 May 2013 (UTC)Reply

You're right, now that you used it on some text, I recognize it, and of course it is intuitive. However, I think it's a text effect that is totally lost on small non-text icons like that, and underlining a telephone or globe doesn't make any more sense than any other text effect would if applied to an image (italicized icons, anyone?). It also becomes redundant by the fact that, unlike text, such icons don't need any extra feature to distinguish them from surrounding text, and people already instinctively try to click or mouseover icons they don't understand. Plus, it seems even further redundant since these icons appear dozens or even hundreds of times in most articles. I think it would look much cleaner and not lose any of its intuitiveness if we were to remove them. Isn't there a way to keep the hovertext without having little dots that effectively alter the design of the icon image? Surely I am not alone in thinking it's ugly and unnecessary to append random stray black pixels to the bottom of every icon? Texugo (talk) 16:10, 10 May 2013 (UTC)Reply

I think we'll be rid of it under the external link icon when we (finally ???) switch to the link-color blue arrow. I think it looks fine, and even kind of helpful under the telephone icon. But it looks positively weird under the cross icon for lat/long, which frankly already looks weird and unintuitive to my eye. I think a map style icon would look a lot better. Here are the best two I can find . --Peter ^Talk 17:20, 10 May 2013 (UTC)Reply

Why are we using <abbr> instead of proper alt="" tags on the images? The alt tag should be used to provide a textual description of the image, but the globe icon has alt="P geography 3 b.png" and the cross has alt="14X14 Géolocalisation 2PR.gif". According to , a proper alt="" tag, along with a title="" tag for hovertext, would make it more accessible for screenreaders and other accessibility-impaired people... and then we could get rid of the <abbr> tag. (Only catch is, I'm not sure what to do about the telephone icon... but I think it can be done using a plain tag, like so: ☎) Bigpeteb (talk) 18:39, 10 May 2013 (UTC)Reply

Peter, I'm not a big fan of the lat/long icon either, but do you think those two icons you found would even be recognizable at our icon size? Would the current icon perhaps look better if it had a circle to make it look more like crosshairs? Texugo (talk) 00:15, 11 May 2013 (UTC)Reply

Why two different map icons?

Latest comment: 11 years ago12 comments5 people in discussion

After the external link format is changed, eliminating the gray globes, why don't we replace the odd crosshairs icon for the map links with the same globe that already signifies map link at the top of every article (the {{geo}} globe)? Both links go to the exact same place. Why should we have two different icon styles for them? Texugo (talk) 11:52, 21 May 2013 (UTC)Reply

I'm all for it. --Peter ^Talk 16:16, 21 May 2013 (UTC)Reply

This icon

shows a map and a magnifying glass. Perhaps that is suitable for both cases

. Neither the cross nor the globe is always interpreted as a link to a map by me. -- Mey2008 (talk) 16:37, 21 May 2013 (UTC)Reply

I think that icon works at the geo template size

(24px) but becomes unrecognizable at the standard listing icon size

(14px). Texugo (talk) 17:21, 21 May 2013 (UTC)Reply

True, but I still have a 16px version available. Is a little clearer. The real icon is 14px because of the white space around. -- Joachim Mey2008 (talk) 19:58, 21 May 2013 (UTC)Reply

That would work. --Peter ^Talk 20:20, 21 May 2013 (UTC)Reply

See name, Address, ☎ +91-22-2222-1234, e-mail: test@example.com,

. Description of attraction. -- A working example with tooltip and 16px icon. Please click on symbol. -- Joachim Mey2008 (talk) 05:19, 22 May 2013 (UTC)Reply

I think Joachim's icon(s) makes much more sense for both cases. All for it. JamesA ^>talk 10:20, 26 May 2013 (UTC)Reply

Even I should be able to make this change. Any opposition? --Peter ^Talk 18:18, 10 June 2013 (UTC)Reply

None from me. Texugo (talk) 19:20, 10 June 2013 (UTC)Reply

No objection from me. • • • Peter (Southwood) ^(talk): 19:24, 10 June 2013 (UTC)Reply

Done James A ▪ talk 11:37, 11 June 2013 (UTC)Reply

Alt/title tags and the dotted line

Latest comment: 11 years ago1 comment1 person in discussion

I have a mockup in a sandbox of what it could look like if we get rid of the <abbr> tag. This improves usability for people with screenreaders, and follows WWW guidelines, and generally looks better (because there's no ugly dotted line).

Incidentally, the fact that the Map and Website images are linked means the <abbr> tag isn't even serving its purpose. Web browsers are showing the destination of the link as the hovertext instead of the <abbr> tag.

Have a look at the mockup and see what you think. Bigpeteb (talk) 18:54, 11 June 2013 (UTC)Reply

tags parameter

Latest comment: 11 years ago4 comments3 people in discussion

This project page seems the only one that is still referring to the tags parameter, so I would change the page removing all the references to it. Before doing that I've asked here to verify if I'm missing something. --Andyrom75 (talk) 07:25, 17 June 2013 (UTC)Reply

The original <listing> tag was specified in mw:extension:listings to have a 'tags' field, even though (in the extension code, now bypassed) that field did nothing. My guess was that this was proposed but no one ever bothered to implement anything? K7L (talk) 17:57, 18 June 2013 (UTC)Reply

It's probably a carryover from the site where the content was originally hosted, and was likely meant to generate RDF. Since we're not using it then it should be safe to remove. -- Ryan • (talk) • 18:00, 18 June 2013 (UTC)Reply

Ok &

Done. In the meanwhile I've clean up the page removing the references to tags attribute. As you ocnfirm this shouldn't be used in the future. --Andyrom75 (talk) 22:42, 18 June 2013 (UTC)Reply

Icons for Itineraries

Latest comment: 11 years ago12 comments4 people in discussion

Would like to get some feedback on a proposal to add icon parameter to the listing template. The intention is only for use in Itineraries were points of interest are not listed in order of type (eat, see , ..) like in town articles but in order of the route being describe. I would like to have a small icon at the front of the listing line to show what time of location is being described. Example of how it could look can be see at Rheinsteig#Rheingau and Taunus (page not complete but can see when add more historical sights, restaurants, parking places etc. it will require some visual aids). Idea would be to have option in template such as icon=see or icon=parking. --Traveler100 (talk) 10:56, 6 July 2013 (UTC)Reply

They look useful, but display a bit small to easily identify on my screen setting. It would help to have a mouse-over description associated with each icon, or a legend at the top of the section. The milestone icon is a bit obscure at first, but works for me once I worked out what it meant. Here again an explanatory mouse-over would help. In all, an Idea that shows promise. Cheers, • • • Peter (Southwood) ^(talk): 11:29, 6 July 2013 (UTC)Reply

Mouseover a good idea, have set a few up for testing. --Traveler100 (talk) 12:22, 6 July 2013 (UTC)Reply

I would like to see this proposal start from the other way around, developing a set of matching icons first, then talk about placing them. If they do go in a listing template, I think it would be best to make it a separate listing template so we don't get people adding random icons in random articles where they are not sanctioned. Within the template, I think they should probably be inserted by an attribute switch, limiting it to the approved set of matching icons (and making it easier to implement without having to remember the full icon filenames).

As for the icons themselves, I think they should either be all black-and-white or they should all match the color scheme of the burgeoning dynamic map expedition, and should have thematically matching styles. As it is, I think it looks too busy and is more of a distraction than anything (and I have absolutely no idea what the "H" icon stands for). Also, I'd like to see the arrows of the milestone icon be the same as the small horizontal arrows we use in the routeboxes; I think the diagonal arrows are odd and less intuitive. Texugo (talk) 13:02, 6 July 2013 (UTC)Reply

I'm also thinking the milestone icon might look better on its own line as a sort of mini subsection header, or at least at the left margin before the text. To have such a large icon set inline like that, at varying distances from the left margin, contributes a lot to the "overly busy" look of the page. Texugo (talk) 13:11, 6 July 2013 (UTC)Reply

Creating another template which adds the icon then calls the other listing templates I was also thinking about. A uniform set of icons is probably a good idea (the H if you ever use a bus in Germany would be clear but take your point). Where is the discussion on the dynamic mapping. The link was added to the Rheinsteig page and looks like a very useful tool but is not clear to me how to drive it. I was thinking of using poi as the name for a template but I see that is already being used for something similar. What is the plan to combine listings and poi?Traveler100 (talk) 13:26, 6 July 2013 (UTC)Reply

I see you have changed the arrows a bit, but I still think it looks bad. Could you try the plain horizontal one?

I'm not totally up to speed on the dynamic maps thing, but the color scheme I was talking about (and a couple of sample maps with the listings placed on them) can be seen at Tokyo/Roppongi, and the discussion/coordination is at Wikivoyage:Dynamic maps Expedition. Texugo (talk) 14:00, 6 July 2013 (UTC)Reply

OK so dynamic map project is looks like it is proposing numbering the listings to match a map on the page User:Mey2008/Sandbox. Also a good idea. Maybe need to see where this goes before push forward with the icon proposal. Traveler100 (talk) 14:19, 6 July 2013 (UTC)Reply

How about these for icons de:Wikivoyage:Symbole für Karten ?

Fairly good at the size shown. Look like the ones you have been using. • • • Peter (Southwood) ^(talk): 07:47, 7 July 2013 (UTC)Reply

Have increased the icon size as far as I think it can go without changing line spacing. Also change the indentation method at Rheinsteig so there are less bullet points. --Traveler100 (talk) 11:13, 7 July 2013 (UTC)Reply

The indentation looks a bit odd right now (Chrome on XP) Some lines have extra indents for no obvious reason. Icons would look better if vertically aligned. Agree with Texugo on the arrows in the milestone. I think horizontal would look better. Try just arrowheads to save space. If you need help with graphics let me know.

There is still one icon from a different set on the Rheinsteig page. The black and white museum icon, which I actually prefer to the rather weird red and white museum icon from de:

Size is better. My eyes are weak, so I still need the mouse-over. Others may differ. • • • Peter (Southwood) ^(talk): 13:08, 7 July 2013 (UTC)Reply

I find all that visual information very overwhelming. Maybe it's just the lack of explanatory prose for most listings. I'm more used to the narrative tour format for itineraries, like that found at Along the Magnificent Mile. Articles like that would benefit from just a simple icon next to each bolded "stop," which would have a number corresponding to the map, like what is at Wheaton#See. I think a template separate from Template:Listing would be in order, though, since the listings template has many fields that aren't really necessary in an itinerary article. --Peter ^Talk 18:57, 9 July 2013 (UTC)Reply

Text-to-template conversion

Latest comment: 11 years ago15 comments4 people in discussion

I've got a work-in-progress bot that may be suitable for converting some text listings to use the appropriate version of Template:Listing and would appreciate any feedback. The bot has these caveats:

The approach is to avoid false positives - if the bot isn't sure about converting something then it won't be converted.
Listings must be at least somewhat similar to the format defined in Wikivoyage:Listings to be converted - if the order is significantly different (for example, it is something like name followed by hours followed by prices followed by address) then it won't be converted.
The bot doesn't convert hours or prices. That data will be left in the listing content and can be manually moved later (these fields vary too much and can't be easily parsed).
See, Do, Buy, Eat, Drink and Sleep listings are converted if the bot can determine name and at least one more field with 100% certainty (url, phone, fax, email). Other listing types (such as transportation types) require two additional fields to avoid false positives since generic listings vary greatly and can easily be mistaken for a non-listing list element.
If a listing contains two or more URLs then it isn't converted - I was getting too many false positives.
If a listing contains multiple phone numbers then the phone number isn't converted and remains in the "content" field - a significant number of Indian articles contain multiple phone numbers, and when the bot tried to parse them out it often left behind bits and pieces that needed manual updating.

At the moment I've been testing by grabbing random articles and converting. Here are a few examples - feedback appreciated:

(Doylestown) - With the exception of a phone number containing letters and an address of "62-64" this one converted 84 listings fairly cleanly.
(South Kingstown) - This article had a lot of badly-formatted addresses and other values that require manual cleanup even after the bot runs.
(Hollywood (Florida)) - This one seems to have converted cleanly.
(Dubai/Jumeirah) - Only two conversions, note that the "Jumeirah Road" address wasn't recognized as an address since there was no street number.

Feedback and suggestions appreciated - the bot still needs more testing and I'm sure some remaining issues will need to be addressed, but I've run it against dozens of articles at this point and it seems to be getting close. Once more testing has been done I'll put it on the script nominations page unless there are objections. -- Ryan • (talk) • 07:20, 8 July 2013 (UTC)Reply

Does it leave a centralized record of what it has done? • • • Peter (Southwood) ^(talk): 09:47, 8 July 2013 (UTC)Reply

Can you elaborate on what you'd like to see? Like any bot it creates an edit summary message, and the change is available like any other edit in the article history. -- Ryan • (talk) • 14:38, 8 July 2013 (UTC)Reply

I just wondered if there would be a list of which articles had been edited, so one could make a random check. • • • Peter (Southwood) ^(talk): 16:06, 8 July 2013 (UTC)Reply

It all runs under the Wrh2Bot account, so Special:Contributions/Wrh2Bot will have all changes. For now I've got the bot set up to copy the article to a sandbox page and modify it there, but if/when it runs for real then that account's contribution history will show all changed articles. I could also copy the bot logs to a page here if that would be helpful, although it probably wouldn't show anything not available in the account history. -- Ryan • (talk) • 16:18, 8 July 2013 (UTC)Reply

No problem, One of these days I will try to figure out what is going on with bots... Cheers • • • Peter (Southwood) ^(talk): 20:02, 8 July 2013 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

I've started using the bot to update small batches of mainspace articles that I then manually review - see recent contributions for Special:Contributions/Wrh2Bot. As noted previously, hours and prices are not moved and stay a part of the listing "content" attribute, and addresses from some countries are problematic, but even if the conversion isn't 100% accurate I think it's worth running - at best we get an accurately-converted templated listing, and at worst we get a mostly-accurately converted templated listing that will require minor cleanups. I'll continue running this and manually checking the changes with a goal of nominating it to run autonomously in the coming week or so, and would appreciate any additional feedback. -- Ryan • (talk) • 06:06, 10 July 2013 (UTC)Reply

This looks like it could be hugely useful. The one part that worries me a bit is the address field. Addresses are pretty standardized in some parts of the world, but less developed areas are more likely to have "addresses" that really are just a road name, or something odder. I'd be curious how it would handle Delhi. --Peter ^Talk 06:46, 10 July 2013 (UTC)Reply

The pattern I'm using for address is "number + letters + a huge variety of abbreviations such as 'st'". This works well for places like Wilton (Connecticut), but when it fails to find a match the address is simply left as part of the listing content, so I don't think we're any worse off than we were before the listing was converted. See Jakarta/West for an example of a place where the existing listings were all horribly formatted and the address field couldn't be determined for any of them; in that particular article I later manually moved addresses to the "address" template field, which is a task that anyone editing a similar article could do post-conversion. -- Ryan • (talk) • 07:01, 10 July 2013 (UTC)Reply

And that is kind of the main selling point here: even if some items are missed by the bot and left in the content field, a partial conversion is definitely preferable to no conversion. --Peter ^Talk 07:18, 10 July 2013 (UTC)Reply

You might consider adding an alternate address construction used in Spanish and Portuguese-speaking countries, among others:

Rua/Avenida/Calle/Estrada/abbreviation thereof + streetname (+ comma) + number (+ hyphen or comma + name of barrio/bairro)

The comma between streetname and number is usually there but is omitted in some cases. The barrio/bairro name is not always present, and is most correctly separated with a hyphen but in many listings has a comma instead.

Banana Museum (Museu da Banana), Rod. das Bananeiras, km. 23, ☏ 15 1515-1515. Museum about the history of banana growing, banana harvesting, banana transport, banana sales, banana peeling, and banana eating.
Bar do Zé, R. Augusta, 976 - Consolação, ☏ 11 2222-3333. Great 24h dive bar. Try their breakfast shots with a side of bacon.
Hotel Sleepytime, Calle Ricardo Montalban, 452, Barrio del Rey, ☏ 34 567 5555. Has beds specifically designed for sleeping, special basins with running water for washing your face and body, and a special type of "indoor outhouse".

You'll catch a lot more listings if the bot can handle these types of addresses too... Texugo (talk) 11:25, 10 July 2013 (UTC)Reply

Can you point me to an article on English Wikivoyage that has what you would consider well-formatted addresses of the type mentioned above? "Rua/Avenida/Calle/Estrada ..., #" should be easy to parse, but if the abbreviation is a single letter then I'd be concerned about false positives, so those might need to be skipped - I'll do some testing to see what the results are. -- Ryan • (talk) • 14:56, 10 July 2013 (UTC)Reply

Have a look at São_Paulo/Downtown, Lisbon, or Lima/Central. The only single letter abbreviations I can think of are "R." for "rua", but I don't think it is in as widespread use here as it is on pt: .Texugo (talk) 15:29, 10 July 2013 (UTC)Reply

I've updated with the new street pattern - see this test edit of São Paulo/Downtown for an example. It seems to have converted the addresses as expected, so this looks like a solid enhancement. If anyone else has any country-specific patterns that should be considered please let me know. -- Ryan • (talk) • 04:05, 11 July 2013 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

After several hundred manually-reviewed test edits I think the bot is getting close to being ready for nomination to run on the full site. Before doing so, I'd just like to make sure that it is acceptable for the bot to make an occasional (but hopefully rare - I'd estimate much less than 1% in my testing) odd mistake. For example, in this edit the opening sentence "This 3 small churches built around St.Bogorodica Perivlepta" was interpreted as a street address - "3 small churches built around St." Mistakes like this have been rare and are pretty easy to fix when someone later comes along to edit the article, but even with a very conservative approach it's going to be impossible to get things completely right. My feeling is that having better formatted listings (examples: , ) far outweighs having a tiny number of weird errors, but if others feel differently please let me know. More common will be cases where the bot just isn't sure about something (like a phone number or email) and leaves it in the listing content, but that is better than the status quo since at least some of the fields will be converted and the proper template will be used. -- Ryan • (talk) • 04:24, 18 July 2013 (UTC)Reply

Space missing before "Check-out" in Sleep

Latest comment: 11 years ago1 comment1 person in discussion

Some Sleep listings at Hong Kong/Kowloon#Sleep have a "Check-out" time but no "Check-in" time. No space appears between "Check-out" and the preceding info. In the Budget subsections see Welcome Guest House, Canadian Hostel and Tokyo/Australian guesthouse. thanks. Nurg (talk) 20:50, 14 July 2013 (UTC)Reply

Spacing between listings

Latest comment: 11 years ago1 comment1 person in discussion

It would be nice to eliminate spacing between listings, since that spacing makes it harder to read/edit multiple listings in the edit window. Is there a reason to preserve spacing? And could spacing between listings be eliminated via a bot? When they are eliminated by users in the process of making other edits, edit diffs can be pretty hard to read. --Peter ^Talk 07:32, 17 July 2013 (UTC)Reply

Listing template overuse

Latest comment: 11 years ago7 comments3 people in discussion

Must Template:Listing be used everywhere?

Look at this recent edit to Childs. It converts bulleted prose into awkward inline listings, with the only apparent gain being the addition of (rather unnecessary) coordinates for five of the eight buildings. (Why the other three don't merit coordinates or separate listing templates is beyond me.) Most egregious is the addition of periods (full stops) in the middle of sentences (between the name of the building at the coordinate icon), but the icons are equally interruptive.

If the existence of Template:Listing is going to result in the inability to format articles without using it, then maybe we need to re-evaluate its use.

-- LtPowers (talk) 14:06, 4 August 2013 (UTC)Reply

I agree that this edit does not improve the article. Unnecessary full stops simply require some adjustments within the current template. Moreover, it is rather straight-forward to create a special "in-line" version of the template that will store the coordinates and generate a POI marker without disturbing the format of the surrounding text. --Alexander (talk) 14:18, 4 August 2013 (UTC)Reply

Take it easy. I inserted coordinates only temporarily for the dynamic map of Childs. It took five minutes. I think more effort here is not worth it. Please compare the maps (parking, gas station, land use, location accuracy, etc.). Tomorrow I will bring the article back at the previous status. - Grüße Joachim Mey2008 (talk) 14:47, 4 August 2013 (UTC)Reply

But what do we need the dynamic map for (and will it still work after you revert the article)? And why only five of the buildings rather than all eight? LtPowers (talk) 20:13, 5 August 2013 (UTC)Reply

You will see the old version of the map from the cache of your computer. Please press the [F5] key twice or click the reload icon. - The dynamic map is excellent for

Navigating to nearby article: Click on the icon 'destinations'. Immediately displays all items in a radius of 150 km. Then click on one of the symbols. The desired article is displayed.
On-site navigation: Where-am-I icon indicates your location.
More details: Parking lots, gas station, the surrounding countryside with many details (farm yards, orchards, terrain structure). - Grüße! Joachim Mey2008 (talk) 05:55, 6 August 2013 (UTC)Reply

Sorry, I've reloaded the map, even doing a hard reload, and no travel icons show up, just what's on the map tiles. LtPowers (talk) 20:11, 6 August 2013 (UTC)Reply

This is what you wanted. Then everything is fine. -- Mey2008 (talk) 04:37, 7 August 2013 (UTC)Reply

Project page does not explain how to use listings.

Latest comment: 11 years ago2 comments2 people in discussion

The overview section on the project page says The following section describes how to manually enter or edit XML-formatted listing tags., but it does not. There is also no guidance on the page as to where and when to use listing tags (with reference to comments above) and implies that there is a "non-manual" method, which is not mentioned again. The information is really only useful if you already have a pretty good idea of what to do, so would be useless to a newbie. I could barely make out what is intended, and with a high degree of uncertainty, and I have been editing a lot in wikitext for about 5 years on several projects. I would rectify it myself if I was less uncertain of what should be said. Is there a consensus on whether this templated format should be used whenever possible, or is it only for some cases? If so, which cases? Is there an automated method? Where is it described. Is it still in development? • • • Peter (Southwood) ^(talk): 07:28, 6 August 2013 (UTC)Reply

The XML tags are no longer in use; they were from a mw:extension:listings which was replaced by the {{listing}} template and its variants (see, do, buy, eat, drink, sleep). There is currently no listing editor, all listings are now templates and are manual. It looks like what you're describing is outdated info (it's the way things were done on WT, not the way they're currently done here) and should be updated or removed. There is documentation at template:listing/doc which may be of use. K7L (talk) 03:02, 10 August 2013 (UTC)Reply

One-liner pointer listings in region articles

Latest comment: 11 years ago8 comments4 people in discussion

Take, for example, this conversion of one-line listings to use the Listing template. Is this necessary, or desirable? (I realize it was a bot conversion.) Or should one-liner listings such as these be kept/reverted back to simple markup? LtPowers (talk) 14:48, 9 August 2013 (UTC)Reply

I guess it depends on whether it is desirable for the missing parameters to be added. If not, then the template is not right for this application, because its presence suggests to any editor that we want the rest of the information to be filled in. If we want the full listings to be completed in time, then the template is good. My understanding of the one liner listings policy is that for those applications specified, we do not want the full listing at any time, so either they should be reverted to simple markup, or a one-liner template should be used. A template may make consistency of format easier. • • • Peter (Southwood) ^(talk): 15:31, 9 August 2013 (UTC)Reply

I'd say that those listings (and external links) belong only in the destination guides themselves, which should be linked from that overview region article. --Peter ^Talk 23:47, 9 August 2013 (UTC)Reply

As in:

Attraction, optional terse description, Destination in the region article? • • • Peter (Southwood) ^(talk): 07:17, 10 August 2013 (UTC)Reply

Wikivoyage is not a DMOZ-style link farm. External links should not be used on anything less than a full listing, and those belong at destination (city/district) level, not region level. A long list of business names with links to vendor sites (but no info) is advertising, but not helpful to a traveller with a printed copy of the page. K7L (talk) 11:46, 10 August 2013 (UTC)Reply

So far we are in agreement, and this does seem to be a reasonable interpretation of existing policy. Any dissenting opinions? • • • Peter (Southwood) ^(talk): 12:37, 10 August 2013 (UTC)Reply

If we're going to ditch the external links, then they should follow the standard Wikivoyage:One-liner listings format, as at United States of America#Museums and galleries. LtPowers (talk) 17:34, 10 August 2013 (UTC)Reply

one-liner listings appears to recommend bold text for the caption. USA Museums and galleries uses normal. External links are not mentioned in the policy, so I assume they are not part of the normal one-liner listings. • • • Peter (Southwood) ^(talk): 19:09, 10 August 2013 (UTC)Reply

We have lost listings numbers in print version

Latest comment: 11 years ago11 comments5 people in discussion

Swept in from the pub

It seems we have lost listings numbers in print version after last MediaWiki upgrade. Could anyone check it please? --Voll (talk) 07:37, 27 August 2013 (UTC)Reply

Hi, Voll. Can you give more details? If you explain how to reproduce and check for the problem, we can more easily track it down and fix it. (I am not as familiar with Wikivoyage and with what the print version should look like.) https://blog.wikimedia.org/2013/03/18/how-to-create-a-good-first-bug-report/ has some good tips! Sorry for the trouble. Sharihareswara (WMF) (talk) 14:25, 27 August 2013 (UTC)Reply

I am soory, I have no ideas where is the issue, because this feature (numbered and autonumbered listings) was developed by User:Torty3 and User:Mey2008, I am a user only. Numbers in articles printable versions have disappeared at 3 sites: wy/en (roughly 1-2 days ago), wy/ru and wy/uk (roughly 4-5 days ago). I know that ru and en users are working on this feature independently so the problem is somewhere outside. You can reproduce the bug for example on Cologne page, there you can see colored square boxes with numbers. When you click in the left menu to Print/export and then Printable_version you will get Cologne article printable version without mentioned square boxes with numbers. Thank you. --Voll (talk) 18:15, 27 August 2013 (UTC)Reply

The colored square boxes on https://en.wikivoyage.org/wiki/Cologne are shown for me in the print preview of Firefox 23.0.1. Please tell us more information, for example your browser and if other users have the same problem. Also see https://www.mediawiki.org/wiki/How_to_report_a_bug for general information. Thanks in advance! --AKlapper (WMF) (talk) 14:50, 28 August 2013 (UTC)Reply

I have the same problem, but also the same browser: Firefox 23.0.1. --Danapit (talk) 05:52, 29 August 2013 (UTC)Reply

How is it displayed for you? Is "just" the blue background missing, or also the numbers (as they are in white it might require marking that text)? Is there still the "empty space" for these squares or is it also missing? Does it work with another browser for you? Looking at https://en.wikivoyage.org/wiki/Cologne (https), the blue squared boxes with numbers are links which have class="external text" and they link to the external website http://maps.wikivoyage-ev.org (http), so I also wonder if Firefox' new policy to not display unencrypted (http) content on encrypted (https) pages comes into play, however the CSS is not loaded from an external resource if I get it right, hence unlikely. --AKlapper (WMF) (talk) 10:20, 29 August 2013 (UTC)Reply

Both the colorful squares AND the numbers are missing (they don't appear even when the text is marked), there is no space left for them. I have no other browser than Firefox. The same problem occurs from https://en.wikivoyage.org/wiki/Cologne and http://en.wikivoyage.org/wiki/Cologne. --Danapit (talk) 10:37, 29 August 2013 (UTC)Reply

Actually, that is supposed to be the intended behaviour, and I really don't recall any difference between now or a month back. From w:Help:Printable#Printable_version (do we need a printing help page?), This printable version is often misunderstood, as it is not exactly a print preview. It does not show page numbers, headers and footers applied by your browser. For a proper print preview, use the one supplied by your browser, which means File->Print->Print preview. It works for me with Firefox 23. The PDF version doesn't work well in either en or de, so there needs to be a more customisable book extension, or a rethink. -- torty3 (talk) 11:00, 29 August 2013 (UTC)Reply

When I do the print (from print preview to pdf, not using a physical printer), the numbers appear all right. No problem. Danapit (talk) 11:07, 29 August 2013 (UTC)Reply

Yeah, sorry about the whole printable version mess, it threw me for a loop the first time round as well and is certainly not very user friendly. Basically this is the best way to cater for both printable web version and printable export to pdf version. Other ways lead to extraneous external links in the print version, unless any one has any ideas. -- torty3 (talk) 11:17, 29 August 2013 (UTC)Reply

I am sorry for silence, but I was without Internet two weeks. It seems that you have fixed it. Am I right? --Voll (talk) 18:42, 9 September 2013 (UTC)Reply

Black and Blue

Latest comment: 11 years ago6 comments3 people in discussion

Because the associated explanatory "Project page" is not in Mainspace, the names of any externally hyperlinked listing examples there display in the conventional (for the world wide web) blue colour (if the reader hasn't changed their default skin) whereas we decided that these names (when they are in Mainspace) would in fact display in black.

This may be slightly puzzling for some new editors, so should we make an effort to make the exemplars display more realistically? --W. Frank^e-mail_talk 14:34, 10 August 2013 (UTC)Reply

I think I fixed it. I can confirm that the secondary pages (WV:Accommodation listings, WV:Restaurant listings etc.) are now displaying correctly in black. The main WV:Listings page is still showing in blue for me, but it may just be a cache thing. Texugo (talk) 16:26, 10 August 2013 (UTC)Reply

Mmmm....., strange. I've just whizzed down the Mitchell Library to use one of their terminals, but there's still the same blue problem at this main WV:Listings page even though I can see that you've fixed the the secondary pages by changing our MediaWiki:Common.css. While you're at it, you might want to fix the "good" example (green background) at tout... --W. Frank^e-mail_talk 18:59, 10 August 2013 (UTC)Reply

Wikivoyage:Listings should be fixed now. -- Ryan • (talk) • 19:29, 10 August 2013 (UTC)Reply

Yup - you nailed that pesky missing comma, Ryan. I still think that the coloured icon height is 25% too tall in height compared to the listing text it is embedded in -especially that coloured part of icon above the numeral(s). It's especially and unnecessarily obtrusive and distracting when it appears in the middle of a geo-encoded POI in prose rather than right at the start of a paragraph. --W. Frank^e-mail_talk 20:03, 10 August 2013 (UTC)Reply

I tried to fix WV:Don't tout but I don't know how to make the apostrophe work properly. Texugo (talk) 20:23, 10 August 2013 (UTC)Reply

Proposed consolidation of the SEVEN current Wikivoyage:Listings pages

Latest comment: 11 years ago34 comments8 people in discussion

Currently we have one policy page for each listing type, meaning SEVEN total pages devoted to using listings in articles. These pages mostly duplicate the same information and tend to get out of sync, so I would propose that the information all be consolidated at Wikivoyage:Listings:

Each of the current pages includes the following information, which is already present on the Wikivoyage:Listings page:

Provides an example of what the listing will look like in an article.
Provides an example of the wiki markup used to generate the listing.
Provides a description of each listing template attributes.

Some of the listing pages also provide the following information, but this info is applicable to all listing types and should be consolidated at Wikivoyage:Listings:

Additionally, a few of the pages provide some additional policy information that would need to be moved. Sub-sections of Wikivoyage:Listings should suffice:

Project:Accommodation listings#Avoid listing nearest attractions
Project:Accommodation listings#Rental listings
Project:Activity listings#Tour listings
Project:Attraction listings#Complex attractions
Project:Restaurant listings#Describing restaurant chains
Project:Shopping listings#Boring stores (although this guidance applies to all listing types)

This consolidation would make it much easier to keep our listing pages current, and should also be easier for editors who need a reference. Any comments or concerns, or can I go ahead with this cleanup? -- Ryan • (talk) • 17:35, 1 September 2013 (UTC)Reply

That seems reasonable in principle to me, Ryan - but, as usual, the devil is in the detail.

(The counter argument is that, at the moment with separate articles, we can point newbies in the direction of precise advice relating to the listing type they're having problems with - when our numbers pick up, many contributors making sleep listings won't necessarily contribute eat listings. However, that argument can be addressed by making sure that the individual eat, sleep, drink, etc, sub-sections of the omnibus article have visible shortcuts - at least in WV namespace.)

I've just been working on Wikivoyage:Restaurant listings today when I spotted that someone had edited it to contain the bizarre idea that "times should be AM and PM" without mentioning the 24 hour format that is used by more than half the world's population.

My suggestion would be to show us a draft (that you agree that we can modify) in your user space and discuss anything controversial here before implementation, Ryan. --W. Frank^e-mail_talk 19:15, 1 September 2013 (UTC)Reply

I understand the reasoning behind your proposed consolidation, Ryan. My concern would be that the resulting merged page might be too long. I think Frank's suggestion is a good one - go ahead and do the work but let us see the draft and discuss it before a merge does (or conceivably doesn't) take place. Ikan Kekek (talk) 19:31, 1 September 2013 (UTC)Reply

The needs of each type of listing are distinct, so I think it's good to have separate documentation for each. Certainly some reorganization would be in order, though. LtPowers (talk) 19:52, 1 September 2013 (UTC)Reply

Here is an example of a consolidated page: User:Wrh2/Listings. -- Ryan • (talk) • 20:11, 1 September 2013 (UTC)Reply

I like the consolidated page and support the proposed consolidation on this basis. Side note: We have to resolve the problem with the "apt" shortcut. Ikan Kekek (talk) 20:15, 1 September 2013 (UTC)Reply

LtPowers: the majority of the information on the seven current pages is duplicated content, so I think there is significant value in consolidation - in particular, it is easier to keep the data up-to-date when it is in a single location and easier for editors to find the relevant info. Is there anything on the current pages in particular that you think benefits from being separate that might allow us to consolidate into fewer than seven pages? Alternately, after looking at User:Wrh2/Listings, would that be acceptable as a consolidated page? -- Ryan • (talk) • 05:47, 2 September 2013 (UTC)Reply

I looked at the proposal and it seems too long. Most of the second half of it is applicable only to specific types of listings, and consolidating them all into one long page makes them harder to find. Your proposal also omits a number of useful clarifications and details, like how to determine the price of various types of listings (for example, the detailed price information on Wikivoyage:Bar listings has been lost). Plus, I think maintaining a conceptual separation of the different listing types is desirable just from a purely psychological point of view. If there are a lot of details that are common among the seven pages, then they can be put into a helper template and transcluded into each, but I'm not sure how much of what we have would apply to that. LtPowers (talk) 14:18, 2 September 2013 (UTC)Reply

There are two goals I have, and perhaps you or others can make suggestions on how to meet them. Currently we have a lot of Wikivoyage: pages that combine "how to" with "Wikivoyage policy". In this case, the "how to" add a listing is duplicated in seven places, literally with copy and paste (I had to update them all when we switched from XML to templates). The "policy" discussions on each of those pages applies to some or all of the listing types, although in many cases it also duplicates information found elsewhere (example: Wikivoyage:Avoid long lists). If the main concern is about the consolidated listings page being too long, what about splitting it into two - "Wikivoyage:How to add a listing" and "Wikivoyage:Listings". The first would contain the information from User:Wrh2/Listings#Overview and User:Wrh2/Listings#Examples, while the second would contain the policy information from User:Wrh2/Listings#Usage guidelines? This would allow us to consolidate pages, and would also provide space to fully explain what the "price" field should be for each listing type. Consolidation of pages should be an important goal - realistically, a user trying to add listings isn't going to read a policy page for each listing type, they will read 1-2 policy pages to figure out how to add a listing, then just repeat the process for the other types - so calling out the differences between listing types in one place should be a better user experience in addition to making things easier to maintain.

Thoughts? Would that be a compromise that would address your concerns? Is there another solution that would be preferable and still allow some consolidation? -- Ryan • (talk) • 18:29, 2 September 2013 (UTC)Reply

That's OK with me, but then I thought your proposed combined single page was OK, too. Ikan Kekek (talk) 20:58, 2 September 2013 (UTC)Reply

I'm afraid, Ryan, that I don't share your aversion to combining how-to with policy. I think it better mirrors the way editors think. We don't want to send editors hither and yon; it's better to provide them with all the information (or at least a summary of all the information) about adding a particular type of listing all on one page. So they want to know how to add Sleep listings, and what policies apply to doing so, and they look at Wikivoyage:Accommodation listings and have what they need. Now, I do appreciate the problems with duplication and keeping policy in sync across multiple pages, but I fear that it might be a necessary evil pursuant to putting information where editors can find it easily. I think summarizing the differences among the different listings types is a great idea, and that would be a good addition to this page, but I think that has to supplement the individual pages, not replace them. LtPowers (talk) 01:34, 3 September 2013 (UTC)Reply

I'd like to solicit further opinions - personally I think the fact that our documentation is so fragmented makes it much, much more difficult for both new users and existing editors to figure out the preferred way of doing things. It sounds like we may have a fundamental difference of opinion on this matter. I know Peter has been doing some consolidation of policy pages lately, and my default assumption was that we should be trying to avoid duplication where appropriate, so it would be helpful if others could weigh in to get a sense of the broader community's feelings. -- Ryan • (talk) • 17:01, 3 September 2013 (UTC)Reply

I've further updated User:Wrh2/Listings to include information about what belongs in the "price" field for different listing types, and I've copied in actual listing examples rather than dummy text. As far as I can tell this single page now has all of the information that the seven separate pages have, and presents it in a single place. The page is somewhat longer than our normal policy pages, but most of that is due to the separate listing examples. In my mind having a single page instead of seven is far better from a usability and maintainability standpoint, but as that appears to be a matter of opinion I'll post a request for further opinions in the Pub. -- Ryan • (talk) • 01:35, 5 September 2013 (UTC)Reply

I think you're unfairly discounting the value, psychologically, of making sure each listing type is kept conceptually separate from the others, as well as for keeping policy pages short and easy to digest; it's far from obvious when reading the page which sections apply to which listings types. LtPowers (talk) 13:28, 5 September 2013 (UTC)Reply

I don't understand, so can you elaborate on what you feel this "psychological value" is? If a user is adding a listing, they aren't going to read the page for each listing type, they will read 1-2 pages and then ignore the rest since they "get" how to add a listing. As you noted in a comment above: "...we don't want to send editors hither and yon; it's better to provide them with all the information (or at least a summary of all the information) about adding a particular type of listing all on one page" - why doesn't that comment apply to "adding a ~~particular type of~~ listing" in general? Also, please note that the ONLY content that is specific to a single listing type is Apt and Tour, so it is only those two sections that are type-specific. As to "short and easy to digest" comment, each section of the new page is pretty short and easy to digest, and the single page is much, much shorter than the combined length of all of the old pages. -- Ryan • (talk) • 14:39, 5 September 2013 (UTC)Reply

Now that I've seen your concrete example (and ignoring the many breaches of our Mos, such as currency, phone and time notations, it contains) I am leaning towards LtPowers point of view. The Wikivoyage:Listings article should become shorter by just keeping the leading sections and a description of the use of and format of the generic listing tag and removing all the eat, do, see etc examples and discussion by just linking to the relevant specific articles. By the way, "Sleep" has the specific "checkin", checkout" fields. There's also the difficulty of one sole discussion page (this one) becoming very long if there is only one discussion page to discuss 7 different listing types. Some of the topics we will be discussing will be quite specific to "Sleep" or "Drink" or "Shop". I also think a "how to"/policy split is artificial and un-helpful. --W. Frank^email_talk 15:14, 5 September 2013 (UTC)Reply

Er... coming in a bit late, but I'd like to say I actually very much support Ryan's suggestion for consolidation. Regarding the psychological aspect mentioned by LtPowers, I can definitely tell you that I - as a relatively new but highly active editor - had a lot of pain navigating through the seven different pages, which "psychologically" was very despairing. They aren't kept up to date, they're conflicting. Whenever I try to find whether to write 18:30 or 6½pm I have to look through all seven of them to find in which one has someone found it appropriate to link to tdf which actually contains the answers I'm looking for. Some of you say you're afraid that the policy page's length might be overwhelming, but I don't think that would bother anyone: it's immediately visible that there's a very short and consice Overview section, and that does it. Another quick glance would reveal that half the page's length are just usage examples (all listed under the Examples section), and everybody knows you can ignore that if you don't need that.

If you still think that won't be obvious to new users, then how about that: create a very short "Listings overview" policy/help page, which only contains the current contents of Wikivoyage:Listings#Overview section; along with links to all relevant mos pages ($, tdf, phone, plus maybe Ryan's prices guidelines); and (if you really think it's necessary) links to a page or pages with detailed instructions for each specific listing type, with absolutely no duplicates from the root "Listings overview" page. Hope I'm not too late here. Tamuz (talk) 12:36, 11 September 2013 (UTC)Reply

Could anyone else comment? In particular, I think my last comment and Tamuz's comment above address the concerns with putting everything on a single page, and any MoS issues are easily fixed, so I think all concerns raised have been addressed. However, given the small number of participants in this discussion further comment (support or otherwise) is definitely needed. -- Ryan • (talk) • 15:10, 21 September 2013 (UTC)Reply

I, too, am waiting for more comment. I didn't see Tamuz' post, but I still think that consolidating all of these together sends the wrong message: that all of the listings types are the same. LtPowers (talk) 16:17, 21 September 2013 (UTC)Reply

I'm even more late to this discussion, but I definitely support Ryan's proposal. Our policy pages in general are sprawling, requiring new users to hunt for information across many pages, and frustrating attempts to keep them up to date and synchronized. To LtPowers' concern, I think that the usage of different listing types is similar enough where most information can be consolidated into one section (which is clearly illustrated by the fact that each page has duplicated content), while important differences can be noted on the page, as Ryan has done. Anything gained by separating the pages is outweighed by the advantage of collecting the information (especially the differences) in one place, where it's easy to find and update. --Peter ^Talk 19:35, 26 September 2013 (UTC)Reply

As I said, I'm sympathetic, but I don't feel the marginal gain in updating ease (let's face it; this stuff just doesn't change very often) is worth losing the conceptual separation that having individual pages provides. Accommodations listings are different and require different rules than activity listings, and we shouldn't pretend they're all the same just because they share some attributes. LtPowers (talk) 00:35, 27 September 2013 (UTC)Reply

I'm still not understanding what is so different about sleep and activity listings - there is a checkin/checkout attribute for sleep listings, and my latest proposal calls out differences in usage of the price attribute (other attributes are not type-specific) so further clarification would help me understand your concerns. Additionally, I'm having trouble reconciling your support for having seven separate pages with your previous statement that "We don't want to send editors hither and yon; it's better to provide them with all the information (or at least a summary of all the information) about adding a particular type of listing all on one page". While you added the caveat that your concern applies to "adding a particular type of listing", others in this thread are making exactly your argument but stating that listings are so similar that we don't want to send editors "hither and yon" to figure out how to add them. Finally, can you propose any compromise that would help us move forward? Or are we simply deadlocked over a difference of opinion? -- Ryan • (talk) • 17:10, 27 September 2013 (UTC)Reply

I support Ryan's proposal too. I agree that updating advantages are of marginal impact, but in terms of navigating through information I think this is a great gain. I use the listing tool all the time and I'm wondering what the different rules are that you are referring to, LtPowers? I'm not really aware of any, to be quite honest, so I'm probably doing something wrong. The listings editor seems quite straightforward on first sight, so I imagine there are more people who, like me, never even bothered to look for a help page on it. I think chances of people actually reading any rules are a lot higher when they are easy to find than when they're scattered over 7 different yet similar articles, so I wonder if your assumption on conceptual separation is actually correct. Whatever those differences are, would it be possible to make them explicit on the consolidated page? JuliasTravels (talk) 18:34, 27 September 2013 (UTC)Reply

Here's how I see the order of operations. User wants to add a Sleep listing. User looks through our help pages and finds Wikivoyage:Accommodation listings. There the user finds everything the user needs to know about adding a Sleep listing -- including what to do with checkin/checkout, what the "price" field should include for Sleep listings, and what section Sleep listings go in. The user also finds a good example of a Sleep listing to use as a model. The user also sees that pictures of the room should not be included, that rental listings have severe restrictions. The user also learns how to avoid long lists (and use Template:sleeppricerange) and compile information from other sources. All of this is specific to Sleep listings, and by having it all on one page, the user doesn't have to skip past irrelevant information to get to it. When the user wants to add an Eat listing, some of the information is the same, yes, but some of it is different, so having it on a separate page keeps them separate, to reduce the possibility of confusion. LtPowers (talk) 01:48, 28 September 2013 (UTC)Reply

At the risk of sounding a little bit like a jerk, I think everyone but one has agreed that Ryan's approach makes more sense than splitting the information up across seven pages, and if I'm not mistaken LtPowers' concerns have been addressed, if not always agreed with. That does mean that we have consensus (consensus is not unanimity) to make the change. --Peter ^Talk 16:46, 28 September 2013 (UTC)Reply

I haven't commented so far, but I'll add one more voice to that consensus. I look at it from the prospective of a new user, who will be able to read one page and know everything they need to know about all they listing types, rather than reading 7 pages and skipping over the many repeated parts in search of what's different. Texugo (talk) 16:56, 28 September 2013 (UTC)Reply

Without any compromise proposals remaining to discuss, any last objections before implementing this consolidation? -- Ryan • (talk) • 04:22, 29 September 2013 (UTC)Reply

In fact, I don't feel my objections have been addressed; in particular, my most recent explanation (three comments up from here) has not even been mentioned. No one has addressed the confusing layout of the proposed page, nor addressed the likelihood of a reader completely missing information relevant to the type of listing she is adding because there is so much information irrelevant to that type also present on the page. LtPowers (talk) 15:30, 29 September 2013 (UTC)Reply

It would help greatly if you could suggest ways for us to meet in the middle. As to "no one addressing your concerns", I beg to differ. Initially I proposed splitting the new page in two to address your concerns about a new page being too long, but that was deemed unacceptable. The new page has also been updated to specifically call out differences in attributes for different listing types to address your concerns, which was an excellent suggestion and definitely improves usability. Regarding your latest concerns, I don't see that a user is any more likely to miss relevant information on the new page than she was on the old page, but suggestions for improvement would be welcome. Unless I'm mistaken, this is also the first time that you've said the new page has a confusing layout, and I would argue that the layout is the same as what was used on the old pages so if it is a problem then it isn't a new problem. Beyond that, I think we're down to simply just a difference of opinion over whether or not a single page is better than separate pages, and consensus seems to have fallen in favor of consolidation. In the interest of not dragging this discussion out indefinitely I'd like to move ahead with that consolidation today, and we could then discuss improvements to the consolidated page unless there are any specific proposals left to address. -- Ryan • (talk) • 15:48, 29 September 2013 (UTC)Reply

What, exactly, is the middle ground between "these pages should remain conceptually and practically separate" and "these pages should be consolidated into one page"? If it would be sufficient to ease maintainability, then I could suggest transcluding common text into each of the separate pages, but somehow I don't think that would be enough to satisfy whatever impulse has grabbed you here. I think the resulting single-page is certainly better than it was initially, but it remains (necessarily) too long and too jumbled, trying to cram way too much disparate information into a single page. What I mean by a confusing layout is that it's hard to find information specific to one listing type without looking through the entire page and a bunch of information that isn't relevant. Ultimately, this comes down to my contention that repetition is sometimes a necessary evil to achieve clarity. Reducing maintenance work for editors at the expense of confusing readers is a bad trade-off. LtPowers (talk) 01:15, 30 September 2013 (UTC)Reply

The contention that the consolidated page is worse for readers has been disputed by the others who have participated in this discussion. Given that we're down to a difference of opinion, and that there do not appear to be any compromise proposals left to address, I'm going to move ahead with the consolidation. -- Ryan • (talk) • 01:21, 30 September 2013 (UTC)Reply

I wrote that "the devil is in the detail" and I am now quite amazed that you would want to replace 7 pages where at least some of them are current-policy-compliant with one omnibus page that wilfully introduces so many howlers. I'll try and give you a fuller critique tomorrow but, just for starters, I don't think we have actually agreed "Tony's" lower case am/pm alternative yet, and $ still says that we should use "₹" rather than "Rs. " in India. Why you think that "<pre>" is preferable to my "code" syntax is also baffling. Do you never look at what you create on standard screen widths? Can you not see how it falls off the right hand page margin? It's really pretty pointless discussing such a page unless it's pretty close to what we are really going to have - I think most of us already understand what consolidation means and we do need to know quite exactly what parts of Wikivoyage:Restaurant listings or Wv:sleep you intend to junk. Failing that, I must reluctantly and strenuously oppose any such sloppy and misleading conversion in practice if not in principle. --W. Frank^e-mail_talk 00:19, 2 September 2013 (UTC) --W. Frank^email_talk 15:14, 5 September 2013 (UTC)Reply

Why do you prefer to use the "pre" tag in the wiki markup so that the example code overflows the right hand page margin on standard width screens, Ryan? Why exactly do you think that "the recent changes did not improve readability" for you?

Why exactly don't you want us to use the "code" and "nowiki" combination in the wiki markup so that the example code does **not** overflow the right hand page margin on standard width screens but, instead wraps gracefully and adapts, Ryan? Why exactly do you think that my changes did not *improve* readability for the majority of our readers, Ryan?

--W. Frank^email_talk 19:48, 2 September 2013 (UTC)Reply

Overprecise geotagging

Latest comment: 10 years ago41 comments8 people in discussion

Okay, this is driving me up the wall.

Six decimal digits on a latitude (e.g., 45.000001) equates to a precision of about 8 centimeters. Unless you're pinpointing a street sign, you don't need that many digits, and using them implies a level of precision that isn't really accurate. Please try to use the appropriate number of digits for the size of the entity you're tagging.

-- LtPowers (talk) 17:30, 10 September 2013 (UTC)Reply

Absolutely right. Unfortunately a lot of these nonsenses were imported willy nilly by machine editing from Wikipedia (I've also seen examples of lopsided precision such as 16.66666666666666|12 and no zoom specification (when there's no zoom specification our maps currently default to a not-unreasonable-for-most-contexts 13) in countries as large as China. And it's going to get worse when the specifications I and others have carefully crafted get overridden with Wikidata. --W. Frank^email_talk 17:51, 10 September 2013 (UTC)Reply

They are unnecessarily exact but it doesn't really hurt much of anything and it's better than having no coordinates at all. Yes, many of them were imported from Wikipedia without trimming the extra digits, but feel free to trim them if you like. And Frank, who says wikidata is every going to override anything we do here? It hasn't so far, and I don't know of any plan to make our manually entered info stop taking precedence over WD in any case. Texugo (talk) 18:03, 10 September 2013 (UTC)Reply

I may have misunderstood this edit from Stefan. I'll email him in German for clarification. --W. Frank^email_talk 18:21, 10 September 2013 (UTC)Reply

I agree with Texugo here, particularly since many of the address lookup tools produce results with five decimal places. Does an overprecise coordinate do any practical harm when we're just using them to produce a dot on a map? If the lat/long gets me to the hotel or gets me to the exact tile in front of the lobby desk doesn't seem to matter, or am I missing something? -- Ryan • (talk) • 00:24, 10 January 2014 (UTC)Reply

The fallacy here is that these numbers' only purpose is producing a dot on a map. If this were some convoluted graphic-design workaround, designed to allow easier editing of maps without running an external program, then there's no problem with overprecision. But these are coordinates; they are meta-data about the location, and part of that data is the precision to which the location is known. Saying something is located at 45.42984 implies that it's not at 45.42979, and in the case of most objects we geocode, that's just not true. The fact that we don't currently display the coordinates to the user except on a map should be irrelevant when it comes to getting the data right now.

If it helps, consider a trivial case: the expression "45.430000" is computationally the same as "45.43". But the former conveys significantly more certainty about the location. Each has its uses, but they should not be treated as interchangeable, because they convey different information. The same applies to any decimal; it's just more obvious when it's zeros.

-- Powers ^(talk) 13:58, 10 January 2014 (UTC)Reply

For latitude anywhere or longitude at the equator, one minute (.01666 degree) is one w:Nautical mile, about 1.8 km or 1.5 land miles. Out toward the poles a minute of longitude is less. That means a degree is (at most) 60*1800 = 108000m so four decimal places is accurate to about 10m and five to about one.

To me, that indicates that nothing here should ever use more than four or five decimal places and co-ordinates for larger things like towns or regions should mostly use two or three. Pashley (talk) 14:30, 10 January 2014 (UTC)Reply

Here is Wikipedia's policy on the matter, and if someone wants to write something similar up for use here it would be helpful: w:Wikipedia:WikiProject Geographical coordinates#Precision (alternately we could just agree to use their guidance). HOWEVER, I believe strongly that the current discussion at User talk:Mey2008#Overprecision is a bit too harsh - five decimals of precision is what a lot of the lookup tools produce, so while policy should allow correction to reduce such over-precision, this strike me as a similar issue to our policies on dates and times, ie that it is not something we need to strictly enforce. Precision can be reduced when doing cleanups (assuming the coordinates remain accurate), and people should not be changing coordinates to add unnecessary precision, but we should not be chastising people who take the time to add lat/long coordinates for using five decimals when four would have sufficed. -- Ryan • (talk) • 15:59, 10 January 2014 (UTC)Reply

For the record, Mey2008's edits to which I objected were a mix of new coordinates and changed, more precise coordinates. If it had been the first instance of this happening I would not have been so strident in my language. Powers ^(talk) 16:51, 10 January 2014 (UTC)Reply

Frank and the good Lieutenant were right in suggesting that decimal places beyond 6 were ridiculous. Powers is academically correct in his point about the implications of metadata; however, this concern is outweighed by his objections to dynamic map implementation on the grounds that, many times (and especially at low zoom levels), the overly large markers obscure important detail. However, most readers will quickly learn to increase the zoom level (when they're on-line, of course) to reveal any obscured detail.

Additionally, Joachim has responded to these concerns by writing: "To clarify: I use 5 decimal places with intention. So I can place the markers exactly. Then they do not hide captions and signatures. With fewer decimal places that is not safe". It may well be that Joachim is using (to some people's mind) an unnecessarily precise level of co-ordinate specification precisely to meet this objection and ensure that, at high magnifications, no significant detail is obscured by (more random) marker placement. Since anyone using http://maps.wikivoyage-ev.org/w/geomap.php to look up co-ordinates is going to get a result with five decimal places I don't think that anyone should waste time trimming other editor's conscious work to 5 or less decimal places.

I can clearly see why Joachim might want to use five (or even 6 decimal places) to avoid markers overlapping or obscuring detail but, so far, I fail utterly to see why any markers listed with five (or even 6 decimal places) of precision need to be re-done at all.

The actual co-ordinates are hidden from our readers unless they examine our template code, so I fail utterly to see what the big drawback of that over-precision is. It's not like it's an over-precision clearly visible and irritating to our readers in the article prose such as pints (568.26125mL) of Guinness are expensive in Dublin, is it? --118.93nzp (talk) 01:42, 11 January 2014 (UTC)Reply

I have not been aware of this discussion and have been using 6 decimal places for my locations (This is because Bing Maps has a handy geo locate popup box that yields 6 digit lats and longs).

I will stop doing this for now, although I should mention that the guidance on Wikipedia:WikiProject_Geographical_coordinates#Precision doesn't actually tell me NOT to use detailed precision but just explains the implication of using each one. Additionally, I'm with 118.93nzp in not understanding why it is required to fix any existing decimal places greater than 5 points in precision?

I would ask that the rationale behind 5 decimal places is explained a bit more clearly and in a more visible place than it is currently. Andrewssi2 (talk) 07:32, 30 January 2014 (UTC)Reply

Even five is too many for most purposes in a travel guide. Four should be plenty. Any more than that and we imply a level of precision greater than what is actually present. It's like when you're on the phone with someone and ask where they are, and they say "five meters north-northwest of my front door." Powers ^(talk) 01:52, 31 January 2014 (UTC)Reply

With respect, Powers. it's not.

These raw co-ordinates are hidden from either the printed or online view and are not obtrusively precise to our readers. As Joachim has explained to you (and I'd be grateful for an explicit acknowledgement that you have understood and agreed with his reasoning) they may sometimes serve a very good purpose in making sure that, at very high zoom levels, auto-generated point of interest labels do not overlap or obscure other significant detail.

If you have followed any of my edits, I personally have been known to remove as many as 9 significant figures at the country or region level, but further down the hierarchy is different.

A better analogy might be that your home has been attacked by kidnappers who are now laying seige to a SWAT team outside. You have managed to seek refuge in a secure room and are on the phone to the SWAT commander who does not have a plan of the interior of your home and asks where you are (to avoid collateral damage in the imminent assault), and you say "five meters north-northwest of my front door." In this specialised situation the attempted precision is useful and does no harm. --118.93nzp (talk) 02:13, 31 January 2014 (UTC)Reply

I'm sorry but a life-or-death situation is a poor analogy. It may be true that at the moment, the raw co-ordinates are hidden, but what happens when that's no longer the case? Even now, there could be third-party applications out there using the coordinate data for some purpose that we don't know about; it's important to be correct now about the data we're putting out into the world, because we don't know who's using it. Powers ^(talk) 16:31, 31 January 2014 (UTC)Reply

Excellent new point that I hadn't thought of. Let's address it if and when we discover that third-party application out there using the coordinate data for some purpose that we don't know about. For now, you are very welcome to trim all coordinates that exceed 6 decimal places and do a selective cull where you are certain they will not bugger label placement. I would strongly counsel caution when trimming coordinates that have been specifically edited to be more accurate by experts such as Joachim.

I'd still be grateful for an explicit acknowledgement that you have understood and agreed with Joachim's reasoning. Consensus is very difficult to achieve if interlocutors deliberately ignore specific questions for the sake of polemics. --118.93nzp (talk) 17:00, 31 January 2014 (UTC)Reply

We have developed the dynamic map so anyone can create an useful map in a simple way. This includes entering the coordinates in listings. How easy would be the statement: In this wiki we use only coordinates in decimal notation. Coordinates are always specified with five decimal places, even if this were not necessary sometimes. That would be a clear guide for beginners and users who do not want to deal in detail with this issue. - The argument with use by third-party applications is untenable. Some data in the wiki may be incorrect, outdated, or inaccurate. Liability for all data is excluded, everybody knows that. The user must be satisfied with it, or should use other sources. -- Joachim Mey2008 (talk) 11:27, 1 February 2014 (UTC)Reply

I'm afraid I don't find Joachim's reasoning compelling. Needing to tweak the input data to be less accurate in the interest of improving the output of only one specific usage of that data is what is untenable. The problem is conflating these "coordinates describing the location of the listing" with Joachim's desired "coordinates to decide where the markers should appear on a map", and the two uses are related but not necessarily compatible. Powers ^(talk) 15:46, 1 February 2014 (UTC)Reply

This makes it understand by non-specialists: A GPS-assisted device (smartphone) will take you exactly to the coordinates that you entered. With 5-digit coordinates you are led into the heart of the great city. Just on the 2 historic market square (52.15275|9.95174). Wow! 2-digit coordinates also lead in the center of the city. In any 3 backyard (52.15|9.95). Wow? Please click the markers and compare the preview images :) . - Two-digit coordinates have a grid of about 1000m. No chance to refer to the exact desired location . Even 3-digit coordinates are not sufficient. They could guide you to the other side of a highway or a river. -- Joachim Mey2008 (talk) 06:34, 2 February 2014 (UTC)Reply

There is only so much we can do to protect people from their own stupidity. I can't imagine taking coordinates with four significant figures from an article on a city and expecting them to lead me within a few meters of an interesting site. Coordinates with that level of precision are only intended to get you within a kilometer or so; if they were more specific, they'd have trailing zeros. Powers ^(talk) 14:31, 3 February 2014 (UTC)Reply

Well yes, and that's why I'm baffled by this edit of yours. It's also better to stick with the current level of 5 or 6 significant figures after the decimal point as being the easiest and most useful level of accuracy for the majority of (stupid) users and assume that the developers of external apps should have the knowledge to round or truncate where appropriate. --118.93nzp (talk) 16:16, 3 February 2014 (UTC)Reply

Hundreds of malformed coordinates prove it. Also interested users have enormous difficulties when entering coordinates, especially with decimal places. LtPowers is right, but only in theory. Practically his comments without benefit. Today's users make no theoretical thoughts about the accuracy of the coordinates. They see no coordinates in their navigation software. But the navigation will guide them exactly on the "backyard" coordinates. - In my beautiful hometown, the geographic center is in the middle of a huge roundabout, 3 km east of the touristic center of town. Who needs that? This is a guide for tourists. Coordinates should always have the practical benefit that a tourist expects - not just a senior teacher. - Joachim Mey2008 (talk) 08:19, 4 February 2014 (UTC)Reply

I'm afraid I cannot countenance a preference for practicality over correctness, especially not when it will lead to more work for us and for re-users of our content in the future. Powers ^(talk) 13:37, 4 February 2014 (UTC)Reply

I am just not buying that it will actually lead to significantly more work for us, and I don't see why we would have a special responsibility to go above and beyond what is practical for our own purposes to make sure our data is technically correct for any ulterior purposes a reuser might wish to pursue. Texugo (talk) 13:51, 4 February 2014 (UTC)Reply

I'm sorry to be obtuse about this, but currently I just can't imagine how having five or even six levels of decimal places in geo-coords "will lead to more work for us ...in the future". On a few occasions I do cut down four to eleven (!) places of decimals in country templates, but that's just my usual copy-editing mania and is entirely optional and voluntary. I know that you have a great interest in and expertise with maps, Powers, so if this really is as important as the language you use implies, could I trouble you to spell out exactly what this extra future and necessary labour might be? --118.93nzp (talk) 03:42, 5 February 2014 (UTC)Reply

If and when the time comes that we need to make better use of this data, then we would have to back through and round off the overprecision to the proper precision level. Far better to do it now as the coordinates are added, especially with the added benefit of making this easier on reusers. Texugo, the whole point of the site is to provide easily reusable travel information to the world. That's what CC-by-sa is for. I am stunned that you think we don't have a responsibility to others. Powers ^(talk) 00:44, 6 February 2014 (UTC)Reply

Thanks for explaining that; I think they are both points that require further cogitation. --118.93nzp (talk) 00:54, 6 February 2014 (UTC)Reply

(edit conflict) LtPowers - Texugo didn't say that we "don't have a responsibility to others", he said we don't have a responsibility to "go above and beyond what is practical for our own purposes". As noted far above, I agree in this case - I don't see that five decimal places does any harm, and it has benefits when used with dynamic maps. Additionally, I'm usually finding 4-6 decimal points in coordinates I find online, be it in Wikipedia or on government web sites for public lands, so if overprecision is truly a problem (which several people are disputing) then it's a widespread one, and as such not something that I think we should be too concerned over. -- Ryan • (talk) • 01:01, 6 February 2014 (UTC)Reply

To whom, then, do we not have a responsibility when we're avoiding going beyond what is practical for our own purposes, if not to others? Powers ^(talk) 18:09, 6 February 2014 (UTC)Reply

The odd semantics of that question aside, my point was that we are bound to adapt the data to be suitably accurate for our purposes, on our travel site, in our templates, on our maps, for our readers. 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 every other imaginable tertiary purpose that someone might want to data-mine our site for. Texugo (talk) 18:24, 6 February 2014 (UTC)Reply

Yes, we do. And they aren't tertiary purposes, they're secondary. Powers ^(talk) 02:15, 7 February 2014 (UTC)Reply

Yep, that's the very document in question. I don't see anything there that supports an absolute-accuracy-or-nothing argument any more than it would support an argument that we have a duty not to list phone numbers unless we have actually called to make sure they are correct. Texugo (talk) 10:22, 7 February 2014 (UTC)Reply

That document requests that we make our guides useful for "Inclusion in other travel publications – for travel-guide publishers and advisers who want up-to-date information." That inherently gives us a responsibility to make sure that the guides convey accurate information. Powers ^(talk) 13:29, 7 February 2014 (UTC)Reply

Summation

At this point I think this topic has been discussed to the point where everyone has had an opportunity to make their arguments, and we seem to now be going around in circles. My reading of the above is that this discussion has resulted in no consensus, but I'm not entirely sure whether there was ever any specific proposal to change existing policies. Is there some specific change to policy pages that we want to propose, or should we just stick with the status quo where people can use 5-6 decimal places where they see fit, others can trim the precision if they desire, and in cases of dispute each side takes it to a talk page? -- Ryan • (talk) • 02:28, 7 February 2014 (UTC)Reply

If you want a specific proposal, it's this: That Wikivoyage:Geocoding and Wikivoyage:Listings add text that makes clear that coordinate precision is a consideration, and that coordinates should be exactly as precise as necessary. It's extremely important to note that these coordinates are not just tools to generate maps. I don't think anyone has acknowledged that fact. (But then, we've only had five or six people even weigh in; it might be worth putting up an RFC to see if we can get more input.)

The status quo, I should point out, is extremely burdensome on those of us who know that precision is a vital property of any measurement. Consider again the difference between "43.320000" and "43.32". The first tells you something that the second doesn't, and the two are not interchangeable. Powers ^(talk) 13:29, 7 February 2014 (UTC)Reply

To tell you the truth, although I find that distinction to be of extremely minimal consequence to almost anyone, it wouldn't bother me so much to have some language encouraging a target degree of precision when practical and when there is no reason not to. However, my main concern is that, just as we don't frown on people adding a listing with incomplete details or starting an article with only a little info, we still must recognize that it's better to have something than to have nothing — better an approximation than a complete lack of info. It's far better to have some coordinates than it is to have none at all, even if the precision level does not perfectly match your apparently rigorously demanding standards. Texugo (talk) 13:49, 7 February 2014 (UTC)Reply

As I read the above discussion, several people have argued that overprecision is not a problem when it is done with intention, specifically in relation to dynamic maps. I don't think anyone has argued for using more than 5-6 decimal points of precision, so indicating that anything more precise than that should always be trimmed seems good, and having text indicating that trimming is fine in cases where there is no reason for the overprecision is fine, but it does sound like people want the ability to use very precise coordinates in some cases. If we wanted to boil that down into something that could be included in a policy page, what about "There should never be a need to include more than 5-6 decimal points of precision in lat/long coordinates. Unless there is a specific reason for using very precise coordinates, try to use a level of precision that is appropriate for the item being described - see w:Wikipedia:WikiProject Geographical coordinates#Precision guidelines for some helpful guidance." -- Ryan • (talk) • 15:56, 7 February 2014 (UTC)Reply

That's a good start, but I'd prefer that the reasoning behind this advice is expanded slightly: Don't use more than 5-6 decimal places of precision in lat/long coordinates. Unless there is a specific reason for using very precise coordinates (eg, ensuring labels do not overlap or obscure important detail), use a level of precision appropriate for the item being described - see Wikipedia's Geographical coordinates:Precision guidelines. --118.93nzp (talk) 01:36, 8 February 2014 (UTC)Reply

I can't disagree with Texugo that something is better than nothing; my problem is not with new editors who don't know any better, but with editors who do, and have been reminded multiple times, but yet stubbornly continue to use excessive levels of precision, when rounding to appropriate precision would be much simpler and easier for them to do than for a later editor to come along and do later. Keep in mind, also, that coordinates taken from WP may be decimal conversions of DMS-formatted coordinates, which may have unknown degrees of precision, rendering the extra decimal places meaningless. (For example, an object with a coordinate of 45.816743 could be rendered as 45° 49' 0.264", which would round to 45° 49'. But if you take that 45° 49' and convert it to decimal, it comes out 45.8166667. Using that excessively precise figure is not just misleading regarding precision, it's actually wrong.

Ryan's wording is good, but it should really be 4 places of precision on this page, and 2-3 on Wikivoyage:Geocoding (for cities and villages). 5-6 is way too many unless you're pinpointing a statue. And I'm still uncomfortable recommending that these numbers be adjusted to make dynamic maps look better. What happens when the underlying layers of the maps change (thus changing the location of text that these coordinates were adjusted to avoid)? What about when a listing is removed; will coordinates of items that were adjusted to avoid conflicts be adjusted back to their proper precisions? Powers ^(talk) 18:09, 8 February 2014 (UTC)Reply

If I may suggest an alternative to overprecise coordinates for purposes of making maps look better, it would be to improve the map software so that such conflicts are resolved automatically. After all, isn't one of the advantages of dynamic maps that they don't require as much human tweaking? Powers ^(talk) 18:18, 8 February 2014 (UTC)Reply

Of course that would be the ideal situation but, being fair to Joachim, I seem to recollect that he's come up with at least two automatic schemes so far that saw little or no consumer support.

It would be nice to think that we could make things better (rather than perfect) in the interim, but seeing the way that user's stated preferences for thumbnail sizes have been flouted and subborned for months on the pretext that we're waiting for the perfect solution of an increase in the default size from 220px to 270px, I'm certainly not holding my breath with regard to co-ordinate accuracy.

That's why I could not support any formulation that does not make clear why some editors may "adjust" the academically correct accuracy as a "temporary" workaround. --118.93nzp (talk) 03:57, 9 February 2014 (UTC)Reply

There's a difference between explaining and recommending. Powers ^(talk) 16:24, 9 February 2014 (UTC)Reply

Telephone number

Latest comment: 11 years ago31 comments8 people in discussion

I would like to propose making the phone number a hyperlink that will take mobile devices to the phone function and pc to the VoIP application. This would be really useful for making restaurant reservations or check hotel availability. I believe would make the site much more popular. The hyper link appears to work ~~but only if there are no spaces in the number~~.

Template:Marker/sandbox, ☏ +49 800 791-0100.
Template:Marker/sandbox, ☏ +49-800-791-0100.
Template:Marker/sandbox, ☏ +49 (0)800-791-0100.

So do other think this is a good idea? ~~Would the dash in number be acceptable? If so we could run a bot through pages to change the format of numbers.~~ Have ~~not~~ been able to find a way to strip whitespace out of a parameter in a template. --Traveler100 (talk) 13:35, 28 September 2013 (UTC)Reply

If you could get that to work, I do think it would be a great asset. JuliasTravels (talk) 14:22, 28 September 2013 (UTC)Reply

~~As long as there are no spaces in the number it works.~~ Would appreciate people testing the example above on different devices. Do not be concerned it does not directly dial it goes to the call menu but you will have to make an additional call press action before it connects. --Traveler100 (talk) 19:06, 28 September 2013 (UTC)Reply

Please test

Template:Marker/sandbox, ☏ +1-202-226-8000. M-Sa 8:30AM-4:30PM. The center of the legislative branch of America is home to the House of Representatives and the Senate, as well as numerous impressive paintings, statues, historical exhibits, and one magnificent dome. Free.

Tested on:

Windows with Firefox, Internet Explorer and Chrome works.
- Connect fine to phone option of Office Communicator passing the call number through.
- Can get to start Skype but will not pass in number.
Android smart phones
- Andrioud 4.1 works.
Blackberry works.

format

So I just discovered this page Wikivoyage:Phone numbers, but judging by entries on many pages a lot of other people were also not aware of it. So currently the recommendation is to have a space between <country code> and <area code> and also between <area code> and <local number>; only using dashes within the local number part. This will make hyper-linking for mobile devices difficult to code. Do people think this is an important convention or something that can be changed for additional functionality? After all I think most readers now use mobile smart phones in preference to the one in the hotel or even at home, and those using a land line will probably not have it connected to a web browser.--Traveler100 (talk) 20:44, 28 September 2013 (UTC)Reply

I didn't see this discussion before objecting at Wikivoyage talk:Accommodation listings and Wikivoyage talk:Shopping listings. To get this functionality, is it worth dictating a format no-one or very few people use, otherwise, and prompt the editing of hundreds of articles? By the way, the fact that the edits to the phone number format took place in several different listings pages and turn out to have been discussed here should provide additional ammunition behind the idea of unifying the listings pages (and, therefore, the policy page) into one page. Ikan Kekek (talk) 21:24, 28 September 2013 (UTC)Reply

What is the proposal? Having phone numbers be clickable for mobile devices is obviously something we want. --Peter ^Talk 21:29, 28 September 2013 (UTC)Reply

Yes, it is. The proposal is to hyphenate everything: e.g. +1-800-555-1212. I may have occasionally seen the 1 hyphenated to an 800 number, but otherwise, this is pretty much never done in the US, nor can I recall ever seeing country codes hyphenated to phone numbers in European countries. I would wish there could be another way to have this functionality than by hyphenating everything, and if we do decide to hyphenate everything, we'll have to use a bot to do it - repeatedly - because people are not going to automatically use this format when creating listings, no matter what our stated policy is. Ikan Kekek (talk) 21:55, 28 September 2013 (UTC)Reply

I agree that it would be better if we didn't have to hyphenate everything—it looks a little weird to me, although I think I've seen just about every format imaginable in use somewhere. I'm pretty sure that {{listing}} could be altered to automatically switch from spaces to dashes, though, so I don't think a bot would be necessary. --Peter ^Talk 23:48, 28 September 2013 (UTC)Reply

We traditionally have used dashes to distinguish between must-dial and optional-dial parts of phone numbers. Going to all-dashes would eliminate this semantic information. I'm not aware of any good way to get a template to convert displayed textual information on the fly; text parsing is tedious and computationally expensive in templates, and our listings templates are used dozens of times per page. LtPowers (talk) 00:17, 29 September 2013 (UTC)Reply

I've always thought of our distinction between spaces and dashes to be more of a hypothetical ideal than a reality ;) I've always had to consult the country page#Contact to really figure out what's going on, and if that fails, Google. --Peter ^Talk 04:13, 29 September 2013 (UTC)Reply

I agree the idea of the policy to use dashes to show the local part of the number is a good and useful idea in principle but does not appear to be used universally. In fact telephone numbers on many articles consist of many flavours. Take a look at this update bot test I did, pages consist of every type of separator and county and region code format. Also not sure how many readers will see and understand the subtlety of the spaces and dashes. I think pages could do with a mass update to clean up the different formatting. Updating the pages, which has been done with things like new listing format and banner page, is not a bad thing. It actually helps up the search engine rankings. The maintenance of keeping the format correct does concern me a little though, would help it the listing editor could format on save but will probably also mean a regular bot check of pages. --Traveler100 (talk) 05:47, 29 September 2013 (UTC)Reply

if the phone number consists of only a plus sign and numbers separated by dash (minus sign) it is possible to do a syntax check in the template and create a category listing article with incorrect format. --Traveler100 (talk) 11:01, 29 September 2013 (UTC)Reply

Code currently in {{Listing/sandbox}} will only create the telephone hyperlink if in correct format, otherwise will just print as text.Traveler100 (talk) 11:12, 29 September 2013 (UTC)Reply

There is a better way to do it. Just remove all the spaces from the url part but leave them in the display part, so you could get for example +1 234 567-890, then there is no need to update all the phone numbers to change all spaces to dashes. -- WOSlinker (talk) 11:18, 29 September 2013 (UTC)Reply

Sounds promising. What is the syntax? And can it be also used in the error check so can then ignore numbers that have brackets and other separators in them? Traveler100 (talk) 11:28, 29 September 2013 (UTC)Reply

I've created {{Listing/sandbox2}} and here's an exmaple: {{listing/sandbox2| name=Exploratorium | phone=+1 415 528-4360}} -- WOSlinker (talk) 11:30, 29 September 2013 (UTC)Reply

awesome, that save a lot of work and controversy.--Traveler100 (talk) 11:48, 29 September 2013 (UTC)Reply

So now in {{Listing/sandbox}} is a syntax that will create a phone link if the number only contains digits, dashes, spaces and plus sign; otherwise it prints as normal text. Need to make a few more tests, but would this be acceptable to people? --Traveler100 (talk) 11:48, 29 September 2013 (UTC)Reply

I've also updated the tollfree param in the sandbox to be linked as well. -- WOSlinker (talk) 12:37, 29 September 2013 (UTC)Reply

I've added the category tracking, without the link formatting part into the live template just to make it easier to see where some of the problems may lie, and the category is now filling up. One issue I have noticed is that there are some phone number where the country code and area code are sometimes put into italics. Also, some of the phone numbers don't contain a country code (but these won't be included in the category, since the #expr works fine on the numbers.) I think it may be worth expading the lua part a little more to strip out a few other characters and also tracking those phone numbers that do not start with a + in a separate category as well. -- WOSlinker (talk) 15:33, 29 September 2013 (UTC)Reply

I've done a function at Module:LinkPhone which will do the link formatting and will also flag those without a country code. Could use that instead of the #expr function if you want to. It also handles the italics issues. -- WOSlinker (talk) 16:50, 29 September 2013 (UTC)Reply

thanks that looks useful. Someone else will have to make the edit though as I do not have edit rights to the listing template.--Traveler100 (talk) 16:53, 29 September 2013 (UTC)Reply

Ok, now live. -- WOSlinker (talk) 17:03, 29 September 2013 (UTC)Reply

@Traveler100: You do have the edit rights to the listing template, the only restriction is against anon IPs and new users.

Looking at the new format, I would prefer to remove the external link arrow using , but then it won't be that obvious that it's a link. Thoughts? -- torty3 (talk) 05:38, 30 September 2013 (UTC)Reply

The telephone link also shows up in the printable versions, which is very awkward looking. Any ideas how to fix it, or will a hack like the maps link be needed? -- torty3 (talk) 05:53, 30 September 2013 (UTC)Reply

if someone knows how to remove the link arrow I do not think that would be a problem, on mobile browsers the number will still highlight as a dial link.Traveler100 (talk) 05:59, 30 September 2013 (UTC)Reply

I've added some code to the module to hide the extra link when printing but it will need the following code adding to Mediawiki:Print.css -- WOSlinker (talk) 06:26, 30 September 2013 (UTC)Reply

.nourlexpansion a.external.text:after {
    display: none !important;
}

Unfortunately that doesn't remove the extra link when you click "Download as PDF". I ran into the same problem when inserting the maps.wikivoyage-ev.org links, and was hoping someone had a better solution. Unless the Books extension can be tweaked, or perhaps we should at least put in the CSS for now. -- torty3 (talk) 07:12, 30 September 2013 (UTC)Reply

I've been looking into something similar for Wikisource. Wikipedia has the templates {{hide in print}} and {{only in print}} to handle similar problems. Perhaps you can import them, or steal bits of their code, and adapt them to your needs. - AdamBMorgan (talk) 11:17, 30 September 2013 (UTC)Reply

These no longer work. See the bugs linked in Wikipedia:Help:Books/Feedback#Category:Exclude in print, specifically Bug 45861 -- WOSlinker (talk) 11:54, 30 September 2013 (UTC)Reply

OK, what I take away from the link is that the extension really needs an update. I'll go ahead and add the CSS, so the web printable version is useable, and also add the plainlinks in. -- torty3 (talk) 10:19, 3 October 2013 (UTC)Reply

Consolidated listings page

Latest comment: 10 years ago6 comments2 people in discussion

I just looked through this page and made a few relatively marginal edits. I think it's great to have all of this here. I find it readable, and I think the content in one section reinforces or at least follows from the others. Kudos are due! Ikan Kekek (talk) 05:19, 30 September 2013 (UTC)Reply

You don't see a problem with treating "see", "sleep", etc. as just variations on a theme rather than individual types of listings with their own requirements and rules? LtPowers (talk) 14:07, 30 September 2013 (UTC)Reply

No, I don't. However, if you think the differences between the guidelines for different kinds of listings are insufficiently clear, the page can be edited to further clarify this. Ikan Kekek (talk) 18:12, 30 September 2013 (UTC)Reply

I'm not sure how, without dividing the page into seven separate sections, each with some repeated information. And that would be an objectively worse situation than we had before the big change. LtPowers (talk) 18:36, 30 September 2013 (UTC)Reply

An alternative that comes to my mind is to mention only those things that differ between the different types of listings, not to repeat the things that are in common. And these things can be mentioned in the "examples" sections, right after each already existing subsection. Ikan Kekek (talk) 22:04, 30 September 2013 (UTC)Reply

The conversation below reminds me of another drawback to consolidation: talk page discussions on accommodation listings or activity listings or restaurant listings now all go on one page, instead of being neatly segmented and organized. LtPowers (talk) 19:48, 3 December 2013 (UTC)Reply

Mid-range or Splurge

Latest comment: 10 years ago4 comments3 people in discussion

What qualify as a splurge hotel? Both Regent Plaza and Beach Luxury hotels in Karachi are full-service hotels but because they charge less for standard rooms, I've listed them as "Mid-range" hotels. --Saqib (talk) 14:37, 2 December 2013 (UTC)Reply

That sounds like a good decision. These categories are flexible and have no absolute meanings. What's a splurge in rural Ethiopia might be a budget hotel if it were suddenly transplanted to New York City. Ikan Kekek (talk) 18:40, 2 December 2013 (UTC)Reply

Some destinations have a templated box on the page itself indicating where the boundary has been arbitrarily drawn between budget-midrange-splurge. If not, the line is arbitrary. K7L (talk) 19:48, 2 December 2013 (UTC)Reply

Actually I was confused because Beach Luxury standard rooms starts at a mid-range price but they also have Executive rooms which are at splurge rates. Anyway, I've moved the said hotel listing under "Splurge" sub-section. --Saqib (talk) 19:56, 2 December 2013 (UTC)Reply

Listing templates vs. tags

Latest comment: 11 years ago4 comments3 people in discussion

Swept in from the pub

Hi. It isn't clear to me from Wikivoyage:Listings wether templates are prefered over tags. The examples use templates, but the tools linked from the page use tags. If templates are prefered, is there any robot/script than can convert a large number of tags to templates? Thanks.--Strainu (talk) 12:05, 20 November 2013 (UTC)Reply

The tags were replaced by templates earlier this year and are now deprecated; bugzilla:43220 redirects the tag output through the template in any case. A 'bot script was run at that time to replace all of our existing tags with templates. Any documentation which describes tags or links to tags should be changed as the listings editor expects templates. K7L (talk) 15:13, 20 November 2013 (UTC)Reply

Thanks, so there was a bot, as mentioned on Mediawiki.org :) Who run it? I'm interested in having access to the source code or to ask the user to run it on ro.wikivoyage also. Thanks again.--Strainu (talk) 16:42, 20 November 2013 (UTC)Reply

See Wikivoyage:Script nominations#XML listings to templates. I've run the bot on pt, it, fr and ru, and if you'd like it run on ro: see User talk:Wrh2#Help for fr:voy for a list of translations that I would need. It's the holiday season in the US right now and I'll be traveling a bit over the coming weeks, so I might not be able to get to this immediately but will do my best to get it done as soon as possible. -- Ryan • (talk) • 16:58, 20 November 2013 (UTC)Reply