FindAGrave Template addition

Question

I would add parameter to FindAGrave template to define type of the link.

• {{FindAGrave|1234|relation=relative}}
  this links would be ignored by errors program.
• {{FindAGrave|1234|relation=profile}}
  this links would be used by errors program ignoring other links to FAG on this profile.

That is all. This parameter would not change the appearance of the template unless you want it to. It would only tell Error checking algorithm how to handle the link.

 

I am also not completely satisfied with texts (relation relative and profile) so if you have other suggestions,  Please let me know.

Comments

Final call: 

• {{FindAGrave|1234|sameas=yes}} 
  this links would be used by errors program ignoring other links to FAG on this profile.
• {{FindAGrave|1234|sameas=no}} 
  this links would be used by errors program ignoring other links to FAG on this profile.
• {{FindAGrave|1234|sameas=anything else}} or
  {{FindAGrave|1234}} 
  this links would be used by errors program if there is no yes link and if it is best match.

if no other suggestions are made, we will go with this.

---

This works for me.  Please make the template case-insensitive. That is, {{FindAGrave}}, {{Findagrave}}, {{findagrave}}, etc., ought to produce the same result.

---

It is not possible in WikiTree. Everything is Case sensitive on WikiTree except First letter of pages, that is always in uppercase.

But maybe EditBot can correct those, if there will be too many of them. On my end case is ignored, so it will be recognized correctly.

Interestng, https://www.wikitree.com/wiki/Special:Whatlinkshere/Template:Findagrave is used 7 times.

Does anybody know if redirect on Template:Findagrave to Template:FindAGrave would work?

---

The Puritan Great Migration template can be added with {{PGM}} or {{pgm}} or {{Puritan Great Migration}}.

I was unhappy when I added {{findagrave|48002839}} to a profile and got a redlink.

---

I assume that the aliases for {{Puritan Great Migration}} are created via redirects, but I can't verify that because I don't have edit access to the Template name space.

---

>> Does anybody know if redirect on Template:Findagrave to Template:FindAGrave would work?

Yes you can include other templates in one template see Template:SPC_Gen_Parish that includes 5 others...

but doing extra templates for all possible and impossible spelling versions feels wrong and unstructured....why not 

1. Have a naming standard of templates inside WikiTree (compare coding standards) ==> easier to read profile and more a feeling of quality.... compare profiles on both WeRelate and WikiTree. I feel WeRelate has more structure and is easier to read....
   1. Maybe add a short version {(F|12345}}
2.  Add Database Errors that check naming of templates... 
3. Check when saving that Templates on the profile exist and warn?!?!

Feels more important that the quality of sources start get documented in a structured way so other people understand how to use them and the weaknesses see Werelate Source:Find_A_Grave

To make it easier to use Templates

1. Get a standard for documenting templates with fixed headers I did a suggestion in 2015 see Category:SPC_Toolbox
2. In standard WIkimedia templates used on a page is displayed when editing compare categories see video ==> 
   1. much easier to see when you do preview what templates are used
   2. access the help page for the template... 

Example standard Wiki interface ==> you find direct if you have a problem or not when you do preview.... also used on category pages in WikiTree see edit Category:Söderala (X)

---

Thanks Ellen. Redirects work. I just have to check if inbound links also work.

I added a redirect on Findagrave. Findagrave and findagrave is the same for WikiTree.

I might add FAG, but that is another discussion. There is none at the moment.

---

Hm better checking when saving that you have templates that exist.... looks messy to support plus it looks more professional ==> a profile you dont trust... 

• Findagrave
• FindaGrave
• FindAgrave
• findaGrave
• findagrave
• .....

better work to get a style guide and create tools to support to make it easier to have a common style... I think one of the good things with Wikipedia and WeRelate is that a profile has a better look and feel because they try to create profiles with a common style guide...

---

I added 2 more variations, so we have:

• Findagrave
• FindaGrave
• FindAgrave

See Inbound links on https://www.wikitree.com/wiki/Template:FindAGrave

First letter's case is always ignored by WikiTree.

---

I use:

John was buried at [[:Category: Akron Cemetery, Akron, Colorado| Akron Cemetery]], Akron, Colorado. His [http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=41102239 memorial] has links to those of family members.<ref>[https://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=41102239 Find A Grave Memorial# 41102239 John J Dodge].</ref>

This is how I do it by copy paste because I am not a fast typist

---

I "cleaned"

• Findagrave
• FindAgrave
• FindaGrave

 

---

Thanks, but I think I will do this by the BOT for all templates with redirects.

---

......

---

So, just to be clear, if a profile includes a FindAGrave citation that is not their own memorial, the template should look like {{FindAGrave|1234|sameas=no}}.

If the link is to their own memorial it would be {{FindAGrave|1234|sameas=yes}} . Is this correct? And if the profile does not have its own memorial page, but they are listed on a relative's tombstone, the link would be {{FindAGrave|1234|sameas=no}}.

Do I have this right?

---

You understand correctly. 

Use of {{FindAGrave|1234|sameas=no}} is recommended, so I definitely don't link to the wrong profile. 

Use of {{FindAGrave|1234|sameas=yes}} is not necessary, since I successfully connect most of the profiles to the correct memorial based on data. But if you get error 572 or any other that was linked incorrectly, then you can help the program by using this. We are talking here only about few percent of the profiles.

BTW: It doesn't actually work yet, But will in a week or two. You can already use it.

Answer 1

how about primary for the FAG# that matches the wikitree-id being worked on?

secondary for everyone else.  i have seen profiles that include non-relatives

not having a relation= element defaults to profile, error only exists if a second FAG template present

Comments

Logic I envision is to completely ignore relation=relative links.  If there is one relation=profile link It is used. If there are more only those are added to a linking logic. If there is none, all links without parameter are added.

So if you add relation=profile to one link, all other are ignored. 

Primary/secudary sounds better, but name of the parameter is not ok.

relation=primary
relation=secondary

Maybe type or something better

type=primary
type=secondary

---

I don't like the terms "primary" and "secondary" in this context because those words identify an important attribute of a genealogical source, resulting in large potential for ambiguity.

Some findagrave profiles are considered primary sources because they include photos of a gravestone that is believed to have been erected near the time of death. Others are secondary sources (at best -- often they are probably about fifth-hand information) because there is no photo of a gravestone, and the source of the information may be something like a published genealogy.

---

Good point. Anyway I like yes/no/nothing variant better. I am just not sure about prameter name.

Answer 2

I would like to see the semantic sameas together with no to say that you don't have an Instance equivalence... ==> sameas=no

as a link from a person profile could go to a page describing the family then maybe add type of relation ==> sameas=no_relative

• Compare
  • owl:sameAs
  • schema.org sameAs
  • w3c sameAs

This should also be implemented on all external references that has personal profiles mixed with family pages....

• Template:Wikidata used on
• Template:SBL used on
• ......
  • Ancestry 
  • Encyclopedia Brittanica Property:P1417
  • GENI Property:P2600
  • Genealogics.org Property:P1819
  • The Library of Congress Name Authority File (NAF) Property:P244
  • WeRelateMe Property:P4159
  • .....

Comments

I needed to see capitalized version to understand sameas. 

This would be working solution with Yes and No.

sameas=yes
sameas=no

but SameAs is not intuitive. Maybe issame or issource or only source would be beter.

---

@Aleš for me it is ;-) ...... 

One thing that is odd implemented inside WikiTree and I think is good help for users is that you can see on a page what templates are used and then easy jump to the "help" page for the template.... I think this should be implemented also on profile pages IF WikItree starts using templates more

• It works on
  • Category pages ex. Söderala (X)
• but not profiles.....

See video

Answer 3

I'll admit that I like the longer expanded Family Search version of the citation, as it clearly states (without having to click on the link) several additional bits of data, such as name, date of death, and burial location including city, county, state, and cemetery name. I guess since I pull a lot of my sources from there, I'm a bit partial to their format, but at the same time, I like being efficient by having as much of my information all in one place at one time. I've actually had a few "helpful" people come to some of my profiles and remove the Family Search entry and replace it with the template already, which was a bit irritating as I lost this information from the profile when they did this. Granted, I can click on the link, hope it isn't dead, and get it back, but it's another potential weak link that could fail.

Comments

I think you should not compare this with citations for humans this part is more for making it machine readable ==> tools like Aleš Project Database can produce better quality....  

I can see a combination of machine readable and human readable ex. Memorial #181655852 John Heard

URL: https://new.findagrave.com/memorial/181655852

* Citation: Find A Grave, database and images (https://new.findagrave.com : accessed 16 August 2017), memorial page for John Heard (7 Mar 1946–21 Jul 2017), Find A Grave Memorial no. 181655852, ; Maintained by Find A Grave Unknown.
** {{FindAGrave|181655852|sameas=no}}

---

I'm more than OK with that approach - I've done the same with a direct link to F-A-G as well. I just want to make sure that ambitious implementers of the profile respect the profile manager's desire to retain existing information and not wholesale replace everything they see with their personal preference or template-only approaches.

---

I would recommend usage like this

* {{FindAGrave|181655852|sameas=no}} accessed 16 August 2017), memorial page for John Heard (7 Mar 1946–21 Jul 2017), Find A Grave Memorial no. 181655852, ; Maintained by Find A Grave Unknown.

Or for inline citations

<ref>{{FindAGrave|181655852|sameas=no}} accessed 16 August 2017), memorial page for John Heard (7 Mar 1946–21 Jul 2017), Find A Grave Memorial no. 181655852, ; Maintained by Find A Grave Unknown.</ref>

Note: Now also FindAGrave have citation text produced in preview of new version. When they will change it to the main site, it could also be added after template.

---

The problem is, that is you put this on wikitree (it has 3 links)

Find A Grave, database and images (https://new.findagrave.com : accessed 16 August 2017), memorial page for John P. Smith (1882–1969), Find A Grave Memorial no. 87199557, citing Forest Lawn Cemetery, Buffalo, Erie County, New York, USA ; Maintained by Jay Boone (contributor 46889203) .

You will get this as an output (2 links are lost since only text is copied)

Find A Grave, database and images (https://new.findagrave.com : accessed 16 August 2017), memorial page for John P. Smith (1882–1969), Find A Grave Memorial no. 87199557, citing Forest Lawn Cemetery, Buffalo, Erie County, New York, USA ; Maintained by Jay Boone (contributor 46889203) .

Maybe they will change the citation before production.

With template added and citation modified a bit

{{FindAGrave|87199557}} : accessed 16 August 2017), memorial page for John P. Smith (1882–1969), citing Forest Lawn Cemetery, Buffalo, Erie County, New York, USA ; Maintained by Jay Boone (contributor 46889203) .

you get

Find A Grave Memorial #87199557 : accessed 16 August 2017), memorial page for John P. Smith (1882–1969), citing Forest Lawn Cemetery, Buffalo, Erie County, New York, USA ; Maintained by Jay Boone (contributor 46889203) .

---

No with current Biography editor on WikiTree. I had an idea to write addon for Wikitree, where you would just paste URL of a source and it would create appropriate citation. But now WikiTree-X partially does that already. So it is way back on Todo List.

---

Perhaps one advantage, if the links were all driven by template, would be that we would only need to make the change in one place to repoint to the proper location. If we have to change millions of existing links out there individually, it will take a very long time to do. I would be hopeful that the memorial numbers wouldn't change.

---

That is the most important advantage of template. FindAGrave will change URL pretty soon. Old ones will still redirect to now ones, but you never know how long.

The number doesn't change unless they merge two memorials on FindAGrave. But we have an error for that.

---

I disagree with Scott. I don't like the citations that point to the Family Search FindAGrave Index instead of pointing directly to FndAGrave -- because (1) FamilySearch is not the source of the information and should not be identified as if it were and (2) linking to FamilySearch requires a person to go through several unnecessary steps to get from WikiTree to FindaGrave, through an interface that may not fully or accurately represent the information on Findagrave.

Regarding my second concern, when a person clicks on a link to a Family Search Find A Grave index page, they are presented with a page that contains a transcription (hopefully its accurate) of some of the data that was on a FindaGrave page at some time in the past (often there's a new photo or a correction since the Family Search transcription was made). To get to the FindaGrave page, they have to go to the second column on the FamilySearch page to the text that says

The image is viewable at findagrave.com. By clicking here you will be leaving FamilySearch.org. (fees and other terms may apply)

VISIT PARTNER SITE

Find A Grave Index

And they need to know (or have sufficient web savvy to discern) that the hyperlinks to "findagrave.com" and "VISIT PARTNER SITE" will take them to the findagrave memorial, but "Find A Grave Index" is useless because it takes them to a search page on FamilySearch. 

I have decent vision and I understand the Internet, and I am very annoyed by Family Search Find A Grave Index links. I can imagine that if I had limited vision and relied on a screen reader, I likely would be grumbling about the need for violent action against the WikiTreers who think they are doing me a favor when they present me with those links. We need to be considerate of users, folks!

---

I do, however, agree that citations to FindAGrave should not be limited to "Find A Grave Memorial #1234", which is what the template produces. More information is needed. If a template is used, the additional information can be added manually, but when a more complete formatted citation is provided by the website (as is true of the new findagrave), the template becomes an inconvenience.

Another concern I have with the template is my practical/aesthetic preference for hyperlinked text to identify the content the link points to. When I see "Find A Grave" as a text label on a hyperlink, I assume that the link points to the main page of findagrave.com. If the hyperlink points to a specific memorial, I think the linked text should be specific to the memorial, such as "Memorial #1234".  The hyperlinks in the source citations on newfindagrave.com conform to my ideas about standards for a hyperlink, but the WikiTree Findagrave template discussed here does not.

---

Instead of "Find A Grave Memorial #1234", the template should result in "Find A Grave Memorial #1234," where the underline identifies the text that should be hyperlinked to the findagrave memorial.

---

Ellen, That is a valid point. I corrected the template. The appearance can always be changed thanks to template. I just corrected  23.363 profiles.

---

FYI regarding template design...

On page Template:FindAGrave you have the link to G2G were things like this was discussed before....

WeRelateMe also a wiki for genealogy has created the following tools/pages for Find A Grave (just do edit and you can steal the code)

• Sources
  • Source:Find_A_Grave 
    • They explain the quality of the source and problems
    • Talk page where they discuss the source 
• Templates
  • Template:Fgravemem - for graves
  • Template:Fgravecem -  for cemeteries

 

---

I agree with all these points :) A link directly to the findagrave memorial is much better than a link to the FamilySearch index -- but, the advantage of the FS index citation is that it includes the key info about the person listed, and the cemetery.

I usually use the template and then add some additional info after it that lets the next person who comes along see at a glance what I was looking at. For example "Photo of gravestone for [list all people on it]" or (if no photo) "Memorial for..." in [cemetery] in [city/state].

Also thank you for the template update Ales! I agree with Emma on the link placement and the update looks great!

Answer 4

Aleš, while you're editing could you make the template accept whitespace around the pipes? Right now {{FindAGrave | 123}} doesn't work.

Comments

As far as I know, you can have anny nummber of spaces arrounnd the pipe.

Shoow me example.

---

My mother: https://www.wikitree.com/wiki/Groomer-35

Thanks for looking, you can test on her profile

---

I checked the documentation of Wiki and it is not possible.

It does work with named parameter, but not with numbered as used in this case.

This would work {{ FindAGrave |1 = 47196354 }}

This does not {{ FindAGrave | 47196354 }}

So don't use spaces with the number.

Maybe I can add error for such cases. I just prepared the error, if first parameter is not a number.

I could also let EditBOT correct all such cases.

---

When will EDITBot do most of the edits on Wikitree ;-) 

On wikipedia bots do 22% of the edits link (some Wikidata statistics 70% of the work is done by bots and 80% of items created is by bots)
 

---

And Bots are correcting each other.

---

I would love for EditBot to make that correction.

I'll leave my mom's link with the unwanted spaces so EditBot can fix it.

---

I will put it on To-do list for BOT. It will have to be corrected after weekly dump, since I can't check 20000+ profiles for parameter.

Answer 5

Maybe add parameters to support scenario

• when the WikiTree profile and the FindAgrave profile is the same person but the fact(s) at FindAGrave is wrong
  • No error created
  • Maybe easier to track profiles with a known problem at FindAGrave.....
• a request for a picture of the grave has been done at FindAGrave