User talk:Dallan

Old topics archived: 2007, 2008, 2009, 2010, 2011


Topics


Missing link [15 June 2011]

Hi Dallan, I noticed that a link is missing on the left sidebar on Person and Family pages. To the left of TALK at the top, there should be a link to Person or Family. When you are on the talk page, that link is needed to direct you back to the person/family page. Maybe you're in the middle of tweaking things and know about this already... but I thought I would post just in case. --Jennifer (JBS66) 12:46, 15 June 2011 (EDT)

Ok... you must be tweaking something :-) I'll add a few things to the above list
  1. The Search box on the top right is not working now in Chrome 12 or Firefox 4.01 - pressing the magnifying glass does nothing.
  2. A user posted on the Dutch forum that she has "no watchlist, no navigation, no edit at top" etc. She is using IE 8. --Jennifer (JBS66) 14:36, 15 June 2011 (EDT)
I just fixed a bug. The search box should be working and the Person/Family links should be back. I didn't see a problem with the watchlist, navigation, etc links at the top using IE8; could you ask her if they're still broken? Thank-you for pointing out these things.--Dallan 17:03, 15 June 2011 (EDT)
Thanks Dallan! The links and search are working fine for me now. I'll ask Lidewij if it's improved for her as well, and let you know if it has not. --Jennifer (JBS66) 17:32, 15 June 2011 (EDT)

Unused MySources in gedcom upload [20 June 2011]

Hi Dallan,

I want to see if I have this right: In the gedcom I uploaded last night, I mistakenly included an entire generation already on WR, so there were a lot of matches. There were several sources that were only used on the matched pages. I did not bother to edit or match or exclude these sources, because I thought they would be ignored if they were only used on pages that were themselves ignored in the upload. But I think, if I'm remembering everything correctly, that MySource pages were still created for those sources. (for example). Is this how this is supposed to work? Can it be stopped? Thanks--Amelia 19:46, 19 June 2011 (EDT)

It's not a quick fix. Could you add it to the suggestions list so it doesn't get forgotten?--Dallan 16:15, 20 June 2011 (EDT)

Question [22 June 2011]

Hi Dallan, I was wondering if I could delete an account that I made, as I just realized that I have two accounts. Sorry. The one that I am using to write this is the one that I wanted to delete or to merge in with my other account. Is this possible?

Jennifer--Jeneagen 21:37, 19 June 2011 (EDT)

I can't merge accounts, so I've renamed Jeneagen to "Renamed to Jacksbox4you". You can just ignore that account from now on.--Dallan 16:15, 20 June 2011 (EDT)

Thank you Dallan. You are doing a great job with this wiki. I am hoping to be more involved in my family research this summer and plan to use the site to share it with my family.--Jacksbox4you 20:28, 21 June 2011 (EDT)

Thanks, I'm glad to hear that you like it!--Dallan 14:14, 22 June 2011 (EDT)

Search for subordinate places bug [13 July 2011]

I searched for sources place=Massachusetts, subject=vital records. Checked the "subordinate places" box. 1232 results. Click "next". I'm seeing records 21-40 of 57 - the subordinate place is no longer checked, and only Massachusetts records are shown. --Amelia 18:13, 7 July 2011 (EDT)

This will be fixed tonight.--Dallan 15:41, 13 July 2011 (EDT)

Bug in merge screen? [13 July 2011]

Hi Dallan. I've been having an intermittent problem with merges, and maybe figured why it's intermittent? What happens is that I check some pages to merge, and not all of them show up on the compare screen. Usually I work around it without much problem. But it seems on thinking that the ones that don't show up are usually/always towards the bottom of the list. Perhaps when the screen got lengthened from 10 to 20 results, the code still only checks the first ten to see which are checked? Does that make sense? The symptoms occur even if the guess about the cause is wrong. Thanks. --Jrich 01:09, 12 July 2011 (EDT)

You're right! I changed the search screen to show 20 results, yet the compare screen still checked only the first 10. This will be fixed tonight.--Dallan 15:41, 13 July 2011 (EDT)

MySource redirect bug [19 July 2011]

One of the help pages advises redirecting MySources to Sources. Didn't think this worked, so I tried it. The coding works, but it screws up the linked pages. See [1] The original links to the MySource on the person page are now red because they are looking for MySource:Hines... etc. instead of MySource:Amelia.Gerlicher/Hines... etc.--Amelia 17:35, 18 July 2011 (EDT)

I see what you're saying. Thank you for pointing it out! I'll fix it tonight.--Dallan 13:18, 19 July 2011 (EDT)

My Account [25 July 2011]

I would like to delete my file and start again later. Much information went in that I do not want made public. So sorry. Judy--JudithBackus 11:35, 25 July 2011 (EDT)

You can remove your file using the MyRelate menu, Trees option. There is a button for Remove Tree which will delete pages which are not watched by other users. In the future, please use the Gedcom Review carefully. It is intended to let you preview your pages and you can edit or exclude any that you don't want shared. It is less disruptive to handle this in preview rather than after the pages are imported into the shared database. Thanks. --Judy (jlanoux) 15:24, 25 July 2011 (EDT) (WeRelate volunteer)

Place-matching [30 July 2011]

This isn't urgent but I thought I ought to call it to your attention. While working the place-matching tab in a GEDCOM review this morning, I discovered the system couldn't find a match for "St. Joseph Cemetery, Clarksville, Red River, Texas, United States". I had to change it to "Saint Joseph Cemetery, Clarksville, Red River, Texas, United States." I thought the whole problem with matching commonly abbreviated names to spelled-out names had been taken care of some time ago. . . . --MikeTalk 07:13, 27 July 2011 (EDT)

I thought so too. I'll add it to my list of things to do.--Dallan 00:05, 31 July 2011 (EDT)

Strange place "correction" [24 August 2011]

On Gen. Anthony Wayne's page, I typed in "Old Saint David's Church Cemetery, Wayne, Delaware, Pennsylvania, United States" as the place of burial. I knew it would be a red link since there was not yet a place page for it. (That's how I often add a cemetery page -- I'll add it as a red link on the person page and then click on it to actually create it. Saves a step that way.) When I saved his page, however, the system tried to match that place to "Old Saint David Church Cemetery, Wayne, New Sweden Colony," which was also a red link. In other words, his page still showed what I entered, but it had the New Sweden Colony before it {"Old Saint David's Church Cemetery, Wayne New Sweden Colony|Old Saint David's Church Cemetery, Wayne, Delaware, Pennsylvania"). I had to go back and edit his page to remove that reference. Even after I created the page for the cemetery and typed the place name in on Mary Penrose's page, it still tried to change it to New Sweden Colony. In fact, the only way I could get her page to go to the cemetery page was to have the place name entered as "Old Saint David's Church Cemetery, Wayne, Delaware, Pennsylvania, United States|Old Saint David's Church Cemetery, Wayne, Delaware, Pennsylvania, United States". Any idea what's going on? Thanks. -- Amy (Ajcrow) 08:42, 17 August 2011 (EDT)

You're right - that's really strange. It has to do with both Delaware and Pennsylvania being "located in" Place:New Sweden Colony, but it's obviously wrong. I plan to re-do place matching later this year; assuming it doesn't show up very often, I'll make sure to fix this bug then.--Dallan 01:41, 24 August 2011 (EDT)

Merge error [23 August 2011]

Something odd happened with this merge. I got the following error: search server returned bad response: 404 for function: placestandardize

It appears the merge has not been recorded in the Merge Log, but the (2) version of the page is redirecting to the (1). The data, however, was not copied to the (1) page (I copied it over after).--Jennifer (JBS66) 18:04, 23 August 2011 (EDT)

I am having the same problem. I can add data only as long as I add nothing to a place field

--Susan Irish 18:11, 23 August 2011 (EDT)

Due to a lapse in judgement on my part, all search-based functions, which includes place auto-complete and standardization, were down for 30-60 minutes today. I'm sorry about that. I hope I've fixed everything now.--Dallan 21:04, 23 August 2011 (EDT)

Question re gedcom export [7 September 2011]

I was re-reading the discussion of formatting URL's here and I don't think we ever got an answer to the question underlying the formatting discussion: does it matter, and how, if a URL is placed in an associated note field v. in the text/transcription field v. in the vol./page field? And what happens if the link is formatted (i.e. brackets/short name)?--Amelia 01:09, 7 September 2011 (EDT)

I'll answer on that page (short answer: it doesn't matter).--Dallan 15:16, 7 September 2011 (EDT)

Unknown Place type [3 October 2011]

The page for Place:Ancient Burying Ground, Hartford, Hartford, Connecticut, United States was created yesterday (1 Oct) and has a place type of "Unknown." I thought that "unknown" wasn't an option anymore. (Or is leaving it blank the only illegal option?) -- Amy (Ajcrow) 08:16, 2 October 2011 (EDT)

Amy, I changed the type to cemetery, but unknown is available on the drop down type list. Can't remember the discussion we had regarding unknown types.--Beth 10:21, 2 October 2011 (EDT)
The issue is that Unknown is our second-most-common place type, appearing on nearly 143,000 places, because the Family History Library Catalog didn't include a place type on their places. We could omit it from the list of possible place types, but then if you edited a place with an Unknown type, you'd be required to change it in order to save your edit. That may not be a bad thing; I don't know.--Dallan 13:14, 3 October 2011 (EDT)

Managing "excluded" people after an import [20 March 2012]

My family tree has about 800. About 300 will be excluded because "living" and about 100 excluded because "early".

How can I get a list of all excluded people AFTER the import? I would use that list to verify and resolve all excluded people. Will the list of "excluded" remain on WeRelate after the import? Should I just sort and screen-print all those pages? I cannot "select" from that list to copy/paste to create my own spreadsheet. Any suggestions?--Donkle3 15:29, 5 October 2011 (EDT)

No one has asked about this before. The only way I can think of is to sort and take screen-prints unfortunately.--Dallan 23:50, 7 October 2011 (EDT)

Dallan, After much fine-tuning, I have successfully imported my Gedcom to WeRelate with about 505 new people imported and about 291 excluded. Prior to import, I counted about 70 that were excluded due to "Early" with the remaining exclusions for "Living".

Last October, after I was taught about WeRelate by the genealogists at the Allen County Public Library, I first learned about the "Early" exclusion. I called the ACPL people to discuss it and they were surprised such an exclusion existed. (I also posted my original "excluded" comment at that time, 10/7/11.)

They suggested that after I successfully uploaded, I should write you to request the exclusion be waived for this tree. Hence this post. Please make an exception to the "Early" exclusion for my "Donkle3" tree.

If there is anything I can do to assist with my request, I would be happy to do so ... (other than manually finding and entering 70 old relatives!) For example, I could delete and re-import my Donkle3 tree if that would help.

Thank you, Lou Donkle--Donkle3 19:14, 18 March 2012 (EDT)

Let me play the devil's advocate here, at the risk of sounding unwelcoming (though it is really a reflection of my desire for accurate genealogy). This is about collaborating in a single, shared family tree. I am convinced that websites that allow people to upload their family tree with no questions asked, have created an expectation of no accountability that is not consistent with true collaboration. To expect a stranger to accept one's data, one must provide some kind of objective proof, especially since there are often differing opinions about what is correct. So here is my question: What has been demonstrated by your upload that would lead a the powers that be to trust you with even older genealogy, where nobody alive can have any possibility of first hand knowledge, and where you are more likely to interact with or change the work of other researchers as family tree converge on common ancestors? Is it the 505 pages with apparently not a single source citation? (I only looked at 30 or so of your pages, but either I got incredibly lucky, or there are no sources.) No, that is certainly not a persuasive argument. Is it the documentation of careful research, so that strangers trying to add to the same page know where the information comes from and can either be enlightened or respond appropriately if they disagree? Same answer. Is it comments like "Bef. 2010 arbitrary death date so www.WeRelate.org will consider this person not-living and import their data"? No, I'm sure that isn't going to engender much trust. Is it dates without locations or marriages without dates that clutter up other people's search results with half-matches that could be a match or could be half a world away, or might be the person I'm searching for or could be centuries removed from the person I am looking for? I don't think so. My suggestion, which is certainly not official as I am only one ordinary user here, is yes, go enter the 70 other people by hand, and add sources to the pages you've created, then ask again. --Jrich 23:32, 18 March 2012 (EDT)

Fair enough. Thank you for your very thoughtful answer. I will proceed manually. As you have probably guessed, the file I submitted is the research work and data-entry of many others from my parents and grandparents generation and believed to be accurate, if without documentation, by the families represented. By getting it online, I hope other living family members (along with me) will collaborate to improve documentation and add content. I also hope to educate and draw some family members away from Ancestry to WeRelate along with their private trees at Ancestry. This is not a justification, but an explanation, that may be of interest. Thank you again for your comments and your efforts with WeRelate.--Donkle3 00:06, 19 March 2012 (EDT)

I moved the early cut-off date back to just before 1700 a couple of months ago. Once you've gotten more experience with the website and have shown that you are a careful contributor, you can request the right to import people back to around 1600. But entering some people by hand isn't so bad either. In fact many of the "regulars" around here prefer it, because it provides them an opportunity to make sure that the pages they're creating are the best that they can make them.--Dallan 00:24, 21 March 2012 (EDT)

Person:Louis Williams (1) [7 October 2011]

Hi Dallan,

There is an oops here. Louis or Lewis C. Williams who married Mary Crane was from Paris, Wisconsin. He has the wrong parents. Easy mistake since both parents are named Lewis and Margaret Ann Williams. I am going to fix the pages but probably will not take the time to add the actual siblings of Louis C. who married Mary Crane. Looks like these people may have been sealed so some corrections are probably needed. --Beth 19:55, 5 October 2011 (EDT)

Thank you for going through my tree Beth! It looks like you've been adding a number of sources and you also found this mistake. I went ahead and added Louis' siblings. I got this tree from my mother, so I'm going to talk with her about it. Thank you again!--Dallan 23:50, 7 October 2011 (EDT)

Page won't save [8 October 2011]

I am trying to add a person page. Preview as normal, all else is normal but hitting SAVE button brings up an error beginning with theses lines.

MediaWiki internal error.

Original exception: exception 'DBQueryError' with message 'A database error has occurred Query: UPDATE `site_stats` SET ss_total_edits=ss_total_edits+1 LIMIT 1 Function: SiteStatsUpdate::doUpdate Error: 1205 Lock wait timeout exceeded; try restarting transaction (wiki) ' in /var/www/htdocs/w/includes/Database.php:647 Stack trace:

  1. 0 /var/www/htdocs/w/includes/Database.php(604): Database->reportQueryError('Lock wait timeo...', 1205, ' UPDATE `site_s...', 'SiteStatsUpdate...', false)
  2. 1 /var/www/htdocs/w/includes/SiteStatsUpdate.php(79): Database->query(' UPDATE `site_s...', 'SiteStatsUpdate...')--50vicar 12:52, 8 October 2011 (EDT)
Looks like something got stuck. I've just restarted the database server, and it appears to be working again. I'm sorry for the trouble; thank you for letting me know.--Dallan 13:39, 8 October 2011 (EDT)

Un-redirect-able place [14 November 2011]

Hi Dallan

I've been going through the places in the London area and tidying up the duplicate places, but have found one place which seems to be misbehaving: Place:Stepney, Tower Hamlets, Middlesex, England. It's the same place as Place:Stepney, Middlesex, England but the former page won't let me make it a redirect page because it has contained places. However, none of the places it lists as contained places are actually pointing at that page - I've corrected them all to point at the latter page. I don't know whey they're still showing up as contained places on the former. I can only think it may be because the latter page was once a redirect to the former, but I undid that - because "Stepney, Middlesex, England" is the correct format for the place name - whoever put in the extra layer of "Tower Hamlets" was throwing a bit of a spanner in the works. Any thoughts? Many thanks RichardK--RichardK 09:40, 31 October 2011 (EDT)

I don't know why the contained places were still showing up on the former page after you corrected them either -- it looks like a bug. Thanks for letting me know. Anyway, I merged it into the latter page. If you come across something like this again, just let me know.--Dallan 19:26, 1 November 2011 (EDT)

Thanks Dallan - that's great.--RichardK 02:33, 2 November 2011 (EDT)


Dallan, Is there a simple way to ask a question in WeRelate? In trying to identify the parents of my great grandfather born in Oostdongeradeel (Wierum near Nes) and his twin sister, I came across the WeRelate information of WeRelate user Ekjansen. Is it possible to ask this question of him?

The people of interest are my Age van der Wagen and she is (I think) Eetje van der Wagen both born in December of 1848. Eetje married John (Jan?) Bronsema before leaving for America about 1874. He came to America when single in 1873. Age married Wilhelmina Feltman in 1874 in America; she born in Groningen. He visited the Netherlands often until his death in 1932 in Ferrysburg, Michigan. His first born son is Jacob Edward van der Wagen, possibly named after Age's father? Eetje's first daughter was named Pietje Bronsema, possibly named after their mother. I do see a Jan Ages van der Wagen and wife Pietje Teensma in the Ekjansen data. Do you know how I could find out if my two people are their children?--Tom&Laurel 10:24, 14 November 2011 (EST)

Contacted by separate mail already.--Klaas (Ekjansen) 10:37, 14 November 2011 (EST)

Next step: Review your GEDCOM [5 December 2011]

I think I have completed my review, but the import tab is grayed so it wont work, HELP, thanks :-)--Gypsy1930 19:20, 4 December 2011 (EST)

You need to do two things: First, go to the warnings tab and click on the warning so the system knows you have reviewed it (you may have done this already). Second, go to the Family matches tab, click on each potential match, then scroll to the bottom of the page in the bottom half of the screen and click on either Match or Not a match. Once you've done this, you should be able to click on the "Ready to import" button.--Dallan 14:44, 5 December 2011 (EST)

Mass accumulation of non-relatives [6 December 2011]

I spent days trying to get my gedcom in good order to be accepted. Then I found out there where matches to my data. JonJay has spent years borrowing other peoples families. He even has my mother in his database and there is positivly no relationship. I do not want my work connected to his "work". The information he submitted was my early work. I work on my data 24/7 bring it up-to-date. How did he manage to get his thousands on there? I was starting with 20 people and found it to be difficult. I am very disappointed.--Gypsy1930 12:08, 6 December 2011 (EST)

I saw this message and can't comment on the data you are referring to, but I will point out that WeRelate does not have any way of screening for what is right and what's wrong (except for really outlandish things like a child born after the mother died, etc.) It relies on the collaboration of multiple users like yourself using the wiki features to accomplish quality control. Internet genealogy has a horrible, but well-deserved, reputation for being junk because so many people copy the first data they see without understanding, analyzing or confirming it. At least on this site there is the opportunity to correct those errors and provide quality sources to refute the bad genealogy. Once something has been corrected (or better yet, created the first time) with credible sources, the self-evident-ness of it usually keeps things moving towards better, and away from junk. And the synergy of multiple quality-minded researchers can result in some really great pages.
By the way, I personally suggest abandoning your GEDCOM, and just entering the data by hand. My experience has been that it is easier and possibly faster than uploading GEDCOMs, and particularly if you are often merging with existing pages, it is more likely to end up with coherent, useful pages as you are better able to review the existing contents and make finer-grained changes than is possible through GEDCOM uploading. Just my preference, though. --Jrich 13:28, 6 December 2011 (EST)
Jonjay uploaded some gedcom's back in 2007 and hasn't made any contributions since. The pages he created are not owned by him. In fact, others are encouraged to make changes. One of the principal benefits of a wiki, and the reason for WeRelate, is that others can come along later and improve or correct originally-submitted work. Over time, the quality of the work increases. If you stick with WeRelate and add your information (and I hope you do), you'll be dispelling misconceptions. We have lots of examples where someone created a page with no sources, and later someone else adds a source or corrects a date. That's the way a wiki is supposed to work.--Dallan 01:11, 7 December 2011 (EST)

Is there a bug in editing GEDCOM pages prior to upload? [18 December 2011]

I imported a GEDCOM a few days ago and just submitted it for processing. When I edited individual and family pages (in the GEDCOM), and saved the changes, the changes appeared correctly, but when I moved the cursor off that individual or family and back, the display reverted to the original GEDCOM data (lost my changes). I am waiting now to see if my changes were actually saved (though not displayed) and get uploaded. I will let you know either way. In the meantime, you could take a look at the GEDCOM. I edited individual Abigail Allen b. est 1682 and family William Clark and Hannah Griswold. If you need more details, let me know. --DataAnalyst 22:26, 6 December 2011 (EST)

I looked at Abigail. It appears that you turned the source citation for her birth into a note. And in family William Cleark and Hannah Griswold, it appears that you moved Thomas Clark from the page number field to the record name field. Is this all that you did to those two pages? And you're saying that neither of those changes "stuck" when you moved the cursor away from and then back to the row? Did you happen to re-edit the pages to see if the changes were still there on the edit screen? It's possible that we have a caching problem - that the server is showing a pre-edited version of the page when you cursor away and then back to the row. Though when I just tried this, cursoring away and back showed the edits I had just made. Additional information would help me track this down. Thank you--Dallan 01:11, 7 December 2011 (EST)
Dallan, DataAnalyst made some important changes to William and Hannah that included adding a source showing two more wives than were there. Having been notified of changes, I analyzed them, looked up some sources, and added those wives. Of course the description says GEDCOM upload, but as another user, there is no indication whether the upload is completed or still proceeding. I did not change either of the indicated pages directly (in fact, I don't think Abigail Allen exists yet as a regular page, and I, fortunately, didn't add her and the other children of the three marriages, though I considered it since I had some sources on the screen in front of me during this process) but one change I made ended up propagating something to the Family page.
I have only uploaded a GEDCOM once or twice, but I know there are two types of changes: I think changes to existing pages are real-time, but adds get held and may or may not get made permanent at the end of the process. I just mention my actions because, depending on the time between cursoring away and cursoring back, I see various potential effects that might create something that looks like a "caching problem". I assume the above discussion takes this into account, but just wanted to mention it as a potential complication. --Jrich 09:36, 7 December 2011 (EST)
You're right - changes to existing pages are immediate, but adding family members doesn't happen until the upload is complete. It's not ideal, but I can't think of a way around this.--Dallan 00:40, 8 December 2011 (EST)
Dallan - you are exactly right about the changes I made. That is all I changed on those records (I had changed a couple of other records earlier, but not tracked the changes). After making the changes, moving my cursor and moving back, I tried re-editing and got the original GEDCOM without my changes - in fact, I made the same changes to Abigail twice so that the second time, I could verify what happened the first time. If I remember correctly, the second time I made the changes to Abigail, I added the note but forgot to remove the source and saved it. I immediately noticed this and re-edited the page (without moving my cursor off Abigail) and the edit page reflected my changes so I only had to make the incremental change of removing the source. Saved and it looked good. Moved my cursor off and then back and the changes disappeared.
Given that the edit page the second time around did not reflect my changes, and when I made the second edit and missed part of it, the display reflected exactly what I did the second time, it is clear that I really was back to the original GEDCOM record the second time I edited.
If this is not happening to you, then maybe it is my local setup. I changed computers about a month ago and this is the first GEDCOM I have tried - well, not quite, because I imported a version of the same GEDCOM a week or so ago and noticed the same issue with it. I deleted that GEDCOM when I realized that my updated genealogy program had put text in the GEDCOM that I did not want. So this might be an issue with caching on my computer. My technical support person (aka husband) is away tonight, so I might not mess around with settings until tomorrow or the weekend.
It is good to know that the changes are there even if I don't see them. I'll look for them in the uploaded GEDCOM. Thanks for checking this out. If this additional info gives you some ideas, check them out. Otherwise, I'll let you know if my husband can help me figure out any caching options that might be making a difference on my end. BTW, I am using IE 8.
And JRich, thanks for the comments, but in this case, I don't think that anything you might have done would have affected my GEDCOM. Especially since I saw the same behaviour in the first version of my GEDCOM a week or so ago and I had not done any merging with it yet. --DataAnalyst 18:58, 7 December 2011 (EST)
Just so I understand clearly, you're saying that you still don't see the changes that you made to those pages when you review your gedcom? I've put the gedcom back for your review. Would you mind reviewing your gedcom and checking those pages once more for me? If the caching problem is happening to you, then it's happening to others as well. If you could try this again and verify that you're still not seeing your changes (perhaps try changing a different page to see what happens), please let me know and I'll make some changes to the software to see if I can fix the problem. I'm sorry to ask you to be the "guinea pig", but I don't have a good way to test whether I've fixed this since I can't reproduce it at my end.
Also, when you review the gedcom, could you re-look at William Clark and Hannah Griswold as a family match? You've marked them as "not a match", but they look like a match to me? Thank you!--Dallan 00:40, 8 December 2011 (EST)
I looked at the GEDCOM you put back for review, and I now see the edits I previously made. However, when I changed another record (William Clark's individual record - moved "Thomas Clark" from page number to record name), I encountered the same behaviour as before - changes appear to be saved, but the display reverts back to the original GEDCOM data when I move the cursor away and then back. So I tried changing another record (similar change to Joseph Gilbert) and this time I refreshed the page after saving the edit. This forced a reload of the GEDCOM, and then I saw my changes, including the changes to William Clark's record. So it does appear to be a caching problem. I tried same thing again with one more record (Mary Richard) just to double-check that I am describing the issue correctly and confirmed the same thing - move the cursor off the record and back on and the edits are gone, but reload the screen and the edits appear.
Re: William Clark and Hannah Griswold - these were not a match at the time I reviewed the GEDCOM (wrong William Clark in the marriage). I fixed the record manually after I submitted the GEDCOM, so now they match. I had planned to do a post-upload merge, but I have matched the family in the GEDCOM instead.
I don't mind being a guinea pig. I've done a considerable amount of system testing over the past few years at work - this is pretty minor in comparison. I hope I can help by being explicit in describing the issue. Let me know what else I can to do help on this one. --DataAnalyst 21:04, 8 December 2011 (EST)
Thank you. I think I've solved the caching problem. Would you mind checking it again? If it's working now, please mark it ready to import and I'll import it. (I'm moving the database to a larger server later this evening, so you may need to wait until tomorrow.) I appreciate your help with this, and your clear explanations.--Dallan 22:06, 9 December 2011 (EST)
Sorry - not fixed yet. Removed underscores from citation for Elizabeth Belcher and the same problem occurred. Do you want more information on my IE options? --DataAnalyst 10:20, 10 December 2011 (EST)
Dallan - I have noticed recently that WeRelate is no longer offering a place name when I start typing in a place field, and when I think about it, this is just since I changed computers. Do you think I have a security setting that is preventing this, and also affecting the GEDCOM, or have you changed WeRelate so that it no longer gives dropdown lists on place names when you start typing? --DataAnalyst 11:18, 10 December 2011 (EST)

I looked through the server logs, and I can see where you were accessing and updating Elizabeth Belcher. It looks as though somehow you were using the old version of the gedcom review program, which is odd, because I thought I had bumped up the version number to force everyone to use the updated version. Anyway, I bumped up the version number again; could you try this once more? Bring up your gedcom for review, press "Control-F5" to force the browser to get the latest version of the gedcom review program (or even better, clear your browser cache before reviewing the gedcom, but control-F5 should work), then try once more to edit someone. Please let me know if it still doesn't work, and let me know who you edited like you just did, so I can review the server logs to see what happened. By the way, I tried this in IE8 (with the updated gedcom review program; I didn't think to try it beforehand), and it worked.

As for place drop-down lists, they should work in all the places they used to. I haven't made any changes. I've never added place auto-completion to the Search or Add Page forms - maybe that's where you're not seeing it? It should be there in the place fields when you edit a page however. One thing that would be helpful to know: when you click on this link, do you see text that begins with response header status 0?--Dallan 22:49, 10 December 2011 (EST)

Sorry, still not working. I cleared browser history and used ctrl-F5 and changed William Clisby (removed bold in citation). Same bug. Then I rebooted and changed Amy Gilbert (2 changes in a citation) - same bug. I checked the link (both before and after I rebooted) and it shows text beginning with response header status 0. I also tried editing an existing person page and the place auto-complete is not working. (Neither is the journal auto-complete working when I add a new source page for a journal article.) Is the auto-complete Java? --DataAnalyst 10:00, 11 December 2011 (EST)
Ok, I might have found the problem. It appears that both problems have the same root cause. The next problem is how to fix it :-).
The problem is that when you click on the "submit" button after editing the page, some javascript needs to run to tell the gedcom review program that you've updated the page. It's not running. Similarly, the javascript needed to run for auto-complete (javascript is needed; java is not) isn't running either. Javascript could either be turned off in your browser altogether, turned off just for WeRelate, or an error could have been encountered while running the javascript for the edit page, which caused it to stop running. I have a few more questions to try to determine which one it is.
When you edit a page normally - not during gedcom review, does the place auto-complete work?
No
When you're looking at a person page in the gedcom review program, can you click on the "Spouse and children" or "Parents and siblings" links at the left and navigate to the family pages?
The screen changes, but it says there is no info on the family, even when there is.
When you're editing a page during gedcom review, can you click on a "Remove" link to the right of an event, source citation, or note to remove it?
Yes
If you exit the gedcom review program and re-open it, do you see your edits then?
Yes
Does everything work if you use Firefox or Chrome for gedcom review?
Haven't tried, and unfortunately don't have time right now.
Thank you for your help and patience with this.--Dallan 14:05, 12 December 2011 (EST)
See my answers above in italics. I have a meeting I have to run to - will check in later. --DataAnalyst 19:36, 12 December 2011 (EST)

For some reason I can't understand, javascript is running, but the (jquery) document ready event isn't firing on your browser. I can walk you through trying to figure out why, but at this point it may be less trouble to use a different browser or upgrade to IE9. If you're interested,

  1. Review your gedcom
  2. Click on "Developer tools" in the browser "Tools" menu. This opens a new window.
  3. Click on the "Script" tab on the left, and make sure that the "Console" tab is clicked on the right.
  4. Edit a page and save it
  5. Let me know what appears in the Console tab in the Developer tools window.

--Dallan 00:41, 15 December 2011 (EST)

Console shows the following line (13 times):
'addthis' is undefined wikibits.yui.28.js, line 1 character 24840

--DataAnalyst 16:05, 16 December 2011 (EST)

That helpful. I just made a change that could fix that problem. Could you try editing a page to see if the place drop-down is working again? If it is, could you try reviewing your gedcom again and editing a page in there? I've got my fingers crossed :-). Thanks.--Dallan 17:46, 16 December 2011 (EST)
Still not working. I updated Elizabeth Belcher before a restart and then Thomas Buckingham after a restart - same bug. Sorry. Will try Firefox soon.--DataAnalyst 19:39, 16 December 2011 (EST)
Sticking my oar in here, Data. . . . I would strongly urge you to download Firefox or Chrome. Both are excellent browsers, both are free, and I use them both, depending on what I'm doing. Both are continually increasing their share of the browser market, and for good reason. Internet Explorer has continually been losing share, also for good reason. Almost the only regular users of IE nowadays are those who have no choice -- corporate captives and such whose employers buy into the "only Microsoft" mantra and disallow non-Microsoft software on their systems. IE has a great many problems, and new problems in each new version, largely because of Microsoft's self-absorbed attitude that only they know the best (and only) way to do anything. Firefox and Chrome (because Google generally has more sense than Microsoft) pay close attention to their user base and respond to real or perceived problems very quickly. There. Got that off my chest. :-) --MikeTalk 08:05, 17 December 2011 (EST)

Dallan - I feel like I've sent you on a wild goose chase, because my husband finally found the problem on my end. We installed an anti-adware hosts file, available from http://winhelp2002.mvps.org/hosts.htm, that maps known ad and malware sites to 127.0.0.1. Some site in that list must be one that you are using, because when we revert to the default hosts file and flush the DNS cache everything works. We've tried it twice to confirm. If you would be able to take a look at that list and identify which site is needed, we could comment it out and still be protected from other sites.

The hosts file affects all web browsers and internet communication. (I had previously confirmed that using Firefox did not fix the bug.)

I assume you know this already, but (for the benefit of other readers) in Windows the hosts file is found in c:\windows\system32\drivers\etc. Changes to the hosts file take effect immediately, but because of dns caching on newer versions of Windows it's always advisable to perform an "ipconfig /flushdns" after making changes.

Sorry that it took us so long to figure this out - I hope this did not waste too much time on your end trying to "fix" the javascript. But at least we know what it is now. Let me know if you can't find any site in the hosts file that seems to be causing the problem - another possibility is simply that this list is too long, so we could try shortening it. Thanks for your patience working on this. --DataAnalyst 09:52, 17 December 2011 (EST)

I'm glad we got to the bottom of this! It looks like the hosts file you mentioned includes http://s7.addthis.com. We (and many other websites, including apparently whitehouse.gov) use AddThis's buttons to make it easy for people who want to share their pages on Facebook, Twitter, Google+, etc. And disabling that causes the other javascript that should run after it on the page to also be disabled. I'll change it the next time I'm in that code so if addthis is disabled, it doesn't impact the rest of the javascript. But you might want to consider removing addthis from your copy of the list.--Dallan 00:10, 18 December 2011 (EST)
Thanks - I have re-instated the hosts file with "addthis" commented-out and the javascript seems to be working for me now. --DataAnalyst 17:16, 18 December 2011 (EST)

Down for maintenance message [17 December 2011]

The down for maintenance message is still on the home page.--Beth 18:53, 10 December 2011 (EST)

Odd - it doesn't show up for me. I've just done an empty edit of the page. Maybe you can force a refresh of your browser window?--Dallan 22:10, 10 December 2011 (EST)

Thanks, that worked. No longer seeing message.--Beth 07:44, 11 December 2011 (EST)

Wow! The new server (I assume that's the reason for the change) just screams through my watchlist. It probably is taking less than a quarter as long, maybe better.
That's good - I'm glad to hear it.
The search results now show recent edits in the list. I can deal with it just fine, but I wanted to note that I am not particularly fond of this change. I liked the recent edits better on the side. Now, they don't seem to be ordered by relevance, rather, all recent edits come before the other pages. I tend to work on a whole family, so most of my recent edits tend to have the same surname, same locations. I find that most of the time I don't want a recent edit, so it pushes the more likely candidates down, often out of the visible are, even if there is an exact match. The saving grace is that things seem to get cached quicker. --Jrich 16:28, 17 December 2011 (EST)
I see what you're saying. I don't want to move them back to the side, because we're having problems with people creating duplicate pages within a few minutes of each other, and I'm hoping that putting them at the top of the search results list will make it more obvious to choose a recently-added page instead of creating a duplicate. But I can make them take up less space vertically, so you don't have to scroll down so far to get past them. I'll do that on Monday. And yes, we're indexing changes every 15 minutes now. I'll try shortening that to 10 minutes, which should also help.--Dallan 00:10, 18 December 2011 (EST)

Upload a Big Gedcom [3 January 2012]

Hallo Dallan,

A Friend Genealogist asks me to upload his Gedcom, but his Gedcom contains 15.000 individuals. His tree is a good addition to my tree, that's why i'd like to have his Gedcom on Werelate. I understand it's going to be a lot of work, but i have uploaded my own tree with a lot of individuals to, i now better understand how Werelate works. Could you give me permission to upload this Gedcom?

JSFaber--Jsfaber 11:07, 3 January 2012 (EST)

Hi Jaap-Sip and Dallan, I hope you don't mind me jumping in here. I have had the experience of uploading a gedcom that was greater than 5000 people, and I would strongly caution against taking this approach. It is far better to split the gedcom into smaller chunks and process each separately. If this is a Dutch gedcom (which based on your message I assume it is) you are going to have many, many family matches. These do take a lot of time to process and clean up. It is also preferable from an administrative standpoint to upload a smaller gedcom because the WR admins can help process it - larger files require Dallan to import the file differently than others. WeRelate does sometimes allow files larger than 5000 people, but this is usually for files that are only slightly above the limit that would be tough to split up. If you need any advice on splitting up a large gedcom, I am sure that Klaas would be able to help. --Jennifer (JBS66) 11:40, 3 January 2012 (EST)

Error message on user talk page [23 January 2012]

Dallan, User:Susan Irish mentioned that when trying to leave a message on a new user's talk page, she received the following error message "This site has restricted the ability to create new pages. You can go back and edit an existing page, or sign in or create an account." The user had not yet been welcomed and no messages appeared on his page. I can see the Add Topic link and can add a message, but Susan cannot. This is not the same message I get when trying to leave a message when not signed in, or on the sandbox when I use a non-admin account. I'm not sure why this might be happening. --Jennifer (JBS66) 16:15, 22 January 2012 (EST)

I fixed this bug and left a message on Jennifer's talk page.--Dallan 10:02, 23 January 2012 (EST)

Changes to search? [23 January 2012]

It seems that changes have been made to search recently. As of 20 Jan I could enter the word Unknown in a given or surname field, and the pages with Unknown in the title would be returned. This is no longer working. --Jennifer (JBS66) 05:06, 23 January 2012 (EST)

Sorry - this is working again now. Over the last couple of days some "Unknown" names will have gotten removed from the index. They'll all show up again in a couple of weeks.--Dallan 10:02, 23 January 2012 (EST)

Deleting trees and watched pages [21 February 2012]

Good morning Dallan. See Family:Kay Ottenberg and Unknown (1). The person page for Kay Ottenberg has been deleted. So the user who was watching the family page is now watching an empty page. Can we minimize the deletion impact by extending the "no deletion" of watched pages to the husband and wife if a person is only watching the family page?--Beth 07:56, 19 February 2012 (EST)

Can you add that as a suggestion to the WeRelate:Suggestions page?--Dallan 21:59, 21 February 2012 (EST)
I added this on the suggestions page. Thanks. --Beth 10:57, 26 February 2012 (EST)

FamilySearch links [11 March 2012]

FamilySearch links from source pages have not been working for a few days. I get various errors, including "An error occurred on the server when processing the URL. Please contact the system administrator." If I change the Eng/Library to eng/library they work again. --Jennifer (JBS66) 12:05, 24 February 2012 (EST)

I sure wish they wouldn't change their URL structure. I know I need to eventually turn the URLs into templates. In the meantime, on Monday I'll lower-case the Eng/Library on the fly when displaying those pages.--Dallan 01:43, 26 February 2012 (EST)
We have the same problem on place pages that have the FHLC link. --Jennifer (JBS66) 10:01, 11 March 2012 (EDT)
I modified the fhlc template to lowercase Eng/Library. I think the take-away is that whenever we link to the fhlc we should do so using templates.--Dallan 22:45, 11 March 2012 (EDT)

Issue with Uploading GedCom [29 February 2012]

Hi Dallan, I don't know where to put this - I am having trouble uploading my GEDcom (new user - your wiki is amazing - I can't wait to delve in!)

So I uploaded my tree two days ago, and yesterday went through and corrected all the warnings and errors. I deleted that tree on WeRelate and uploaded the corrected one last night. It says in the instructions it should take 10-30 minutes but it has been several hours and it still says "PHELPS-Quinton_Hare-McAnelly2.ged Waiting for analysis". I deleted and re-uploaded in the first couple hours to see if that would fix it (it didn't) and it's just been sitting like that for hours now. It worked pretty quickly a couple of days ago, and the tree should only be faster now (fewer errors), so I'm wondering what I should do? Thanks for your help Marilyn--phel0049 05:58, 28 February 2012 (EST)

Every once in awhile the gedcom uploader gets in a situation where it crashes and waits for me to restart it. Yesterday was one of those occasions unfortunately. It looks like it imported successfully, after several hours' wait though.--Dallan 19:05, 29 February 2012 (EST)

Updating an image [8 March 2012]

I've done some additional work on an image, and want to upload a better version of the one I already uploaded. On Wikimedia Commons one can upload improved versions of an image, but I don't see that option here on WeRelate. Is there a way I can do this? Here is the image I want to update: Image:Banks_Family_Home_in_Michigan.jpg. — Parsa 14:25, 3 March 2012 (EST)

There's not a way to do that here, because we had people overwriting others' images with their own. Ideally the system would allow you to overwrite your images but not others' images. In the meantime, if you'll upload the image to a different (temporary) name and let me know what you've titled it, I'll update the original image.--Dallan 14:23, 6 March 2012 (EST)
Thanks, I'll do that. However, I just want to clarify something I saw in the section on uploading instructions I found on the Images Tutorial page. It says, "If your image filename happens to be the same as another already on WeRelate, you will receive warning message. If you choose to upload the image without changing the filename, the existing image will be overwritten." Is that no longer the case? And does the overwriting eliminate any text on the image page as well? — Parsa 19:03, 6 March 2012 (EST)
That used to be the case until just a few days ago, when I disallowed overwriting images because someone overwrote someone else's image and it seemed like disallowing overwrites was better than allowing them. The overwriting doesn't eliminate any text.--Dallan 17:58, 8 March 2012 (EST)

Urgent: GEDCOM Upload Merge Bug [17 March 2012]

I am in the process of merging a GEDCOM file and just started encountering a bug in the last hour or less. Check out the history of the children in this family Family:Samuel Boreman and Mary Betts (1). It appears that 2 updates are being done on some of the children, and the second removes info, such as birth and death events, and in one case, a citation. I have manually fixed the data. I have not yet looked for a pattern, but wonder if it has something to do with whether or not the person has marriages (and the marriage is identified as a potential match in the same GEDCOM file).

I checked out my contributions, and sure enough, they show the following:

01:33, 8 March 2012 (hist) (diff) mFamily:Samuel Boreman and Sarah Steele (1)(Propagate changes to Person:Samuel Boreman (6))

This family is farther down in my GEDCOM family matches, and I have not yet processed it - yet it seems to be updating the record that I am merging (Samuel Boreman (6)) without me being aware of it. There are other records in my contributions like this. As far as I can tell, this issue started with this family. I merged 2 families before this one that included children with marriages (and it looks like I merged info on one of the children, Person:Mercy Boardman (1)), and the double-edit did not seem to happen. Hopes this helps with tracking it down. Let me know if you need more info.

Another thing I have noticed in the last hour or so is that when I search WeRelate, I get all search parameters, not tailored to the namespace I am searching in (e.g., Person). This happened to me before when the javascript was not running correctly, when I was blocking the addthis webpage. As far as I know, I have changed nothing on my side, so I should not be blocking addthis, but maybe something else is getting blocked that is needed, or something else is interfering with javascript on my workstation.

I'll stop doing merges until I hear from you. Thanks--DataAnalyst 21:08, 7 March 2012 (EST)

BTW - I hope that checking into this problem does not require you to remove my GEDCOM file. I have invested several hours in tedious source matching and edits that I would rather not lose. Thanks.

--DataAnalyst 23:24, 7 March 2012 (EST)

Here's what I think is happening. When you match and merge a family, you're updating not only the family page, but you're also potentially updating the person pages for the husband, wife, and children. So in the case of Person:Samuel Boreman (6), his person page was updated when you merged Family:Samuel Boreman and Mary Betts (1), because he's listed as a child in that family. When a person's parents' family and their spouse family are both identified as potential matches, then the person will be updated during whichever merge you do first: either the parents' family or the spouse family. You should be able to continue; we shouldn't need to remove the gedcom file.--Dallan 18:38, 8 March 2012 (EST)
Sorry, Dallan, but I am pretty sure there is a bug. You are right that I was merging the husband, wife and children pages as well. The problem is that the children pages were updated twice - once with the merge that I controlled and that ended in a correct web page, and a second time that I did not submit, and that removed info (such as birth and death dates). If you look at the history, you will see two updates with the same timestamp, both saying "(add data from gedcom)" - but I only did one of those explicitly. The second one was done without my requesting it, and invisible to me, until I went looking for it. Does that make sense?
The GEDCOM upload merge is definitely working differently than it did the last time I used it - I have used it quite a bit and have not had this problem before. Also, I uploaded the exact same GEDCOM file about 3 weeks ago so that I could preview where I needed to manually update WeRelate. At that time, it proposed matches of 187 families. I cancelled it and then uploaded it again, and this time, it proposed matches for 231 families. I checked a few that did not have match proposals last time, and the families it proposed matching to this time were not new data. So the matching algorithm has clearly changed in the last 3 weeks. Could this bug have been introduced at the same time?
I can try out one more upload merge tonight to confirm the bug. --DataAnalyst 19:36, 8 March 2012 (EST)

Merged some more records from my upload that appeared to have the same characteristics as the ones that had the problem. These ones worked correctly - only a single update and no data removed. I will keep going and let you know if I have any more issues. --DataAnalyst 21:13, 8 March 2012 (EST)

Another issue - I was just able to merge a GEDCOM upload with a semi-protected family. All I did was add sources (and in a couple of cases replace existing sources) and correct one death date - however, WeRelate has never allowed me to do this before. I was already on the watch list of the family in question, but I don't think that has made a difference before. The family is Family:Nathaniel Foote and Elizabeth Deming (1). I corrected daughter Frances' death date and replaced 2 sources on daughter Elizabeth's record (in addition to adding sources to some of the other records). (The earlier bug - double-updating - did not occur.)--DataAnalyst 21:57, 8 March 2012 (EST)
Thanks for pointing out that the person had been edited twice in a row. I missed that. Upon further research it appears that the entire family was updated twice, one immediately after the other. This might have happened if the update button was double-clicked, or perhaps there was another reason. Regardless of the reason, on Monday I'm going to keep families from being updated twice in a row during gedcom upload. That should prevent this problem from happening again in the future.
You're able to edit semi-protected pages because you've been listed as a "trusted" gedcom uploader - one who is more careful with updates during gedcom upload.--Dallan 19:38, 11 March 2012 (EDT)

The bug of the double-update during a GEDCOM merge just happened again, on record Person:Samuel Wright (40). The first update was correct, and the second one removed the death date. I manually reverted to the version with the death date. --DataAnalyst 21:27, 14 March 2012 (EDT)

Now that I think about it, it is possible that I selected the update button twice, before the page had refreshed. I had thought my mouse had missed the button the first time - this probably explains the double-update, but not why information was removed in the process. But at least I should be able to avoid the problem if I am a bit more careful about selecting the update button. --DataAnalyst 22:22, 14 March 2012 (EDT)
I've made another change; hopefully it won't happen again. Thanks for your patience.--Dallan 23:21, 17 March 2012 (EDT)

Modifying page date [17 March 2012]

Hi Dallan,

What is the reasoning behind adding an updated modified date to a person page when only the family page of the person has been updated? Sample is this page Person:Walter McManners (1) which I will update soon but have not when this message was posted. Thanks. --Beth 22:38, 13 March 2012 (EDT)

The families that a person belongs to are stored on the person's page, so if a family is added or renamed, the person's page is updated.--Dallan 23:21, 17 March 2012 (EDT)

Places Tab "not matched" for "Facts" from Family Tree Maker gedcom [17 March 2012]

Hi Dallan, Should I worry about this? I'm trying to eliminate all "not matched" places in my Family Tree Maker gedcom, but FTM allows "Facts" to be created with a field called "Place or Description". WeRelate is looking for a "Place" for all facts generating "not matched" if it cannot match a place.

As an example, here is a fact for Military Service that is does not match a Place. (Military Service Fact) Enlisted as a Private in Verona, WI. Mustered into "K" Co. WI, 42nd Infantry.

How should I handle an example like this? Is it better to leave it "not matched", or should I move this information into the "Notes" section and delete the fact?

Thank you, Lou--Donkle3 09:55, 14 March 2012 (EDT)

WeRelate has separate fields for place and description, so if you like, you can edit the pages and move the descriptions from the place field to the description field. But it's not essential - you can leave it unmatched if you like.--Dallan 23:21, 17 March 2012 (EDT)

Bug in transfer of family info to person page? [19 March 2012]

Just did some work on Person:Joseph Daniell (4), now the names of his 3 wives are all blank in the display of facts (they are shown in the infoboxes). They do have the name fields filled in. I tried doing a minor edit and re-save of the page, and also one of the family pages, with no change. --Jrich 12:49, 19 March 2012 (EDT)

I changed the gender on Joseph's page from unknown to Male, and the spouse's names now appear. --Jennifer (JBS66) 12:52, 19 March 2012 (EDT)
Thanks, didn't even notice that, since the page had been previously created. --Jrich 13:01, 19 March 2012 (EDT)

Contained place [20 March 2012]

Hi Dallan, due to a series of redirects, Place:Begraafplaats Eikelenburg, Rijswijk, Zuid-Holland, Netherlands appears as a contained place under both Place:Rijswijk, Zuid-Holland, Netherlands and Place:Rijswijk, Noord-Brabant, Netherlands. It should only appear under Place:Rijswijk, Zuid-Holland, Netherlands. I've tried null edits and deleting redirects, but I can't figure out why it's still showing up under Noord-Brabant. --Jennifer (JBS66) 19:04, 19 March 2012 (EDT)

Thanks for reporting this. It's been fixed now.--Dallan 00:28, 21 March 2012 (EDT)

Selecting tree during edit does not watch page [26 March 2012]

If I click Trees from a page that I am not watching, and select a tree, the page is added to my watchlist. However, when I edit a page that I am not watching and select a tree before saving, the page is not added to my watchlist. I believe this is new behavior, as I've been able to watch pages in the past by selecting a tree during edit. --Jennifer (JBS66) 08:10, 24 March 2012 (EDT)

Working now.--Dallan 23:45, 26 March 2012 (EDT)

Searching Family Search [15 April 2012]

Hi Dallan,

Searching for James Luther Holder died in 1944 in Sabine Texas only brings up the death index searching all collections. Even added the name of his father. Finally found the death certificate image by removing the last name searching the specific database. He is listed as Halder. I noticed that you have changed the name variant pages. So I did confirm that Halder is a variant and saved. Hope these search improvements are added to the FamilySearch database. I don't have any confidence in my search capabilities and the search engines on any site. I cannot eliminate possibilities in research just because I have not found them; one of the frustrations in online research. However the benefits of online research outweigh the alternative of courthouse research.--Beth 20:09, 10 April 2012 (EDT)

A couple of companies have told me that they plan to use the results of the WeRelate:Variant names project. FamilySearch is not one of them yet.--Dallan 11:16, 15 April 2012 (EDT)

Living People [24 April 2012]

I have just recently updated my family tree on WeRelate by importing a new gedcom. I set the flags as 'Exclude details about living people' and 'Change name to 'Living. I was therefore expecting living people, like myself, to appear as 'Living' but without any details. However they haven't appeared at all. What have I done wrong?--Johnstona 17:41, 14 April 2012 (EDT)

You've done it just right. Pages for living people aren't created at WeRelate, unless they're famous enough to have a wikipedia page.--Dallan 11:13, 15 April 2012 (EDT)

Is this something which has happened recently? I restored a previous page and it records the wife as 'Living'.--Johnstona 17:09, 20 April 2012 (EDT)

It's been the policy for awhile now; I've made changes to the gedcom uploader to fairly recently (in the past six months) make it better at identifying and excluding living people fairly recently.--Dallan 20:16, 20 April 2012 (EDT)

The reason I restored the page was that according to my records the person (Simon Peter Dylke) was deceased but had not appeared in my latest GEDCOM upload. I wondered what data I had at the last upload but the restore shows that it is identical to the information I currently have. Why did it appear previously but not in the current upload? Also it is now floating on its own. How do I connect it to the rest of the family because the link is regarded as 'living'? Similarly the son (Simon Ronald Dylke) who is also deceased hasn't appeared. As a result of this I have disappointedly lost a lot of people who were previously published on WeRelate, making it less effective as these are the type of records where I have most hope of making connections with other trees. If I had known this was going to happen I might not have deleted the previous GEDCOM.--Johnstona 19:35, 21 April 2012 (EDT)

Like I said, I changed the gedcom uploader recently to make it better at identifying people who are living. If the person is deceased, go ahead and enter a death date. A death date tells the uploader that the person is deceased. To connect this page to the rest of your tree, say to a family that you have previously added, navigate to the page and click on the "Add parents and siblings" link. Then enter the parents you have previously added, and select that page when it shows up in the search results list.--Dallan 12:06, 22 April 2012 (EDT)

But the problem is that the person who links with the rest of my tree hasn't been imported because she is regarded as 'living'. She probably is deceased but I haven't got a date of death. As a result I can't add her husband (deceased) or children (deceased). Previously these people did appear on WeRelate because she appeared as 'Living' without any of her details appearing.--Johnstona 16:58, 22 April 2012 (EDT)

If you think she is deceased, then you can enter an approximate date for her death date when you create the page for her; e.g., "about 2009" or "before 2012".--Dallan 22:55, 23 April 2012 (EDT)

Very helpful - thanks very much. I'll go through my database and add these.--Johnstona 15:17, 24 April 2012 (EDT)


How do I see the code for ... [20 April 2012]

How can I find the code behind the following? I tried findin by typing the "name(s)" below and also tried to find it as a template.

{{{title-content}}}

{{{title-header}}}

{{{left-content}}}

{{{right-content}}}

What do the three curly braces indicate?

Thanks ...--cowantex 22:29, 17 April 2012 (EDT)

Those are template parameters. The best thing to do when working with templates is to look at the help pages at wikipedia. Just remember that we're using an older version of the wikipedia software, so some things that work there will not work here.--Dallan 09:41, 20 April 2012 (EDT)

Bug? [26 April 2012]

There seems to be a bit of a bug in this agent - see [2] for an example. AndrewRT 17:11, 25 April 2012 (EDT)

If you edit the wikpedia page, it shows {{convert|16|mi|km}} by {{convert|8|mi|km}}. It would appear that those templates are not available to WeRelate. Wonder if the agent tries to run them as WeRelate templates? For simple ones with no names conflicts, the template could just be brought over to WeRelate. For other cases, perhaps not, especially when differences in wiki code versions causes problems or if we already have a template with the same name that does something else. Is the agent even in an environment where it can execute wikipedia templates? If not, what to do? Create the WeRelate page with the raw code embedded it in nowiki tags: <nowiki>{{convert|16|mi|km}}</nowiki>? Some other stub to show there is incomplete text on the page? --Jrich 20:35, 25 April 2012 (EDT)
The problem is the agent isn't smart enough to know whether the templates on the wikipedia page have been duplicated at WeRelate or not. As you say, the problem is especially difficult because the template may exist at WeRelate but be different. I think we can either overlook the problem (like we do now), or we can remove the contents of all templates on Wikipedia pages, or we can put nowiki tags around the templates to display the raw text, as Jrich says. I'm not sure which solution is better.--Dallan 14:32, 26 April 2012 (EDT)

How to remove a spurious husband who hasn't a page [3 May 2012]

http://www.werelate.org/wiki/Person:Ann_Moncrief_%281%29 refers. I've managed to merge the Ann and Annie MONCRIEF(FE)s that existed, one from a fellow researcher's upload and the one from my subsequent update. But there's this spurious "husband" sitting there, and is what stopped my merging Ann and Annie at import time. It's place name, not a person, and if I try to "edit" the family I'm told to create a page. I've been round that circle without solving this so far. Hints please!--LornaHen 21:58, 2 May 2012 (EDT)

I removed the spurious "husband" from Ann's page. Does that solve the problem? I first tried to remove the spouse and children from the spurious family page but was not able to do so. Nor could I delete the page. Problem is the page does not have an ID and suggests you add the page which I did not wish to do. --Beth 07:47, 3 May 2012 (EDT)
Many thanks Beth, yes that solves the problem. thought I'd tried that but obviously not --LornaHen

GEDCOM ?? [17 May 2012]

GEDCOM ? - Just wondered if the last GEDCOM imported was okay . Have not heard or seen it yet merged into the Nash,Mahoney,Finn,Power,Ryan Family tree since upload a week or so ago .

Thanks . --HFR100HFR100

We're talking about mahoneywerelate, right? It looks like that one fell through the cracks. It's still sitting waiting to be reviewed by an admin. I've asked the people who review gedcoms to look at it as soon as they can. Thank you for being patient, and for letting me know about the problem.--Dallan 18:12, 17 May 2012 (EDT)

Next step: Review your GEDCOM [10 June 2012]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test-name.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.


--WeRelate agent 19:22, 10 June 2012 (EDT)

Redirects in trees [12 August 2012]

Hi Dallan, it appears that page redirects created by a merge still appear in trees (they appear in the tree total # under Manage Trees and in FTE but not in search). Is it possible to remove the redirect page from the Tree during a merge? --Jennifer (JBS66) 13:26, 25 June 2012 (EDT)

I've added this to my ToDo list. I'll implement it in September.

MediaWiki:Place types [29 August 2012]

Dallan What I meant was: can you put a link to MediaWiki:Place types on the editing screen of a place page--right beside the box for "Type"?

I have bookmarked MediaWiki:Place types for my own use in the interim.

Editing suggestions:

  • combine "historic" and "historical"
  • currently we have "district municipality" and "municpality district"

There are plenty of others, but those are the ones I remember from a browse earlier today.

Don't know whether you have seen my Portal proposal for a cleanup of Ontario (Canada) places. Ottawa is now done and some early-in-the-alphabet counties. /cheers --goldenoldie 11:36, 1 July 2012 (EDT)

I've removed "historic region" and "municipal district" since we have "historical region" and "district municipality". I'd remove "historic county" from the list, but before doing that we'd need to rename the types of about 50 historic counties in England and Wales.

I'll add a link to MediaWiki:Place types next month when I get off vacation.--Dallan 19:40, 12 August 2012 (EDT)


Last week I had a go at sorting out the list of MediaWiki:Place types. This was done "off-piste" and when I work out how to set up a spreadsheet table in wiki-speak I will present it.

But one point that is outside the list itself is that some descriptions fall into the general category of Inhabited Places and some don't.
Example: "hamlet" when written in the Place Type box arrives under Contained Places as "Hamlet" while "village" arrives under "Inhabited Places".
Since there may be little to differentiate between hamlets and villages, could hamlet be joined to the group eligible to be an Inhabited Place? --goldenoldie 06:37, 22 August 2012 (EDT)

That makes sense to me. I'll show Hamlet's under the general heading of "Inhabited Places" when I get off vacation next week.--Dallan 12:49, 22 August 2012 (EDT)

Just a couple of other quickies:

  • "town or village" would be better as "village or town" and
  • "city or town" better as "town or city"

because that's the way population usually grows.

  • and "prefecture" has also got into the list as "perfecture".

Continue to have a good holiday. --goldenoldie 14:02, 22 August 2012 (EDT)

I removed "Perfecture". I can't change "Town or village" or "City or town" right now without changing the type on a number of existing place pages. I've added them to MediaWiki talk:Place types so we don't forget about them. (I added a note about Historic county there as well.)--Dallan 10:29, 29 August 2012 (EDT)

Bible records [12 August 2012]

Hi I was wondering if we have a category for "Family Bible Records"? I was thinking it would be nice to be able to check and have them in one place. --Txbluebell6 08:08, 11 July 2012 (EDT)

We have Category:Family bibles; does that work?--Dallan 19:40, 12 August 2012 (EDT)

Updating GedComs [13 August 2012]

Dallan,

I'm considering resubmitting my Gedcons to We Relate. They hav'nt been updated sense 2010, and I have added a number of people and families.

To do this should I first remove my existing tree, and then proceed with the new expanded Gedcom upload, or can I upload the new without removing the existing?

Jim Tarbet--Tarbet 12:24, 12 July 2012 (EDT)

Tell you what - the gedcom re-upload capability has been completed by User:Npowell. I need to test it and integrate it into the website. This will allow you to re-upload your gedcoms without first deleting the old ones. Once I integrate it, the system will detect which pages in your current gedcom haven't changed since your previous upload, and will ignore those pages. I plan to integrate it into the website sometime in September. How about if you wait until then, and then you can help test it :-). I'll make an announcement on the watercooler when it's ready.--Dallan 19:40, 12 August 2012 (EDT)
Yea!! I have a small GEDCOM (abt 200 persons) with lots of dups that I want to re-submit. I assume that when there are changes to a page, the system will let you select which version to keep, not just automatically keep the latest version.... hoping... I'll be watching for this. --Janiejac 20:54, 12 August 2012 (EDT)
When changes are detected, it will treat it as any other potential match and let you choose which pieces of information to include in the merged page.--Dallan 06:59, 13 August 2012 (EDT)

Place redirects appearing in drop-down boxes [12 August 2012]

Hi Dallan, a few weeks ago, I renamed Place:Friesland Cemetery, Columbia, Wisconsin, United States to Place:Friesland Cemetery, Friesland, Columbia, Wisconsin, United States. I am wondering why both places are still showing up in the drop-down boxes. Thanks, --Jennifer (JBS66) 17:25, 12 July 2012 (EDT)

I'm not sure - only the new title is showing up now.--Dallan 19:40, 12 August 2012 (EDT)

Family from Germany [12 August 2012]

I have several Germanic families. What part of Germany does the ones your searchin for come from. Mine are mainly out of what is now the state of Rhineland Pfalz but was known as the Palatine, Hesse, and Germanic Switzerland. Ben--Treeshaker55 14:44, 11 August 2012 (EDT)

We have people from all over the world. I just did a search and found around 2000 people born in Rhineland Pfalz.--Dallan 19:40, 12 August 2012 (EDT)

Special Gedcom [19 August 2012]

Hi Dallan: I have a special file for pre 1650. As I'm a descendant of Edward Goddard and is connected to many noble and royal famlies of Europe which has been proven. If possible I could post this Gedcom but asking first before attempting.Its a work in progress because so much intermarriage of famlies.But I wonder if others would be intersted to link with that Gedcom for those truly interested in history? Just need a go or no go :>). I m still trying to clean up on the maternal line of both parents before attemptin a gedcom.--Treeshaker55 11:22, 18 August 2012 (EDT)

We already have quite a few pre-1650 people linked into WeRelate, due to Jrm's copying information from Wikipedia. If you were to upload a pre-1650 gedcom, you'd end up matching a lot of those existing people, and the matching would be complicated by name issues, approximate dates, etc. I believe you're better off to see who we don't already have pages for and add them by hand.--Dallan 16:32, 19 August 2012 (EDT)

Possible flash problem [1 September 2012]

Dallan, are you aware of possible problems with the latest version of Flash as they relate to FTE? I've never had a problem moving the vertical divider in FTE, so as to narrow the column of names on the left and widen the page being displayed on the right -- until now. As long as I don't touch the divider with the mouse, it's okay, but the instant I try to click on it, it locks up not only FTE but the whole tab that WeRelate is displayed in. I basically have to reboot the browser to get back to what I was doing. I don't seem to be having problems with other websites that use Flash. My version of Flash 11 is 11.2.202.235, downloaded in May -- I think that's the current one. --MikeTalk 17:32, 27 August 2012 (EDT)

I just tried moving the vertical divider in Chrome with Flash 11.3.31.225 and it seems to be working fine. What browser are you using? Could you try updating to 11.3?--Dallan 23:16, 28 August 2012 (EDT)
Well, the Flash plugin is now version 11.3.300.262 and I'm using the new Firefox 15.0 -- and the problem still exists. If I try to slide the vertical divider, it completely locks up the browser. I just tried it in Google Chrome and it seems to work okay there -- but I hate the way Chrome handles text-selection and cut-and-paste in wiki editing. Anyway, it appears to be a Firefox problem, but I have no idea what. --MikeTalk 06:31, 29 August 2012 (EDT)
I'm not sure why it's not working. I just updated Flash in my Firefox browser (it updated to 11.4.402.265) and updated to Firefox 15, and it's still working fine for me. I'm not sure what to try next.--Dallan 10:41, 29 August 2012 (EDT)
Well, Flash just tapped me on the shoulder with another update, which I've just installed -- and I can play the violin again! Or at least move the vertical divider. I'll settle for that. Thanks, Dallan--- --MikeTalk 21:04, 1 September 2012 (EDT)

Minor issue: user id lost by system [22 September 2012]

Logged in (user id displayed at top), perform "watch" on a page, page refreshed with banner saying you are now watching this page, but top now says "Sign in" and any attempt to do anything requires new login.

Use back arrow, return to last page logged in, now am able to resume work, system thinks I am logged in still.

Logged in, type search criteria into search box. Get to new page, top now shows "Sign in" and must login to edit. However, back up to page where last logged in, follow a link to same page, get there and I am still logged in and able to edit.

??? --Jrich 16:40, 2 September 2012 (EDT)

That's weird. Sounds like something's going wrong with cookies. We use a cookie to keep you logged in. Can you make sure they didn't get turned off in the browser?--Dallan 09:17, 13 September 2012 (EDT)
I can't repeat the search example, but both watch and unwatch seem to consistently produce this same symptom. Other activities don't, suggesting cookies are generally working. --Jrich 09:55, 13 September 2012 (EDT)
Can you tell me what browser you're using? Also, when you click on watch and get signed out, when you hit the back-button where you're still signed in, does the url start with "www.werelate.org" or just "werelate.org"?--Dallan 18:06, 14 September 2012 (EDT)
About Firefox says 15.0.1, Firefox is up to date.
URL displays as werelate.org/wiki/User_talk:Dallan
Perform an unwatch, top of page now says "Sign in"
URL now displays as www.werelate.org/w/index.php?title=User_talk:Dallan&msg=unwatched. --Jrich 10:18, 15 September 2012 (EDT)
I'm guessing you suspect some issue with werelate.org versus www.werelate.org. Following links that say www.werelate.org (e.g., "Show all pages changed since last visited" link points to http://www.werelate.org/w/index.php?title=Special:Watchlist&changed=yes) seem to give a page that says "sign in", but editing the URL in the navigation bar to remove "www.", then gives you the desired page with the user id displayed at the top (i.e., logged in still even though I navigated through a page that said I wasn't). --Jrich 10:07, 17 September 2012 (EDT)

I'm able to reproduce the no-longer-logged-in problem if I visit a "werelate.org" page (without the www) and click on watch, because it takes me to "www.werelate.org" and my cookie says I'm logged into werelate.org, not www.werelate.org. So I made a change to force all "werelate.org" URLs to automatically rewrite themselves as "www.werelate.org" from now on. That solves that problem at least. Does it solve yours as well?--Dallan 18:11, 22 September 2012 (EDT)

Yes it seems to. Is the problem that my bookmark that I was logging in on was not www.werelate.org? --Jrich 19:05, 22 September 2012 (EDT)
Yes. When you logged in, the cookie that tells the server you're logged in was saved under "werelate.org". But when you watched/unwatched a page, you got redirected to "www.werelate.org". As far as your browser is concerned, that's a different website, so it tells the server you're not logged in. I couldn't think of a reason to treat "werelate.org" and "www.werelate.org" differently given the confusion it causes, so the server now redirects all "werelate.org" requests to "www.werelate.org".--Dallan 19:17, 22 September 2012 (EDT)

Possible change in bot that processes source-wikipedia template [17 September 2012]

I'm taking the liberty of reproducing below an exchange I had w/Amelia:

I've noticed, on a number of pages where a WP copyright notice appears, instead of:
{{wikipedia-notice|William Carey (courtier)}}
You seem to prefer:
<show_sources_images_notes/>
{{wikipedia-notice|William Carey (courtier)}}
Am I correct in this? If so, there's nothing keeping us from making this standard behavior for the script that replaces the {{source-wikipedia|whatever}} template. Do you think this would work correctly on non-Person/Family pages? Do you think it would work correctly if there weren't any sources|images|notes to show?
I don't have a preference for one form versus the other - but I think one should be preferred. If you think we're better served by the second form - let's adopt it! We can ask Dallan to change his script to do that by default. I assume it would be trivial for him to do the in-place replacement of the source template with the specific wp page template, and then separately add the copyright notice at the end of the page. I'll try to remember to make that change when the opportunity presents. Maybe converting old forms could be an early task for those of us who will be beginning bot writers? --jrm03063 11:32, 4 September 2012 (EDT)
I like the latter because I think that "footer" shouldn't go in the middle of the page. Even if there is other content that's not WP, the style of the notice is inappropriate as a divider, at least to my eyes. Hence I add the show line wherever I'm otherwise editing. I assumed that it would break something to have it be automatically added, but that would be lovely.

So - long and short of it - can you add the show_source_images_notes tag to the substitution? When appropriate? Thanks!--jrm03063 08:41, 6 September 2012 (EDT)

Any chance that the <show_sources_images_notes/> XML tag could just be embedded in the wikipedia-notice template? I tried to make a test that would do that, but I'm afraid my wiki syntax wasn't up to the task. --jrm03063 11:06, 7 September 2012 (EDT)

The show_sources_images_notes tag can't be added to the wikipedia-notice template unfortunately, but it would be fairly easy to make the wikipedia-bot add it before the wikipedia-notice template if you like. Another bot would have to be written to update the existing pages - would you like to write that?--Dallan 09:14, 13 September 2012 (EDT)
Sounds like there's plenty to do... :) --jrm03063 13:40, 17 September 2012 (EDT)

New User and Impressed [1 December 2012]

I am new to the wiki, but have been very impressed so far. I have used One Great Family for years and became very dis-heartened when data that I had cleaned up a week before was messed up again. My full line built very fast there and I connected with royalty which sent my line all the way back to Adam by several routes. But I could not download more than a few generations at a time. Large tree sections would take days to try and download. Often the downloads contained zombies, (living people 150 to 6,000 years old). Since they were living their data was not downloaded, just the word "living" and perhaps a surname.

I find the review process of WeRelate very encouraging. Errors are being corrected before trees are connected. This process also helps us to update our data on our home computers and in our favorite genealogy program.

One Great Family, Ancestor.com, and Family Search, and others all just take the gedcom, as it is, and upload it. Errors, zombies, and all are dumped into the database. error corrections are never permanent, and error builds upon error. One of my Thomas Barneses had hundreds of children with different last names. It became impossible to clean up.

You are doing a great job.Keep it up.

Ron--Rgbarnes 11:40, 20 September 2012 (EDT)

Thank you! That's nice to hear :-)--Dallan 18:13, 22 September 2012 (EDT)

I'm also a new user of WeRelate, and as the first user am very impressed with the error correction and clarification process before a gedcom is accepted into the system. It gives me great confidence that any information I gleam for these trees will be well-researched and documented.The site found many errors in my gedcom that had slipped through the cracks till now, and I appreciate getting them corrected in my tree. NOW FOR MY QUESTIONS: First--is this the proper forum to post my questions about anything I can't figure out how to do? Second--I think I've completed going through my gedcom and correcting/documenting everything in all the tabs. Now, how do I indicate I think it's ready to be considered to be a part of the site? I can't find any tabs/menu items that seem to do that. Thanks so much for everything and I look forward to hearing the answers.--Jaynes931 18:32, 23 November 2012 (EST)

This page is meant to serve as a location to post general support requests, although this page is more specific to your query. I regret that I havn't done a GEDCOM upload in a while, and I don't recall the exact nuts and bolts. --jrm03063 20:32, 23 November 2012 (EST)

I'm already enjoying having my tree actually on the site. It's so exciting to learn the things that other people have already researched about my family. Thank you so much for your help. I've noticed a couple of typos in some of my comments and I figure there's a way to edit them, but so far I haven't figured out how. Is there a tutorial teaching me how to use my wonderful new tool? Thanks again, Mary Jean--Jaynes931 00:20, 1 December 2012 (EST)

Thank you! If you want to fix a typo, click on the "Edit" link either in the left-hand sidebar, or to the far right of the heading for the section you're trying to edit. I hope that helps.--Dallan 01:34, 1 December 2012 (EST)

Massachusetts Vital Records Project [23 October 2012]

I sent you some email a while back indicating that I was talking to John Slaughter, steward of Massachusetts Vital Records Project. With data that he provided, I've created a couple of sample transcript pages from the Vital Records for Bradford, Massachusetts, in particular - page 61 and page 215. I would like to know if I can tentatively expect support like that which you provided for Savage. Thanks.--jrm03063 15:12, 23 October 2012 (EDT)

I know this is a late response, but yes. Just let me know when you're ready.--Dallan 07:23, 11 November 2012 (EST)

Duplicate Image [4 November 2012]

I have tried to add a few images. I was having trouble in the beginning but I did work through my confusion. I have 2 of the same images in my file and ask that one of them be deleted. The image is Paul Baier-1867-pg 331, Line 7(pdf file). It was created on 28 oct 2012. I saw a note that send to send a link to the image, but I don't know how to do that. Thank you.

Sharon Reynolds Connolly--SharonReynoldsConnolly 10:08, 4 November 2012 (EST)

Left a message on user's talk page. --Jennifer (JBS66) 16:24, 4 November 2012 (EST)

Migrating to Wikimedia [13 January 2013]

Hi, I noticed you discussed extensively about migrating WeRelate to Wikimedia on this page, and you offered to bring it up at the watercooler. Has there been any news since then? -- Ypnypn 12:43, 31 December 2012 (EST)

I'm going to presume to comment, since Dallan can be a little hard to reach and I've got an opinion anyway! I just skimmed that page - and it looked to me like getting the WR code base to the point of being a reasonable open-source project is a practical pre-requisite. To my knowledge, Dallan is still working on that. Further, I'm not aware of a wider discussion of doing something like this yet - though such a discussion might be confined to the oversight committee. As far as I can see - the primary benefits would be prestige and/or credibility. I wouldn't expect any immediate up-side from the perspective of most users. Is there a particular benefit that you see from such an affiliation? --jrm03063 14:32, 31 December 2012 (EST)
I've been on a full-time consulting contract and don't have a lot of free time right now, but the plan is to bring this up on the watercooler to get reactions to the idea. Yes, it requires me to migrate to the latest version of MediaWiki, and I don't see any particular change that it would make from the perspective of most users other than being able to remove the google ads. I'm going to start taking Friday's off this year, so hopefully I'll be able to make more progress in migrating the codebase.--Dallan 07:59, 13 January 2013 (EST)
Have you noticed that, in spite of the huge increase in productivity brought about by contemporary tools (relative to what I presume you and certainly I started with), there are still not enough hours in the day to accomplish what needs to be done? I sometimes feel like there's a perverse and sadistic variant of Moore's law at work here. Research appropriate for an Ig Nobel I should think!  :) --jrm03063 11:10, 13 January 2013 (EST)

Propagating GEDCOM data? [23 January 2013]

Yesterday a page I happened to be on the watchlist for was changed by a GEDCOM upload. The GEDCOM added a marriage to a person who had previously only a birth. When I looked at the Family page for the marriage, the person's information was different than what I saw on his Person page. Among other differences: the family page showed the surname capitalized, the double/dating of the birth date and location of birth were removed, there was a death date added. I.e., the information shown on the Family page looked like what I imagine was in the GEDCOM, even though the actual Person page had no changes other than the addition of the marriage. In the History for the Family page, look at the older versions to see this, while the history of the Person page shows no version that had these changes. I assume the Family page is different because the GEDCOM version of the Person page was propagated to the Family page? Even though the GEDCOM person page wasn't or hasn't yet been stored. Finally I edited the Person page to make some other changes and everything is again consistent.

Now the GEDCOM upload process has multiple steps and may take a user several days to complete, so I am wondering if the observed differences portended pending updates already stored, or if the user will do their final merge of Person pages using a dynamically-loaded realtime version of the page? Further, what effect will my edits will have on the whole process? Will the changes I make cause an error because the page no longer matches? Will it confuse the user because the page doesn't look the way it did when he matched the Families? Are the user's changes stored pending completion of the process, when their updates are applied in bulk, wiping out the edits I did today? On top of those worries, this could be (i.e., was) confusing, to see information on a Family page that can't be found, so that one can't do edits to fix it or see the attached sources, etc.

Don't know if there is any need to mark a page as being involved in a GEDCOM upload, as a warning to other users. I just get notified of changes when the page is saved, and it is hard to tell if more is coming or not. Of course, there is the issue of how long it can take, and whether it gets abandoned. --Jrich 12:22, 23 January 2013 (EST)


Jonas Ullberg 1706-1770. [24 February 2013]

Hello Dallan, I am new on werelate so I do not understand from the set up of this system if you are interested in Jonas Ullberg or you are a watcher to all what is happening on werelate. In any case I ask you to superwise me on the use of werelate. See my article about Jonas Ullberg wchich should be of interest to his family. What will be the best way to make it possible for them to find this information and search and check for swedish history and swedish churchbooksfacts? I live in Norway and are not related to Ullberg, but I found the misspelling of the names "hellberg" og "ullberg" so interesting that I wished the right persons to be known with it. I think that only a genealogist would be able to put together historical and genealogical material so a 250 years old misspelling of a name would come to the surface. Is a point like that within your specialities? --Frank Burmann--Frank Burmann 16:10, 17 February 2013 (EST)

Hi Frank. I looked at Person:Jonas Ullberg (1) and clicked on the History link to see that the only contributor is User:Dlongmore. There are a couple of things you could do to tell people about your research.
  • Leave the information on Person:Jonas Ullberg (1), or leave a URL that points to your article if you've already posted it on a different website.
  • Go to User_talk:Dlongmore and leave a message, telling them about your article.
--Dallan 22:02, 24 February 2013 (EST)

Main Page [8 March 2013]

Hi Dallan,

The main page recognition article doesn't appear to have changed for a while. Is this something you are open to anyone doing with the direction of the nominated pages and the guidelines that are there?

Jeffrey--JeffreyRLehrer 21:30, 4 March 2013 (EST)

User:Delijim is currently volunteering to change the featured page, but I'm sure he'd love to have some help! I'll leave him a message on his talk page. Perhaps you'd like to leave him a message as well?--Dallan 11:58, 8 March 2013 (EST)

Congratulations on your consulting [20 April 2013]

I was glad to see you say that you had secured a full-time consulting position with a company which was occupying your time. Good to hear someone secure full employment in the current economic environment. --ceyockey 05:43, 16 April 2013 (EDT)

Thanks! Unfortunately we're behind a bit in development - trying to get a beta out soon - so I haven't been able to spend as much time on WeRelate as I would like lately. I'll let you know when we have something to show though; I think it will be pretty interesting.--Dallan 21:44, 20 April 2013 (EDT)

Rating the suggestions [21 April 2013]

I guess counting the number of folks who watch a suggestion is one way to rate which suggestions might need your first attention; but I'll bet you could get a pretty good picture if you'd start a "Pet Peeve" page. I'm thinking of little things that cause big frustrations. Like missing a button here or there. Nothing major, but little things can cause the frustration level to go pretty high.

While I have your attention, I will add that by removing accomplished suggestions, you are losing the psychological impact that a crossed off list of items accomplished would give. Let us see what is being accomplished so we don't give up hope. Right now my bucket of hope is pretty low. --janiejac 22:36, 20 April 2013 (EDT)

Not removing accomplished suggestions is a great idea. You've probably noticed that suggestions aren't getting implemented right now. The problem is that I'm working more than full-time for a genealogy start-up, trying to help them get launched later this year. Once I help them get launched, I'll be able to spend more time implementing suggestions on WeRelate.--Dallan 10:44, 21 April 2013 (EDT)

Raw HTML appears on WeRelate pages [16 May 2013]

Dallan,

I have been using WeRelate just a short time but started noticing raw HTML code in some of the drop-down menues. I am using a MAC-book computer and have made a screen shot of a page that exhibits this. I can email you the screen shot if you wish.

Best regards,

Richard -Rcampbell14 10:53, 15 May 2013 (EDT)

I have also noticed this from time to time, and it goes away on its own (maybe after I close IE and open it again - can't really remember). I think I figured out once that it might be related to an update occurring to WeRelate since I had logged on, but I could be wrong. I use a PC and IE 9.--DataAnalyst 21:42, 15 May 2013 (EDT)
This is an intermittent issue that I believe is caused by the WeRelate system being busy. It can be ignored. --Jrich 11:17, 16 May 2013 (EDT)