What about smoking, accessibility, sound level, veggie friendly, alcohol? (3 of these are important to me, and all may be important to someone or other)
Also, is $ for entree only, complete meal, with or without drinks? —The preceding unsigned comment was added by Notty (talk • contribs)
I think that stuff would fit well in the "description" area of restaurant listings.
As for price: it should probably be for a complete meal, but there's a little comment area for the price, so you can put in (plus wine) or whatever. --Evan 12:54, 7 Feb 2004 (EST)
I would like to suggest we specify that the price range be for a dinner entree (places that only do breakfast and/or lunch would be for those). Not making it standard leaves quite a bit of variance. Obviously some restaurants wont fit this approach but that can be explained in the comment area when necessary. From what I have looked at that usually seems to be what was done, but not always, so it makes it very difficult to use the price list as any sort of guide. -- Webgeer 17:28, Sep 15, 2004 (EDT)
I'd like to BUMP discussion on price ranges. Presently price ranges are very unhelpful if not misleading: every contributor has his own understanding of "typical meal", and when I visit a place and discover the prices are somewhat different (from Wikitravel article), it's not 100% clear how to fix it in the article.
I haven't seen really good definitions of "price range" at Wikitravel so far. Do we have some best practice in that? The best I've seen is "Main courses are generally around X to Y" (which allows only few exceptions like lobsters or other unregularly expensive delicacies). Maybe we should start with this?
Same question applies to Template:Eatpricerange: it's nearly impossible to cluster restaurants basing on different meaning of price range. --DenisYurkin 17:21, 20 October 2007 (EDT)
I agree that clarification on this point would be useful, right now the intent behind given price ranges are sometimes so vague as to be useless. But wouldn't using main course price ranges be unhelpful for countries where meals are not based around the main course? This would not be a good way to indicate the price of a night of Spanish tapas or a Japanese tora fugu restaurant. Nor would it be a good way to indicate the price of this dumpling restaurant in Pittsburgh. For a clear policy to work, I think it would need to be pretty finely grained, detailing how to indicate price ranges for many different types of "eating" institutions, and may even need to be country-specific. --PeterTalk 22:05, 20 October 2007 (EDT)
As for Dumplinz Cafe, I assume that standard serving size is "Like me", right? Then it's $4.29 to $7.19 for what they call main dish. It can be the same as pasta cafes / pizzerias which don't serve standard meat-or fish-centric meals. The problem may be that it's bit difficult to have a single measure for both a steak house and a pasta place, which can be both in the same city, district and even cuisine category and budget.
I agree that reference type of dish should vary from country to country, and even allow several classifications within a single country: in Spain, for example, it's impossible in most cases to compare full-meal restaurant with a tapas bar: former doesn't serve tapas, latter doesn't serve full meals; prices are too different to appear on the same scale. From what I just read about tora fugu restaurants, they should also have its own ranges.
What I understand now is:
eatpricerange template should allow parameter "what exactly is called a typical meal"
we should use the same small set of category-typical meal throughout every country
What I don't understand is:
how to make sure the same set of typical meals is used throughout country (should I edit all articles within Spain to make sure same set is used? Should we have Spain-specific guidelines for Eat? then how we make sure editors of every article belonging to Spain are aware of it?)
how to combine different categories within a single section (steaks vs pastas) if we still recommend high-level grouping by price range, and allow food categories only under specific price range:
* budget pasta restaurants
* budget steak houses
* mid-range pasta restaurants
* mid-range steak houses
Other opinions, please? --DenisYurkin 18:37, 9 November 2007 (EST)
I don't think that we should have separate budget ranges for different types of restaurants—if $3-5 is the budget category, then no steak restaurants should be considered budget options. Speaking as a very cheap traveler, I don't want to have to sift through $9 steakhouse dinners when looking for budget eats, they should remain in the mid-range category. I think what is important is defining what the price range means. So if a Tapas restaurant displays "$12-15," does that mean it serves each "tapa" for $12-15, or does it mean that the "average visitor" spends that much on the main part of the meal (i.e., not including drinks, dessert, or appetizers). Could we maybe simplify the criteria for price classification by asking contributors to give a range of the average meal, not including drinks, appetizers, and desserts? Would that make sense? We could also define things more specifically for certain kinds of restaurants that don't fit this pattern well, like set Fugu restaurants and Tapas restarants (e.g., define the number of tapas that Wikitravel considers to make up an "average" meal), but I think we should do that on this page—the list of exceptions shouldn't be too long.
I realize that still doesn't fix the problem of subjectivity—I personally tend to eat a lot more than most people—but at least it would clarify what the price ranges are intended to display. --PeterTalk 19:27, 9 November 2007 (EST)
Agree with idea to have a single price range for all types of restaurants.
Like your idea of excluding "optional" meals out of "average spending" (drinks, appetizers, desserts).
Should we therefore focus only on main course in European cuisines (thus not including salad nor soup?)
Still, how we deal with italian restaurants with "cheap pasta vs expensive steak" widest ranges available in many restaurants? --DenisYurkin 19:54, 9 November 2007 (EST)
I see a lot of Chicago pizza restaurants like that—that have $6 pasta dishes and $25 pizzas. I usually just put in the huge range, $6-25 and then try to work out where it belongs by price category. For the pizza restaurant example, I would usually put it in the mid-range, since most people will want a more expensive pizza, but usually one person will not eat the entire pizza himself. For the pasta/steak restaurant, I would categorize the restaurant based on a number somewhere in the middle of the range, tending towards the most common options. So if there is just one steak dish that costs $50, but the rest are pasta dishes at $6, choose the lower price category.
I think it is best to just use the main course in European cuisines, unless there is some sort of Table d'hôte with a fixed price that everyone will pay, because it is usually possible to eat only the main course. But I don't know for sure, I don't have much experience in continental Europe. --PeterTalk 21:40, 9 November 2007 (EST)
So we are back to where we started: "Main courses are generally around X to Y" :-)
On a serious note, I see two aspects of price ranges:
First is how to define price ranges for Budget-Midrange-Splurge, and which range to put specific restaurant into.
Second is how to describe prices for a specific restaurant--and to give just enough information.
Speaking of Europe:
For first I find "average main course" is an easiest measurement.
I was wondering if an appetizer is part of a typical meal? Seems like it's a toss up for most people, but I'm not sure and depending on whether or not an appetizer is part of a typical meal, I would need to alter several templates. -- Sapphire • (Talk) • 06:00, 2 January 2008 (EST)
As for your question, my opinion that typical European ordinary-day dinner includes a salad, a soup and a main course. But whether to use full dinner as a measure here, or a single meal like main course is what we are discussing here, and haven't came to any conclusion yet. --DenisYurkin 10:43, 18 January 2008 (EST)
Perhaps I've misunderstood the discussion above but is there a move to drop the "budget, midrange, splurge" classification of restaurants? Or is the discussion limited to the 'price' field in a restaurant listing?--Wandering 10:51, 18 January 2008 (EST)
The discussion aims to define both:
what exactly we call typical meal when we define priceranges for splitting listings into budget/midrange/splurge
what exactly we mean in 'price' field in an individual restaurant listing. --DenisYurkin 11:05, 18 January 2008 (EST)
Travel and food are in my top five favorite subjects. As I contibute to listings I have been adding Budget-Moderate-Splurge to the eat sections usually. I break them down by price in that area. Comparing Chicago prices to Cleveland prices has many draw backs, I as a contibutor have no idea what Chicago prices are. Currently I am working on some cities in Ontario, Canada, in preparation for a summer visit. I have no idea of prices, or really quality. So, I am adding information for my own adventure. After the trip, I will amend the article and add more information. If changes like dropping Budget-Moderate-Splurge, from the listings is being considered, where are these considerations taking place. Do the administrators have their own conversations going on, that I do not have access to, or am I missing something as usual? 2old 11:46, 18 January 2008 (EST)
What exactly do we call a typical meal in terms of price? A main serving for one person. I'm largely in agreement with DenisYurkin. As Peter points out, different cuisines don't always have a corresponding item to a main serving. This is okay, because our policies and our format allow flexibility when things don't fit. At Zachary'e Chicago Pizza in Oakland (why go to Chicago if you don't have to :-), a pizza for two costs $10 per person. At Destinos in Swallow St (if you need your mexican fix while in London) a mexican platter costs £14 for one. Never include dips, starters, breads, wine etc. But feel free to mention these as additional costs if you want. Always give the menu price, and put details about tips, service charges, in summary form. What if the menu prices vary? An average price is preferred over a range. If the menu prices are so diverse that an average isn't representative, then give a range that is representative, even if that means omitting the single Lobster/Caviar dish.
In summary, the guideline should be the average price of a main for one person, or the closest equivalent in the appropriate cuisine.
How do we determine the price ranges? By destination article. Price ranges apply the same to all restaurant types, so if steak is pricey relative to pasta, the steak restaurants go in splurge. We always want to end up with a mix of places across each article. If we do it per country we will end up with some towns with everything in budget, and others with everything in Splurge. No point in having categories if we do that.
In summary, the guideline should be to set the price ranges per article, to get a balance of eating suggestions in the different categories. Restaurants are classified into price ranges, regardless of the cuisine or food they serve.
The policy at Wikitravel:External_links says that links should be hidden, not written out explicitly. It seems to me this restaurant style guide needs to be changed to relect that. -- Beland 22:28, 14 Aug 2004 (EDT)
What about cities which have mandatory 10-digit dialing? Should we still leave out the area code? In this case, I feel like it should be left in. -nick 11:32, 18 Aug 2004 (EDT)
In areas where 10-digit dialing is mandatory, it's not a valid phone number unless there are 10 digits. So the area code is mandatory. Moreover, I think that the area code should be included even in areas where 7-digit dialing is OK. Many of the people who are going to be using these listings are, guess what, travellers, and thus may be trying to call from out of town or from a cell phone that's in a different area code. It can be put in () to indicate that the area code is optional. Also, larger cities tend to have many area codes with no particular "central" area code. -- Beland 18:34, 18 Aug 2004 (EDT)
This has been discussed frequently, and I think the idea is that it's best to list the area code or dialing code in one place ("Contact" section is usually the best) instead of putting it into each and every listing. People in different places will need to dial different prefixes (area code, maybe country code, maybe some other prefix to get to a country code), so there's no one good "complete" number. Just having the number you have to call locally is probably still the best idea. --Evan 17:10, 19 Aug 2004 (EDT)
What order should lists be in? Is there a policy for this? This question actually applies to the
attraction, bar, and accomodation listings too. Can't see a recommendation anywhere. Maybe lists should be roughly ordered by importance of the restaurant. e.g. the Restuarant which you think most travellers will find interesting should go at the top of the list. In that case the order will end up becoming slightly ad-hoc, once several contributors add to the list... or maybe they're supposed to be alphabetically ordered. Is this specified somewhere? -- Nojer2 18:47, 8 Dec 2004 (EST)
...and following that rough guidline, I always try to put them in order by price. -- Mark 03:31, 17 Apr 2005 (EDT)
As discussed elsewhere, we usually sort listings alphabetically within a single section. I updated the article with this. --DenisYurkin 16:10, 20 October 2007 (EDT)
How to write multiple branches of restaurants?
Swept in from Pub
I was wondering if there is a suggested way of writing restaurant entries where there are several branches of the restaurant. If the "Eat" section already has separate neighborhood headings, then that's easy, but if there's just a single "Eat" section...
I suppose that I could just start neighborhood headings, but not all cities really merit such an expanded list. -- Mikito 16:50, 25 Jan 2005 (EST)
I usually enter them this way:
Chain Restaurant. 66 Original St. (branches in Copy Blvd, Clone Lane). Blah blah.
But if it's an utterly ubiquitous local fast-food chain or something it should be mentioned in the country/region page's Eat section. Jpatokal 21:22, 25 Jan 2005 (EST)
This format is a quick way to convey any differences in addresses, hours, and contact details, while limiting the common terms to one listing. --PeterTalk 15:59, 10 November 2007 (EST)
Thanks, I've added it to the article. --DenisYurkin 17:19, 10 November 2007 (EST)
Just clarified to not copy main review into districts, but refer to the main article instead.
Another thing that we still need is example of multi-district listings. Does anyone have a good example? --DenisYurkin 03:35, 15 December 2007 (EST)
I'm not sure I agree that the main restaurant review should be in the main city article. I think the main city article in a "districtified" guide should only cover general information about the dining scene. All restaurant-specific listings and info should be in the district pages. I think it's ok to use the same description for a specific chain across more than one district article—that helps readers, who will therefore not need to flip back and forth between articles to understand what they are looking at. I certainly used the "The great South Side fried chicken chain is cheap, usually a little dirty, and always delicious. Crowded at meal times" description for Harold's Chicken Shack across most of the south side Chicago district articles. --PeterTalk 03:56, 15 December 2007 (EST)
Oops, that's an important thing--I think we definitely need to find a consensus here.
Consider London#Chains. Currently it holds a full review for Wagamama, while district articles contain only specifics on individual locations: 1, 2, 3, 4, 5.
I agree that it would be more useful for traveller to find a review just in place, but:
it's really difficult to maintain consistency between multiple texts appearing on different pages
it's difficult to distinguish between individual-location edits and global-review ones.
Maybe we should create a city-wide/country-wide template for a global part of chain review texts, and complement it by a location-specific texts for individual locations?
Since this has come up again, I suppose we should try and come up with a firm consensus. I do lean towards Sailsetter's point of view, because the presence of listings in the overview article is misleading to readers (who might not realize that all other listings are actually in the district articles) and to contributors (who might think it is OK to put listings in the overview article). So, just to decrease possibilities for confusion, I think it would be best to have no restaurant listings in the main article.
Linked references are fine, especially to call attention to especially famous chains where you can eat local delicacies (which are described in the overview section), but they should not be in listing format. Perhaps most importantly, each listing in the districts should be able to stand on its own (without reference to the overview article), so that someone who only prints out the district will have all the necessary information on hand about whatever is listed in that district.
I'm less concerned about maintaining consistency between the mini-reviews on the various district pages. Chains sometimes do vary in terms of quality & price by location, so differing reviews might actually be helpful. While on the other hand, I don't see differing descriptions being harmful. Similarly, I don't think it's too much of a concern if a reader takes a "global-review" as being proper to a specific location—provided the global review is an accurate description of the chain, it should be accurate for the individual location. And if it is not, the reader can see this and change the individual location description without losing anything important.
Lastly, I'm tempted to avoid creating a template for this, since that would complicate the formatting (especially within listings) and increase the difficulty for newer contributors to correct information. --PeterTalk 12:20, 27 March 2008 (EDT)
I don't like the idea of having individual location reviews to be written completely independent. Unfortunately, I don't have anything new to propose to what's said above at the moment. However, I don't find "misleading for newcomers" as sufficient for not listing chains on city pages--they can be clearly indicated, I can give an example of how if you want. As for "locations may vary in quality"--yes, but in many cases they don't, at least in Moscow.
One of the greatest reasons why I don't like is that for large chains (10+ locations), it is much more valuable for a traveler to have a single review to read [and remember]--and it's essential to find an easy way for contributors to write and edit a single review, not many of them spread into many articles
Sorry that I'm not too constructive at the moment. --DenisYurkin 12:59, 27 March 2008 (EDT)
Again, I'm stuck thinking how can we make progress on this discussion. Can we do anything beyond just waiting for someone else join us in talking on this? --DenisYurkin 14:41, 26 October 2008 (EDT)
In some articles there are already exhaustive lists of restaurants categorized under the style of cuisine (example: Bangalore). As it is unlikely that any one person will have the knowledge to reorganize such listings under the standard sub-headings of 'Budget', 'Mid-range', 'Spurge', I propose that astericks be used to represent the price ranges (i.e. *=Budget, **=Mid-range, ***=Splurge, again see Bangalore) as a means to solve these kinds of situations. Using this method will allow a number of individuals to add the prices over a period of time while, at the same time, the listings will still conform to the Wikitravel categorizations of Budget, Mid-range and Splurge. Comments? Other ideas to solve the problem? - SZ
I much prefer to use the prices themselves. --Evan 17:24, 1 Sep 2005 (EDT)
OK, I'll suggest that for Bangalore and other places that have lists categorized by style of cuisine. - SZ
If you want to eat at a foreign country, the first thing you discussed with your family or your friends is the TYPE of the restaurant, not the price. People prepare/save large amount of money for overseas vacation. My suggestion:
1. The classification of restaurant should be based on the style/taste: American (hamburger, hot dog etc), Latin American (Mexican, Argentinian etc), European (Italian, Spanish etc), Asian (Chinese, Indian, Japanese, Korean, Vietnamese, Middle Eastern etc), African, and local dishes.
2. For price classification: at the end of each entry, there is an information: "Price: budget" or "Price: moderate" or "Price: splurge".
I agree with template, but other templates are missing now. Perhaps someday it will be possible to create automatic input for certain industries: Template:Eat for restaurant listings, Template:Drink for bars and clubs, Template:Sleep for hotels and Template:See and Template:Do.
Uh... please look at the Wikitravel talk:Listings page. You can do this now with <see>, <do>, <eat>, <sleep>, ... tags. --Evan 16:49, 8 September 2006 (EDT)
In certain cities, searching for information about the menu, price of the food can be dangerous to your health. If you try the food, it maybe contaminated with dirty water/bacteria/stale ingredients/illegal preservatives (formaldhyde)/illegal food coloring agents (rhodamin, metanil etc) and you will be poisoned/get diarrhea/gastroentritis and forced to stay in bed for several days. If you asked about the menu and the price, the owner will be angry because he suspected that you are a spy from the competitors. The best way is to bribe the waiter for a xerox copy of the menu and price list. —The preceding unsigned comment was added by 126.96.36.199 (talk • contribs)
I do not dispute the veridicity of this claim, but what can we do about that? Note also that it would be quite a difficult statement to insert into some article, I do not see a reasonable way of warning the reader without violating NPOV. Johann.gambolputty 04:43, 18 September 2006 (EDT)
This is not a warning for reader, but a suggestion for people who want to write a review/collecting data. Related question: how do they collect data from hundreds of bars without getting liver disease/drunk (from beers/wine)/diarrhea (from fruit juices)? —The preceding unsigned comment was added by 188.8.131.52 (talk • contribs)
Recall that we do not in fact aim for a neutral point of view here. We do actually do mini-reviews. If the food is bad, the noise is overwhelming, or the staff are rude, say so. If the local Chamber of Commerce or the owner doesn't like that representation, it may stand anyway, and doesn't need disclaimers about "however some critics find that..." encyclopedia style. NPOV is a redirect to our different policy: Be fair. Hypatia 20:29, 9 October 2006 (EDT)
I'd like to chime in here and add to the reminder that Wikitravel most definitely has a POV, the traveller's. We also have the mission of presenting travel info in at least a slightly cheaky manner. If you want to warn the reader, then warn the reader! the traveller comes first! -- Mark 01:04, 10 October 2006 (EDT)
"Many travellers report becoming ill after eating here. Stay away!" strikes me as NPOV if it is true. So does "Utterly brilliant restaurant — excellent food, reasonable service, low prices. Pashley 05:06, 18 September 2006 (EDT)
Like most of the listing examples, this one doesn't cover all the bases. There is no demonstration of how to list email or fax in the example. Also, do we want a tel: prefix. I know listings are up for being changed, but let's do this right anyways? OldPine 07:44, 17 October 2006 (EDT)
I think we should mention in this policy how to write the street address, with regards to language issues. I often see translated addresses (e.g., Tavisuplebis Moedani translated to Freedom Square). My hunch is that this is not a useful thing to do for the traveler. I think we should always keep the local version of the street address, since that's what travelers will see on signs and will need to communicate to taxi drivers. Since foreign alphabets can be tricky, perhaps our policy should be to always transliterate street addresses from foreign languages. --PeterfitzgeraldTalk 20:12, 30 May 2007 (EDT)
Agreed; this applies to other types of listings as well: see, do, sleep. Which article is best for this kind of policy? --DenisYurkin 04:03, 21 October 2007 (EDT)
Good point, I suppose Wikitravel:Foreign words is the best place, although a better place would be a more general policy "help" article to explain how to use the new listings editor, when we roll it out on the site. --PeterTalk 16:07, 10 November 2007 (EST)
encourage evolution of reviews
Can we allow/recommend to list specific dishes that wikitravellers (dis)liked about a restaurant? The idea is to collect enough opinions before summarizing them into a concise summary.
For most destinations each wikitraveller visit them once or twice in a lifetime, and can't check its every aspect or dish. This is why every article is full of one-per-restaurant "try this" or "that is particularly good". Such wording doesn't encourage follower travellers to share their own experience on other dishes--and descriptions remains the same for years, without any progress.
Once someone likes a dish, he can add it to the "Recommended:" list. Once someone dislikes another dishes, he adds it to "Not recommended:". Once there're different opinions on a dish, it is moved to "Controversial:".
Once we have at least seven dishes in a single list, we can summarize place as good, bad or inconsistent quality.
This way we'll allow reviews to evolve and become valuable early in their lifecycle, not to wait for a distant day when we have a local expert willing to share his multiple-year experience of dining his overseas friends around his town. --DenisYurkin 16:48, 11 November 2007 (EST)
I think this is something that will be covered in the future when we are able to post personal reviews on Extra. I think it's great to say what dishes the restaurant is known for (and which ones to avoid), which is what we've tried to do all along without having a policy in place.
I personally don't like having lists within the description of the restaurant. Instead of saying:
Recommended: Big Macs, Strawberry Shakes. Not recommended: Filet-O-Fish.
I would rather is said:
Try a Big Mac, which is delicious and has an awesome special sauce, and a Strawberry Shake for desert. Don't order the Filet-O-Fish, unless you like eating a tarter sauce covered shoe.
I think the reason many descriptions stay the same for years is that we just don't have many contributors (yet). -- Fastestdogever 11:12, 12 November 2007 (EST)
I heard that Extra will allow reviews for individual venues, but haven't seen any prototype to have an opinion whether it will work. Is there anything demonstrating that:
contributors can as easily share their experience on specific dishes (as just contributing it to a specific review in wikitravel article);
a reader (or another contributor) can as easily find that information when reading about a specific venue in Wikitravel article?
--16:15, 14 November 2007 (EST)
I regularly recommend specific dishes, although I avoid language that sounds like a review. Some good examples here, I think. --PeterTalk 16:54, 14 November 2007 (EST)
Now imagine another contributor comes in to include his opinion on another dish which is not mentioned yet.
If he has a plain no-frills list, the process is easiest possible: he just edits the section (or soon a single listing item), adds his dish to the list and saves. Done. He doesn't need to rewrite the text around to accommodate two or three dishes (as you can see, your texts typically describe a single best dish, single to avoid etc).
If he deals with the examples you gave, he needs to re-phrase (re-structure the sentence). It raises barrier seriously: not only he needs to be able to structure a new sentence in English, he needs to keep the info gained so far. So in some cases he'll just give up; in others he'll modestly add to "Big Mac is delicious and awesome" something like "try also McFresh and McChicken" when he likes it. And of course, he typically don't have enough experience to compare Big Mac already reviewed with McFresh he's just tasted--and judge whether it's McFresh is really awesome (as in most restaurants his choice is dozens of options, not 3 or 4).
That said, the format you practice is good as an ultimate review in a Star article, but doesn't help much in collecting info for it (and review to evaluate to its Star condition, as I named this thread in the first place).
That's why I vote for something much more simple--like what I proposed. --DenisYurkin 02:34, 15 November 2007 (EST)
Well, frankly, this is the English Wikitravel — contributors should be able to structure a new sentence in English. I wouldn't support turning the restaurant listings into bare lists of good/bad dishes. For one thing, that's against Wikitravel:Tone. Generally, if a restaurant does some dishes very well, the other ones probably aren't too bad, either. Travelers need to know from us if the restaurant overall is good. They don't need to be pulling out their Wikitravel guide to hold up alongside the menu.
If a new contributer wants to add a highly recommended dish, fine, and if several people want to add recommended dishes, they should take it to the talk page and decide upon two or three to highlight. That's the same thing we'd do if fifty restaurant listings appeared for the same small town. Gorilla Jones 19:56, 15 November 2007 (EST)
We have some number of Star-status articles, plus some number of Star-potentials--not to mention earlier-status artucles. How many examples of such discussions around dishes to recommend (or avoid) in a specific restaurant do we already have in the past? --DenisYurkin 17:45, 16 November 2007 (EST)
We have a 'sleep' tag. Why is there no corresponding 'eat' tag (or if there is, is there a reason it's not mentioned in the article)? Army of me 00:00, 20 May 2009 (EDT)
The xml tags were added later than the listing format, and are all documented at Wikitravel:listings. Someone has updated the Wikitravel:Accommodation listings article etc, but noone has updated the info here. I still think there are some tags without any article devoted to them? --Inas 00:35, 20 May 2009 (EDT)
directions instead of an address
What if you want to add a restaurant that you feel represents the place well and would be a great experience for the traveller, but you do not know the address, only directions on how to get to the place? This is particularly applicable to Japan, where straight up street addresses are rarely used, and telling somebody that the restaurant is at 3-12 in the 3rd block of Nishiura doesn't really tell much about finding the actual place.
And what about providing external links to google maps? Azolotkov 09:34, 23 May 2009 (EDT)
Google Maps are out (Wikitravel:External links), but by all means, if you don't know the address, give directions to the best of your ability. The listings templates have a 'Directions' field, although if your directions are more than a few words (like the nearest subway stop), it's better to just add them to the body of the description. Gorilla Jones 11:58, 23 May 2009 (EDT)
The example at the top uses italics within the price field (labeled as "extra price info"; in the example it's "prix fixe menu on Friday and Saturday".) But the example is actually hard-coded, rather than using the <eat> tag, and for good reason: italics can't be used inside our listings tags. Any objections to removing the italics from the example and converting it to use the listings tag? LtPowers 13:07, 20 November 2009 (EST)
Please do. --PeterTalk 13:24, 20 November 2009 (EST)
Done. I replaced the Montreal example with one from Hiroshima, but I'm open to other suggestions if anyone can find one that uses as many of the fields as possible (I was looking primarily for one that had extra price information but with a not-too-long description). LtPowers 14:57, 20 November 2009 (EST)
OK, time for some trivial formatting problems!
It would be nice to add on a few examples of how to deal with more complex hours configurations, like:
I've kept pretty consistent to the style above throughout the many articles I've either written or cleaned up. Does it look right to others? --PeterTalk 18:18, 30 November 2009 (EST)
Wikitravel:Time and date formats seems pretty clear that it should be "Oct-May: M-F 10AM-4PM, Sa Su 11AM-3PM", etc. No – and no hyphen between Sa and Su. We might want to raise discussion there if you think it should be otherwise. LtPowers 21:36, 30 November 2009 (EST)
Fair enough—if I've just been doing it wrong, I'm not going to try and rewrite the rules to avoid correcting my own work. The more complex examples, though, aren't fully covered, so I'll bring those up. --PeterTalk 22:48, 30 November 2009 (EST)
Just to verify -- must "Eat" subsections always be "Budget/Mid-range/Splurge", or is division by cuisine sometimes appropriate? LtPowers 18:47, 30 April 2010 (EDT)
"Budget/Mid-range/Splurge" is always preferred for the sake of consistency, but most of the listings guidelines (Wikitravel:Bar listings, Wikitravel:Accommodation listings) also note the division by neighborhood or cuisine is OK when it makes sense. I'd be in favor of specifically calling out "Budget/Mid-range/Splurge" as preferred unless there is a good reason to use something else. -- Ryan • (talk) • 19:26, 30 April 2010 (EDT)
When I'm traveling, I'm most interested in type of cuisine first, and that's something that isn't captured in our listing format, so in many cases it seems like that would be the best way to sub-categorize listings. But maybe that's just me. LtPowers 20:17, 30 April 2010 (EDT)
I don't think that there's any doubt of the utility of a division by cuisine, but I'm not sure it's feasible in a collaboratively edited guide. While there are obviously exceptions, since most of our articles will have 10-30 restaurants (after which we tend to districtify or start trimming listings) division by cuisine would seem unnecessarily granular, or worse would encourage yellow page listings. See Palmdale#Eat and San Leandro#Eat for two such examples of where this seems to have gone very wrong. -- Ryan • (talk) • 21:11, 30 April 2010 (EDT)