YOU CAN EDIT THIS PAGE! Just click any blue "Edit" link and start writing!

Wikitravel talk:Listings

From Wikitravel
Jump to: navigation, search


Templates for listings[edit]

Moved from Wikitravel talk:Using Mediawiki templates by 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 .

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

(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}} 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? --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. 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. 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. --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. --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? 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? -- 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 Wikitravel 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:Evan/hcard examples. --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 [8] which is included into other templates [9] 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 Wikitravel versions, so (eg.) changing the telephone number in French version would automagically change the number in Japanese one too. 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. -- Evan
A day, as in a single 24-hour period? Egads! I think I can restrain myself that long... 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 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. --Evan 13:51, 4 April 2006 (EDT)

Listings tags[edit]

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="" price="$100-$280">Fun B&B with 25 rooms. 
Located on the Plateau and across the street from Parc Lafontaine. </sleep>

This becomes:

  • Auberge de la Fontaine, 1301 rue Rachel est, +1-800-597-0597 (fax: +514-597-0496), [1]. Fun B&B with 25 rooms. Located on the Plateau and across the street from Parc Lafontaine. $100-$280.  edit

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? --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. --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. -- 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? --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: 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:

<sleep name="Sijori Resort" tel="+65-6271-2002" url="" price="S$120-">Blah blah</sleep>
Sijori Resort, [2]. Blah blah S$120-.  edit

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! 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?) Jpatokal 13:00, 6 April 2006 (EDT)
The buy tag is a good idea.
The attribute is actually phone, not tel. viz.
  • Sijori Resort, +65-6271-2002, [3]. Blah blah S$120-.  edit
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. --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. 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. 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 "<br />" 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. - 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 (Wikitravel:restaurant listings, ...) pages to use this format. --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. 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"). 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. -- 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 Wikitravel 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 Wikitravel[edit]

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. 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. --Evan 08:23, 14 April 2006 (EDT)
Now implemented! Jpatokal 07:09, 30 April 2006 (EDT)

List or not list?[edit]

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. 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.) -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. 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 Wikitravel. I think if we served information about listings as a WFS and/or KML service, we could let people include Wikitravel data in lots of fancy mapping mashups -- some innovative stuff is going on out there. --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. --Evan 15:48, 17 June 2006 (EDT)
Doesn't using the closing </li> tag after every list item make it valid XHTML? --Rogerhc 15:56, 11 June 2007 (EDT)

Additional attributes and tags[edit]

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. 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. Jpatokal 15:43, 17 June 2006 (EDT)

Tag name redundancy[edit]

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. - 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"? --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... 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? -- Mark 01:05, 16 May 2006 (EDT)

Automated conversion script[edit]

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: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. Jpatokal 03:41, 4 June 2006 (EDT)

Where are we on this?[edit]

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. --Evan 14:27, 17 June 2006 (EDT)
Can I add tags for future RDF implementation? — 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 '<'. --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. 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? -- 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? 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. – 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...? Jpatokal 01:21, 10 June 2007 (EDT)
Try your beloved hometown [10]. 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. --Evan 08:53, 11 June 2007 (EDT)
Spiffy-keen! Now can you conjure up a button for adding new entries like that as well? Jpatokal 11:19, 11 June 2007 (EDT)
The text fields in the wizard need to be longer. Maybe use a <br/> in the Wizard after each input text field to create room for that. --Rogerhc 16:10, 11 June 2007 (EDT)
Wow! That is an excellent piece of work. 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! – 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? – 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? – 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 – 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. -- Ryan • (talk) • 14:34, 23 June 2007 (EDT)
Any chance you're related to this chick? -- Sapphire(Talk) • 14:46, 23 June 2007 (EDT)
Ha! First time I've ever been compared to a lesbian in adult diapers. – 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. --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! – cacahuate talk 05:20, 1 July 2007 (EDT)

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

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:
    • some attraction. Some details  edit
    • some other attraction. Some other details  edit

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

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. JimDeLaHunt 03:21, 7 August 2007 (EDT)

Feature or bug?[edit]

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

  • Britannia and Co, Sprott Road, Ballard Estate, Fort, Mumbai (next to New Custom House.), +91-22-2261-5264. 10 am to 3:30 pm (''Open only for 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. Rs. 180 will buy you a good lunch..  edit

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. 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... --Evan 12:11, 3 November 2006 (EST)

For those of us who are visual learners[edit]

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. - 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. - 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. - 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. - Todd VerBeek 08:04, 16 May 2006 (EDT)
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 -- 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. - 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. -- 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. - 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 Wikitravel, but it will probably not be included in toto into the site. --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. -- 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 [11] 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? --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. -- 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 Wikitravel'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...) - Todd VerBeek 18:16, 18 May 2006 (EDT)

I'd like..[edit]

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 = "" hours = "9 pm -5:30 pm" admission="Rs. 50 for entrance">Stuff about the event. </event>

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

My take on tags[edit]

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. 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. -- 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. --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. -- Tom Holland (xltel) 10:40, 23 September 2006 (EDT)

Non-latin alphabets[edit]

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 [12]. 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 = "" hours = "" price="880-1,900 RMB">Blah Blah Blah.</sleep>

it would come out as follows:

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

With the characters in bold and no way to italicise the pinyin (which is what Wikitravel: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. --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. 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. --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). --Trsqr 16:45, 16 September 2006 (EET)


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? 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? --Evan 15:36, 2 November 2006 (EST)
Yep! Sounds good! 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. -- 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. --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. --Paul. 11:27, 12 December 2006 (EST)

What's left?[edit]

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? --Evan 16:19, 2 November 2006 (EST)

Please don't forget the alt tag proposed above. Jpatokal 23:03, 2 November 2006 (EST)
It's done! --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. Jpatokal 03:24, 3 November 2006 (EST)
Test entry (해수피아 Korean 赤あかアカ Japanese 中华人民共和国 Chinese). Sniff sniff.  edit
If that's the case, can you do some work on Wikitravel:Foreign words to make that clear? As far as I can tell, they should be in italics. --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). 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. --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. --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. --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? -- Andrew H. (Sapphire) 01:53, 3 November 2006 (EST)

We don't usually do structured airport listings, though. Could you maybe start Wikitravel:Airport listings or bring it up in the Pub? I'd rather have the listings format follow the MoS rather than lead it. --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. 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. -- Colin 11:34, 3 November 2006 (EST)
That's my feeling too. The best place to ask this kind of question is on shared:Technical requests. --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. 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. -- Ryan 17:05, 3 November 2006 (EST)

Tags Needed[edit]

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

-- 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. --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. -- 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.
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. -- 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. --Evan 14:54, 4 December 2006 (EST)
Please also consider "textphone", as used by people with speech or hearing disabilities. Thank you. Andy Mabbett 09:55, 5 December 2006 (EST)
"textphone" is the kind of exceptional situation which would fit nicely in the "phoneextra" section. --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. 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. --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! -- Colin 20:52, 6 December 2006 (EST)

Bot Inserted Listings[edit]

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? -- 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 Wikitravel:Listings, but it's kind of a pain to do so. -- Ryan 00:56, 17 November 2006 (EST)
Writing a bot to add the missing tags would be kinda trivial :-) -- 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. --Evan 09:02, 17 November 2006 (EST)


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

Name property[edit]

The property "name" is described thus:

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

Note that it's required for hCards. 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. --Evan 17:10, 25 November 2006 (EST)
Better to not parse them, than publish invalid hCards. Andy Mabbett 16:45, 26 November 2006 (EST)

Telephone number format[edit]

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. Andy Mabbett 18:21, 25 November 2006 (EST)

I think that's the format we use; see Wikitravel:Phone numbers. --Evan 14:57, 4 December 2006 (EST)
I'm sure I've seen parentheses in numbers, but can't recall where. Sorry. Andy Mabbett 10:50, 5 December 2006 (EST)

More on addresses and hcard microformats[edit]

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 [13] (e.g. SP035928) would be useful as an optional attribute. 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. --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. 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. -- Mark 19:15, 7 December 2006 (EST)

Emboldening issue[edit]

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

The attributes hold plain text, not wiki text. Styled stuff like that won't work. --Evan 15:00, 4 December 2006 (EST)
I'd suggest that that's documented on the main listings page, then. Andy Mabbett 10:50, 5 December 2006 (EST)

Lat and long decimal places[edit]

User: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. --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.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. --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? 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. --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". 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? -- 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. Andy Mabbett 09:22, 2 January 2007 (EST)

slight fix needed on accomodation listings[edit]

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... Cacahuate 00:52, 6 January 2007 (EST)

*BUMP* -- Ryan 13:42, 15 January 2007 (EST)
This is fixed now. I also fixed a problem with italicizing the "directions" field. --Evan 13:01, 22 January 2007 (EST)

multiple attributes of one kind per item[edit]

Is there any recommendation on having two emails for a single hotel? Using email="[email protected]; [email protected]" 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. --DenisYurkin 18:27, 6 January 2007 (EST)

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

prices appear beyond bullet in multi-paragraph listings[edit]

For sleep tag, prices sometimes drop away from the bulleted block, appearing with no indent. I created a sandbox page demonstrating that: User:DenisYurkin/Sleep sandbox (note the last line on that page). --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. -- 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? --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. --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. --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 <br>'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#Seecacahuate talk 01:48, 9 August 2007 (EDT)

HTML in listings?[edit]

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="[email protected]"
 fax="" checkin="" checkout="" price="" url=""><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

Which shows up as

  • Senator Ház, Dobó tér 11., +36(36)320-466 (tel/fax) (), [5]. 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.

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. Maj 23:04, 20 January 2007 (EST)

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 <span> 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 Wikitravel for details of specific places I recommend (thus developing content at Wikitravel). Is there a better way to attach an anchor to a specific hotel or restaurant?
Second and third are <br> and <u>. 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. --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. 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... Wikitravel:Internal_links is pretty sparse at the moment... ::: 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 <br clear="all"> 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. 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 <U> and <BR> tags. However I have something to say on the rest of above comments.

  • I used <span> 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 Wikitravel--thus driving more readers to Wikitravel, and possibly converting some of them to contributors of Wikitravel--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 Wikitravel is not totally isolated from other Internet tools like blogs, but rather exist in a context; understanding how Wikitravel 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. 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. Jpatokal, any suggestions on how this idea can be expressed in this listing item for Senator Haz?
  • Maj, does it look good overall now?

--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. --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? --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? --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. 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? --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! 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? --DenisYurkin 00:55, 22 January 2007 (EST)

prefix for hotels, restaurants etc[edit]

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? --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". 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. --DenisYurkin 07:35, 10 February 2007 (EST)

bug in hCard microformat[edit]

I have just noticed that the (templated) hCards on Birmingham (England) are marked up with <SPAN class="addr">. This should be <SPAN class="adr"> (with just a singular "d"). Andy Mabbett 07:14, 7 March 2007 (EST)

Got it. That's fixed, now. --Evan 14:18, 22 March 2007 (EDT)
Indeed it is. Thank you. Andy Mabbett 08:25, 26 March 2007 (EDT)

Form-based editing of listings[edit]

shared:Tech:Form-based editing of listings

<drink> tags[edit]

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 Wikitravel: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? --Dawnview 06:33, 26 September 2006 (EDT)

Yes, it's a known bug, see shared:Tech:Url field of listings should be autonumber or word. --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). Jordanmills 10:51, 26 September 2006 (EDT)
Good point. My thinking (from somone who never prints out the Wikitravel pages) is that if you can get to an internet cafe to visit some website, you can just as easily get to Wikitravel 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. --Dawnview 14:41, 26 September 2006 (EDT)
The problem with assuming that people can follow the links from Wikitravel 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. --Paul. 13:18, 1 October 2006 (EDT)

MediaWiki Templates[edit]

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. Jordanmills 14:11, 30 December 2006 (EST)

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

Translated item name[edit]

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? --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. --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:

Test (Test テスト 実験 ижица 조선말).  edit

As you can see, only the Latin word is italicized. 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? – 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. JimDeLaHunt 13:48, 12 June 2007 (EDT)
I've added the alt and directions tags to the edit tools. Jpatokal 23:30, 13 June 2007 (EDT)
I'm loving the directions tag. Gorilla Jones 23:52, 13 June 2007 (EDT)

{{no source}} and {{no license}}[edit]

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 Wikitravel? OoishiMoe 02:07, 4 June 2007 (EDT)

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

web/email format[edit]

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. – cacahuate talk 00:00, 12 July 2007 (EDT)

copied in from the pub:

I'd like that, too. The escalating number-links are odd. 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. --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. --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? Texugo 02:47, 12 July 2007 (EDT)
Absolutely nothing, I think that could work great. Should we move our discussion to Wikitravel_talk:Listings#web/email_format? --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? – 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. 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. --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. -- Sapphire(Talk) • 16:11, 17 July 2007 (EDT)
Arrrrrrgh! 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. – 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> 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 – 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. --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. 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. --Evan 12:59, 18 July 2007 (EDT)
Had a feeling people wouldn't like that idea! What about @ and [14] (without the [12])? Or what if Todd/Ryan/Nick/someone made up some beautiful options for icons? – 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? -- 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, 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, 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. – 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. 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. 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. --Evan 12:54, 18 July 2007 (EDT)

While I might be new to wikitravel, 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.

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. -- Sapphire(Talk) • 12:38, 2 August 2007 (EDT)

Names don't appear[edit]

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="" 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="">[3]</a>. <span class="price">$39.95 day pass</span>. </span></li></ul>

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 reportcacahuate talk 23:12, 23 August 2007 (EDT)

Translation section[edit]

The listings tags do not work when translated into Russian (see 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. --Peter Talk 16:58, 5 September 2007 (EDT)

still experimental?[edit]

Aren't we ready yet to remove the "still experimental" banner from this article? --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. – 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. KevinSours 16:59, 2 November 2007 (EDT)
Looking good! Three things jump out at me at first glance:
  1. Lack of a "description" box
  2. It's not possible to edit listings on an "out of date" page that have since been deleted
  3. 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? --Peter Talk 18:41, 2 November 2007 (EDT)
shared:Tech:Form-based editing of listings – let's continue there so all language versions can participate... I'm glad we're moving forward on this! – 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? --Peter Talk 16:12, 11 April 2008 (EDT)

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

section anchor is overridden by listing anchor[edit]

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

Listings' telephone icon[edit]

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? --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. -- Sapphire(Talk) • 18:35, 16 April 2008 (EDT)

Formatting question[edit]

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! --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 = "" 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>

  • Bluebird Cafe, 4104 Hillsboro Pike, 615-383-1461, [6]. 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.  edit

Or formatted using general wikitravel formatting, like this:

* '''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.

  • Belle Meade Plantation, 5025 Harding Road, +1 615 356 0501 (group sales: 1-800-270-3991), [15]. 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 Wikitravel:Listings for details. Jpatokal 12:14, 24 August 2008 (EDT)
Even despite "This feature is still experimental..."? --Matt Talk 14:21, 24 August 2008 (EDT)
We should remove that disclaimer—it's no longer experimental; it's standard. --Peter Talk 15:48, 24 August 2008 (EDT)
Got it. Thanks guys. I removed the disclaimer from Wikitravel:Listings--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. LtPowers 19:19, 24 August 2008 (EDT)
I agree with LtPowers, not long ago i reported on shared about this impossibilities. -- Sergey kudryavtsev 02:17, 25 August 2008 (EDT)

Listings using "Do" and "See" tags etc[edit]

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:

  • Solstice Restaurant and Lounge, 2801 California St (at Divisadero St), +1 415 359-1222 (fax: +1 415 359-1242), [7]. 5PM-midnight daily. 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! $8-$17.  edit

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. --Peter Talk 23:53, 31 August 2008 (EDT)

Wikilinks in listings?[edit]

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. --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? 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. LtPowers 10:29, 8 December 2008 (EST)

Implementation on other wikis[edit]

I am interested in implementing almost exactly the same thing on a gardening wiki ( ) 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! Raffikojian 13:04, 24 November 2008 (EST)

Kevin might be able to help you find this information. --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. --Peter Talk 21:31, 13 May 2009 (EDT)
Thanks a lot, I'll do that. Regards, Richard Fahey -- 07:40, 14 May 2009 (EDT)
Yes, thanks very much, I'll try that now as well. Raffikojian 09:05, 8 June 2009 (EDT)


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 Wikitravel 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. 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:
Seems like a useful feature to me that doesn't take up that much room. -- LtPowers 20:08, 8 January 2009 (EST)
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 Wikitravel 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 LtPowers seems like a good way to do things to me. -- Huttite 03:02, 17 January 2009 (EST)
Just to be clear, it's not a suggestion; it's the way Wikitravel works right now if you use the "email" field for listings. 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 Wikitravel, I think they should at least do it right. Put mailto: in the Wikitravel search box to see how ugly it can get. 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". 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:[email protected]

This is obviously wrong: the email address in question is not mailto:[email protected], it is [email protected] What I mean by it's not in the template is that for instance the listing template for hotels (maybe template is the wrong Wikitravel jargon for this, but that's what it really is)has an email input area reading


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. 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 Wikitravel, 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? 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 Wikitravel search box, as I explained a dozen lines above that. 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. 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 – cacahuate talk 19:38, 19 January 2009 (EST)

"add listing" issue[edit]

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. 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. 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 <span id="listing_do_1">...</span> then we could put something together that would suppress them from appearing. Might be a good candidate for a tech request. -- Ryan • (talk) • 04:28, 12 January 2009 (EST)
It was mentioned briefly at shared:Tech:"add listing" link occurence improvements, I'm noting it again there now – cacahuate talk 10:11, 12 January 2009 (EST)

As of November 2015, I don't see any "add listing" link anywhere... how do we make them appear? Laurian (talk) 21:02, 1 November 2015 (EST)

Email addresses[edit]

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? --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. 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. --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.--Burmesedays 21:23, 2 February 2010 (EST)

Translate listings[edit]

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?

  • Drama Theatre (Драматический театр).  edit
  • Dramaticheskij Theatre (Драматический театр).  edit
  • Drama Theatre (Драматический театр, Dramaticheskij Theatre).  edit

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

  • City Museum (Museum of Local lore) Городской краеведческий музей города Комсомольск-на-Амуре, Gorodskoj kraevedcheskij muzej goroda Komsomol'sk-na-Amure). bla bla bla  edit

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

Streetnames in listings[edit]

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

  • City Museum (Museum of Local lore) Городской краеведческий музей города Комсомольск-на-Амуре, Gorodskoj kraevedcheskij muzej goroda Komsomol'sk-na-Amure), Komsomolskaya Prospekt (Комсомольский проспект) 7, Phone number is 3 lines down on my PC.  edit

Comments or pointers to previous discussions? --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. 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.
  • Tygyn Darkhan (Тыгын Дархан), ул. Аммосова, 9. 8AM-10AM, noon-3PM, 6PM-11PM daily. 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. ~1,000 rubles.  edit
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:
  • Tygyn Darkhan (Тыгын Дархан), ул. Аммосова, 9 (ulitsa Ammosova, 9). 8AM-10AM, noon-3PM, 6PM-11PM daily. 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. ~1,000 rubles.  edit
  • Attraction X, თავისუფლების მოედანი (Freedom Square) (tavisuplebis moedani), +X XXXXX-XX. 8AM-10AM, noon-3PM, 6PM-11PM daily. ~1,000 lari.  edit
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. --Peter Talk 23:40, 3 February 2010 (EST)

Lat/Long in listings[edit]

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? 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. LtPowers 16:40, 22 February 2010 (EST)
A third party user of our free data, may of course find a good use for them. --inas 16:59, 22 February 2010 (EST)
As far as I recall 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. --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 :) 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!--Burmesedays 08:30, 23 February 2010 (EST)

Flags at the beginning of embassy/consulate listings[edit]

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 [16] 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. – 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. 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. --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 Wikitravel 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). – Vidimian 08:39, 17 August 2010 (EDT)
The images would be loaded with the page even if hidden with CSS. 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. --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. --Stefan (sertmann) talk 23:35, 17 August 2010 (EDT)

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

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!! 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. LtPowers 22:08, 26 February 2011 (EST)
But they do seem to be done with MediaWiki templates-- those listed at the bottom of Wikitravel: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.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. LtPowers 20:17, 27 February 2011 (EST)
Ah, gotcha, but you understand my problem, right? Know how to make a substitution script? 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. =) LtPowers 16:18, 1 March 2011 (EST)

Multiple phone numbers[edit]

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? 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. 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? 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. -- 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. texugo 22:58, 27 February 2011 (EST)

Adding a listing for churches/religious services/places of worship[edit]

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. ElectroSpace 01:59, 17 April 2011 (EDT)

As I was one of the two people who removed many of these listings, User talk:ElectroSpace#Meeting House Listings has some of the reasoning. Wikitravel isn't currently anti-religion, and as Wikitravel: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 [17] 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. -- 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. 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 Wikitravel.
Incidentally, aside from User:Jonboy's question on the WYCSI talk page back in 2006 and User: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. Wikitravel 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 Wikitravel 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. 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. 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. 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. -- 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. 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? 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. -- 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. 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? 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 Wikitravel:External links#What not to link to). -- 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.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. -- 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 Wikitravel. 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 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 Wikitravel 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.• • • 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. 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 Wikitravel. Not so sure about supermarket chains though... • • • 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. 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. • • • 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? Ikan Kekek 14:42, 22 April 2011 (EDT)
This is Wikitravel, 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. • • • Peter (Southwood) Talk 08:45, 26 April 2011 (EDT)
Region or city is where I would come down. 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:

  1. Where is the closest X of my denomination?
  2. Where is the most famous X of my denomination?
  3. 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. --Peter Talk 19:53, 2 June 2011 (EDT)

I ran into this. Any comments? 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. --SaxonWarrior 07:47, 23 June 2011 (EDT)
Churches, barbershops, rental bikes, it is the same issue. Wikitravel 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. --inas 06:00, 8 November 2011 (EST)

Listings of individuals[edit]


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. 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. --Inas 23:59, 28 January 2012 (EST)
The issue has also turned up at Talk:Yangshuo#Tour_Guides. Pashley 10:10, 29 January 2012 (EST)

Random order in listings?[edit]

For about 7 years now, we have not had anyone suggest that listings should be in a random order rather than in alphabetical order as a default, or another logical order if agreed on the destination article's discussion page.

However, our Wikitravel:Accommodation listings#Listing order current policy has now been questioned so I thought I would bring a discussion from an IBadmin's page here to seek other views:

Sorry to trouble you again, but I was a bit puzzled by your reversion of this edit pair by an IP.

On the face of it, this was a good edit, putting the "Splurge" hotel listings into better alphabetical order - or have I missed something? --Ttcf (talk) 20:54, 8 April 2014 (EDT)

It's not about the alphabetical order, we don't allow users to arbitrarily move listings from the bottom to the top of the list.Ibrshao (talk)
That's an interesting new concept that we shouldn't allow users to put listings into default Abc order (or whatever other order has been agreed upon) but rather leave them in some weird (and presumably random order) for ever.
In the decade or so that I've been editing here, I've never really seen that concept (that listings should not be put into a logical order, with alphabetical order as the default until and unless a better order is agreed upon) proposed before. Where did you get that strange idea from, please? --Ttcf (talk) 20:48, 9 April 2014 (EDT)
I see no benefit to listings being in Abc order as most if not all pages rarely have enough listing to warrant a sort. To prevent edit wars and misunderstandings, I would prefer that all new edits are added to the bottom of the section irregardless of Abc seeing as how this is how they are added with the add listing feature anyways. Ibrshao (talk)
  1. More than 10,000 destination articles have sections with more than 2 listings. Rather than give IBadmins, Admins and long term editors like myself extra work in explaining changes by having a policy vacuum, I do think it necessary to have some policy. Since it is yourself who is proposing a change in a consensual policy that has been enunciated in writing for many years at Wikitravel:Accommodation listings#Listing order I've brought this discussion here from your user talk page so that the discussion may be seen by a wider audience...
  2. If it were not for the fact that it then makes it easier for touts to just keep clicking the "update" button to move their listing to the top, personally I would like the latest (and, hopefully, most up-to-date) listings to appear at the top of each section.
  3. The current system means that touts at least have to learn how to edit to move their listings up from the bottom and the abc default means it's easier to ask them not to try and unfairly advantage their listings.
  4. I really think that you need to make a very powerful argument indeed to change many thousands of articles - it's not a trivial task to go back through the edit histories and see which listings were added last and should, according to your new proposal, therefore be moved to the bottom of each section...
You may wish to also read Wikitravel_talk:Accommodation_listings#alphabetical_order before you respond. --Ttcf (talk) 23:09, 9 April 2014 (EDT)
This is a very interesting discussion where it’s hard to say what’s right and what’s wrong. The truth is that with the thousands of pages we have it’s almost impossible to see one that would have listings in alphabetical order. So, if we decide to go with the alphabetical rule none of the articles would actually follow it. And I don’t want to see users deleting all the new listings that people put just because they are not in the abc order as the rule says (and in our community there are users like that). Another very strong argument not to go with the alphabetical order is the fact that our Add listing box is designed to put new listings under each other. I have the feeling that users use more often “Add listing” option than just Edit because it’s easier to comprehend. With new listings added to the bottom, we will keep things simple. Therefore, I'm leaning towards adding new listings to the bottom of the section. What does the others think? Warm regards, IBAlex (talk) 20:51, 10 April 2014 (EDT)
If the "Add listing" option adds the listing to the bottom I would also agree to leave it like that, just add the listings at the bottom. Listings should not be deleted/reverted if the order is "incorrect" (except if someone just moves his/her listing to the top), what matters is that we have valuable information in the articles and that editors spend their time on adding valuable information, not having to worry about putting long lists in alpha order. Adzas (talk) 07:01, 11 April 2014 (EDT)

Of course if there were an artificial forced choice between adding information about what to see or where to sleep and correcting spelling mistakes or punctuation then it is clear that we should sacrifice copyediting for content.

However, this is an artificially forced dichotomy. Many IP editors will just edit once or a couple of times to add their favourite restaurant or warn that a bridge has been flooded out or a nightclub is operated by the local gangsters - and we should do everything to encourage and make it easy for these kind of edits - that's one of the principal benefits of the Wiki way.

However, some long term editors (I've been copyediting here for more than 10 years now) not only like to add content but also try to make sure that our project looks good and consistently follows our Manual of Style.
Our MOS policies also benefit the traveller directly by making our text less ambiguous, easier to understand, more concise (less pages to print and carry) and, last but not least, more authoritative.

Our project relies on Internet Brands being able to bring in the advertising dollars to keep the servers humming and pay the wages and expenses of IBadmins such as you three.
If advertisers see pages that are badly formatted, randomly organised, with childish looking spelling and grammar mistakes, then they worry (at least sub-consciously) that this is a less than optimally authoritative travel guide and may be less reluctant to advertise here.

Now what has abc order got to do with any of this?, you may ask. The obvious answer is very little. For most readers, they won't care at all if the lodgings are listed in alphabetical order or in what will seem to them as no logical order at all. As you say, for most destination articles, we will have only a handful of listings and there may actually be an argument for listing the most up-to-date listings first since those listings are less likely to have closed or have out of date prices and/or descriptions.

However, I would like our readers to remain blissfully ignorant of the daily and constant battle behind the scenes that we fight to combat selfish marketeers and touting.

It's a relatively trivial programming task for IB technical personnel to modify our listing routine so that it adds new or updated listings in alphabetical order within the subsection. This non-random order then makes it much easier to spot duplicate listings both within sub-sections and those that have been added to many different sub-sections.

While they're at it, and or the sake of consistency and to avoid all those confusing, incrementing little footnote-style numbers appearing all over the place, IB technical personnel should also update the way that URLs appear in listings so as not to give a perverse incentive not to use our listings format. It's long overdue for them to change our code so that Example appears as the standard hypertext-style of external link seen all over the world wide web so that it is very easy for our readers on the Web to spot when they will be taken away from this great site to another website because the upward and right pointing arrow symbol like this is very visible. This "good" style also will not interrupt listings with meaningless, footnote style numbers and nor does it occupy valuable screen space or confuse screen readers for the visually impaired with huge, ugly, unpacked URLs. Note that offline readers will also not be distracted with references to links that they cannot access.

Although even if it were true it would be a poor argument (many people confuse ie and eg, but that's not an argument to give up copyediting), it’s just plain wrong to write that "'s almost impossible to see one that would have listings in alphabetical order. So, if we decide to go with the alphabetical rule none of the articles would actually follow it."
Firstly, we already decided to follow a non-random order and not use "latest update/addition comes last order". We already decided long ago that alphabetical order should always be the default order (unless a better order is agreed for individual articles) many years ago in practice and more than 5 years ago as explicit policy. That means that our consensual way of changing policy means that you need to advance powerful arguments for changing the status quo and also counter all my arguments for keeping it.
Secondly, far from being "almost impossible to see" an article "that would have listings in alphabetical order", ALL of our Star articles followed this existing policy at the time they were awarded Star status and many of them that have not been degraded in the last couple of years still do.

(in no particular order). --Ttcf (talk) 04:16, 23 April 2014 (EDT)

Usefulness of sleep/eat/drink listings[edit]

I tried to look around to find if this topic was already covered, didn't find it but don't get mad in case it has been discussed before. But, back in the day I found Wikitravel listings quite useful. I do not anymore. As you know there are services that focus solely on such things (such as Tripadvisor) that I now look into when in need for such information. For a few years I've been skipping the eat/drink/sleep sections at Wikitravel and now thought I should ask why they're still there? In my opinion Wikitravel should keep those sections - not as listings of random places a certain individual has liked, but to spread information about that topic in general (like, nightlife areas instead of listings of single bars randomly spread around). I recently moved to a new country and would have loved to have information about areas, not certain establishments. vesse (talk) 13:12, 7 May 2014 (EDT)

Hi Vesse, thanks for sharing your opinion! I honestly still find them useful; I used Wikitravel during my trip across USA and I stopped in many restaurants based on the listings I saw in articles. I was happy with the choices.
Please know that you can include information about nightlife and "food scene" in the articles. You can mention any general types of restaurant that travellers should look for, areas with especially good nightlife, or interesting musical traditions, information on the type of accommodations (pensions, guest houses, hostels, motels, etc.) travellers will encounter, as well as rough price ranges. And I agree that in this way we will make our articles more useful. Would be great to see your edits about the new country you moved to:) Warm regards, IBAlex (talk) 13:30, 7 May 2014 (EDT)