Wikivoyage talk:Restaurant listings

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 comment was added by (WT-en) 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. --(WT-en) 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. -- (WT-en) Webgeer 17:28, Sep 15, 2004 (EDT)

price ranges

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 Wikivoyage article), it's not 100% clear how to fix it in the article.

I haven't seen really good definitions of "price range" at Wikivoyage 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. --(WT-en) 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. --(WT-en) Peter ^Talk 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 ($3-5)
    * budget pasta restaurants
  Steaks ($7-15)
    * budget steak houses
Mid-range
  Pasta ($5-8)
    * mid-range pasta restaurants
  Steaks ($15-20)
    * mid-range steak houses

--(WT-en) DenisYurkin 04:43, 21 October 2007 (EDT)

As a related initiative, I proposed to define region-level guidelines for Eat sections of articles in Spain: Project:Travellers' pub#region-wide guidelines. --(WT-en) DenisYurkin 17:27, 21 October 2007 (EDT)

Other opinions, please? --(WT-en) 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 Wikivoyage 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. --(WT-en) Peter ^Talk 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? --(WT-en) 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. --(WT-en) Peter ^Talk 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.

For the second, I vote for giving price ranges for most common categories: salads, first courses, main courses; set menu (if available). Here are some examples: Barcelona/Ciutat Vella#LElx, Barcelona/Ciutat_Vella#Silenus, Barcelona/Ciutat_Vella#Carmelitas. The reason is that traveler needs, appetits and situations vary, and we'll save a reader much time giving enough info on prices before he arrives to a restaurant.

This seem to cover typical categories for Europe. If we reach consensus on this, we can move on to other classes of food properties.

--(WT-en) DenisYurkin 17:48, 10 November 2007 (EST)

Looks like we're stuck with this discussion. Peter, do you think it make sense to invite more opinions from the Pub? --(WT-en) DenisYurkin 17:11, 15 December 2007 (EST)

Any ideas what can help us to make some progress in this discussion? --(WT-en) DenisYurkin 14:33, 26 October 2008 (EDT)

(Discussion moved from Template_talk:Eatpricerange:)

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. -- (WT-en) Sapphire • (Talk) • 06:00, 2 January 2008 (EST)

Would you mind to move this question to the discussion in Wikivoyage_talk:Restaurant_listings#price_ranges? It's quite relevant to the ideas recently added there. --(WT-en) DenisYurkin 14:51, 6 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. --(WT-en) 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?--(WT-en) 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. --(WT-en) 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? (WT-en) 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 (WT-en) DenisYurkin. As (WT-en) 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.

--(WT-en) Inas 22:45, 1 April 2009 (EDT)

Giving the issue a second thought, my proposal is to expand EatPriceRange template so that it can specify what exactly is meant a typical meal for a given article. Looks like it's easiest way to proceed with this. I've just plunged forward and edited Template:eatpricerange accordingly. --(WT-en) DenisYurkin 17:06, 27 November 2010 (EST)

URL style

The policy at Project: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. -- (WT-en) Beland 22:28, 14 Aug 2004 (EDT)

Please take a look at Project:External links/Links in listings for a (long) discussion of the topic. --(WT-en) Evan 19:33, 15 Aug 2004 (EDT)

Area Codes

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. -(WT-en) 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. -- (WT-en) 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. --(WT-en) Evan 17:10, 19 Aug 2004 (EDT)

List Ordering

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? -- (WT-en) Nojer2 18:47, 8 Dec 2004 (EST)

Based on the District Article Template and Big City Article Template, it seems that breaking them up into Budget, Midrange and Splurge is the way to go, for all listings. (WT-en) ByeByeBaby 03:27, 17 Apr 2005 (EDT)

...and following that rough guidline, I always try to put them in order by price. -- (WT-en) 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. --(WT-en) 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. -- (WT-en) 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. (WT-en) Jpatokal 21:22, 25 Jan 2005 (EST)

I have two different examples in hand:

First for really many locations: see Wagamama in London#Chains_reviews and its specific locations in Soho, Wimbledon and Islington.

Second for several-locations chain in Barcelona (before it's districtified): El Glop, Origen 99.9%.

Just created third example in Budapest: main review in city article, only relevant details in the districts: Buda and Pest. --(WT-en) DenisYurkin 17:08, 20 October 2007 (EDT)

BTW, aren't we ready to add more clarity on chains in this guideline article? I can plunge forward if no objections so far. --(WT-en) DenisYurkin 16:40, 20 October 2007 (EDT)

I plunged forward: added initial draft to the article. Of course we need to provide an example, but before that -- any serious corrections/criticism? --(WT-en) DenisYurkin 15:43, 10 November 2007 (EST)

Those guidelines look good to me. I just wanted to add an example of how we've been using listings for multiple-location chains in individual Chicago district articles:

• Harold's Chicken Shack. The great South Side fried chicken chain is cheap, usually a little dirty, and always delicious. Crowded at meal times. $2-5. 

• 917 W 87th St, ☏ +1 773 224-4621. 11AM-3AM daily. 
• 10259 S Halsted St, ☏ +1 773 568-5906. M-Th 10AM-midnight, F-Sa 10AM-1AM, Su 11AM-10PM. 
• 2521 W 63rd St, ☏ +1 773 778-9659. Su-Th 11AM-2:30AM, F-Sa 11AM-4AM. 

This format is a quick way to convey any differences in addresses, hours, and contact details, while limiting the common terms to one listing. --(WT-en) Peter ^Talk 15:59, 10 November 2007 (EST)

Thanks, I've added it to the article. --(WT-en) 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? --(WT-en) 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. --(WT-en) Peter ^Talk 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?

--(WT-en) DenisYurkin 08:07, 26 January 2008 (EST)

Since this has come up again, I suppose we should try and come up with a firm consensus. I do lean towards (WT-en) 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. --(WT-en) Peter ^Talk 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. --(WT-en) 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? --(WT-en) DenisYurkin 14:41, 26 October 2008 (EDT)

Categorization

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 Wikivoyage categorizations of Budget, Mid-range and Splurge. Comments? Other ideas to solve the problem? - SZ

I much prefer to use the prices themselves. --(WT-en) 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

Restaurant Classification

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

You might want to look at Project:Listings, where we're planning a new structured listing format, and Project:Restaurant listings. --(WT-en) Evan 15:18, 8 September 2006 (EDT)

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 Project:Listings page. You can do this now with <see>, <do>, <eat>, <sleep>, ... tags. --(WT-en) 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 comment was added by (WT-en) 210.210.145.6 (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. (WT-en) 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 comment was added by (WT-en) 210.210.145.10 (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. (WT-en) Hypatia 20:29, 9 October 2006 (EDT)

I'd like to chime in here and add to the reminder that Wikivoyage 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! -- (WT-en) 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. (WT-en) Pashley 05:06, 18 September 2006 (EDT)

Example

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? (WT-en) OldPine 07:44, 17 October 2006 (EDT)

Address Language

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. --(WT-en) Peterfitzgerald ^Talk 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? --(WT-en) DenisYurkin 04:03, 21 October 2007 (EDT)

Good point, I suppose Project: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. --(WT-en) Peter ^Talk 16:07, 10 November 2007 (EST)

encourage evolution of reviews

Can we allow/recommend to list specific dishes that wikivoyagers (dis)liked about a restaurant? The idea is to collect enough opinions before summarizing them into a concise summary.

For most destinations each wikivoyager 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.

The idea is to allow and encourage listing of good/bad/controversial dishes for a restaurant, like this: Calella de Palafrugell#La Torre.

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. --(WT-en) 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). -- (WT-en) 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 wikivoyage article);
• a reader (or another contributor) can as easily find that information when reading about a specific venue in Wikivoyage 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. --(WT-en) Peter ^Talk 16:54, 14 November 2007 (EST)

Peter and (WT-en) Fastestdogever,

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. --(WT-en) DenisYurkin 02:34, 15 November 2007 (EST)

Well, frankly, this is the English Wikivoyage — 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 Project: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 Wikivoyage 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. (WT-en) 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? --(WT-en) DenisYurkin 17:45, 16 November 2007 (EST)

Bold Tags

Moved in from the Pub:

I have been working on the California wine country lately and I have been wondering if it is appropriate to put bold tags at the end of listing for example

• Restaurant Y, xxx Main street. Bla bla bla review. Families romantic or Thai Food

So that people can scan through the article really quick and find something that fits what they need. The type of food or type of location, like good for families or a romantic date.

Any thoughts? (WT-en) Trew 20:02, 18 December 2008 (EST)

I suspect most people will prefer not to use bold tags for that kind of thing as typically bold is used only for really important information (example: "travelers should be aware that there are severe penalties for drug trafficking in Singapore"), but as long as you don't mind people potentially editing your work later you're welcome to see how it works out - if it turns out well and is useful then others may begin following your example. -- (WT-en) Ryan • (talk) • 20:36, 18 December 2008 (EST)

I think we need something like this--I tried to use Wikivoyage in my trips specifically to find a restaurant of a particular sort, and near me--and 2 or 3 keywords would be really helpful in my experience. So--definitely support. --(WT-en) DenisYurkin 16:38, 20 December 2008 (EST)

Eat tag

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)? (WT-en) Army of me 00:00, 20 May 2009 (EDT)

The xml tags were added later than the listing format, and are all documented at Project:listings. Someone has updated the Project:Accommodation listings article etc, but noone has updated the info here. I still think there are some tags without any article devoted to them? --(WT-en) 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? (WT-en) Azolotkov 09:34, 23 May 2009 (EDT)

Google Maps are out (Project: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. (WT-en) Gorilla Jones 11:58, 23 May 2009 (EDT)

Italics

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? (WT-en) LtPowers 13:07, 20 November 2009 (EST)

Please do. --(WT-en) Peter ^Talk 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). (WT-en) LtPowers 14:57, 20 November 2009 (EST)

Hours formats

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:

M,W-Sa 9:30AM-4PM,6PM-10PM, Tu,Su 10AM-4PM,5PM-9PM

It's not appropriate for all possibilities, but sometimes it can be useful to break it out by lunch, dinner, etc. I do that like so:

Lunch: M,W-Sa 9:30AM-4PM, Tu,Su 10AM-4PM; dinner: M,W-Sa 6PM-10PM, Tu,Su 5PM-9PM

And then there are seasonal hours, which I tend to format like:

Oct–May: M-F 10AM-4PM, Sa-Su 11AM-3PM; June–Sep: M-F 9AM-5PM, Sa-Su 9:30AM-4PM

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? --(WT-en) Peter ^Talk 18:18, 30 November 2009 (EST)

Project: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. (WT-en) 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. --(WT-en) Peter ^Talk 22:48, 30 November 2009 (EST)

I tend to leave out the "Lunch:" or "Dinner:" markings, as days/hours seem to be the most essential. I'm thinking WTers are smart enough to know if they arrive at 7PM, they shouldn't expect lunch specials any longer and if they have any questions, they can give a call to the establishment. For the restaurants which actually close in order to get prepared for the next shift of meals (i.e., lunch menu to dinner setting), then I the hours of operation would still help out the traveler and therefore, separately listing "lunch:" or "dinner:" seems unnecessary IMO. Additionally, wikimarkup allows for "hoursextra="" to be included, which is where I might put special notes about awesome lunch specials, happy hour, etc.

On another note, I see listings which state both "Tu-Su, closed M" and "Tu-Su." To me, the latter seems quite clear and thus preferred.(WT-en) Zepppep 12:38, 6 April 2011 (EDT)

I would object, as the former states a restriction more explicitly, and also helps when scanning listings on the go, looking for a place to eat right now. --(WT-en) DenisYurkin 16:13, 6 April 2011 (EDT)

Months should also be abbreviated to 3 letters. (WT-en) Zepppep 12:38, 8 April 2011 (EDT)

Subsections

Just to verify -- must "Eat" subsections always be "Budget/Mid-range/Splurge", or is division by cuisine sometimes appropriate? (WT-en) 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 (Project:Bar listings, Project: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. -- (WT-en) 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. (WT-en) 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. -- (WT-en) Ryan • (talk) • 21:11, 30 April 2010 (EDT)

Far from perfect, but in my belief it worked out in Barcelona (which still needs to be districtified) and Ciutat Vella, its central district. --(WT-en) DenisYurkin 16:39, 2 May 2010 (EDT)

emphasize key words to help in choosing a place

I find it useful to emphasize a word or two in restaurant listings to help a reader to choose a place. Current template does not allow that at all, but I'm sure we can create some precedents first, and after that generalize them as a rule.

So here is how I tried to implement this idea: see Paris/5th_arrondissement#Eat (see underlined words). The idea is to help create a shortlist basing on region/main focus of cuisine. Consider it what precedes breakup into "local / imported cuisine" plus "vegetarian"--precedes before we have enough listings to create subsections.

I'm sure it was discussed previously (and I even took part in the discussion), but I can't find it right now.

--(WT-en) DenisYurkin 16:55, 27 November 2010 (EST)

I see no reason why listings should not be subject to the same rules on bolding we have for other prose. That is, not too much, just enough to attract the reader's eye to words of importance. I would be wary that bolding a word or two in every listing may be too much (combined with the bolding of the restaurant's name), but I don't see that we need a unique policy for restaurant listings. (WT-en) LtPowers 10:40, 28 November 2010 (EST)

Do you mean you suggest to simply change underlines to bolds in the above example given? I'm only afraid it will make scanning the text more difficult compared to underlines (as it will take extra effort to understand a distinction between a characteristic/type keyword and a restaurant name). --(WT-en) DenisYurkin 16:27, 29 November 2010 (EST)

Ah, you were actually proposing using underlines, then. I misunderstood. As you know, we don't currently use underlining (not least because there's no wiki markup for it, and HTML must be used). I would want to see a consensus on using underlines at a wider forum (such as Project:Manual of style) before making rules on how to use them within restaurant listings. (WT-en) LtPowers 20:20, 29 November 2010 (EST)

Done: Project:Manual of style#how to emphasize prose keywords in listings. --(WT-en) DenisYurkin 16:27, 1 December 2010 (EST)

Formatting

I have two thoughts:

1. The <eat> tag adds a period at the end of the info, but if last item already ends in a period, this looks bad. Example: " Foobar's, at Main St. and Purple St.. " Could we have it not show double periods?

2. Most paper guidebooks I've read list all the information in italics or something, so that at a glance you can tell where the info stops and the review starts. Could we do that for the XML tag?

Example of current format: Shabuchin Shabu Shabu, 1-1-6 Kokutai-ji, Naka-ku, ☎ +81 082-246-7327. 11:30AM-2PM, 5PM-10PM daily. Small, friendly, family run shabu shabu restaurant in the fashionable Jizo-dori area. They make their own sauces, and all the ingredients are fresh; dip fresh meat and vegetables in a hot sauce to lightly cook it before dipping it in a savory sauce to eat. Expect to pay from ¥3,000-5,000, including drinks.

Example of desired format: Shabuchin Shabu Shabu, 1-1-6 Kokutai-ji, Naka-ku, ☎ +81 082-246-7327. 11:30AM-2PM, 5PM-10PM daily. Small, friendly, family run shabu shabu restaurant in the fashionable Jizo-dori area. They make their own sauces, and all the ingredients are fresh; dip fresh meat and vegetables in a hot sauce to lightly cook it before dipping it in a savory sauce to eat. Expect to pay from ¥3,000-5,000, including drinks.

2 Seems very much reasonable for me. --(WT-en) DenisYurkin 16:23, 19 March 2011 (EDT)

Some of the fields are already set off with italics, so we'd lose that if we italicize everything. Regarding the periods, we shouldn't be using them on most abbreviations per Project:Abbreviations, so it's a very rare situation. (WT-en) LtPowers 16:41, 19 March 2011 (EDT)

Formatting price range

The article provides "$lowprice-$highprice" yet the example has "¥3,000-5,000". I think it would be helpful if we removed the "$" next to "$highprice," as we only use one currency symbol. I think this is one reason why in several articles I see "$5-$10," for example, because the article is a little inconsistent. (WT-en) Zepppep 12:40, 8 April 2011 (EDT)

I've always wondered which way it was supposed to be. Do we have a reason for preferring one over the other? (WT-en) LtPowers 15:12, 8 April 2011 (EDT)

should we omit/explicitly state "daily" for 7 days a week venues?

For restaurants/cafes working 7 days a week, should we explicitly state that (e.g. adding "daily" next to business hours) or we should rather omit that? My question is related to this mass removal of "daily", among other edits: [1]. --(WT-en) DenisYurkin 15:50, 18 May 2011 (EDT)

I might be in non-compliance with our policies. But I think we should avoid stating the obvious, we also omit stating that it is Jan-Dec, --(WT-en) ClausHansen 15:59, 18 May 2011 (EDT)

I believe it's not obvious for everyone. I believe in some countries default is there are one or two day off a week (same for most restaurants in that country). OK, that could be fixed by stating in the intro paragraph that a typical restaurant in Vienna works 7 days a week.

Another reason for stating explicitly is to resolve ambiguity: if days are not stated, are they unknown (eg added by a one-time contributor who is not too aware of our policies) or are they 7 days a week? And I don't have an easy solution for this. --(WT-en) DenisYurkin 16:08, 18 May 2011 (EDT)

See your point. I have been doing what I find most reasonable, but I have no strong feelings about this, and am happy to follow whatever is the general opinion, --(WT-en) ClausHansen 16:17, 18 May 2011 (EDT)

Price range

I can't see a guideline for how we enter the price range. Is it for a main course only, a two-course meal, a three-course meal, with or without drinks? And what's the definition of budget, mid, and splurge? --(WT-en) SaxonWarrior 10:59, 16 October 2011 (EDT)

The definition of "budget", "mid-range", and "splurge" varies by location. They're used to divide listings into sensible categories, so whatever works best for that purpose in any given article is what should be used. For your other question, see #price ranges, above. (WT-en) LtPowers 11:46, 16 October 2011 (EDT)

Restaurant categories

Swept in from the pub

Sorry, another question. Can someone point me to a place where I can find how to determine what makes a place budget, mid-range or splurge? For the Netherlands, that is. Thanks! (WT-en) Justme 13:07, 26 July 2011 (EDT)

Mostly it's just a subjective matter, and the price categories are relative to the city in question. You could take a look at some well developed Dutch articles like Hilversum#Eat or Amsterdam/Old_Center#Eat. --(WT-en) Peter ^Talk 13:55, 26 July 2011 (EDT)

Lat / Long, Coordinates in restaurant listings

In the "Describing a chain of restaurants" section, the main entry lists both "lat" and "long", though that is not part of the template described at the beginning of the article. ¿Were these deprecated or added? Since this is a template page, the style should be consistent.

My guess is that they were present, but removed and accidentally left in this section. (WT-en) Mxmlln

As far as I know, lat and long are still valid parameters but not currently used for anything. Some third-party programs might use that data when it's present; I'm not sure. (WT-en) LtPowers 16:37, 16 March 2012 (EDT)

lat and long are used to show an icon that links to a page showing the place on a map. Very useful in my opinion. Nicolas1981 (talk) 11:53, 25 March 2013 (UTC)

My statement was correct at the time I made it. LtPowers (talk) 14:06, 25 March 2013 (UTC)

Do we really need more than four or five decimal places worth of precision in example co-ordinates for a listing? It looks like 0.00001 degrees is only a few feet. K7L (talk) 14:45, 25 March 2013 (UTC)

For most listings, four is probably sufficient; some might need five or even six depending on the size of the subject, while others might only need two or three. LtPowers (talk) 19:08, 25 March 2013 (UTC)