Question of the Week: What's on your wishlist for 2021 WikiTree improvements? [closed]

Question

What's on your wishlist for 2021 WikiTree improvements?

Since this is the Question of the Week and not actual proposals, let's try to let people share their wishlist items without getting into too much discussion over them.

Thank you! :) 

Comments

This helps make my point that thing are not obvious or easy to find. I had no idea there was such a template.

---

Thanks Ian,

Took me a little self-educating to figure out how to do it but it works really well!

 - Dave

---

Agreed. Good suggestion.

---

This isn't a wish list item but rather a thank you to who ever added the "ID" "Link" and "URL" copy buttons to the profiles. Can't tell you how much easier that has made my documentations. Thank you!

---

A bit late sorry and quite a minor request, but it would be good to have a workaround to allow badges to be moved up and down on an iPad webkit browser in some way (not necessarily as smoothly as on a computer browser). See here.

---

What have y'all done to the Wiki Genealogy Feed Emails I receive?  All of the information is in small print and looks like a horrible run on sentence.  Can we go back to the way it was???

---

Have a way to check for words within profiles, such as indirect family names that are mentioned but may not have a profile yet.  Example:  Sibling name that has no profile but is mentioned within other profiles.

Also have an option to include the profile number (cator-80 for example) in trees, etc.

---

Donna, if you click on the "Search"-button in the "Find" -menu on the right top, the page opens to look for profiles. If you scroll down to the bottom, there is a field: "Search for any text". When you fill that field, the text you search for is looked for in any position of the profile, no matter if name field, data, location or in the biography text.

---

Knowing where all the Challenges are.  It would be nice if there was one location in addition to the others.  I might want to be in more than one challenge at same time regarding to a profile.

---

@Dave, age at death is now listed next to the death date. Thanks for the suggestion!

Answer 1

A differentiation between a Watchlist and a Trusted List - I would love to be able to be informed of changes to profiles (be on the watch list) without having to contact the Profile Manager and wait for them to approve. Trusted List would only be necessary for people to see and edit profiles for which the privacy level is set to less than Open.

Comments

I like the idea and also see it has potential downsides.  For example the age of 14 is too high for locations such as Scotland where females could marry at age 12.  Also, maybe it is just me, but I see value in having to have someone set it manually based on analysis of the person in question. Setting if for children ages 0 to 6 does make sense.

Answer 2

When adding a profile of someone who died young (say at 14 or younger), set the "has no spouse" and "no children" flags by default.

Answer 3

Besides implementation of the great ideas following the discussion of 'Year of Accuracy', my biggest wish is an extension to the database that allows linking sources (better said: their URI with unique identifier) to profiles. Or even better: the events therein.

Answer 4

Tie births to mothers instead of fathers so when polygamous fathers have many children born within a few months of each other, it doesn't trigger a warning message every time you make a change.

Answer 5

Have a [compare] type link next to X-DNA information on a profile.  It would allow the comparisons of two X chromosomes via GEDmatch.

Answer 6

A button to click that inserts the FindAGrave formatting code and you just put the memorial number.

Comments

I think we have that in WikiTree+...?

---

What's that?

---

This explains it better than I possibly could: https://www.wikitree.com/wiki/Help:WikiTree_Plus

* edit: Having said that, I don't see the information about the Chrome extension on that page.  The thing I said we have is on the Chrome extension: https://chrome.google.com/webstore/detail/wikitree%20/giodhdfeabddjnlhknbggojlgpnhanof

Good luck!

** edit 2: I think you're right. The features of the WikiTree+ extension are very useful and should be integrated into the main site.  

I take back my previous comment.

---

How does this relate to my suggestion ???

---

That I don't know, because I don't use Chrome.

But I've just created a bookmarklet that generated  FindAGrave template code, when you click it while being on a memorial page.

Feel free to copy the code from https://github.com/FlominatorTM/WikiTree/blob/master/Bookmarklet_FindAGrave.js to a bookmark in your browser (I only tested it with Firefox, but it should work with others as well). When you are now on a FindAGrave memorial and you click the bookmark, you will receive a popup from which you can copy the template code from.

---

Thanks! I will try that when back home on PC

---

Chris, it relates to your suggestion because with the WikiTree+ extension, there is a big list of templates to choose from.  You just put in the necessary information (for Find a Grave, the memorial number and maybe the 'sameas' part (to say if it's from that person's grave or if it's someone else's page)).  It's very useful (if you're on a PC).

---

Chris, do you have any feedback on the bookmarklet?

---

I cannot figure out what to do with the link you sent and the code to create a bookmark in Chrome as you said.  Not sure why as I am a tech type engineer but this is new to me.  Thanks

---

Hi Chris, the idea is as follows: create new bookmark and insert the whole source code from https://github.com/FlominatorTM/WikiTree/blob/master/Bookmarklet_FindAGrave.js to it (from "javascript:" until "(0);"). Then you put it in the bookmark bar (but you can probably also leave it in the bookmark menu). When you are on a find a grave page, click the bookmark and you should see an input dialog. If it doesn't work, please writee (can also write me directly), so we can figure this out.

Sorry for the delay

Answer 7

Compare Y haplogroups on a direct paternal line and flag when the first letter does not match e.g. R-M222 and I-Z59 would have a dull red warning such as  “Y haplogroup mismatch (i)” with “i” linking to an explanation that there is a error somewhere the direct paternal line.

Compare mtDNA haplogroups on a direct maternal line and flag when the first letter does not match e.g. H2a1 and T1b1 would have a dull red warning such as  “mtDNA haplogroup mismatch (i)” with “i” linking to an explanation that there is a error somewhere the direct maternal line.

Answer 8

Have the option for

Direct Paternal Line Relationship

https://www.wikitree.com/index.php?title=Special:Connection&action=connect&person1Name=Roberts-7085&person2Name=Roberts-7104&relation=4&ignoreIds=

To have the appearance of 

https://www.wikitree.com/index.php?title=Special:Relationship&action=calculate&person1_name=Roberts-7085&person2_name=Roberts-7104

And 

Direct Maternal Line Relationship

https://www.wikitree.com/index.php?title=Special:Connection&action=connect&person1Name=Roberts-7085&person2Name=O%27Conner-89&relation=0&ignoreIds=

Have the appearance of 

https://www.wikitree.com/index.php?title=Special:Relationship&action=calculate&person1_name=Roberts-7085&person2_name=O%27Conner-89

Have that relationship show up in the url so it can be saved and shared.

Answer 9

When comparing two male or more male Y-DNA testees who belong to the same direct paternal line then have the default show their direct paternal line relationship(s) back to their most recent direct paternal line ancestor (not their closest relationship).

When comparing two or more mtDNA testees who belong to the same direct maternal line then have the default show their direct maternal line relationship(s) back to their most recent direct maternal line ancestor (not their closest relationship).

Answer 10

A pretty simple one in concept (and may already be there): Search just within my tree alone. Sometimes i have another source to add and know the person, but navigating back 5 or 6 generations by following the tree, it's like, "Which grgrgrparent branch is this person on again?".

Comments

Yes, it's already there.  You know the two little boxes at the top of a profile page? (not G2G).  Right underneath them is another box which has 'Name on Watchlist' inside it.

---

Who woulda thunk that's what "Name on Watchlist" meant? But it works just like i asked for. Thanks mucho!

---

Technically, thats not the same thing. If you arent on the trusted list or the PM then that ancestor might not be on your watchlist. I think "search within my ancestors only" is still an interesting idea.

Answer 11

To remove the middle name field and have one field for all given names instead.

Together with this the preferred name field should become optional. No value for a person with multiple given names simply means that you don't know which of these names was their preferred name, which is a very common situation that now most of the time isn't shown properly in Wikitree.

Profiles that now have given name field A and a non-empty middle name field B should get A+B as given names and A as preferred name. No information at all is lost, but for the rest of the world it means we get rid of a constant problem.

Answer 12

My wish is a simple one - to have a little box to click on for "no spouse" next to "add spouse",  the same as for adding children.

Wishing you all a peaceful Christmas.

Comments

There is now a checkbox for this :)

Answer 13

I would like to see an official Help page listing all the unofficial help pages created by WikiTree members.  The list could be listed in the Help index under "U."  I would volunteer to help set it up.

Answer 14

In Wiki Geneaology Feed show first the target last name, then first/initial, then the Wikiperson who performed the action and the action. This would make it vastly easier to visually search the last names I follow. For email format, show it as a list (like in the app) so I can just scroll fast down the list. I have stopped following these emails because it's too long to visually filter to what I care about.

Answer 15

I wish I could open Dynamic Tree (surname) in one fell swoop.

Answer 16

When on the edit person page a simple checkbox for never married, like the 'no children' one, rather than having to go to add spouse (opening a new tab) and then down to unmarried. That's all a bit of a faff when adding someone who died age 3.

Comments

There is now a checkbox for this.

---

Thank you!

---

YEAH! Thank you

Answer 17

I wish for key fields to include baptism date and location.

Comments

See here what the team says about it. 

Answer 18

The biggest change I hope will be implemented one day is multilingual (french being my first choice) in the main pages.

It is almost useless to have help pages in something other then english, if they are not linked from main pages also translated.

Until this is done, I can not really encourage french native to get it a try and that's a pity.

Comments

The help pages can be translated rather easily... if you would like to help: contact the France project, I am sure they will appreciate the help . For the menu items and navigation: yes that would be a great improvement!

---

I know. I already contributed a little bit. But useless without translation of the main pages.

If I sell WikiTree to a french speaking person, and this person finds the home page untranslated, he.she will stop here.

---

Bernard, you are asking for the General pages of WikiTree to have multiple language translations not just those related to a specific project?   Does something like Google Translate do a decent enough job?  What if translate this web page link was added to all pages?

---

Laura, yes Google Translate does a pretty good job, and a button to translate the page could be a second solution.

But I would recommend this one only on a system which is already statically translated in case that particular page is not yet done.

In general, all pages should have the possibility to switch to a different language than english, and then keep that information from page to page.

Have a look at https://cgsavoie.fr the home page of the association for which I act as webmaster, and choose another language thru the flag icon.

It's far from perfect, in particular it's time consuming to keep up with dynamic information, but at least the skeleton should be understandable.

---

Hi Bernard,  I selected English flag and it changed the menu options but not the content on the page.  I then tried using Google Translate through Chrome Browser and it translated the menu and the page contents.  So in my test the use of a link for Google Translate worked better from a technical stand point.  I do however think anytime a more precise translation can be rendered it is preferable.  But that is also much more time consuming and labor intensive.  

My thinking is add a link now to all pages.  That is a quicker fast way to deploy language options.  Then identify the pages most often used and translate the ones with more importance first.  Kind of doing both versions in tandem.

---

Hi Laura,

Sorry for the delay (pretty busy with these Merry... and Happy...).

You said "it changed the menu options but not the content on the page.". On certain pages, the ratio between translated vs untranslated is better, but as I said "far from perfect" ;-)

Your proposal might be best in the short term, but I really urge to find something that doesn't need to be toggled on EACH page viewed. In my previous example, if you go to another page after having switched to english, you will be in english for all the pages on the site until your next visit.

---

Understood... I minored in Elf...  Have a long tradition of holiday projects. Back to this language issue...

I guess the years I spent working internationally have given me a view of multi language use and when it works and when it doesn't work as well.  

It is always better when you have people who understand both languages working on communications.  So you don't end up with diced pigs when trying to explain spam...  (actual example)...  or stubborn cows when talking about milk persistency which is a cow's ability to continue to give milk (also a real life example)...    

but for most normal communications Google Translate does a pretty good job and it is less labor intensive.  I think WikiTree might consider a hybrid.   For now drop the link on pages.  But identify pages that should get a human translation and set up a priority for those pages that warrant it.

---

With a full multi language website you could do much more. eg: set specific terms for fields like prefix and middle name; show the specific help pages first; make it interact with the language field in the edit page; select posts in G2G with specific languages....

With modern software this is not to hard to achieve, but with WikiTree I am not sure. The programmer should explain probably how much  work it is and the owner if the intention is really there.

---

I had a try with automatic translation from english to french.

With Firefox, which is my preferred browser, it's useless.

But with Chrome it's not so bad, although it doesn't take too much in consideration variation in style, and sometimes the result is a little bit difficult to understand.

---

A bit late, but a big +1 for internationalisation of the interface. Since I joined in spring 2019, I have tried to bring in many French people, close or far-off cosuins most of them, and have some connected to The Tree, but most of them had no further activity, or a very symbolic one, although some of them are very active genealogists otherwise, mainly on Geneanet. I think if the interface was simpler, people would do with english, but language barrier is just the extra hurdle which keeps them off.

Answer 19

Simple idea, have 2 last name fields for women (or more) to allow searching on multiple names, could be tied to a date to limit number? So a search for Mary (Smith) Jones would show those with both Smith and Jones (either might get large) but would be ok if limited to a date.

Answer 20

I would like to see Suggested Matches filtered better geographically so the list for common surnames isn't so long.  If the birthplace or deathplace is filled in and the tickbox for "certain" ticked in both cases, then there is no reason a William Jones born in Utah should be suggested as a match for a William Jones born in Wales.

Comments

YES PLEASE. I’ve been working through Tonkin, Tresise, and Rowe families in St Just in Penwith, Cornwall and this would solve my nightmare of crawling through search results to find the ones from the right place. Because they’re everywhere in Cornwall.

---

The problem with this is that people enter place names in too many varied ways. Maybe at some point we will be able to figure out how to differentiate places without missing valid matches in a way that won't significantly slow down the time it takes to show the match list.

---

We already have place name suggestions when we type place names in, and we have Ales' new WikiTree+ Map Navigator and the option of getting suggestions about place names in our watch list which it can't parse.  I don't see why we can't insist on standardized formatting of place names just as we have standardized formatting of dates in the date fields.

---

Place names can often be politically divisive (e.g. Northern Ireland, United Kingdom) so no, that looks like a non-starter.

---

Place names can be politically divisive yes, though since we are doing collaborative genealogy we do in practice have to end up with one version of each place name in each location field, and whatever version of the name gets put there is not going to please someone if there's controversy about that place.  But surely there aren't so very many hotly controversial place names that we couldn't have a system where two alternative versions of the name were acceptable to use in place fields, without permitting the sort of things that would really make it impossible to compare place names automatically - like town names with no region or country following them.

---

I think we could find we have overstretched ourselves if we become too prescriptive and the end result will be that we drive people away. Whilst many places will need a country to be comprehensible, there are others, London, New York, Paris and most US states which stand on their own two feet. Whilst it is desirable to include a country, any system must be able to pick out major cities etc. as well as a country. Perhaps we need a system that is able to highlight profiles which have one location in common be it town, city, county, state, country. That hopefully would sort out your William Jones born in Wales, Utah or Timbuktu.

I would go on to add that we do need to pare down the number of matches where the name is nothing like that input, so perhaps the system needs to work on a maximum of one letter different which would sort out some less than appropriate suggestions.

No system will ever be perfect so maybe we just have to try to design one which picks out 99% of the potential matches.

---

I agree no system will ever be perfect, and certainly the last thing I want to do is drive anyone away by making entering place names more onerous or annoying.  My concern is that people are probably already being put off WikiTree by these long lists of implausible match suggestions, and I agree with you that many of the name suggestions are also highly unlikely to match.  Any reasonable solution that reduced the implausible matches would be fine by me.