Wikivoyage talk:Breadcrumb navigation Voyage Tips and guide

Contents

Breadcrumb navigation is here! Coolness! Is this enabled across all Wikivoyage language versions now, assuming the proper templates are migrated etc? (WT-en) Jpatokal 03:27, 8 Dec 2005 (EST)

District pages look a little fugly if you try to add the IsIn code:

Singapore/Bugis
From Wikivoyage
< Singapore
Asia : Southeast Asia : Singapore : Singapore/Bugis

Any way to make this look prettier? Something like this would be better:

Singapore/Bugis
From Wikivoyage
Asia : Southeast Asia : Singapore : Bugis

< Singapore

(WT-en) Jpatokal 03:31, 8 Dec 2005 (EST)

It's enabled across all Wikivoyage versions. It doesn't work well with sub-pages ("Page/Subpage") yet; we should probably discuss how we're going to deal with that. For now, I'll get rid of the "< " stuff, and make the sub-page navigation fit seamlessly into the "isin" navigation. Actually, if that's the case, you shouldn't have to bother putting "isin" stuff into sub-pages, since I can figure it out from the name... hmm.

In any event, yes, fun stuff. Let's get Project:Breadcrumb navigation started so we can document the process. --(WT-en) Evan 10:46, 8 Dec 2005 (EST)

So I should hold off putting isIns into district pages right? --(WT-en) Ravikiran 00:44, 9 Dec 2005 (EST)

It doesn't cover spaces into underscores? --(WT-en) Ravikiran 07:06, 8 Dec 2005 (EST)

No. What's happening under the covers is that the template is adding in-page RDF that describes the geographical hierarchy, and the breadcrumbing code just reads that RDF and builds navigation from it. It's pretty magical, but it does require that you use the "URL form" of the parent article's name. --(WT-en) Evan 10:46, 8 Dec 2005 (EST)

I copied over Template:IsIn, but I can't make breadcrumb navigation work — even if I use all Latin characters (see [1]). What's wrong? (WT-en) Jpatokal 12:51, 11 Dec 2005 (EST)

Evan, I saw you played around with this, but it still doesn't work — any idea what the issue is? (WT-en) Jpatokal 23:14, 11 Dec 2005 (EST)

No, not yet. I'm going to experiment some more. It seems to be working on fr: (see fr:Australie) but I haven't tried on the other language versions. The error seems to be that PAGENAMEE isn't doing variable expansion in the RDF template... weird. Anyways, I'll try over the next couple of days. --(WT-en) Evan 00:37, 12 Dec 2005 (EST)

The problem occurs if the first letter of a site name is a non-ASCII character (for both linking and linked pages), ie {{PAGENAMEE}} returns a string starting with a percent sign. A solution is not only important for CJK languages but for all non-Latin and a lot of Latin-based languages, for instance German (examples de:Ägypten (Egypt) or de:Österreich (Austria)). (WT-en) Unger 06:21, 19 Dec 2005 (EST)

Unfortunately there's something more involved in ja:, because isIn doesn't work there even if the article name is entirely ASCII. (WT-en) Jpatokal 07:56, 19 Dec 2005 (EST)

Remark: Not only the name of the article itself must start with an ASCII character, but also the name of the article to be referred. For instance, the followings are impossible. (1) Nordarfika (North Africa) : Ägypten (Egypt), but also (2) Ägypten : Sinai. Then I added an X in front of Ägypten (XÄgypten) at the Sinai page, and in this case isIn was working. (WT-en) Unger 08:54, 19 Dec 2005 (EST)

OK, so, this is fixed for en:, de:, sv:, and now ja:. I hope someone else can copy the equivalents to the other language versions. --(WT-en) Evan 01:06, 6 April 2006 (EDT)

moved from User talk:(WT-en) Evan

You said in USA Talk -->I'm working on the code to show more than one breadcrumb list on the top of the page (we need it for a lot of areas, not just NM), so in the next week or so NM will appear in both regions.

I think that is great! and very much needed. Would it be okay to add add'l isIn's in areas that I work? Thanks! (WT-en) Xltel 15:25, 21 Jan 2006 (EST)

Absolutely; note that right now the last isIn template is the one that will be listed, so try to list add'l ones before it. Let's discuss this on Project:Breadcrumb navigation. --(WT-en) Evan 15:29, 21 Jan 2006 (EST)

I can see several places where this would be useful, I already figured out that last wins for now based on your edits. I can use this in the Ozarks and I know there are other areas that have this problem. Thanks!!! (WT-en) Xltel 16:03, 21 Jan 2006 (EST)

So let's suppose we have

• Ozarks isIn Oklahoma, Arkansas, and Missouri
• Eureka Springs (Arkansas) isIn Ozarks.

It Would Be Nice (tm) if we could have some kind of "directed breadcrumbing" where Eureka Springs' breadcrumb navigation pointed backwards only to Arkansas, and skipped the Oklahoma and Missouri paths. Hypothetically, if we marked Eureka Springs as {{isIn|Ozarks}} {{isIn|Arkansas}} you could infer the path. Use whatever mechanism and syntax you like. I see many examples where this would come in handy. -- (WT-en) Colin 22:57, 8 March 2006 (EST)

Albury-Wodonga and the other Australian twin cities (which are in two states) also could use two isIns. (WT-en) Hypatia 17:34, 10 September 2006 (EDT)

Did we ever find a way to have TWO bread crumbs displayed, one below the other?

eg: South America > Chile > Easter Island
      Oceania > Polynesia > Easter Island --W. Frank^e-mail_talk 12:19, 6 October 2012 (CEST)

No idea. On any other wiki, one would use categories for this (which make sense), for instance wikipedia:Glenrio, New Mexico and Texas is categorised to both states properly while here Glenrio is not because {{isIn}} isn't bright enough to take anything but the last tag listed. I run into the same issues with Thousand Islands and Niagara Falls only gets around it by creating two separate pages plus an ugly disambiguation. K7L (talk) 23:13, 22 October 2012 (CEST)

Sorry to be the bearing of bad news, but it seems that the breadcrumb navigation system is not functioning again. Check:Cotswolds (WT-en) WindHorse 18 Feb 06

It is now. --(WT-en) Ravikiran 08:49, 18 Feb 2006 (EST)

It looks fine to me. Can you be more specific, WH? --(WT-en) Evan 08:57, 18 Feb 2006 (EST)

Problem wasn't in the system. He'd put in the braces incorrectly. I fixed it. False Alarm --(WT-en) Ravikiran 09:01, 18 Feb 2006 (EST)

Sorry Evan. Thanks Ravikiran. I checked everything - but the braces by the sound of it. Anyway, it is lucky for me. Didn't they used to chop of the heads of bearers of bad news in Medaivel England!?! (WT-en) WindHorse 18 Feb 06

"The argument to the "IsIn" template must be in URL form. That is, spaces should be replaced by underscore ("_"), and non-URL characters like parentheses must be URL-escaped."

I don't think parantheses need to be escaped. I haven't been doing so and haven't had any problems -- see for example Contra Costa County. Is there some browser or some special circumstance where this is required, or can this warning be removed? -- (WT-en) Ryan 12:54, 4 March 2006 (EST)

Me too. I've been lazy and neeglecting to escape parantheses. I haven't faced problems, either in FF or IE. --(WT-en) Ravikiran 13:13, 4 March 2006 (EST)

Yeah, it's true. I think it's OK to have non-URL chars, but you _do_ have to do the underscores. --(WT-en) Evan 16:25, 4 March 2006 (EST)

Probably there is a good reason why a script is used for this Breadcrumb feature. The feature is beautiful and I love it. But it got me thinking, why a script? An alternative (that might not scale well with many people using it but I don't know that and it comes to mind) might be to simply use Templates one instide another something like this:

(spaces inserted in markup below to escape rendering)

On a Palo Alto page	{ {Palo Alto} }
On a Template:Palo Alto	{ {Bay Area} } : [ [Palo Alto] ]
On a Template:Bay Area	{ {California} } : [ [Bay Area] ]
On a Template:California	{ {USA} } : [ [California] ]
On a Template:USA	[ [USA] ]

('SF Bay Area' probably better that 'Bay Area' to keep it unique, but above is just for example)

Seems to work for me on my own MediaWiki without any script and to not require underscore in names.

Just thinking... --(WT-en) Rogerhc, 6 March 2006

It's not a script, it's a Mediawiki extension, which uses RDF markup in the output of a template called "isIn". -- (WT-en) Mark 01:12, 10 March 2006 (EST)

Examples where the breadcrumbs displayed don't refect what the isIn says:

Richmond (Virginia)/The Fan isIn Richmond_(Virginia)/Central -- North America : United States of America : South : Virginia : Central Virginia : Richmond : The Fan

New York (city)/Soho isIn New_York_(city)/Manhattan -- North America : United States of America : Mid-Atlantic : New York (state) : New York : Soho

New York (city)/Morningside Heights isIn New_York_(city)/Manhattan -- North America : United States of America : Mid-Atlantic : New York (state) : New York : Morningside Heights

The breadcrumb navigation functionality short-circuits for sub-pages. It doesn't even check for the RDF code -- it just assumes that X/Y is in X. I'll see what I can do to change that. --(WT-en) Evan 20:21, 6 March 2006 (EST)

Just in case it's somehow possible: it would be great if (for example) {{isIn|Durham_(region,_Ontario)}} would work, instead of having to use {{isIn|Durham_(region%2C_Ontario)}} - not just for lazy/forgetful people like me, but for all non-expert/non-techie types.

This is only a commemoration, because the IsIn template does not work on Japanese and some German pages where names use Japanese characters or German umlauts (especially at the beginning of the page name). (WT-en) Unger 01:37, 13 March 2006 (EST)

It's an error in the template, not the RDF code, it turns out. I changed de:Template:IstIn, and I guess I should probably copy something similar over to ja:, too. --(WT-en) Evan 00:53, 6 April 2006 (EDT)

It's working at the German Wikivoyage. (WT-en) Unger 11:09, 6 April 2006 (EDT)

This template version of breadcrumbs is great, and has very simple applications that using categories just cant cover.

Is there any way we can get our hands on the code for this template to use in other mediawiki installations?

Or can you even just give us a run down on how to create a similar breadcrumbs navigation tree ourselves? Thanks.

We're interested in adapting this breadcrumb system to our needs for developer documentation at Mozilla. It looks like you guys have a custom extension to process the RDF data and actually create the breadcrumbs; is this something that's available or will we have to develop our own? 24.151.172.59 12:41, 20 March 2007 (EDT)

It's available; email me at [email protected] and we can synch up a bit. I'd love to talk more about dev., anyways. --(WT-en) Evan 12:53, 20 March 2007 (EDT)

Golf in Australia is currently marked {{isIn|Australia}}. Is this an intended use of the template? The project page doesn't seem to say either way. (WT-en) Hypatia 04:32, 22 July 2006 (EDT)

I've run into this before, but can't seem to fix it here. The order that the isIn is saved seems to affect how the breadcrumbs are saved. Currently my problem is withNapa, Napa Valley and Bay Area (California). If you move the isIn and save (like I did here with Bay Area to try to fix the initial problem with the upper hierarchy not showing (i.e. California and higher wasn't showing above Bay Area on the Napa Valley page, then the hierarchy goes away. Wow, dunno if I made that clear. (WT-en) OldPine 18:33, 31 July 2006 (EDT)

I fixed it down to Napa using a complicated process involving the purge command, a squirrel, and jumping up and down on one foot. It'd be nice if this process was automatic or something. I think the root of it is something like "if the parent isn't in the cache, the breadcrumb trail for the child don't work". -- (WT-en) Colin 18:58, 31 July 2006 (EDT)

I think it's extremely important to note for the record, in case anyone is worried, that no squirrels were harmed during the performance of this maneuver. -- (WT-en) Ryan 19:01, 31 July 2006 (EDT)

Dudes! You be geniuses as usual! You explain like a genius, too. Can I use your squirrel for Calistoga, too?. And what the heck is a purge command. Damn. I'll never make Admin. (Which is OK :)) (WT-en) OldPine 19:03, 31 July 2006 (EDT)

To purge, click on the 'history' tab. Then edit the URL at the top of your browser to change 'history' into 'purge', then return to perform the purge. Then I usually have to click 'discussion' then click 'article' again to get the right version. I'm unsure whether you have to perform the purge-n-binge from the top down, or if it suffices to just purge-n-binge the article, I'll have to ask that squirrel as soon as I figure out where I threw him. Darn things hate being swung by their tails. -- (WT-en) Colin 19:14, 31 July 2006 (EDT)

Durn squirrel is fast, but it's the moose you gotta watch out for. Thanks, Colin. (WT-en) OldPine 19:19, 31 July 2006 (EDT)

I see people changing the order that these are in. Typically they are putting the article status (e.g. outline ) below the isIn|xxx. I my drive to Do Everything Right(tm), I am curious as to the reason/necessity for this. (WT-en) OldPine 06:51, 25 September 2006 (EDT)

Apparently the breadcrumbs work more reliably if they are above the article status - exactly why I don't know, but I've seen in mentioned more than once (on talk pages, don't think I've seen it on an actual "policy" page).

In addition, I think it makes sense to have the isIn and status right at the very bottom, as they are the most likely of the bottom-of-the-page-stuff to need editing (especially status, as the article progresses from outline to star; also isIn as the guide hierarchy becomes more complete and stuff gets shuffled around), and easy to navigate to if you know you want the very last line. ~ 203.144.143.3 08:07, 25 September 2006 (EDT)

One of the minor (major?) problems we've had with Template:IsIn, and other RDF-containing templates, is that the arguments to the template have to be URL-encoded (non-ASCII characters are changes to %XX), and spaces need to be converted to underlines. With the upgrade to MediaWiki 1.8.2, there are now functions built into MW to do this. So we can start changing these templates so they don't need to have encoded input.

Changing IsIn and other templates so that they expect unencoded input rather than encoded input would mean that huge numbers of pages won't work correctly. One way to do this kind of changeover is to create a new template (like Template:IsPartOf) that expects unencoded input, and use that for new pages. We could then gradually convert the older pages with Template:IsIn to use the new template.

Then again, it may not be that urgent a problem. Any ideas for how, or whether, to do this? --(WT-en) Evan 17:20, 17 October 2006 (EDT)

Not sure if this would work, but... it seems to me that underscore and percent-escapes never occur in the proper names of destinations. If you installed ParserFunctions, you could use #pos to grep for those two chars and then use #if to select between passing the text raw or encoding it first. -- (WT-en) Colin 17:56, 17 October 2006 (EDT)

We actually have ParserFunctions installed, so that might be a good way to do it. It's worth some further experimentation. --(WT-en) Evan 18:14, 17 October 2006 (EDT)

My bad. #pos is a StringFunction. --(WT-en) Colin 19:04, 17 October 2006 (EDT)

The isPartOf coding seems to work with our without underscores... so why can't we just copy that code into the isIn template to save the better-named and easier to use one? Names that were previously underscored for the isIn template should still work. Am I missing something else? – (WT-en) cacahuate ^talk 19:42, 25 June 2007 (EDT)

OK, I missed the parentheses part... it doesn't work with url-style ones (New_York_%28city%29). Can't someone whip up a bot or something to go through and change them into parentheses? I personally would much rather keep isIn working and change the code to work like isPartOf than switch to isPartOf – (WT-en) cacahuate ^talk 19:53, 25 June 2007 (EDT)

If it means having only one template, I'd be in favor of using the isPartOf code for isIn, fixing broken isIn's as we find them, and converting all isPartOf's to isIn's and then deleting isPartOf when it is unused. It's a bit of work, but it's easy, we would just need to gain consensus that it's a good idea. -- (WT-en) Ryan • (talk) • 20:17, 25 June 2007 (EDT)

I would support this. To clean up the breadcrumbs we could just hire the birds from Hansel & Gretel. Or unleash the (WT-en) fastest dog ever. --(WT-en) Peter ^Talk 21:48, 25 June 2007 (EDT)

Ha! I think they'd make a good combination! And a (WT-en) Jani-bot would make a deadly threesome – (WT-en) cacahuate ^talk 22:12, 25 June 2007 (EDT)

Bump! Any additional comment re: updating the isIn code, getting rid of isPartOf, and fixing broken isIn's as they are found? -- (WT-en) Ryan • (talk) • 17:14, 26 June 2007 (EDT)

Seems like the obvious thing to do. (WT-en) Pashley 19:41, 26 June 2007 (EDT)

All seems sensible to me. (WT-en) Gorilla Jones 19:55, 26 June 2007 (EDT)

Agree, improve "IsIn", change uses of "IsPartOf" to be "IsIn", clean up problem cases. (Not that I'm volunteering to steer the bot that cleans up the problem cases.) (WT-en) JimDeLaHunt 04:33, 27 June 2007 (EDT)

What a huge amount of busy work for 0.0% visible gain to contributors or readers. Please, let's use this amount of energy for making travel guides instead.

If people are worried about the funny characters, let's use IsPartOf from here on, deprecate IsIn, and at some point in the future I'll make IsIn work magically with either encoded and unencoded characters. --(WT-en) Evan

But if people are willing to do the work, and it clears up the confusion of having two templates that perform the same task, is there any harm? It seems like there is an interest in getting rid of the template duplication, and people have indicated they prefer the shorter "isIn" to "isPartOf", so I'm not sure I see the harm in making this change. -- (WT-en) Ryan • (talk) • 12:11, 27 June 2007 (EDT)

It's a problem with a simple technical solution (fix the IsIn template so it works like IsPartOf by default but if there's a % or _ in the input, it works like the old IsIn) that really shouldn't be done by hand. During the hand conversion, which may take months, tons of breadcrumb paths will be broken. At the end of that time... we'll have exactly the same breadcrumbs as now. The whole reason we use MW templates is so that we don't have to rewrite tens of thousands of articles by hand.

Let's do this: I've installed the StringFunctions extension (see Special:Version). Let's see if we can make a Template:SmartIsIn that acts either like IsIn or IsPartOf depending on if there's a % or _ in the argument. If it works, let's replace Template:IsIn with it. We can then go back and de-encode the existing IsIn uses at our leisure, if anyone's really hot to do that. --(WT-en) Evan

This sounds like a good plan to me. Great to see the bureaucracy in motion! --(WT-en) Peter ^Talk 14:22, 27 June 2007 (EDT)

That sounds great, anything we can do to save the better named and easier to type isIn! – (WT-en) cacahuate ^talk 21:19, 27 June 2007 (EDT)

I agree with the idea of fixing isIn and any links that that breaks. However, I'd like to keep IsPartOf as well, for use where there's a relationship but isIn doesn't fit. For example, several shorter intineraries are part of Overland_from_Singapore_to_Shanghai and Yunnan tourist trail is part of one route in Overland to Tibet. So perhaps isIn for places, IsPartOf for itineraries. Is the Related tag all we need for travel topics? (WT-en) Pashley 06:16, 28 June 2007 (EDT)

(WT-en) Pashley, it sounds like you are proposing a new template function, to identify shorter itineraries as part of longer itineraries, and reusing the IsPartOf name for that function. I think that's a separate discussion that belongs in a different place. Here we're talking about Breadcrumb Navigation and the templates that create it. (WT-en) JimDeLaHunt 14:25, 28 June 2007 (EDT)

We now have Template:Related that works for Pashley's concern – (WT-en) cacahuate ^talk 22:17, 2 July 2008 (EDT)

(swept in from pub)

I can't believe this is not covered elsewhere, but I could not find it. What is the rationale for using one rather than the other. Should IsPartOf always be used? (WT-en) OldPine 09:31, 2 June 2007 (EDT)

I think it's a historical thing. IsIn was created, and everyone loved it and was happy. Then someone noticed that it broke badly for places with spaces or other non-alphabetical characters in the name, and the level of happiness declined. Evan then created isPartOf as a test to see if it fixed the problem, and the happiness level again increased. The downside was that we had a ton of articles that used isIn, but a much better solution in the form of isPartOf. Since isPartOf is a better solution I think it should replace isIn, but unfortunately we can't simply get rid of isIn since it's used in so many existing articles. If desired we could probably start a crusade to get rid of isIn altogether, much like 2005's war against the "External links" section, but prior to embarking on that battle it might be best to get other's opinions on whether or not it's worthwhile. -- (WT-en) Ryan • (talk) • 12:39, 2 June 2007 (EDT)

Ryan pretty much covered all there is to know, but in case anyone is interested, this was also discussed here. --(WT-en) Peterfitzgerald ^Talk 12:42, 2 June 2007 (EDT)

OK, Thanks. Seems way over my head so I'll just start using the new form. I trust there is a reason why the old template (IsIn) cannot just be changed, that is, fix the code. Is this not a job that a bot could run? (See IsIn, replace with IsPartOf?) Geez, nevermind. Why do I even think I can understand Geekiness on such I grand scale? :) (WT-en) OldPinw 13:06, 2 June 2007 (EDT)

The problem (as I understand it) is that IsIn requires the use of underlines and other kludges, but IsPartOf breaks if you use them. - (WT-en) Todd VerBeek 13:09, 2 June 2007 (EDT)

A key element of geekiness involves laziness. In this case, since nothing is actually broken we can procrastinate and avoid doing any additional work. If it HAD to be fixed then the laziness vs. work quotient (LVWQ) is applied to determine if it's worthwhile writing a bot. Basically, you guess how long it will take to write a bot (and this calculation is ALWAYS wrong by half) and compare that to how long it will take to fix by hand, taking into account the likelihood that someone else will deal with it. Note the special case where the person performing the calculations is too lazy to actually work out the solution, in which case you again default to hoping someone else will deal with it. -- (WT-en) Ryan • (talk) • 13:16, 2 June 2007 (EDT)

You know, I have been using IsIn because it is faster to type, but that's kind of silly. I'll add the IsPartOf to the article templates—it is marginally easier to edit. --(WT-en) Peterfitzgerald ^Talk 13:42, 2 June 2007 (EDT)

Ah, now that all rings a bell,Ryan. Guess I don't have the perspective. I was thinking that whipping up a bot is real easy since I've never actually done it... or even written a script in probably 10 years. It all seems so easy when you're sitting in the audience. Thanks, guys, for splainin' things to the old guy. (WT-en) OldPine 13:46, 2 June 2007 (EDT)

If for some reason we do go on a crusade or start a bot, I would suggest rather than changing IsIn's to IsPartOf's we should fix the IsIn template and then spend the work fixing the spaces and underscores. I also continue to use IsIn because I would much rather type that than IsPartOf, and it just has a much better ring to it. Lame, but true. On the new Hindi WT we've set up IsIn to work the way that IPO does here, though obviously a much easier task since we've only got like 20 articles. – (WT-en) cacahuate ^talk 03:26, 3 June 2007 (EDT)

I tend to use isPartOf by default these days since it just works better than isIn, but I agree with (WT-en) Cacahuate that a better solution will be to get isIn fixed and use that exclusively --(WT-en) NJR_ZA 05:10, 3 June 2007 (EDT)

We are currently trying to drum up consensus for a proposal to update the isIn code, get rid of isPartOf, and fix broken isIn's as they are found. Please comment here. --(WT-en) Peter ^Talk 18:33, 26 June 2007 (EDT)

We're working toward using this at Mozilla's documentation site now, but have encountered a problem. We have pages with colons in the name; this seems to badly break things. Changing the colons to %3A doesn't seem to fix anything. Any suggestions?

How does it badly break things? Any idea where it happens in the code? --(WT-en) Evan 15:03, 26 April 2007 (EDT)

Turns out the actual problem is that the extension doesn't work for namespaces other than NS_MAIN, and my test cases were all in the User namespace. Once I figured that out, everything's actually fine. 24.159.184.104 14:05, 27 April 2007 (EDT)

Regardless of your position on IsIn or IsPartOf, the SmartIsIn template created above is unused, and unnecessary when using isPartOf. I'm not sure it is appropriate for a vfd, but nevertheless I think it should be removed to avoid confusion. Any views to the contrary? --(WT-en) inas 20:08, 8 July 2009 (EDT)

Nuke it. (WT-en) Jpatokal 22:38, 8 July 2009 (EDT)

I've suggested formalising the omission of the isPartOf template on districts here. It anybody has an opinion they can express it there. --(WT-en) inas 01:48, 10 July 2009 (EDT)

The edit screen still encourages the use of IsIn. Right below Save Page and Show Preview is a template shortcut for IsIn. How do we update this to IsPartOf? (WT-en) Jtesla16 14:56, 18 July 2009 (EDT)

Should be fixed now [2]. --(WT-en) Peter ^Talk 15:32, 18 July 2009 (EDT)

Swept in from pub:

Is there are a way to view all articles that are marked as part of another with the IsPartOf tag?

Specifically, I am trying to identify all articles which have been marked IsPartof Bali.--(WT-en) Burmesedays 10:20, 6 September 2009 (EDT)

Sadly, no. The best I've got for you is to use the search function to look for "{{IsPartOf|Bali}}". (WT-en) LtPowers 10:24, 6 September 2009 (EDT)

Thanks. I really ought to have thought of that myself. A search for each of IsPartOf|Bali and IsIn|Bali seems to do the trick. --(WT-en) Burmesedays 10:39, 6 September 2009 (EDT)

Is there a Magic word or template which extracts the country name of a certain article? I'm looking to build a template which needs "Austria" for Vienna and "Germany" for Berlin... -- Eiland (talk) 21:03, 22 October 2012 (CEST)

Swept in from the pub

Is there any way to turn off breadcrumbs on an individual page?

I tried removing {{isIn}}/{{isPartOf}} from Thousand Islands with the intention of creating the breadcrumbs manually (as the autogenerated crumb trail doesn't properly handle a destination split by a region boundary) but I still get "contentSub" as a pointless circular link "Thousand Islands". K7L (talk) 20:54, 20 November 2012 (UTC)Reply

K7L devised a hack for displaying two sets of breadcrumbs in Thousand Islands. While non-standard, and not very verisimilitudinous with the programmatic breadcrumbs, it does get the most visible part of the job done. Is this something we want to ratify? LtPowers (talk) 20:31, 21 November 2012 (UTC)Reply

Yes, why not. --Alexander (talk) 20:56, 21 November 2012 (UTC)Reply

Not to repeat myself, but because it's non-standard, doesn't actually look like our current breadcrumbs, isn't positioned in the same place as our current breadcrumbs, and doesn't allow the breadcrumb data to be machine-readable. LtPowers (talk) 21:51, 21 November 2012 (UTC)Reply

FWIW, any changes higher in the hierarchy would need to be updated manually every time if this is implemented en masse (even if it's for a limited number of articles that needs multiple breadcrumb trails). Vidimian (talk) 20:54, 22 November 2012 (UTC)Reply

Obviously we don't want such a solution. Dual breadcrumbs are useful, but they should be built into the template, not manually written out on every page. --Globe-trotter (talk) 21:53, 22 November 2012 (UTC)Reply

Anything higher in the hierarchy can be done by creating a redirect like Russia (Asia): #REDIRECT [[Russia]] {{isPartOf|Asia}}. If one then puts {{isPartOf|Russia (Asia)}} on some other article under that level, ie: Siberia is part of Russia (Asia) (the redirect, which is part of Asia) the breadcrumbs actually do fall into place as Asia > Russia (Asia) > Siberia. This is true even though the actual Russia page isn't in the Asia hierarchy. All smoke and mirrors. Moscow is still in Europe. The fake dual breadcrumbs aren't enough to make this happen as they create an article which technically isn't in either parent region, so anything under such a page would just be Russia > Siberia instead of Asia > Russia > Siberia. K7L (talk) 22:47, 22 November 2012 (UTC)Reply

That would be lower in the hierarchy (though you've come up with a good solution there). I believe Vidimian was talking about the case where we have a destination in two different regions (with two manual breadcrumb trails), but one of the larger container regions gets moved or resegmented. The automatic breadcumbs will pick that change up automatically, but the manual ones will not. LtPowers (talk) 03:32, 23 November 2012 (UTC)Reply

Yes, that ("but one of the larger container regions gets moved or resegmented") was exactly what I was trying to convey. Vidimian (talk) 11:55, 23 November 2012 (UTC)Reply

That would have occurred recently... Thousand Islands is in eastern Ontario and northern New York. The division of Eastern Ontario was changed to combine various shells of county articles (Frontenac County, Leeds-Grenville, Stormont-Dundas-Glengarry) into Seaway Region. That did, indeed, require that Thousand Islands be placed manually in Seaway Region. It also required that Kingston (Ontario), Gananoque, Brockville and Cornwall (Ontario) all be edited manually to place them in the created Seaway Region. I don't see a way around this - if we change the hierarchy, there are always multiple manual edits. The fake breadcrumbs are only a small part of this as they affect so few articles (they address what I shall call the one narrow Glenrio problem, where a point too small to be split into two articles Windsor-Detroit style falls directly onto a region boundary - Glenrio being a TX/NM Route 66 ghost town so as small as it gets without falling off the map). K7L (talk) 19:07, 23 November 2012 (UTC)Reply

When the extension displays "India -> Plains (India) -> Delhi", the "(India)" part is useless, I think. How about removing it at display time? That would make breadcrumbs more pleasant for readers. Nicolas1981 (talk) 16:38, 18 December 2012 (UTC)Reply

That would require a change to the PHP code for mw:extension:GeoCrumbs and therefore might be best addressed on bugzilla:? K7L (talk) 17:01, 18 December 2012 (UTC)Reply

Good idea, though if it takes non-trivial effort I'd say it is one we need not worry about until other things like fixing images are done. Pashley (talk) 19:18, 18 December 2012 (UTC)Reply

It should be recorded in bugzilla for tracking purposes, even if it is low-priority. You never know when a MW developer might be browsing around looking for low-hanging fruit. LtPowers (talk) 19:25, 18 December 2012 (UTC)Reply

Is there any case where this would actually hurt? Just seeking community consensus before sending to bugzilla. Nicolas1981 (talk) 05:08, 19 December 2012 (UTC)Reply

No, please do! --Peter ^Talk 08:28, 19 December 2012 (UTC)Reply

Yes, go ahead. The only complication I see is that there are cases like the one here where you have both Antwerp (province) and Antwerp or something similar. There would need to be a little cleverness in the bot or you might get "Holland -> Antwerp -> Antwerp" or some such in the display. Pashley (talk) 01:44, 20 December 2012 (UTC)Reply

As opposed to "New York, New York" which wouldn't even get a second glance? K7L (talk) 01:53, 20 December 2012 (UTC)Reply

Wouldn't it? LtPowers (talk) 02:05, 20 December 2012 (UTC)Reply

https://bugzilla.wikimedia.org/show_bug.cgi?id=43313 Nicolas1981 (talk) 10:32, 20 February 2013 (UTC)Reply

Thanks, but the proposed solution is needlessly complex. We should just remove all parentheticals from the breadcrumbs, without bothering to check the stack for prior occurrences of the term. LtPowers (talk) 02:04, 21 February 2013 (UTC)Reply

I'm not understanding your proposal. How would it be OK to remove parentheses from breadcrums, especially when a province and a city within it have the same name? Ikan Kekek (talk) 03:04, 21 February 2013 (UTC)Reply

North America > United States of America > Great Plains > Kansas > Eastern Kansas > Kansas City (Kansas)

Do we need (Kansas) once more in parenthesis when it's already in the crumb trail twice? K7L (talk) 18:16, 21 February 2013 (UTC)Reply

OK, I get it now: The parenthesis will be removed only from the display - commented out, basically. Yes, that's a good idea. Ikan Kekek (talk) 19:18, 21 February 2013 (UTC)Reply

Swept in from the pub

Why are self links at the top of the page made active? I am referring to the (useless) links for navigation present on a page (like Asia > South Asia > India > Southern India > Kerala > Cherthala). Merry Christmas···Vanischenu^「m/_Talk」 17:34, 25 December 2012 (UTC)Reply

See bugzilla:42946. This, that and the other (talk) 22:14, 25 December 2012 (UTC)Reply

Thank you very much. But I am confused why it is written Status: RESOLVED FIXED there while I can still experience it.···Vanischenu^「m/_Talk」 00:44, 26 December 2012 (UTC)Reply

Sorry, that was the wrong bug! The issue you reported is not, as far as I know, yet resolved. Perhaps another bug needs to be filed in the GeoCrumbs component. This, that and the other (talk) 09:18, 26 December 2012 (UTC)Reply

Thanks for pointing out that. And the reported bug is also appearing to me!···Vanischenu^「m/_Talk」 11:21, 26 December 2012 (UTC)Reply

I agree that self links in the breadcrumb trail are unnecessary. Please do file a report. --Peter ^Talk 18:38, 27 December 2012 (UTC)Reply

As far as I know, bugzilla:42946 just gets rid of links like Travellers' pub from pages where it is the only "crumb" in the breadcrumb trail (ie: pages which can't claim to be "isPartOf" some other region or place). The "resolved fixed" only means that a valid code change which can fix the bug has been written and tested, not that it has actually been deployed to the servers. The link is obviously still here until the extension with the bug fix is deployed. If you're suggesting going further, for instance to change "Europe > Spain > Madrid" to "Europe > Spain > Madrid" on the Madrid article (as there's no point in the self-reference being a clickable link) that should be reported as a separate bug. K7L (talk) 04:06, 28 December 2012 (UTC)Reply

Bugzilla:43660 I am sorry for taking too much time. Thank you···Vanischenu^「m/_Talk」 14:59, 5 January 2013 (UTC)Reply

K7L is completely correct. Resolved fixed usually means the code has been merged into master (except some devs on small projects use it when a patch has been uploaded to Gerrit), not that the patch has been deployed to <insert name of your wiki which MediaWiki development is expected to revolve around here>. The patch for bugzilla:42946 does just get rid of links with only one crumb (since these breadcrumbs are usually just a repeat of the title above, excluding namespace). --Krenair ^{(talk • contribs)} 15:11, 5 January 2013 (UTC)Reply

Swept in from the pub

I was thinking this project was doing very well with only 89 Orphaned pages, but I have come across a few pages that the only linked to them are from user pages. Take for example Los Alamitos and Cypress. Is there a more accurate list of orphans? Also these pages bring up another question; is there a convention for listing towns, cities and areas of a county? For example Orange County (California) only lists a few cities (in USA sense of the word), adding all would be a little messy but how else do you navigate to such local pages? I can see you can navigate up a Breadcrumb but how do you navigate down one?--Traveler100 (talk) 06:54, 27 December 2012 (UTC)Reply

I've long wanted to know that too, but never took the time to ask. The relevant page for this issue is Wikivoyage:Breadcrumb navigation. There's nothing about navigating down the breadcrumbs on either the page or it's talk page. If someone knows the answer please also update that page. AHeneen (talk) 08:33, 27 December 2012 (UTC)Reply

One idea is to place the article in a category based on parameter used in {{IsPartOf}}. --Traveler100 (talk) 15:40, 28 December 2012 (UTC)Reply

Well it appears I was not the first to think of this. Just looked at the German Wikivoyage and this is exactly what they do. I have created a sandbox for the template with the edit required for people to test and comment upon.--Traveler100 (talk) 19:06, 28 December 2012 (UTC)Reply

I can see that the Breadcrumb navigation is a good alternative for categories, but as far as I can see only when moving up a trail. How can you move down a breadcrumb trail? Or maybe more to the point how can you see which articles are using a particular parameter in the {{IsPartOf}} template? For example I would like to see which articles are tagged with {{IsPartOf|Orange County (California)}}, {{IsPartOf|Inland Cities (Orange County)}} and {{IsPartOf|Beach Cities}}.--Traveler100 (talk) 17:44, 27 December 2012 (UTC)Reply

Everything that is tagged with {{IsPartOf|Orange County (California)}} should be listed on the Orange County (California) page. Sometimes this doesn't happen for one reason or another, but that's the ideal; any anomalous cases should be repaired. We do it manually because geography is messy, and doing things programmatically can backfire very easily. LtPowers (talk) 22:03, 28 December 2012 (UTC)Reply

How do you propose to find "any anomalous cases" which "should be repaired"? The list of pages with "isPartOf" and a geographic location don't seem to be obtainable from special:search or special:whatlinkshere, so short of downloading a project:database dump and extracting the information programmatically I'm not sure what would find these. K7L (talk) 04:17, 29 December 2012 (UTC)Reply

The same way we fix any other problems in our guides. Why does it have to be programmatic? LtPowers (talk) 15:03, 29 December 2012 (UTC)Reply

Could you explain exactly how that is done? For example I have come across a number of articles that have {{IsPartOf|Orange County}} which is a dis-ambiguous page. How do I find other cities and locations that reference this county without going through all towns in these counties in 8 different states of the USA and possibly China and others? --Traveler100 (talk) 15:09, 29 December 2012 (UTC)Reply

From the database dump, it looks like the following are (or were) {{IsPartOf|Orange County}}: Anaheim Hills, Caspers Wilderness Park, Costa Mesa, Cypress, Fountain Valley, Garden Grove, Laguna Niguel, Lake Forest, Los Alamitos, Orange (California), Placentia (California), Saddleback Valley, Stanton, Yorba Linda. All of them belong in California, most of them still need to be fixed. K7L (talk) 07:05, 30 December 2012 (UTC)Reply

Thanks for the information. This will help with me cleaning up this area but this was really just an example case. How can this be done in general. Do I need to get an explanation of how to read the database dump?--Traveler100 (talk) 07:32, 30 December 2012 (UTC)Reply

We seem to be talking past each other a bit. Let me be clear. There is no programmatic/automatic method of navigating down a breadcrumb tree. The intended method for readers is to use the subregion and destination links to navigate down the tree; breadcrumbs are for getting back up and providing context. For wikignomes maintaining the tree, there is no technical measure in place that generates a list of inclusions. Perhaps that's an oversight, but it's just never been implemented. It's always been the responsibility of editors to update those breadcrumb links when the hierarchy changes.

For Orange County specifically, it's probably my fault. I moved the disambiguation page to the base name several months ago, but I missed updating those particular breadcrumbs. The only breadcrumbs I updated at that time were the two subregions of O.C.: Beach Cities and Inland Cities (Orange County), because those should have been the only articles with "IsPartOf|Orange County". If those two subregions don't represent the entirety of O.C., then other subregions should be added to Orange County (California); if they do represent the entirety of O.C., then the articles K7L identifies above should have their breadcrumb trails adjusted to point to one of the two subregions, not the county article. LtPowers (talk) 15:45, 30 December 2012 (UTC)Reply

Whatever is done about this, it needs to be a fairly general solution. Ideally, it would support navigating down the tree, but you don't always want all the levels; that is probably OK if you are looking at Orange County, but if you look at the USA you probably don't want links to every town. Ideally, you'd be able to use the hierarchy to select contents for a book too. Are there consistency checks worth doing? Pashley (talk) 18:04, 30 December 2012 (UTC)Reply

The obvious solution is to use Categories. It is easy for the IsPartOf to add the article to a category of the same name as the region parameter (have set up sandbox of the syntax). Problem is that creating all the categories and the hierarchy to match the breadcrumb trail, not something you would want to do manually. This would allow people to walk down as well as up the trail. Also provide a method for all contributors to check that region article have a link to pages that reference it. This or some similar system is going to have to be set-up as the site becomes more popular. --Traveler100 (talk) 18:58, 30 December 2012 (UTC)Reply

Certainly, I am seeing exceptions which we may want to know about, such as blank "isPartOf" tags (or no tags) on geographic locations and "isPartOf" tagged onto disambiguation pages, itineraries and travel topics. Many on the "no tag" list are false positives in that they should be marked as itinerary or travel topics, but the "blank tag" is likely an error.

Blank "isPartOf" tags appear on Abastumani, Acharacle, Aleutian Islands, Aligoodarz, Alstonville, Alytus, Amagasaki, Andeok, Anjar, Anyang (South Korea), Aogashima, Arbus, Arcadia (Greece), Ariel, Athy, Azna, Baan Ao Leuk, Bacacay, Bacup, Bahuan, Bahuna, Ballyhaunis, Ballymoney, Bandel church, Bandel, Ban Sen, Bao Loc, Barcelos, Bergslagen, Bhandardara, Bhimtal, Bikal, Biysk, Blönduós, Bontang, Boseong, Boyle, Braidwood, Bressay, Buchanan (Liberia), Buscalan, Buyeo, Byumua, Caral, Cardenás, Carlingford, Carrick-On-Suir, Celbridge, Chara, Charlestown (Ireland), Charleville Castle, Chinon, Chiusure, Čičmany, Circum-Baikal Railway, Ciudad Pemex, Cividale del Friuli, Clane, Claremorris, Clervaux, Clonmel, Co Loa, Comalcalco, Conception Bay South, Cong, Croajingolong National Park, Cromford, Cross Plains, Curonian Spit, Cyangugu, Dan Chang, Datong Township, Dehang, Dhulikhel, Dokos, Dorrigo, Drexel Hill, Drummore, Dunleer, Elbow Cay, El Cuco, Ellode Sri Lakshmi Adinarayana Swamy Temple, El Medáno, El Mina, Emmendingen, Engels, Ennistymon, Enugu, Erice, Esso, Etawah, Evans Head, Falcarragh, Ferapontovo, Fethard, Fetlar, Forillon National Park, Foundiougne, Foxford (Ireland), Frankston, Frear Park, Frutillar, Fukue Island, Gabiro, Gaiziņkalns, Gako, Gapyeong, Gargnano, Gennadi, Giethoorn, Gikongoro, Gimhae, Gitega, Glen Mills, Glen Saint Mary, Gorontalo (city), Gortahork, Goshen, Gotō Islands, Green Ridge State Forest, Guatape, Guatavita, Gwangmyeong, Hajo, Haworth (New Jersey), Hayden (Colorado), Hayfork, Hermitage, Hikutavake, Hiva Oa, Hokuto (Hokkaido), Honokaa, Hornchurch, Hradec Kralove, Huahine, Huatugou, Huehuetenango, Hunsrück, Hüttschlag - Großarltal, Ialysos, Iao Valley State Park, Ibusuki, Ichalkaranji, Igatpuri, Ilkley, Inagi, Indiana (Pennsylvania), Intipuca Beach, Ioannina, Iowa Great Lakes, Iranduba, Isojoki, Jaintia Hills, Jaipurhat District, Jinggangshan, Juma, Kakani, Kakarbhitta, Kalinga, Kappad, Kazeroon, Ketambe, Kežmarok, Kharga Oasis, Khasab, Khun Yuam, Kibungo, Kien Giang, Kigeme, Kilbeggan, Killala (Ireland), Kilrush, Kimolos, Kivuruga, Koenigslutter, Koh Rong, Kokrobite, Komae, Koto Gadang, Koyonza, Kulusuk, Kutancane, Kyaukpadaung, La antilla, La Calera, Laem Yai, Lai Chau, Lamayuru, La Merced, Lar, Lecompton, Leixlip, Les Gets, Limone, Lira, Liuku, Lohja, Long Branch (New Jersey), Longford Town, Lure National Park, Luso, Lysekil, Macaé, Macchiwara, Machala, Madonas novads, Mahone Bay, Maiduguri, Maithili phrasebook, Majorlândia, Makanda, Malanje, Malegaon, Mamori, Manacapuru, Maplewood (New Jersey), Marcali, Mariinsk, Marshall (North Carolina), Märsta, Marvdasht, Matawai, Maupiti, Maynooth (Ireland), Medford (New Jersey), Mellieħa, Międzyodrze, Millinocket, Mirissa, Moalboal, Monchique, Monteroni d'Arbia, Mount Ida (Arkansas), Muscatine, Muui-do, Muyinga, Naas, Nagaon, Naihati, Nalychevo Nature Park, Nameri National Park, Nanling national forest park, Narra, Negishi, Neillsville, Neryungi, Neusiedl Lake, Newbridge, Niangziguan, Nkoringo, Novaya Chara, Oamaru, Ocumare de la Costa de Oro, Oens, Ogaki, Opatija, Östhammar, Oued Laou, Out Skerries, Owings Mills, Paço de Arcos, Pader, Pak Lay, Pallas-Yllästunturi National Park, Pangumbahan, Pang Ung, Papa Stour, Paraíso, Paraparaumu, Paratunka, Parmadan, Peggy's Cove, Pequenos Lençóis, Pezinok, Phan Rang - Thap Cham, Pingxiang (Jiangxi), Playa El Esteron, Playa Las Flores, Poggio San Quirico, Polemitissa, Posio, Pragpur, Promajna, Punta Carnero, Punta de Choros, Punta gallinas, Punta Uva, Quan Lan, Quin, Quispamsis, Raumati, Reggello, Risoul, Roscrea, Rosendale, Rougemont, Sabae, Sabang, san jose, camarines sur, Sainte-Adèle, Saint-Joseph-du-Lac, Sakai (Fukui), Salaberry-de-Valleyfield, Sälen, Sam Neua, Samobor, Santa Catalina (Panama), Santana, Santaquin, Santa Teresa Costa Rica, Santo Domingo (Venezuela), Sape, Saravan, Sarkaņi, Savage (Maryland), Seaford, Selkirk (Manitoba), Semmering, Severomorsk, Sevlievo, Sheregesh, Shimabara, Shiroda, Sikinos, Slyudyanka, Small Carpathians Wine Region, Soc Trang, Somers (Connecticut), Sorsogon City, Souss-Massa, South Windsor, Srostki, Stia, Stockholm with children, Stony Brook, Straffan, Suomenniemi, Surigao Del Norte, Svobodny, Swanage, Tabarka, Tadachi, Takengon, Takestan, Talakona, Talampaya National Park, Talofofo, Tamphel, Tamuning, Tangting, Tarcutta, Tari, Tashtagol, Tatajuba, Tatopani, Taüll, Tavarnelle Val di Pesa, Tellicherry, Telšiai, Temanggung, Temerloh, Templemore, Tentena, Tetonia, Tien Giang Province, Timonium, Tipperary, Tissamaharama, Todos Santos Cuchumatán, Torotoro National Park, Trappeto, Tra Vinh, Trois-Pistoles, Tuam, Tullahoma, Tupana, Tynset, Tyrellspass, Uiwang, Ungasan, Valley of Fire State Park, Vanderbijlpark, Varamin, Vereya, Villanueva de Sigena, Volokolamsk, Vrbovec, Wadsworth, Warwick (New York), Wears Valley, Weligama, West Sepik, Whalsay, White Marsh, Willow (Alaska), Wimberley, Xiandu, Yeongi, Yeongnam alps, Yusuhara, Zahle and Zaouiate Oued Ifrane.

I have copied that list to User_talk:Pashley#Sandbox and am fixing them. Pashley (talk) 15:34, 8 January 2013 (UTC)Reply

Done, except for three where I could not work out what link to use. Pashley (talk) 18:08, 9 January 2013 (UTC)Reply

Nice job, I was wondering who was bringing the list down so quickly. Note I have the template automatically creating a list at Category:Articles needing IsPartOf parameter. --Traveler100 (talk) 20:32, 9 January 2013 (UTC)Reply

There are no tags on A Day In Providence, Aizawl, Alvar Aalto Center, Amedi, Anina, Appenzell, Aran va Bidgol, Architecture, Arctic, Ardabil, Asia, Asuke, Baclayon, Badaling, Bampoor, Banovci, Vukovar-Srijem County, Baybay, Behshahr, Bellary, Binhai New Area, Bobovišća na Moru, Bodie, Bojnourd, Bosanska Krupa, Bukovnik Lake, Buruanga, Butuan, Canyon de Guadalupe, Cape Sata, Chimmony Wildlife Sanctuary, Cixi City, Clairton, Coron, Costa Verde (Marina di Arbus), Dalton in Furness, Devgad, Dezful, Discover, Dive sites of Timor-Leste, Edgewood (Cranston), El Yunque National Forest, Epidaurus, Espoo, Fraser Island, Futaleufu, Gorgan, Goseong, Grand-Bassam, Great Limpopo Transfrontier Park, Gurmukhi, Hamilton (Massachusetts), Hogenakkal, HouJie, Ilam, Imperial Beach, Islas Paridas, Jageshwar, Jalasjärvi, Janjanbureh, Jhelum, Karijoki, Khekhtsirsky Nature Reserve, Khorram Abad, Khowar Script, Kindia, Koramangala, Korhogo, Kot addu, Kumbo, Kupang, Lamma, Langzhong, Lansdale, Lapua, Learning Devanagari, Lenzerheide, Los Barriles, Los Cristianos, Madiun, Magalawa Island, Maku, Maltahöhe, Mannargudi, March, Marlborough (England), Masjed Solayman, Matara, Maumere, May, Mekedatu, Merimbula, Merzouga, Mount Pleasant (Michigan), Mrkonjić Grad, Mukah, Munger, Mures, Murray Bridge, Nagari Sungai Pinang, Nanqen, Nekala, Neumünster, Nevada City (Montana), Nineveh, Nishitokyo, North Uist, Ocna Sibiului, Okinoerabujima, Oraviţa, Out Stack, Ovar, Pagudpud, Palm Beach (Aruba), Pangandaran, Parrsboro, Patacancha, Pawapuri, Pelabuhan Ratu, Penghu, Prijedor, Qingzhou, Quonset Point, Ranau, Raniya, Rawanduz, Red Bank, Riffa, Rödelheim, Sabang (Palawan), Sabzevar, Saint-Marc, San Martín de los Andes, Scala, Sedella, Severna park maryland, Shahmukhi, Shangli, Shunan Zhuhai National Park, Sikhote-Alin, Slobozia, Soča Valley, Sodankylä, Solta, South Uist, St Albans, Star articles, Sudbury (Suffolk), Sugar Land, Sulaimaniyah, Sulina, Table Rock Lake, Tafi Atome, Tal Afar, Tangomarkkinat, Tanjung Limau, Tarbet (Loch Nevis), Terney, Torbat Jam, Trim, Tripura, Universal Orlando, Universal Studios Florida, Villupuram, Wasco, Wimborne Minster and Žumberak.

The no-tag list is a mess of false positives until continents and valid itineraries, travel topics and phrasebooks can all be tagged as such. The German breadcrumbs use "Index" as the one top-level node, then "World" for geographical locations (with the continents at third level) and the travel topics under "Index". If we had a means programmatically to generate and display the entire tree, it would be one tree with "Index" as one root; any other broken tree bits with something else as a root would be errors. Our top-level nodes are continents, so there is a separate tree for each and the travel topics, itineraries, disambiguations or phrasebooks are not part of these trees. Nonetheless, displaying the trees programmatically would tell us if Orange County were broken off as a root of its own tree (by being listed "isPartOf" from lower-level articles without actually being a valid branch of anything above). All those broken tree bits could then be tossed into a wood chipper.

Another possible sanity check could be to have some sort of 'bot verify that any page tagged as {{isPartOf|wherever}} actually appears on the "cities and towns" or "regions" list on [[wherever]]'s main regional page. I don't know of any existing programs to do this, although certainly the tools do exist for categories (special:wantedcategories, uncategorised categories and the like). K7L (talk) 19:05, 30 December 2012 (UTC)Reply

On Wikipedia the AutoWikiBrowser is often used for checking and clean-up processes, bots are relatively easy to create and do not need knowledge of database dumps and the like, only a reasonable category structure of articles. I can understand not wanting too many categories on an article but one that mirrors the breadcrumb hierachy of regions would suffice. --Traveler100 (talk) 20:55, 30 December 2012 (UTC)Reply

I believe there is a workable solution working with manual creation of categories that will not create Wanted Categories red links. Examples of sandbox test referenced in discussion at Template talk:IsPartOf#Category of IsPartOf.Traveler100 (talk) 15:04, 5 January 2013 (UTC)Reply

There's a script 'pagefromfile.py' in the pywikipediabot package which reads a file and posts it to a wiki as an article. I have a list of "isPartOf" tags extracted from database dumps at user:K7L/isPartOf (huge, 1MB or so list) which I could feed to a database programme, weed out the ones that don't have any levels beneath them and then start spitting out category description pages, "'''category:SomeTown''' {{isPartOf|Category:SomeRegion}} For the main article on SomeTown, see [[SomeTown]]." for posting by a 'bot. Is this worth opening as a script proposal? K7L (talk) 22:03, 10 January 2013 (UTC)Reply

Yes if you could start a script proposal I will provide some input on the spec. Have not got to grips with bot myself yet. Would save me months of manual typing! Also one we have a mirror category tree I think it will be possible to set up a category of mistyped isPartOf parameters. --Traveler100 (talk) 08:39, 11 January 2013 (UTC)Reply

Districts do not automatically show the breadcrumb trail anymore. If an IsPartOf-tag is added, it does show, but it lists the district in the City/District format. Anyone has an idea how to get this fixed? --Globe-trotter (talk) 02:15, 6 January 2013 (UTC)Reply

File a bug, or dig into the code yourself; the extension was re-written and doesn't match the old functionality precisely. LtPowers (talk) 14:51, 6 January 2013 (UTC)Reply

So we're going forward with Categories? Do we have a consensus to actually do that? LtPowers (talk) 00:05, 8 January 2013 (UTC)Reply

See no reason for not switching it on. Has been discussed for over a week, mainly positive comments. Best to try out while in Beta, can always switch it off again if major issues are identified. Only negative I see at the moment is that the categories are to be created manually, it would be really useful if someone could generate these automatically. --Traveler100 (talk) 06:11, 8 January 2013 (UTC)Reply

So I have created one trail down from Category:United States of America through Category:Orange County (California) to individual cities. Only drawback I see is that the contents of a category once it is created does not update until those articles and categories are updated again. This gives a false impression sometimes of the category hierarchy. Really would be good if someone could write a batch job for the categories (based on current syntax). Simple update of the template would then update the contents. --Traveler100 (talk) 08:34, 8 January 2013 (UTC)Reply

I am not (yet?) convinced categories are a good idea. You end up with two hierarchies, one coded by IsPartOf tags and one by categories. Keeping them in sync is going to be problematic if it is done with code, and a disaster if we try to do it manually.

Moreover — and this is both an advantage & a disadvantage here — while each destination has one parent in the region hierarchy, categories are inherently suited to overlapping relations. The hierarchy shows Paris in in France and Europe, and that seems to me to be the important info. A category tag that only shows it is in its immediate parent region does not look all that useful, unless you duplicate effort and build a hierarchy based on those tags.

Also, there might be other uses for category tags & it is not clear to me if these would conflict. Does the region contain a UNESCO world heritage site? Does the city have an international airport? Is it a seaport?

Anyway, I do not think we should seriously consider categories here until the IsPartOf hierarchy is cleaned up, complete & consistent. Pashley (talk) 13:38, 8 January 2013 (UTC)Reply

If you could navigate down as well as up with the isin breadcrumb or could guarantee that all pages of a region where listed on the page, then I would agree. This is however not possible. As for cleaned up IsPartof hierarchy, this is a growing wiki, it will never be complete and consistent. Not a criticism, just the nature of the beast. Traveler100 (talk) 14:36, 8 January 2013 (UTC)Reply

My biggest concern with this proposal remains that we don't (yet) have a bot that will automate the task of managing these categories. Managing this manually seems like a non-starter: it's too big of a task and too easy for things to get out of sync, in which case the usefulness of the feature is greatly diminished. If someone can create a bot that runs regularly to manage this hierarchy, however, then this could be a very useful feature. -- Ryan • (talk) • 15:57, 8 January 2013 (UTC)Reply

If you change the inPartOf parameter in an article to change its region position in a breadcrumb this automatically changes the article to the new category. Which region category is a category goes in would have to be edited but then the same argument goes for what articles a region article lists. In testing this I have also seen page content out of sink with the breadcrumb trail. Traveler100 (talk) 20:17, 8 January 2013 (UTC)Reply

I'm not concerned with articles being added to categories via isPartOf, but the creation of the category pages and the management of which category "isPartOf" another seems like it will be problematic. Manually creating (and managing) thousands of categories doesn't seem like something that can be reasonably done without automated tools. -- Ryan • (talk) • 20:56, 8 January 2013 (UTC)Reply

I am hoping someone will come up with some good tools. Get some momentum going. --Traveler100 (talk) 22:29, 8 January 2013 (UTC)Reply

Unfortunately, I missed this discussion, but even after reading the whole scattered conversation I don't feel I understand what is going on. Could anyone summarize the proposal? What will these new categories contain? Will Category:Europe contain only individual countries, or all European destinations in a single list?

My first (and probably wrong) impression is that the geographical categories will be a useful maintenance feature, but they should remain hidden from readers because we don't want people to mess up things by editing categories manually, and we don't want people to bypass our regional articles. --Alexander (talk) 16:40, 8 January 2013 (UTC)Reply

In an article when you use the inPartOf template to say what region it belongs to, that article will be placed in a category of the same name. This will create a category hierarchy that mirrors the breadcrumb hierarchy. Categories do not contain more than what is in the breadcrumb structure. Users should/need not create their own categories in an article. Provides the ability to then walk down the trail of regions from country to area to city as well as up which was the only direction possible before. Allows the reader to see other locations in the same region when these articles are not listed on that regions page but have been given that region's inpartof value. Will provide an article collection method and structure to help with bot and semi-automatic browser runs. Provides a cross check of links in page to articles in region. --Traveler100 (talk) 20:27, 8 January 2013 (UTC)Reply

You can "walk down the breadcrumb trail" by going from a region to its subregion, then to another subregion, and eventually to a single destination. Missing (unlisted) destinations should be simply fixed, this is a purely technical matter. Considering your arguments, I am pretty sure that the categories must remain hidden and used solely for maintenance purposes. Otherwise, these categories will simply duplicate and eventually replace our regional articles. --Alexander (talk) 20:47, 8 January 2013 (UTC)Reply

How do you simply fix a subregion? How do you find articles that belong to subregion but are not mentioned in that articles text?Traveler100 (talk) 21:12, 8 January 2013 (UTC)Reply

Sometimes they are mentioned in other articles or in an upper-level regional article. Anyway, we have a mechanism to go down the breadcrumb trail. We should keep this mechanism in order rather than replace it with a new one. There are several serious arguments why categories should not be used here (except for maintenance purposes -- those are perfectly fine):

• Categories provide bare listings without any descriptions. Regional articles have (or should have) more information about individual destinations, including brief descriptions adjacent to each link
• Categories stimulate people to add and create new categories. We know that Paris belongs to Île-de-France, but most readers will manually add Category:France because they reasonably consider Paris as a part of France. Regional articles solve this problem because they always mention big cities on every level of geographical hierarchy (i.e., we have a link to Paris in the France article). As far as I understand your proposal, the category tree will mimic the cryptic system at Commons, where you have to go through all regions and subregions.
• Categories are a slippery slope. If we create categories for geographical objects, why don't we create them for something else?

--Alexander (talk) 21:57, 8 January 2013 (UTC)Reply

If someone sticks {{isPartof|France}} onto Paris, we currently have no easy way to spot these (short of looking at every article individually to find them). With categories, it would be possible to look at category:France and know exactly what is tagged as being there; this would make moving misplaced local articles to some lower level of the hierarchy easier, not more difficult. commons: does this sort of thing routinely with images filed as commons:category:Canada, commons:category:Russia as huge areas that must be subcategorised. K7L (talk) 01:40, 9 January 2013 (UTC)Reply

Yes, but this does not happen because most people do not know what the isPartof template means. Categories are simple and attractive, they stimulate people to add more categories (we have seen this shortly after the launch at WMF). Once again, I am supportive of the idea to introduce categories, but they should remain hidden. Categories were never supposed to be the navigation mechanism at Wikivoyage, and I don't see why we may want to change this. --Alexander (talk) 06:58, 9 January 2013 (UTC)Reply

Being hidden may not be a bad idea, at least until all the categories have been sorted out. If people think this is the thing to do at this point, simply add __HIDDENCAT__ to {{RegionCat}}.--Traveler100 (talk) 07:55, 9 January 2013 (UTC)Reply

I also think that makes sense, at least for now. --Peter ^Talk 18:23, 9 January 2013 (UTC)Reply

I have to say that the manual creation of categories is counterproductive. This takes a lot of time that can be spent for more useful edits, such as adding new content and updating existing texts, not to mention the never-ending image replacement. As long as no automatic tool is available, the category tree will never be complete and will not serve its purpose. Additionally, the link "create category" at the bottom of the page is annoying. Should not we wait (and look) for a bot solution?

Even more importantly, should not we develop a bot solution for the synchronization before the new categories turn into a mess? --Alexander (talk) 11:43, 11 January 2013 (UTC)Reply

Creating the template and some categories as been an informative process. It has shown to be useful in identifying misplaced articles and how best to label the categories before we generate a large number of them. I also find the category tree a quick way to find locations. However I tend to agree with you that a manual creation is not really the way to go. Please support Wikivoyage:Script nominations#User:K7Lbot. Yes the Create category link is not nice looking; any suggestions on some way of keeping it on a page without being so visible? Until we have the bot I would like to keep it there but I think it is only confusing people at the moment. --Traveler100 (talk) 10:45, 12 January 2013 (UTC)Reply

The "subpages" section says:

• Subpages are commonly used for districts of huge cities. In this case the the breadcrumb navigation assumes that the subpage lies within the parent page. For instance the article London/Westminster is recognised as a sub-region of London.

• However if the template is omitted, no RDF will be generated for the isPartOf relationship.

I thought this meant subpages of huge cities did not need the tag; they would automatically get the breadcrumbs without it. Currently, at least on my browser (recent Firefox on Ubuntu Linux), there are no crumbs on the London or Warsaw districts, though Shanghai districts are OK. What do others see? Is something broken? Pashley (talk) 13:48, 8 January 2013 (UTC)Reply

There is code in mw:extension:GeoCrumbs which is explicitly intended to assume a subpage is part of its parent's crumb trail; I believe this used to work. I do notice one bug now gone where a main article with no isPartOf tags used to get a useless one-article breadcrumb trail pointing to itself (that used to happen on every page, every namespace). I presume, then, that WMF actually is maintaining the code and that it would be a good idea to report this as a bug. K7L (talk) 14:56, 8 January 2013 (UTC)Reply

I have seen the same inconsistent behavior—looks like a bug. --Peter ^Talk 04:15, 9 January 2013 (UTC)Reply

Oddly, the crumb trail exists for "Dixieland" (as a subpage of project:BJAODN) but not for "Manhattan/Midtown" (as a subpage of a mainspace article). Adding or removing the blank "isPartOf" tag seems to make no difference. K7L (talk) 15:49, 11 January 2013 (UTC)Reply

The German WV uses a template de:vorlage:isInKat which applies the {{isPartOf}} tag and also places an article in a category with the name of the region a place isPartOf. This appears to be a workaround for the problem that breadcrumbs simply cannot handle a place which isPartOf more than one region (usually because of being on a region boundary):

• In Asia, Europe: Caucasus
• In Asia, Europe: Russia
• In Australia, Islands of the Indian Ocean: Christmas Island
• In Bavaria, Upper Palatinate: Regensburg
• In California, Nevada: White Mountains (California)
• In Canyon Country, Dixie: Zion National Park
• In Charlotte County, Sarasota County; Englewood (Florida)
• In Chicagoland, Northwestern Indiana: Lake County (Indiana)
• In Chile, Argentina, South America: Tierra del Fuego
• In Daniel Boone Country, Eastern Tennessee: Big South Fork National Recreation Area
• In Desert (California), Southern California: San Bernardino County
• In Eastern Alberta, Saskatchewan: Lloydminster
• In Faroe Islands, Eysturoy: Gjógv
• In Faroe Islands, Suðuroy: Hov
• In Faroe Islands, Suðuroy: Hvalba
• In Faroe Islands, Suðuroy: Sumba (Faroe Islands)
• In France, Caribbean: Guadeloupe
• In France, Northern France: Normandy
• In Gulf Coast (Mississippi), Florida Panhandle, United States of America: Gulf Islands National Seashore
• In Idaho, Montana, Northwest Wyoming: Yellowstone National Park
• In Illinois, Eastern Iowa: Quad Cities
• In India, Pakistan: Baltistan
• In Islands of the Southern Ocean, South America: Falkland Islands
• In Kayin State, West of Bangkok: Three Pagodas Pass
• In Knowledge Corridor, Five College area: Northampton (Massachusetts)
• In Lorain County, Erie County (Ohio): Vermilion (Ohio)
• In Melanesia, Australia: Norfolk Island
• In Middle East, Europe: Turkey
• In Montenegro, North Montenegrin Mountains: Kolašin
• In Monterey Bay, Santa Cruz County: Santa Cruz (California)
• In Mpumalanga, Limpopo: Kruger National Park
• In Navajo Nation, Northern Arizona: Window Rock
• In Nevada, Desert (California): Death Valley National Park
• In New Mexico, High Plains: Glenrio
• In New South Wales, Queensland, Gold Coast: Tweed Heads
• In Northeastern Utah, Northwestern Colorado: Dinosaur National Monument
• In Northern Benin, East Burkina Faso, Southwestern Niger: W National Park
• In Oklahoma, Arkansas, Missouri: Ozarks
• In Ozarks, Ozarks (Arkansas): Buffalo National River
• In Ozarks, Southwest Missouri: Licking
• In Ozarks, Southwest Missouri: Rockaway Beach (Missouri)
• In Polynesia, Micronesia: Midway Islands
• In Polynesia, United States of America: Hawaii
• In Republic of Macedonia, Povardarie: Demir Kapija
• In Riverina, High Country (Victoria): Albury-Wodonga
• In Rocky Mountains (United States of America), Southwest (United States of America): Four Corners
• In Seaway Region, North Country: Thousand Islands
• In Silicon Valley, Santa Clara County, South Bay: Campbell
• In Silicon Valley, Santa Clara County, South Bay: Cupertino
• In Silicon Valley, Santa Clara County, South Bay: Gilroy (California)
• In Silicon Valley, Santa Clara County, South Bay: Los Altos
• In Silicon Valley, Santa Clara County, South Bay: Mountain View (California)
• In Silicon Valley, Santa Clara County, South Bay: San Jose (California)
• In Silicon Valley, Santa Clara County, South Bay: Santa Clara (California)
• In South Goa, Canacona: Palolem
• In Southwestern Idaho, North Central Idaho: River of No Return Wilderness
• In Southwest Virginia, Eastern Tennessee: Bristol (Tennessee-Virginia)
• In Summit County (Ohio), Wayne County (Ohio): Norton (Ohio)
• In United States of America, Caribbean: U.S. Virgin Islands
• In United States of America, Polynesia: American Samoa
• In Upper Austria, Salzburg (state), Styria: Salzkammergut
• In Viana do Castelo, Minho: Caminha
• In Western Australia, Wheatbelt: Wagin
• In West Pomerania, Baltic Sea Coast: Usedom
• In Worcestershire, Cotswolds: Broadway (England)

Swept in from the pub

I think we should have our breadcrumbs in our mobile site version. I believe this could be done by adding class="mf-breadcrumbs" to the <div id="contentSub"> like so:

<div id="contentSub" class="mf-breadcrumbs"> (I believe that is only for mobile Main Page. Not sure really if there is anything like it for regular pages. --Rogerhc (talk) 21:52, 5 February 2013 (UTC))Reply

I may be mistaken but I think this would be done by us coming to a consensus that it should be done here, and then someone posting a request in Bugzilla with a reference to that consensus. I think mw:Extension:GeoCrumbs is what makes the breadcrumbs and the PHP code for it in the extensions dir of Wikivoyage on the server would need an edit. Yes? --Rogerhc (talk) 22:39, 29 January 2013 (UTC)Reply

In MediaWiki, the "contentSub" line normally contains a tagline slogan like "From Uncyclopedia, the content-free encyclopedia" or "From Wikipedia, the free encyclopedia". GeoCrumbs just replaces that text with the breadcrumb trail. The code which generates 'div id="contentSub" ' is likely part of MediaWiki or a MediaWiki skin (and not the extension), so I have no idea whether this is something easily changed. K7L (talk) 15:16, 30 January 2013 (UTC)Reply

I believe that "From Wikivoyage..." tag line is in "siteSub" not "contentSub". See page source and mw:Manual:Skinning/Tutorial#Subtitles . --Rogerhc (talk) 18:49, 30 January 2013 (UTC)Reply

The problem with breadcrumbs on mobile is that they can get REALLY long. Take Walt Disney World/Magic Kingdom for instance. LtPowers (talk) 15:47, 30 January 2013 (UTC)Reply

Agree with Powers, I see breadcrumbs can get too long. Maybe not do this on mobile, unless breadcrumbs could be converted into a workable pop-up list. --Rogerhc (talk) 18:35, 30 January 2013 (UTC)Reply

Could we possibly just have the previous 3 items in the breadcrumb hierarchy? That would prevent it getting long, but still allow users to go up the hierarchy, even if slowly. JamesA ^>talk 01:37, 3 February 2013 (UTC)Reply

Interesting idea. Might just work. I haven't a clue how to make it happen though. --Rogerhc (talk) 21:56, 5 February 2013 (UTC)Reply

Swept in from the pub

I looked at the rules, but didn't find anything regarding this issue.

It's been suggested in Talk:Muntenia that all counties in the region are redirected to the region, because there are too many counties and too few destinations. I proposed I will drop all counties except Prahova County which contains a lot of cities. But wouldn't it be weird to have a bunch of cities in the region, and then a county which has even more cities? I'm just asking because I am not sure whether that would be against the rules or not. IonutBizau (talk) 13:17, 18 December 2014 (UTC)Reply

I find myself wondering if Padlipsky's "If you know what you're doing, 3 layers is enough; if you don't, 17 layers won't help you." might apply here. He was talking about network design and, as usual, being snarky about OSI and its seven layers. I do think we sometimes have a problem with too many more-or-less empty articles, partly caused by bad layering.

However, policy has always been to redirect real places and counties are real places so I see no point in deleting them. On the other hand, if the articles do not exist there is no reason to create them, except perhaps for a well-known name that seems likely as a search term. Pashley (talk) 14:22, 18 December 2014 (UTC)Reply

Agree. In this case, the articles exist, and I would redirect them, as most of them have only one city. The issue is that one of them has more cities and would cause the region to have 18 cities, which is apparently too much. So then the question is - can that particular one be kept as a county (sub-region) while the others get redirected ? IonutBizau (talk) 14:37, 18 December 2014 (UTC)Reply

No, each level of the hierarchy must be completely subdivided or not subdivided at all. Partial subdivisions make for confusing data structures. 18 cities is a lot, but it's acceptable if there's no good way to subdivide the region. That said, there's usually a way to subdivide, especially at this level. Even if it's just "East Mutenia" and "West Mutenia"... or "Greater Bucharest" and "Outer Mutenia" or something like that. Powers ^(talk) 21:03, 18 December 2014 (UTC)Reply

So with Willamette Valley, sub-divide and have regions with no text or no subdivide and have long list of locations? --Traveler100 (talk) 21:32, 18 December 2014 (UTC)Reply

I would subdivide, under the assumption that there are many more destinations in the valley that simply don't have articles yet. The lack of text isn't a huge deal. In my experience, most U.S. states (that is, all but the very smallest) need two regional levels between the state level and the bottom destination level. Powers ^(talk) 01:09, 19 December 2014 (UTC)Reply