Create categories from Wikipedia and Find a Grave using WikiTree BEE

Question

Starting with v.32.14.5 the browser extension WikiTree BEE now allows you to create categories based on data from other websites. It will extract the data from the website and popuplate the template code in a new browser tab with the category. In case I wrote this too complicated, Sandy made a video on how to use it on Find A Grave. BEE is available for Firefox, Chrome and its relatives, but not for Apple platforms. Check out my bookmarklets in case you're stuck on those.

Currently supported websites/use cases:

• US location categories from English Wikipedia (so far still counties instead of parishes for Louisiana, sorry)
• German location categories from German Wikipedia
• Italian location categories from Italian Wikipedia
• Multi language categories for the area affected by the Treaty of Trianon in the former Kingdom of Hungary (currently in Serbia, Romania and Hungary)
• Basic location category code containing Wikidata and coordinates for basically any other Wikipedia article in any language containing this data
• Basic location category code containing coordiates from node entries at Open Street Map (those with coordinates on them, when you click the search results)
• Cemetery categories from Find a Grave (extensively tested in the US, other countries might need improvements; with options to create US Black Heritage cemetery categories and to automatically search for BillionGraves id as well)

Please remember that "with great power comes great resposibility"! Make sure, you check what got generateed there, before actually saving the category.

I hope these will help you and your projects. If you need country specific optimizations or additions, feel free to reach out to me (can also reply here), but be aware that although the actual implementation usually is not a lot of effort, it might take some time until will have time, patience and motivation. Hint: Offering to help with testing might shorten this time significantly

Update 6 Sep 2023: The upcoming preview version will also support English cemeteries from Find a Grave (including historical counties)

Comments

The current preview version 32.14.7.1 now properly supports England cemeteries. Cemetery categories in Scotland and location categories for Poland are work in progress.

Also it writes in the edit summary that the category was created by BEE and reviewed before saving.

---

The current preview version 32.14.7.2 supports Polish location categories and contains better parent categories for cemeteries in Scotland and Poland.

---

sorry, but this is bad news in fact, few users of this BEE feature will think to check the language and / or  the specific categorization guidellines for my part of the world.

---

@Danielle: Feel free to reach out to me with some good category examples, so we can collaborate to make BEE  work better for your part of the world.

---

Space page for Québec categorization over time gives you an overview.  There are 2 parent categories for each.  Please leave it alone, CIBs give before and after, it's not a simple one-two item.

---

The page you gave is about location categories. In BEE those are only available from Wikipedia for projects who explicitly wanted them and helped develop the ruleset. So far Canada is not one of them, so there won't be any location category creation at the moment.

For the Find a Grave cemeteries in Canada I just implemented a ruleset to meet the cemetery category structure for the individual provinces (including the additional location category for New Brunswick and Quebec). It will be available in BEE Preview soon.

---

oh dear, cemeteries are an absolute pain here, the vast majority are named after a saint, have worked on sorting some of the early creations by city, it's a bit of a nightmare as in French, the terminology starts ''Cimetière de...''  So everything wound up under C.

---

Might be an idea to pipe the city name?

---

that's what I did for the bunch that had been created previously, with no profiles.  But it's a long involved process to keep track of these things and see that they are also under both parent category streams (FR & EN)

---

I have four relatives that where buried in a small cemetery in a small town in Württemberg.  How do I address this situation and how would the citation read?  There is nothing on Wikipedia for this town.  The name of the town is Indelhausen which is part of Hayingen.

---

Danielle, I plan to address sorting of French cemeteries in BEE, see https://www.wikitree.com/g2g/1658640/category-infobox-cemetery-more-sorting-parameters-please

Answer 1

It will likely take me a day or two to check it out and get back here, but I am super excited to try this out.

Follow up pending ....

Comments

wonderful!  TY

---

OMG!!!!!

That is so amazing and awesome!!! I did see that it is a must to check it over, nothing major but still good to check anyway!!

I will definitely use this much more in the future.

Thank you so very much!!!

---

Happy you like it. Is that "nothing major" something general I should look into or was it some isolated case?

---

Nothing to worry about checking. Thank you for asking though.

Answer 2

That works so well, thank you very much.  There is a change I need to make to Location.  I generally use the town and province instead of the county and province in that field as I like to have the cemeteries sorted between towns. It creates a town category where one doesn't exist and that needs editing but that's easy to do.   Maybe that isn't standard but it seems to be where I am.  My main focus is Westmorland County, New Brunswick.

I just did Bermuda last week manually.

Comments

I believe, we have that already: In the settings you can choose if you want town or county as lowest level. Town will only be used, if a town category exists. Else it's county automatically.

---

Thanks, I just checked the settings, town is selected already, county is still populating the field.

---

Hi Stu. Can you give me an example to test?

---

Try https://www.findagrave.com/cemetery/2319451

The town is Port Elgin.

---

Thanks. I'll take a look later.

---

Thanks Ian.  This is the category for Port Elgin. https://www.wikitree.com/wiki/Category:Port_Elgin%2C_New_Brunswick

It's otherwise complete.

---

Counties don't work.  You need to go to town levels.  I have at least 3 cemeteries named Pioneer Cemetery within Westmorland County.  If you don't give the town name, it's meaningless.

Do we talk about the category name or the location parameter in the template? How would it properly look for https://www.findagrave.com/cemetery/2319451 ?

---

The category name is working as expected, it's just the location field that wasn't using the town.  

Here's another Port Elgin cemetery:

https://www.wikitree.com/wiki/Category:Saint_James_Presbyterian_Church_Cemetery_Old%2C_Port_Elgin%2C_New_Brunswick

---

So: if I change in the BEE settings page the option "use town or county" to "town", then it will create https://www.wikitree.com/wiki/Category:Saint_James_Presbyterian_Church_Cemetery_Old,_Port_Elgin,_New_Brunswick exactly how the way it is right now.

If I switch back to "county" location will be "Westmorland County, New Brunswick".

Only if there is no category for the town existent, it will use the county anyway, regardless of the setting.

So far, I think, I didn't get the problem.

---

There is a category for the town though.  Anyway, it's not a big issue.  The category name seems to work.  If you set the toggle to County, does that address Steve's concern?

---

We're very sorry. That was a bug in the Chrome version, that was fixed with the latest release v.32.14.6 from a few hours ago. Can you please check again?

Answer 3

Thank you so much Flo! What a time saver. And thanks for reminding us, Spider Man style, that we still need to do our homework. That's my favorite part anyway!

Comments

I agree Erin!  In fact, I think I am more precise because instead of spending time focusing on the my spelling, from manual entry, I am focusing on the correctness of the FG data/location.

Answer 4

Thank you for work on this.

However, there appears to be a major issue with this implementation. The Cemeterist Project does not use Find A Grave Names or Locations for cemeteries. By using the Find A Grave name and location data, this could introduce thousands of categories that are duplicates which need to be merged and/or renamed to fit the correct naming guidelines.

In the example provided for East Union Presbyterian Cemetery, the correct category name would be:

East Union Presbyterian Cemetery, Indiana County, Pennsylvania

Taylorsville is a Populated Place and is not valid for locations of cemeteries. Here are the guidelines for creating cemetery categories: Space:Cemetery Categorization.

On behalf of the Cemeterist and Categorization projects, I would please ask that this feature be removed/disabled until we can work on the finer details.

Comments

The same applies to the next example, Bethel Cemetery.

---

Counties don't work.  You need to go to town levels.  I have at least 3 cemeteries named Pioneer Cemetery within Westmorland County.  If you don't give the town name, it's meaningless.

---

Stu, in the examples above - those were not towns/cities - they were populated places.

Categorization is a complex topic, and I while I applaud the efforts, the extension is not adhering to the guidelines established. In your case, you have had to make judgement calls on handle similar names cemeteries - an extension cannot do that.

---

I agree that judgement is required but if the method used is providing the 99% solution, which I think it is, then the exceptions can be dealt with individually.   Or we can keep doing what we were doing and progress will slow back to where it was.

---

IMHO, the Cem needs a specific reference and cardinal direction and distance from the closest town, if not in a town.

County only, far, far, far, too vague.  Baker county that I drove through yesterday has 3,068.36 sq. mi. Where I live, the county is 1,870.32 sq. miles, the one I grew up in has 4,553 sq. mi., Harney has over 10,000 sq. miles.  We don't have counties out here that are not much larger than a town's quadrant.  One has to have a solution that fits all favors, not just the abnormally high density populated places like one has on the East Coast.

County is certainly a *far* too liberal category for sure, I'd never be able to locate it, and in reality, the physical location is absolutely the most important part.

So, if you want to say where it is, use like the closest town, and either compass rose cardinals, or degrees, and distance.  If you say 3.1 miles NNE of Scotts Mills, OR, I have a general idea, as the crow flies, roughly where to go look for it.

Otherwise just skip the whole location thing, as otherwise it is mostly pointless.

---

Hi Doug, did you check out the guidelines posted above? Using the County is not a general rule for all cemetery categories - just the ones in which do lay within the boundaries of a city / town. So anything within a populated place, census designated place, etc. would be listed at the County Level.

It just so happens that both examples provided in the video were not in a city / town - which means they fall into the County scenario. This is what alerted me to the problem of using an extension to generate data here based on another website (which does not follow the same guidelines).

---

Knowing how often Find a Grave gets the names of cemeteries in England wrong, I share the concern that this will lead to the creation of duplicate categories, and support the request for the automatic creation of cemetery categories feature to be removed.

---

Man, I hate to do it, but I agree with Steven Harris on this based on WikiTree's cemetery category naming guidelines. I live in a very large county with only two very small cities, so most cemeteries in this county are not in a city or town. I just checked Find A Grave and the cemetery across the road from my home was put inside a city on Find A Grave when it is definitely not in the city--it is in the county. (It is not yet on WikiTree.) I looked at the list of other cemeteries in this county on Find A Grave and found that many were placed in cities or towns which do not actually exist as incorporated places but are only communities or "populated places." So if I use the data from Find A Grave to create these cemetery categories, most of them would have the wrong category names. Not many cemetery categories from the county where I live have been created on WikiTree.

I did use the extension to create a cemetery category today and it worked great, as far as I can tell. And I think the cemetery category name automatically created was okay because that cemetery was located in an incorporated city, as far as I can tell. It is often hard sometimes to tell where city or town boundaries are so, for that reason, I have not felt very comfortable making cemetery categories.

Update: I just looked at the list of cemetery categories for my county in WikiTree and some of them are already incorrectly named. By the way, I used to work for the county as the Chief Voter Registrar and one of my tasks involved locating where people lived in the county and/or in the cities.

Examples:

1. Cartecay United Methodist Church Cemetery was placed in the town of Cartecay--no such town.

2. Cherry Log Baptist Church Old Cemetery was placed in the town of Cherry Log which is not an incorporated city or town.

3. Flat Creek Baptist Church Cemetery was placed in the town of Webb. I've never even heard of that as even an unincorporated place.

4. Yukon Cemetery was placed in the town of Ellijay when it is outside the city limits of Ellijay 

There are others. I'd have to dig further to see whether these errors originated with Find A Grave, but I suspect they may have.

---

To address the fear of duplicate categories, starting with v.32.14.6 (out now for Chrome, might take a few hours for Firefox), BEE will show a warning, if there already is a category using the same cemetery ID from Find a Grave.

Also the manual now contains a passage that explicitly links to the cemetery guidelines. It also points at the upcoming "rename" and "copy & rename" functions in the Category Management feature in WBE, which will make it super easy to create a new category and to request EditBOT having moved the profiles. Category management will also bring a Batch Categorize function, that will make it actually fun to move a few profiles from one category to another. So as much as I understand the need to stick to the rules, I don't consider the problem that heavy.

---

Thanks Florian, that is certainly a step in the right direction.

However, I am still not sure this satisfies the needs. Even with a link to the guidelines, this has the potential to create hundreds or thousands of incorrect categories that members of the Cemeterist, Categorization, and other affected projects have to work through. While you may not see that as a heavy problem, it certainly is a major concern for me.

And this is only my review for Find A Grave. I haven't even tackled how the extension works for Wikipedia - whose naming also does not typically conform to our guidelines (they are encyclopedic, we are not).

---

While I understand the City vs County discussion as well as unincorporated communities/towns/locations (I have a lot of those in my ancestry) needs to be better understood, I am confused why this extension is getting so much heat.

Whether I create a Cemetery Category manually (as previously) or by using this new extension option, the result, for me, is the same:  It is up to me to confirm accuracy and make changes when required. 

Isn't it suppose to be the person creating (any) Category (manually or via an extension) to double check for accuracy of location/name?  In my mind, this extension option allows me more time to research to confirm everything up before saving.

---

And to support our fellow cemetery category creators, start with v.32.14.8, BEE now places links to OpenStreetMap on Find a Grave cemetery pages. With those, you can either have the location of the cemetery shown in OpenStreetMap or query OpenStreetMap for the entities, the cemetery is part of (e.g. if it is actually in town or not).

Answer 5

Thank you so much, Flo! This is so time saving, even after your helpful bookmarklet.

I tested the Italian categories, but as Flo wrote, please make sure you look over every category content before you save. If you see weird things happening, please don't save and message me the Wikipedia page.

Also: make sure you only create location categories if you place the category in a fitting profile afterwards. So, first have a profile that needs this category.

Answer 6

Fabulous!  I cannot wait to try this!

Answer 7

This feature is going to cause problems for the England Project. The EP uses location categories based on the historic counties, rather than the modern administrative units of local government which is what Find A Grave uses.

We already have a category for the very large and famous Brompton Cemetery in West Brompton, which was once in Middlesex. https://www.wikitree.com/wiki/Category:Brompton_Cemetery%2C_London

If someone didn't check that there was an existing category, they would try to create a new category from the Find a Grave link https://www.findagrave.com/cemetery/658429/brompton-cemetery and they would succeed, but it would give it the wrong names and also create a tier of higher level categories for places which don't exist. I can see this causing a lot of work for the EP categorisation team, as the duplicate categories would be created over and over by this method.

I've also checked churchyards and cemeteries outside London, and the same problem exists. (St Mary's churchyard, Docking, Norfolk for instance https://www.findagrave.com/cemetery/2504738/st.-mary-the-virgin-churchyard which already has a populated category on WT https://www.wikitree.com/wiki/Category:St_Mary_the_Virgin_Churchyard%2C_Docking%2C_Norfolk )  

Can we please have this facility blocked on English cemeteries please until a solution is found?

Edit 6 September: Thank you Florian for working with the England Cat team to get this issue sorted out. We now have no concerns with the way that Bee extracts the information from Find A Grave for English cemeteries. But we would ask everyone creating a new category with this facility to check that Find A Grave has its facts right to start with (name of cemetery, location etc) and make any edits accordingly at the creation stage. The examples I used in my original answer above now come out flawlessly.

Comments

I recently set up a category for St Cuthbert's Churchyard, North Meols, Merseyside: https://www.wikitree.com/wiki/Category:St_Cuthbert%27s_Churchyard%2C_North_Meols%2C_Merseyside

Find a Grave calls it "St Cuthberts Churchyard, Southport, Metropolitan Borough of Sefton, Merseyside". So not only is the name wrong, the location is too. Because the England Project uses the historic counties for location categories, the correct location is "North Meols, Lancashire".

Relying on the information on Find a Grave is going to result in many errors which will take the England Project more time to sort out than if we had been asked to set up the categories manually as at present.

---

Ian Beacall has let me know that changes have been made to the code since I posted, and you now get a warning box if you try to create a cemetery category with the same Findagrave ID. This helpfully has a link to the correct category. Click the Bee to see what you now get for Brompton Cemetery: https://www.findagrave.com/cemetery/658429/brompton-cemetery

This is definitely an improvement for categories which have already been created. Thanks Florian and Ian. I still have concerns though that the England Project cat team will be mopping up wrongly created categories when people ignore the red writing because they don't understand what it means. 

Please, if you need a category located in England, drop us a message in G2G using the "request a new category or advice" link that you will see next to the Edit Text box on the edit page of any profile, or if you are in the England Project, via the Categorisation channel in the England server.

Cheers, Jo, England Project Cat Team

Edit: The WT category link was too long for G2G to process, so I replaced it with the Findagrave link

---

Thanks to the collaboration between the England Project Cat Team and Florian and Ian, we have now come to a point where this system is workable. Thank you Florian and Ian.

All English cemeteries categories which have a presence on FindAGrave now have the FG code added to their Category Information Box. This prompts Bee to display a warning box if anyone tries to create another category with the same FG code, and takes them to the existing category.

Anyone can request a manual set-up of a cemetery category from the England Cat Team if the "red writing" in the Bee category set-up concerns them. This facility already exists via the help link to G2G, and via the England Discord Channel.

For the few that slip through the net and are set up via Bee with incorrect higher level categories, these can be mopped up by the England Cat team.

Jo, on behalf of the England Project Categorisation Team

---

The next release of WikiTree BEE Preview will use historical county categories for the location parameter of English cemeteries.

---

Thank you Flo. You have done amazing work to resolve the concerns we in the England Project initially had on this facility. All seems to be working very well now!

We have clarified the England Project guidance on naming cemetery categories in England: https://www.wikitree.com/wiki/Space:Categorisation_in_England#Cemeteries

Answer 8

When I click on the BEE in Chrome, I get a dialog box next to the bee icon with the below info instead of the WikiTree category page.  Am I doing something wrong?

*Burial:  Find a Grave, database and images (https://www.findagrave.com/memorial/199668167/charles-c-campbell: accessed 31 August 2023), memorial page for Charles C. Campbell (19 May 1863–10 Mar 1954), {{FindAGrave|199668167}}, citing Oak Park Cemetery, New Castle, Lawrence County, Pennsylvania, USA; Maintained by Paul Myers (contributor 49962849).

Death:

Comments

Yes, you need to go on a cemetery page, rather than an individual memorial.

---

Correct.  I need to pay more attention to the video.  However, when I added the category for the cemetery where Mershimer-1 is buried, it doesn't appear on the profile.  The edit page shows that it is there and the Changes page show the change but there is no "Category" box on the profile as shown in the video.  This is my first attempt to add a category.

---

What you did here looks good and I see the category at the bottom.

---

Also be aware that the category box is not shown in preview, but only after actually saving the profile.

---

Are you sure the category is named correctly and has the correct location parent category? If the location is Shenango Township, shouldn't it be named "Mershimer Family Cemetery, Shenango Township, Lawrence County, Pennsylvania" with the location parent as "Shenango Township, Lawrence County, Pennsylvania" ? Like this one and this one and this one ??

---

Thanks, Paul.  I didn't know that BEE would create the correct citation for Find a Grave.  That will help me out a lot!  I can just copy the citation from there.

Answer 9

How long does it take for a newly created category to get onto the WT category database? I created this one over 2 hours ago, https://www.wikitree.com/wiki/Category:Rippleside_Cemetery%2C_Barking%2C_Essex_%28London%29  and Bee is still not finding it as a duplicate when I try to create a category from this  https://www.findagrave.com/cemetery/1987143/rippleside-cemetery

I also added the FG ID to an old category https://www.wikitree.com/wiki/Category:Barking_Friends_Burial_Ground%2C_Barking%2C_Essex and Bee isn't finding that as a duplicate when I try to create a category from https://www.findagrave.com/cemetery/1723636/quaker-burial-ground?

Comments

Jo, your new category is showing up in the category picker tool in edit on a profile, I just tried it and it was there. It generally only takes a few minutes for that to happen. I wonder why the BEE isn't finding it??

---

For the duplicate check, BEE relies on WT+ data, that is only updated every few days.

---

Thanks Florian. It's useful to know that there is a significant time lag where duplicates might potentially be created. Do you know when in the week WT+ is updated? Is it a set time and day?

---

I think there is no schedule to rely on, because it's often triggered manually. The url https://plus.wikitree.com/DataDates.json shows two dates regarding the last update of WT+. The categoriesDate only refers to the results, when searching for the profiles within a category, if I got it correctly, so I assume, it should be the other one.

---

"For the duplicate check, BEE relies on WT+ data, that is only updated every few days."

Another reason not to let apps create categories.

Answer 10

Thanks Florian...I've been making a few categories lately and I noticed it's only giving me the city and state.   I thought we did it like city, county, state?   

My new cat:

[[Category:Mock Cemetery, Damascus, Virginia]]

I was expecting:

[[Category:Mock Cemetery, Damascus, Washington, Virginia]]

Am I ok to use my new cat?

Thank you!

Melissa

Comments

It seems that in Virginia, the standard way is County, State (https://www.wikitree.com/wiki/Category:Virginia%2C_Cemeteries).  There is an option in the BEE settings to make them either Town, State, or County, State.  I'm pretty sure that Town, County, State is non-standard.

---

I'd also saw that it fits pretty well to the other categories at Category: Washington County, Virginia, Cemeteries

---

The standard way for locations in the US is city/town, state. The county only gets added if

*the location is a township when it's not a municipality. This covers ALMOST all townships in the US, except in a few places like PA, NJ, and charter townships in MI. Example:[[Category:Monroe Township, Adams County, Indiana]]; [[Category:Harding Township, New Jersey]]

*there are repeated places with the same name within a state. So, if two or more communites are named, say, Richmond, you would use the county in the category name to distinguish both of them by adding the county. WikiTree has MANY places like this for US locations. [[Category:Spring Valley, San Diego County, California]] [[Category:Spring Valley, Lake County, California]].

Answer 11

I am in love!  I'm going back through all my family and adding cemetery locations to their profiles.  Also checking all unsourced that I need to updated.

Answer 12

Florian did I ask my question in the wrong place?

Rolf

Comments

I have four relatives that where buried in a small cemetery in a small town in Württemberg. How do I address this situation and how would the citation read? There is nothing on Wikipedia for this town. The name of the town is Indelhausen which is part of Hayingen.

No, I'm just slow ...

I assume, we're talking about a location category or about a cemetery category?

You can get a basic category info box with BEE from OpenStreetMap probably. Then you would need to add the non existent category to one profile by hand, click save anyway and then follow the red link and paste the code BEE shows you (in case there are coordinates on the left side after you search for the place in OSM). I can also create the category at one point, when I'm at the PC at one point.

---

Florian, when you find some time can you check to see if I did this correctly.

https://www.wikitree.com/wiki/Category:Friedhof_Indelhausen%2C_Hayingen%2C_Baden-W%C3%BCrttemberg

---

I did some improvements:

https://www.wikitree.com/index.php?title=Category:Friedhof_Indelhausen%2C_Hayingen%2C_Baden-W%C3%BCrttemberg&action=history

I also created categories for Hayingen and Indelhausen

---

Thanks for the update.  Having not lived in Germany for very many years, would I enter a family member in Find a Grave even if they have been exhumed?

---

That question I've been asking myself over and over again, same with cemetery categories over here.

Answer 13

I am absolutely APPALLED at the idea of an app using Find A Grave (!!!) to automatically create cemetery categories in France. Most Find A Grave French cemeteries appear to be made by people who know nothing of France, and their formatting of locations is nothing like the system we use for geographic categories in France (and indeed, not at all the way we recommend populating location fields on profile).

I also strongly object to the automatic creation of "Basic location category code containing Wikidata and coordinates for basically any other Wikipedia article"  and "Basic location category code containing coordiates from node entries at Open Street Map".

All 3 of these features would lead to (well-meaning, I do not doubt that) contributors with no knowledge of the French language or of French conventions on WikiTree to create French categories and this is a recipe for disaster.

Apologies if this sounds too harsh, but this is the way I feel and I'm shocked that I never, ever heard of this until now.

Comments

Would you mind taking at least a look at the two latter ones, before declaring them entirely useless?

---

Where did I write "entirely useless"? I suppose they're fine... for areas the majority of WikiTree contributors are familiar with. Which does not include an odd, backwards and exotic country like France.

---

Florian, I don't think you understand what Isabelle is saying. She's not saying Wikipedia/Open Street Map/Wikidata or anything else is useless itself, she is very worried about this feature leading to people creating WT categories for countries they know nothing about (our main worry is for France, of course, since it's the Project we're a part of and the one she Leads) and those will probably not follow the guidelines of the Project, or even the basic format of how locations are identified in France at all.

---

If either one of you would have looked at the features you're discussing here, you might have discovered, that they don't contain anything country specific, which was exactly why I implemented them this way.

So, I think, I'm understanding pretty well: you're building yourself an opinion without even bothering to look at it.

---

Florian, it not being country specific is exactly the problem. I literally gave this a try just now and it's exactly what I was worried about. Here is what it gave me:

{{CategoryInfoBox Cemetery

|name= Cimetière de St-Marcellin-en-Forez

|address= 157 Chemin De Rodillon, 42680 Saint-Marcellin-en-Forez, France

|parent= Departement de la Loire, Rhône-Alpes

|location= Departement de la Loire, Rhône-Alpes

|findagraveID= 2788485

|coordinate= 

|startdate= 

|enddate= 

}}

The parent and location here should be Loire, France.

Category names do not contain "Departement de", because firstly if it did it would be "Département de" (accents are not optional in French) and secondly it would be like adding "State of California" instead of just "California" to US locations. We, as a Project, chose not to use régions in category names (here, Rhône-Alpes) because those were only relevant since the 1980s and even changed in 2016 (for instance, Rhône-Alpes was paired up with Auvergne and is now Auvergne-Rhône-Alpes) and they're not necessary to identify a département anyway.

 So this will absolutely lead to a disaster if it becomes more wildly used, just like Isabelle was saying.

---

To be perfectly precise, what we would expect in this particular case, would be "Saint-Marcellin-en-Forez, Loire" as Location and "Loire, Cimetières" as Parent. (with "Loire, Cemeteries" as second parent, actually, because our cemetery categories are mostly used by contributors who want categories for the Military cemeteries American or Commonwealth soldiers are buried in).

Provided, of course, Saint-Marcellin-en-Forez is really a current commune and the cemetery is really on its territory (the last point being probably always correct in the case of a communal cemetery; much more likley to be wrong in the case of a CWGC cemetery for example).

---

I was not talking about cemeteries, I was talking about Wikipedia and OpenStreetMap (the latter two). But thanks for trying that one out as well and sorry for me being so short in my reply.

The cemeteries are not configured for France and will for sure need some country-specific optimizations. I'm also looking into doing something like for Wikipedia and Open Street Map if the country is not configured, but that might take some time.

---

(edited comment above to reflect that we have a bilingual cemetery hierarchy for France)

---

That said, I would love to see if we could also make this work for French cemeteries, because I believe it can't be worse than Canada. Feel free to reach out via email/Discord to discuss the details and to be equipped with prototypes.

---

Pardon my being so dumb, but as far as I can see it is very possible to go to Find A Grave and create a category for a cemetery in France.

As for Wikipedia, I could not see what is preventing anyone for creating a location category for something that isn't a location (or more precisely, not a location that should be categorized). I mean it looks possible to  got to Wikipedia and create a "Location" CIB for something that is not a municipality/commune (our landing units for location categories).

---

I didn't say you were dumb and I'm sorry that this discussion got a bit emotionally.

What I wanted to say, is that I'm perfectly aware that Find a Grave will need some modifications for France (like for every other country as well, which is why I state that at every occasion and invite the local projects to help me out with specs, insight and testing).

Thanks for also trying out Wikipedia. Of course, one can create "wrong" categories from there with basic information like coordinates and a WikidataId - exactly like one can create "wrong" categories without any tool support. It is the responsibility of the projects (and the people who want to prevent such categories) to teach their fellow WikiTreers about it.

---

Léa, I wrote you an email. Since it contains some weird {{ characters, I just wanted to make sure it doesn't end up in your spam filter ... at least not for technical reasons

---

Thank you Florian, new version of the feature works fine!

Now let's only hope there is not too much wrong info on FG that will get imported here...

Answer 14

My understanding was that BEE was supposed to give inexperienced category creators the ability to create cemetery categories using only potentially incorrect data from Find A Grave. That was bad enough.

Now we know that it also gives those same inexperienced category creators the ability to easily overwrite an existing category's data with FG data generated by BEE, or create a duplicate, if the name BEE generates is different to the existing category's name. 

This happens because the message saying "this could be a duplicate", is also accompanied by an edit box which, if saved, will either overwrite the existing category data (If the category name is the same) or create a duplicate (if the FG name is different to the existing one's name). 

The inexperienced category creator probably thinks they are doing the right thing by saving the edit page.

Is there a logical reason to have an edit page along with the message saying there is already a category with that FG ID, surely a link to the existing category is sufficient?

This is already happening, existing categories ARE being overwritten by BEE users. It will get worse as more countries are added.
 

I just created a duplicate category for a cemetery in England, as easily as saving the page. The message asked me if I was creating a duplicate, but I couldn't be could I, the cemetery names are different?? I'm talking about someone who is inexperienced with categories and category creation and thinks this BEE is helping them do it.

Please consider changing this feature and removing the edit box, (with potentially conflicting information to that which already exists), just have the message and the link to the existing category. If the category does need some parts editing, it can be done from the category page. Overwriting ALL the existing information shouldn't be made easy to do.

Comments

Jim,
I admire Florian's work to make it easier for everyone to create categories with a standard format with CIB.
I do not support removing Australian categories from BEE coverage.

The sticking point in my view is the ease with which a pre-existing category can be overwritten with a poor replacement. A warning is not sufficient.

---

There's an option that will let BEE automatically open a tab and google for the cemetery on Billion Graves. Upcoming is also recognition of "Commonwealth" in the description, that will do the same for CWGC.

---

Steve, it's Margaret that needs to be convinced, not me, because it's she and other Australia Project members who'll have to clean up if the app makes mistakes.

That said, if I'm reading the earlier discussion correctly, some objections from other projects to the automated method have been overcome by improvements to the code. It's possible that with careful discussion and cooperation that can happen for Australia as well.

But that spirit of cooperation is not helped by slowness to remove the overwrite capability, which has widely been recognised as unnecessary and dangerous. Fixing that quickly should be the next step. Florian: please respond seriously on what you propose to do about this particular issue.

---

Jim, I was busy implementing a solution, which Ian is uploading to the stores as I'm writing this, which I considered more important than writing prose here. Additionally I was emotionally quite affected by the whole discussion and didn't want to write anything impolite.

Editing existing categories is no longer possible with the new version 32.14.9(.0). People who were using it by purpose and need another solution, should please report on this G2G post.

Like Scott said, the Australia modifications are an improvement, instead of using the default configuration (as described on our space page). Therefor those will be integrated in the new version 32.14.9(.0) as well. Please reach out, if further improvements are needed, preferably via Discord.

---

Thanks Florian. I thought I had seen it search for BillionGraves before, but it didn't today. I suspect I had that option turned on in the production version, but had failed to turn it on in the preview release. I'll try again.

@Jim - I deliberately did no make any changes to the generated category to see how it worked on a cemetery that has correct information on FG. There are still quite a few cemeteries on the WikiTree+ "Missing Cemeteries" report, and using the BEE to prefill the information was far quicker this morning than using a blank form or the CIB template editor. As I expected it to fail, I checked everything extra carefully and the only "fail" was that the cemetery is not yet on OpenStreetMap, and Google StreetView is 15 years old without the new sign, so I thought it had opened to the wrong place.

I've added BillionGraves, Australian Cemeteries Index and Wakefield Regional Council links now, which would need to be added (if required) no matter which method was used.

---

Thank you for the removal of the capability to edit existing categories, Florian. I'll leave it to Margaret to comment on the other points. If the discussion moves to Discord, I hope someone will summarise here. G2G is the forum of record for public WikiTree discussions, whereas Discord is opaque and transient.

---

Stable version live in Chrome and Firefox.

---

@Florian, I see the Australian modifications are now live in this new version, despite asking both you and Ian for that not to be the case. Also the option for adding "Australia" as a project parameter is still available in the options despite me asking for that to be removed. Well, so much for collaboration and cooperation with the project and it's leadership. Perhaps it only works if they agree with you?

@Steve, @Scott, the Australian modifications work fine IF (as you and I do), you know and understand that FG data for Australian cemeteries is not always correct, the location is not always correct, the coordinates are not always correct, and that you need to check all those things. In line with the Cemeterist project guidelines, we use the current name the cemetery is known by, often that's not the same as FG's name. A lot of times it is but not always. 

This was the concern of our project leadership, that we would be making it easy for inexperienced category creators to just create cemeteries using the raw FG data and nothing else, no aka, no afilliations, no space page, no web page, because they aren't aware those parameters exist on a cemetery CIB. It's already happening in the US, with categories being created by members who have never created any before, with incorrect names and data.

And no, I don't believe they've been doing them manually up to now, these are the members who ask for categories on G2G, on our request page, who now could think, maybe they could do it themselves with BEE. Up to now, there is really only us who have been creating cemetery categories.

I do not have access to the daily category feed to check new category creations. The editing function on the navigate page will become more important. I am pleased that the last couple of days of G2G angst have brought about a result. It's annoying we had to do it, it should never have been like that in the first place.

@Jim, rest assured we will still be providing our category creation service via the request page. I know you get around on G2G, so if you happen to see a request for an Australian category I haven't seen, drop me a comment on my page! 
 

---

Thank you, Margaret. As you'll know I'm quite a heavy user of your Australian category creation service for cemeteries, and I really appreciate not having to worry about the fine details myself. I'll try to watch out for requests to point your way as you suggest.

---

Thanks Jim!