Template parameters as attributes

Question

I have noticed certain profiles where people are using the auto-categorization features of the extension to continually change the cemetery category to an incorrect location on some of the profiles that I manage.

My initial attempt to prevent this was to add a comment at the top, so that editors would leave the cemetery category off. But since it's mostly automated, they ignore that.

My next attempt is to add "sameas=no" to the Find a Grave template. I am hoping that when the next WT+ reports run, those profiles don't show back up in the cemetery report as missing the cemetery category. (I don't really like using sameas=no when it really is the correct memorial, but it's the only hack I can think of to solve this if the manager of the Find a Grave memorial isn't going to correct the cemetery location.)

I'm not sure what the status of the HTML redesign is, but it would be very helpful to extension developers if the HTML that is rendered on the profiles had attributes to reflect some of those parameters like sameas=no that we can't see from the rendered HTML.

For example, the <a> link for the Find a Grave template could have something like <a href="..." itemprop="findagrave" data-sameas="no"> so that when we are parsing HTML, we could have visibility on that parameter.

Taking that a step further, it would be really nice to not have to do so much auto-detection of the text inside HTML elements, which is currently necessary to make features like Readability Options work.

If WT could take advantage of tags like itemprop and/or data-* attributes for template parameters, it would make extension development much easier in the future. It sort of works with CSS classes today, but it's not structured enough to make the WBE code stand up to future changes in the HTML.

Answer 1

I'm not sure if I fully grasp what your saying so forgive me if I go awry. But your talking about two different things Categorization and source references.

The preference is that each profile would be categorize to show the cemetery they are buried. So someone is going to come along and attempte to add the correct categorization at some point given we are a collaborative process.

So the best choice would be to add the proper cemetery category.

The referencing "sameas=no" in the Findagrave source reference is for those times when you are listing a reference to an other family member and you don't want the system to generate warnings that the birth, death dates, etc don't match.

Comments

Yes, the cemetery categorization was my initial example for this suggestion, but it could apply to many other templates as well. I have suggested the tagging of elements to make life easier on WBE developers in the past, but I think it's on the back burner until the site redesign happens.

The cemetery situation that I am referring to is one where the burial location on Find a Grave is actually incorrect (the manager has guessed the location might be in a certain cemetery, but documentation from other family members states that they were buried on their private homestead, and I don't control the Find a Grave profile).

Admittedly, sameas=no is not the ideal solution to this edge case. If the parameter were called "ignore" instead of "sameas" then it would be clearer, as the main intent of the sameas parameter, as stated in the documentation, is that it "helps define the correct memorial page for usage in WikiTree+ hints."

When developing WBE, we only have access to the rendered HTML on the profile you're currently viewing (unless we make a separate API call and force the user to be logged in). It doesn't pass along any of the metadata from those template parameters so that they can be consumed.

So, for example, if somebody makes a feature for WBE to highlight the FamilySearch and Find a Grave links for the person in a toolbar at the side or top, it can't detect whether that Find a Grave link was entered as a plain URL in the bio, whether it was generated by the {FindAGrave} template, or whether the sameas parameter was set. So in the example you used, where one profile uses the Find a Grave memorial of a family member as a source, or links directly to the Find a Grave memorial for a relative who doesn't currently have a profile on WikiTree, WBE might show the wrong link to the user.

This, of course, still would depend on editors using templates instead of direct links to external sites.

So, the request is to have that data in any HTML elements rendered by a template, and in addition, for the structural elements on the page to be more clearly tagged so that features like Readability Options don't require code like this to detect the various components of the profile page.

This could include many items, such as:

• linked people, spaces, categories, etc.
• bio sections like Biography, Sources, DNA, etc.
• various icons, buttons, navigation
• source list items generated by <ref>
• and many others queried here