User talk:Dallan/Archive 2010

Watchers

Topics


Imported GEDCOM... awaiting analysis [15 March 2010]

what analysis needs to be done, does my tree need to be approved by a human as opposed to a script/bot? Sorry to be a pest but uploaded it an hour ago anf dying to try out werelate. feenydev 14:33, 1 February 2010 (EST)

Welcome to WeRelate. There is a problem with the importer this afternoon. It seems to be hung on someone else's import. I'm sure someone will kick it and let things go through soon. You will receive an email when yours is ready to review. Sorry to keep you hanging. --Judy (jlanoux) 17:29, 1 February 2010 (EST)

Feature Request: Date Handling [12 January 2010]

As long as we're queuing up various feature requests, I'd thought I add one.

Besides the oft-mentioned request for sorting of marriages by date, I have encountered several cases where child sorting doesn't work. I believe this is because WeRelate doesn't correctly handle various legal GEDCOM dates that occur sometimes. On the sandbox I created a page to illustrate two of the issues. A brief facsimile of how the results end up being ordered is:

Children:
Child2 Doe Birth: Aft 6 Jun 1683
Child1 Doe Birth: Bef 6 Jun 1683
Close2 Doe Birth: 28 Feb 1686/87
Close1 Doe Birth: 1 Apr 1686

In this family, child1 should sort before child2. These implement the case where all we know about their births is based on being mentioned, or not, in the grandparent's will, so one birth is before that date, and one birth is after that same date. Obviously the before should sort first, and after second.

Also, close1 and close2 are born nearly 11 months apart, but sort in the wrong order because WeRelate doesn't handle double dating correctly. Instead of ignoring the second year, it should use the second year. Or as a shortcut, if the slash is there, add one. In this case, close1 was born before close2 and so should be listed first. --Jrich 20:48, 20 November 2009 (EST)

Dallan would have to cue up a list of prefixes for the sorting algorithm to ignore, but I expect users will keep coming up with new variations: "b", "bef", "before", "ante", "ant", etc (all of which I have seen used). TMG seems to manage this pretty well, automatically converting whatever you type in into a standardized display format. I don't know if that sort of mechanism is programmable in a wiki or not, but that might be the preferred solution. I would think it would make searching easier, too. On the double-dating, the format I was taught, and which I see in the journals, is "1686/7" or "1689/0" -- only one digit after the slash. I tend to convert the dates to modern style for convenience, sometimes with the notation "O.S." in the following note as a reminder. --Mike 10:46, 21 November 2009 (EST)
The GEDCOM specification says to use two digits for the second year. (YEAR_GREG:=[<NUMBER>|<NUMBER>/<DIGIT><DIGIT>] - the year is either a number, or a number followed by a slash and two digits).
If you put the date in modern style, I would assume you would mark it "N.S" as I would interpret "O.S." to meant the date is in the old style, not modern. The problem with N.S./O.S. is that there is also the 10 [1600's] or 11 [1700's] day shift, besides the year and month numbering issues. So did you adjust for that as well, or are simply indicating the meaning of the year? This can quickly become ambiguous, so I think it is always safer to write the date the way it was written, only adding the double year notation when context makes it clear which of the two possible meanings the year should carry. Does 3 Feb 1682 mean 3 Feb 1681/82 or 3 Feb 1682/83?
It is clear many people are unsure about all this, and it would appear when they enter a date like 3 Feb 1682, which their home system must convert to 1681/82, when it should be 1682/83, because this is a common error I find on WeRelate pages all the time. --Jrich 12:56, 21 November 2009 (EST)
Well, since the notes are in my own database, on my own desktop, for my own use, I know what the note means, so I have problem back-forming it if I'm going to report it to some other researcher. But you're right, it ought to be "N.S." because that's what I've converted it into (rather than noting where it came from). But as regards the number of digits: GEDCOM is not a standard for writing or citation, and in this case it's simply wrong. Mills says to use a single digit, so does Professional Genealogy, so does Val Greenwood, and that's also the required style for the NEGR and the NGS Quarterly and TAG, and outside of genealogy, it's what the academic supplement to CSM recommends. All of which considerably predate GEDCOM. --Mike 09:25, 23 November 2009 (EST)
I am not sure it is a question of right or wrong, just a question of style. Certainly one digit is sufficient to indicate the dual year meaning. My software happens to enforce the GEDCOM form. If I enter 1739/0, it changes it to 1739/40. However you choose to do it is at home, if you upload by GEDCOM, it should be two digits when it arrives at WeRelate. Dallan could certainly enforce one display form, or the other. Displaying data with two digits would probably be easier because then he would only have to do formatting on manual input, without needing to convert back on the way out to mesh with GEDCOM. Obviously date handling is hard. The question is how important is it to have them handled correctly? Maybe we should prohibit any dates before 1753 :-). --Jrich 11:35, 23 November 2009 (EST)

It would be about the same amount of work to allow you to override the system-defined sort order. People have asked for this already to handle the case where they know child 1 was born before child2, but they don't have dates for either of them. Would being able to "fix" the bad sort orders when they occur be sufficient?--Dallan 17:34, 4 December 2009 (EST)


Yes, that would workaround this one symptom, perhaps the only place where this shows up? I'm wondering what other places this might affect, e.g., searching, though I'm not sure searching needs the precision of absolutely accurate dates to be effective. Certainly I would think if you wanted to add any verification of intervals (at least 7 months between children with different birth dates, at least 15? 17? years old when becoming a parent), the one year difference of the double dating could be significant. Fundamentally, I can't help but think that dates are so central to genealogy, date handling should be accurate. With luck, all the logic is in one place, and it could be fixed sometime when more need becomes apparent... --Jrich 18:25, 4 December 2009 (EST)


I agree with both approaches. Yes, ideally the WeRelate engine should automatically sort things in the proper order. But there should also be a function for those cases when you know the birth order (or at least suspect the birth order <g>), but don't necessarily know the dates. -- Amy 17:37, 5 December 2009 (EST)


I agree that dates are important. It's just that sorting relative dates (before, after, about) is never going to be an exact science. It's not possible to say whether "before 1850" comes before or after "after 1849". That's why I think that no matter what we'll need the ability to manually sort dates as well.--Dallan 18:32, 21 December 2009 (EST)


I just attempted a GEDCOM import and got six or so warnings. I believe 4 were caused by WeRelate not correctly handling double dating (event before birth because bap was 1699/00 when birth was late in 1699, event before marriage, and similar situations.)

I agree there is some difficulties sorting dates because the common usage mixes single dates with intervals. Most of the qualifiers actually turn a single date into an interval, usually not well defined, so it is difficult to sort. But I am not sure that issue prevents handling double dating. --Jrich 20:57, 22 December 2009 (EST)

Another place where this showed up: merging. Two pages, one had date 1 Jan 1690, the other was 1 Jan 1690/91. Since the system recognized these as the same date, the 1 Jan 1690/91 was green, and there was no way to reject 1 Jan 1690 and take the more precise and more accurate 1 Jan 1690/91. --Jrich 14:21, 12 January 2010 (EST)
I've added better date handling to my todo list.--Dallan 14:36, 12 January 2010 (EST)

GenWeb Sources [7 January 2010]

Dallan, I noticed that the GenWeb sources were not renamed to reflect the new geographic naming (ie Source:United States, Alabama, DeKalb. GenWeb). Can these be renamed automatically? Thank you!--Jennifer (JBS66) 10:15, 16 December 2009 (EST)

If the GenWeb page contains a transcription of a particular record set, then we should title it according to the place covered followed by the html page title. But if the GenWeb page is a collection of links, then I thought we decided in this discussion to migrate these sources over time to research guides. The problem is that the computer can't tell the difference, so it will require manual work unfortunately.--Dallan 15:06, 31 December 2009 (EST)

Thanks for the reminder, Dallan. I'll resume work on the Research Guide project. Jillaine 08:13, 1 January 2010 (EST)
Update: I don't think it makes sense to link to individual county genweb pages on a given state research guide page. I'm just going to point to the GenWeb page for that state. Jillaine 20:45, 1 January 2010 (EST)
Update Update: Actually, this is going to take forever. Dallan, is there a way to automate seeking and deleting all Source pages that contain "GenWeb" in the title that are also not linked to? Jillaine 21:05, 1 January 2010 (EST)
Good point. I'll add deleting GenWeb Source pages that are not linked to my todo list (not as a top priority though).--Dallan 13:21, 7 January 2010 (EST)

Large GEDCOM [11 January 2010]

I wish to upload a large Gedcom of 15000+ people. Can you help?--Glroberts 11:07, 20 December 2009 (EST)


I'm curious to know how you're going to handle this, too, Dallan, as I'm nearing ready with my 10k GEDCOM, which might reach 15k by the time I'm done. Jillaine 12:29, 20 December 2009 (EST)
Well, I'm curious how long you guys think it will take you to do all the reviewing and duplicate-checking. --Mike 10:54, 22 December 2009 (EST)
And mine will be a doozie-- it's a town genealogy of a small town in Germany with a limited # of surnames and generation-after-generation of recycling of given names. It will REALLY challenge WR's duplicate checking tool. Jillaine 14:05, 22 December 2009 (EST)
For now I'd recommend splitting it up into smaller files. Eventually I plan to make it possible to upload large gedcoms on a case by case basis, but that's a ways away. Mike's right that the main issue here is that reviewing/merging a large gedcom will take some time to do.--Dallan 15:08, 31 December 2009 (EST)
I've thought about breaking it apart into smaller chunks but have no idea how to do so. The challenge with mine is that it's so internally intertwined-- small town, intermarriages, brothers marrying sisters (not their own), etc. I'd appreciate suggestions. Jillaine 08:00, 1 January 2010 (EST)
Jill, I planned my uploads back at the beginning of my involvement in WeRelate by allocating each to one of my great-grandparents -- which also helped exclude living people -- but that obviously won't work for a community project. Do you have the project separated in its own datsaset? If so, I assume they all have ID numbers, #1 to #15,000, and you could be completely arbitrary, doing a GEDCOM of 1,000-2,000 at a time. I wouldn't make each one bigger than that, frankly, or you're going to get awfully tired of the reviewing process! The first couple of batches should be pretty straightforward, presuming not many will have pre-existing pages in WR, but obviously it will become more time-intensive as you proceed, with more overlapping families from previous uploads. I don't know what software you're using, but in TMG this would be pretty easy to do by defining a series of focus groups. Any good program should have something similar, though. That's the best suggestion I can come up, I think -- and you already know this is going to take you awhile to achieve, if you do it right. But it's also going to be well worth the effort. --Mike 13:00, 1 January 2010 (EST)
Fascinating. I use Reunion, and yes, I can mark people by Person ID#, and then export only marked people (with options to include spouses and/or children). A question I have is if I do NOT include spouses and/or children, how will the system "reconnect" these relationships once I've uploaded the separate GEDCOMs? Jillaine 19:36, 1 January 2010 (EST) (not Jill, please; thanks)
Hmmm. Well, TMG allows you to start building a focus group by identifying one person, then adding all that person's ancestors (for X generations), then adding spouses, then descendants (for X generations), etc. You can do this multiple times, excluding certain individuals in each step if you like. See if there's a similar process in Reunion that allows you to mark people by some kind of inclusion-pattern, not merely by listing all the ID numbers. That way you wouldn't have to "touch" each single person you want to include. If you can, and you're careful, you can end up with only a few duplicated individuals where one focus group (one GEDCOM) is tangential to another, and those can be merged in the review process. In a small town, as you noted, there's a lot of intermarriage back and forth, so you probably won't be able to isolate individual family groups for import; there's always going to be overlap to some extent. But that should be a lot easier to handle at WR than, say, on Ancestry. --Mike 23:15, 1 January 2010 (EST)

Jillaine, trying to split up your particular GEDCOM would probably take more effort than it's worth, since everybody's intertwined. When you're ready, the easiest thing is probably for me to make an exception so you can upload your entire GEDCOM at once. Going through the review process will be time-consuming for such a large GEDCOM, but since your GEDCOM probably doesn't include a lot of people that we already have, it may not take that long after all.--Dallan 13:26, 7 January 2010 (EST)

Thanks, Dallan. I think you're right. Actually, I'm very curious to see how the upload tool deals with all the internal "dupes" that are not dupes-- i.e., all the Anna Schlenkers born within the same year. It will be an interesting test. I think I still have a few more months before my gedcom is ready. Jillaine 22:14, 10 January 2010 (EST)


Double First Names [12 January 2010]

Dallan, this is related to my upcoming large GEDCOM. It has MANY MANY first names that are double names:

  • Anna Maria
  • Anna Catharina
  • Maria Magdalena
  • Johann Martin
  • Johann Friederich

In the case of this town, the individuals were distinguished more by their middle name than their "first" name. WeRelate is going to take the above names and split them into first and middle, and then title the person pages by the "first" name.

This will be completely wrong and totally mess up the intent of this GEDCOM. The second names must be included with the first names.

What if anything can we do about this?

-- Jillaine 12:58, 11 January 2010 (EST)

You could hyphenate the names; e.g., Anna-Maria. This should cause the GEDCOM uploader to create the page title using both names; e.g., Anna-Maria Goetz (1), yet both names can be searched individually; e.g., a search for Anna Goetz will return this person. I know that the online "Add page" tool works this way. If the GEDCOM uploader ends up not working this way then it's a bug and I'll fix it.--Dallan 16:17, 11 January 2010 (EST)
There's nothing that says the page title has to be exactly the same as the name in the "Name" field on the page itself. I have several Germans and Irishman whom I have page-titled with the name they used day-to-day -- generally not the baptismal name but the middle name. But I include the entire name in the name field on the page. And searching is done by the name field, right? Not by the page title? The same method works for Acadians, where a single family might include kids named Jean Paul, Jean Robert, Jean Christophe, and Jean Octave. And six girls whose first names are "Mary." Basically, the page title can be anything you want it to be. (Browse through the medieval peerage lineages sometime. . . .)
In the case of your pre-upload database: Do you have everyone filed by their full name already? (Baptismal name, middle name?) If so, you probably would have to go through and create an "alternate" name for whatever you want their page-title name to be (middle name only, or whatever). I've pretty much been doing that for years as I go along creating people, long before WeRelate. I can't think of a way to finesse the main ID names in your database by changing them to fit a pattern, since most of them aren't identical. (But you would have to edit each record to hyphenate them all anyway.) --Mike 16:38, 11 January 2010 (EST)
I'm getting a headache just thinking about this. I'm working on the database right now and it's approaching 11,000 names. Dallan, how does the gedcom upload tool handle /Anna Maria/ Schlenker? I'm sure there are other countries where this is a major issue, but if you want any serious contribution of German families, you gotta solve the double first name problem.
Mike, first name=Anna Maria; last name = Schlenker. I don't further distinguish the names. I do periodically use the AKA when I run into seriously divergent names or nicknames for the same person. Jillaine 17:09, 11 January 2010 (EST)
The gedcom uploader treats names surrounded by slashes as surnames. That's a pretty standard convention. So /Anna Maria/ Schlenker would be treated as a surname of Anna Maria, with Schlenker as a surname suffix. That's not what you want.
How do you handle the situation currently in your desktop genealogy program? I assume that you're entering both given names in the "given name" field. When you view a person or get a list of all people in your database, you see both given names, right?
It would be pretty difficult for the uploader to figure out automatically when the second given name should be used for the title and when the first given name should be used for the title. Therefore I think it needs to use the first given name (or use both if they're hyphenated). One approach to the problem is to figure out where you'd like to see the person's full name in the interface rather that just the page title, and make sure that the system displays the full name in those situations, not just the page title. Search results for example already list the full name, and I've been thinking that we should list the full name in big font for search results instead of the page title. Where else would you want to see the full name?--Dallan 20:17, 11 January 2010 (EST)

There is an element here of making the title too important. After all it is just the name of the page and probably wouldn't even need to be displayed. However, in search results, the page name of the parents and the children is displayed, not the name fields. They are for the subject of the search but not his relations. --Jrich 00:01, 12 January 2010 (EST)

That's a great example of what I'm looking for -- places where the title is currently featured but where the full name would be more appropriate.--Dallan 12:36, 12 January 2010 (EST)

Add data from gedcom behavior [23 January 2010]

Hello Dallan, I have a question about something that happened in a recent Gedcom upload. While updating this person, a place was automatically redirected to a potentially incorrect place. Nijkerk, Gelderland, Netherlands|Nijkerk, provincie Groningen. When I went in to remove what appears before the pipe, the software forces it to reappear. I couldn't locate a redirect within the Nijkerk, Gelderland page... Just curious why this might happen. Thank you.--Jennifer (JBS66) 09:15, 12 January 2010 (EST)

Here's what's happening: Whenever a page is saved, the system tries to link places on the page to Place pages. It first looks up "provincie Groningen" and can't find with this name, so it assumes that this is some descriptive text that you've added to the end of the place. (For example, sometimes people will add cause of death to a death place; e.g., "Groningen, Netherlands, died of typhoid".) So it ignores "provincie Groningen". Next it looks up "Nijkerk" and finds one in "Gelderland". So it assumes that's the place you want to link to.
One thing you could do that would solve the problem would be to add "Provincie Groningen" as an alternate name for Place:Groningen, Netherlands. Roughly 6-8 hours after you did this, if you were to removed "Nijkerk, Gelderland, Netherlands|" from the place and re-save the page, it would turn into a red link to Place:Nijkerk, Groningen, Netherlands. In fact, it would be helpful if you added "Provincie <province name>" as an alternate name for all provinces in the Netherlands.
I'll probably change how places are looked up in the future, but regardless of how they're looked up we'll still want "Provincie <province name>" listed as alternate names for the Netherlands provinces so they can be found by the system.--Dallan 12:36, 12 January 2010 (EST)
Thank you for the detailed explanation! I added the Provincie alternate names to the NL provinces.--Jennifer (JBS66) 15:08, 12 January 2010 (EST)
Thanks :-) Dallan 16:36, 12 January 2010 (EST)


Another somewhat related question... I noticed on a page that was saved, Amsterdam turned into Place:New Amsterdam, New Netherlands. This New Amsterdam page is a new one, doesn't really fit with our naming scheme, but... even though I created an Amsterdam redirect, this still happened. My thought is that redirects would take precedence. I did try to follow the above logic with this example, and I got a little lost :-)--Jennifer (JBS66) 06:22, 20 January 2010 (EST)

Redirects are ignored in place matching. (Including them causes other problems.) The problem is that Place:New Amsterdam, New Netherlands is two levels, while Place:Amsterdam, Noord-Holland, Netherlands is three levels, and the place matcher matches to the place with the fewest levels, so it matches "Amsterdam" to the first place instead of the second. This isn't right, but until I improve the place matcher I've had to delete Place:New Amsterdam, New Netherlands so that it stops causing confusion.--Dallan 13:11, 23 January 2010 (EST)

Categories [12 January 2010]

Another question... When looking at categories, the full page name appears, including the namespace. As a result, everything is sorted under P for place, or F for Family. Could it be beneficial to use the {{PAGENAME}} instead of {{FULLPAGENAME}}, so contents alphabetize properly?--Jennifer (JBS66) 09:22, 12 January 2010 (EST)

I could do this, but it would require some effort. If we went down this route you could have places and sources and images and people intermingled in the category page list. Is this what most people want?--Dallan 12:36, 12 January 2010 (EST)

There is value in segregating namespaces since their significant to the category may be different. If you're looking for sources to try, the source namespace might be interesting. If you're looking for a person, you might want Family or Person. Etc. And removing the namespace still does not result in proper alphabetization since it would still be by first name, plus with random types of other namespaces mixed in. Ideally, a table of contents to sections, one section per namespace, with Family and Person sections alphabetized by last name, then first, then birth or marriage date. Since you're asking... --Jrich 14:16, 12 January 2010 (EST)


Still too many emails [23 January 2010]

I complained about this six months ago [1] and it happened again -- 15 emails from a gedcom upload where there are no changes - just the computer reordering things. This strikes me as a pretty big usability problem when new users can't figure out what's going on when they get these emails. Where is it on the list of things to fix?--Amelia 12:24, 18 January 2010 (EST)

I just posted a call for votes on the WeRelate:ToDo List. I'd like people to vote on their most-desired new feature. This will help me focus on which features to add next.--Dallan 13:11, 23 January 2010 (EST)

Image Size [23 January 2010]

According to instructions images should be, if possible, 150 KB or less yet I see some at 400, 600 and even 1000+. What exactly is the rule?--HLJ411 09:41, 20 January 2010 (EST)

It's more of a guideline than a rule. Asking people to reduce the size of uploaded images reduces storage costs for the site, but I realize that many people don't have the technical skills to do so. To date we've had roughly 4 gigabytes of images uploaded, so it hasn't been a problem. If it becomes a problem then I'll have to enforce a maximum size (probably 1-2 megabytes) and have the server automatically down-size images above this limit.--Dallan 13:11, 23 January 2010 (EST)

Source - needs your help to delete/fix [23 January 2010]

Dallan, there is a source that appears within the Category:Connecticut that could use your help, Source:::: Public Library :::. Due to the colon characters, the page cannot be accessed to fix and/or delete. Thank you!--Jennifer (JBS66) 10:45, 23 January 2010 (EST)

Here is another one under Category:Hawaii, Source:::::Student Services:::: (transpacific.org/english/student/student f.html).--Jennifer (JBS66) 12:05, 23 January 2010 (EST)

Category:Illinois Source::: Cullom-Davis Library: Special Collections :: and Source::: Erlander Home Museum -Rockford, IL :: Category:Nebraska Source:::Wayne State College:: --Jennifer (JBS66) 12:50, 23 January 2010 (EST)

There are 98 sources that start with a colon. I'm in the process of deleting them right now.--Dallan 13:11, 23 January 2010 (EST)
Ahhh... you have advanced ways to find these pages :-) Thank you! --Jennifer (JBS66) 13:17, 23 January 2010 (EST)

Census data [23 January 2010]

Will you please point to instructions for listing census data correctly? How should it be labeled in the Census line and also in the Source area. Many thanks! Ruth Ellen Luehr-Richter-Opheim-Quandal--RELuehr 12:10, 23 January 2010 (EST)

Dallan, I will respond directly to Ruth Ellen on her user page. --Jennifer (JBS66) 12:13, 23 January 2010 (EST)
Thanks!--Dallan 13:11, 23 January 2010 (EST)

User: Alexandrina Murray - Welcome ? [25 January 2010]

Hello Dallan,

Is this a new extra User name, or has this User decided to start completely over? Could you advise? Thank You Debbie Freeman --DFree 00:39, 24 January 2010 (EST)

Please ignore it. I'll tell the user to use her existing Alexandrina account.--Dallan 09:27, 25 January 2010 (EST)

Trees [30 January 2010]

Dallan, I am curious. Why is it when I delete a tree that I no longer want, I am still watching all of the pages that it contained? Months ago, there was talk about deleting inactive users' trees, so I "adopted" one. I no longer want to watch her pages, but in a test, when I delete a tree, the pages are not removed from my watchlist.

The pages should be removed from your watchlist, though it's done in the background so it may take 5-10 minutes before they're removed. And you may have to force a refresh of the page in your browser to make sure you're seeing the latest page. Finally, if you happened to have the page in more than one of your trees and you just deleted one of the trees it was in, the page will still be in your watchlist. Do you have an example of a page that's in a tree you removed but is still in your watchlist?
That is how I thought it should work :-) I don't recall the specifics on my previous test. This morning, however, I deleted (~10:20 am EST) the Coret tree that I had also adopted. An hour later, the tree is not in my list of trees, but I am still watching the pages in the tree. Always a possibility I haven't waited long enough... --Jennifer (JBS66) 11:39, 25 January 2010 (EST)
You're right. :-( It looks like pages that did not get deleted because someone else is watching them do not get removed from your watchlist when you delete your tree. I have fixed this going forward, but in the meantime, it looks like you are watching 3703 Person pages and 1653 Family pages that are not in any of your trees. I can remove these from your watchlist pretty easily, but I don't want to do this if you have Person/Family pages that you're interested in watching but that you haven't assigned to one of your trees.--Dallan 18:35, 25 January 2010 (EST)
These have got to be all the Coret pages, hmmm.... Would this work... what if I re-adopt the same tree, so the pages are officially in a tree, and then re-delete that tree? --Jennifer (JBS66) 18:45, 25 January 2010 (EST)
Good idea. That ought to work.--Dallan 00:21, 26 January 2010 (EST)
I re-adopted the tree and deleted it again. After about 15 minutes or so, the pages themselves reflect that I am no longer watching them. However, in searches, it still shows that I am a watcher. I did wait about 24 hours in case things are refreshed on a daily basis. --Jennifer (JBS66) 07:24, 27 January 2010 (EST)
Thank-you for letting me know. I need to force those pages to get re-indexed. Normally this should happen in about an hour, but there's a bug where it's not happening for pages that didn't get removed because others were watching them. I forced the pages to be re-indexed, so they should disappear from searches on your watchlist about an hour from now, and I'll fix the bug.--Dallan 12:35, 30 January 2010 (EST)

Another tree related question: I sent a tree to a user who is working on a project with me. When he adds pages that are related to that project, they are not added to any sort of common tree. I need to watch his additions carefully, and manually add them myself. Also, I wanted to send this same user a revised version of the tree, as it contained many new people. It will not allow him to overwrite his current tree's contents, and says that he already has a tree by that name. Seems like an inefficiency, am I missing a procedure? Thank you for your time, --Jennifer (JBS66) 09:47, 25 January 2010 (EST) --Jennifer (JBS66) 09:47, 25 January 2010 (EST)

Yes, having to watch his additions carefully and manually add his additions to your tree is a known problem. The system can't automatically add his pages to your tree because it doesn't know that you're interested. We need to have a way for you to specify that you want to add every page that gets added to a specified tree to your tree.
Regarding not being able to overwrite a current tree's contents, did you send him a new gedcom and he's trying to upload it, and the system is telling him that the new gedcom overlaps a previous gedcom? If so, this is just a warning to keep people from doing this accidentally, since it will require him to do a lot of matching in the gedcom review process. If you or he sends me an email with the name of the gedcom I will release the "hold" on the gedcom and allow it to be uploaded.--Dallan 10:21, 25 January 2010 (EST)
No, I sent him a newer version of the tree we were working on, not a gedcom. I will get the specifics of that error message for you a little later. --Jennifer (JBS66) 11:39, 25 January 2010 (EST)
Ok, and please let me know what you mean by sending him "a newer version of the tree". Thanks.--Dallan 18:35, 25 January 2010 (EST)

Menus not pulling from message file [30 January 2010]

Hey Dallan,

When I clicked on the link for TiffanyDunn's user page, I noticed the menus aren't pulling the descriptions from the message file; they are instead showing the message key surrounded by html encoding for the < and > symbols. I copied and pasted the menu below; you can see the selections that pulled the actual messages vs. those that did not.

Menu

    * <home>
    * Search
          o <all>
          o <articles>
          o <people>
          o <images>
          o <sources>
          o <places>
    * <add>
          o Content page
          o <person>
          o <family>
          o <image>
          o <mysource>
          o <source>
          o <repository>
          o <place>
          o View user page
          o <otherpage>
          o Import GEDCOM
    * <myrelate>
          o Dashboard
          o Network
          o My watchlist
          o User contributions
          o <userprofile>
          o Discuss this page
          o Manage Trees
          o Show duplicates
          o <launchfte>
          o Preferences
    * <admin>
          o Recent changes
          o <nominate>
          o <logs>
          o Gallery of new files
          o <imagereview>
          o <gedcomreview>
          o <speedydelete>
          o <browseall>
          o Compare pages
          o Special pages
          o <adminlog>
    * Help

I was accessing her page from a Person page where she showed up as watching the page in the sidebar.

--Lhridley 15:31, 26 January 2010 (EST)


I've noticed this happens from time to time. Sometimes with all menu items, sometimes with only one. If I reload or go back another time, it's normal-- as is the above user's page now. Jillaine 16:19, 26 January 2010 (EST)
I've noticed it too. Not sure why. Hopefully upgrading to the latest mediawiki version (which is planned for later this year) will fix it.--Dallan 12:35, 30 January 2010 (EST)

my page seems to be locked by you ! [27 February 2010]

Is this true ? if so how come, ?--Mikekib 08:19, 30 January 2010 (EST)

I previously left notes here and at User talk:Mikekib asking for a description of this problem. --Jennifer (JBS66) 08:24, 30 January 2010 (EST)

RE: Your e-mail about B.Holmes and B.holmes. We are the same. I switched over to a Win7 machine and cannot force it to differentiate between the two. I did register again to sign on and edite one of my pages.

I would very much like you to recombine my split personality! :>)

Thanks, Buddy--B.Holmes 21:42, 21 February 2010 (EST)

Done--Dallan 19:51, 27 February 2010 (EST)

Person page info not appearing on family pages [27 February 2010]

Hello Dallan,

I noticed a few instances where parents appear on a person's page but do not show up on their family page. Example: Family:Jan Van Sloten and Uilkje Smidtje (1) . Jan's parents, Pieter Van Slooten and Lijde Jans appear on his Person page, but not his Family page. Uilkje has parents as well that are not appearing. I have tried opening and closing the respective pages in the hopes it would refresh, but it didn't.--Jennifer (JBS66) 07:28, 26 February 2010 (EST)


As I read the history of your page (always iffy), it looks like he was attached to his parents by a second GEDCOM upload, when his pages and those of his parents already existed. This bears some similarities to the situation described at Watercooler topic GEDCOM upload problem, and may be the same problem. --Jrich 09:28, 26 February 2010 (EST)

It does look like the same problem. In the future I'll be getting the spouses' parents' information by reading it off the pages instead of copying it to to the family page, so it won't be a problem long-term.--Dallan 19:51, 27 February 2010 (EST)

submission not a GEDCOM [27 February 2010]

Dallan, Re Alexander Family.FTW. It should have ended in ".GEDCOM" I guess. My first attempt to upload a GEDCOM didn't work--don't try to do it after a late dinner with wine--so I will read directions and try again. dtpadg--Dtpadg 12:23, 27 February 2010 (EST)

Check out Help:GEDCOM/Family Tree Maker.--Dallan 19:51, 27 February 2010 (EST)

Can you weigh in on current status... [28 February 2010]

I'm not sure you're watching this, but I think you can answer Aabh's question more specifically -- What I did, by the way, was upload a gedcom of 4 people that I'd uploaded previously, but changed about six dates in the file. It kicked it out as duplicative. That seems like a problem, but, as I said on the page, I don't remember the status of the update function.--Amelia 23:06, 27 February 2010 (EST)

I'll check it out. Thank-you for pointing it out. As for GEDCOM upload, the re-upload function isn't working yet; until it does, gedcom's that overlap previous gedcom's get kicked out as duplicative. But if you're willing to do the merging that will be required, you just have to ask me to override and push it through. (Delijim does this periodically.)--Dallan 00:04, 28 February 2010 (EST)

Request Import of Overlapping GEDCOMs [12 March 2010]

Dallan, please allow me to import 3 recent GEDCOMs identified below and at User talk:BobC that were rejected because of overlapping data. While there may be some overlap connecting to existing families, much of it is new to my data and would save me time I would otherwise have to add name by name. They are small files for only a couple families each, and I will ensure overlapping names and data fields are identified and merged appropriately and carefully.

  • Schannauer2.ged
  • Schonouer1.ged
  • Schonour2.ged

Thanks.--BobC 17:20, 12 March 2010 (EST)

They're importing right now.--Dallan 17:26, 12 March 2010 (EST)

Overlap [16 March 2010]

Re overlap John Truax Ring.ged. This was done on purpose. I will take care of matches. Howard--HLJ411 16:44, 15 March 2010 (EDT)

It's importing right now.--Dallan 18:30, 16 March 2010 (EDT)

Redirected pages [17 March 2010]

Hello Dallan, I was wondering... I noticed that pages that are simply redirects remain on our watchlist and in our trees. Does it need to be this way? --Jennifer (JBS66) 13:37, 17 March 2010 (EDT)

Not really. If someone were to unmerge the pages we'd want to put the original page back on your watchlist, but I think it could be taken off your watchlist after a merge. There's a bit of a difficulty figuring out which of the merged pages you were originally watching, so in case the page gets unmerged I might need to add both of the original pages to your watchlist. I'll add this to my todo list.--Dallan 00:21, 18 March 2010 (EDT)

Place pages being deleted of content [31 March 2010]

Hello Dallan, I noticed a few cases today where content on place pages was deleted. I'm not sure if this was user error, but I believe it happened during gedcom upload place matching (the user was Tr smith). Examples are: Albany, NY and Minneapolis, MN. I reverted them, but thought I would let you know in case this is a bug. Thanks, --Jennifer (JBS66) 13:48, 29 March 2010 (EDT)

I've never seen that before. THANK YOU for catching and fixing them! It looks like there were at least half a dozen of them. I'm going out of town tomorrow morning but I'll fix this as soon as I return this weekend.--Dallan 21:50, 31 March 2010 (EDT)

3 new users, likely the same [6 April 2010]

Dallan, I wanted to bring these 3 new users to your attention: 1, 2, and 3 (likely all the same person).--Jennifer (JBS66) 06:25, 3 April 2010 (EDT)

Hello Jennifer, Adding my two cents. Probably I would not be surprised, It could be. Though two of the three have different numbers when I welcomed them after they signed on as new WeRelate Users. Thank you for noticing. Debbie Freeman --DFree 10:05, 3 April 2010 (EDT)
Believe it or not, they have (fairly different) email addresses. But it's good to check since multiple accounts often results in confusion. (I do need to write something to warn people when they create multiple users for the same email account.)--Dallan 10:14, 6 April 2010 (EDT)

Error Signing In Message [6 April 2010]

Hi Dallan,

I am new user (just registered today). When I try to sign in to the Sandbox it tells me my user name does not exist, however I received and clicked on the confirmation I email I received from you. Please advise, thanks Aandreje2 (Jean Andrews)--Aandreje 15:55, 4 April 2010 (EDT)

Hello Aandreje2, Welcome to WeRelate I am User DFree. I will try to help. Was there some problem with your original WeRelate User name? Were you not able to use your original WeRelate User Name Aandreje to sign in? WeRelate is a wiki so you do not need two User names. We have found that having more than one WeRelate User name creates confusion and some frustration for some User's. Could you try to see if the original WeRelate User name works and get back to me or Dallan?

Thank You, Debbie Freeman --DFree 16:27, 4 April 2010 (EDT)

Hi Debbie - I thought after reading the Sandbox page that I needed a second ID to use the Sandbox. I have tried both ID's and neither one works in Sandbox. My original ID aandreje works fine logging into the WeRelate main page, but not Sandbox. Same error message "There is no user by the name Aandreje". You can delete my duplicate ID Aandreje2...and then help me with logging into Sandbox? Thanks so much, Jean

Hi, I'll delete your Aandreje2 account. As for the sandbox, you need to create a separate account on the sandbox -- the accounts aren't shared. Sorry about that.--Dallan 10:14, 6 April 2010 (EDT)

getting emails [6 April 2010]

Why am I suddenly getting emails that I never got before every time something is put on this page. How can I get rid of the emails being sent.--Melbostad 09:47, 6 April 2010 (EDT)

Click on the "Unwatch" link in the upper-right corner of this page. That will stop the change notifications for this page.--Dallan 10:14, 6 April 2010 (EDT)

Gedcom upload (trouble with accent marks) [6 April 2010]

Dallan, FYI: I've reviewed a couple of Bergsmit's gedcoms today. They have been coming through with odd characters instead of accented ones (ie, Löhndorf instead of Löhndorf). The latest gedcom was BernhardLippe 10 gen 100406.ged. --Jennifer (JBS66) 15:12, 6 April 2010 (EDT)

It looks like whatever program he is using to generate the gedcom is generating it incorrectly. The program claims that the characters are written using ANSI character encoding, but it's really writing the characters using UTF-8 character encoding. Most gedcom files say which program generated it, but this one doesn't so I don't know which one it is. At this point:
1. He can review the gedcom and manually correct instances where this problem appears.
2. I could manually fix the character encoding in this gedcom and re-process it. I'm a bit concerned that if I do this, the family matching will need to be re-done, so option 1 may be better.
3. Going forward he needs to use a different program to generate the gedcom. All of the commercial desktop genealogy programs that I know of specify the character encoding correctly. I'll tell him about the problem and ask him to switch genealogy programs.
--Dallan 16:15, 6 April 2010 (EDT)
He uses a website called Geneanet. They allow downloads in ASCII and UTF8. He can really just edit 1 CHAR ANSI to read 1 CHAR UTF-8 and that will solve the problem? That's pretty easy, then he can keep downloading from his work on Geneanet. Also, I fixed the places for him, there weren't too many, and uploaded the gedcom. --Jennifer (JBS66) 16:49, 6 April 2010 (EDT)
Yes, that will do it. That tells our importer to expect non-roman characters to be encoded using UTF-8, which is how Geneanet is encoding them. (He might also want to tell Geneanet to fix their export.)--Dallan 16:52, 6 April 2010 (EDT)

Andrew McCLURE of 1700s Augusta Co, VA [16 May 2010]

As you may remember, I am new to werelate and not sure how to find this family. I would like to ID all the parties in: 15 Feb 1786- Andrew WILSON only wit to Augusta Co, VA m of David WILSON s/o John, and Ellen McCLURE d/o Andrew McCLURE. --Halmccawley 20:45, 14 April 2010 (EDT)

I did a quick search for Andrew Wilson born 1786 +/- 5 years by clicking on Search then on People in the blue menu bar above. The only result returned was Person:Andrew Wilson (28)
A search for David Wilson son of John yielded Person:David Wilson (4)
A search for Ellen McClure daughter of Andrew McClure yielded Person:Eleanor McClure (6)
--Dallan 23:09, 18 April 2010 (EDT)

--Halmccawley 13:03, 16 May 2010 (EDT)The Andrew WILSON in the above WILSON/MCCLURE 15 Feb 1786 Augusta Co, VA marrage was an adult witness which makes his probable birth date bef 1765. [Hal McCawley]


Gedcom tags [20 April 2010]

Hello Dallan - just an FYI

This user's gedcom came through with what might be gedcom tags that WR didn't support, like: (PEDI, PLC, CREA, AGNC). Examples: Family:Augustus Chamberlin and Elizabeth Cotter (1) and Person:Ethel Chamberlin (1).--Jennifer (JBS66) 09:41, 20 April 2010 (EDT)

I see tags like this every once in awhile. They're custom/non-standard tags. The gedcom importer doesn't know how to interpret them, so attaching them to the related event/note is the best it can do.--Dallan 18:03, 20 April 2010 (EDT)

Image references removed during merge [20 May 2010]

Hello Dallan, I noticed that when I performed this merge that image references for Wijtske Talma/Wytske Talma (Child 3) were removed. Here is the side-by-side comparison for these two versions. I can easily go and fix these, but I wanted to alert you in case this was a bug. Can you also let me know when you're done looking at these pages? I'm going to rename and delete redirects - but not until after. Thanks, --Jennifer (JBS66) 06:22, 16 May 2010 (EDT)

That sure looks like a bug. THANK YOU for letting me know. I'll fix it right away.--Dallan 10:48, 20 May 2010 (EDT)
I've fixed the problem for future merges. The problem didn't normally occur, so most merges shouldn't have been affected. It only occurred when a reference to a source, image, or note was listed in the wrong field. That is, when a reference to an image was listed in the sources field of the event, which is what happened here - the I1 was listed as a source reference. From now on it won't matter which field a reference appears in - it should be retained. Looking back on this, it seems like at some point in the future we ought to put all references (sources, images, and notes) into a single "references" or "citations" field on the event. That would simplify things.--Dallan 12:35, 20 May 2010 (EDT)
Thanks Dallan! Goodness, it's not like me to put the Image ref in the Source field - glad that didn't happen too often. I'll go ahead and fix the page and rename now that you're finished with the merge example up above. --Jennifer (JBS66) 12:48, 20 May 2010 (EDT)

User trying to rename their userpage? [17 May 2010]

Dallan, it looks like this user was trying to rename their userpage, but only the talk page was renamed. --Jennifer (JBS66) 06:21, 17 May 2010 (EDT)

I'll ask if they want to rename their account.--Dallan 10:48, 20 May 2010 (EDT)

Prefix field, person page [21 May 2010]

Dallan, while you're reworking the input fields on the Person page, would you please consider physically moving the "Title Prefix" field to a position just before the "Given name" field? It logically belongs there, with the "Title Suffix" field after the name. Having the prefix field in front might encourage people to actually use it, instead of just sticking a prefix in the "Given name" field (e.g. "Capt John" -- which, if it's imported that way, ends up with a page title like "Person:Capt Smith"). I find myself frequently correcting this on pages I edit. --Mike 10:00, 21 May 2010 (EDT)

Good point. I'll do that.--Dallan 10:43, 21 May 2010 (EDT)

Can you delete this? [3 June 2010]

Dallan, this source is showing up in searches, but has been deleted. Can you remove it from being displayed in search results? Thanks, --Jennifer (JBS66) 07:24, 31 May 2010 (EDT)

Thanks for letting me know. I've removed it.--Dallan 11:55, 1 June 2010 (EDT)

On the subject of moving fields, wouldn't it be wise to place the "Baptism" field next to the "Christening" ? Maybe I should have put this in the "Wish List" enquiry, but I just began finding its placement a little inconvenient. --Neal Gardner 18:00, 1 June 2010 (EDT)

In the upcoming version of WeRelate that is currently being tested on the sandbox, events appear in chronological order when the page is displayed. Eventually you'll be able to move events around on the edit screen, but that won't happen for awhile yet.--Dallan 22:47, 1 June 2010 (EDT)
According to GEDCOM standard:
  • BAPM tag = "The event of baptism (not LDS) performed in infancy or later."
  • CHR tag = "The religious event (not LDS) of baptizing and/or naming a child."
I assume these are the tags that WeRelate translates the Baptism and Christening facts into. resectively. (There is also a CHRA tag for an adult christening, and a BAPL tag for the LDS baptism. I'm guessing WeRelate doesn't use these, since I see no event type that would appear to match.) Some people may have an attachment to one or the other of these terms in some external context, but it does not appear to me that there is any difference from a GEDCOM perspective. I can't see how any baptism wouldn't qualify equally well as a christening. Genealogically speaking, they are of interest for the same reason, because they serve as proxies, or confirmations, of the birth date.
There is, however, a difference in the way that WeRelate handles these two event types. WeRelate will display the CHR date in lieu of a missing birth date on the Family page, but it will not do the same for a BAPM. Because of this additional benefit for CHR, it seems to me that Christening should be used in preference over Baptism. --Jrich 00:31, 2 June 2010 (EDT)

Using a baptism for an approximate birth date can be a bad idea. Christening is always for an infant or a young child, but a baptism can be for an infant or an adult.--Lauren 12:38, 2 June 2010 (EDT)

I don't mean to expand this subject into a debate about the meaning and usage of the two terms, but it's not as simple as noted above, and people working on their family histories should be aware of the terms when recording these events. In the early Christian church, when christening first began, it was a ceremony in which a child was given a Christian name and then baptized. The christening referred to the naming ceremony. However, because of the baptism, many people thought the child was being christened when he was baptized. Therefore, baptism was rarely a word associated with infants. Now, children are named prior to the baptism. Since they are no longer given Christian names while being baptized, there is no need for a traditional christening. Therefore, children and adults now just get baptized, even though it is still often referred to as a christening. It is important to realize, in modern times christening and baptism are basically the same thing and can be used interchangeably. --BobC 14:50, 2 June 2010 (EDT)
As mentioned I wasn't discussing the meaning of the terms in an external context (i.e., religious), only in terms of GEDCOM, and specifically WeRelate. I wasn't suggesting to look for Christening versus Baptisms in records, though I'll note that I've never seen a record of a Christening, only baptisms (my research is pretty limited, being 90% 1600-1800 United States, therefore mostly Protestant denominations, and often using secular non-religious vital records after about 1650). Perhaps my comment is aimed more at Dallan as a suggested change, but as long as the processing of the two event types is different, I prefer to see the event labelled Christening on the WeRelate screen used in preference to the optional event labelled Baptism. Perhaps there is no need for two event types? Perhaps, if we begin to sort events by dates, and there is no birth date, then the first event in a person's life, whatever type it is, gets promoted to the Family infobox in place of the birth date? It would be nice if the same promotion in lieu of birthdate happened on search results, by the way, and not to be a broken record, but of marriage banns when the marriage date is unknown, instead of having to used a marriage date of "Aft. intention-date". --Jrich 21:12, 2 June 2010 (EDT)
Well I learned something new today, and that's a good thing - thanks! I've added promoting the Baptism in cases where Birth and Christening are not found to the todo list. I put it right next to promoting Marriage banns :-). Progress is being made on the website - take a look at the sandbox for the new look that will hopefully be approved for the main site in the next few days. Hopefully it won't be too long before I get to these other things.--Dallan 15:42, 3 June 2010 (EDT)

References from Wikipedia [4 June 2010]

While reviewing the changes to the page Person:William I of England (1) I noticed that there is a superscript reference [1] on his birth date in the WP text, but it doesn't go anywhere. It appears that when we suck in the Wikipedia material, we leave the reference targets behind - not good. Is there a feasible way to fix this?

I hadn't realized that. Yuck. Removing the references would be the fastest way to solve the problem, though it's not ideal. Determining which references had been referenced and automatically-generating our own references section would be ideal, though that would require a fair amount of effort. It doesn't seem worth the effort to do the latter, so I'm leaning toward the former. What do you think?--Dallan 15:48, 3 June 2010 (EDT)
I doubt that it's a huge problem if noone has noticed till now. When I hover over the superscript, a link shows but nothing happens when I click. The curious could go back to wikipedia to see it. It would be nice if clicking on the ref would take you there, but not worth diverting development time from the redesign. Do whatever is easiest or even nothing. Maybe just change the boilerplate to say see WP for references? you already have a link to their page. --Judy (jlanoux) 18:07, 3 June 2010 (EDT)

Another question: has anything been decided on handling birth/death dates to get us away from having alt dates widely separated on the page and out of chrono order? These drive me crazy as they represent problems which should be compared and perhaps resolved or at least discussed. But when they aren't together, they are often overlooked. --Judy (jlanoux) 15:01, 2 June 2010 (EDT)

The new facts and events list on the sandbox lists the events in chronological order. It even has a little timeline "eye candy" so you can see relatively when events occurred. I'm hoping this will help.--Dallan 15:48, 3 June 2010 (EDT)
Wow! I just went to take a look. Very nice. I especially like the changes to the family page. I can now see all the children together. The timeline thingy didn't do much for me. Took a while to figure out what I was looking at. But nice try. --Judy (jlanoux) 18:14, 3 June 2010 (EDT)
Thanks! I put the timeline in on a whim because I thought the pages looked a little plain. I'm not sure I like it either. Let's see what others think.--Dallan 18:33, 3 June 2010 (EDT)
It looks pretty nice to me. I think the timeline would be clearer if a line was drawn from the text date to the mark on the timeline that represents it, or something like that.
Still doesn't deal well with Family page that has missing Person pages for one of the spouses. [2] has two marriages like that, and her Person page doesn't even have a clickable link to get to the corresponding Family page. --Jrich 18:55, 3 June 2010 (EDT)
I see what you mean. Eventually I'll display the name from the Family page title and add a link to the "Add Page" screen that will let you create a new Person page that will be linked automatically to the family. (I also plan to add links for "Add Child", "Add Spouse", etc. to the family infoboxes section -- I expect this will become the typical way to add relatives' pages.)
In the meantime, you can click on the "Spouse and Children" and "Parents and Siblings" headings to go to the family pages.--Dallan 10:16, 4 June 2010 (EDT)

Facebook page instead of group? [7 June 2010]

Have you given any thought to having a WeRelate Facebook page instead of a group? The great thing about pages is that when the page creator posts something to the wall, it goes to everyone who "likes" the page (used to be "fan of" the page). For example, you could post something like a link to a new Featured Page and everyone who likes the WeRelate page would see it on their news feed. With a group, it is much more dependent upon the group members going to the group page. I think you'd get a lot more interaction and a lot more attention with a FB page. Just a thought :-) -- Amy 12:53, 7 June 2010 (EDT)

I'd never thought about that. (I just found out about the group a couple of weeks ago :-). Once I get the new look and feel in place I'll create a facebook page.--Dallan 13:09, 7 June 2010 (EDT)
No rush, certainly! I just thought I'd throw that out there. :-) How are things coming with the new look? -- Amy 13:35, 7 June 2010 (EDT)
I just reviewed a bunch of additional comments on the Watercooler. I hope that's it. I hope to have these latest changes made by Wednesday, so I can post it by the end of the day Wednesday.--Dallan 16:04, 7 June 2010 (EDT)

New look? [10 June 2010]

Hi Dallan -- Is the look that's in the Sandbox pretty much what the new look is going to be? I'm giving a presentation at my local genealogy society meeting this evening and I thought I'd go ahead and grab the screenshots from the Sandbox if that's pretty much the way it will be. Also, is it still looking like a day or two before the new look rolls out? I'd like to tell them what to expect. Thanks! -- Amy 10:35, 10 June 2010 (EDT)

Yes, the sandbox has exactly what the new look will look like. Solveig is doing the final tests right now. I'm hoping to roll it out in the next couple of hours.--Dallan 16:23, 10 June 2010 (EDT)

Awesome! -- Amy 16:42, 10 June 2010 (EDT)


Update and question [11 June 2010]

Hi Dallan -- First, I want to tell you that the folks at my local society meeting *loved* WeRelate! They were very excited about the possibilities that it presents! (I have to admit that you changing the site today made it a bit crazy for getting screenshots <g>).

I have a question -- have burials always sorted at the top of the event list when there isn't a date of burial but there is a date of death? I thought they were sorting after the death when there was a date, but a couple pages I've looked at this evening (for example, James Ray), the burial is sorting at the top of the Facts and Events list, between gender and birth.

Also, I just noticed a little quirk. On some pages, the menu across the top has code showing up. The link to "Home," for example reads "& lt;home& gt;" (but without the space after the ampersands -- I couldn't find another way to express it without it being rendered as less than and greater than symbols <g>).

Thank you for all the hard work you've put into the new look for WeRelate. It looks terrific! -- Amy 22:30, 10 June 2010 (EDT)

I'm sure this is because there is no date, which probably sorts first datewise. I would suggest moving the name of the cemetery into a note, or source text, but this will probably be a common problem for various events having no dates (AFN events for example?) --Jrich 14:21, 11 June 2010 (EDT)
I just found a screenshot I had done before the new look went live. The burial event (even if there wasn't an exact date for it) did sort after the death event which had a date. I hesitate to add the cemetery to the note field, as we've been working very hard on creating place pages for cemeteries. Seems to defeat the purpose to put it in a note when so many GEDCOMs already have it in the burial event. -- Amy 14:28, 11 June 2010 (EDT)
This was a bug - thanks for pointing it out. I've fixed it, so death and burial events without dates sort after everything else. The server caches old copies of the pages, so if you're still seeing it add "?action=purge" to the end of the URL (without the quotes) to clear the server's page cache. I'll clear all pages from the cache tonight after I've fixed a few more bugs :-).--Dallan 15:09, 11 June 2010 (EDT)
Oh, and the problem with the "& gt" signs got fixed as well :-).--Dallan 15:10, 11 June 2010 (EDT)
It works great! Thanks! -- Amy 15:32, 11 June 2010 (EDT)
I forgot to mention that facts and events without dates sort just after the previous dated fact/event on the edit screen. So if your AFN fact comes after a Census event with a date, then your AFN fact will be displayed after that Census event. This will in preparation for the future when you can move events up and down in the edit screen.--Dallan 16:06, 11 June 2010 (EDT)

Henry Kingman (6) [11 June 2010]

What's up with Henry Kingman? segross uploaded a GEDCOM that wiped out data and sources that had been there previously (one of three cases I am aware of his upload doing this), added no sources and had an abt. date instead of the exact date that was there before. I reverted to the version before his gedcom upload wiped out data and added additional sources, and you restored Henry to the gedcom version? Curious why?

--Jrich 12:40, 11 June 2010 (EDT)

It looks like Segross removed a lot of sources when he merged his gedcom data into existing families. I'm going through all of the pages he modified right now and re-adding the sources that you and others haven't already re-added.--Dallan 12:48, 11 June 2010 (EDT)

Edit warning [12 June 2010]

The new look doesn't seem to have the "you will lose edit" warning if the back button is hit rather than "save page".--HLJ411 16:54, 11 June 2010 (EDT)

Thanks for letting me know. It's fixed now.--Dallan 00:03, 13 June 2010 (EDT)

Place name in source citations [14 June 2010]

Dallan, a user brought the following (possible bug) to my attention: Source:Itawamba, Mississippi, United States. 1850 U.S. Census Population Schedule.

Since the page uses a pipe to redefine the place name, the citation is showing up as Itawamba, Mississippi, United States|Itawamba County, Mississippi. 1850 U.S. Census Population Schedule. Is it possible to display the citation with the redirected to final name for the place instead? Thank you, --Jennifer (JBS66) 11:53, 14 June 2010 (EDT)

This should be working now.--19:09, 14 June 2010 (EDT)
Thank you! Would we want citations such as this displaying the WR place page name instead, regardless of what a user inputs after the pipe? So rather than Itawamba County, Mississippi. 1850 U.S. Census Population Schedule, this should really be Itawamba, Mississippi, United States. 1850 U.S. Census Population Schedule to minimize confusion. Is this possible? I suppose that not encouraging using pipes in source page fields would help too! --Jennifer (JBS66) 20:33, 14 June 2010 (EDT)
For the record, I probably did this because either 1) I like the look better for displaying a county back when it didn't matter; or 2) it happens automatically when you save a page that says X County, State in the place field (and I would often copy that format of place from some other field into the place). In this type of instance, the system can pull the WR place, but I don't know what that does for records from places that no longer exist, but are linked to the currently existing place. It's not correct to label those as records of the "new" place.--Amelia 21:19, 14 June 2010 (EDT)
I think it's fine (to use pipes in source page fields).--Dallan 22:54, 14 June 2010 (EDT)

Edit message [19 June 2010]

When creating a new page by clicking on a red link, the message says that to create the page, click on the Edit link above. The message needs to be changed to click the Edit link to the left. Thanks! -- Amy 17:59, 19 June 2010 (EDT)

Thanks for letting me know. :-) Dallan 22:35, 19 June 2010 (EDT)

Order of tabs on Add a Person page [26 June 2010]

On the Add a Person page, is there a way that the order of the tabs could be changed? Right now it goes from given name to surname to "Add Page." Could it go from given name to surname to gender instead (especially since gender is a required field)? -- Amy 15:48, 23 June 2010 (EDT)

Can you tell me which browser you're using? When I bring up an "Add page" window for a person the tabs go from given to surname to gender. I've tried it in Firefox 3.6 and IE7. Thanks.--Dallan 18:23, 24 June 2010 (EDT)
Chrome for Mac. The tab order was fine until the new look. -- Amy 19:18, 24 June 2010 (EDT)
That's odd. Well, it doesn't work on Chrome for Windows either. I'll try to fix it tomorrow.--Dallan 23:08, 24 June 2010 (EDT)
This is working now.--Dallan 23:20, 25 June 2010 (EDT)

Thank you! That makes things a lot easier when adding people manually! -- Amy 06:09, 26 June 2010 (EDT)


Gedcom file [25 June 2010]

They tell me that I need to talk to you. My Gedcom file has about 14000 names, and is too big. Can you help? best wishes Ken--KenPhillips 07:13, 25 June 2010 (EDT)

I'd suggest that you load a smaller gedcom - which is looks like you have - and see if you like doing genealogy "the wiki way". Occasionally we approve larger gedcom's, but only for people who are long-time contributors.--Dallan 12:25, 25 June 2010 (EDT)

Also, it is better to load specific familiies (one at a time) that are well documented and researched. It is much easier to review gedcoms that way. We'd also ask that if your gedcoms have multiple error messages and/or major differences with families already on WeRelate that you resolve those errors or differences, delete your original gedcom and re-load it with the corrections.

Thanks,

Jim Volunteer Admin. at WeRelate--Delijim 18:19, 25 June 2010 (EDT)


Merge and gedcom upload checkbox behavior [30 June 2010]

Dallan, this morning I noticed the checkboxes in the Family Matches tab in the Gedcom upload behave differently. Previously, I'd click the topmost Match box on the column, and the system would automatically check the boxes for the husband and wife. That no longer happens - just the box I click shows a check mark (though the other boxes do change in color slightly).

I tried this outside of the gedcom upload - as a regular merge - and the same thing happens. I used Chrome, Firefox 3.6.4, and IE 8. --Jennifer (JBS66) 07:09, 26 June 2010 (EDT)

Dallan, I've also noticed this in the last 2-3 gedcoms that I've loaded within the past week or so. Can you program it back to how it was? Delijim

I'm sorry about that -- it should be fixed now.--Dallan 01:31, 30 June 2010 (EDT)

Why do I keep getting messages? [28 June 2010]

I am in the process of importing my gedcom file to We Relate and succeeded in doing that this afternoon. I received a message that it would be reviewed and someone would get back to me when the review was done.

Meanwhile, I have half a dozen messages in my email box that are totallly confusing and I have NO IDEA HOW TO RESPOND TO THEM. They all say I have such and such a problem.

There is a link in each message which says to click on the link so I can respond, but all I get is a HUGE list of topics....I have no idea what to do with it.

If I try to reply to the message, that doesn't happen either.

I think this particular feature could be simplified.

Thank you,

Virgina Mann vxmann@comcast.net--Vxmann 21:27, 28 June 2010 (EDT)

I'm working with Virginia via email. Her file has been imported. --Judy (jlanoux) 21:41, 28 June 2010 (EDT)

Search messed up [30 June 2010]

Hi Dallan, When I selected one of my trees to view and search; the search results were not for people in my selected tree. The search results were from pages that I am watching. What's up with this? I selected my Robert and Elizabeth Coker Family of Murray County, Georgia tree and searched for watched pages, person Leonard and the results on the first page are not even in that tree. Here is the link to his page and he is clearly in the tree that I was searching: [3] Thanks. --Beth 23:01, 28 June 2010 (EDT)

Hi Beth, I went to your user page, clicked on the view link next to "Robert and Elizabeth Coker Family of Murry County, Georgia", and was presented with a list of 671 people: http://www.werelate.org/wiki/Special:Search?k=%2BTree%3A%22Beth%2FRobert+and+Elizabeth+Coker+Family+of+Murray+County%2C+Georgia%22 Leonard is one of the people in that list. (If you want to restrict your search to a particular tree, you need to make sure that the +tree:"tree name" appears in the keywords field.)--Dallan 01:41, 30 June 2010 (EDT)

Gedcom upload has few duplicates, many additions, and makor updates and corrections [11 July 2010]

Dallan,

Today I have uploaded a GEDCOM with (thanks to yDNA and the FTDNA Bailey Project) the major new addition of the Baileytown, Adroscoggin, Maine Bailey genealogy plus important updates to a section of my family's tree.

However, there is some small amount of overlap which could not be avoided Sorry about that.

BTW, will yDNA (Paternal links) and mtDNA(Maternal Links) fields be added to this database someday???

Regards, Joseph jfbaileyatcomcast.net--JFBailey 16:56, 8 July 2010 (EDT)

Hi, I cleared your GEDCOM for upload. You should receive a message shortly that it's ready for you to review. You'll want to match the overlapping pages with the existing pages so that new (duplicate) pages aren't created for them.
Regarding DNA fields, I'd like people to help me understand more about what is needed here. I've created a couple of DNA templates, which you can see here, but I'm not sure that's the best solution. I'm open to people's suggestions.--Dallan 18:34, 11 July 2010 (EDT)

Links to places [25 July 2010]

I know this is a stupid question, but the heat is affecting my brain. (That's my story and I'm stickin' to it! <g>) When a new Place page is added, links that reference that place will eventually show up as blue instead of red, correct? If so, (1) how long does it take for that process to occur and (2) how "far off" can the name of the link be and have it still match? For example, I just created Place:Marcus-Amherst Cemetery, Marcus, Cherokee, Iowa, United States. I've seen red links to "Marcus-Amherst Cemetery, Marcus, Cherokee, Iowa, USA" on some Person pages, including this one. Will those links eventually be blue? (Does that question make any sense at all? <g>) Thanks -- Amy 17:38, 23 July 2010 (EDT)

Hi Amy, if the link matches the title exactly, then the links should turn blue right away. If the links contain missing levels and/or alternate names or capitalization/dashes (e.g., Marcus Amherst cemetery, Iowa, USA), then they'll turn blue the next time the page is edited. At some point in the future I plan to write a "bot" that will go through the pages periodically (a few times a year) and try to match red links, but it's not high up on the todo list.--Dallan 10:16, 24 July 2010 (EDT)
Thanks, Dallan. I appreciate the info. On a different topic: Are there any plans to have the search for sources not be case sensitive? (I'm referring to the dropdown when you're entering a source citation on a Person or Family page.) I was entering marriage info on a Family page and typed in the beginning of the title of the book as Jackson County, Ohio History and Family (capitalized). I got no results, so I started to enter a new source. When I did that, I discovered that this book does have a Source page, but the title is Jackson County, Ohio history and family book (lower case). -- Amy 09:56, 25 July 2010 (EDT)
I've added this to the WeRelate:ToDo List.--Dallan 18:46, 25 July 2010 (EDT)

Nice Job [29 September 2010]

Dallan, I know I've been MIA for quite some time-- other priorities pulling at me this last year-- but just wanted to say REALLY FINE work you've done on the new interface. FAR superior to before. Great work. Jillaine 13:50, 1 August 2010 (EDT)

Thanks :-)--Dallan 12:10, 4 August 2010 (EDT)


Genealogy of the Cushmans [5 October 2010]

  1. I have this book and I am scanning it into a pdf so I no longer have the weight of responsibility of passing its contents on to future ages. I was thinking of uploading it to Wikisource but they have funny formatting ideas. The pdf is an image of the book with most text OCR'd and embedded in optimized page images. The page images are fully human readable and there is enough embedded text for purposes of searching and cataloging. Generation One, a long discussion of Robert Cushman, the Puritan, is 83 pages long and sizes out to a little over 4MB. Not that big by current standards. I am willing to upload this entire book eventually to this site if it is welcome.
  2. I am not entirely happy with this site since your code is not open source and your code does not have a distributed linking architecture that would allow me to run my own subsidiary site with the genealogy information that should not yet be published to the world. I will probably be using phpgedview instead on my own site. Or I might just decide to not do anything at all since there is no appropriate software out there. Over time, that is a loss to the world. For now, I need a place to put this book. I can overlook your deficiencies for this purpose, if the book is welcome. Otherwise I will find some other repository. Perhaps I should turn it into a Kindle offering?--Dunning 18:00, 29 September 2010 (EDT)

If it is the same, this book about the Cushmans by Henry Wyles Cushman is already available on the internet in 8 different formats and is searchable and can be downloaded.--HLJ411 21:53, 29 September 2010 (EDT)


Thanks for the pointer. I will discontinue this effort.Dunning 05:16, 1 October 2010 (EDT)

Do you know of anyone who has developed or is working on a distributed linking architecture? I'd be interested in hearing about it. At one time I thought that Google Wave would be the answer, but that's been discontinued.--Dallan 23:51, 1 October 2010 (EDT)
Since your software is already a fork from Mediawiki it should have all the needed linking capability. I am currently running a Mediawiki and I am able to link back to Wikipedia using "[[wikipedia:topic|title]]", which is very convenient. You could use a "[[werelate:article|title]]" convention to do the same thing here. There could be a list of quicklink wikis that might be referenced this way, in addition to making "WeRelate:" available by default. The other needed piece would be to allow the publication/movement of articles from the local or family genealogy wiki to your wiki under a process with good safeguards to prevent accidental publication. It would have to handle the already established relationships from the local wiki article to WeRelate and make them two-way. It would involve setting up the WeRelate sign in credentials and having proper local privileges. Ideally, the publication process could work between any two "WeRelate" wikis. It actually doesn't sound that complicated, but perhaps you are aware of other important issues that I have not considered? It is true that there would need to be be some kind of security system to prevent public viewing of local nonpublic documents, based on the login id. There are extensions in Mediawiki for that kind of control so maybe you do not need to worry about that if those extensions would work for your fork of the software. It is a temptation to volunteer to help with the modifications and packaging of this approach. Sadly, I am busy and not yet retired. Dunning 02:57, 2 October 2010 (EDT)
Good ideas, lots of work. The MediaWiki developers do not recommend restricted-access extensions. The recommend creating separate wikis, ala wikia. You need to have a way to publish pages between wikis and subscribe to changes. It's just a small matter of programming, as one of my professors used to say, but it's at least several months' work.--Dallan 18:28, 2 October 2010 (EDT)
Yes. I understand. We both knew all of this all along. Then there is the fact that most genealogists do not have the expertise to install and manage a wiki. Maybe MoWes is the answer to that problem. Regardless, you would need help. I have not kept up with WeRelate, so I don't know if you have help yet. Until there is a WeRelate support community the whole project is at risk. Note that I am unwilling to commit private family data to a public repository, and certainly not to one that ends with ".COM", no matter what assurances or safeguards they provide. Dunning 04:15, 4 October 2010 (EDT)
I think the long-term solution is for the various family-tree websites to agree on a standard publish-subscribe protocol, but that's not likely to happen anytime soon. As a first-step, I like the idea of being able to selectively publish information from a personal genealogy wiki to a public wiki, subscribe to changes, and selectively copy those changes back into your personal wiki. I'd like to go there, but it means a lot of re-work. I've been thinking about re-working the codebase sometime next year anyway, so I plan to do it with this in mind.--Dallan 14:58, 5 October 2010 (EDT)

Text in source box overlapping infoboxes [8 August 2010]

Dallan, I added text inside code tags to this page. The text is now overlapping the Spouse and Children infoboxes on the right. Is there any way to avoid this? I first tried to put a wiki table inside the source text box (with class=wikitable), but that didn't work. Are there any other options for adding an aligned table to a source? Thank you! --Jennifer (JBS66) 17:42, 1 August 2010 (EDT)

You could fall back to using html <table>, <tr>, and <td> tags. I just tried this and it doesn't look too bad if you add some padding: <table cellpadding="5">. You might also want to add spaces in some of the column headers so they'll wrap onto two lines and occupy less space horizontally. For example (I think I broke the column headers incorrectly, but you get the idea):
PerceelNaamVoornaamBeroepWoon plaatsLeggerSoorteigendomInhouds- grootteKlass- eringMinuut- plan
Hym A177PoelstraNammen ArjensLandbouwerFinkumHijum 221Bouwland183202Hijum A1


--Dallan 12:10, 4 August 2010 (EDT)
Thanks Dallan, I'll give this a try. --Jennifer (JBS66) 11:03, 8 August 2010 (EDT)

Collaboration [4 August 2010]

Dallan, I would like to invite my cousin to join me in working on our family tree. Will you please point me to instructions for collaboration? Many thanks!

Ruth Ellen -- USER RELuehr--RELuehr 22:09, 2 August 2010 (EDT)

Sure - the easiest thing to do is to email your cousin a link to one of the pages you're working on. Your cousin can start editing that page as soon as they've registered.
If your cousin wants to be notified by email when the page is changed (when you edit the page for example), ask them to click on the "Watch" link on the left-hand side of the screen.
If your cousin wants to be notified when any of the pages in one of your trees are changed, ask them to go to your user profile page, click the "Launch FTE" link next to the tree they are interested in, then in the Family Tree Explorer's "File" menu (upper left corner of the screen), click "Copy tree". This will cause them to start watching all of the pages in that tree (there's a 10 minute delay while the pages get added to their watchlist).
--Dallan 12:10, 4 August 2010 (EDT)

Bug(s) in gedcom upload [19 August 2010]

Hi Dallan,

I uploaded a gedcom yesterday (Jbingham). In investigating this morning, I found that at least some of the source matching didn't take. For example, on this page, I remember matching both the 2nd and 3rd sources to books in the system (see the current version). And then because of something weird in the way I use fields, a lot of my sources come in with "source" as the title. I suppose I could change this during upload, but in fact what I thought I was doing was matching them all (the other reason I know I matched the records on the Elisha page is that I looked at the list of sources titled "source" and made sure all were matched or excluded). But now they are all linked to the very first "source" I uploaded, which has been renamed and redirected since then. At the very least, the system shouldn't assume that all six new sources are not the same as a previously uploaded one, particularly if the title is system-generated. --Amelia 11:52, 12 August 2010 (EDT)

P.S. There are at least two instances where place matching did not "take" either.--Amelia 13:47, 12 August 2010 (EDT)
It looks like your example is a case where a gedcom person matched an existing page. I just tried this in the sandbox and it worked, but I matched the source before matching (and updating) the existing family. Do you think you might have updated the family first, before matching the source? That definitely would have caused the behavior you're seeing, since the family edit would have happened before the source got matched.
Judy and I have been discussing a "fix" for this problem -- having people update matched pages after the gedcom import is complete. I'm going to announce it on the watercooler and ask for feedback.--Dallan 18:10, 19 August 2010 (EDT)
I just commented there, though this answers one of my questions - it is likely that I merged first, because I tend to do places and sources last. It's nice to know the problem is avoidable.--Amelia 23:59, 19 August 2010 (EDT)

Royalties [19 August 2010]

Hi Dallan,

You are owed royalties of $16.50 from FGS 2009 in Little Rock but I don't have an address to send them to. Please send address to treasurer@fgs.org and I'll get a check out.--Fgs 21:06, 12 August 2010 (EDT)

Handled off-line--Dallan 18:10, 19 August 2010 (EDT)

Categories for places that have been renamed [19 August 2010]

Dallan, Place:Acy, Ardennes, France used to be named Acy, Ardennes, Champagne, France - until you renamed all of France back in Sept. Now, Acy is appearing in the newly created category Category:Ardennes, Champagne, France. However, the automatically created category at the bottom of the Acy page says Category:Acy, Ardennes, France. Furthermore, if we are using the current naming scheme as a guide, the category at the bottom of the Acy page should be Category:Ardennes, France.

Similar category problems are happening for Portugal, Friesland NL, and I believe any other renamed place. --Jennifer (JBS66) 06:33, 16 August 2010 (EDT)

I just fixed the categorization level for France (categorize at the department level instead of the city level). But the fix affects only pages that are edited from now on. All of the pages edited prior to today will continue to be in the old (city-level) categories, even though the pages will start displaying the new (department-level) categories. The problem is that the system only re-generates a page's category membership when it is edited. So if places are renamed, the pages continue to be in the old-named categories unless I force the system to re-generate the category memberships. I've just started a process to re-generate the category memberships, but it takes several days to run.
This is a good argument for having the system simulate a category structure in the future without creating actual category pages -- so that place renames take affect immediately without needing to forcibly re-categorize the pages.--Dallan 18:10, 19 August 2010 (EDT)

Bug in creating MySource title from GEDCOM [24 August 2010]

I submitted a GEDCOM with a source title with text in italics. I also matched families before matching sources (which I now realize is a problem), and as a result, several records include reference to a non-existent MySource. That's fine - I know how to clean them up and will do so. However, I noticed that the MySource title in the reference kept the HTML markup for italics in the title (albeit with parentheses instead of angle brackets) as (i) ... (/i). For example, see references 2 and 3 on this page: Person:Richard Odell (3) - I'll hold off on cleaning this page up until you have had a chance to look at it.

Here is the data from the GEDCOM file:

0 @S1@ SOUR

1 ABBR Turney - Odell

1 TITL Mrs. Turney Sharps, "Turney - Odell," The American Genealogist 1

2 CONC 4 (1937): 224-228

I don't know if this bug would have occurred if I had not matched sources after matching families, but thought you might want to check it out anyway. BTW, the italics in the citation text were handled correctly (see reference 3 on Richard Odell's page).--DataAnalyst 12:01, 20 August 2010 (EDT)

Yes, the non-existent MySource is because you matched sources after matching families (the situation we've been talking about lately). I didn't expect people to have html markup in gedcom source titles, so I didn't plan for it. Wiki page titles don't handle angle brackets very well, so I convert them to parentheses. But what I should do is just remove html tags from MySource titles altogether. I'll add that to WeRelate:ToDo List.--Dallan 11:02, 24 August 2010 (EDT)
Thanks--DataAnalyst 19:42, 24 August 2010 (EDT)

new place name for Scotland [14 August 2019]

Hello, On Sept. 3 a new place name for Scotland called "Kingdom of Scotland" was created and I would like to see it redirected to "Scotland, United Kingdom" because "Place" for some of my people entered on werelate are defaulting to this new place name and I can't see how to stop it. When I type "Scotland" for a place the system auto defaults to this new "Kingdom of Scotland" and I don't like it and can't seem to change, delete, rename or redirect it.

Thanks for your help. --Susan Irish 17:55, 7 September 2010 (EDT)


A GEDCOM uploaded today with England as the location was getting matched to Place:Kingdom of England. Not sure why this is preferred to other choices, such as Place:England? Is it based on last modified date, and the above update moved this to the top of the list of places matching England? --Jrich 18:03, 7 September 2010 (EDT)

Same problem here. My theory is it's because the Kingdom of England page has it as the name of England during the right dates for those events, since the user uploading doesn't seemed to be involved with that page. But I think this violates the rule about place pages being named according to their current name. It's also not a sustainable solution - what, we're going to have two (or more) place pages for every place in England, Scotland and Wales? I'd like to confirm what the correct/preferred approach is for "old" place names before figuring out what to do, though. --Amelia 18:58, 7 September 2010 (EDT)

Sorry for being obscure. The GEDCOM (user uploading) did not do anything, the reference to modified dates was because a user redirected Place:England to Place:England, United Kingdom on 3 Sep. Don't know how all this affected things, but I bet automatic matching was affected somehow. --Jrich 19:18, 7 September 2010 (EDT)
Agreed - and I modify my theory, since it doesn't matter what date one uses with "England" - the system is choosing Kingdom of England even if you say 1850. And it's even changing some places that do exist to places that don't (i.e. London, Middlesex, England to London, Middlesex, Kingdom of England). I don't have the brain power this late to contemplate how this should work, but this is definitely not it.--Amelia 01:48, 8 September 2010 (EDT)

This brings up another expanded topical subject of associated UK placenames. We have the Place:Commonwealth of England place name, the Place:Kingdom of England place name, the Place:England, United Kingdom place name, the Place:Kingdom of Great Britain place name, the Place:United Kingdom place name, the Place:Commonwealth of England Scotland and Ireland place name, the (Place:England and Wales, United Kingdom [link removed --cos1776 17:17, 14 August 2019 (UTC)]) place name, and the Place:United Kingdom of Great Britain and Ireland placename. Most include variants of the countries of England, Northern Ireland, Scotland and Wales. The overlapping duplicity of the designations and inclusions are confusing, and the fact that they are based partly upon overlapping administrative, historic, geographic and political divisions makes it even more confusing.--BobC 12:47, 8 September 2010 (EDT)


In addition to the above problems, Place:Wales now is automatically matched to Place:Australia and Place:Northern Ireland is matched to Place:United Kingdom. Place:England, Place:Scotland and Place:Northern Ireland were renamed to Place:England, United Kingdom, Place:Scotland, United Kingdom and Place:Northern Ireland, United Kingdom, without any of their contained places being renamed. I believe this is all a result of User:David Newton's recent place renaming based on this conversation. He also renamed some of the counties in Ireland like: Place:Antrim, Northern Ireland to Place:County Antrim, Northern Ireland, United Kingdom. I'm sure this must be affecting the place matching. --Jennifer (JBS66) 10:16, 12 September 2010 (EDT)


This is my mistake, argh. I told User:David Newton that he could rename the places to be more "correct", without realizing that because the place matcher code prefers places with fewer commas to places with more commas, renaming Place:England to Place:England, United Kingdom would cause the place "England" in a GEDCOM to be matched to Place:Kingdom of England, since it doesn't have commas in the title and Place:England, United Kingdom does. So I'm renaming the places back, and putting United Kingdom as an also-located-in. Someday I need to enhance the place-matching code to avoid this limitation, but until then renaming is the best solution.--Dallan 14:30, 13 September 2010 (EDT)

Outside the change in matching algorithms, wasn't part of your comment that if he wanted to rename the thousands of pages, he could? I.e., not just Place:England to Place:England, United Kingdom, but shouldn't Place:Fordham, Essex, England be renamed to Place:Fordham, Essex, England, United Kingdom, et al. ad naseum, which didn't happen. Also, should the Place:Kingdom of England place be there at all? If it wasn't there, what would have happened? --Jrich 21:19, 13 September 2010 (EDT)
Technically, that's true. At some point I'll need to write a program to rename all of the pages. We wouldn't have had the problem if Place:Kingdom of England hadn't been there, but it's been there for awhile. FamilySearch has been contracting me to improve their place matching algorithm, so soon I'll take what I've learned doing that and apply it to WeRelate.
The problem with this situation is that according to the rules for naming places developed for the Wiki they really should be like that. As in the US sections of the website UK place names are canonically four-level in genealogy. In the UK counties are really going slowly out of use as administrative areas in many places. All of the metropolitan counties were abolished over 20 years and Berkshire has been gone for administrative purposes for over a decade. However genealogical naming traditions do not necessarily take account of administrative changes. What would be really good for this site would be redirects so that all of the historical changes in county are taken care of. Nonetheless if what I have done is causing problems for GEDCOM recognition then it probably needs to be undone.
The place names are supposed to be as of 1900. Admittedly somewhat awkward, but keeps things from being a moving target. It doesn't matter, for example, what the roll of counties today might be, it matters what county it was in 1900. It also means you don't need to be able to supply a precise date in order to know the correct place name. Imagine, you find out a birth date is off by a year because somebody made an error with pre-Gregorian dates, and the name of the birth place changes. --Jrich 21:19, 13 September 2010 (EDT)
The place names are indeed supposed to as of 1900 in theory. However that does not take account of the fact that a great many people will not have place names which correspond to that rule in uploaded GEDCOMs and newbies will not necessarily know the rule when editing. Consequently having redirects to deal with the historical variants is probably the best way of dealing with the problem. David Newton 16:57, 15 September 2010 (EDT)
However the renaming of the counties in Northern Ireland and the Republic of Ireland should not be undone. The counties need to be distinguished from the cities and towns with which they share a name and the correct name for them is County _________, never just the name alone. Another situation which was really bad was having the West Midland metropolitan county and the West Midlands region going to the same page. They are vastly different areas, although the region does incorporate the former metropolitan county. As a whole the region incorporates Staffordshire, Shropshire, Herefordshire, Worcestershire, Gloucestershire, Warwickshire and the old West Midlands metropolitan county.
I don't understand the county argument. In the US, there is Place:Barnstable, Barnstable, Massachusetts, United States (and lots of others). The word county may help clarify but is not used and is not strictly needed. Place:Barnstable, Massachusetts, United States refers to the county, the 4 part name to the city. --Jrich 21:19, 13 September 2010 (EDT)
I know that the use of "County X" in Ireland is much more prevalent than the use of "X county" in the US. I've never had anyone say that we needed to drop County from Irish counties, and I wasn't sure which way to go when I created the counties initially, so I don't mind it being added.--Dallan 12:37, 14 September 2010 (EDT)
If you talked about Cork, Ireland the default would be to assume that the city was being referred to. Cork, Cork, Ireland is also never used that I have come across. County Cork on the other hand is the standard name for the county and is unambiguous. The difference between Ireland and Great Britain is that in Great Britain county names are pretty much uniformly distinct from the county town: Dorset and Dorchester, Warwickshire and Warwick, Norfolk and Norwich, Aberdeenshire and Aberdeen etc. It is definitely the case that the dropping of the word county from the name occurs extremely rarely.
I would also question the practice of dropping the county suffix from the place name in US locations. I know that I was very confused when I saw Place:Utah, Utah, United States whereas if I had seen Place:Utah County, Utah, United States it would have been immediately obvious. Nevertheless that is a separate and distinct discussion from the question of Irish counties. David Newton 16:57, 15 September 2010 (EDT)
Except that it isn't used that way in the US. One might refer to Utah County, Utah, United States, but not County Utah, Utah, United States. -- Amy 22:22, 15 September 2010 (EDT)
I know it's that way in the US but I appear to have swapped things round without realising it. Thanks for pointing that out. I have fixed the issue. David Newton 02:58, 16 September 2010 (EDT)
Slightly more than 50% of incoming gedcom's omit "county" in the US, when I did a study a couple of years ago. FamilySearch's library catalog also omits county, so the standard is to omit county. The only exception is the one we just made for Ireland.--Dallan 15:39, 19 September 2010 (EDT)
Hopefully the GEDCOM matching algorithm can be weaned off its dislike of commas and the correct names for the areas of the UK can then be restored. David Newton 14:39, 13 September 2010 (EDT)
I didn't rename the County___ places, and I've added preferring exact-match on name to fewer commas for the place matcher to my todo list.--Dallan 14:56, 13 September 2010 (EDT)
What is the plan for renaming places like Place:Ballynoe, Cork, Republic of Ireland? Now that Cork has been renamed to County Cork, all the places underneath are misnamed. --Jennifer (JBS66) 14:03, 4 November 2010 (EDT)
I hadn't planned on doing anything in the near term. It doesn't matter to the system, since Place:Cork, Republic of Ireland redirects to Place:County Cork, Republic of Ireland. I'm hoping that it doesn't cause too much confusion.--Dallan 23:14, 4 November 2010 (EDT)

Error in importing GEDCOM [13 September 2010]

Dallan, I imported HCShannon's GEDCOM this morning and it merged at least one of the family pages incorrectly. It merged to the page with the "unknown" spouses instead of the one with their names. One of the pages involved Person:Marie_Renaudeau_(1). Is there any way you can unmerge those family pages? Thanks. --Amy 08:41, 9 September 2010 (EDT)

I added the family: Family:Jean Garnier and Marie Renaudeau (1). But I'm not sure if this is a duplicate of Family:Unknown Garnier and Unknown (1) (the page the gedcom family was originally merged with). Both families (gedcom and wiki) have a daughter Person:Marie Garnier (1) who according to the gedcom and the existing wiki page was married to a fellow named Olivier CHARBONNEAU, though the gedcom lists her as being born in 1617 and the existing wiki page says 1626. So I didn't create a separate page for the daughter, but left her merged with the existing wiki page.--Dallan 15:22, 13 September 2010 (EDT)
Thanks for looking at that. I think it is another example of why merging on import isn't a good idea. It never gave me the option to set the target family. I think it would be much better -- not to mention much safer and accurate -- to create the pages just like they were new. Then after import, the person who uploaded the file could get a message either with a list of possible matches or to at least prompt them to run "find duplicates." While the goal is to have one page per person/family, I'd rather have a duplicate page than two that were merged incorrectly like this one was. -- Amy 15:45, 13 September 2010 (EDT)
I've become convinced that merge during import isn't a good idea, but I still think that match during import is. The match work is the same whether it's done during import or after. If we require matching to be done during import, we avoid the problem of people who import and then never review their matches, resulting in duplicate pages that don't get cleaned up.
The problem above is probably that the uploader clicked on "Match related" on the daughter's family, and since the daughters of these two families matched and the parents didn't differ significantly, the system auto-matched the parent families as well. I plan on removing the "match related" functionality in the future because I think it's too non-obvious (leads to problems like this). Once "match related" is removed, the uploader will be required to manually accept every possible match during gedcom upload.--Dallan 16:02, 13 September 2010 (EDT)

"Trusted User" [13 September 2010]

I know there was a discussion of this somewhere but can't find it now. Just wanted to pass on this article by Dick Eastman which discusses wiki sites and 'trusted users' as a way to cut down on new users messing up already carefully formatted pages. Thought this might be food for thought: http://blog.eogn.com/eastmans_online_genealogy/2010/09/wikitree.html --Janiejac 09:31, 11 September 2010 (EDT)

Janie, apples and oranges. I believe the "Trusted User" concept as used by WikiTree is a cross between the WeRelate "Watcher" function and an opening up of the "Privacy" function for semi-private collaboration of whole family trees, not the "Trusted User" concept Dallan proposed at a Watercooler topic relating to modifying GEDCOM imports to ease the import requirements for experienced, truster users and to develop a stricter and more guided process for untested newbies. In WikiTree contributors maintain "ownership" and become managers of their family trees, granting access and permission to select others by name to help maintain or contribute to a portion of their trees. Trees are not true community assets as they are here, even for deceased persons. While the WikiTree process enables the inclusion of living individuals, it severely restricts the visibility and availability of a majority of the information for casual "uninvited" viewers, even to information for non-living individuals. --BobC 11:57, 11 September 2010 (EDT)
And for what it's worth, attempting to restrict visibility to certain specific pages is not recommended. After reading Dick Eastman's writeup I'm not sure if that's what Wikitree is trying to do, but if it is, the MediaWiki folks recommend creating separate wiki's with interwiki links.--Dallan 15:37, 13 September 2010 (EDT)

Search for People [19 September 2010]

Hi Dallan, Just tried 'Search' 'People'. Page came up as a search for a book or other authored source. Amusing, but not overly helpful. {:>) --Neal Gardner 16:24, 15 September 2010 (EDT)


I see that it also gives actual people, but the top section is a little disconcerting at first, so never mind...--Neal Gardner 16:28, 15 September 2010 (EDT)

Sorry, I have no idea what you're talking about. Selecting People from the Search menu searches pages in the Person namespace.--Dallan 15:41, 19 September 2010 (EDT)

sorting articles on category page [25 September 2010]

Dallan, The Category:Jackson Surname has already got WAY too many pages to scroll through and we're just getting started! I could put an alpha table on the first page but that wouldn't help because it still would sort into all 'F' and 'P'. So what is the solution? Is there anyway to sort by the first name? I'd love to sort by state, county and then first name but ??? --Janiejac 17:04, 22 September 2010 (EDT)

Which state? the one they were born in or the one they died in? I suspect sort order will vary based on the preferences of the reader and what they might be trying to find on the page. Perhaps it would be nice to have access to a dynamic sort so the reader could choose what is most convenient to them. --Jrich 18:02, 22 September 2010 (EDT)
That viewers choice sounds even better! But if we have to take this in steps, just getting to sort by first name instead of only two choices - family or person - would be a great start! I'll bet the Smith page is even going to be worse than Jackson. --Janiejac 18:34, 22 September 2010 (EDT)
It does sort by first name - within namespace. The problem is that it is so many "Next 200" to get to the start of the Person namespace (roughly a dozen), it is too daunting. Perhaps a "jump to" feature ("Person:K" jumps to beginning of the K's)? --Jrich 18:44, 22 September 2010 (EDT)
I agree that some of the categories are already starting to become unwieldy. As part of an improved search that I'm working on, I'm going to demo an possible alternative approach to browsing that will allow people to filter pages by place, surname, and namespace, and sort the pages by title. Let's talk more when I have the initial cut ready to show.--Dallan 17:31, 24 September 2010 (EDT)
I have a suggestion for Surname catagories. How about pages listed under oldest ancestor or DNA or location? Or maybe by WeRelate number (1) or by WeRelate User? Would any of these ideas work?

Debbie Freeman --DFree 18:54, 24 September 2010 (EDT)

RE location - like above, which one? birth, death. Using some "of" location that is different than those two would require adding a new field. RE DNA - probably not known for most pages, would need a new field. RE Oldest ancestor - would involve a lot or processing to collect it, and if it goes through a spelling change (i.e., Snyder to Schneider) or connects to a medieval line (i.e., Baron Ulrecht of Obscurantia) would you recognize it? Or would all of a surname end up connecting into the same person providing no simplication? Re WeRelate number: it sort of does already sorting by title - just not a numeric sorts, so John Smith (11) would precede John Smith (2), but it's a predictable ordering. RE WeRelate User: which one? If 20 people are watching a page do you want that page repeated under all twenty user names? I think your suggestions are sort of solving a different problem that what was under discussion. It is not so much about finding a page based on criteria (search does that), or about the ordering of the list (if you know which page you want you already can predict where it will be in the list), but jumping to the desired spot quickly. Filtering works because it makes the list effectively smaller. I think a jump-to function, or some type of table of contents would also work, so whatever seems easiest/best for Dallan. --Jrich 19:40, 24 September 2010 (EDT)
I was thinking that filtering by location would include any event, so setting the location to "Virginia" would list people with birth, marriage, death, or census, etc. events in Virginia.
I could conceivably also add filtering by user, so you could see a list of all users watching "Smiths in Virginia", and filter that list to just those being watched by DFree for example. I could also add filtering by given name initial, so you could filter the list to Smiths in Virginia whose given names started with the letter K.
Using the approach that I'm considering, filtering by various criteria is relatively easy, sorting is more difficult. So I'm hoping that we can get by with just one sort (by page title) combined with various ways to filter (narrow down) the list: by place, surname, given name, namespace, and/or user.--Dallan 01:18, 25 September 2010 (EDT)

Contained places [25 September 2010]

Dallan, it seems as though contained places only appear on parent pages when they contain coordinates, otherwise they are missing. Was this always the case, or is this new since the site redesign? I thought that pages used to appear as contained based upon the the page title. --Jennifer (JBS66) 11:44, 25 September 2010 (EDT)

I take this back... This seems to be a cache issue instead. A null edit caused the page to appear as a contained place as well. --Jennifer (JBS66) 11:54, 25 September 2010 (EDT)
We've had some problems with that in the past; looks like I didn't find them all. Null edits are (unfortunately) the best way to go until I get around to finding and fixing them.--Dallan 12:00, 25 September 2010 (EDT)
I'm finding this happening for new place pages being adding during gedcom upload. Is there a way to update the cache just after the new page is created? --Jennifer (JBS66) 13:28, 25 September 2010 (EDT)
Do you have an example of a place that is not listed as a contained place of it's parent? There is one of two possible problems going on; it would help to see an example so that I can figure out which problem it actually is. Alternatively, did you edit the parent place or the child place to cause the child to show up? If editing the parent place fixed the problem, then I know what the problem is. If you edited the child place, then it could be either problem, and looking at an example of a place that doesn't show up in its parent would help me sort out the issue.--Dallan 14:06, 25 September 2010 (EDT)
Place:Heesterkante, Laar, Hannover, Preußen, Germany is one example. It doesn't appear on the Place:Laar, Hannover, Preußen, Germany page. Place:Deusen, Dortmund, Westfalen, Preußen, Germany is another. These examples come from User:Ekjansen's gedcom that is in the uploading queue. I realize the pages may not necessarily fit our naming scheme, but they illustrate the point.
On his NL places, I edited the child page, which caused it to appear on the parent page. I don't think I tried a null edit on the parent yet. --Jennifer (JBS66) 14:31, 25 September 2010 (EDT)
Thanks. I know what the problem is now. I'll fix it early next week.--Dallan 22:33, 25 September 2010 (EDT)

Gedcom upload error? [5 October 2010]

Hi Dallan, just want to bring this to your attention. It looks like some sort of html code for italics in the titles of MySources with a recent gedcom upload. --Jennifer (JBS66) 18:06, 4 October 2010 (EDT)

A few gedcoms have sources that look like this -- titles contain things that look like html or proprietary formatting codes. Someone else reported something similar a few weeks ago. Removing html and proprietary formatting codes from gedcom sources before creating MySources for them is on my list of things to fix.--Dallan 13:25, 5 October 2010 (EDT)

Front page "News" [16 October 2010]

Um, you might want to update the "News" section on the front page. We came back from FGS a while ago. . . . :) --MikeTalk 12:56, 11 October 2010 (EDT)

Yeah, I know. I can't think of anything "newsworthy" that's happened this past couple of months. I'll keep thinking about this; if you have any suggestions, let me know.--Dallan 18:15, 11 October 2010 (EDT)

Might I suggest plugging the Genealogycenter.org launch?--glamberson 07:22, 14 October 2010 (EDT)
Great idea! Thanks.--Dallan 13:04, 16 October 2010 (EDT)

Gedcom import of surnames with more than 3 parts [28 October 2010]

Dallan, I know I've mentioned this before, but I don't recall what your proposed remedy was. There is still a bug during gedcom upload that causes surnames with more than 3 parts to be titled incorrectly. The title for their person and family pages stops at 3 parts and drops the remaining. The full surname does appear in the data field, however. --Jennifer (JBS66) 06:27, 14 October 2010 (EDT)

Sorry, could you give an example page title that's messed up?--Dallan 13:04, 16 October 2010 (EDT)
Each of the pages in this category. However, they've already been renamed and the redirects deleted. The pages came through in a gedcom upload with van Harinxma thoe Heeg correct in the surname field. The page titles were incorrect though, and only contained Van Harinxma Thoe. --Jennifer (JBS66) 05:43, 19 October 2010 (EDT)
I see the problem -- I'll add it my list of things to do.--Dallan 20:31, 28 October 2010 (EDT)

Getting a duplicates message... [18 October 2010]

Hi Dallan,

Thanks for all the help you've been giving in getting various bits of my information uploaded.

Right now I'm getting a duplicates message on a GEDCOM with a total of something like 35 people in it. This GEDCOM is a supplemental one which contains the sibling information for one of my direct lines previously uploaded. There are duplicates, but they are from the identical, unchanged information previously uploaded and so are easy to merge during the normal process. I've been doing this regularly, adding meat to the skeleton, as it were. This is a small group, but doing these small pieces allows me to keep track of what I'm doing better. Could you please go ahead and load this Wilsons1.ged for me? Also, if there's something else you recommend in terms of process, I'm all ears. Thanks.--glamberson 07:19, 14 October 2010 (EDT)

It's already loaded. --Judy (jlanoux) 12:03, 14 October 2010 (EDT)
I checked the file uploaded, which is entitled wilsons1.ged sized about 37k and created 14 Oct. about 6AM. I imported this file into its own, new database in my genealogy program to confirm it was what I thought it was. It is. This data has duplication, but it also contains the core of the information I need imported. This is one of my 4 Wilson families, and many of these families share similar names form the same areas during the same times. The core of the aforementioned file is in fact not something I have previously imported (besides the acknowledged overlap which I will accommodate as part of the import process). As mentioned, now I am getting a Notice (message) when opening FTE in my default tree that says the following: "Notice - Your GEDCOM appears to overlap with a GEDCOM you uploaded previously. Please click on the 'My Relate' button near the top of the page on the right, then click on the 'Check messages' for more information." Perhaps the message is outdated, because it is now not possible to successfully follow its instructions to determine the problem or what to do. So, at this point, I would like to: 1. Get this message removed when I use FTE in my default tree; and 2. I would still like to get the aforementioned data in the aforementioned file uploaded. Uploading this data is specifically germane at the moment because, as I have seen many times, there are those who are mixing up these families on this site, and I would like to add sourced information to one of the families to help illustrate the problems (see Person:Nicholas Long (10) Person:Nicholas Long (7) ). Nicholas Long was the half brother of James Wilson according to his affidavit... If I need to do something, please advise. Thanks.
It looks like you have been creating a new tree each time you import. This eventually results in the overlap problem. I prefer to do all of the imports into a single tree. You can create a new tree at any time that you need one, but a single tree is easier to manage. If you keep getting the overlap message, you can try using the existing tree that contains the people who overlap and see if that helps.
re Nicholas Long. It sometimes helps to put links to the pages for the other same-name people in your disambiguation paragraph.If they don't exist, you can create one with enough info to help someone tell them apart. Leave a note on my page if you need help with this. I may not be catching exactly what the problem is. --Judy (jlanoux) 12:28, 15 October 2010 (EDT)
No, I clearly haven't been, which is clear if you look at the fact that several GEDCOMS are associated with my default tree. The other trees I have created are each for parts of a one-name study that show little to no likelihood of being related. When I have done imports for groups likely to be related, I import them into the tree with which they are likely to have eventual convergence. Am I supposed to just accept this problem? The problem with Nicholas Long and is nothing I can't handle. I would like a solution to my technical issue. Is Dallan on vacation?

Messages that say "appears to overlap a previously-imported GEDCOM" require that Dallan give them special permission to import. You can leave a message on his talk page here (which you've done), or email him, both of which he usually handles promptly. You will need to provide him with the name of the gedcom (which I believe is WILSONS 1.GED from your talk page). I think the problem here is that there was some confusion as to the nature of your problem. --Jennifer (JBS66) 17:59, 15 October 2010 (EDT)

Just to be clear, I now am attempting to import a file called wilsons2.ged. This eliminates quite a bit of the duplication of wilsons1.ged but contains the information needed (which is very small anyway). Thus I NO LONGER NEED wilsons1.ged imported but I DO NEED the message in FTE regarding duplicates to be resolved.
Wilsons2.ged gives me the duplicates error as well, so I would appreciate help on these two issues: 1. Importing wilsons2.ged (which replaces wilsons1.ged but either/or would be fine to stage for me to process for importation); and 2. Removing the above-mentioned message that I continue to get within FTE on my default tree. Thanks.
As Jennifer mentioned, Dallan will have to handle overlap issue. I confess I didn't understand your reference to duplicates. I've never seen that in FTE. But have you tried checking the Find Duplicates list on the MyRelate menu. When adding people this should be looked at fairly regularly as things will pop up. But I'm not sure that is your issue. --Judy (jlanoux) 21:48, 15 October 2010 (EDT)
Yes, thanks, I have looked at all duplicate candidates as detected by that option. They're actually quite few, and I have gone through each of the possibilities which, as you suspect, has not addressed my problem. I'll wait for Dallan. There's plenty other work to do. Thanks.

I'm sorry for the delayed response. I've released Wilsons2.ged; it's processing now. I just tried opening FTE on your default tree and didn't get an error message. Do you still get an error message opening FTE on your default tree?--Dallan 13:04, 16 October 2010 (EDT)

Thanks for getting Wilsons2.ged taken care of. Unfortunately when I open FTE on my default tree, I do still get the aforementioned notice within FTE.
I found the problem. Please try it again now.--Dallan 23:11, 18 October 2010 (EDT)

Upload Gedcom [15 October 2010]

My Gedcom file has over about 11,700 names. Can this be uploaded to Werelate? Barbara Pixley troypix@msn.com--Troypix 19:53, 15 October 2010 (EDT)

Barbara, Take it from me, a pretty new user here myself with over 3 decades of genealogy experience and about 16,000 reasonably-well-documented persons in my working data: Start smaller. Try a subset of around 500 or something. You'll want to go through a process of checking your data during import that is properly detailed, and that process would be overwhelming for such a large import. I wanted my entire main dataset imported initially, but upon doing a subgroup of about 1100 because policy here prevents uploads of more than 5,000 persons, I was very glad of the initial limitation.
I agree--Dallan 13:04, 16 October 2010 (EDT)

Dates and places of my GEDCOM do not appear in compare pages. [19 October 2010]

I'm comparing my pages with possible dups and find my side has no dates or places for marriage, and sometimes places for birth and death. I can't compare well without knowing the differences. Is something wrong with my GEDCOM?--Bigdeacon 09:26, 18 October 2010 (EDT)

I took a look at a few items on the Family Match page. While the system is designed to show the information, it appears that many of your families are missing marriage dates. You also have many people without dates. You can see this if you check the Person and Family tabs. I'm not sure that there is anything wrong with your gedcom. You may not have the info in your database. If you don't have information on these people and they appear to be matches, you can simply match them and not do updates to the existing page. This will prevent the creation of duplicate people and families. --Judy (jlanoux) 16:03, 18 October 2010 (EDT) (WeRelate volunteer who worked on your file)
FWIW, the first three unmatched families in the match list don't have marriage dates listed in the gedcom file.--Dallan 23:11, 18 October 2010 (EDT)

Thanks. I have discovered the problem. I use iFamily for Mac Snow Leopard and there is a glitch in the GEDCOM creator. The option to depersonalize living people has three options and if you pick the third it depersonalizes everyone in the database. To those of you who use this program, do not pick option three. My GEDCOM is now ok and I'm fixing the warnings and family matches. Thanks again. Bigdeacon--Bigdeacon 09:58, 19 October 2010 (EDT)

Thanks for the information regarding your gedcom. Added link and info to Help:GEDCOM --Beth 21:19, 19 October 2010 (EDT)


Edit button [28 October 2010]

My edit button has disapeared from all my person pages and family pages. Can you tell why? can it be fixed?--Tarbet 12:48, 20 October 2010 (EDT)

Make sure that you're logged in (look for a sign-in link in the upper-right corner).--Dallan 20:31, 28 October 2010 (EDT)

Thoughts on the Tapestry Projects [28 October 2010]

Hi Dallan,

Just wanted to pass on some random thoughts as I'm trying to work through some navigational problems on WeRelate. I have some Jacksons who were in Anson, NC when they redrew the state survey line and they ended up in SC even though their grants and deeds all read NC. When I saw Bill Willis' Carolina Cradle Tapestry I immediately went to that to see just what geographical area that covered. And the more I looked around, clicking from one link to another, the more I liked it.

Then too, I have Jacksons in very early Virginia which became West Virginia - and I checked out Jim's Old Augusta Project. When I first began putting articles on WeRelate, I found I couldn't remember what I had put where, so I created a category just for my pages. But when we went through the Category Project, the consensus was that we should not have 'personal' categories - that if every user did that, it would become unmanageable. So I was back to not being able to find my pages and began putting links to my pages on a user page. Well, that has helped, but the more I see of the index at the Tapestry pages, I see that is even better than my personal category would have been. By using the Tapestry navigation box I'll be able to find not only what I have added to this study, but any pages that anyone else adds to the same study.

Just yesterday Beth Gay used my Jackson in Virginia, United States table of counties to create a page for Jackson in Surry, Virginia. Then she went to my talk page to let me know she had created this page because she knew I wouldn't be notified of this new page. I think if I create Tapestry: Jackson navigation box and encourage folks to use it, this would give another way to know what is happening to other Jacksons in all areas. Bill Willis has offered to help me with this and I think I'd like to try it.

But I also read the criticism by Jrich who obviously was very frustrated by this outside-the-box use of WeRelate. I for one love and appreciate what Bill has done with his Southwest Virginia Project Tapestry and don't really understand why Jrich is so upset by it. If it works for Bill, Great! If it doesn't work for Jrich, then he can pass it by.

So I have no idea what your take on this is but I wanted to mention that I want to learn what I can about the way the Tapestry format functions and hopefully will put my Jacksons into such a navigational box. I did have to ask Bill for a description of the various page types - that is - what is the difference between an analysis page vs a data page. He said that his work on that had outgrown his documentation, so he wrote it all out for me and that helped tremendously. Then he said my question had helped him know to get it all on paper (and prob on a page on WeRelate). So we grow in knowledge together.

Isn't WeRelate wonderful?? I told Bill I thought he was stretching our mental image of what a genealogy site could do! --Janiejac 15:26, 21 October 2010 (EDT)

Please don't do anything with this right now. I'm working with Bill to try to figure out how to standardize what he's been doing. I don't think it's helpful to have part of the site work one way and part of it work another. I'd prefer to take the good ideas that Bill has developed and to try to make them work everywhere. That will likely mean changing a lot of pages, and the fewer that have to be changed, the better.--Dallan 20:31, 28 October 2010 (EDT)

Delete duplicate user account [28 October 2010]

Dallan, can you either merge or delete an account? User:Lidewij inadvertently created this account and User:Lidewij C J.. She would like the User:Lidewij C J. account deleted. Thanks, --Jennifer (JBS66) 17:12, 23 October 2010 (EDT)

done--Dallan 20:31, 28 October 2010 (EDT)

Please generate this gedcom [28 okt 2010]

Jacobus Lucas- KALISHOEK-ASC.ged appears to overlap a previously-imported GEDCOM [28 okt 2010] The pages from this GEDCOM have not yet been generated because they appear to match pages from a GEDCOM you have previously imported to WeRelate.

If you don't think you have already imported a GEDCOM containing people in this GEDCOM, or if the two GEDCOM's don't overlap that much, leave a message for Dallan or send an email to dallan@WeRelate.org and we'll go ahead with the import.

--WeRelate agent 08:09, 28 October 2010 (EDT)

This is a very small gedcom, only 1 person with his father and mother, so please give this free for importing, as usual I'll merge duplicates ! --Fred Bergman 09:16, 28 October 2010 (EDT)--Fred Bergman 16:26, 28 October 2010 (EDT)

done--Dallan 20:31, 28 October 2010 (EDT)

Queen update gedcom [28 October 2010]

Dallan, Thios gedcom is a few people who did not make it into my original Queen gedcom. There will be one person who will be a duplicate who I will merge. The rest of this gedcom will add his decendants who were left out originally. Thanks Jim--Tarbet 17:49, 28 October 2010 (EDT)

done --Dallan 20:31, 28 October 2010 (EDT)

Small glitch with gedcom in queue [10 November 2010]

Dallan, User:Kalishoek has a gedcom in review. There are 2 Person and their Family pages that cannot be viewed. I've tried both Firefox and IE, but the pages never load. I wanted to make sure these people/families will import into WR, and I also wanted you to see the problem.

The people are Gabriel Gijzen and Gijzen. The families are Gabriel Gijzen and Anna Elizabeth Clement and Gijzen and Unknown. Thanks, --Jennifer (JBS66) 14:18, 5 November 2010 (EDT)

Dallan, I imported the file. She has worked pretty hard on this today, and I wanted to get it uploaded for her. Sorry if that causes problems, but I figured that we could, perhaps, upload the gedcom again if need be to recreate the error. btw, the gedcom review also lost Gijzen's first name (Johannes) and his wife Maria Elisabeth Duchenne. --Jennifer (JBS66) 17:49, 5 November 2010 (EDT)
I looked at the wiki pages that were generated for these people and families and they look ok. So at least the pages are being generated correctly.--Dallan 16:06, 10 November 2010 (EST)

Parenteel Dirck-BORGMAN-DESC.ged appears to overlap a previously-imported GEDCOM [12 nov 2010]

Indeed it overlaps partly a previously-imported GEDCOM, but I do want it to be uploaded. I will improve and merge all duplicates. --Fred Bergman (User:Bergsmit) 12:28, 11 November 2010 (EST)

It should be importing now.--Dallan 12:35, 11 November 2010 (EST)
Thanks! --Fred Bergman (User:Bergsmit) 12:55, 11 November 2010 (EST)

Elisabeth Catharina- ROOS -all ASC.ged appears to overlap a previously-imported GEDCOM [13 nov 2010]

Indeed it overlaps partly a previously-imported GEDCOM, but I do want it to be uploaded. I will improve and merge all duplicates.--Fred Bergman (User:Bergsmit) 15:24, 12 November 2010 (EST)

I cleared it for import.--Dallan 10:55, 13 November 2010 (EST)
Thanks! --Fred Bergman (User:Bergsmit) 11:05, 13 November 2010 (EST)

Searching a tree with trailing spaces in name [23 November 2010]

Hi Dallan, User:Kalishoek brought up a problem searching her tree using the link from her userpage. When you click View from her De Koning family, the search comes back empty. It appears that the name of her tree has trailing spaces, is this causing the search problems? I tried a wildcard at the end and removing the spaces, but neither helped. She could rename her tree to remove the spaces, but I recall a bug with indexing renamed pages. I thought I would check if this was fixed first before I suggest this to her. Thanks, --Jennifer (JBS66) 07:39, 15 November 2010 (EST)

I renamed the tree and re-indexed the pages. It should be working now.--Dallan 23:24, 22 November 2010 (EST)
I made a null-edit on her user page, and the View link works fine now. Thanks!! --Jennifer (JBS66) 04:11, 23 November 2010 (EST)

Watcher in search but not on page [22 November 2010]

Dallan, I think this was a known bug... wondering if it's been resolved yet.

User:Bergsmit appears as a watcher of many pages according to the search screen, but not on the page itself (ie Person:Adela De Normandie (1)). He was most likely watching it, deleted his tree, and then he was never removed as a watcher of the page in the search. I believe last time we noticed this, you reindexed the pages. --Jennifer (JBS66) 09:27, 21 November 2010 (EST)

Bug is still not fixed; the pages will be re-indexed over the next week.--Dallan 23:24, 22 November 2010 (EST)

Family Tree Explorer [22 November 2010]

I got a message saying that my tree 'John Baylus Harris' was imported succesfully and I should look at it in Family Tree Explorer. However, when I try to do that, the only tree that comes up is my Boughton Tree. No other trees are listed. Is there something I need to do? Ruth--Ruth L 18:42, 22 November 2010 (EST)

You've imported both gedcom's into your "Default" tree. So the pages from your John Baylus Harris should be in the same tree as your Boughton Tree.--Dallan 23:24, 22 November 2010 (EST)

Places with jurisdictional changes [24 November 2010]

A question I had earlier about changing jurisdictional places was answered in the help section. I tried to do what the answer said but it didn't work because I didn't know the exact year the change took place - so it wouldn't accept my change. See http://www.werelate.org/wiki/Help:Place_pages#How_do_I_title_places_with_jurisdictional_changes.3F. I put just what the answer said to put but it wants to know year from & to. I know when WV became a state but it wouldn't even take "Virginia|to 1863" and I have no idea when Mason came into being or when Jackson county was cut out of Mason. I just know it was and wanted to add this info but couldn't. --Janiejac 16:06, 24 November 2010 (EST)

Try "Virginia||1863" (note the two bars)--Dallan 22:15, 24 November 2010 (EST)

Cemetery Category [4 December 2010]

I entered a page for Milford Cemetery, Ellis, Texas, United States. However the category is not set up right. It does not show up when you search the "Cemeteries" section by going to USA, Texas. There is not a link there for Ellis County. Yet the category at the bottom of the page I entered says the category is Ellis, Texas, United States. Can you fix it by editing the page? I just want it to show up in the right place. Thanks,--Sunshine76670 20:43, 27 November 2010 (EST)


Nevermind. It fixed itself when I changed the word cemetery to cemeteries under "type". Thanks, --Sunshine76670 20:50, 27 November 2010 (EST)


Actually, I added the link to the Cemeteries category. Those category links are not created automatically; they have to be added manually. To do so, enter [[Category:Cemeteries of county, state, country|cemetery name]] in the text box. -- Amy (Ajcrow) 21:07, 27 November 2010 (EST)




Parents not displaying on family page [4 December 2010]

On the family page for John Murnahan and Mary King, John's parents aren't showing up above his name, even though he is connected to Edward Murnahan and Mary Clark. I originally imported it from a GEDCOM; he was connected to them in that file. After I noticed this here, I tried removing him from Edward and Mary's family and then adding him back in, but his parents still aren't showing up on his family page. Any ideas? Thanks. -- Amy (Ajcrow) 10:26, 4 December 2010 (EST)

Amy, this is a known bug. To get around this, you can go to John's page, remove his parents and save the page. Then go back into the page, replace the parents and save again. --Jennifer (JBS66) 10:35, 4 December 2010 (EST)
Thanks, Jennifer. It's working now. I swear I did that before and it didn't work! Maybe I neglected to save between deleting his parents and re-adding them. -- Amy (Ajcrow) 10:41, 4 December 2010 (EST)