WeRelate talk:ToDo List

Discuss ToDo list items here.

Gedcom download [19 December 2008]

Hi Dallan,

My highest priority is the capability to download a gedcom; where is that on the list? It is too time consuming to enter my research data for a one name study in my genie program and WeRelate so all of my recent research is only on WeRelate.

I have been through several downers with genie programs; Generations was nixed and FTL was nixed as well; hopefully WeRelate is not another downer. I love WeRelate and the concept but am just a teeny bit concerned about retrieving my data and also the inability to send another researcher a report or gedcom which I could do if one could download a gedcom.

If this is not a priority, I will have to reconsider entering more data on WeRelate. I will happily help with the site but can't afford to waste time entering data that I have no way to retrieve.--Beth 20:16, 8 December 2008 (EST)

Don't worry - it's a high priority. GEDCOM export, re-upload, and merge-during-upload are all near the very top of the list.--Dallan 18:16, 19 December 2008 (EST)

Several little things that would be helpful [16 March 2009]

After clicking 'prepare to merge', the next window is too wide. You have to scroll right, to see the merge button.

When I hit 'prepare to merge' but I've forgotton to check the merge box at the top of the page, the next window tell me 'unable to merge'. When I use the back button the msg is 'Webpage has expired'. I'm determined so click the back button again and I get the compare screen again. A nice feature would be to have something on that 'unable to merge' page giving the option to revert to previous screen without losing all the typed info in the compare windows; OR to start a new search with a clean compare window. If I'm telling it to prepare to merge anyway, why do those buttons at the top of the page even have to be there?

Could we have a option in the preferences to use the enter key as a tab key for moving to the next window?

If there wasn't so much empty space on the compare page between 'compare pages to merge' and 'compare families" then there would be more room to see 'compare people' without having to scroll down.--Janiejac 00:23, 12 March 2009 (EDT)

The upcoming version of the compare screen will prompt you to check the boxes before you leave the compare screen. That should solve this problem. The reason that the checkboxes have to be there are in case you have multiple possible families on the compare screen - you can select which of them to merge.

I'm reluctant to change the definition of the 'enter' key. When you change how common keys behave it can confuse people.

I agree that there's too much room in the title area (for all pages in fact). I need to reduce the size of this area.--Dallan 23:15, 16 March 2009 (EDT)

Tree vs Register [23 January 2010]

Dallan, I know there is a place to discuss data entry design - so is there a place to discuss FTE? I am increasingly frustrated at not being able to invite folks to view a register so they can get an overall picture of the family in question. FTE is NOT a place where a newbie can come look at a whole family tree! I never use it for many reasons. There's no point in rehersing all it's problems. I think I read you were planning to redo it so I've been wanting to suggest a whole different idea to be used in the area that FTE now uses.

Would it be possible to replace FTE with a register like what is now seen on rootsweb?? When I do a search at rootsweb I get what you'd call a family page. But I follow that by clicking on 'Register' as the register gives the whole tree (starting with the searched name) not just a family page. It is a better picture of whether it has anything of interest and also it gives an idea of how careful the rootsweb author has been. I can see at a glance if any of the children have married persons I'm interested in without doing a separate search. It is just a good way to see a tree at a glance and if that were in place instead of FTE, I would expect then to click on a person in that tree and the regular person page would come up beside it.

I did try the FTE the other day and tried to look at the index. The names were indexed by FIRST names, not surnames, and had the (#) beside the name which is of NO help at all. I would need the birth-death dates to know if it was someone I wanted to look at. The (#) may help the program but it is of no help to me when I see 5 different Williams with (#) and I don't know which one to look at. Dates would help me decide which on to look at.

So I sort of assume there will be a place for discussion of the FTE when it comes time to redo it. I just wanted to get the idea of replacing it with a register on your mind. It would certainly give newbies a look they are already familiar with. And that would be a big plus!! --Janiejac 01:39, 15 July 2009 (EDT)

I'm trying to understand what you mean. I clicked on "Register" on a few pages at WorldConnect and got back a few generations of descendants, but I didn't get back the entire tree.

What I'm thinking of is replacing the current FTE with an "ancestor and descendants" view (like you currently get with the FTE but full-screen) available from any Person or Family page by clicking a button. You could extend the view to show more generations of ancestors and descendants, and clicking on anyone would bring up their Person page in a new tab. The view would not be limited to display just people in a particular tree, but would display anyone who is related to the person/family in question.--Dallan 11:56, 16 July 2009 (EDT)

Dallan,

The registry on Rootsweb is akin to a family narrative report. I believe Rootsweb/WorldConnect displays up to and including six generations.

I wouldn't advocate for the removal of the tree concept (although admittedly, I NEVER use FTE), but I would support Janie's request for something approaching a more useful way of displaying the family "registry". I think I've brought this up elswhere, but I think the registry (one generation at a time) would make a good replacement for the FAMILY page.

It would also be nice to display-- like you do a pedigree-- a descendants list. Two versions: a) simple outline and b) a more register/narrative format ala Janie's request.

jillaine 14:31, 16 July 2009 (EDT)

Dallan, Here a link to a tree I posted on rootsweb. This link takes you to their equivalent of the family page; it has the history, his wife and their children. http://wc.rootsweb.ancestry.com/cgi-bin/igm.cgi?op=GET&db=davidjax&id=I1
If you click on register you will get all David Jackson's family and descendants. You will not get ancestors because David is earliest known person of this line.

But if you had searched for James M. Jackson, a later descendant of David's, you would have been taken to his family page and when you clicked on register it would have looked like this:

1. James M. JACKSON (Josiah C. JACKSON2, David JACKSON1) was born 3 Mar 1857 in Overton Co., TN, and died 18 Aug 1931 in Overton Co., Tennessee. . .etc.
and the view just clicks on Josiah (David's father) to go back up the tree, or clicks on David to go to the earliest known ancestor.
http://wc.rootsweb.ancestry.com/cgi-bin/igm.cgi?op=REG&db=davidjax&id=I55

Thanks for listening and considering this. I just want to stress that seeing something familiar looking will be a big plus to newbies and would eliminate a large piece of the learning curve to use this site.

I concur with Janie that seeing something familiar with go a long way to attracting and retaining new audiences. jillaine 15:29, 16 July 2009 (EDT)

P.S. I've never noticed a limit on the number of generations displayed by rootsweb registers, except that each author can limit how many generations can be downloaded. --Janiejac 15:25, 16 July 2009 (EDT)

Thank-you for the links. I agree that more familiar charts would be helpful. I'll think about how to incorporate these.--Dallan 12:59, 18 July 2009 (EDT)

I think I'm probably in the minority on FTE. I use it, really, for only one thing: When I've imported a new GEDCOM, I spend some time with FTE in list mode (not the multicolored tree diagram thingy -- sorry), opening and cleaning up each page in turn. I don't really care, for this process, whether the list is sorted by first name or last name, I just want to be able to work my way down the list without missing anything. Yes, I could choose "view" instead of "launch FTE" -- but FTE allows me to bookmark a page so I can quit for a while and come back later to the same spot. --Mike 16:36, 23 January 2010 (EST)

I still don't use FTE at all! And you can tell from comments above, having a register instead of FTE is about #3 on my priority list so that's pretty high.--Janiejac 16:53, 23 January 2010 (EST)

adding person/family pages with red links [30 January 2010]

I do not agree with adding person/family pages for the red links. I suggest sending the user a notice that the non-existent page will be deleted in one week if the user does not create the page.I probably have some red links on my pages and a reminder would be helpful. Creating pages from the red links will result in more "empty" pages with no information.--Beth 18:53, 6 January 2010 (EST)

Good point.--Dallan 19:16, 12 January 2010 (EST)

Is there a way to even know if I have pages that have red links on them? Jillaine 21:43, 12 January 2010 (EST)

I can't think of a way.--Dallan 10:57, 13 January 2010 (EST)

I have a ton of these from back when we had to hand enter. I never got around to actually editing all the children pages, for example. They are now lost to me, but they still convey valuable information. Does "what links here" work for red links? Like if I want to know why there's no John Szopas (1), and it's because there's a red link somewhere, can I find that? I suspect not because this happens all the time where I find (1) families that aren't deleted but don't seem to have any data either.--Amelia 12:45, 23 January 2010 (EST)

What links here does work for red links. If you enter http://www.werelate.org/w/index.php?title=Special:Whatlinkshere&target=Person%3AJohn_Souza_(1) in the URL line of the browser you would see a list of pages (if any) with red links to this missing page.--Dallan 13:09, 30 January 2010 (EST)

voting [30 January 2010]

It is a little hard to vote. There are so many items listed, many of which I have not followed so don't understand. Also, others may have prerequisites that make voting for them meaningless unless the prerequisite is done. Others may be part of a whole, especially with a redesign of the pages going on. Still others may be doable or not based on scheduling and timeframe issues. So, in summary, I am guessing that there might be a small subset that are really likely to be affected by the outcome of a vote, and then some number where voting will be immaterial. Could the first set be put into a poll? --Jrich 12:00, 23 January 2010 (EST)

If we disagree that you should be putting any effort into doing something, do you want us to express that? Some of these things on the "high priority" list seem pretty insignificant compared to things much, much further down.--Amelia 12:47, 23 January 2010 (EST)

Do we get to chose just ONE item? Hard choices when there are so many! But thanks for letting us have a vote! --Janiejac 16:47, 23 January 2010 (EST)

Vote on what's most important to you. I'm planning to look at all the votes, figure out how much time it will take to implement the most-voted-on features, which will include the time necessary to implement the pre-requisites, and then start implementing features that will cover the most most votes with the least amount of development time.

One of the big reasons for the voting is to help me re-order what goes in high priority, medium priority, and low priority sections. Once the high-priority items are complete, I'd like to take WeRelate out of "beta" status.

You can vote on multiple items. If you vote on just one item, I'll "weight" your vote higher than if you voted on say 5 items.--Dallan 13:09, 30 January 2010 (EST)

So many (me included) are voting on items which will improve the WeRelate site, but my highest priority is one which will enable me to get uploaded in the first place! After I get uploaded I can worry over what will make it easier. But I don't feel it would be right for me to upload my large data base and expect others to clean up the family history text for me. I have over 20,000 folks to upload (branch at a time) with lots of formatting that will go in family history window and I know that I'll not get around to retyping those notes to put in all the line breaks and tabs!! Uploading now and creating a mess in the family history, then trying to upload again later when the problem is fixed would be a merging mess I am trying to avoid by just waiting for the line breaks and tab problem to be fixed. --Janiejac 14:48, 30 January 2010 (EST)

Format notes [5 March 2010]

Discussion copied from primary page

This is not just a nice-to-have item; for me it is a deal breaker. I have so much formatting in my notes which will go into the family history text window, that lack of ability to retain the formatting is keeping me from uploading my main database at all. It is large and I certainly cannot reformat all the notes. So the work is not even uploaded and won't be until this gets implemented. I cannot see me having the ability the reformat all the notes; so I'm waiting for this to be fixed. Also I see this as a great deterent to newbie retention. Once they see what WeRelate does to their notes, they may not be back! So for my vote this is highest priority. Other functions will be good once I get the data base uploaded, but until then they are not important to me. A lot of these other functions will be great to have and I'll vote for them, but get me online first please! I'm surprised no one else has voted for this one!!--Janiejac 09:32, 29 January 2010 (EST)

I will add what I think is my own version of this question: is there a reason why the <PRE> tag from HTML is not supported? I think I read somewhere that most HTML tags are supported except this one. It seems like a harmless tag, and it would accomplish most of this, wouldn't it? Even <nowiki> doesn't honor user line breaks and you have to stick in a bunch of <BR> which is a big pain. --Jrich 11:26, 29 January 2010 (EST)

The issue is that notes coming from some GEDCOM files don't have any line breaks, while in others line breaks and spacing are very important. If I display all notes inside PRE tags (I used to do this), then the ones without line breaks don't get wrapped and they display on one line extending far to the right. Ideally displaying the note would obey user-entered line breaks and wrap if no line breaks were entered. I think the best way to do this is to convert user-entered line breaks to BR tags when displaying notes.

Here's a question: How important is it to preserve spacing? If I'm to preserve spacing in notes so that you can have columns line up from one line to the next, as in

Then I have to display all notes in monospace font like the above. Is this an acceptable cost so that line-spacing can be preserved? This same note in a "normal" font looks like the following. Note that the columns don't line up very well anymore.

Rather than displaying all notes in monospace font, I could say that if you want your note to use monospace font then you must surround your note with a PRE tag. That's another possibility.--Dallan 16:05, 30 January 2010 (EST)

Help:Formatting#Unusable_HTML_tags: The following tags should not be used in wiki pages: pre Tag <pre> </pre>. So are you going to add the PRE tag? As I recall (my HTML is rusty), this uses user supplied line break instead of treating a newline as whitespace and was often used, for example, to display software code on a web page. To get a fixed width font, you can also use <TT></TT>, but the line break control was the real benefit of PRE. I am not sure you can do what janiejac wants, which is to have her home-grown formatting work exactly like it does in her genealogy software, but there are times, like dumping a list of records, a family's entry in the census, gravestones, etc., that you might want to preserve the original line breaks. And it will get her most of the way to what it sounds like she is asking for. --Jrich 18:03, 30 January 2010 (EST)

I think having PRE tags work is a separate feature request. I'll add PRE tag support regardless of how we deal with notes. Removing support for PRE tags was a (failed) attempt to better support notes. But I would like to figure out how to handle user-specified line breaks and spacing in notes. It seems to me that the best way to handle user-specified line breaks in notes to to display them as BR tags. The next question is whether we need to display all notes in monospace font (which I think is ugly) in order to preserve spacing within lines (so columns in multiple lines line up), or if it's ok to require that people use TT and/or PRE tags to preserve spacing within lines.--Dallan 22:10, 30 January 2010 (EST)

Copied from elsewhere on page: my highest priority is one which will enable me to get uploaded in the first place! I don't feel it would be right for me to upload my large data base and expect others to clean up the family history text. I have over 20,000 folks to upload (branch at a time) with lots of formatting that will go in family history window and I know that I'll not get around to retyping those notes to put in all the line breaks!! Uploading now and creating a mess in the family history, then trying to upload again later when the problem is fixed would be a merging mess I am trying to avoid by just waiting for the line breaks problem to be fixed.

Thank you all for addressing this issue. I did not know what it would take to get the line breaks. That is probably the most important and I can live without the monospace font. As for the tags PRE and TT, I'm not even familiar with them. You're talking to a gr-grandma genealogist here and I'm hoping you can make things simple enough for folks like me to enjoy the site. --Janiejac 01:13, 31 January 2010 (EST)

--

Janie, I am guessing a little about what it is exactly that you need, so correct me if I am wrong. If I am right, it is unlikely that you will be able to get just what you want. As I read it, you have 20000 people, but your notes don't get formatted right when you import them into WeRelate, and you want to import your pages without having to edit all your notes. Perhaps, following WeRelate rules would even cause problems with some other process, like how you share your data with collaborators outside of WeRelate?

I am guessing your notes are basically text files, with really long lines which your computer conveniently wraps to fit on your screen, but one line per paragraph. WeRelate, of course, uses the HTML model that allows the input to be formatted however is convenient, and then requires that you add explicit paragraph control. One of the ways to do this is to leave a blank line between paragraphs (or the HTML tag <P>), which will signal WeRelate to start a new paragraph. I am guessing even this simple step would require you to edit your notes. My suggestion of the PRE tag probably wouldn't even help, now that I think about it, because it turns off all line wrapping, and even modest paragraphs would go off the right side of the page and just keep going and going.

I am guessing your use of tabs is for aligning data. This also requires using a fixed-width font (monospace). Now, I doubt all WeRelate users would be happy to have fixed width fonts as the rule, as it is much less pretty, so switching to a fixed-width font when to aligndata into columns is inevitably going to require the insertion of some kind of formatting command, like <TT> where you want it to start, and </TT> where you want it to stop. Again, probably no answer that doesn't involve you changing your notes. Then, there is the issue of defining where tabstops should go, which really should depend on the type of computer that the page is being viewed on rather than the type of computer it is being written on. So this is hard to find a universally acceptable answer for. Normally in HTML people line up data using TABLEs. This involves adding a lot of tags to your notes.

If your notes were HTML there is some possibility that they could be imported without much changes, because the Wiki software has its roots in HTML, and so supports most HTML functionality. Otherwise, bottom line, you are hoping that the style you have used at home to format your notes can be used without change in WeRelate. Since you are only one user out of thousands, that is probably not going to happen. What could happen possibly, if you had access to someone with programming knowledge, is to write some kind of a filter that would scan your GEDCOM file and add the extra tags before your file gets sent to WeRelate. If your notes at home religiously followed a small number of clear formatting patterns, such an intermediate step might be able to do the right thing most of the time, but if your formatting has much variability to it, it may create more problems than it solves. --Jrich 11:18, 31 January 2010 (EST)

Janie, I wonder if you could give us an example of some of the formatting in your gedcom? You could even email me a small sample if you like; I'd like to see the problem you are talking about. I did a small test using RootsMagic 4, one person whose notes included bold, italics, and underlines. When I exported from RootsMagic, it gave me a choice to check a box to keep "note formatting (bold, etc)." This is how the page imported into WR: Person:Test Van Unknown (1) (note, I am going to delete this example in a few weeks). RootsMagic put in the HTML tags required ( <B> <U> and <I>). I'm not entirely sure if it would help with the line spacing issue on your particular gedcom, but it would be interesting to test. --Jennifer (JBS66) 11:43, 31 January 2010 (EST)

Example: here is Person:Josiah Jackson (1) a person page that I've previously uploaded and haven't got around to adding the line breaks. So you can see how the census transcriptions look like w/o line breaks and then check the edit page to see that there was some kind of spacing when it was uploaded, but it sure didn't retain the spacing because the text is scattered all about.

It isn't too bad to go back and fix a few of these types of pages but I've got hundreds of such pages. I like to put the transcriptions in the notes (vs just citing them) because I get a better picture of the changes in the family over the years. At this point, I'll do whatever you folks suggest. I think it looks terribly hard to read and compare when all run together, but if that's what has to happen, so be it. If it looks so bad you don't want it at all, that's OK too. I guess it's late and I'm tired. P.S. I use PAF and it won't even take html in the notes. PAF has a LOT of users so eventually this will need to be dealt with if at all possible. Sounds like it may not be possible. --Janiejac 02:05, 1 February 2010 (EST)

Janie, I had initially prepared a response to your situation above here in this subject thread, but since it is more related solely to your problem and not to the overall conversation, I am going to move the response to your talk page. --BobC 10:58, 10 February 2010 (EST)

A suggestion: How feasible would it be to provide two or more options on upload of a GEDCOM? One option would use the formating currently applied (proportional font, word wrapping) while another would use fixed-width font and retain all existing line breaks. A user could test a few records and see which option works best for them - which would depend on the software they are using and what they have done with their notes. There wouldn't be a need to try to identify all variations now - just offer two options, and if another need comes up in the future, address it then.--DataAnalyst 10:18, 7 February 2010 (EST)

This seems like the best solution. I could put these options (insert TT tags around notes, insert BR tags at the end of each note line) in the GEDCOM review program, so people could see what their notes would look like with the options checked vs. unchecked before finalizing the import. Thank-you for suggesting it.--Dallan 17:41, 14 February 2010 (EST)--Dallan 11:45, 5 March 2010 (EST)

GEDCOM upload maintains child order [5 March 2010]

Discussion copied from main page

I still (as discussed on other pages) think this is a bad idea because people will order them in different ways (their ancestor first might be common, the way they were discovered by the researcher, etc.), and a reader may or may not be able to determine the ordering that results (and of course, want to rationalize it to their own preferred system, causing a war). I get annoyed at birthless children being sorted out of order but the answer is as simple as estimating a birth date. Side effect: it also helps to have something/anything show up for a birth date in search results so you at least know the century that John Smith page pertains to. As long as you include a note saying the estimated date is a guess to preserve known or suspected birth order, people will realize what it is. --Jrich 10:57, 7 February 2010 (EST)

I should have clarified - maintain child order in the absence of either birth or christening dates. Obviously, if dates are available, they should be used (and both birth and christening, but not baptism, dates should be used). I have mixed feelings about estimating dates, particularly when you could be out by a few decades. It is useful in searching, but can lead to false confidence in the dates. I guess I prefer using 'about' if there is some reason to believe a date is reasonably accurate (e.g., based on age at death), and 'estimated' when it is a guess based on 30 years per generation. But I have seen many people use 'about' just to have a date, sometimes leading other researchers astray. --DataAnalyst 11:59, 7 February 2010 (EST)--Dallan 11:46, 5 March 2010 (EST)

Automatically remove characters from name fields [9 March 2010]

The request is to automatically remove characters such as #, ?, (), --, [], etc from name fields.

What about ()'s? What should we do if someone enters a name of "John Smith (Smythe)"? It seems better to keep the parentheses than to remove them in this case?--Dallan 12:02, 5 March 2010 (EST)

Entering a name like that causes multiple problems, Dallan, because as you know WR records the surname as "Smith (Smythe)" and carries that new 'surname' to the associated Surname in Place article, Surname page and Category page under "Smith (Smythe)" rather than as "Smith" and then another entry as "Smythe," which would be correct entered more appropriately as an alternate name (or vice-versa). --BobC 13:00, 5 March 2010 (EST)

I know; the problem is what do I do about such names in uploaded gedcoms. If I simply remove ()'s then the name becomes "Smith Smythe", which doesn't solve the problem and seems to make things even worse. It seems that if we're going to do this, then I need to move parenthesized names to alt-names in gedcom uploads.

FYI: There are names in Dutch that include an apostrophe, such as 't Zand. --Jennifer (JBS66) 15:40, 5 March 2010 (EST)

I presume a single hyphen (-) would be acceptable for hypenated names, as well as the so-called grave accent (`), the acute accent (´), and the apostophy ('). Glad to see you will remove the question mark (?), because I see that too frequently in records (thankfully, mostly outside the WR community). --BobC 15:52, 5 March 2010 (EST)

Let me ask: are we talking about removing these characters from the page titles, but not the name fields themselves? That would simpler, because then I wouldn't have to worry about someone getting upset because we removed the ?'s from the names that they weren't sure about. They wouldn't appear in page titles but would still appear in the name fields.--Dallan 18:59, 5 March 2010 (EST)

My concern is that these extraneous characters not appear as an "indexable" attribute or as an automatically categorizable surname field, so that they don't create file name spaces such as Surname:Smith(?), Smith (or Smythe?) in Seattle, King, Washington, United States, Category:Smith[Jr.] surname, or the real examples on the WR Most Wanted Categories List: #2 - Category:? surname ‎(which has an embarrassing 3515 members), #3 - Category:??? surname (2496 members), or #12 - Category:?? surname (724 members). --BobC 19:31, 5 March 2010 (EST)

I see what you're saying. So it's ok to keep them in the name fields so long as they're not in the title, index, or category listings. I can do that.--Dallan 18:48, 9 March 2010 (EST)

Fix unnecessary notifications bug [5 March 2010]

The request is to fix a bug where page elements are re-arranged on save so that it appears that the page is edited when the page isn't really edited. It has to do with the GEDCOM uploader adding elements out of the usual order.

• • Amelia, I fear that this is a non-technical solution that needs emphasizing. We need to really encourage people who are editing pages to click "this is a minor edit" when all they are doing is minor formatting changes. I am amazed at the few people who are regular contributors who *regularly* fail to click this box. (Similarly, I also really dislike the lack of entering something useful in the Summary field. Sigh...) Jillaine 10:23, 3 March 2010 (EST)
    • I wonder if some people don't realize what is meant by "minor edit." Maybe something short could be added to explain what it is. Something like "This is a minor edit (corrected punctuation, etc.)" Amy 10:31, 3 March 2010 (EST)
      • great idea amy, perhaps a little "help" link could send them here
        • I think these changes often happen as a result of gedcom uploads and merging. An example is [1] where the change was simply an internal reordering of items, not a change in the data itself. --Jennifer (JBS66) 10:45, 3 March 2010 (EST)
        • Jennifer has the BUG correct. I agree that there is a user issue with minor edits, but this isn't that. For the system to send change notifications because of an internal reordering of data is a bug, one with increased user impact because the emails are likely to come in waves that get a user excited about changes only to have the site look broken and not ready for prime time. Getting an email because of a typo change is a much smaller deal.--Amelia 11:12, 3 March 2010 (EST)
          • Ah. My misunderstanding. Now I see why you (Amelia) put this under the GEDCOM heading. Got it. Jillaine 11:24, 3 March 2010 (EST)--Dallan 12:08, 5 March 2010 (EST)

Add do-not-merge template link [5 March 2010]

• add a "do not merge" link to the ShowDuplicates screen (if there are only two people/families listed in a potential merge) that adds the nomerge template to the talk pages. -- Jillaine 10:13, 25 January 2010 (EST)--DataAnalyst 10:22, 7 February 2010 (EST)

Don't you just have to click on one link in the duplicates list to see the compare screen, where there is a Does Not Match button, which does add a nomerge template? I think it would be dangerous to add nomerges without at least doing a field by field compare. --Jrich 11:04, 7 February 2010 (EST)

This item is no longer being considered.--Dallan 12:12, 5 March 2010 (EST)

Reuse empty index number slots [5 March 2010]

• Not sure if this is possible: Reuse empty (deleted or unlinked-to redirects) index values for person and family pages. ie, instead of creating a John Smith (144), create a John Smith (2) if that spot is empty. --Jennifer (JBS66) 10:20, 27 January 2010 (EST); --Leo Bijl 14:43, 4 February 2010 (EST)

This is not a 'best practice'. Consider someone who refers to John Smith (23) in a communication or an online discussion somewhere outside of WeRelate, and then John Smith (23) is merged into John Smith (12). Now a new John Smith (23) is created. This could easily cause confusion with someone new to the discussion. At least if John Smith (23) no longer exists, they would realize that John Smith (23) had been deleted. Granted, online discussions should be using links, not just references, but people do all sorts of things, and some communication still occurs offline :) --DataAnalyst 10:44, 7 February 2010 (EST)

This request is no longer being considered--Dallan 12:14, 5 March 2010 (EST)

Add township pages [5 March 2010]

-- NEGATIVE VOTE -- This would effectively quadruple the number of county name listings, with no useful return that i can see. And not all states even have townships (Texas doesn't). Township names can be added just fine after a pipe in a placename. --Mike 16:50, 23 January 2010 (EST) -- concur with Mike Jillaine 10:29, 25 January 2010 (EST); I have to disagree and vote in FAVOR of township pages for places that have townships. Some records are recorded at the township level.--Lauren 09:22, 26 January 2010 (EST) Don't we already have township pages? For example, Place:Hopewell, Perry, Ohio, United States. Or are we talking about something different? --Amy 08:40, 29 January 2010 (EST)

I am in favor of township pages. Using the pipe symbol does not make it possible to easily see what other pages are related to that township, whereas a Place page does. Besides, in some areas townships are a notable part of local government, not to mention of the community. Are they any less a "place" than a county? --JoshHansen 22:32, 30 January 2010 (EST)

We have a few township pages because they've been created by users, but I haven't tried to automatically create pages for all townships. (Similar situation exists for cemeteries.)--Dallan 21:54, 30 January 2010 (EST)--Dallan 12:23, 5 March 2010 (EST)

Remove website source type [5 March 2010]

is this still being considered?--Jennifer (JBS66) 18:55, 5 February 2010 (EST)

I'm not sure if having it there causes problems or not.--Dallan 12:24, 5 March 2010 (EST)

International name handling in GEDCOM upload [5 March 2010]

• Consider an improvement on allowing the GEDCOM upload of names to be more international or tweaked to help order the surnames. Thanks, Debbie Freeman --DFree 01:10, 24 January 2010 (EST) -- Can you explain further?--Dallan 21:54, 30 January 2010 (EST)

In my case Norwegian and German (baptismal) names are a problem. The Norwegians if I understand it can go by a farm name i.e. Dahl/Taug, or a patronymic i.e. Peterson/Frederickson. As mentioned before on another page German names if I remember right would be saint, then first name, then family name ie, Johannes Georg Mueller or John George Miller probably americanized to George Miller. Also many African American and Native Americans were only known by one name in written/historical records. Chinese names if I understand it correctly are family name first, then first name. ie. Freeman Debbie. --DFree 20:48, 31 January 2010 (EST)

Maybe we should consider using only page numbers for Person page titles. There's a discussion going on at the watercooler about this right now.--Dallan 12:28, 5 March 2010 (EST)

Search [14 June 2010]

Search is on the list to be improved. I just want to put some observations on how it currently works on (virtual) paper to be taken into consideration. This focuses mostly on searching for people.

As a rule, if I provide more search criteria, I expect a more refined result set, not a bigger result set. Intersection on a Venn diagram, not a union. A search result set in the thousands is is hard to use unless I can count on the probable target being on the first page. I put more criteria in trying to focus the result set to a narrower set. Typically when I search for John Doe born 1878, my thinking is find all those named John Doe and filter the result set for those born in 1878. If that doesn't work, I can modify the search to just look for John Doe, or just look for born in 1878. But I am giving two criteria because I expect them both to be valid if the target is in WeRelate.

I think it has been pointed out that matching state and country is virtually meaningless when one asks for a particular place specific to the city level. This seems to cause place to be vastly overweighted (does count as matching 4 fields, or just one?) Considering that many websites just assume people never strayed from their adult location, places are often wrong anyway.

Also names seem to be underweighted. I suspect this latter case may be partially due to missing information in the WeRelate record counting as a no match? For example, John Doe may be in WeRelate with no birthdate. In this case, the fact that he doesn't match my request of 1878 is not as bad a failure as he had a specified birthdate of 1659. Perhaps scoring, if still used in the new approach, should be a percent of those search criteria that could actually be compared instead of an absolute score?

Spelling variations are always important, unless I am trying to find a page I have already looked at, and know it is spelled a certain way. So there is rarely a time when I don't want spelling variations taken in account. It would seem that matching an alternate spelling should score just slightly less than matching the exact spelling and should work even when I ask for an exact match only.

If I ask for a date, there are probably ranges around that date, beyond which need not be considered. 100 years? If I ask for John Doe with a birthdate of 1878, do I even want to see the John Doe who died in 1709? Probably less than I might be interested in the John Doe that has no birthdate. --Jrich 11:00, 5 April 2010 (EDT)

Thanks for writing up your thoughts. In fact I'm currently consulting part-time for FamilySearch writing the back end for their upcoming search engine so I've been thinking about search a lot lately. They're gathering feedback from users on the new search engine right now. Once that effort is finished, I plan to re-use many of the ideas in the new WeRelate search engine.

• I've had the same ideas as you about intersection vs union, so unlike WeRelate, I wrote the new FamilySearch engine to use intersection. But the feedback coming in is that some people are finding it confusing when they enter a person's name, birth date, and death date, and they don't get results that include just a name and birth date (with an empty death date). It seems like there needs to be a middle ground - perhaps including results where the specified fields either match closely or are missing, unless the "exact" checkbox is checked?

• Places are overweighted in WeRelate and names are probably underweighted in both search engines. Matching a similar spelling is I believe currently scored just less than matching a name exactly, but I agree names need to be weighted higher. I'm not sure though that including similar spellings is what most people would expect when they check the "exact" checkbox.

• Regarding dates, I think the best result is to return people born near the date you requested, or who are missing the date, but not return people with a greatly-differing date. Same goes for places and names.

--Dallan 11:27, 6 April 2010 (EDT)

I wonder, is it possible to weight pages based on certain categories or number of links or even number of watchers? Sort of a Google algorithm? There are pages for people who are famous or just the ancestor of a lot of people that are really hard to find (just try finding *President* George Washington, let alone John Adams. Or King John I.) and it seems like any of those could provide a decent proxy for weighting what a user is most likely to be looking for. (Best would probably be most links, since this would encompass both categories and watchers, and could still be organically influenced, but I can see how that would also be the hardest).

Alternatively, I hope some basic changes could make things at least predictable. If I put "George Washington" in the keyword box at the top of the page, I get pages upon pages of sources, and if I then narrow to person pages, the president (who is (6)) doesn't show up until the second page, which is just weird.--Amelia 21:20, 4 June 2010 (EDT)

Ranking pages in the search results based upon the number of watchers seems like a great idea. Let's do that. For sources we might want to use number of pages linking to the source for ranking.--Dallan 13:01, 7 June 2010 (EDT)

Since you say you can do sorting by pages linked to... Does the number of pages linking to the source include the users pages of all the watchers? In that case, I think we should do page linking for all of them. There are people (like, say George Washington) who are well-linked to from wikipedia templates because they are at the center of certain events and their relationship is noted on the pages of their ancestors. Given the current nature of the site, people take interest in a particular area or set of people and one person may set up many such links, while only adding one watcher to the list. More watchers will hopefully come over time as a result of those cross-links, but it seems that the primary indicator that a page is of greater interest than others like it is going to be those cross-links. And just because I want well-known and well connected people to come up first when I search for their names doesn't mean I want to watch them all to encourage that to happen.

For "normal" pages, page linking would promote those with lots of children or lots of sources. Either of which seems like a reasonable proxy for watchers and for pages people are interested in.

The weakness, if page linking does not include watchers, would be for "normal" people who themselves don't have many children that are also the ancestors of lots of people and therefore we would want the system to assume that's who's being searched for. I think, however, given that you can search easily for just pages you are watching, that I would rather sacrafice this possibility - particularly because if the person really is of interest, then people can and should add source links that will raise the page in search results.

For sources, I like the idea of pages linking to the source. I think that would be really useful.--Amelia 22:52, 10 June 2010 (EDT)

The number of pages linking to a page (i.e., What links here) doesn't include the user pages of watchers, but I could add those two numbers together for the metric: number of watchers + number of pages linking to the page. The number of pages linking to the page doesn't include the number of outgoing links though. I could add the number of outgoing links as well and/or the size of the page (which would rank pages that had narrative or lots of events/sources/notes higher).--Dallan 16:30, 11 June 2010 (EDT)

I like adding the watchers + pages linking in. I'm agnostic on the outbound links. How will that work on pages with templates? It's the template that will get the weight then, right? I don't think that's useful. Or I can think of lots of ugly data that generates lots of links. But you're right that sources would need to be captured with outbound links. Would children be captured twice? I.e. each of the children would link back to the parent, and the parent page has outbound links to all of the children. I think that might cause a lot of weighting that wouldn't improve the process. Also, are category listings only outbound or are they both? (I notice that the categories a person is in don't show up on what links here.)--Amelia 00:29, 14 June 2010 (EDT)

Wikipedia templates can add inbound links because the templates contain links to the corresponding Person pages. Over 500 pages link to George Washington for example. Category listings are only outbound though. Essentially, if it doesn't show up on what links here, it wouldn't count as an inbound link. Children count as inbound links for the Family page they belong to as well as for the Person pages of their parents and siblings. I agree this isn't very useful, but it does rank people that are linked to parent and spouse families with other known children listed higher than "orphan" person pages, which may be semi-useful. For Person and Family pages I think we could also add the number of sources + notes (so just count sources directly rather than using number of outbound links as a proxy measure).

One additional note: the "What links here" list is currently out of date for most of the Person and Family pages in the wiki. The "What links here" list is typically updated only when a page is edited, under the assumption that's the only time links can change. But under the new look Person pages now link directly to their parents, spouses, siblings, and children, which they didn't before. To fix this I need to launch a (long-running) process that re-parses every page in the system. I'll do this in the near future -- before updating the indexing process.--Dallan 23:30, 14 June 2010 (EDT)

Capitalize dates [30 August 2010]

I am happy to see this todo item. It would be nice if WeRelate used a consistent display format for dates, no matter how they were input, just to resolve this whole issue. GEDCOM doesn't care about capitalization and all values are supposed to be converted to all uppercase or all lowercase for any comparison when processed. So most of the various requests merely reflect personal preference and removing this variability will be helpful.

My preferences differ from what was requested slightly. Also, I have some uncertainly about what the resulting to do item is saying, since it talks about capitalizing months and I don't think that was what was requested. The original request asked for mixed case for months, unless I misread it. Actually if mixed case is not possible, I would prefer all lower case to all upper case, as it is easier to type and uses less screen real estate.

Sorry - I meant capitalize just the first letter; I changed it to say mixed-case.

I would also like to argue for mixed case for qualifiers, not all lower case as the original request asked. Those qualifiers that go at the beginning of the field, are like the word at the beginning of the sentence, and it seems like they should be capitalized. So I prefer "Bef Dec 1690" to "bef Dec 1690". No real justification for making it lower case was given, but I feel this downplays the significance of the qualifier, which often makes the resulting meaning very different from an unqualified date. For example, 1685 would be a reasonable match for Bef Dec 1690, so it is important to notice the qualifier when you are reading a page. --Jrich 20:34, 25 August 2010 (EDT)

I could go with mixed-case qualifiers. I'll do a quick survey to see whether all lower-case or mixed-case is currently more common.--Dallan 20:32, 30 August 2010 (EDT)

MySource pages and editing [25 June 2011]

Jrich, I have moved this discussion to this page. Don't see any reference to the subject here so I don't know the reason behind this request. I also see another request regarding MySources that doesn't allow one to delete a MySource if someone else is watching the page. If it is indeed a source that is unique to the user, I still probably would not support the no editing rule. To me this rule is not compatible with a Wiki. Well for that matter neither is the title MySource but that is another subject. If I entered as a MySource images from the Robinson family Bible and a transcription because I have possession of this Bible, why does this entitle me to be the only one to have editing privileges? The family record in this Bible has entries starting in the early 19th century from Pennsylvania, Ohio, and Mississippi. Presumably there are many descendants who may wish to collaborate on the Robinson family pages. What if I died next week or a year from now decide not to use WeRelate? Maybe I made an error on the page or someone wishes to improve the formatting? What then? Also MySource also contains many sources that are not unique and some are even junk sources such as unidentified family trees. --Beth 22:22, 24 June 2011 (EDT)

"...neither is the title MySource but that is another subject"

"MySource also contains many..."

I suspect this discussion hinges on what purpose one thinks MySource serves. They are used inconsistently and GEDCOM upload did/does use them almost as a dumping ground for unrecognizable sources. So there are many uses of this namespace that perhaps don't fit my personal opinion of how they should be used. Also, now there is some fuzziness between MySource and the new way of handling Transcripts. But, my feeling is that they are primarily intended to hold unverifiable (i.e., not generally available to the public) sources, and most of the MySources I have personally created contain some kind of transcript of the material in the item. This is unlike sources, where essentially any motivated person can find and access the source, and speak about it and its contents with equal authority as the original user.

If I happen to have a unique source, why should anybody else be changing it? If they do, on what basis/authority are they able to do it? What need there is, that this editing is required? Jrm03063 has mentioned interviews, for example. If somebody else wanted to edit a MySource page describing one of jrm03063's interviews, I'm inclined to think that is actually wrong of them, and they should be stopped.

I think it is possible to have no editing and still solve most problems. Say the MySource is a family Bible and the contents are given incorrectly (perhaps a picture was posted on the Internet and I interpret the writing differently). The creator/owner of a MySource isn't responding. For starters, I can post a note on the Talk page documenting the differences. Or the actual source citation of that MySource on the affected Person/Family page can be annotated with a note. Alternately, a new MySource can be created by a still-active user and used to replace or supplement the defunct user's MySource.

I think people should attempt to use unverifiable sources as little as possible. But a wiki is about letting people contribute their knowledge, and I do think some users have unique contributions to make, and the very value of the contribution may lie in its uniqueness. So having a way to protect the integrity of that contribution is not a bad thing. I agree that a big part of any wiki's reliability is based on community access and review. MySource pages are readable, and review is provided by discussions on the associated Talk pages. Family and Person pages should be completely open to editing and if MySource pages are not useful, their citations will be removed, and it will effectively be ignored. The name of the MySource namespace clearly indicates its nature, and I don't believe it is incompatible with wiki ideals. --Jrich 10:21, 25 June 2011 (EDT)