From Wikitravel

Contents 1 Templates for listings 2 Listings tags 3 Pictures in listings implemented on Japanese Wikitravel 4 List or not list? 5 Additional attributes and tags 6 Tag name redundancy 7 Automated conversion script 8 Where are we on this? 9 Possible bug 10 Feature or bug? 11 For those of us who are visual learners 12 I'd like.. 13 My take on tags 14 Non-latin alphabets

Templates for listings

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 http://www.semapedia.org/ .

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

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

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

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

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

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

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

I'd like to start talking about this and maybe work up some sample templates that render, more or less, to our current formatting. Comments? Questions? Ideas? --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 [1] which is included into other templates [2] 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 wikitravel.org by 1PM EDT tomorrow. We can experiment a bit to make sure they look right (I could probably use some CSS2 help on them...) and then start doing a run-ahead on Singapore and its districts. --Evan 13:51, 4 April 2006 (EDT)

Listings tags

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

• name
• address
• directions
• phone
• email
• fax
• url
• hours
• price

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

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

This becomes:

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

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="http://www.sijoriresort.com.sg" price="S$120-">Blah blah</sleep>
→ Sijori Resort, http://www.sijoriresort.com.sg. Blah blah S$120-.

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.

Test! First Second

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, http://www.sijoriresort.com.sg. Blah blah S$120-.

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

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?

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)

Additional attributes and tags

So the following attributes would come in handy:

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

Also, a "contact" tag for netcafes etc would be handy. 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

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

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?

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)

Possible bug

The following seems not to format well:

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

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

• Here's a bunch of attractions I want to list under some common idea:
  • some attraction. Some details

• • some other attraction. Some other details

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)

Feature or bug?

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

Renders as:

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

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)

For those of us who are visual learners

Swept in from the Pub:

Has anyone discussed the possiblity of creating some standard icons for various systematic information, such as hours of operation, admission charge, telephone number, guided tours available, photography not allowed, handicap access, restaurant or cafe at the location, etc? Perhaps a small section behind each location description that would include the icons and the related information? I can provide a Photoshopped proof-of-concept if anyone is interested. - 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 [3] 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..

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

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

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

My take on tags

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

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 [4]. Blah Blah Blah. 880-1,900 RMB

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

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

it would come out as follows:

• Shangri-la (香格里拉大饭店 ''xiānggélǐlā dàfàndiàn''), 66 Renmin Lu, ☎ +86 411 8252 5000, http://www.shangri-la.com/dalian. Blah Blah Blah. 880-1,900 RMB.

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)