WeRelate talk:Watercooler/Archive 2010



Archived single-topic discussions ending in 2010

Technical details? - non-GEDCOM import/export, API, MediaWiki extensions, etc. [3 March 2010]

Is there any place which describes some of the technical underpinnings of the site such as the schema used, how things are modeled, etc?

The FOLG site implies that the code is open sourced (since they're advertising for open source collaborators), but I wasn't able to find where the code repository is located. Is it someplace on werelate.org or on a MediaWiki extensions site or a generic Sourceforge style repository or ...?

Is there an API that can be used to access the site? Where can documentation be found?

Any support (or future plans) for import/export of formats other than GEDCOM?--Tfmorris 05:12, 23 November 2009 (EST)

I am interested in the answer to these questions as well. Anybody? --JoshHansen 23:13, 21 December 2009 (EST)

The best way to see the technical underpinnings is to add "?action=raw" to the url of any page (say a person or family or source page). That will show you the actual contents of the page. You'll see that the data is stored in an XML "island" in the page. The XML schema follows the GEDCOM schema fairly closely.
In four years of advertising for open-source developers I've had only one person express an interest, so the WeRelate source code is not open source. It's simply not worth time it would take.
There isn't an API that you can use to access the site, but the page content is available for download in case you are interested - the same as Wikipedia. Are you interested in helping out?--Dallan 23:01, 12 January 2010 (EST)
Hey Dallan, thanks for your reply and sorry for the delay in responding. I suspect that there have been many people over the years who have wanted to contribute to the development of the site, but that the lack of available code has dissuaded all but the most determined. Though it is true that there are some administrative issues with releasing your code as open source (especially when you start to have other contributors that you have to interact with), at the outset opening your code can be as easy as labeling the files with your chosen license (BSD,GPL,AGPL,Apache...) and then uploading the code to a source repository on SourceForge or somewhere else. In the long run, especially as you get more volunteers implementing features on your rather long to-do list, you could save a lot of time by opening the code. An example of another website that has its source available is pgdp.net, which has a project on SourceForge.
My interest in the code is for purposes of putting WeRelate on the Semantic Web. This seems like a fairly straightforward problem, yet as far as I can tell from the graph at [1] there are no genealogy sites doing this yet, in spite of the potential benefits. I think it would be fine to do something quick-and-dirty where we just get the site to generate RDF to go along with each page. We could add a link tag along the lines of <link rel="alternate" type="application/rdf+xml" href="http://werelate.org/resource/Person:Billy_Bob_Bimbo_(1)" title="RDF/XML Representation" /> to each person and family page, and then generate the rdf conforming to the "genealogy-core" ontology, which is a _very_ simple semantic encoding of genealogical information.
Some links: a guy at the BBC talks about why making their site semantic was beneficial [2]. A helpful tutorial document about how to do the integration [3]. Discussion of URI issues [4].
What would be required from you:
  • Put the WeRelate source up on something like SourceForge or Gitorious -- or host your own source repo.
  • Decision support concerning URI and namespace issues
  • Perhaps implementation of some redirects on the web server
In exchange, WeRelate would become the first genealogy site to join the "Giant Global Graph" and as such its data would become even more useful to the world.--JoshHansen 22:10, 30 January 2010 (EST)

Here's what I've done:

  • You can download the full set of pages on WeRelate here.
    • I can update this file for you on a regular basis if you implement your project. The file format is similar to the format that Wikipedia uses for its pages file.
  • I've released the WeRelate Robot Framework as an Apache licensed] code and posted it as a Mercurial bundle here.
    • The WeRelate Robot Framework is a set of java files for reading the page file from WeRelate and parsing the person data. It's similar in purpose to the Python Robot Framework for Wikipedia. Check out the subclasses of StructuredDataParser for examples. If there is enough interest, I'll host this at google code.

This should be everything you need to generate RDF files from the data.

Unlike the robot framework, which I'm happy to open-source, I don't want to open-source the php code that runs the website, at least not yet, because I don't want a bunch of people creating separate genealogy wiki's that didn't interface/synchronize with WeRelate. In my opinion that would defeat the purpose of a shared genealogy website.--Dallan 12:06, 3 March 2010 (EST)

Getty Vocabulary [14 January 2010]

Getty placenames from their Thesaurus of Geographical Names (TGN) are used in WeRelate. According to Source:Getty Vocabulary Program, these were added during a research period when WeRelate was being put together. According to http://www.getty.edu/research/conducting_research/vocabularies/tgn/ (and child pages), however, the kind of large-scale use that the vocabulary is being put to here could potentially run afoul of The Getty's copyright on this material. Could WeRelate's Administration speak to this, please? I am sensitized to this issue through contributing to OpenStreetMap, which is very averse to using copyrighted material as the mission is to create resources which can be used with the least copyright overhead possible. Regards, ceyockey 13:54, 27 December 2009 (EST)

I asked Getty about this when I incorporated their material. They said that as long as I wasn't incorporating their entire database they were ok with what I was doing. I only incorporated the populated places and political divisions in their database, which is a small fraction of what they have (their database also includes geographic features like rivers and mountains). Also, I did not incorporate any of their descriptive information about places, which for certain places is fantastic.
The Alexandria Digital Library also has a place database. It looked pretty good and I received a license to use it, but I ended up not using it.
Open Street Map is very cool by the way. It looks like it's come a long way since I saw it last.--Dallan 20:42, 14 January 2010 (EST)

1st Ohio Heavy Artillery project update [6 January 2010]

There are now two companies complete in my 1st Ohio Heavy Artillery project: Company A and Company B (just completed this morning). All of the officers (commissioned and non-comm) for Company C are also online. There are a few men from almost all of the other companies as well. -- Amy 09:18, 31 December 2009 (EST)

Great job, especially the links to individual Soldiers. I have been pondering doing something similar for the regiment my great-great grandfather served in during the American Civil War -- this might give me the inspiration to start working on it again and make it a reality. BTW, I added the Civil War category to those pages.--BobC 09:33, 31 December 2009 (EST)
Yes, Amy, that's becoming a really useful chunk of research as it grows in size. I've thought about doing something similar on the 91st Indiana Inf, the 36th Iowa Inf, the 1st Kentucky Cav (CSA), and/or the 29th Texas Cav, all of which include people from my own family, . . . but I probably have too many irons already in the fire right now. (I tend to get too ambitious with things and over-extend myself.) You know, a project like this -- researching all the members of a specific CW company or regiment -- would also make an interesting methodological seminar lecture -- but you've probably already thought of that! --Mike 10:14, 31 December 2009 (EST)
Thanks for the kind words, both of you! Bob -- thanks for adding the US Civil War category. I had forgotten (if I ever knew <g>) it existed. Anyone thinking about doing a similar project wouldn't have to tackle an entire regiment. They could do a company or two. The only reason I decided to work on the entire 1st OHA is because I've been collecting data on them for so long. If I was starting from scratch, I would probably start with my ancestor's company (D). Mike -- funny you should bring up the idea for a lecture. I'm doing a lecture at the Ohio Genealogical Society's conference in April about the research I did for my senior honors thesis, which was a case study of African American Civil War veterans living in Springfield, Ohio. I don't know if I could do something similar with my 1st OHA work (yet), as so much of the material has been gathered rather happenstance over the years. -- Amy 10:30, 31 December 2009 (EST)
Well, yeah -- I wasn't thinking so much about a whole regiment as about the individual company. Especially in rural areas, as you know, a particular company was generally recruited all in one county or neighborhood, so I'm likely to already know something about many of the members of a company from previous family research. --Mike 14:57, 31 December 2009 (EST)
I too would probably begin with the unit my gr-gr-grandfather served in because most of them were from Berks County, Pennsylvania, whereas the other companies of the regiment were from neighboring counties. Anyone else have ancestral ties to the 88th Pennsylvania Volunteers? Sounds like a good project for 2010. Interesting thought. --BobC 22:39, 31 December 2009 (EST)

Numbering children on family page [14 January 2010]

I'd like to suggest a minor improvement to the display of a family page. Can we get the children numbered? I know it takes up a bit of space, but when there are 12 children in the family and you're trying to compare a WeRelate list it to your own list of children, it makes it a bit quicker to spot discrepancies - at least I have found it useful on other websites.

Obviously, this needs to be a dynamically-numbered list, so that if a new child is inserted, the numbers are updated accordingly.

Not high priority, but please put this on your wish list. Thanks.--DataAnalyst 23:13, 1 January 2010 (EST)

That's an excellent idea. I've got quite a few of those farm families, too. It may not be so much a problem, though, when the pages get redesigned. If it's a family-group-sheet kind of thing, dynamic numbering would be easy. --Mike 23:19, 1 January 2010 (EST)
My 2 cents worth - I'd much rather see the WR ID# beside the children's names! And entering a new child should be no problem if and when the sort order becomes first by birth date, and second by order entered if there is no birth date. Or have some way of manually ordering the children. The lack of WR ID numbers on the family page is a continuing frustration for me. --Janiejac 23:36, 1 January 2010 (EST)

WR ID? When you mouse over a child, doesn't the link for that child page show up in the status bar at the bottom of the window? The link of course, contains what I assume you mean by WR ID#, i.e., 3 in http://www.werelate.org/wiki/Person:John_Doe_(3). Or are you referring to something different? --Jrich 23:49, 1 January 2010 (EST)

Hmmm. I have never noticed that 'status bar' before. And it does have a number in it; but without your telling me I would never have known that

http://www.werelate.org/wiki/Person:Jeremiah_Jackson_%283%29 was Jeremiah Jackson (3). Maybe knowing now how to translate that %283%29 into (3) will help eliminate some frustration, but how hard would it be to just put (3) beside his name? Apparently the WeRelate assigned number is always the number after 28??? --Janiejac 02:29, 2 January 2010 (EST)

%28 is how a left parenthesis is encoded for a URL. Similarly, %29 is a right parenthesis. So %283%29 would translate as (3). If you're curious, you can read more about URL encoding here. -- Amy 07:27, 2 January 2010 (EST)
Thanks for the explanation. That helps. But werelate cannot expect the average uploader to know this. It would be helpful to me to see the assigned number by the name. But wouldn't seeing both the werelate assigned number AND a sequential number be confusing? Perhaps not, because the sequential numbers would be easy to understand. --Janiejac 11:04, 2 January 2010 (EST)
With mouseover, I get floater as well as the usual link reference on the status bar. (I see that with both Firefox and Chrome.) Both of them say "Jeremiah Jackson (3)" -- so I can't imagine why you wouldn't see the parenthesis as a parenthesis. What in the world browser are you using, Janie? --Mike 16:53, 3 January 2010 (EST)
It's not necessary to imply that she's not reporting just what she's seeing, Mike. It works the way she describes in Safari, which is at least as mainstream as Firefox and Chrome.--Amelia 20:50, 3 January 2010 (EST)
I wasn't suggesting that the average WR user would necessarily know that. I was just explaining what it is. I think a lot of this will be covered when the pages are redesigned. --Amy 11:20, 2 January 2010 (EST)
And I appreciate the discussion and explanation. I wouldn't have known and it will be helpful to know those WR numbers. I checked using AOL (paid version), IE and Firefox. Both AOL and IE show the %283%29 while Firefox shows (3). --Janiejac 23:39, 3 January 2010 (EST)

Adding the WR number is a good idea, but I had more in mind adding a sequential number before each child's name. If the family page is being redesigned, please consider this. My reasoning: If I am looking at a family to determine if a) there is more info there than I have in my own database or b) there is invalid info in WeRelate that I might want to clean up, a quick count of the number of children tells me whether it is worth looking more closely. The human brain can easily do this for about 5 entries, but when there are 7 or more, it is very helpful to see the total number of children. Numbering each child is a common way to do that. Then if both WeRelate and my database have 12 children and numbers 4 and 8 are the same, I might not take a closer look. But if WeRelate has 13 children and I have 12, I start looking for a duplicate or misplaced child in WeRelate, or maybe I am missing a child. Having a number beside each child makes it easier to keep track of where I am when I go through the list.

And yes, I suspect it is mostly farm families that are this large, but I find a lot of them in early New England, if one is bothering to list all the siblings of one's own ancestors. Both my husband's and my families trace back there.--DataAnalyst 10:42, 2 January 2010 (EST)

Well, yes, I have improbable numbers of kids in New England colonial families as well -- but they're nearly all farmers. :-) My personal annoyance is that I lose track of the number of kids in the list because I generally have to scroll down a couple of times to view them all. --Mike 16:53, 3 January 2010 (EST)

I would find two sets of numbers confusing. Real estate on the screen is one of the more limited resources and I think its use needs to justified by some functional need.

Dallan is talking about allowing the normal sorting of children by birthdate to be overridden. If this is done with a sequence number, obviously sequence number would be necessary. On the other hand, perhaps he might chose move up/move down type of list to accomplish this. In the latter case, data entry and display of a sequence number may not be necessary, since it can be easily determined by counting. Making a sequence number a data entry field may involve some data management headaches, such as edits by two different people resulting in the same sequence number being assigned to the two different children, etc.

[Second thought re data management headaches: not to mention people misusing (unwittingly or not) the ordering for other purposes, such as moving their ancestor to the top of the list? For this reason, I wonder if it is better to just require people to enter estimated birth dates if they think the order is important. A child every two years following marriage, adjusted for what is actually known, seems to be a pretty standard approach. A will may identify somebody as the second son, but that may not be enough to provide a sequence number since you may not know the relative order with respect to the daughters, but if the first and third son's births are known, you can enter BET. X AND Y.]

Display of the sequence number that is used to distinguish people with the same names (the WeRelate ID) does not really seem necessary. Besides the fact that it can be easily determined in the status bar as discussed, it is rarely needed directly. The list of children are links to their pages and can simply be clicked on (opened either in a separate tab, or in the same window and use the back arrow). In fact, knowing this particular number is of limited use unless you are profficient at entering URLs directly into your browser's navigation bar. --Jrich 11:58, 2 January 2010 (EST)

I second JRich that WR ID is not a widely needed feature (I for one much prefer seeing full names; if you need all the numbers, click edit or use the status bar, which I do think that most people advanced enough to try a wiki and care about WR IDs will understand). I don't really care about ordering numbers either, but I can see the usefulness and I agree that having both types of numbers would be quite cluttered.--Amelia 18:48, 2 January 2010 (EST)

It sounds like allowing people to manually correct the automated sorting by birthdate and displaying a sequence number next to each child is the general consensus. I'll put displaying a sequence number on my todo list. (Manually correcting the sort order is already there.) If anyone wants something other than that, please say so.--Dallan 21:01, 14 January 2010 (EST)

The Generations Project - new program on BYU sponsosred by Roots Magic [7 January 2010]

The series will premiere on Monday, January 4, 2007 at 6:00pm MST on BYU Television with repeats shown throughout the week. New episodes will air every Monday. BYU Television is available on Dish Network channel 9403, DirecTV channel 374, many local cable systems, or online.--Beth 21:40, 4 January 2010 (EST)

Tried to find where I can stream this. Does not appear to be available via on-demand streaming. See [5]. If anyone else finds how to watch this, please post here. Thanks. Jillaine 17:44, 5 January 2010 (EST)

The PBS family history and genealogy television series from 2000, "Ancestors" is also broadcasting this week on BYU TV. I'm DVRing the entire series so I can watch it at my leisure. --BobC 23:00, 6 January 2010 (EST)

Also from BYU, for those interested in Independent Study, BYU now offers free courses (non-credit) in different areas of study. These areas include Family History, Family Life, and Religious Scriptures. Refer to the BYU Independent Study site for more information.--BobC 22:00, 7 January 2010 (EST)

Suggestion for the future = "pre-populate" WeRelate [14 January 2010]

This my get right up the noses of those who hate "Name Collectors" but here goes.

asuming the general aim of weRelate is the Pando thing - oneworldtree by another name - but with genuine quality of information to Wikipedia standards.

In short become the ultimate authority on family History relationships

Is having people submit their own family trees then (hopefully) having some mentor process or volunteer heirarchy which cleans up and enforces standards the most efficient way to achieve that ? The danger is the 'clean-up process' might involve so much work its impossible.

One thought would be to build an interface whicch allows volunteers to pre-populate based on resolving vital records.

Much in the way you can build trees very quickly in ancestry public member trees - with basic sourcing etc etc - obviously the checks an balances need to be there that aren't in such as ancestry at this point in time - each entry to be checked at least once by other volunteers - much the way it is done in transcription projects now.

There would oneed to be lots of detailed policy etc etc. For example ambiguities and bad trancriptions, information would need to be addressed.

But I'm still speaking hypothetically. The work would be methodical and targetted. the 'random' approach would take much longer to reach the "pando" ideal and would have many more errors. (I stress my argument only holds up if "Pando" is the ultimate goal)

I realise I'm talking about a huge amount of work. But wikipedia is a huge amount too, it was accomplished. There are millions of people now working on family history in a basically random faxhion. It just needs the leadership--Dsrodgers34 21:37, 5 January 2010 (EST)

I should add the result would only be a framework. People subsequently coming to weRelate would add more detailed information, or older information etc - its just that the framework would be much more robust--Dsrodgers34 21:41, 5 January 2010 (EST)

Two questions: (a) I wasn't aware that editors were restricted to only upload their own family trees - are you sure? (b) I don't understand what you mean by "resolving vital records" - coudl you give an example? AndrewRT 16:33, 6 January 2010 (EST)

No, people are not restricted to what they can enter there are already already have projects where they comprhehensively cover an location and / or a place in time. I'm suggesting that a more structured approach would get to the 'end game' more quickly than random approaches.

Resolving vital records is family or place reconstitution. Something like my little 'project' in which I have accounted for every census entry for a parish between 1841 and 1911. As time goes on I hope to:

  1. resolve every record, photo, event or fact I find to a person record in my databese
  2. gradually increase the parishes covered starting with the two adjacent ones and so on.

Its illustrates what I am discussing but obviously the approach would be much more structured and with many people involved (if they could be motivated - but there are benefits for people who are not 'name gatherers" too.

Werelate has already got structure which has been systematically included (sources and places) - A fremework supplied by resolved census recoreds (for example) is just a smilar step (although avery big one)

Project HolmeVillageHome and technique discussion Article:HolmeVillageHome How a reconstitution was done--Dsrodgers34 17:24, 6 January 2010 (EST)

Constructing family trees by linking people found in a comprehensive set of records for a particular geographic area is a really interesting idea. Norway is considering doing this for their entire country. I hope the project gets funded!

I've been thinking lately about a middle-ground approach. This is a long-term idea: What if

  1. when someone uploaded their gedcom it first went into a "private" area,
  2. WeRelate presented possibly-matching records and made it easy for you to attach them to your people, like Ancestry does with their "shaky leaves" but for records that are available on free websites,
  3. WeRelate required that you review the possibly-matching records and attach them as sources before moving your gedcom to the "public" area.

Under this approach at least we'd get more pages with sources being added.

This doesn't include the "check by volunteers" idea that you mention. That's what happens before you publish an academic paper. I'm not sure how feasible it would be in the genealogical community though.--Dallan 21:34, 14 January 2010 (EST)

Shared research vs. Surname in place [17 January 2010]

We have 2 categories that appear to overlap: Category:Shared research pages and Category:Surname in place. The Shared research page says that "Surname in place articles are now referred to as Shared research pages." The help on each of these pages conflict... does anyone know what the most current decision is? I'm asking, because I am trying to make category pages for the automatically created red-links at the bottom of my person pages. Thanks!--Jennifer (JBS66) 12:10, 9 January 2010 (EST)

I don't know 'the most current decision,' but I do hope we keep the Category:Surname in place because I think that is most descriptive. 'Shared research pages' can be anywhere and everywhere, but nailing the info down to a certain place seems to me to be the most helpful. And if the folks migrate on to another place that can be noted. It does seem to me that Surname in place categories should be automatically generated and I thought they were; but I'm not sure now if that has been consistent. --Janiejac 18:07, 9 January 2010 (EST)

I'd also like to see the "Surname in Place" Category survive, it certainly helps "target" a family to a specific area for organization and makes it easy to find. Delijim--Delijim 08:57, 10 January 2010 (EST)

I've been experimenting a bit with some ideas to organize our Surname categories. I believe this is an underused feature here at WeRelate, but one that could be very useful. I began with a popular surname, Smith. This category automatically contains the pages that reference the Smith surname, (families, people, users, etc). I also created a few subcategories that appear at the top (Smith in Massachusetts Smith in Canada, etc).

To further organize these categories, I would like to propose a change. We currently link surname categories to Category:Surnames via pages such as Surname "A" and Surname "B". I believe this is unnecessary. We could eliminate these extra 26 category pages completely, and allow every surname to appear simply under the Surnames category (similar to Wikipedia). For ease of navigation, we could use a table of contents template.

I'm still thinking about Category:Surname in place... It doesn't seem to make sense to link our Surname in place pages to this category. As seen with Smith above, they could be linked to the relevant surname category only.--Jennifer (JBS66) 08:11, 11 January 2010 (EST)

If you look at the history, the Shared Research Pages category was a manually created category by Beth in Feb 2008. If the reason for creation is valid as intended (i.e. "Shared research pages contain information about people having a particular last or surname living in a particular place"), then Jennifer (JBS66) is correct in her observation above; the category seems totally redundant and unnecessary as it would serve the exact same purpose as the Surname in Place category which is a more user-friendly automated function. Additionally, the Shared Research Pages category contains only two linked pages, both of which also link to the Surname in Place category. The Surname in Place category has 54 connected subcategory links and 361 article links, making it far more useful and resourceful.
Rather than moving or redirecting the Surname in Place category links to Shared Research Pages category, I would be in favor of deleting the Shared Research Pages category altogether. It seems to serve no useful function and in my opinion is not a value added category to WR and causes confusion (as proved by Jennifer's initial inquiry). --BobC 09:22, 11 January 2010 (EST)

I generally like Jennifer's idea. I'm a visual person, so need to see this in outline form. Jennifer, if I understand you correctly, the hierarchy categories would be this:
  1. Surnames
    1. Surname (e.g., Smith)
      1. Surname in Place (e.g., Smith in California)

Only downside I see to this is that Jillaine Smith, born in California, would appear (if I were dead) in both the Surname in Place category as well as in the Surname Smith category. Ideally, the system would identify that I was born in California and place me only in Surname in California, and place in Category:Smith only those Smiths who have no birth place listed. Oh wait, am I confusing Surname:Smith with Category:Smith? I think the problem is still the same. I'd appear in both Surname:Smith and Category:Smith in California. How do we deal with that? -- Jillaine 09:44, 11 January 2010 (EST)

I don't see a problem with a name appearing in both the Surname in Place category and the Surname Category -- both serve a very useful purpose for different reasons. For example, if you look at one of my ancestral Surname in Place pages (Schonauer in Berks, Pennsylvania, United States), an auto link to the Surname in Place category was created upon initial entry. I then manually added a link to the Schonauer Surname category in the text block. That's how I dealt with it. --BobC 09:57, 11 January 2010 (EST)
 :I like Jennifer's idea of using that table of contents template!! That would make several categories much easier to navigate. As time goes on those pages that use just the letters of the alphabet will get terribly long and the need for table of contents template will be even greater. I am not programmer enough to know how much trouble it will be to make such a change but better now than a year from now. Anything that will make this site easier to use gets my vote!
If I clicked on 'Surname Smith' the next logical subcategory would be 'Smith in some State'. All the more reason to keep Surname in Place pages and not call them Shared Research pages.
There's a common v. rare surname issue here. I can see how it would be nice to "unclutter" the Smith category by putting the people with associated places in other categories, but if you have a really rare name like, I don't know, Gerlicher, it's nice to see at a glance if there are any such people entered on the site.--Amelia 12:55, 11 January 2010 (EST)

Here is the hierarchy I am thinking of (same as you detailed above Jillaine, just with links)

1 Category:Surnames
2 Category:Smith surname
3 Category:Smith in California

What tends to become confusing, I believe, is there are both Surname in place Categories and surname in place Articles. The categories are automatically generated, the articles are user created. I propose to no longer link Surname in place Category pages (like Category:Smith in California) to Category:Surname in place --Jennifer (JBS66) 10:23, 11 January 2010 (EST)

Not exactly true in all cases, Jennifer, because the Surname Research Links you create in your personal Profile Page creates Article Pages, which in turn automatically link to the Surname in Place categories (both the general category and to the individual surname category) as well as to the Surname Category itself. The category line on the article page looks like this sample Surname in Place page:
Image:Sample Category Link 2.GIF
So, as you see, it is important to know what is a bot function and what is a manual function. --BobC 11:36, 11 January 2010 (EST)

I will admit that I am confused on where to properly direct the surname Articles... I also wonder what will happen when we generate too many surname in place Categories. Say we have a few hundred Smith in place categories - will it become confusing? --Jennifer (JBS66) 10:23, 11 January 2010 (EST)

NOTE: I added the table of contents template to the Category:Surname in place to test it out.--Jennifer (JBS66) 10:36, 11 January 2010 (EST)
Is there a template showing just the 2 digit state designations that would be helpful?
Janie, the pages underneath this category are sorted by page title (in this case, surname). Clicking on a letter in the table of contents jumps you to the first occurrence of that first letter in the page's title.--Jennifer (JBS66) 10:57, 11 January 2010 (EST)
Jennifer, the template is mahvelus, simply mahvelus. Jillaine 11:19, 11 January 2010 (EST)

Well, I am going to be bold... I'll take the first organizing step and start eliminating the Category:Surnames "A"-Category:Surnames "Z". --Jennifer (JBS66) 13:45, 11 January 2010 (EST)

We have a third category named Category:Surname in Place. Capitalization requirements in the wiki are annoying. Who can remember what is capitalized and what is not? --Beth 21:53, 14 January 2010 (EST)

I found the origination and original definition of a Shared Research Page: Within the User Pages Help page the question is posed...

What is the difference between user pages and shared research pages?
  • User Pages are password protected, so that they can only be edited by the original creator
  • Shared Research Pages are community pages that can be edited by any registered WeRelate user

While it looks as if the decision has been made with regard to keeping the Surname in Place pages, I hope this helps refocus what so-called "Shared Research Pages" were meant to entail and encompass at WR. --BobC 14:50, 17 January 2010 (EST)

When use Category vs. Article [24 September 2010]

Above, Jennifer (re)raises the question of when do we use the Category:(Surname) in (Place) and when do we use an Article (Surname) in (Place).

I have preferred to edit the relevant Category page so it's all together. But in some cases, the narrative before the auto-generated list of pages becomes too long. Here are some examples of each:

Category:(Surname) in (Place) (Surname) in (Place) articles
Category:Schlenker_in_Schwenningen Brown in Missouri
Category:Fuller in Massachusetts Townsend in California
Category:Taylor in Massachusetts Taylor in Massachusetts
Category:Barber in Massachusetts Jackson in Queens, New York

I would limit categories to their intended purpose, to provide a visual structure for WeRelate's contents. I would put extended descriptive text, such as that on Category:Taylor in Massachusetts on it's own article page (Taylor in Massachusetts) (which does link back to the category).--Jennifer (JBS66) 11:36, 11 January 2010 (EST)

This part above is KEY to our (and others') understanding of the distinction between category pages and article pages, and because I don't think I've fully appreciated this before, I'm going to repeat it:
I would limit categories to their intended purpose, to provide a visual structure for WeRelate's contents.
Now I'm going to clean up the category pages I've messed up. Thanks Jennifer! Jillaine 12:44, 15 January 2010 (EST)
Jillaine, you didn't "mess up" anything. I suppose in theory I agree that Categories are just for "structure". But three problems here. First, you can't get a visual structure when there are hundreds of entries in a category. That's just a category that exists only for taxonomy structure purposes. Second, these surname in place categories link on EVERY PERSON PAGE. That makes them prime real estate and MUCH more likely to be seen than any articles on the subject. Third, the people as listed in category pages are incomprehensible since they lack dates. I therefore think it's really useful to do things like in the chart above (see also Category:Harrison in Virginia or Category:Arnold in Rhode Island). They aren't full surname in place articles, but I wouldn't have a problem with them being that way.--Amelia 13:55, 15 January 2010 (EST)
I would prefer to see WeRelate adopt a procedure similar to both Wikipedia and Familypedia. They use a template at the top of their category pages, directing users to the appropriate article on that subject. (ie Category:Canada and Smith (surname)). It saves a lot of confusion for users wondering where to put their information - categories or surname pages or an article, etc. --Jennifer (JBS66) 15:37, 15 January 2010 (EST)

While I generally haven't have a problem with enhancing the category page with additional manually added information, I agree with Jennifer (JBS66) that the additional information on the Taylor in Massachusetts category page would be better served on the Taylor in Massachusetts surname in place article page. This category page in particular, probably because the categorized links extend beyond 200 in number (i.e. multiple pages), demonstrates the "problems" that can appear when a lot of manual input is added to a category page with hundreds of linked pages. The manual input shows up at the top of every category page as the user scolls through the pages, and the linked pages, for which the category page is designed to highlight, are at the bottom of each page under the manually inputted material, which is duplicated with each page turn.

Category:(Surname) in (Place) (Surname) in (Place) articles
Category:Taylor in Massachusetts Taylor in Massachusetts

You're a good sport, Jillaine. If you'd like some help combining the manually-inputted information on the Taylor in Massachusetts category page with the Taylor in Massachusetts surname in place article page let me know. --BobC 18:05, 15 January 2010 (EST)

Just in case you have any need to know how confusing this is I offer the following:
Category:Surnames, click & go to SubCategory Surname:"J"

there is NO category for Jackson (surprise to me!) so to see where it would go if it were there, I clicked on Justice and it took me to the Justice Person & Family Pages which is fine.
So to see where the chain to Jackson was broken, I tried to work backwards from that ARTICLE I created 'Jackson in Queens, New York'. The automatic categories assigned were Category:Jackson surname, and Category:Queens, New York, United States and Category:Jackson in New York. (On the article pg the link is blue!)
A click on the Category:Jackson surname took me back to that category page with family and person pages AND ALSO had a link to another article page I created named 'Surname Jackson' which was meant to be like an overall research page with links to every Jackson in state article, also links to external Jackson web sites and (coming) a page for Jackson DNA. So I get very confused and probably manage to get others confused also.
So somehow Jackson surname should be listed under "J" and if anyone wants to suggest I do something different to distinguish between articles and categories, I'll listen! I had manually added Category:Surname in place to the 'Jackson in Queens, New York' article. When I clicked on 'Surname in place' I first thought my article wasn't listed because the first thing you see on that page is subcategories - and no, it wasn't there. But when I scrolled further down on the page, yes, it IS listed among the articles. If we're going to have subcategories at all, shouldn't all articles be listed in subcategories? (Give me A for effort but I get an F in wiki! That's all for now!) --Janiejac 14:14, 11 January 2010 (EST)
Janiejac, the issue here is that Category:Jackson surname didn't have a [[Category:Surnames]] assigned to it, so it didn't show up as a subcategory. I see that Jennifer just added [[Category:Surnames]] to the Category:Jackson surname page so it does show up now. I agree that having to add this category is annoying. Not many people would know to do this. (More about this below.)
Also, subcategories are listed before articles on a category page. It takes awhile to get used to, but I think it's a good idea to separate subcategories from articles in a category.--Dallan 00:07, 15 January 2010 (EST)

Dallan's Poll on Surname Questions [27 January 2010]

I really like where this is going! I have a few questions and ideas.

1. Should we remove Category:Shared research pages? It's not needed anymore, right?

Correct. I vote "yes" REMOVE. Jillaine 12:44, 15 January 2010 (EST)
I also vote YES to remove Category:Shared research pages--Jennifer (JBS66) 12:57, 15 January 2010 (EST)
For the reasons I stated above, YES. --BobC 13:05, 15 January 2010 (EST). I'll amend my original thought to: Yes, remove as a functioning category. I would like to see the term revert to it's original use as stated within the User Pages Help page from Feb 2008 identifying the difference between user pages and shared research pages, where is stated, "Shared Research Pages are community pages that can be edited by any registered WeRelate user," versus "User Pages are password protected, so that they can only be edited by the original creator." --BobC 09:56, 19 January 2010 (EST)
YES --Jrich 10:15, 17 January 2010 (EST)

2. Do we want to have Category:Surname in place? It seems like this category will start to become very large. Would linking the subcategories and articles just to the appropriate surname categories be sufficient?

It seems that the purpose of such a page would be to list all of the "Surname in place" pages? Would such a list be useful? Jillaine 12:44, 15 January 2010 (EST)
Yes, keep the Surname in Place category. Yes, it will become large. I would say to link both to place and name; that way those searching for the name would be able to discriminate by place, and those searching places would be able to see and easily link to names. --BobC 13:05, 15 January 2010 (EST)
YES and YES --Jrich 10:15, 17 January 2010 (EST)

3. To simplify things, I'm thinking that the user pages should link to the surname in place category pages, rather than a surname in place article, and that creating a surname in place article should be the exception rather than the rule, to be done only when there is too much material to comfortably fit on the category page. If we agree on this, I can ask one of my children to cut-and-paste the material from all but the long surname in place articles to the corresponding category pages and to update links to point to the category pages.

At first I agreed with this, until Jennifer posted this reminder about the purpose of Category pages: to provide a visual structure for WeRelate's contents. I'm with her on this unless someone makes a strong case otherwise. Jillaine 12:44, 15 January 2010 (EST)
I feel that we should not be placing extensive text on category pages. Categories are intended as a finding aid, not an article. At Wikipedia, they generally contain only a brief description of the category, along with the automatically generated contents. --Jennifer (JBS66) 12:57, 15 January 2010 (EST)
Not sure which is more effective or preferential. Creation of an article within the User Page also creates the Surname Page (see Beth's inquiry on the Surname Pages and Links topic below). Personally, I like having the multiple linking of categories to articles and surnames in place. Many people don't use that feature though. --BobC 13:05, 15 January 2010 (EST)
NO. "long" is arbitrary, uniformity is simplicity, same rules for everything. Either insist on separate article if any text to be added, or text is always added to category. --Jrich 10:15, 17 January 2010 (EST)
We rely on judgment a lot here, so I'm fine with keeping only "long" "articles." The worst solution would be to insist on articles -- if they aren't linked to the right category page, they would never be found, and how are you going to stop people from editing categories anyway? Having the category links on person pages change to blue when there's content is a great way to clue people in that some possibly interesting content has been added.--Amelia 19:15, 17 January 2010 (EST)
To answer the question, "how are you going to stop people from editing categories" - well, you do that by maintaining the namespace. Just as volunteers monitor recent changes in place pages, image pages, etc... we should be monitoring the categories space for use that does not fit in with its function.
Your comment about links changing to blue when there is content is confusing to me. The links should be blue in a properly maintained wiki, and it is not because they contain content. Referring to a wikipedia article, describing the intent of categories:
  • Categories are a tool for browsing: they function as a table of contents, leading users to the articles on a specific subject.
  • Categories are a means of classifying articles
  • Categories are an index of a subject
  • Categories are a database search
  • Categories are an index of other categories
The TOC, when used properly, helps us to relax any concerns about category pages becoming too long. "In mid 2005 the category table of contents template, {{CategoryTOC}}, was created. With the table of contents it became possible to navigate through very large categories with a few clicks...there is no longer any reason that categories need to be small." Now, with WeRelate's use of the namespace in listing category pages, it makes the TOC nearly useless. This will essentially direct users either to F for Family or P for Person.--Jennifer (JBS66) 08:34, 19 January 2010 (EST)
I think Jennifer has discovered the root of the problem. If we think of a category as the title of the chapter of our book, maybe we wouldn't try to include the whole chapter as part of the title. If we stick to that it should eliminate a lot of the confusion. I'm visual - I'd like to see this laid out somewhere in outline form.
The book has a title, the TOC has names of chapters (categories) which includes 'index'. But the content of the chapter is not included in the TOC. The chapter or section called 'index' would be the Surnames. Surname category pages could talk about the origin of the surname and have links to Places (countries, areas, states). I don't know if we would need a further breakdown or if further info would be the articles themselves. That would probably depend on the intent of the author. Am I missing something? --Janiejac 09:27, 19 January 2010 (EST)
Janiejac, I really like your analogy to books! The example is valid - just as you would not consider listing a book's contents within the index or table of contents, you would not place article contents on category pages. You can list them (by placing a link to the category) to your heart's content... For those of us who are more visual, I have placed a rough outline of WR's current category structure at Categories_project.--Jennifer (JBS66) 10:02, 19 January 2010 (EST)
Thank you for posting that outline! Clicking on some of those links emphasizes the need for some reorganization or cleanup. There is a category:Family Pages that has only 3 articles in it! The is a category:Products that has only 2 subcategories in it: (1) is 'Books' which has a SOURCE in it and (2)is 'Software' which has one article. Oh, there's more, so lets move over to Categories_project to see what should be or can be done. --Janiejac 11:10, 19 January 2010 (EST)
I think we're emphasizing some organizational ideal over actual usability. Wikipedia, frankly, is not the ideal here. They have excessive numbers of categories that do not provide a useful browsing experience. So do we. Right now, we have a system in which 1) red category links means a category with just articles in it; and 2) blue category links means a category that humans have maintained and therefore might have some useful content worth clicking on. I would like to keep that distinction, although I know I'm going to lose. The reason is that I would like to encourage people to CLICK on categories and get something USEFUL out of it. I've done the following things to make these a useful experience, and all would apparently be jettisoned with no good replacement for no good reason under the 'all or nothing' theory.
  1. Putting information on famous or early ancestors in a place (say, Arnold in Rhode Island). I understand that this can be done through articles, but that's an unnecessary step that just hides the content.
  2. Adding Wikipedia templates for content so that other WP templates link to the category instead of WP (like this one. Doing this on an article page would completely defeat the purpose. It has to be a category to provide any usefulness over just going straight off to WP.
  3. Adding information about what the category is for. Like Category:Notable people. This can't be done any other way, and is an approach used by WP.
  4. Adding information about the people in the group in a more useful way than the 'alphabetized by Person' list that's generated automatically (the reason that the Great Migration ships add the template).
Even if I didn't think that it materially degraded the user experience to ban content on categories, I don't think it's a good use of our time to remove this useful content and prevent other people from doing it, and I'm going to be more than a little upset if my efforts are just deleted without more input than just the 2-3 people speaking in this discussion.--Amelia 10:28, 27 January 2010 (EST)
Amelia, I don't mean to speak for Janiejac, Jennifer or anyone else who has piped in on this topic, so I hope they correct me if I'm wrong. From what I've read, I don't think anyone is suggesting that you cannot put an explanation or definition of the category at the top of the category page, such as at the top of Category:U.S. Secretaries of State and Category:Notable people. What doesn't belong on the category page is a lengthy discourse on the category topic. Let's say there's a category for Mayflower passengers. The category page should define what the category includes and excludes, but shouldn't have a treatise on why they sailed, the hardships they endured, etc. That type of material would be better suited to be in a separate article, though you could link to that article from the Mayflower passenger category page. --Amy 10:50, 27 January 2010 (EST)
I did agree with you, which is why I didn't get excited the first time and agreed with a compromise version of Dallan's proposal -- short information at the top is fine, but long articles should go somewhere else. But then this discussion was described here as a proposal to ban manual editing of categories.--Amelia 11:07, 27 January 2010 (EST)
I took that discussion to be referring to the "(surname) in (place)" categories/articles, not to all categories. It appears we need some clarification as to the scope of that proposal. --Amy 11:47, 27 January 2010 (EST)
It is my understanding and belief that, just as Amy stated, a concise definition of the category's contents is appropriate. What I believe we are trying to prevent is anything that resembles an article, such as Category:Taylor surname. While this is great information, it does belong on a separate page. Dallan had another observation regarding extensive text on category pages at the project talk page. He said: "I was on the other side of the fence before (put the content directly on the category page), but after being reminded that it shows up every time you page forward or backward in a category (e.g., Category:Taylor surname), I agree it's better to put it on a separate surname-in-place Article, with an obvious link to the article at the top of the surname-in-place category page." --Jennifer (JBS66) 15:33, 27 January 2010 (EST)
To reference Wikipedia's description of What goes on a category page?: "Category pages exist to be a convenient cross-reference to related articles and other categories. A category page should contain a brief description of the purpose of the category. A prominent link to the most important article in the category is usually a good idea, but please avoid copying large quantities of text or images from an article to a category page." --Jennifer (JBS66) 16:42, 27 January 2010 (EST)

4. Most surname in place category pages have never been created, even though they contain links to pages. The Category:Smith in Minnesota page doesn't exist for example, so it doesn't show up as a subcategory in Category:Smith surname. Should I write a program to automatically create surname and surname in place category pages when they contain a link to a page, and to automatically assign the category pages to the appropriate "parent" categories (to address Janiejac's issue above)?

This would create quite a few more category pages. At one time I worried (and I still do) that doing something like this would have so many automatically-generated category pages that they would drown out the human-created category pages, which are likely to be much more interesting. But not having the links (e.g., a link to Category:Smith in Minnesota from the Category:Smith surname page) makes it seem like we don't have any Smith's in Minnesota, so this doesn't seem right.

I like it as it presently is, but I may be in the minority in trying to make every red link blue. But you may be right in dealing with a volume of unutilized article and category pages created automatically that overwhelms the manually created pages and categories. --BobC 13:12, 15 January 2010 (EST)
YES. If there is a page linked to it, the category page should be there to list that person as a member of the catgeory. Don't create empty pages, but yes on the ones with members. --Jrich 10:15, 17 January 2010 (EST)
Frankly, I'd prefer we didn't start turning category links blue when they have no content, but I've lost that battle with the "A Surnames" stuff. So go for it.--Amelia 19:15, 17 January 2010 (EST)
I vote NO. Leave the red links until the pages are manually edited by a user.--Beth 18:18, 27 January 2010 (EST)

5. What do we want to do about the "place" categories (see Category:Virginia, United States for example)? Do we want them at all? If we keep them I assume we'll want to automatically-generate category pages for place categories as well.

Keep the place categories - absolutely! However, our place categories are currently taking 2 different forms (ie Massachusetts, and Massachusetts, United States see Category:United_States). We need to stick with one, perhaps we should look to follow Wikipedia's lead on this?--Jennifer (JBS66) 12:57, 15 January 2010 (EST)
I think the Virginia page you cited above is a perfect example of why we should keep that category type (e.g. multiple subcategories -- most of them counties -- and almost three dozen articles and one image). I don't see any problem having county placename categories as subcategories to state category pages. It provides multi-level avenues for research and categorizes pages in a logical heirarchy. --BobC 13:12, 15 January 2010 (EST)
YES. Seemed redundant at first, but What Links Here on a Place page is too unfocused. Need some way to say that these pages are important to Virginia, though why Whyte Robert Rumgay's picture is in Category:Virginia or some of the other things are there is beyond me. The stuff that is there should be of use to almost everybody interested in Virginia, not because the linked item is simply in Virginia. Also, Virginia and Virginia, United States are the same thing, the one named plain Virginia should not exist. The names of these should follow the place hierarchies and Virginia, United States should be a subcategory of United States. People placing things in categories should use the smallest one possible (though this may cause problems regarding historical vs WeRelate place names - people may want categories that represent a place in a subset of time?) This needs some organization and some rules to avoid getting out of hand. --Jrich 10:15, 17 January 2010 (EST)
Yes, but as noted above, these should be human-edited to have content of interest to people interested in Virginia. Auto-generating anything is unlikely to go well.--Amelia 19:15, 17 January 2010 (EST)

5a. Do we want to make the "surname in place" categories subcategories of the corresponding "place" categories as well as subcategories of the surname categories?

Oooh. Nice idea. (That's a yes from me.) Jillaine 12:44, 15 January 2010 (EST)
Definitely yes. Will volume be a problem? --BobC 13:12, 15 January 2010 (EST)
YES if possible. Would suggest adding subcategory to the Place called Surnames, and linking surnames in place to that subcategory, not directly the main place category. --Jrich 10:15, 17 January 2010 (EST)
Yes. I like Jrich's suggestion, because volume will be a problem.--Amelia 19:15, 17 January 2010 (EST)

5b. Do we want to add Source, Person, and Family pages to "place" categories?

Please provide an example; having difficulty visualizing this. Jillaine 12:44, 15 January 2010 (EST)
I'm not sure what you mean. Aren't there other routes to make the connection and search for information between those pages? Or are you talking about categorizing family and person statistical events (such as birth, marriage, death) to places? In that case I might see a value. In Wikipedia, a person's birth or death date can be categorized under "1920 births," "2003 deaths," or "People from Seattle, Washington." --BobC 13:12, 15 January 2010 (EST)
NO. That can be done using What Links Here on a Place page. Place categories ought to be used because there is something that is pertinent to/symbolic of/important to that place, not because it is simply there. Somebody would go to a Virginia category to find important pages to view if one is interested in Virginia, like, I don't know, prominent people in history, emigrant families, important books, articles on Virgina history. A list of the millions of people who have ever lived in Virginia would not be useful unless each such category gets automatically created with a subcategory structure to make it easier to manage. --Jrich 10:15, 17 January 2010 (EST)
Only if you can limit it to towns and counties. It would be a mess for states and countries. And it seems if we add the surname in place categories as subcats of place categories that takes care of it. Don't do both.--Amelia 19:15, 17 January 2010 (EST)

6. I'm thinking I'll need to re-work how page links are listed in category pages. It seems like someday we'll want to be able to filter by namespace so that you can display just the Person pages for example. I'm wondering if we also want to display separate alphabetical links for each namespace, so that Person pages get filed under headings like "Person A" and "Person B", or maybe subheadings "A" and "B" under a larger "Person" heading, rather than the current approach of putting all people under "P".

Yes on filtering by namespace. And I think yes on the second part. Jillaine 12:44, 15 January 2010 (EST)
Yes, that filter or additional automated feature could help narrow searches done via category pages for users. That also raises the issue of how more expert users input and edit the category manually to force it into the right place on the category screen by adding the desired alpha character(s) after the category name. But by doing it manually though, some categorized links are alphabetized by user-provided information and most others are automated by page type and then by alpha/numeric designation. I appreciate the flexibility, but it may cause confusion to some. --BobC 23:40, 15 January 2010 (EST)
YES and YES --Jrich 10:15, 17 January 2010 (EST)
YES please. I notice {{Defaultsort}} isn't supported here, but perhaps autopopulating that could accomplish this? And have it be human-editable for special circumstances? Like right now the U.S. Presidents are in date order...--Amelia 19:15, 17 January 2010 (EST)

6a. Do we want to list the person's full name (and maybe birth & death year) instead of their page title in category listings?

Hallelujah! Hallelujah! h...h... hallay looo yuh! (I've wanted page titles to do this for a long time; since we can't have that, it would be MAHvelous to have it this way on the category pages. Jillaine 12:44, 15 January 2010 (EST)
For Person Pages, yes. Not sure about Family Pages. --BobC 13:12, 15 January 2010 (EST)
YES and possibly in more contexts than just Category lists (instead of displaying page title)? --Jrich 10:15, 17 January 2010 (EST)
Yes this would be much more useful --Judy (jlanoux) 11:55, 17 January 2010 (EST)
To quote Jillaine, Hallelujah!--Amelia 19:15, 17 January 2010 (EST)

6b. Do we want to sort person/family pages by surname, then by givenname, then by birth year, then by death year in category listings?

Sure. Will this slow display down too much though? Jillaine 12:44, 15 January 2010 (EST)
On family pages, will that mean there be a separate category sort for both husband and wife? --BobC 13:12, 15 January 2010 (EST)
YES. --Jrich 10:15, 17 January 2010 (EST)
Yes --Judy (jlanoux) 11:55, 17 January 2010 (EST)
Yes. Are you going to have birth and death years for family pages? It seems like marriage date would make more sense.--Amelia 19:15, 17 January 2010 (EST)

--Dallan 00:07, 15 January 2010 (EST)

I'm overwhelmed! Too many suggestions for change at once :-) Can we take this project in smaller steps? Perhaps we could begin with creating a Categories project page. It would allow a centralized place for dicussion, and users could sign up to help create/maintain the category structure. We could then rename just the surname category pages automatically and assign those to the parent Surnames category.

On another note, it appears that image pages that contain surnames with spaces are categorized differently than person/family pages. One example is Image:1753-10-14 Trouw Egidius van Euwick x Elisabetha van Hedel.jpg. The surnames on the image are categorized under both van Hedel and simply Hedel.--Jennifer (JBS66) 12:59, 15 January 2010 (EST)

I agree with Jennifer - when I'm already confused on this subject, all this detail is very overwhelming. I also like very much her comment: "I feel that we should not be placing extensive text on category pages. Categories are intended as a finding aid, not an article." I find articles in categories, even in subcategories. So can we break it down into smaller bites and come up with short definitions of each type of page and whether the pages are automatically generated or user generated? --Janiejac 13:13, 15 January 2010 (EST)
Ok, I created a WeRelate:Categories project page. I just need a bit of help here... how much of this conversation do we move over?--Jennifer (JBS66) 13:44, 15 January 2010 (EST)

I've been thinking about a couple of points regarding this categorization discussion.

  1. Janiejac has brought up a nice point on the Categories project page. Along these same lines, I noticed a number of new surname-in-place category pages that were created last night. These pages link only to the surname in place category and to neither the surname or place they are representing. I suggest that we develop a standard template for our surname-in-place categories, link them to the appropriate surname page, and possibly eliminate the Category:Surname in place altogether.
  2. I have concerns about Dallan automatically creating our surname and surname-in-place category pages. Yes, it would be nice to have this repetitive task handled automatically. However, I think the WR community would benefit from undertaking this project ourselves. It would help us to strengthen our sense of community and develop a stronger knowledge of the workings of this site. Instead of automatically creating incorrect pages like Category:? surname of Category:Moore in NY, we would learn to be cleaning up our messes and properly maintaining the site. There is a daily generated list of wanted categories. Going through this should be a part of regular site maintenance.
  3. In a previous discussion on multi-part surnames, Dallan suggested putting 'dit' names (alternate names common in Quebec) in the surname field. This translates into possible category pages such as Category:Destroismaisons Dit Picard surname. I suggest creating another option in the alternate name pull-down for dit names instead. Then each name would go on a separate line, and two independent categories would be linked.
  4. I am wondering about our automatically generated categories. These are hidden on our pages, and I wonder if that takes away from people learning how categories work. One idea might be to still automatically generate the category, but place the actual [[Category:title]] text within the text box.
  5. In addition to surname-in-place and shared research categories, we also have a Category:Family Exchange and Help:Family Exchange Pages. This seems like another case of overlap that needs to be sorted out.--Jennifer (JBS66) 08:43, 17 January 2010 (EST)

Surname pages and links to person and family pages [17 January 2010]

Are person and family pages supposed to be linked to the applicable surname page? If so person and family pages are not presently linked properly. I checked the Coker surname page and only one person page is linked. I checked the Gay surname page and no person pages are linked. --Beth 21:43, 14 January 2010 (EST)

I see quite a few Coker's listed.--Dallan 00:12, 15 January 2010 (EST)
Yes, under category surname they are listed. Are the person and family pages linked to the category surname page and not to the surname page?--Beth 11:32, 15 January 2010 (EST)
Beth, this is too easy. Please check your User Page. If you notice in the names you are researching on the far left side, all of the names were input by you as surnames you were/are researching. All of the Coker names/links were red because you hadn't linked to the articles they automatically created when you entered the surnname data; the McGuire and McCullough names are in blue because the articles they automatically created you must have changed in some way at some time. To illustrate this, I clicked on the three Coker surnames in Texas, Oklahoma and California. When each article opened all I had to do was edit and save, and this action automatically linked those article pages to your Coker surname page (as can be seen on page 2). I'll let you do the rest of the Coker Surname in Place pages. After you do so I think you'll agree: it's too easy. Right? --BobC 21:02, 15 January 2010 (EST)

Beth is raising a related issue for me. I think we've discussed it elsewhere, but I no longer recall. WHY do we even *have* Surname article pages? They are not linked to from person pages-- those go to the relevant surname *category* page; the bulk of them only list alternative spellings; and they are only linked to from articles when one fills out the Surname field in an article. Wouldn't it be better to have all those alternate spellings as narrative in the upper part of the Category page for said surname and get rid of Surname pages altogether? Jillaine 12:52, 15 January 2010 (EST)

I think we need to look at the purpose of both page types: the Surname Page identifies related (or unrelated) surnames (each having their own surname page and category page) under different spellings. They can be used as an article page (or as a research guide for that name) letting users and contributors add information about that surname; and as indicated by the Surname Portal it can be utilized as a one-name study regardless of known or proven family or ancestral connection. The associated category page is intended as a finding aid within the WeRelate community; while it too can be manually enhanced to include user-contributed data, it's purpose is primarily to group pages of similar content at WeRelate. I see good uses for both and good reasons for keeping both. --BobC 13:59, 15 January 2010 (EST)
The alternate spellings on the pages within the Surname and Givenname namespaces (such as Surname:Smith or Givenname:Jennifer) work along with the search function to return close matches. There are more details at Help:Name pages--Jennifer (JBS66) 14:12, 15 January 2010 (EST)

Bob, your explanation is clear and I do understand the difference in the surname pages and surname category pages. However; I am concerned about the complexity of this site. As I recall, one of the reasons we decided to eliminate the surname in place pages were because the red links that were automatically generated on the user profile page were confusing to users. Users do not know what they are for and do not understand the difference between the surname page and the surname in place pages and/or categories. How many users actually check the categories? What about the categories that the user has to manually enter on the related page to have the page even show up in the list of categories. Somehow we need to simplify this process. I am sure that some users simply give up from exhaustion. I am not recommending that we eliminate the surname in place pages but somehow we need to make it easier for users to differentiate between surname and surname in place pages and the corresponding categories. I believe that most new users would intuitively look for links to people on the surname page and not on the category page . --Beth 19:33, 15 January 2010 (EST)

Hi again, Beth. I'm sure based on your experience level you do understand the difference. I was actually addressing the issue that Jillaine raised in her comment above, and secondarily to other people who may not understand the primary purpose of both page types. Since I only joined WeRelate last year I may not have read the discussion you are referring to about replacing the Surname in Place pages, but I believe the discussion about the subject above clearly indicates concensus otherwise at this point in time. I respectfully disagree with your viewpoint that we need to "dumb down" WeRelate; I think instead we need to educate. --BobC 21:15, 15 January 2010 (EST)
Bob, just in case you overlooked this in my last entry, I stated that I was not recommending the elimination of surname in place pages. I also do not consider simplification to be synonymous with "dumb down". That would depend on the method of simplification implemented. --Beth 09:03, 16 January 2010 (EST)
Actually I didn't overlook it, I disregarded it because it contradicted your previous observation, and I quote, "One of the reasons we decided to eliminate the surname in place pages were because the red links that were automatically generated on the user profile page were confusing to users." You also wrote on the Category talk:Surname in place, "This page needs to be renamed. --Beth 14:50, 22 February 2008 (EST)." I just wanted to correct the record. Hopefully Dallan's response to this question has put this issue to rest and we can now proceed with (or revert back to) the more popular and conceptually accurate Surname in Place usage. Thanks for bringing this issue up for discussion. --BobC 11:34, 16 January 2010 (EST)
By all means proceed with the more popular surname in place usage. Obviously my message was unclear to you, sorry sometimes I have problems selecting the correct words to clarify my meaning. In Feb 2008, I had been an active user of WeRelate for approximately 3 or 4 months, and I did recommend renaming the surname in place pages. That is precisely why I stated in this discussion that I was not recommending the elimination of the surname in places. I changed my mind after reading the support that all of you exhibited for the pages to remain. Trying to to make the record clear.--Beth 09:39, 17 January 2010 (EST)
Bob, if we can't make it simpler to use, folks aren't going to hang around long enough to get educated! If folks stay long enough and struggle through enough to get educated, that is a plus, but it is not the purpose of this site. WeRelate needs eyes on the site for the ad income; if it is easy enough to use, folks will stay and maybe learn from more experienced folks along the way. Someone told me one time, you fish with what the fish like, not with what you like. Our potential users don't want to struggle with complexity. How many have already dropped out??
But it will surely help if we can come up with a clearer definition of pages and then put that in the TOC of help. I like Jennifer's definition of categories as finding aids. My understanding of articles is that they are for discussions, historical or genealogical. But after being here a year, I'm just now figuring this out. I still am unsure when categories are automatically assigned and when they are user generated. --Janiejac 10:09, 16 January 2010 (EST)
Like any program or application, WeRelate has a learning curve. I don't believe it is WeRelate itself that is so difficult to use for most people, it is the wiki framework. When you and I joined WeRelate we didn't know everything about it in a week, we learned the ropes, through Watercooler discussions, through perusing old archived posts, through adding our own GEDCOM data, through editing our FTE file, through becoming involved in Portal additions, and through contributing project work of various sorts. I'm still learning new things and capabilities of WeRelate. The free form of WeRelate is what draws me here. If I wanted the predefined structure of an inflexible template with no ability to make choices or no ability to modify the appearance of my data I would have stuck with Ancestry.com.
I agree with you about coming up with clearer definitions and usages of pages; that is explanation and education, and helps foster consistency. Implementing the WeRelate talk:Support page is a helpful way to answer basic utilization questions; multiple video and text tutorials giver new users a place to learn the basics; multiple help content pages such as Help:Contents are educational tools useful for new users or experienced users branching into new areas. Can we come up with more helpful recommendations for Dallan to simplify the use of WeRelate? Sure we can, and I'm sure he welcomes any and all ideas.
But to go back to some of the areas that are causing people concern, such as red links on a page, just because they don't know what to do with them, should Dallan entertain a motion to eleiminate them? Those red links are there as automated hints for possible expansion of information. People don't have to use them, but they can if they want to. They are an avenue for recording further research. Just because someone is confused about the difference between an article and a category under the same topic heading, do we eliminate one of them so they don't have to make a choice? My thought is we define the overall scope of each and let them use them the way that best suits their needs and abilities.
But this whole discussion of Shared Research Pages vs. Surname in Place articles, Categories vs. Article, and links between Surname Pages and associated Person and Family Pages, are not coming from new users; they are coming from experienced users, saying it would confuse new users. Possibly. So Dallan took the time to put out a series of questions, and to this point only two others besides myself responded to his specific questions. 'Nuff said.
BTW, Janie, I appreciate your fine work with Surname in Place articles, such as on the Jackson line. Now just hit those Surname in Place red links on your user page and the world will be a better place. :) Take care. --BobC 12:13, 16 January 2010 (EST)
Oh! I just learned how easy it is to 'fix' all those red links. I've been leaving them red because I thought I had to add some text to that page. Not so - just click edit and save! Duh! Maybe some more precise automatic wording across the top of the red pages would instruct wiki-challenged folks like me. --Janiejac 04:23, 17 January 2010 (EST)

Mc and Mac and O' surnames [25 January 2010]

In going through the web page Source pages that are family trees (and that have not been linked to by a Person page), I have been adding the web pages themselves as resources on the relevant surname pages (along with a brief descriptive paragraph) before eliminating the not-useful (too narrowly focused, not an actual source) Source page. I note that there are no auto generated surnames that begin with Mc and Mac (or ones that begin with O'). For obvious reasons, these type of surnames could quickly become overwhelming. But there is no explanation that I can find, nor instructions that one should not add Mc or Mac surnames. Can someone give me the background on these surnames? Is there a policy to index them under the name that comes after the prefix? How should one be redirected to the "correct" location to research these names? If there are guidelines I should be following, let me know! I'll go back and fix any errors I may have created inadvertantly...

Thanks,--Brenda (kennebec1) 09:24, 11 January 2010 (EST)

Hi Brenda, you may want to do a little further searching on those Mc and Mac names -- you may find some of them contain a space between the Mc/Mac and the root name, such as "MacNeil" is shown as "Mac Neil" whereas the name "McClure" is categorized as "McClure." Good luck. --BobC 09:42, 11 January 2010 (EST)
Brenda, you also can't generalize about the use of either "Mac" or "O'" names. As an example, "MacIntosh," "McIntosh," "M'Intosh," and "Mac Intosh" (with a space) are all exactly the same name and the variations often appear all in the same nuclear family -- even in letters or documents written by the same individual. Different 19th century publishers in the UK also had different rules when rendering the name in print. (All this history is also why library catalogs file them all together, and why "Mac" names are alphabetized as a separate "letter" before names beginning with "M.") But note that "Intosh" is not going to appear as a surname, so "Mc" cannot be considered a prefix; it's just part of the name. That's the Scots.
The Irish are different. "Mac" names in Ireland usually have Scots origins. (But not always. "McCarthy" is ancient in Ireland.) Names beginning with "O'" are Erse (as opposed to Gaelic) and often lose the prefix with no problem. Hence, in my family, "O'Cronin" of several centuries ago became just "Cronin" by the time the family began emigrating in the 1820s. Some names, like "Sullivan," are never seen with the "O'" prefix, unless someone is being humorously hyper-Irish. So, yes, with Irish surnames you can consider it a prefix. Probably there should be a redirect from "O'Cronin" to "Cronin," or vice versa, just to keep the variations together.
We'll go have coffee sometime and I'll bend your ear about the Welsh and their insane attitude toward surnames, or the lack of them. Onomastics can drive you to drink! --Mike 20:18, 11 January 2010 (EST)
Hi Brenda. The autogenerated names were taken from some English name book. There aren't any auto pages for a lot of names. That doesn't mean they aren't valid, just that you have to create them yourself. Use the surname pages to indicate equivalent spellings so that searches will find pages using any of the varients. As for what is "correct" there's really no such thing. A person's name is whatever he says it is or whatever other people call him. We in these days of birth certificates, driver's licenses tend to overemphasize what is "correct". Even today many people change their names on their journey through life. Also note that many of the equivalents on the surname pages are just plain wrong. What a computer thinks is a similar spelling (which again uses only English rules) doesn't make it the same name. We need to clean these up as we go. --Judy (jlanoux) 21:23, 11 January 2010 (EST)

Thanks everyone for the input. I'm glad to know I wasn't breaking some unknown-to-me rule by adding these surnames... And I have to say, I really look forward to meeting many of you one day. You all are a wealth of specialized and fascinating knowledge, even if what you "know" sometimes contradicts what others here "know"... I will proceed accordingly, (very slowly) working through the web page sources to add them to surname pages if applicable.

By the way, would any of you onomastics experts (I had to look that up...) care to speculate as to origin of the surname Remeschatis/Remeschatus? It's my family's particular surname brick wall (immigrated from Bremen 1871, immigrant born in Neustralitz, and found in one presumed ancestor of immigrant in Neustralitz in the late 1700s... but otherwise apparently now almost extinct except for the remnents of the U.S. immigrants). --Brenda (kennebec1) 12:25, 13 January 2010 (EST)

Brenda, here is an article from U.S. News & World Report about a lady named Linda Remeschatis. Perhaps you could contact her for more information about her ancestry to see if there might be a connection or to see if she knows the origins of her (or her husband's) surname. It seems to be an unusually rare name. Good luck in your search. --BobC 10:51, 19 January 2010 (EST)
I believe (no promises) that schatis/schatus is an earlier common spelling for the German schatz, which means "heart." And schatus probably has a Latin root. I can't make a guess about the origin of the "reme" part, but I suspect the name might have some relation to Roman Catholic history or liturgy. --Mike 16:24, 23 January 2010 (EST)

My guess for the surname Remeschatis (since I can't a proper reference either), is a latinized version of the town Remscheid. By the way, I can find no references to schatz=heart. The German word Schatz means a valuable thing, ie. treasure, darling, money hoard, etc. --Bgwiehle 12:43, 25 January 2010 (EST)

Help Beth in organization [12 January 2010]

I am starting this topic on my user talk page if anyone is interested. First step is deleting and/or reorganizing email messages. I need encouragement and input. If there is a better place for this discussion please advise. I am on Facebook and Twitter. --Beth 20:21, 12 January 2010 (EST)

Please vote [23 January 2010]

Just in case you didn't see it on the homepage: Please cast your vote for the new feature you most want to see added to WeRelate by signing your name next to the feature in the ToDo list. This will help me focus on which features (on a rather large ToDo list) to work on next. Thanks!--Dallan 11:00, 23 January 2010 (EST)

Dit names and German names [29 June 2014]

Recently there have been a couple of comments about dit names and the German practice of using very-common names for the first given name and people going by their middle name as their "primary" name. I'm looking for advice. Should the system have new "alternate name" types for dit names and german common names? If so, what should the types be called? "Dit name" and "Baptismal name"?--Dallan 09:44, 25 January 2010 (EST)

There is already "baptismal name" in the drop down for alternate names; however, I'd rather see that when a GEDCOM is uploaded, the system takes what's in the first name field, adds it to what's in the surname field and creates a page title with the results, so that Maria Magdalena Dressel becomes Person:Maria Magdalena Dressel (#) instead of Person:Maria Dressel (#). (Hyphenating 50-75% of 10,000 names in my GEDCOM is not an option.) Jillaine 10:35, 25 January 2010 (EST)
It's not a German thing, I think it's a continental thing to use double names with the first name being a common one: John, Mary, Joseph...

I've adopted the practice of using the "real" name as the preferred and using baptismal name for the double name. It avoids having twenty pages with the same name. I think if we start making exceptions to the page name rules just for the Germans, it's not going to end there. Everyone is going to want exceptions and you will have pages names with the same junky stuff we get in the name field. That's already a disaster. We need to keep promoting the idea that page names are irrevelant indexes for the system and not "content" and that the primary name field is the important one. Also the places where search is still using page name need to be fixed. The concern that "someone will merge them" won't go away by changing page titles. I can't agree that it is a reason to change the rules. While using names as index was problematical, I think we're stuck with it and need to keep the rule as is. I speak from experience that uploading a non-trivial gedcom requires a LOT of editing. I'm beginning to believe that no time is saved overall.

When baptism names were added to the type, "birth name" went away. That is unfortunate because we really need both choices. Not every family had their children baptised - not all religions baptize infants. Dit names are an especial problem because there is no consistency in their usage. The most usual case I enter as a title suffix as it is usually listed as an alternative to the surname from the days when names were a lot more slippery than they are today. e.g. Jean Caissey dit Roger. Half of the children used Roger as a surname and half Caissey. I don't feel that we need an extra type for dit names. Alt handles that issue as well as many others. But I do think we need Birth and Baptism types because they indicate that the primary name is not the person's "official" or "legal" name.--Judy (jlanoux) 11:41, 25 January 2010 (EST)
When the dit name is entered in the suffix field, it is not found in searches for that possible surname. So if we put Jean (Given) Caissey (Surname) and Roger (Suffix), searches for Jean Roger don't find him. Then, at one point, Dallan had suggested putting Caissey dit Roger in the Surname field. This now poses problems for the automatic surname in place categories. I agree, perhaps just a policy that dit names are entered as an alternate name will suffice. However, having dit as a drop-down option is a nice reminder. --Jennifer (JBS66) 11:47, 25 January 2010 (EST)

To me it is not a continental thing at all as I go by my middle name with first initial L. I find it extremely annoying that people can't understand that. No one seems to remember such folks as F. Scott Fitzgerald, W. Clement Stone, H. Ross Perot and many more. I recently had some government paperwork returned for lack of a "legitimate" name, whatever that means. Invariably, if I enter my full name, Scot will become middle initial S, Arghh. On the other hand I do know a Portuuese family with six daughters, all of whom are named Maria. One goes by Maria and the other 5 by their middle names.--Scot 12:17, 25 January 2010 (EST)

Okay, if the page TITLE is not to be thought of as important as the NAME, then the user interface/display should be changed. Because right now, the *Page* Title is the most prominent thing one sees on the page. So when I see "Maria Dressel (29)" shouting at me from the top of the page, I go a bit nuts because she's really "Maria Magdalena Dressel" and I really don't want to SEE "Maria Dressel" so prominently. It would be far far far better to have the following be the dominantly displayed text on a given page:

  • Person Pages: A string of Prefix+Given+Surname+Suffix fields; e.g., Rev. Thomas B. Carter Jr.
  • Family Pages: The above strings for each spouse resulting in, e.g., Rev. Thomas B. Carter Jr. and Maria Magdalena Dressel
  • Source Pages: The contents of the TITLE field.


Then relegate the PAGE TITLE display to some smaller, out-of-the-way, but still visible space (for purposes of cut-and-paste). This way, you still have unique page titles, but their often horrendous names do not dominate the page space.

-- Jillaine 12:45, 25 January 2010 (EST)

I agree, I agree. The Name/title area are too obscure. It took me several weeks to realize the name field was there. Maybe I'm unobservant, but it was very disconcerting that the edit view is so different from the display.  :-) --Judy (jlanoux) 13:42, 25 January 2010 (EST)

I'm finally back working on WeRelate after spending the majority of my time for the past few months doing a consulting project for FamilySearch.

  • I'll add "dit" as an alternate name type.
  • I removed "birth name" from the list of name types because I assumed that birth name would always go into the primary name field, and having a separate "birth name" type caused people to think that maybe some other name (e.g., married name, stage name) would go into the primary name field. Is there are reason to have a "birth name" type?
  • I'll work on making the full name be the predominantly-displayed name on person/family pages, and titles on source pages.

--Dallan 14:00, 3 March 2010 (EST)

I'm not at all sure if this is possible here, but in light of recent conversations about "preferred" and "primary" names, I thought I would ask. It appears to me that we often debate about which is a "preferred" name for a person, which spelling should appear as the page title, etc... Doesn't every record in the database have a unique identifying number? Why can't that number be used for the URL? This could eliminate the need to even worry about the page title equaling the URL. Then, each variation of the name could be listed equally. Another wiki genealogy sites employs this number-in-URL technique (Rodovid).

I've thought about that, but here's the issue: one place where you can't use the preferred name is when you link to the page. Now most people don't manually link to pages, but a few do. Would you rather link to [[Person:4832745]] or [[Person:Name-as-it-appears-on-page-title]]. I keep coming back to name-as-it-appears-on-page-title is preferred, although I'm starting to wonder if name-as-it-appears-on-page-title should be the full name, not the first given name. This causes other problems (needing to rename a page when you discover a middle name for someone), but maybe the benefits outweigh the problems.--Dallan 11:11, 4 March 2010 (EST)
Looking at your idea of full-name page title: I have an ancestor, Piebe Lieuwes. In 1811 he chooses the surname Swart, so I rename the page to Piebe Lieuwes Swart. Then I discover that he most often spelled Piebe, Pijbe, so I need to rename the page again as Pijbe Lieuwes Swart. With scenario #1, having the URL be a constant http://www.werelate.org/wiki/Person:4832745, there may be some advantages. I could include the various spellings of his name in the correct form fields and never have to worry about the URL, and never have to rename the page. I, personally, think that one of the most confusing aspects to WeRelate is having to worry about the URL and choosing a "preferred" name and "preferred" spelling. Sure, linking to people and families would require [[Person:4832745]] instead of [[Person:Pijbe Lieuwes Swart]], but do the advantages outweigh that relatively minor disadvantage? --Jennifer (JBS66) 12:03, 4 March 2010 (EST)
I agree with Jennifer. Having names as page ids is a problem and very confusing for most people. Children of a family often get different spellings because different people added them. Then someone decides to rename everyone, etc. etc. etc. When I do manual links, I have to copy and paste because I am never sure of the exact page title. Numbers would be cleaner and wouldn't confuse people with the page title and primary name. (If they survive the transition.)--Judy (jlanoux) 19:00, 4 March 2010 (EST)

Regarding birth names, in my work on Dutch genealogy, the birth name is not always the name that I want as primary, those born prior to 1811 did not have surnames. For these people, I consider their name after they chose a surname in 1811 as their primary name. I think that saying the birth name will always go into the primary name field may be a bit restrictive. --Jennifer (JBS66) 14:36, 3 March 2010 (EST)

Interesting. I wouldn't have expected that. I'll start this as another topic.--Dallan 21:31, 4 March 2010 (EST)

Oh please don't take away Birth Name as a type. Many people are not known by their formal birth name and therefore we don't like to have to use birth name as primary every single time. Also we need Baptismal Name as a separate type because what the priest wrote in his book ofter wasn't what the parents "named" their child. --Judy (jlanoux) 16:52, 3 March 2010 (EST)

Ok, I'll add back birth name as a type. Thank-you for letting me know.--Dallan 11:11, 4 March 2010 (EST)

Just what is wrong with having a discreet field for middle name?--Verlyn 17:49, 29 June 2014 (UTC)

Need Source Merge [28 January 2010]

Here are two Sources I believe are duplicates. I don't want to try to merge them but I think it should be done.

Source:King, G. H. S. Register of Saint Paul's Parish 1715-1798 : Stafford, County, Virginia 1715-1776, King George County, Virginia 1777-1798

And: Source:King, George Harrison Sanford. Register of St. Paul's Parish 1715-1798

This second source has a talk page attached. Once the source pages are merged the talk page may not be relevant. OK with me to delete my part. --Janiejac 19:51, 26 January 2010 (EST)

I did the merge of the duplicate sources; I left a message on the talk page asking if the PAGE should be renamed to the full title (which could be a problem since I've now deleted the duplicate page that used to have the full title??). For now, tho, there is just one source page with all the repositories combined.--Brenda (kennebec1) 11:56, 28 January 2010 (EST)

United Kingdom Crown Copyright Waiver [3 March 2010]

I have many United Kingdom Birth, Marriage and Death Certificates which I would like to upload as images but which are technically subject to Crown copyright. I have recently discovered that subject to certain conditions, see below, this copyright has been waivered. Can we add a new license type to the image upload page as it is rather tedious having to select other and entering the details in the text box.

Guidance - Copying of Birth, Death, Marriage and Civil Partnership Certificates Date: 27 October 1999 (Revised April 2009)


This guidance note sets out the arrangements for the reproduction of official birth, death, marriage and civil partnership certificates (’extracts’ in Scotland). Copyright in the layout of certificates is owned by the Crown. The Crown does not assert any rights of ownership in the contents of the forms.


You are authorised to reproduce the layout of the form in any format including on the web, in films and in print. This authorisation is subject to the following conditions:

  • That you must not use reproductions of certificates to provide evidence of birth, death, marriage or civil partnership. Where a copy is required to provide evidence that an event was registered you must order an official certificate (’extract’ in Scotland) from a local registration office or General Register Office.
  • That the material is not used to advertise or promote a particular product or service, or in a way which could imply endorsement by HM Government;
  • That you comply with the Data Protection Act 1998 and the Human Rights Act 1998. This guidance does not authorise you to reproduce the contents of any certificate containing personal data about living individuals;
  • That you reproduce the Royal Arms and any departmental logo only as an integral part of a certificate.

--Btomp 11:26, 10 February 2010 (EST)

My view is that each image should be a stand-alone document (or image) rather than a group of documents and should have all pertinent copyright information listed for each image. Users will typically look at images or documents as separate files rather than a group sharing a similar origin or copyright and all pertinent copyright information should be listed, identified, and clearly shown on each file-space. Perhaps you might want to {{template}} the above statement and put on each document image, which to the average user would be indistinguishable from the whole copyright included as part of each file. Perhaps some of the WR Admins would have their own recommendations. --BobC 23:24, 10 February 2010 (EST)

I could add Template:CCW2009 to the MediaWiki:Licenses list of image licenses, but in an effort to keep the list of licenses displayed from growing too long, I think that selecting Other and adding {{CCS2009}} to the text of the page is the better approach.--Dallan 14:00, 3 March 2010 (EST)

Zorched GEDCOM-Merged pages? [3 March 2010]

Hi there... I am now trying the impossible task of merging my sister's MyFamily GEDCOM with my WERELATE GEDCOM in an external program... I downloaded the GEDCOM here and loaded it into the desktop program... and noticed about 2,000 people are missing (!)... I came back here and it looks like (This is my theory at first blush) when trees are merged, they are un-treed... thus (Since I've been a little merge happy), most of my lines past a certain point need to be re-added to my tree... The problem is that you have to click on the individual, click add tree... etc. This could -literally- take days of clicking to restore my tree for GEDCOM retrieval-Especially since I know with merges that there are more than 2,000 related folks that are in the Pando here...

Is there any way to "Autofill" an Add to Tree? Add anybody linked to your tree into your tree? Maybe just ancestors (As opposed to linking EVERYONE in the database)... Maybe this function already exists and I don't know it?

Just wondering... I am trying to find the best way to do this (And get one clean tree out of all of our myriad different trees) without having to repair each and every record...

Aabh 01:19, 13 February 2010 (EST)

You have other options when you click Trees. You can add ancestors of a person (and their children) or descendants. So if you can pick a few key people at the top or bottom you can do most of it in one click. You can check for people missed from the Trees link on MyRelate. It has an option Related pages not in Tree. You can filter this for Person pages and see if you missed anybody. --Judy (jlanoux) 11:32, 13 February 2010 (EST)
Judy has a good suggestion, but merges shouldn't have caused someone to be removed from your tree -- after the merge you should be watching the merged page. I'll double-check this to make sure, but I'd appreciate you giving me an example of someone in a gedcom that you uploaded who is not in your tree.--Dallan 14:00, 3 March 2010 (EST)

compiler to researcher [24 February 2010]

A year or more ago someone posted an interesting piece outlining the path from a family historian to compiler to researcher. Does anyone know where I could find that again? I think it was on a user page but I'm not even sure about that. (I wish I had kept a copy!)--Janiejac 16:40, 24 February 2010 (EST)

Page titles for Person/Family pages [31 Mar 2010]

A couple of people have suggested that having ids (numbers) would be better than names for Person and Family page titles. So Person:1235432 or Family:345234. Nothing is going to happen right away, but I'd like to talk about it. Replacing names with numbers affects the following areas:

  • Search results -- this one's easy; we display the full name instead of the page title for Person/Family pages
  • Category pages -- we'd need to display the full name instead of the page title
  • Editing Person/Family pages -- I think we'd need to come up with a way to display full names in addition to numbers in the link fields when editing Person/Family pages
  • Email notifications -- I'd need to modify the notification messages to list the full name, not just the number.
  • Contributions, watchlist, recent changes -- probably all need to be modified to list the full name, not just the number
  • Links to pages (i.e., linking to a person page in text [[Person:1234532]]) -- not sure what do do about this; about the only thing I can think of is to add a button to the edit bar above the text box that opens up a mini-auto-complete screen.
  • Any other places?

So changing the Person/Family page titles would require some programming work, but maybe it would be worth it in the long term. Note that it goes contrary to Familypedia, which includes not only full names but also birth/death years. What do others think?--Dallan 22:01, 4 March 2010 (EST)

I don't understand the purpose of this (even having read the request above). I understand that names change, but you're talking about altering the entire architecture for a tiny minority, back-programming the rest of the system to have it behave the way it already does now, and adding the additional difficulty of forcing us to use 8-10 digits for page names instead of actual words that human beings are familiar with. What a gigantic waste of precious engineering efforts. Right now, if a page name changes, it gets a redirect. Big deal. No links break. There's a learning curve to figuring out what name to use, but it's almost always not an issue, and it's predictable without looking up every single page. (Not to mention the pre-medieval WP page title rule, which ensures consistency in older pages.) Typos with numbers will be far more common, and far harder to fix--impossible if it's not your own mistake, probably, whereas pretty much anyone can tell that Paul Smitth is probably Paul Smith. In sum, I see no advantage whatsoever, and enormous disadvantages in disruption, wasted effort, and confusion.
Now if you're going to propose having categories, watch lists and other auto-generated page lists show better titles with full names, then I'm all for it. But if I only get that in favor of having to keep track of numbers instead of names, I'd really rather not.--Amelia 23:11, 4 March 2010 (EST)
I agree with Amelia for the most part. I don't see the big gain (i.e. value added) for doing this. Yes, every person would have a unique number assignment, but that would not be a searchable useable feature like the current namespace is now. I think it might cause more headaches for many, especially novices, who would view it as a useless and quite possibly confusing feature. While some genealogy programs used/use the unique reference number for identifying people in its database, it is transparent to most users, but upon GEDCOM download sometime caused problems, such as when downloaded sometimes conflicted with other program's assigned reference numbers when imported. An example I can cite was PAF into EFT (from the early 1990s); when later transferred to FO created two extra unique reference numbers for every original person from the old programs (that showed up on every report asking for data fields) that I spent years trying to get rid of. It was more of a nuisance for me than a benefit.
Personally, I think there are many other greater needs on your "To-Do" list. (Just my opinion.) --BobC 09:10, 5 March 2010 (EST)

I think there are definite benefits to considering using unique reference numbers. To be clear, this number would appear in the URL, like this: http://www.werelate.org/wiki/Person:123456. Searches would remain the same, because that would use the form fields (like full name and birth date). Why did I originally bring up the question? Well, there have been conversations such as German names and how they might import and using birth name vs. primary name. There have been disagreements between users that wanted one type of spelling to be "primary" over another. There are naming rules that are complicated for new users to grasp, such as this one. This really is a usability issue, and I appreciate Dallan considering its implications. When a new person/family is created, users could input all of the data for their ancestor's name, including middle names, alternate spellings, etc. They would not have to consider, which spelling should I list as primary, Boudrot or Boudreau? They would not have to edit or rename pages because their baptismal name of Marie or Joseph was considered primary, instead of their more common name. We wouldn't have users become confused over the use of index numbers following names. I can see where seasoned WR users have become accustomed to the system... but the complaints and confusions are out there! --Jennifer (JBS66) 09:42, 5 March 2010 (EST)

Jennifer, you bring up an interesting point in citing the use and appearance of foreign names as would be recorded in the URL title. An example would be one German ancestral line I research, the Schönauer name which page is identified by URL as <http://www.werelate.org/wiki/Surname:Sch%C3%B6nauer>, which I agree is awkward. But if the URL became <http://www.werelate.org/wiki/Surname:S12345> how would that benefit me or users searching for information on my Schönauer ancestry. Yes, "S12345" may be visually more appealing and easier to type than "Sch%C3%B6nauer," but does it make it any more effective as an identifying feature, address or search element?
Furthermore, I think your line of reasoning between deciding which name (birth, baptismal, stagename, etc.) is primary is not totally applicable or justifiable to make such a programming change, because even with number identifiers in place, it is a decision which will still have to be made regardless of how individuals and families are identified in the database. You certainly cannot list all names throughout all documents, pages, and reports and have it remain a user-friendly application. And then throwing ID numbers into the mix would make it even more intimidating.
Please let me know if I missed or don't grasp your point succinctly. --BobC 10:58, 5 March 2010 (EST)

As Dallan's notes indicate, he would still need to export a readable name to family pages and search results, and therefore this process would still be singling out one version of the name over the others. So I am not sure this is worth it. If this had been done from the beginning, I think it might have resulted in some simplification, since I suspect most genealogy software uses a unique number internally to keep individual records having the same name separate. So I agree that it might present less of a learning curve than the current system. Also, in my opinion, this would be a good way to title source pages.

Perhaps Dallan could comment on whether this change could somehow simplify the ability to use GEDCOMs to iteratively download/upload information, this being a feature some people (not me) have requested. It seems like this naming method might make it possible to establish a more stable link between the person in one's personal database and the page on WeRelate, and enable repeated information transfer?

There are techniques for making the number easier to work with, most obviously chunking, like a license plates or old style phone numbers, where the first three or four characters are letters, followed by a smaller number, etc. --Jrich 10:03, 5 March 2010 (EST)

Taking this one step further, would be also have to change our User Names to User Numbers? Frankly, I prefer User:Delijim to User:12321......  :) I guess Dallan and SQ would be User:0001 and User:0002....

Seriously though, if we come up with some "numbering system" to help identify persons and/or families on WeRelate, it should (in my opinion) operate "behind the scenes" and not replace the normal naming convention that has already been established....

Just my $.02. :)--Delijim 19:54, 5 March 2010 (EST)

Having numbers for page titles wouldn't affect gedcom re-upload one way or the other.

User:BobC makes a good point. Having numbers for page titles doesn't remove the need to decide which name is the "primary" name. The basic issue I'm getting is that the page title is often a less-than-ideal substitute for displaying the full primary name of an individual. So if we used upon the page title less often, still used it in the URL, but started displaying the full primary name in search results, at the top of person pages, in email notifications, contributions, and watchlists, etc. that might be the way to go.--Dallan 10:06, 25 March 2010 (EDT)

Rodovid works with ID-numbers. See Charles the Great Charlemagne, displayed in 19 different languages with about 19 different names, but with one ID number. Try to search there and try to change some one, to experience the way numbers are working (no login needed)Regards, salutations, Grüssen, groeten, Fred Bergman 08:05, 31 March 2010 (EDT)

NGS conference, Salt Lake City [25 March 2010]

Hello, I'm curious if WeRelate is going to be at the Salt Lake City conference at the end of April this year? Also, is there anywhere on this site to discuss such things? I didn't see a portal. Perhaps that is too much of a social web 2.0 type thing : ) which is fine, I'm not asking for such a place, just curious if it's out there and I don't see it : ) Is there a better place to post such a question? This is only my second national conference, and my first time at Salt Lake, so I'm a bit excited about the whole thing... the mother ship and all... : )

thanks, Amelia J. (88buckaroo)--88buckaroo 14:55, 9 March 2010 (EST)

The watercooler is the perfect place to ask such questions :-). Solveig and I aren't going to NGS this year unfortunately. (There's too much on my Todo list.) But it should be a good conference (though I wouldn't plan on doing a lot of research at the library since it will be very crowded). I hope you enjoy it!--Dallan 10:06, 25 March 2010 (EDT)

Givenname/Surname Pages [31 March 2010]

There was talk of re-working the way Givenname and Surname pages work so you only have to maintain one list. Wonder if that is still somewhere on the list? I just added Givenname pages for various spellings of Eleazar (the wikipedia spelling), including Eleazer, Eliezer, Eliazer, Eliezar, Eliazar. At the time I had found actual cases of records using five of the spellings. I added the sixth merely for completeness since I'm sure a search of colonial records could find an example of it being used somewhere, and that means somebody sometime is bound to create a page using it. Six essentially identical pages created. If you want to another spelling variation, you would need to update all six, as I understand the way it works, plus adding the seventh page. Sure would be nice if you could just maintain a list in one place. Can redirects be used here, so you can create one page and then simply redirect all the alternate spellings to the one main page? --Jrich 13:17, 11 March 2010 (EST)

Redirects may not be appropriate, because if the family surname is Eliezer, then the suname for that family is not Eleazar and shouldn't be redirected there. Why not do that in the category namespace? All surname pages are categorized to their surname categories. The parent category for all of those surname category pages could be the "dominant" or "original" surname spelling. I have a few examples of that in my own family tree. --BobC 13:47, 11 March 2010 (EST)
Actually, in this example, Eleazar was a Givenname. Nevertheless, before sometime in the 1800's it is very hard to argue what the proper spelling is. Only recently do people use spelling as marks of individuality. Back when half the people signed contracts by mark, the spelling represented the attorney's, or clerk's, idea of what the spelling was supposed to be, and varied throughout the life of a person. A recent article in NEHGR (163:254) on Gabriel Whelden gave the baptisms of his children, all done at the same church. Despite this continuity of being recorded in a single book, his givenname was spelled Gabriel and Gabrill; and the surname was variously spelled as Whelden, Weelden, Wheeldon, Wildon, Wilden, and Weelding. People tend to use the form they work with, so a descendant of his daughter "Kathren" might be focused on the "Weelden" spelling used in her baptism record. Without some flexibility in spelling they would create what is really a duplicate page, and miss their opportunity to collaborate.
As Jennifer points out, the category won't help the search function either, so if I search for Eleazar, I also want to get Eleazer and Eliezer, etc., which are after all the same name. Same for surnames. If I search for the Skillin spelling my family uses, I also want to get the Skillings, and even Skellin and Skillion spellings that have been used throughout history, and may end up used on a WeRelate page. --Jrich 14:49, 11 March 2010 (EST)

I've been wondering about these name pages myself recently. I don't believe that categories would work, because surname pages serve a specialized purpose for the WR search function. An alternative idea to the 6-7 pages for each name variation is the Dutch Namenthesaurus. If you search for a given name, Pieter, 3 choices are returned: Pieter (male), Pietje (female), Pieters (Patronym). Choosing Pieter (male) gives you the 36 various spellings for that given name. --Jennifer (JBS66) 14:02, 11 March 2010 (EST)

Eventually I plan to move the related names off of the Givenname and surname pages and onto separate pages that only list related names, probably one page for each letter of the alphabet for givennames, and for surnames. At that point you'll be able to list all of the variations of a name on a single line, and searches for one variation will search all variations on the line.

One a related note, I've been working with FamilySearch over the past few months to help them develop a better related-names list for their historical record search engine. I've been talking with them about making the result open-content when it's finished. If that happens, I'll integrate that with the related names here.--Dallan 10:06, 25 March 2010 (EDT)

Read this a couple of days ago, and it sounds good, but suddenly now a thought popped in my head. Some spellings don't start with the same letter. An easy example would be Ames/Eames. I'm sure there are several other examples. Just thought I point this out. Possibly the exception rather than the rule, so in these few cases, it would have to be done on two pages? --Jrich 14:40, 27 March 2010 (EDT)
I'd like to add similar names such as "Aebersold" and "Ebersole" (and variations); "Aermel," "Ermel" and "Armel" (and variations); and "Tritsch" and "Dritsch" (and variations). I'm sure there are many others. --BobC 00:21, 29 March 2010 (EDT)
In Dutch, names beginning with Y/IJ, like IJdema and Ydema, Ype and IJpe, also Cornelis and Kornelis.--Jennifer (JBS66) 05:27, 29 March 2010 (EDT)
There are a lot of names like this. In general, each name is assigned to a single group. And the groups are alphabetized, not the individual names. So Eames might be assigned to the Ames group, in which case it might appear with other names like Amis and Imes on the "A" page.--Dallan 22:13, 31 March 2010 (EDT)

South Carolina - Pre 1800 Districts ? [29 March 2010]

Hello Everyone,

I do not remember a conversation on this topic. There probably was and I just forget it though. Or it was part of a broader discussion. So If you could point out it's location that would be good too. I would like to understand the theory here.

I have found out one of my ancestors had land in the "old Ninety-Six" District of South Carolina. It seems to be a pre County location. I am curious how or why WeRelate does not have the Pre 1800 Districts for South Carolina as a Place. There seem to be about 6 of them. Is there an agreed rule, or did someone not create these page yet? Thanks, Debbie Freeman --DFree 14:06, 19 March 2010 (EDT)

For more information about Ninety-Six (which is an actual present location as well as a pre-revolutionary war site), see the Wikipedia article on the location and subject as a judicial colonial district. In 1769, its boundaries included the current counties of Abbeville, McCormick, Edgefield, Saluda, Greenwood, Laurens, Union, and Spartanburg counties; much of Cherokee and Newberry Counties; and small parts of Aiken and Greenville Counties. In 1785, the Ninety-Six District were given the counties of Abbeville, Edgefield, Laurens, Newberry, Spartanburg, and Union. Further adjustments were made in 1791 and 1800. In 1868, the districts were converted back to counties.
Debbie, if you have this information on old SC colonial district locations, and if you are interested in updating the WR place name spaces to reflect their historic names, judicial use and geographic boundaries, why not just add those details to the place pages yourself? --BobC 09:27, 22 March 2010 (EDT)
I agree with BobC. Please do add them! This is the first I've heard about them. You could add a place page of Place:Ninety Six, South Carolina, United States for example.--Dallan 10:06, 25 March 2010 (EDT)
OK Thanks. I will start to add these pre 1800 places. I will add to the State Page more details too. I will probably need help later. Debbie Freeman --DFree 10:49, 25 March 2010 (EDT)

I think I am now done creating the early South Carolina Place Pages. Because of my limited computer skills I cannot do more to these Place Pages. They look a little bare, etc. If and when you have time could someone please help add more content, makes corrections, verify, check grammar, punctuation, etc. I cannot do more to these Place Pages because of my limited computer skills Thank You, Debbie Freeman --DFree 16:47, 28 March 2010 (EDT)

Debbie, please provide a link to what you edited or a point of reference to what you added. I looked on the Ninety-Six, SC place page and was hoping you might have edited the "Also located in (one per line): Place | From year | To year" block to link to the colonial district you created, but there was nothing. Please advise so I can be of further assistance. --BobC 08:48, 29 March 2010 (EDT)
Bob, Debbie created quite a few places which can be found, perhaps most efficiently, under her list of contributions. Hope this helps. --Jennifer (JBS66) 08:57, 29 March 2010 (EDT)
Hello BobC & Jennifer, Thank you ever so much for the help. Yes I did go ahead and created quite a few place pages. I created place pages that the book had that did not exist or seem to exist in detail on WeRelate. I think now we have the whole list of pre 1800 places for South Carolina. BobC the one you mentioned I did not create. I do not know how to do these links from the other websites off of WeRelate. Providing links is a little beyond my scope of computer skills, sorry. I hope Jennifer's idea works. I named the place pages the way the book had them. I did have to use (district) and (old county) for many place pages to make them different enough from the other same named places. Gratefully, Debbie Freeman --DFree 12:16, 29 March 2010 (EDT)

Shared page for DNA project? [30 March 2010]

I understand that user pages can be viewed by anyone but edited by only the user. I would like a page that I could share with one or two trusted people so either of us could edit but no one else could. If I created a user page and shared my user name and password, would that work? Or is there a better way? I know something similar is in the works for living people, but I want this page to be an article and the folks are deceased. I am contemplating a Results page for a DNA Project and the info on the page would be entered only by the various co-administrators of the Project. --Janiejac 11:12, 30 March 2010 (EDT)

Janie - I don't know about any "system" solution, but how about creating a new account just for this purpose? That way you could share the username/pw with people without it opening up all of your account. If you set up an email alias to use, you could all get modified of changes, as well.--Amelia 11:19, 30 March 2010 (EDT)
That's a good idea! Thanks Amelia! I am a new co-admin for a large neglected DNA project and am thinking this would be a good way to keep a results page. If I do this, I would list the member and his father as 'Private' and not give their actual names. The ancestors could be linked to person pages if they are available at WeRelate. --Janiejac 15:21, 30 March 2010 (EDT)
I am not sure the idea of sharing account information is something that we want to promote at WeRelate. If we even loosely base our policies on Wikipedia's they state that "User accounts can only represent individuals. Sharing an account – or the password to an account – with others is not permitted" (found here). In fact, our own policy states: "All users are encouraged to select strong passwords and to never share them." Is it possible for one of you to maintain a user page, with other users making suggestions for edits via the talk page? I know that it's not an ideal solution, but the thought of encouraging shared accounts is concerning. --Jennifer (JBS66) 18:51, 30 March 2010 (EDT)
Ah, so that's another thing to consider. Thanks for your input. This idea is just at the slow simmer stage and will take some watching and needs all the suggestions anyone is willing to offer. There are about 300 members in this DNA Project, so it would be a major understaking. --Janiejac 19:40, 30 March 2010 (EDT)

GEDCOM upload problem? [24 July 2010]

If you look at Family:Edward Converse and Sarah Unknown (1), there are four children: Samuel, Josiah, James and Mary. When I recently uploaded a GEDCOM with this family, the family only ended up with two children and when I noticed, I had to manually connect the other two.

Here's what I think happened. The existing family page was updated with new sources I was uploading. The one lone child originally shown on this page, Samuel, was updated as well. A child Josiah who previously didn't exist in WeRelate at all was added and placed in this family. So far so good.

The remaining two children, James and Mary, both existed in WeRelate with their spouses prior to my upload, but neither one had their parents identified. When uploading, I matched to James and Mary family pages using their spouses. This part worked. But James and Mary did not get added to Edward and Sarah's page as children, even though they were so connected in my GEDCOM.

It happened with one other family in this upload as well. --Jrich 00:53, 23 December 2009 (EST)

Wow you're right - that's a bug. Thank-you for reporting it, and thank-you for the detailed explanation! If you're uploading a person and you match the person with an existing page, and their parent family page with an existing page, and their spouse family with an existing page, and the person in your gedcom is related to both families but the existing person is related to only one family, the system won't add the person to the other family. I'll put fixing this bug high on my todo list.--Dallan 20:25, 14 January 2010 (EST)

I've just tried to upload a GEDCOM containing about 130 people. Why should I get a message "This file is larger than the maximum allowable size for a GEDCOM"?--Robin Patterson 01:20, 14 July 2010 (EDT)

This error appears when there are more than 5,000 "@ INDI" tags in the file (indicating more than 5,000 people), or when the file is larger than 12 megabytes (which happens rarely, generally when the file is not a gedcom file). I'll update the message to reflect that.--Dallan 13:12, 24 July 2010 (EDT)

Category:User-gam3-Direct [8 April 2010]

I didn't notice any guidelines on Help:Categories about what is a reasonable category. I would suspect trees are the appropriate method for this type of grouping? Some categories in use are admittedly a little obscure/arbitrary, but this strikes me as a different case, because it is seems to be designed to be of interest to only one user? If multiplied by all the users in WeRelate it could mean hundreds/thousands of categories on some pages. --Jrich 12:57, 7 April 2010 (EDT)

Perhaps we need something like a MyCategory? Only shows up when that person is viewing it? So I could create a MyCategory:Jrich/BrickWalls, MyCategory:Jrich/Immigrant_Ancestors, etc. if I wanted to tag pages of particular interest to myself. --Jrich 16:32, 7 April 2010 (EDT)
You could keep lists on a user page. --Judy (jlanoux) 17:29, 7 April 2010 (EDT)
Please refer to the general discussion at the Categories Project page and the more specific discussion about the utilization of so-called "family categories" at the related talk page. --BobC 18:58, 7 April 2010 (EDT)

The Categories project page is a long discussion expressing many viewpoints, seems to be developing policies as it goes, and the conclusions are rarely explicitly stated. It would probably be useful if there are some final conclusions, that they be summarized on the appropriate help page, which is probably the place a user would look IF they had questions. It may be useful for an administrator to relay the current policy to GAM3 as my reading of this discussion is that the category named above is not considered appropriate.

Whether a category has a user name in it (user-gam3-direct), has a single person as the topic (descendants-of-edmund-rice), or has a broader title like Settlers-of-the-Gadsen-Purchase or Mayors-of-Chicago, it is not clear to me that any of these are more than one person's research interest. But I believe there will continue to be a desire by various people to create categories that may not have widespread interest. Categories are easy to add, and provide two very useful benefits: stamping the page as part of a group as a alert/reminder, and listing the members in an automatically maintained list anabling easy navigation and study of the group. So, even though I am not personally a big user of Categories, I think there could be benefits to seeing if Categories, or a similar tool, could be provided that allows access to this feature even on a per-user level.

In the meantime, as hinted above, I don't think it has been made clear what a good Category is. The Help page still has the "needs writing" comment on it. What is the principle that distinguishes between a category that is allowable or discouraged? Is it based on universal interest? Should some sort of nomination and acclamation process be necessary to add new categories? Or is the criteria for a good Category based on scalability?

I also thought of a different way to satisfy the desire for categories like descendants-of-edmund-rice, I was wondering if the More menu for all Person pages could support two virtual categories: Ancestors and Descendants of the current person. Selection of these menu items would bring back a list of all the appropriate Person pages that would fall into these categories. --Jrich 10:37, 8 April 2010 (EDT)

Right now, the best way to create user-specific categories is using trees. A tree is a group of pages, similar to a category. You can put as many pages as you want into a tree, and pages can belong to multiple trees. You could have a tree called "actively researching" for example, with the people you were actively researching. The difference is that trees are specific to a single user; they aren't listed at the bottom of the page for everyone's view like categories are.

You can add a person and their ancestors/descendants all at once to a tree by clicking on the "Trees" link at the top of the page.

One issue is that as new ancestors/descendants are added to WeRelate, they are not added automatically to your tree. You have to do that manually by adding the new pages to your tree.

One of the changes that we'd like to make to categories going forward is that they not be specific to a single user, and that they not be used for ancestors/descendants of someone. This would simply generate way too many categories going forward. Descendants of a famous person could be a possible exception, but because of the difficulty associated with having to manually maintain ancestor/descendant categories (adding new people whenever they show up), a better solution seems to be to enhance the system to come up with these lists dynamically rather than try to use categories for ancestors/descendants lists.

On the other hand, Settlers-of-the-Gadsen-Purchase or Mayors-of-Chicago both seem like viable categories to me. The goal for categories is that they are of community interest. Mayors-of-Chicago may be of interest to only a single individual currently, so only one person is working on the category, but you could imagine that others would potentially be interested someday. Groups that are of personal interest ought to be created using trees.

I agree with the comment that the category project page is too long for easy reading. What makes a good category belongs on a help page. Would someone mind adding it to Help:Categories?--Dallan 18:52, 8 April 2010 (EDT)

Perfect timing. I'm attempting to organize and clean up both the project page and the talk page, and extract the highlights and updated category index to both the Help:Categories page and the WeRelate:Category index page. --BobC 21:12, 8 April 2010 (EDT)
Thank you!!--Dallan 21:40, 8 April 2010 (EDT)

Street addresses as place pages [23 April 2010]

I've noticed several people adding street addresses in the Place namespace. Some pages have photos, coords, etc, such as Place:2223 Oak Street, Quincy, Adams, Illinois, United States and others are just the address, like this one Place:132 Hendrick St., Providence, Providence, Rhode Island, United States. I looked on the Place pages help and didn't see anything prohibiting the creation of street address Place pages. I vaguely remember reading something about it, but I cannot find it. Can someone either point me to where it's delineated what kinds of places can have Place pages or correct my recollection that street addresses shouldn't be place pages? Thanks. -- Amy 07:11, 16 April 2010 (EDT)

Thank-you for pointing that out. I've updated Help:Place pages. In a nutshell, political subdivisions, populated places, and cemeteries are ok; hospitals, schools, and street addresses are not.--Dallan 18:15, 20 April 2010 (EDT)
Today I see a lot of new place pages being created such as Place:Noyes Avenue, Pawcatuck, New London, Connecticut, United States. Are these going to be allowed to stay on WeRelate? --Susan Irish 21:58, 22 April 2010 (EDT)
I've discussed the problems with two [1] [2] of the WR users who have a few of those pages in question and have shown them how to correct/modify them to comply with WR Policy. --BobC 10:45, 23 April 2010 (EDT)

Dividing up a large data base for upload [10 November 2010]

Has anyone written a suggestion for how to divide a large data base for uploading? My data base is about 23,000 and I would need to divide it into workable segments but I am having a hard time visualizing just how to do that. I don't want to risk leaving someone out. I have been holding off uploading until the line breaks in family history window gets implemented, but I'm not getting any younger and want to do this while I still can. I would like to start with the earliest folks first and somehow work down but how to do this escapes me. Linking it all back together again will be a challenge. Any suggestions?? --Janiejac 07:58, 16 April 2010 (EDT)

I would use tags. For instance tag the descendants of John Doe, create the gedcom, open the gedcom and scan it to make sure that was what you had in mind, correct if necessary, make a new gedcom replacing the first, then send to WeRelate. Either remove the living before sending or let WeRelate pick them out. Once you have cleaned up the download on WeRelate prepare your next gedcom. For instance the descendants of Sam Smith. His descendants will at some point overlap your first gedcom. When you review Sam's tree, retag to remove the overlap, make a new gedcom replacing Sam's first. Open it to make sure you won't have too many problems once it hits WeRelate, etc. My software is Legacy and tagging is easy. Not sure if all programs have tagging. I don't worry about leaving someone out; it's the family overlaps that I watch for. More than once I've had to ask Dallan to release a gedcom. When you check your gedcom to make sure it is OK, remove the tags before making a replacement gedcom. WeRelate picks up the tag number and every individual that you put on WeRelate will carry the tag number. It's not much fun editing each individual to remove the now meaningless tag number.--HLJ411 11:24, 17 April 2010 (EDT)

This is going to be a lot easier if you explain what program you have. How flexible are the features for marking people for export? Do you have 'flags' that allow you to permanently mark people as being on WR? I can tell you how to do it on Reunion, but that's not going to help if you have different features.

Once you get on WR, you shouldn't have to worry much about overlap. If there are just a few overlapping families, then you match on upload. If you can't easily exclude them in the gedcom and you end up with a bunch of overlap, Dallan will hold your gedcom, you explain what you're doing, he releases it, and you upload/match as before. Since presumably there will be few if any changes between gedcoms, you won't really have to "merge" - you just click the "match" button on the family closest to the root, and it will match the rest of the descendants without you having to do the full merge process. --Amelia 18:29, 17 April 2010 (EDT)

I use PAF genealogy program. I have the following choices for selecting persons for a GEDCOM: All, All Related, Descendants, All Descendants Related, Ancestors, All Ancestral Related. I don't think this program uses tags, at least I never have. And I don't know of a way to mark persons who are already uploaded.

I plan to let WeRelate pick out the living persons as they have no d/o/d. Persons born before 1909 that I have no d/o/d for, I put 'unknown' in the d/o/d spot. (I do have Co. on all the county names because I get tired of trying to figure out whether the named location is a city or county!) Just keeping track of who has been uploaded and who is yet to be done will take some planning! Some of the early folks are not necessarily 'descendants' of my immigrant ancestor. Maybe a daughter married into the Jackson family and to be able to tell who she was, I gathered info on all her family too. I guess that would be "All descendants Related" - maybe.

And maybe I'm biting off more than I can chew. I know that I won't be able to maintain pages on all of these folks though I'll do the best I can. But someone earlier told me that it was better to get it uploaded and get help with it than to let it go undone. And sources - some of it is well sourced, but a very lot of people have contributed their family information and the best source I have for that is just 'Research of so-and-so, descendant of so-and-so'. When possible I bolster that with census records, but that is not done on all of them. --Janiejac 22:26, 17 April 2010 (EDT)

I have to agree with whoever told you that it is better to get it uploaded and to let it go undone. The beauty of WeRelate is the collaboration. You don't have to have every fact for every person and you don't have to have everything with the "best" source available. Nobody can do that. The key, in my opinion, is to get the data out there. Share what you have and allow others the opportunity to benefit from your work and, in turn, give yourself the opportunity to benefit from what others know about the people in your GEDCOM. -- Amy 22:57, 17 April 2010 (EDT)
For what it's worth, the system should import people with a birthdate prior to 1900 even if you have nothing in the d/o/d field. And you can keep the Co. on the county names; the system should still be able to match them to counties. Try uploading it - you can review the result in the GEDCOM review program before any public pages are created. If it looks too daunting you can remove it and try again later.--Dallan 17:27, 27 April 2010 (EDT)

I decided I needed to see a descendancy chart to determine what bits and pieces I had already uploaded. Not having used FTE before, I thought that would be the way to get such information. After reading the tutorial, I still couldn't get the descendants to show up. Jillaine was good to tell me how! But now that I see it, I still can't print it. And the person numbers don't show so I still can't get a good printed descendancy chart of what I've input to this particular tree. Very frustrating. I want this to work, so I'll be back when I can work up a new supply of patience. --Janiejac 15:21, 7 June 2010 (EDT)

I'm sorry -- you're not going to be able to print the FTE screen. The best thing would probably be for the system to generate a descendancy chart as a report for you, similar to RootsWeb: here's an example. RootsWeb shows up to 10 generations on the same page, which can result in a very long page. I'm thinking that 5 generations per page would be do-able. What would you think about that?--Dallan 16:00, 7 June 2010 (EDT)
That would be excellent! Just what I need! Will be even better if it will include the person numbers. Is this something I can generate whenever I need it or would I need to request it now and then? I can forsee a continuing need for this as I work toward uploading different sections of my database. --Janiejac 16:56, 7 June 2010 (EDT)
I'm thinking that there would be a menu option on the Person & Family pages that would generate the report whenever you needed it. And that the index numbers would show up in printed reports, but would be hidden on screeen. Would this work for you? If so, would you please add the descendancy chart as a request on the WeRelate:ToDo List? Thanks.--Dallan 23:29, 7 June 2010 (EDT)
I added a descendancy report request to the ToDo list under updating the person & family pages since that is where the option to print it would be. Also suggested an option to toggle on/off the index numbers both for viewing and printing. --Janiejac 01:27, 9 June 2010 (EDT)
I'd like an update on the possibility of printing the above suggested descendancy chart. I still see the need for such a chart, but I don't know when the ability to print a descendancy chart might happen. Is it still in the plan? --Janiejac 18:43, 9 November 2010 (EST)
Development has been slow on WeRelate lately, unfortunately. I'd suggest that you export a gedcom and print the descendancy chart in a desktop genealogy program.--Dallan 16:12, 10 November 2010 (EST)

Duplicate sources, ending scroll lists [27 April 2010]

I have been trying to convert MySources to Sources and am finding duplicate book sources that often differ only in repository. Can these be combined? Also the scroll list often ends with "more not shown". For instance Miller, John can only be got at by using the more time consuming Find function. Will it be or is it possible to type in Miller, John? Presently the box dies with that in it and then one has to go to the Find. FYI, in the case of Miller, John the full WeRelate source is Miller, John. Twentieth Century History of Erie County ... etc.--HLJ411 10:37, 23 April 2010 (EDT)

Once you have done the Find the first time, it should be possible to determine the smallest string necessary to bring up a short list including the title desired. For example, in this case, simply adding the period, i.e., "Miller, John." is sufficient to narrow the list to the exact title you want. In my experience, if you are working on a family, it is also usual to refer to the same source over and over, so some form of cut and paste can be useful.
In regards to duplicate sources, it is possible to combine the pages but it is tedious work. It often involves following links for the FHL repository to determine if the sources are actually the same, or different editions, etc., comparing pages and copying data to get one complete page, possibly updating links so that nothing points at the other page (though this last is not strictly necessary), and finally adding the redirect and speedy delete directives. --Jrich 11:44, 23 April 2010 (EDT)

"miller, john." doesn't work but "Miller, John." does. The scroll function is case sensitive! Now that I know that, life has just become easier.--HLJ411 12:00, 23 April 2010 (EDT)

Someday we'll have a function to semi-automatically merge duplicate MySource's into Sources. At that point it should be a lot easier to merge them. I wouldn't worry a whole lot about it until then, because I agree that currently it's tedious work.--Dallan 17:30, 27 April 2010 (EDT)

Image Page - request [25 April 2010]


Would it be possible to add an "e-mail option" to the Image pages? So after a WeRelate User uploads the Image to the Image page we can e-mail a link to that Image page to the interested relatives? Thanks, Debbie Freeman --DFree 10:55, 25 April 2010 (EDT)

Hi Debbie, you can e-mail image pages by going to the image page, clicking on More, then on E-mail this page. --Jennifer (JBS66) 11:01, 25 April 2010 (EDT)
Hello Jennifer, Thank you I forgot. Too well hidden for early morning. Debbie Freeman --DFree 11:30, 25 April 2010 (EDT)

Suitablity of Material [1 May 2010]

Moved from Solveig's talk page: Solveig, I have created a new user page and want to ask if you think this is acceptable to WeRelate.

  1. I made it a user page because I wanted a page that cannot be edited. I transcribed these typed pages of Mr. Andrea's work because the condition of them was so poor, I could not use OCR.
  2. As far as I can tell, this has never been published. It was work Mr. Andrea did as a professional genealogist in 1949 and was given to his clients. When he died, his family gave all his private papers to the University of South Carolina which allowed LDS to film the papers. I cannot find these particular pages anywhere in the LDS catalog, but obviously someone was able to find them and copy them.
  3. I have no idea of who originally copied them. These 57 pages had obviously been copied many times. I laboriously transcribed and proofed them, hoping to be able to share this info.
  4. This 1st page was just a trial to see how much editing would have to be done. If it is acceptable I'll need to edit the title.
  5. Also wondering about the length of the user page. What would you suggest for an article that was originally 57 typed pages???

Here it is: User:Janiejac/Andrea--Janiejac 00:36, 23 April 2010 (EDT)

This is a difficult one. Given the dates involved, I'd say that the work is under copyright. I looked it up in the LDS catalog; possible matches are here and here. Since it's under copyright, I think you'll need to ask for permission to publish it (from either South Carolina or from Connie Andrea?), unless you want to publish just a synopsis of the facts.
As for the format, if you're able to publish the entire document, I'd suggest creating one user page for each page of the document, then linking to all of the pages from a "master" table-of-contents page that contained links to each of the individual pages.--Dallan 15:41, 27 April 2010 (EDT)

And I would ask: what is the purpose of this set of pages? And when you're clear on its purpose, then ask "What is the best way to present this information for this purpose?" My $.02 after a long hibernation. Jillaine 17:41, 27 April 2010 (EDT)
Hi Jillaine, You can add your $.02 to anything of mine just anytime. I have missed you. About the Andrea papers - he has researched so many original documents that I thought his material should have a wider audience. It would be time consuming, but I thought the names he mentions could be links to person/family pages that eventually someone would flesh out with more recent research. Just sort of a fun project as a break from working on my own line.
OK, I just wrote a second email to folks at the college asking for permission to post my transcription here at WeRelate. The earlier first request got no response. Since these papers were never published, there is no monetary value going to the descendants or to the college. I don't see any reason they should withhold permission but I may not be able to get through to whoever has the power to give permission. LDS was allowed to film them and that's how I got them, but they say they don't have authority to give me permission to post them anywhere!

Sorry, Solveig, I probably should have put this on the watercooler, but I didn't think it had community interest. --Janiejac 18:20, 27 April 2010 (EDT)

No problems. But, I will put a copy on the watercooler. My $.02 is...generally, work for hire belongs to the person who paid for it. But, I don't know what the contractual relationship with the genealogist was and my bet is that the University doesn't either. I know facts are not copyrightable but sometimes particular sets or arrangements of facts are--such as a phone book designed for Chinese businessmen. This area of copyright law is a quagmire. Everyone posting on WeRelate has to decide if the material is postable. As a policy, we remove material if anyone complains. This probably doesn't help. Sorry.  :( --sq 22:51, 30 April 2010 (EDT)

Janie, there are probably a number of ways to approach this. Creating an article would probably entail the "Fair Use" criteria: fair use being the right to use portions of copyrighted materials for purposes of education, commentary or parody. That would probably not legally permit a complete transcription though. The "Educational Fair Use" guidelines apply to material used in educational institutions and/or for educational purposes. Examples of educational institutions include schools, colleges, universities, libraries, museums, hospitals and other nonprofit institutions; or use within and for nonprofit instructional, research, or scholarly activities for educational purposes. That use might permit complete transcription without permission.
Rather than risk having someone mistakenly assume you are taking credit for a previously published work and presenting it as an original work (or as a User Article), or possibly arguing for educational fair use, if you are intent on transcribing and sharing it, why not do it as a source reference, citing any publication data and appropriate copyright credit as a legitimate source document. That might solve your dilemma. --BobC 23:32, 30 April 2010 (EDT)
The only reason I thought about putting the transcription on a user page was to be assured that someone wouldn't try to edit Mr. Andrea's work. I am hesitant to think about a source record being spread over 57 pages. So is there a 'DO NOT EDIT' template that could be put on each page? I don't know how to create one. --Janiejac 01:03, 1 May 2010 (EDT)
If you added a highlighted DO NOT EDIT to the text, at the beginning and end, people would probably respect that. The benefit of having it editable would be that others may be able to assist in the transcription and add pages to the document, so you wouldn't have to do it solo.
But if you want complete editable control, I suggest you continue transcribing the document in your User Page where it can't be edited by anyone else, then create a Source page (or a MySource page) with the Source Information, Coverage, and Repository information for the document (i.e. book), then add {{User:Janiejac/Andrea}} in the Text block, and you have your protected source page. Let me know if you need help creating it.
Good luck. --BobC 01:58, 1 May 2010 (EDT)

Did you know - suggestion [24 May 2010]

On the latest "Did you know" on the main page. If you add your User name in the Keyword area it will only bring up that WeRelate Users additions. Otherwise the list could be very long to search. Just a suggestion. Debbie Freeman --DFree 14:33, 19 May 2010 (EDT)

Hi Debbie, actually in the instructions in the Did You Know section, it includes the following: check the "Watched" box at the top, which would do the same thing that you are suggesting to list only pages that are being watched by a particular user. Hope that helps. - Best regards, Jim --Delijim

Hello Jim, Thank You for the reminder. Also it helps to sign in too before you search I have found too. A difference in the screen shows up that way. Debbie Freeman --DFree 21:05, 23 May 2010 (EDT)

New look for WeRelate [15 June 2010]

I've been working on a new "look" for WeRelate pages, especially person and family pages. It's on the sandbox right now (here's an example page). If you get a chance, please take a look at it and let me know what you think. If people generally approve I'd like to update the main website at the end of this week, at which point all pages will automatically adopt the new look.

Here are the changes:

  1. Person, Family, Source, MySource, and Repository pages have infoboxes containing the information that has been displayed down the left-hand side. Infoboxes are coming soon for Place, Article, Image, Surname, and Givenname pages.
  2. Source and MySource pages display an automatically-generated citation. The citation is generated from the data in the source infobox. This citation is also displayed on Person and Family pages that reference the source/mysource. Eventually you'll be able to override the automatically-generated citation with your own citation text, but the default should provide a reasonable citation for people who don't want to go to the trouble of entering their own.
  3. I've changed the page background slightly - removed the blue shade and added a grey border. I've also changed the website font.
  4. Source texts and notes are displayed in a monospaced font that respects user-entered spacing and line breaks. This means that if you enter notes with rows and columns of data separated by multiple spaces and line breaks, the columns should line up when displayed on the page.

This last change is to accommodate people who want to import gedcoms with lots of row-and-column style notes. The monospaced font does make the notes look less "pretty" however, so another option might be to use the monospaced font only on text surrounded by <pre></pre> tags. Having to enter <pre> tags for every note where you wanted the rows and columns to line up might be inconvenient for gedcom uploaders however. Thoughts?

Hopefully you will like these changes, but it's very possible that there needs to be a bit of tweaking. If you have suggestions for improvement, please leave them here.--Dallan 09:36, 20 May 2010 (EDT)

I really like the changes! There are a couple of very minor things I'd tweak, like adding some sort of small divider between the parents and the children in the boxes, just to make it more obvious. But the timing could not be better -- I'm finishing the syllabus for the session at FGS in Knoxville. It will be great to have the latest screenshots in the syllabus! ~~ Amy 10:20, 20 May 2010 (EDT)
I'm so glad you're working on this! I do like the new look! I have a comment and a concern. The comment: the area on left for list of watchers is taking up more width than most names will need. Couldn't some of that width be better used by the center section where the text is?
I too am wondering about the watchers section on the left. The watchers, to me, seems like secondary information that perhaps could be placed more compactly elsewhere on the page. What if, instead of listing the user names vertically, they were listed horizontally, separated by a comma, at the bottom of the page. Then the ads could be moved to where the watchers are now. The page would become 2 columns instead of 3, leaving more room for the actual page contents, which is primary. The content would also flow with less visual disruptions, fully to the right of the screen.--Jennifer (JBS66) 11:58, 20 May 2010 (EDT)
And my concern: I have been requesting line breaks for my notes which contain census transcriptions. But what I call notes may not be the same as what you call notes. I'm concerned that when I upload the GEDCOM, my 'notes' are going to go in the personal history window, not in the window WeRelate calls Notes. So using this monospaced font in the Notes may not accomplish what I hoped for my census transcriptions. Sorry for the confusion, but my PAF calls the text I write about the person 'notes'. The census transcriptions are interspersed with regular text so is not practical to separate them out. Perhaps I'll just have to accept that census transcriptions are going to be all run together. --Janiejac 11:46, 20 May 2010 (EDT)

This is very nice. Much cleaner look. I agree with the comments about the watch list. Can they go under the ads? Can ads and watch list both be on the left? I see that the page title is a little smaller, but it's positioning still makes it grab the eye. Can the page title be moved, maybe to the blue bar? maybe to go under the menu items? I just spent the afternoon with another new user and it is very hard for them to let go of the "incorrect name". The page title needs less prominence. The box with the name and dates is great. Can birth and death events now be sorted chronologically with the other events? There is no reason to keep them out of the sort order, is there? It is really great to be able to see the events in the middle of the screen now. Someone might actually notice them. The column format for events looks really nice. --Judy (jlanoux) 18:30, 20 May 2010 (EDT)

Awesome! The first few things that come to mind:

  1. Agreed that the watchers on the left are a waste of space. Watchers only appear on the page so that people can find out the information if they want, it's not actually important information. How about putting the parent/child boxes on the left and the watchers underneath them?
  2. The source citation format is incompatible with the current naming rules for vital records and other geographic records, because it exacerbates the fact that we shoehorned both the vital records and the book records into rules using the same fields. For example, under the correct naming, the California death index will have "Source:Death Index" at the top of the page, which is less than helpful, but the citation will be right. If someone has put the place back into the title field (or it is still there as an artifact from the source conversion; common with census records, and keeping it there improves search results), then the "Source" line at the top of the page will be better, but the citation will be odd. See here for an example of what I mean.
  3. I'm not sure I think the order in the middle column makes sense. See George Washington, for example. Narrative -- which may end with 'bottom of the page' elements like the WP notice and templates, then facts, sources, images, then whatever has been placed at the bottom by code (most of the navigational templates). I think having the facts below the narrative might make some sense in light of the birth/death at top, but it's awkward to have the facts section between the narrative and the sources, and to have the information effectively floating between other elements. It wouldn't be repetitive if you just omitted the birth/death from the top bit (and put sources in the top part) and only generated it if there were other facts.--Amelia 21:20, 20 May 2010 (EDT)

  • I'll add my voice to the chorus about the watchlist. Either at the bottom or even as a "More" function so only when you want it explicitly. There already is Watch and Unwatch which gives you your own status which is all you really need most of the time. Hopefully the Personal History could get the bulk of the freed up real estate.
  • Marriage date is hard to find. Would like to see it part of the Spouses and Children infobox and in the main infobox on the family page.
  • Dislike forcing notes to fixed width font. Mostly ugly and very few notes actually do anything that needs it.
  • If the husband, or wife, doesn't have a Person page, the infobox on a the Family page is half blank. The infoboxes on the person's page just list one spouse. Can it default to the name in the page title if there is no Person page created? For example, look at Elizabeth Kendall, which in the sandbox has two marriages and neither husband had a Person page. --Jrich 23:46, 20 May 2010 (EDT)

Looks like most of my concerns back in the sandbox page has already come up but here tis...

Not sure if you monitor each page in the sandbox or not...

I don't monitor any page in the sandbox.--Dallan 02:15, 22 May 2010 (EDT)

I do like your new format. It puts the normal facts very neatly in what appears to be the "main page" of the presentation rather that a side bar. I would still like my ancestor page to have a readable text for the members of my family who don't do genealogy. By this means, I hope to interest someone in the next generation to continue the effort.

Specific comments on new format: 1) I think the "Watchlist" should be placed at the end of the "main page" perhaps after Sources.

2) Once the Watchlist is moved, then the left side column could be eliminated for more room for the "Main page"

3) on the Family page, the facts would look better above the added Text Description box.--B.holmes 08:31, 21 May 2010 (EDT)

Don't know if others are experiencing whatI am seeing, but nearly every page I have viewed has errors. Overlapping text, failure to load images, etc. The George washington page mentioned above contains the following:

    Error creating thumbnail: convert: unable to open image `/srv/www/htdocs/w/images/2/2e/George-Washington.jpg': No such file or directory.

This textis dispalayed on top of the beginning of the narrative.--Scot 11:45, 21 May 2010 (EDT)

Thank you for the comprehensive feedback!

  • Regarding the space on the left, I'll reduce it. (I'll reduce the size of the logo at the same time.)
  • Regarding the page title, I'll make the page title and the vertical space that the page title sits in smaller. My concern about moving the title out of this space is that for some pages (this page for instance), it's the only place where the title of the page appears. So I don't want to make it too unobtrusive.
  • Regarding moving the watchers, I agree that the watchers are in too-prominent a position right now. They need to be moved elsewhere. Listing them in the left-hand colum or the right-hand colum but hiding them under a "More" menu seems like a good idea, or listing them toward the bottom of the page say just above the categories.
  • I'm not sure about getting rid of the left-hand column. I need to think about that more. I've been thinking that at some point in the future I would move the search box, the edit, history, rename, etc links, and add a few additional menu options into the left-hand column (similar to the effect you see on facebook.com). Maybe I should try that now to see what it would look like.
  • Regarding notes, notes in PAF that are attached to the person and not to a particular event will be added to the Person page text, and yes, you're right, they won't (by default) come out in monospace font. You'll need to surround those notes with <pre> tags to get them to display in monospaced font (sorry). I'll tweak how <pre> text is displayed so it looks a bit better than it does now. Also, based upon the feedback I'll go back to normal (non-monospaced) font for event notes, and let you use <pre> tags to put the notes you want in monospace font.
  • Regarding sorting birth and death events chronologically, I'll do that.
  • Regarding the source citation format, the rule that I'm using lists the citation in author. title format if there is an author, or place. title format if there is no author and it is a government record. The title used in the citation is the title field, not the source page title. I think this results in acceptable citations. We removed place from the title field during the source renaming project, so for California deaths, the title field might be "Death Index" and the place covered might be "California, United States", resulting in a citation of California, United States. Death Index, which seems reasonable to me. The Source page title is not actually used in generating the citation. The sandbox has pre-source-project sources; the post-source-project renamed version of the source in this wiki will generate a place. title citation without repeating the place.
  • Regarding George Washington, 'bottom of the page' elements, and facts separating narrative from sources, I'm not sure how best to address the issue you're talking about. Certainly the 'bottom of the page' elements like the wikipedia notice belong under the facts+events, sources, images, and notes sections. I'll fix that. I think it's helpful to have birth and death events listed prominently in the top infobox. I don't think it makes sense to list the facts+events section below sources; facts+events will often reference sources, just like the narrative, so it seems that they need to go above the sources section. I could omit the facts+events section if it includes nothing other than the person's primary name and their birth and death information, so long as I add gender and source references to the top infobox (which will make the top infobox a bit busier). What do people think about this? Would it be confusing to have a facts+events section on some pages (when there are additional events) and not on others?
  • We could put the facts+events section above the narrative section. What would people think about this?
  • Regarding marriage date, I was wondering if it should be listed in the family page infobox. It's not listed there in Ancestry trees, so I didn't list it. I'll add it.
  • Regarding missing spouses, I'll default to listing the name that appears in the family page title in this case.
  • Regarding missing images, none of the images in the sandbox exist. I copied the page texts from this wiki without copying the images, which is why you're seeing the errors. Please try to ignore them - they won't appear on the main wiki.

--Dallan 02:15, 22 May 2010 (EDT)

General response:

  • LIke facts+events above narrative.
  • Like gender and source in the top box in return for no box if it's just a repeat. I don't think that's confusing.
  • How are you going to put the WP template at the bottom? (I mean, I know how it can be done, I'm wondering how that's going to work in the future if it can't just be resolved from the source template.)--Amelia 02:46, 22 May 2010 (EDT)
Currently I'm injecting the events, sources, etc. in the page where the <show_sources_images_notes/> tag is. But I'd like to change this in the future -- see the discussion below.--Dallan 15:10, 3 June 2010 (EDT)

Specialized source issue that's hopefully minor, so if we want to move it somewhere, fine, but I just want to clarify. My main issue is actually with the title format of the Source page itself, which promotes the "title" in a way that won't make sense for many vital records. But with regard to the citation display, what you're saying is that you're defaulting to using the fields instead of the page title. But the format you're using is exactly what is now used to create the page title. So there should be no difference. I'm wondering why it is necessary to make the change because where there *is* a difference, I think the title is more likely to come up wrong. I mean, the page title follows particular rules, and we went to a lot of trouble to come up with a standard format, including standardized case and capitalization, and I'm missing what this new idea gains. What it's going to lose is the proper display of any sources that have non-standard titles. This comes up in my own experience with census records, which I have left/added places to in a number of cases because they are easier to find in search that way, and I fully understand that my non-standard experimentation deserves to get broken if there is a greater good. But I think that it's also possible that all manner of people tinker with title fields more than they do with the page title itself, so I wanted to point out the issue.--Amelia 02:46, 22 May 2010 (EDT)

I'd like to call out this in a separate sub-topic below.--Dallan 15:10, 3 June 2010 (EDT)

Here are my thoughts on the questions Dallan posed:

  • I think the Facts and Events section should go above the narrative. It acts as a synopsis/entry point into the narrative.
  • I think it would be confusing to have a Facts and Events section on some pages and not on others, especially if we move the F&E section to go before the narrative. I wouldn't add sources to that top box; personally, I like the "cleanness" of the top part having just the dates and places of birth and death. You can tell at a glance whether this is the person you might be interested in. To me, it's like the headline and sub-headline on a newspaper article -- you don't expect all of the info to be in the headline, just enough to let you know if you might be interested in reading the rest.

I second Jrich's idea about adding the date of marriage to the Spouse and Children box. I'd also like to see it added to the Parents and Siblings box. -- Amy 09:27, 22 May 2010 (EDT)

I pretty much echo Amy's thoughts. I like the name, birth, death box - clean and simple. WRT Citations: I hope the custom citations appear soon. Whatever you do with the machine-generated ones is going to have problems. Especially since people mangled the title field to avoid redundancy in the page title. So I wouldn't spend much time tinkering with machine rules. Whatever you fix will break something else. Allowing manually created ones is the real answer. Re: position of the narrative box. If it comes below the Facts/Events the pictures and nice display formats that people have worked on will be hidden. It's not a big deal for me, but a half-vote for Narratives then Facts/Events then Sources. --Judy (jlanoux) 11:35, 22 May 2010 (EDT)

Judy, do you know how to use the pipe and/or the narrative box to do your own citation formats? What tools do you need for the custom citations you want?--Amelia 12:09, 22 May 2010 (EDT)
Yes, know how and do use it. But this is a very labor-intensive process. The proposal was to store citations with the source record so the user could choose. We would then only have to construct it once. We could also store various flavors for reprints, etc. and beginners would benefit from seeing how the source should be cited. --Judy (jlanoux) 13:23, 22 May 2010 (EDT)
I'm probably in the minority, but in my opinion, this worry about custom citations is misplaced. First, I don't think everyone would agree to the same citation style so if you add it to the source page, somebody else might want to change it. After all there are 6 major bibliography styles not counting ESM, which in my opinion is such a mass of rules it's nearly unusable. And I certainly don't like the idea of everybody doing different custom citations. That could be a zoo. The purpose of the citation is to tell someone where the data came from. I thought the old system did this adequately, I think the new system does this adequately. There are so few times when a basic bibliography style entry won't work, that when it happens, it seems better to add the information free-hand to the text box rather than give up the benefits of uniformity. --Jrich 23:04, 22 May 2010 (EDT)
I'll go along with Jrich on this one.--GayelKnott 23:33, 22 May 2010 (EDT)
Seconded. After the fights on merely naming the pages, holy cow this sounds frightening. There's already absolute flexibility and lots of software that will save and past custom formats for whoever wants it.--Amelia 01:22, 29 May 2010 (EDT)
Let's start out using the automatically-generated citations, and see when and how they fail to deliver good citations. Then we can see if improvements to the generated citations are needed vs allowing people to generate custom ones.--Dallan 15:10, 3 June 2010 (EDT)

I'm not sure if this is something that is just because it's in the sandbox, an anomaly with this particular person, or if it shows what will happen when the new design is implemented. The narrative portion seems to reflect the entire GEDCOM import rather than how the narrative was displayed on the old page. Compare Allen Trimble (1) as he appears on WR now with how he appears in the sandbox with the new design. The sandbox version includes the GEDCOM tags in the narrative and lost the paragraph formatting. Also, look at the watchlist. There are 3 people listed on the current page and only 1 listed on the sandbox page. Like I said, I don't know if this is a sandbox issue, an anomaly in the presentation, or how it really will "translate" when the new design is implemented, so I thought I'd bring it up. -- Amy 12:01, 22 May 2010 (EDT)

The pages in the sandbox are about a year old. Allen's page in the sandbox is the way it was when it was first uploaded, but his page in the main website includes about a dozen edits performed over the past year.--Dallan 15:10, 3 June 2010 (EDT)

Agree with most comments about improved appearance of page. But would prefer to have narrative before Facts and Events, possibly because this is standard format for most general interest narratives, and for more scholarly narratives (especially if the narrative begins with the statement of a problem that needs to be resolved). Then the Facts and Events as a synopsis of what was said in the narrative. And if Facts and Events is there on every page, it's easy enough to scroll down if you don't want to read the narrative.--GayelKnott 20:38, 22 May 2010 (EDT)

I too agree that the Facts and Events box should follow the narrative. If users take the time and effort to compose and contribute to a person or family's narrative, then that should *preceed* the F&E. The Facts & Events should be supportive of the biography rather than the other way around. For those person and family entries that do not have narratives (which will be over 90% of the entries), then the F&E will show up first right after the name. I'd also like to see the photos and graphic images, if included, show up immediately following the narrative, rather than perceptionally as an after-thought at the end of the entry. --BobC 21:57, 22 May 2010 (EDT)

On the comments on narrative. A short narrative has a really nice "look" but I thing some of the longer narratives shouldnt push the events too far down the page.

Lets say the default should be to have the events above the narrative - would it then be workable to have wiki codes in the narrative box which allowed a small amount of text etc. to be "moved" above the narrative ? - for advanced use only so to speak.

Otherwise I think the changes are excellent have a lot of appeal, and will make the site appealing to people who are used to "other" genealogy sites--Dsrodgers34 20:05, 23 May 2010 (EDT)

I like it. I checked out some of pages and the images did not work in the new format. I don' know if this is an error or just that they are temporarily inaccessible from the sandbox.

http://sandbox.werelate.org/wiki/Person:Henry_Becker_%285%29 Error creating thumbnail: convert: unable to open image `/srv/www/htdocs/w/images/d/d1/Henry_Becker_1880.jpg': No such file or directory.

http://sandbox.werelate.org/wiki/Person:Charlotte_Becker_%288%29 Error creating thumbnail: convert: unable to open image `/srv/www/htdocs/w/images/c/cd/Illinois_State_Archive_Luetgert_Death_2.PNG': No such file or directory.--Srblac 22:05, 25 May 2010 (EDT)

I didn't download the images when I downloaded the pages last year. I've downloaded them now, so they should show up.--Dallan 15:10, 3 June 2010 (EDT)

Re: narrative and advanced layout coding. Why does the presidents template screw up Barack Obama but not George Washington? I think I slightly prefer having the template be all the way at the bottom but if a page happens not to have show-sources-images-notes, it should not force the page content down like the Barack content does (although that page does have that code, so it's curious).--Amelia 01:22, 29 May 2010 (EDT)

I've fixed this on the sandbox: The Template:USPresidents had a "clear: both" style in it. The family infoboxes are "float: right" so they get right-justified and text floats around them. The "clear: both" directive in the Template:USPresidents tells the browser to position the template below floated elements, which is why it got pushed to the bottom of the page (below the family infoboxes). Removing the "clear: both" from the template fixed the problem. Once the new "look" is moved over here we'll need to review the templates that have "clear: both" in them to see if we really want their content pushed below the family infoboxes. It looks like there are about 50 templates to review.--Dallan 15:10, 3 June 2010 (EDT)

I know I haven't been around much; I'm trying to "catch up". Just wanted to add another $.02 to the chorus of approval for this new look. I really really like it. And it seems like you all are working out the details pretty well. Nice work, Dallan. Jillaine 09:30, 30 May 2010 (EDT)

Newer new look [9 June 2010]

It took longer than I expected, but I have version two of the new "look" on the sandbox. I believe this version addresses all of the issues that people requested above. The only thing missing is that I haven't yet created infoboxes for articles, images, places, and names.

This new version includes several changes in addition to the ones mentioned above:

  • The top menu looks more like the menus on gmail.com or youtube.com
  • The left-hand sidebar is about half as wide as it used to be.
  • I've moved the page actions to the left-hand side. This puts them closer to where most people's eyes focus when they look at the page, and it will give me room to put additional items in the menu over time.
  • The watchers are now displayed only on demand, when you click the "show watchers" link.
  • I've added a little timeline "eye candy" to the right of the facts and events list
  • You can use an <events/> tag to display the list of facts and events anywhere you like on the page.

I'd love to get feedback about this new version and also comments on the two topics below. I'm hoping to post the new look (very) soon, and start thinking about how best to address the topics below.

I like the "newer new look"! Having the left-hand menu shrunk really helped the rest of the page. I also like the move of the menu items to the left-hand column. The only thing I'm not crazy about is the timeline "eye candy." It doesn't add any useful information and I thought it made the events area rather cluttered. Eye candy can be good, but not when it detracts from the stuff around it. -- Amy 15:33, 3 June 2010 (EDT)
This is great. Really like it. (I could go either way on "eye candy".)--GayelKnott 16:44, 3 June 2010 (EDT)
I like most of the list above. Think the eye candy is a little confusing, but don't feel strongly about it. A few issues found while browsing --
  • Some pages just don't load on my Safari browser, i.e. [6], [7]
  • I think the parent/child info box is a little overwhelming when there are lots of children. It's like the opposite of the clean and simple box on the person page. I'm not sure the children should be in the box, actually - they could easily be in a table below that's not blue - but if they are, I think the formatting needs to be more ... overt, I'll say, having some familiarity with the pain of coding tables. Right now the numbers throw off alignment of the names, the data wraps in the middle of the place name if you don't use the full screen width (which I never do because I'm always dealing with other windows at the same time), and the center alignment for the children's dates is kind of chaotic.
  • A side effect of the auto-generated citations is that there's no indication when something is a MySource. I'm not sure how I feel about that, but I thought I would throw it out there.

--Amelia 02:01, 4 June 2010 (EDT)

I noticed a few instances where the marriage order listed under Facts and Events does not match the order for the infoboxes on the right. Douwe Johannes and Albert Brien. I also wonder if we need the primary name under Facts and Events, since it already appears at the top of the page. --Jennifer (JBS66) 20:31, 4 June 2010 (EDT)

Thank-you for the feedback. I'll:

  • remove the timeline eye candy. I wasn't sure I liked it either, but thought that I'd at least see what others said.
  • fix those two pages not displaying. (They don't show up in firefox either.)
  • move the children from the Family page infobox to a separate table in the content area. I'll try it out as a "Children" table just below the "Facts and Events" table, and I'll add a <children/> tag so that you can position it elsewhere if you like. I'll also left-justify the birth and death information in the table columns, and I'll look into putting the birth/death places on a new line under the dates so they're less likely to wrap.
  • re-order the spouse and family infoboxes so they match the marriage order listed in the table.
  • remove the primary name from the "Facts and Events" table.

I don't know how I feel about not distinguishing between Source and MySource in the citation table either. I'll leave it alone for now. --Dallan 15:29, 7 June 2010 (EDT)

Dallan, I'm not sure if you've finished the new look for place pages yet but... the map placement doesn't really seem to work. See Ferwerderadeel for an example. When the map is placed in that blue box, it can actually be larger than the box, making the infoboxes underneath it move awkwardly. --Jennifer (JBS66) 15:23, 9 June 2010 (EDT)
Thanks for pointing that out. I fixed it.--Dallan 22:59, 9 June 2010 (EDT)

Footnotes, Sources, Images, and Notes [7 June 2010]

If you don't want facts and events listed at the bottom of the page (the default behavior) you can add a <events/> tag to put them anywhere you want on the page. You can also add a <show_sources_images_notes/> tag to display sources, images, and notes (and also facts if you don't have a separate <events/> tag).

If you want to cite footnotes in the text on the page, you can use the <ref> and <references/> tags to do this. For example, this page on the sandbox contains both text footnotes and source citations.

I'm not really happy with how sources, images, and notes are separate from text citations. Why can't I type <ref name="S1"/> in my text narrative to cite a Source? And when I put the <references/> tag on the page, why doesn't it list my sources, notes, and maybe images as well in the same section?

What would people think about combining footnote references and sources, notes, and maybe images, so that they all show together in a single numbered list when you add the <references/> tag on the page? (And if you didn't have a <references/> tag on the page, the system would inject one for you automatically at the bottom of the page, just above the wikipedia-notice template.)

Regarding images, I'm thinking that images of scanned documents that are cited by events or sources probably belong in the references listing next to the sources to which they apply. But general photos and other images not tied to a fact or event probably belong in a separate image gallery section, and that the system could inject a <gallery> tag for images not tied to any event.

--Dallan 15:10, 3 June 2010 (EDT)

I continue to think it's kooky to have the narrative then facts and events, but it's especially bizarre when there are footnotes. (For example, I think this looks much better with the events up top.) One of the reasons to use footnotes over just citing S1 is that it's a lot easier to repeat cite to different pages with footnotes. Both the data entry and the display for sources are a little kludgy in doing that. Also, it's more flexible on pages like Ella Gray where the footnotes are notes instead of citations. But overall I think it's all distinctions without difference and it would be really cool - and less cluttered - to have one list of sources, text references, and "notes." I don't think images should be in that list, even if the go with a source - the formatting would be a mess. Maybe an icon linking to them or something (since the thumbnail usually isn't useful anyway)?
Other related thoughts -- 1) the "primary" photo right now is super (too) small up top, and then duplicated at the bottom. I assume the latter is because of the former, but I think it looks like a mistake when there is a short narrative and you can see them both at once. And it exacerbates the issue with the bottom of the page looking strange. 2) Stemming from the same thought, does it make more sense to have images go before the sources and notes? That seems a more natural flow (but if the primary image keeps repeating, it would look even more silly on pages with a short/no narrative). 3) In the course of this drastic redesign, particularly if you do this combined source list, can we please have some more space for the source title on the data entry page? It's just impossible right now to tell sources apart unless they are all books with different authors that you recognize, leading to the above issue where footnotes are far easier when repeat citing. Dealing with specialized citations using that field would also be super annoying.--Amelia 01:37, 4 June 2010 (EDT)

  • I agree that especially for a long narrative, it looks odd to have the facts way down at the bottom of the page. But I also know some people who have spent a lot of time developing their narratives who would be upset to see their narrative get pushed down so that it is no longer "above the fold" (visible without scrolling). Hopefully the <events/> tag gives everyone flexibility in where the fact and event table is positioned.
  • I'll combine the sources, notes, and references into a single section.
  • Images that are linked-to from facts and events will be displayed simply as icons in the sources section. If you hover over the icon you'll see a larger image; if you click on the icon you'll be taken to the image page.
  • I'll remove the primary image from the images section.
  • The remaining images (not linked-to from a fact/event, not primary) will display in an "Images" section that will be by default just before sources/references, although you'll have an <images/> tag that you can use to display the images anywhere you want.
  • I was thinking that I'd focus on improving the data entry pages later, but I'll make a quick fix to widen the source title field.
  • As for the size of the primary image, I don't want to make the person infobox much larger than it currently is. How about if I add a "hover" capability to the primary image as well, so if you hover over the primary image you'll be able to see a larger image.

--Dallan 15:29, 7 June 2010 (EDT)

Source Citation Format [5 November 2010]

Amelia makes a suggestion above that we use the source page title in place of the source title field in the automatically-generated source citations. Currently the automatically-generated source citations use the source title field, preceded by either the author(s), or place covered (for Government/Church records). I've thought about her suggestion over the past week. Using the source page title in the source citation, instead of the title and author fields, appeals to me because it means that maybe we could get rid of the source title field altogether, which would eliminate an area of confusion. But it requires addressing a few issues:

  • Source page titles for multi-author books only list the first author, whereas the source citation includes the first two authors (plus et al. if there are more). We would need to rename source page titles to include additional authors.
  • When someone exports a gedcom, the source in the gedcom needs to have separate fields for title and author. The system would have to be smart enough to remove the author(s) / place covered from the source page title when adding the source to the gedcom.
  • Would we ever want/need to distinguish two sources with the same author and title? (Radically-different editions of a book??) If so, using the source title field for the citation allows us to append additional information (like distinguishing publication information) to the source page title without badly affecting the citation.

I'd like to get people's thoughts on this.--Dallan 15:10, 3 June 2010 (EDT)

Wow, I didn't understand Amelia's comments to be recommending that we use Page Title in source citations. If that's what she meant, I didn't get it.
Either way, I do NOT recommend such a change. We already know that PAGE TITLEs must be unique and therefore cannot always match the real title of whatever the source is (when there is the same name for more than one source).
Expected behavior by most researchers is going to be that a citation is derived from the specific fields, including Author and Title. Creating a different way to do citations from the standards that most genie programs would generate citations is um, in my mind, just plain wrong.
If I'm misunderstanding something, please clarify it for me.
Jillaine 15:37, 3 June 2010 (EDT)

As Jillaine said, researchers would tend to expect the automatically generated citation to be pulled from the fields, not the page title. Along those line, I'd like to request that automatically-generated citations for sources that have an author include the author, even it it is a geographically-based resource. If the goal is to have a "standard" citation, then it would need to pull the elements of a standard citation, which would be the author/editor/compiler. In other words, I'd like the auto-citation to read "Wagner, Charles W. Inscriptions from the Old Baptist Cemetery West of Thornville and the Lutheran-Reformed Cemetery in Thornville" rather than Perry, Ohio, United States. Inscriptions from the Old Baptist Cemetery West of Thornville and the Lutheran-Reformed Cemetery in Thornville Personally speaking, I know that would reduce the sting of the page title of geographically-based resources not including the author. -- Amy 15:50, 3 June 2010 (EDT)
Auto-generated citations for sources that have an author include the author. The place is included only for Government/Church record or Newspapers without an author.--Dallan 15:29, 7 June 2010 (EDT)

I'm finding this discussion really confusing. First of all, I thought the automatically generated source citation was the Source:Page Title (as for example, "Inscriptions from the Old Baptist Cemetery . . . ").

Second, as someone has already mentioned earlier, the reason for a source citation is to allow other researchers to find the same source and verify what it says.

The format for source citations is determined by the publisher of the book, journal, website, or whatever, and can vary (sometimes drastically) from one publisher to the next. In other words, there is no one "correct" way to cite a source, although usually authors of published works are included in the complete citation as a means of granting credit (or blame) where due.

At present, there are two major fields on a WeRelate Person or Family page associated with a source citation. One is labeled "Title", which leads to the automatically generated Source:Title page. The other is titled "Record Name", which allows a freehand entry, which can include additional information if desired. I'm not sure what more than this is needed. If you want to reference a specific subset of the automatically generated "Title", then that information can be entered in the "Record Name" field. (For example, if there are several FHL microfilms for one parish and you want to cite one specific film.) Or, if you don't want to use the automatically generated "Title", you can put your full citation in the "Record Title" field (which is sometimes the easiest way to deal with manuscripts found only in a single archive.)

As for distinguishing between different versions of the same publication -- there are already a great many different Source pages for the same publications, either because an old edition has been republished (unchanged) or because it has been digitized, not because it is a second, revised, or otherwise changed edition. For some reason, these often seem to have resulted in separate Source pages. While I can live with this, the extension is that we should be citing the library where we found the book (and I've seen this done). But it seems to me that it would make more sense to combine all the information about different locations for finding what is really one source on the same page.

There are also Source Pages that really should be renamed -- like the "Inscriptions from the Old Baptist Cemetery . . .". And I can understand how someone dealing with hundreds and hundreds of source pages might make the occasional mistake, as well as I can understand how most of us would hesitate to change those pages.

In the end, I think it should really be about facilitating the exchange of information, and that includes keeping the automatically generated Source reference as easy to use as possible, for both people adding sources and for people trying to follow them through; and then providing the additional field to allow for additional information if needed. Pretty much the way it's already done.--GayelKnott 19:44, 3 June 2010 (EDT)

In the new format on the sandbox, the source citation is no longer being generated from the Source page title. It's being generated from the title and author (and other) fields on the page. Hence the discussion. "Record name" is still part of the generated citation as before.--Dallan 15:29, 7 June 2010 (EDT)

This discussion pretty much illustrates why I protested in the first place. We fought extremely unpleasant battles that left a lot of us ... ahem... highly irritated to get the source title rules to an agreed upon state. And now we want to revisit that battle to determine what "proper" citations are? Please, no. Not when we already have the tools we need to do any kind of citation one could possibly want, and when the rules for what constitutes a source page and what makes since for a wiki source are not necessarily compatible with a "proper" citation (which would require, for example, citing a reprint or a film instead of the original book, when neither actually has a page here).

But to backtrack to the request, my request was simply to leave things as they are and display the source page title as the default. There is no reason to get rid of the fields on the source page (although as a design issue, how the title is displayed is another issue). I think auto-generating citations takes effort better spent on other things, will generate another round of really irritating and obtuse discussions, and will more often then not by default be wrong (as in the 99% of FHC films that list the filming information instead of the book information) or misleading (conveying specificity of version and format that may not be accurate), and to the extent that it is inconsistent with the page titles, will negatively impact data entry usability.--Amelia 01:04, 4 June 2010 (EDT)

Ugh. Just shoot me, Amelia. I'm sorry. I'm having brain drain. You're right. When the Source PAGE Title is author. title it does generate a nice citation. However, as someone posted elsewhere, when it's: Place. Title. as in Scituate, Plymouth, Massachusetts, United States. Vital and Town Records of Scituate, Massachusetts, 1640-1847 it will NOT generate a nice citation. Jillaine 11:59, 4 June 2010 (EDT)
Using the source page titles for auto-generated citations would require additional programming and page-renaming (the three things I mentioned above). It doesn't look like there's enough support for using Source page titles in the auto-generated citations to justify changing it, so let's use the title and author fields for the auto-generated citations.--Dallan 15:29, 7 June 2010 (EDT)
I still don't understand why we couldn't leave well enough alone, but having lost that battle, can we do something about geographic source titles so we don't have this kind of incorrect and useless citation format? These authors are FHC's way of indicating authorship of town records, but their method is clumsy and duplicative and results in silly-looking citations. Can we have place.title back, please?--Amelia 03:02, 14 June 2010 (EDT)
If the authors are deleted from that source, the citation defaults nicely to Windsor, Hartford, Connecticut, United States. Records of Births, Marriages, and Deaths, 1638-1925. --Jennifer (JBS66) 13:06, 14 June 2010 (EDT)
True enough, but I'm wondering if there's something else to do other than fix them by hand. We already have to fix some large percentage of the books by hand as it is (because of the incorrect publication information imported from FHC).--Amelia 20:25, 14 June 2010 (EDT)
The FHLC sources tend to have bad publication information and authors. I can't automatically remove the authors because they're not all bad. I don't think there's anything I can do automatically to correct the publication information. It seems like thing to do is to remove bad authors and correct publication information when you see it. I've been talking to FamilySearch about cleaning up their FHLC sources (they ultimately want to generate citations from their sources as well), but I haven't made much progress so far.--Dallan 12:34, 15 June 2010 (EDT)

I'm late to this discussion but I just created a source page for a book and very dutifully filled in the citation window. After it was saved, I saw that now the source has two citations - mine and one that is apparently automatically generated. So I removed mine. But if the system will automatically generate the citation, shouldn't the window be removed or at least a note be there to indicate that I shouldn't put the citation in? I cannot remember all these rules. If I see a window, I'll try to fill it in! --Janiejac 00:30, 18 October 2010 (EDT)

The additional text box on the Person/Family page is there so you can add additional information that is specific to your citation, that is not in the community Source page. You could use it to add the exact text that you found, or maybe the URL of the record.--Dallan 23:27, 18 October 2010 (EDT)
I didn't make myself clear. The window that generated the duplicate citation was not on the Person/Family page. It was on the community Source page as I was creating the Source page. If the system automatically generates the citation based on title, author etc - then the window doesn't need to be on the source page for us to fill in; the system will do that. --Janiejac 00:59, 19 October 2010 (EDT)
Hi, I just set up a new source to see if I could tell what you meant. After clicking "add page" to my new source, the screen opens up to a full page with a section called "Source information" at the top,

then a section called "Coverage" and then a section called "Repositories." This is followed by a large blank box with the small label "Text" above it.

I can see two places that might be what you mean/where you are placing the citation. Do you mean the large box labeled text? If so, then I think that text box is designed to be used for additional information about the source, like what is useful or not so useful about the source, or best places to find the source material, or a description of the source and its contents.
The other line that often confuses me is in the top section called "Source Information" - the box labelled "References/Cites." This could easily be interpreted as a place to put the citation. But I *think* it is a rarely used field for a source that cites another source. I recently used this field in setting up a source for a Family Search Collection; the Collection is essentially an index to another source. An example of how I used it is Source:New Brunswick, Canada. New Brunswick Census, 1861. But I'm not entirely sure I'm interpreting the field correctly...--Brenda (kennebec1) 16:14, 20 October 2010 (EDT)
Brenda, you're right -- the References/Cites field is a seldom-used field for citing another source. Janiejac, could you provide an example where the citation is coming up twice? A link to a source page that you've created with two citations would allow me to see what you mean. Thanks.--Dallan 11:24, 5 November 2010 (EDT)
The problem is on the EDIT page for Source:Holcomb, Brent H. St. David's Parish, South Carolina. When in edit mode for the source, the window that says 'references & cites:' looks empty and so invites some text. But if you type anything in there, you are going to end up with both the system generated citation AND whatever you typed there. So my first instinct was that either the empty window shouldn't be there or that something should say that the system would fill in the window when the page is saved. I see that even tho the citation shows on the source page, on the edit page it still looks empty. BTW, what I've got there doesn't look so good, so I hope somebody will fix it! I gave up. --Janiejac 12:55, 5 November 2010 (EDT)

When we were doing source cleanup last year, I used that field as a handy parking spot for the pub information when I looked it up. I didn't always delete it after filling in the date, place fields as it wasn't hurting anything then and would have been handy for someone to cut and paste from. I've been deleting them as I find them, and invite anyone else to do so if they run across it. It will cause duplicate source info. I would like the fields for volumes, pages, and ref/cite to be left out of the autocitation if possible. We continue to have tangles with bibliographic info getting into the citations. --Judy (jlanoux) 14:01, 5 November 2010 (EDT)

Other comments

I really, really like the new new format, especially the clean, sophisticated look.

Its works well for creators of pages but what about potential contributors who might have info to add later? I imagine people searching the net might arrive at a person page without seeing the WeRelate front page. They may have info of value to add.

I'm just thinking about a prominent note saying something like "Have you something to add ? then do this (eitther go to talk page, communicate with page creator or just how to add info. Another option might be to emphasise that people browsing can add to "watching" list to be notified of updates.

Sometimes I think it would be nice if people just left a "I read this and it helped me" comment on the talk page--Dsrodgers34 20:36, 3 June 2010 (EDT)

I'm thinking that eventually I'll add the talk page comments and a "Add topic" form to the bottom of each main page, so that each wiki page looks kind of like a blog with the main content followed by comments. I'm hoping the "Add topic" form will encourage contributors. Also, I'm toying with the idea of adding "Vote up" and "Share this" links to the left-hand sidebar. I'm open to other suggestions too, though it will be awhile before I get around to implementing these ideas.--Dallan 15:29, 7 June 2010 (EDT)

I read through the discussion a little while back but I waited until you presented v.2 before opening my mouth. I really, really like both the basic redesign and the tweaking you did as a result of people's comments. Very clean, very efficient, much less page-jumping to see everything that pertains to a particular family unit. (I note the comments about certain people's artwork not fitting properly at the top of the page, but you really shouldn't worry about that. Think about the other 99.99% of users.)

I think I vote for "Facts & Events" above "Narrative," though I could live with it either way. Having the birth/death repeated with the person's name at the top fills the need for all essential info appearing "above the fold." OTOH, on the Ella Gray specimen page, the narrative is short enough to fit nicely at the top without pushing the Facts & Events way down the page, so it looks okay. So there's no "best" result; it just depends on the details of a particular page.

A reasoning for putting narrative first by default is: a non-sophisticated user can add a paragraph or two of text and it will appear "above the fold" and look nice. When that user becomes more sophisticated and writes longer narratives they can be introduced to the <events/> tag that will allow them to place the events table anywhere they want. If we did it the other way (events first by default), then the non-sophisticated user who wants to write a paragraph of text might need to learn about the <events/> tag to have their paragraph appear above the fold.--Dallan 15:29, 7 June 2010 (EDT)

The vertical timeline at the left: Meh. It's okay but it's not necessary. And when there's only one event in that list, it looks a little funny. See the bottom of the Augustine Washington/Mary Ball family page, where the marriage is 1731 but the timeline says 1720 -- the beginning of the decade, I know, but it could confusing.

The vertical timeline is going away.--Dallan 15:29, 7 June 2010 (EDT)

Since the watchlist is now hidden behind a link, you could also open up the "more" link and stack its contents on down that column with no visual problem. However -- and this is a personal design preference -- I think I would put a bullet (or the equivalent) before each item in that left-most column, and I would indent "Talk" under "Person." Make it explicit and hierarchical. It wouldn't require any more space and I think it would "cue" the eye better.

Even though we have the room, I'd like to use the "more" menu to hide less-often used links, just so they don't clutter up the page. Gmail does this too. But if there are menu items that you use semi-regularly, let me know and I'll pull them out of the "more" menu and put them in the regular page menu.
Personally, I'd love to see "What links here" on the main list and not under the "more" menu. But it certainly isn't a deal-breaker for me :-) -- Amy 15:45, 7 June 2010 (EDT)
I'm following gmail's lead and not putting bullets on the left-hand menu. It doesn't seem necessary.
If I put "Talk" indented under "Person" (like "Edit") what would happen if someone clicked on "Talk"? Would talk then be displayed at the top where "Person" used to be, and "Person" displayed indented underneath where "Talk" used to be? I could go either way on this. What do people think? (Also, as I mentioned earlier I think that long-term we need to display the talk page contents at the bottom of the primary page, so long-term the "Talk" link may not need to be displayed in that menu at all.)--Dallan 15:29, 7 June 2010 (EDT)

One other design point that I feel much more strongly about: On the Family page, there are three columns for the children. Names are numbered and flush left -- as they ought to be. But each line in the "Birth" and "Death" columns is centered. That looks TERRIBLE. Seriously. A long line followed by a very short (year only) line is jarring. Please, please, make all three columns flush left within their table cells. Please! --MikeTalk 16:32, 4 June 2010 (EDT)

Thank you, Mike. I knew there was something bugging me about the display of the children on the family pages, but couldn't put my finger on it. The birth/death info really does need to be left-aligned. It allows the eye to follow down and doesn't look so chaotic. -- Amy 17:14, 4 June 2010 (EDT)
The cenered birth and death events in the Family infobox is a bug, honest :-). I'm almost positive it wasn't that way last week. Something I've done recently must have caused them to be centered. I'll fix it.--Dallan 15:29, 7 June 2010 (EDT)

There seems to be something funky going on with the fonts in the parent/siblings box and the spouse/children box. For example, everything looks fine in those boxes on Ella Grey's page, but click on the link to her father James Allen Gray and look what happens to the fonts in those boxes -- it becomes a mix of regular and non-proportional fonts. -- Amy 09:26, 7 June 2010 (EDT)

The funky fonts in the family infoboxes on the Person page are the result of another bug. I'll fix that bug as well.--Dallan 15:29, 7 June 2010 (EDT)

Latest New Look [1 July 2010]

I've just posted some updates to the new look on the sandbox. It includes everything that was mentioned above, with the following additions and exceptions:

  • I didn't omit the primary name from the "Facts and Events" list so that it would be displayed in case it has sources attached to it. I could remove it in case there are no sources attached to it, but I'm thinking it might be better to list it always for consistency.
  • I've added all events listed on the spouse-family pages to the spouse's Person pages. So you see not only marriage, but also divorce, census, banns, etc. on the husband's and wife's Person pages. Please let me know if you like this or think this is overkill.
I think that looks fine. The less backing and forthing, the better. --MikeTalk 08:43, 10 June 2010 (EDT)
  • I list the children above the "Facts and Events" on the Family pages by default. I did this to keep them "above the fold", but I could be talked into listing them below by default. Also, I added a <children/> tag so you can list them where ever you want.
  • Sources and notes now appear together along with footnotes in a "References" section. You can use the <references/> tag to list this section anywhere you want. You can use a <ref> tag to refer to sources in your narrative. For example <ref name="S1"/> will generate a superscript reference to source S1.
  • Images that are referenced in source citations or facts/events appear as small icons in the references section. Other images appear in an "Image gallery" section. You can use a <images/> tag to list this section where ever you want.
  • You can hover over any image on Person and Family pages to see a full-size or near-full-size image.
  • I've cleaned up how text inside <pre> and </pre> tags appears. You can use these tags to surround text where the spacing and line breaks are significant, such as record transcriptions where you want the rows and columns to line up. -- see below for an update

--Dallan 22:59, 9 June 2010 (EDT)

I like all of this. This is ready for prime time. --MikeTalk 08:43, 10 June 2010 (EDT)
Something seems to be messing up page widths. When I display [8] the page is wider than my screen pushing the infoboxes way over to the right. The indented lines seem to cause a change in text styles which messes up line wrapping. --Jrich 09:46, 10 June 2010 (EDT)
I just opened that page and didn't have any formatting problems with it (other than the odd non-proportional font in part of the narrative). I'm using Chrome with the window set at 1024 X 768. -- Amy 09:54, 10 June 2010 (EDT)
I am using Firefox. It appears that the indentation of a line is triggering insertion of <PRE> tags? --Jrich 10:35, 10 June 2010 (EDT)
I just opened it up in Firefox (for Mac) and Safari and didn't have any problems there, either. Weird... -- Amy 10:41, 10 June 2010 (EDT)
Thank you. Apparently an old version of Firefox. Will have to see if I can update it (Windows 95!!!). --Jrich 11:33, 10 June 2010 (EDT)

It's the pre tags. Lines that are indented are automatically surrounded by pre tags by the mediawiki parser. (Not sure I agree with that, but the parser is the most complex part of mediawiki and I'm hesitant to start modifying it.) Anyway, to get around this problem I re-styled how pre text was displayed in the current format so that it has a normal font and gets wrapped just like normal text. But recently I found out about a relatively-new way to style text: "pre-wrap" which keeps your line spacing and carriage returns, but wraps the text if a line extends outside the boundary.

Argh, I just found out that IE7 doesn't support "pre-wrap" either. It looks like I'll have to go back to styling "pre" text like normal text (as it is now) so that when lines start with spaces they don't extend outside the boundary. Thank-you for pointing it out. I'll see if we can use a different approach for preserving user-entered spacing and line breaks, but because the mediawiki parser automatically wraps text lines that start with spaces inside pre tags, and a lot of text from imported gedcoms have lines that start with spaces, we'll need to continue to style pre text like normal text.--Dallan 14:11, 10 June 2010 (EDT)

Update: instead of using <pre> and </pre> tags, if you want to keep your spacing and line breaks you should surround your text with <code> and </code> tags. For example:

<code> John Doe 10 July 1800 Jane Johnson 15 December 1801 </code>

--Dallan 15:15, 10 June 2010 (EDT)

Dallan, did you go back and re-change something on the way text displays in the Source text boxes? I went into a tree I had been working on, expecting to have to do some remedial work by inserting <code> tags for census listings in those boxes -- but they hadn't wrapped the lines as I had expected them to. (They had done the other day, of course.) The text boxes are still displaying the census data in "stacked" style as I had entered it, with no tags and no colons or anything. So I'm a little puzzled. Though if you did make a subsequent change to this issue, you've saved me a bunch of work! --MikeTalk 10:27, 19 June 2010 (EDT)
I did make a change -- any line-breaks that you enter in source text or a note are now preserved even if you don't use the code tags. You need to use the code tags only if you have multiple spaces that you want to be preserved so that columns line up.--Dallan 23:20, 19 June 2010 (EDT)

Everything looks pretty good, but I put a lot of work into posting my Research Interests (Surnames in Place) on my user page and would like the option of viewing them and having them seen by others on my user page. Is that still an option or has that feature now been permanently eliminated? Right now it looks like I have multiple surname duplicates (linked only to the surname article page & surname category page), when in fact they are (or should be) linked to separate geographical surname in place pages.--BobC 20:22, 10 June 2010 (EDT)

Sorry about that. I had some problems with user pages on the launch. It should be fixed now. Let me know if you notice any other problems.--Dallan 23:25, 10 June 2010 (EDT)

I don't mean to be a Donny Downer, but there may be another possible minor problem with the new pages. I noticed that in some of the article and person pages that the cursor link to the associated Talk Page (under the WeRelate logo) is not actually on the Talk word but on a tiny space midway between the type of page and the word Talk. --BobC 20:22, 10 June 2010 (EDT)

I see what you mean. It's working on Firefox, Chrome, and Safari but not IE7. I'll fix it first thing Monday.

I have had just a quick look at the new format and it is so much improved. Congratulations!

I have mixed feelings about listing facts/events (such as marriage date) below children on the family page - I think I would prefer it above the children (but not enough to actually request a change). I'm sure we could quibble forever about minor things such as this. Overall, I find the user interface much better looking and easier to use. Thanks for your hard work on this. Again, Congratulations.--DataAnalyst 23:27, 10 June 2010 (EDT)

I had a problem tonight. Twice I added a page while editing another page. Both occurrences, the first time I pushed Add, it it appears to return, but was still displaying the search page instead of returning to the page I was editing. So I pushed Add again and this time it seemed to work. But I found out later, in both cases, duplicates were added. Hope this is clear. It's late and I don't plan on playing with this any more until tomorrow.

I like the new look, but a lot of formatting that used to work has changed in sources and notes. It used to respect the lines in the text box just the way I typed them, but now it runs them all together. I.e., when typing in the birth of one child within a family, I used to enter
The children of John and Jane Doe
Paul born 7th day of the 4th mo 1673
and it would display as three lines. Now it displays as "The children of John and Jane Doe ... Paul born 7th day of the 4th mo 1673". I can change going forward, but I am sure not going to review the 10K pages I have entered to change the layout to match the new formatting. --Jrich 01:16, 11 June 2010 (EDT)

Your formatting should still work. It's been a bit of a challenge getting formatting to work with the ref/references extension, but I just fixed another bug. Could you send me the url's of a couple of pages that still don't work if you find any?--Dallan 23:16, 12 June 2010 (EDT)
Person:Ruth Tilson (1) is a recent page with exact issue described above. In the old version, the birth record would have been displayed with 3 lines, instead of all run together on one. It appears to be both the source text box and notes. I can add tags to force this into a multi-line text if that is needed, but this worked before, so just checking. --Jrich 10:56, 13 June 2010 (EDT)
I see what you're saying. This has been fixed now.--Dallan 12:34, 15 June 2010 (EDT)
I retried this. I added parents while editing a Person page. Pressed the Add button, get the "Please Wait" warning, it goes away, progress bar fills in, and then the Firefox tells me its done. Then it sits there for about 15 seconds as if I never pushed Add. Finally it goes away and the Person page is now displayed with the parents added. So technically, it works, but that 15 second gap with no feedback will clearly cause problems. Caveat: this is an old version of Firefox version 2.
This doesn't happen with a newer version. To speed it up, after the "Please Wait" disappears, if I pop a different window to the front, then return to the Add window, it will disappear instead of popping to the front. --Jrich 12:26, 12 June 2010 (EDT)
That's really odd. You're saying that it doesn't happen with a newer version of Firefox? I want to re-do how add works in the next couple of months, so I'll try to see if we can fix this at the same time.--Dallan 23:16, 12 June 2010 (EDT)
Not sure what it is exactly, but yes I tried it once on my newer computer with Firefox 3.x and no problem, but the older computer which cannot be upgraded past Firefox 2.x started exhibiting this problem when the new version was rolled out. When I Add a page (as opposed to Selecting an existing one) Please Wait is displayed, then goes away and the page sits there until by some mouse clicks I cause focus to shift away and then back to the page. So the receiving focus event seems to wake up the page and cause it realize it supposed to go away, if that makes any sense. Sorry, don't mean to cause problems because I run an old version of Firefox and certinaly don't expect it to be supported unless this is an indication of some lurking problem. --Jrich 10:56, 13 June 2010 (EDT)
I just made a change; see if it works now. If it works, great; if not, let's come back to it when I re-do adding pages later this summer.--Dallan 12:34, 15 June 2010 (EDT)
It works, I noticed it earlier this morning. Thank you. --Jrich 14:13, 15 June 2010 (EDT)
Prior to the new look, I used to hit tab once and my cursor would be positioned in the first input field. Now tabs through all the various menu items. It is a nit, but would be nice if the cursor was in the first input field, or perhaps to avoid inadvertent input, if it only took one tab to get there. For a reasonable typist, it is easier to hit tab than to move the cursor with the mouse. --Jrich 09:07, 11 June 2010 (EDT)
This should be fixed now.--Dallan 12:34, 15 June 2010 (EDT)
I just tried edting a Person page and a Family page (using Firefox 3.6) and the tab key took me to the first field. Can you tell me what kind of page you were editing, and what browser+version you were using?--Dallan 23:16, 12 June 2010 (EDT)
Sorry for the imprecise description. I should know better. It was the Find/Add screen prior to the full Edit screen where this was observed. It is obviously not critical, just a usage habit I had gotten into. The first tab seems to go to the WeRelate logo, and then it start moving through the various menu items at the top, I think. --Jrich 10:56, 13 June 2010 (EDT)

I am working on a page with only one set of parents, but the More menu still shows "Compare Parents". It brings up the Compare page with nothing filled in. I expected the option not to be offered?

This page has multiple spouses. When I select Compare Spouses it brings up the Compare page with nothing filled in. I expected the side by side comparison of the multiple family pages? --Jrich 09:27, 11 June 2010 (EDT)

This is fixed now.--Dallan 23:16, 12 June 2010 (EDT)

Were we going to display the name of a spouse from the page title if there is no Person page for that spouse? Otherwise, leaving it blank in the infoboxes as it does now encourages creating empty Person pages with just a name even if all you know is the name (i.e., just have a marriage record and can't identify the spouse so don't know birth or parents), and this clutters up search results to get a bunch of pages listed with only the name and no dates or places, especially for spouses like Mary Unknown. --Jrich 12:26, 12 June 2010 (EDT)

Another vote to use the Family page title. I am also opposed to having to create empty person pages just to get a name. --Judy (jlanoux) 16:40, 12 June 2010 (EDT)
I'll add this as soon as I can.--Dallan 23:16, 12 June 2010 (EDT)
I noticed this was working this morning. Thank you. I think it makes much more sense to a reader this way. --Jrich 14:13, 15 June 2010 (EDT)

I absolutely love the new look and flexibility! Great job and big thanks to everyone who worked on this and made it happen. :)--Aberksan 17:24, 11 June 2010 (EDT)

Problem with Citations and source text:

  1. The source extracts or comments that are in the source text smash up against the end of the citation. Is there any way you could add a break or CR (or whatever we use these days) at the end of the citation to separate these? I am having to add an extra break at the top of the source box to correct this.
  2. I tried using the <code> that you mentioned above for my census listings. The results are not pretty. The font is much bigger than that on the rest of the page and the spacing between lines is also increased. Since census listings are interspersed with book extracts, etc. it makes for a jarring look. If anything the text box data should be in a smaller font than the source citation.

On a more cheerful note, using a : in front of a paragraph of text results in a very nice look. Also, I would like to put in a vote to have the watch list displayed at the bottom of the left column like it was before. I'm having to open it on every page I look at. --Judy (jlanoux) 16:40, 12 June 2010 (EDT)

I'll start the source text on a new line, and decrease the size of the code text. Solveig has also requested that the watchers be shown always, so I'll add that as well.--Dallan 23:16, 12 June 2010 (EDT)
I'm having real trouble reading or editing this page using AOL!! The width is very much wider than the maximized screen so there is a lot of scrolling back and forth to be able to read it or edit it. So I just checked using IE 7.0; the watercooler page itself is all visible without scrolling - but there is a long scroll bar there and when scrolled right just shows a lot of blank space. When trying to edit the watercooler in IE, there is no scroll bar.
I don't have AOL, but I just made a fix that removes the horizontal scrollbar in IE7. See if that fixes the AOL problem as well.--Dallan 12:34, 15 June 2010 (EDT)

Also has the size of the font changed? Or is it just my eyes? The type is clear and crisp but I think it is the size that makes it difficult for me to read. I can't put my finger on what is different but didn't have trouble reading it before. --Janiejac 14:09, 13 June 2010 (EDT)

I had reduced the font size to 13 pixels and changed the typeface from Verdana to Tahoma. Tahoma is basically the same as Verdana except that it is takes up 15% less room horizontally. Facebook uses Tahoma. I just now changed the font from Tahoma to Arial. Arial is the same size as Tahoma but can be a bit more readable. Gmail uses Arial.--Dallan 12:34, 15 June 2010 (EDT)
Dallan, I personally find the Arial much more readable. Looks great! Thank you, --Jennifer (JBS66) 12:58, 15 June 2010 (EDT)

Still being frustrated! I wanted to edit the source for Person:Mary Fitz Randolph (3) I tried to change 'mysource' to source and show the proper source. It is normal to expect to be able to do that. But no, the next click opens a new window (with no back button) and won't let me edit the source. I x out of that window, go back to try again. Now I figure I cannot edit a mysource, I should instead remove it and then add the new correct source. But even that is difficult because the window is too wide for the screen and I'm scrolling back and forth. I gave up and left it the way it was. Am using IE7.

I'm not sure what you mean by the "next click", but I do this all the time. Change the drop-down to "Source" and then type the correct source title in the box. Or you can click Find/Add to get to Search. I don't see that the process has changed and I've been doing this a lot in the past week while cleaning up a gedcom import. I personally find it easier to search for the correct source in a separate window and then paste the name into the title box. --Judy (jlanoux) 17:44, 1 July 2010 (EDT)

Listing Facts and Children Above Narrative [12 June 2010]

After looking at a bunch of pages today, I decided to try putting the facts and events table above the narrative by default instead of below, because it was getting lost at the bottom of long narratives. You can still customize where it appears by adding an <events/> tag. Also, I put the children just after the facts and events table on Family pages. You can still customize where children display using the <children/> tag.

Finally, each major (2 equal signs) section is now close-able by clicking on the little triangle to the left of the section headings.

Please try out the pages this way and let me know if you prefer or dislike this new approach.--Dallan 23:16, 12 June 2010 (EDT)

Thank you

I wanted to thank everyone for the excellent feedback on the new look. I think it's much better because of the comments. Thanks to all who contributed!--Dallan 12:42, 15 June 2010 (EDT)

Capitalisation of Surnames [10 June 2010]

Is there a preferred way to enter surmnes? I have been using capitals for my surnames in my database for years as I was under the impression that this was the preferred convention used by most genealogists and was discussed a few years ago on Rootsweb. There are now pages with Lower case and Upper case as an alternative name which, although only minor, are an annoyance.--Kenamoore 06:27, 23 May 2010 (EDT)

The preferred method is an initial capital letter, and the rest lower case (ie: Kennedy). It's my understanding that people often use all uppercase in their software when they want to distinguish their "direct" line of ancestors. Here on WeRelate, that is not applicable, as all pages are shared. If you come across a page that has Kennedy and KENNEDY as preferred/alt names, feel free to delete the KENNEDY. Additionally, the software here on WeRelate automatically renames pages in a GEDCOM that are all uppercase. --Jennifer (JBS66) 06:39, 23 May 2010 (EDT)
The use of ALL CAPS for surnames was originally an aid to spotting surnames of interest in printed works. In the days of electronic media, where we utilized search engines to find things, this is less necessary, and is a practice that has largely become passe', at least on the internet. I understand that the current version of the MediaWiki software (used by this site) automatically capitalizes the first letter of a surname in the title of a Person page, even if the usage is for a small initial letter. For example "deVries" would probably come out "DeVries". I understand there are plans in the work to over-ride this. Q 19:01, 24 May 2010 (EDT)
right.--Dallan 15:10, 3 June 2010 (EDT)
Actually, in both editorial and library work, either upper or lower initial letter is regarded as correct, depending on how it's presented: "Peter deVries" in a narrative, but also "DeVries, Peter" in an index. Plus, the standard usage is to put a space in there, since it's really two words -- "de Vries" -- but there's a tendency since the advent of computer-sorting to jam the name all together. --MikeTalk 16:47, 4 June 2010 (EDT)

Thanks for your comments, however I notice that although the page titles have lower case surnames (except for one case I know of) all of the surnames which were imported from my gedcom file have upper case surnames. I don't like to be pedantic, but maybe this could become more of a problem in the future when people are trying to find connections, particularily when looking for surnames with MAC/MC/Mac/Mc--Kenamoore 22:02, 25 May 2010 (EDT)

The page titles should be in lowercase, but the names in the fields will be how you listed them in your gedcom file. Consistency in capitalization is something that's planned for future improvement. Searches are case-insensitive, so searches for MAC should find names listed as Mac.--Dallan 15:10, 3 June 2010 (EDT)

Category problem [15 June 2010]

There is something wrong with the categories on this page: Person:Donelson Jackson (1). Can someone tell me how this happened (so I won't do it again) and how to fix it? I don't see that I added these categories myself but ?? --Janiejac 11:40, 30 May 2010 (EDT)

Hi Janie, you just had a comma in the alt-name surname field, which I removed for you. --Jennifer (JBS66) 11:43, 30 May 2010 (EDT)

All that for a mis-placed comma! Thanks for seeing the problem and fixing it Jennifer! I wish the system would automatically generate categories for surname in county, state, country. It looks like it just does state, county. --Janiejac 12:35, 30 May 2010 (EDT)

Sorry, categories is also planned for future improvement. Until then...--Dallan 15:10, 3 June 2010 (EDT)

I have added History and Early Settlers sections to Place:Wantagh, Nassau, New York, United States but I think it needs a bit of help. There is one line just above the History section that I thought I was supposed to add but it wasn't supposed to show. Also the stub reference to WP at the bottom; doesn't look right to me. Would someone check this page? --Janiejac 15:04, 14 June 2010 (EDT)

I made some minor changes to the page. By the way, if you want text to show when you're editing but not show when you're viewing, you can write it as <!-- put hidden text here -->. --Dallan 12:39, 15 June 2010 (EDT)

Category for Medal of Honor recipients [5 June 2010]

I just started a category for Medal of Honor recipients. I looked for an existing one, but didn't find any; if there is one, please let me know. Assuming that there isn't already one, I'm wondering if it should have subcategories for each engagement (Civil War Medal of Honor recipients, World War I Medal of Honor recipients, etc.) It might make it easier to scan through the names, since there are approximately 3400 of them. If you think that there should be subcategories, which way would you name it: <war> Medal of Honor recipients (eg. Civil War Medal of Honor recipients) or Medal of Honor recipients: <war> (eg, Medal of Honor recipients: Civil War). Thanks. -- Amy 23:28, 5 June 2010 (EDT)

GEDCOM upload process [17 July 2010]

I have been a little frustrated lately with GEDCOM uploads from the point of view of maintaining data that is already in WeRelate. It seems like every new user that uploads a GEDCOM ends up adding duplicates, changing existing pages with bad data contradicted by sources that are already on the page, adding alternate dates that don't match simply because they are less precise, etc. There seems to be no reading of the pre-existing page by these users before-hand, nor in most cases, any checking to see if the resulting page makes sense. And hardly any of the uploads by new users contain sources, much less sources that indicate any kind of quality genealogy (i.e., trying to locate the primary sources as opposed to believing some stranger's ancestry tree, etc). And of course they never realized they were doing anything wrong, or aren't aware how to respond to the error messages, or don't know how to fix the problems after they have created them. It's not a massive problem, but every hour spent removing some of these errors is an hour not spent doing something a little more constructive. More new users will only create more of this entropy, until there is no longer any forward movement.

To quote a Jlanoux comment: "Gedcom import isn't the first thing we want a newcomer to do." Yet it is invariably the first thing they want to do. This rush to upload, apparently without even looking to see if there is anything useful to learn from what is already in WeRelate, doesn't seem to indicate the attitude of a good collaborative researcher. It seems to indicate that the new user thinks they have stumbled onto another rootsweb or ancestry.com.

So can we slow these new users down a little? These are various thoughts I have had, one or more of which may be possible to implement so as to provide some more protection from "newbie" uploading:

  1. Perhaps start with a smaller number than 5000, even as low as 100-200 and get that successfully done without too much negative feedback before allowing someone to do 5000.
  2. Make them demonstrate some minimal degree of proficiency with WeRelate before giving them upload privileges. This could be done by requiring them to have performed certain key processes before giving them upload capability (adding a page manually, adding a source citation, posting to a Talk page, doing a merge, etc.). I don't know if it would possible to develop some kind of computer-guided training where the user is led through a captured session and their responses are analyzed, and corrected with feedback if necessary. The ability to have them do a small GEDCOM upload in the sandbox in this manner would be terrific!
  3. Find some way to ensure they have read (and understand!) some minimal set of instruction pages before they are given permission to upload a GEDCOM.
  4. Especially the further back in time you go, and as the pool of affected descendants/researchers gets larger, it would be nice if there could be more restrictions on what an upload is allowed to change. For example, add a warning that people before 1800 require sources. Or even at a more recent date. This would help new users get feedback/guidance about what is desired before they change pages. --Jrich 18:37, 29 June 2010 (EDT)

I've been waiting to see others' opinions on this subject before I voiced my own, but here goes.

  • We've had a couple of gedcoms uploaded during the past several weeks that negatively affected existing pages, so I think that a solution to the problem is needed.
  • I don't think that requiring manual page adding before a gedcom upload would be very helpful, because the type of editing that you do during gedcom upload is pretty different than the type of editing you do during manual page adds.
  • We could require a much smaller number to start, say 100-200, but the risk is that with such a small number the upload doesn't match any or many existing pages, so the uploader hasn't learned proper etiquette before uploading their large gedcom.
  • I like the idea of computer-guided training or ensuring that the uploader has read and understood some instructions before being given permission to upload. We could use that opportunity to explain the proper etiquette and procedures for matching and updating existing pages.

Here's what I propose: Would anyone who is interested please edit: Help:Before you import your GEDCOM. This help page would be required reading for anyone to upload their GEDCOM. Ideally this page would teach people how to match and update existing pages. It would be great if this page were a community effort. If others contribute the content of this page I can add screenshots and require that people pass a quiz on the contents in order to upload their GEDCOMs.

What do people think?--Dallan 23:07, 4 July 2010 (EDT)

I think this is going to get super long and complicated. I agree with Jrich. Even though manual edits may not be the same type of editing required in a gedcom, I think what we most want is users willing to stick around. If the first thing someone wants to do is upload 5000 people, and they aren't willing to learn the ropes first, then this is not the place for them. People who start out by improving pages manually are more likely to understand the basic concepts that will make for better uploads. As for how they learn to upload reasonably, I think having such a page as a resource is useful, but if we're going to do a tutorial, I think we have to figure out how to get the main points across with much less text.--Amelia 15:07, 7 July 2010 (EDT)

Discussion moved to Help talk:Before you import your GEDCOM. Please review and continue to add to this dicussion at the associated topic Talk Page or to the topic Help Page itself.

Congratulation to WeRelate: Among 101 Best in 2010 [27 July 2010]

Congratulation to WeRelate once again for being designated as one of the 101 Best Websites in 2010, listed among the Best Big Genealogy Sites, as named by Family Tree Magazine.

The listing states, "WeRelate - Still in beta, this wiki for genealogy (sponsored by the Foundation for On-Line Genealogy in partnership with the Allen County Public Library) is home to pages for more than 2 million people and families. Its powerful search can drill down in whatever “namespace” you select, such as nearly 104,000 surnames or more than 989,000 places. As a wiki, it lets you add to and edit its pages."

Well done, Dallan and the core of administrators who make this work.--BobC 17:06, 9 July 2010 (EDT)

Congratulations to All (Admin's and User's). Thank You BobC for the heads up. I appreciate it. I was wondering what was going on. Debbie Freeman --DFree 17:24, 9 July 2010 (EDT)

Congratulations !

The feedback and subsequent action is a very strong point of WeRelate.

Incidentally, I noticed the front page no longer mentions its in beta - is this the case ? (edit I re-read and got that wrong Dale)

After a quiet year 'on board' I am now starting to get some collaborators - its very encouraging.

I also wondered if there will be an awareness campaign at some point (I realise theres quite a bit to do in preparation for that)--Dsrodgers34 01:39, 14 July 2010 (EDT)

The homepage still says we're in beta toward the bottom of the page. (I thought it could be de-emphasized since we've been in beta for several years now.) I think we're getting closer to coming out of beta, but we're not there yet. Still need to improve search, adding+editing person and family pages, the ability to re-upload a gedcom, and features that encourage more people to stick around once they start. Once we reach these goals I think we'll be ready for an awareness campaign.--Dallan 18:13, 27 July 2010 (EDT)

Coordinates [12 July 2010]

At the risk of showing my ignorance, I have to admit that the various styles of expressing latitude and longitude don't make a whole lot of sense to me. I tried adding the coordinates to Place:Hopewell Cemetery, Meigsville, Morgan, Ohio, United States as they're shown on the Ohio Genealogical Society's website 81° 47' 19.31" N, 39° 37' 20.97" W. (Yes, I entered them in the separate fields, not all in one.) However, the Google map keeps putting it in northern Greenland. I've tried taking out the degree signs and the apostrophes for the minutes and seconds, but it still shows up in Greenland. What am I doing wrong? I've never had any problems when I've entered coordinates expressed in decimals. -- Amy 08:19, 12 July 2010 (EDT)

It seems you have the N & W mixed up. 81 degrees north is getting close to the north pole.--HLJ411 09:42, 12 July 2010 (EDT)

Thanks. I was so fixated on the formatting that I didn't stop to think about the actual numbers. As it turns out, the OGS website has all of the coordinates reversed. I've alerted them to this; hopefully they can get it fixed soon. -- Amy 10:17, 12 July 2010 (EDT)

Rating system re-visited [6 August 2010]

In light of the renewed concern about Gedcom upload. I would like to put "person" and "family" page rating system back on the table.

I'll suggest a system for discussion later. Briefly what I have in mind is where a contributor self-rates their pages, but the contributer is also rated according to WeRelate-Genealogy experience. Simply the higher a contributor is rated, the higher rating they can give to a page

Without detailing a rating system up front, it's useful to think about where such a rating system would integrate with WeRelate:

1. When searching, the rating can also be ised as a search filter. the rating for a person page would show up in the search listing. It would indicate more "interesting" pages, much as when one with a picture shows up

2. When listed on another family or person page - indicating a relation (eg a child on a parents form)there is a small notation - meaning someone browsing a one persons page, can be alerted to a childs page which has a high rating ie more interesting

3. Person pages uploded by Gedcom automatically have a 0 rating. It would be expected for the uploader would then 'check' each page has appeared as expected. As the WeRelater improves the standard of the page they self-rate, they allocate a higher rating to the page. I have noted people use trees or categories to maintain a 'to do' list insofar as they want a listing of pages they still need to attend to. If people use a commoin rating system as their 'to do' list, its even better, as common standards can be expected.

4. Hence if gedcoms are dumped and not worked on, they are not seriously considered 'genuine' as as they relate to the overall 'status' of WeRelate as a whole. Statistics would be published in relation to the ratings of pages. That is 'O' rated pages are not included.

5. If you are concerened about Junk genealogy from gedcom dumping - have no fear - they are in here but they are zero rated. Also pages above a certain rating can be afforded higher protection from automatic processes such as gedcom merge and merge

6. I also think a rating system in regular use underlines WeRelate as a quality site. Once it becomes more popular, it will help administraors to measure and enhance quality in parallel with the growth of the site. There may be periods of very rapis growth

The above points are valid no matter what rating system were adopted. I am proposing a simple system which is based on self rating combined with a rater rating system. I think the human mind copes well with up to three factors so I'm using 3 as my limit.

Contributers Ratings:

A Contributor has the rating 1, 2 or 3. The default rating is 1 for a new contributer. This is so even if the person is already a competent genealogist but is not yet conversant with WeRelate. A 'regular' contributer has rating 2. This is still a valid achievement An expereienced has rating 3. A rating 3 can promote a new contributer to rating 2 (once the competency has been reached). Rating 3 contributors are the gatekeepers to the high standards of WeRelate

What do the ratings mean ?

A person can "rate" a person or family document up to their limit. In essence when a new contributor (rating 1)has achieved a basic level in a particular person page, they can allocate rating 1 to that page. If they believe they have achieved level 2 for that page, but their personal rating does not allow them to allocate that rating, they nominate it as a rating 2 - this automatically puts the document in a queue - where volunteers with the rating 3 check the work and allocate the rating. Discussion can take place.

I thought that if a rating 1 contributor has successfully achieved enough person pages at the higher rating, this is a trigger for them to be rated level 2. As an aside a rating 2 person could be allowed larger gedcom uploads without having to refer to administrators. If you look at what a rating 2 means to a document, it suggests the competency (contributor rating 2) required to test and rate a document to rating 2. I suggest that while a contributer with rating 2 could rate their own document, a contributor would need to be rating 3 to asses another persons contribution.

So a page can be rated 0 to 3 what does that mean ?

I think this is too arbitary and how could you condense all the requirements to tick off before you rate a document. Suppose its got greas sources but false assumptions in reletion to marriage, parentage ? It might have lots of narrative and photos but poor sources

Overall I suggest rating 1 is basic quality which is a stepping stone to rating 2, as more research has taken place on a pericular person. Rating 2 would be the aim for most person pages Rating 3 will remain rare and highlight those entries with excellent content - probaly limited to outstanding or notorious ancestors about which there is lots of information.

My thought was a 0 to 3 rating for each of the categories : Sources : Unambiguity  : Narrative.

Again I limit it to 3 different aspects although more could be adopted if needed.

The rating could be published in the format '333'or for one which achieved top rating in each category or '312' for one which achieved differing levels in each category , there could also be the cumulative total '9' meaning a rating system from 0-9

More detail in the ratings

Sources: 0 - Unrated (which does not mean it is poor, just not rated yet)

1 - Basic - e.g. some sources (secondary) which appear logical and complete

2 - Regular - complete sources (secondary and primary)entered with high clerical standards

3 - High - very high standards, as many primary sources (e.g. BMD certs) as can be found

Unambiguity: 0 - Unrated

1 - Basic simple checks to show that contradictory theories about marriage or parentege etc cannot be made.

2 - Regular Exhaustive checks and evidence to in relation to ambiguity to 1- show there is not or 2- if there is, that the details of the ambiguity, including links to the other people involved so that future resesrchers csn ubnderstand it or resolve it with new evidence

3 - High - as above but to a very high standard

Narrative (which also includes photographs or other embellishments to the persons life

0 - Unrated

1 - Basic. A photo or a simple paragraph summarising the theories which arise from genealogical evidence. A timeline.

2 - Regular - Well written narrative and/or excellent supplimentary information relating to the person

3 - High - the really good documents such as the ones featured on the WeRelate home page--

How would the ratings appear ?

If the above system "SUN" (Sources,Unambiguity,Narrative) were used, the text " 312* " would appear in search listings, and in a small part of the header on a person page.

It would mean S3 U1 N2 and the asterisk would be there if a higher review froma higher rated contributor were pending. Click into the edit mage and the boxes for each would be there, this a space for notes. The name of the rater would also be there. Discussion would be on the Talk page

If you have read this far, fwiw I would rate myself as someone still to attain rating 2. I suggest though, that there are many contributors currently on the site who are already functioning at rating 3.

If we achieve huge growth, we will need many rating 3 people, If thet were to occur, we might be able to organise them so they are providing rating services on pages covered by an area of expertise, genealogy wise (eg scottish FH experts rating scottish ancestors)

Dale--Dsrodgers34 07:35, 14 July 2010 (EDT)

Variations of these ideas have been raised before, as you're aware, and I too would like Dallan and administrators to consider some such rating, grading or assessment system for pages and users. I would recommend a more automated and objective recognition or assessment system, rather than what may be considered a more bias, subjective, and high maintenance manually-inputted system you are describing. With that in mind, I would also tend to recommend a "0-10" scale to account for multiple variables.
Some of the pages where aspects of these ideas have been raised are...
The parts where you infer "ownership" of certain pages concerns me though, because WeRelate is based on community collaboration, or the voluntary release and denial of private and personal rights relating to contributed information. Although the bulk of pages here may be have been contributed and watched by a single user, they are a community public resource, not private or personal.
Good luck. Personally, I think most people feel there are many other more critical changes needed here, but I suspect as those get resolved, more attention will be paid to these ideas. And if this idea only stays in the Watercooler, it will soon get "washed down the drain" with all the other topics and will only be a distant memory. --BobC 18:38, 14 July 2010 (EDT)

Thanks for those links I had reviewd some of them before posting and I agree rating isnt such a high priority - unless it can be used to solve some of the other issues - like gedcom upload misuse.

I agree some automated rating system would be nice, especially when estabishing a rating system, or when administrators are facing a task involving hundreds of pages. BUT the actual rating would be the same as produced by a manual rating - less experienced people would use the manual means only.

Perhaps I should clarify what a simple rating system would mean to someone coming across a page for the first time

Rating 0 - The page has not been rated. A contributor uploaded via gedcom and has not checked the page since. In time these pages might be ignored totally - or if housekeeping is required, those trees with consistent rating 0's would be reviewed after an amount of time has passed. Perhps an administrator could use a tool which might assess the 'worth' of the tree as a whole, saving manual effort. A tree with merit could be marked for remediation by volunteers - or, if no merit - just removed altogether.

Rating 1 - The page has been rated according to the conrtibutors personal standards Once uploaded, the contributor re-chekced the page, and is personally happy for the community to view it. This allows for conrtibutors to create a person page, then do further research before marking it viewable. Is it reasonable to expect contributors to take this step, given we have allowed the 'shortcut' of a GEDCOM upload ? I think it is. This would be the very driver of a rating system.

In any case the reader should be aware the 'standard' can be variable and does not mean much, except the contributor re-examined the page. In most cases I think people would do some checking before rating it.

Rating 2 - The page has met WeRelate community standards In practical terms - this page got the rating from the contributor who has been rated by the community as competent (contributor level 2) to allocate that rating OR it has been proposed by a contributor and checked by a Rating 3 person who has confirmed the standard. The aim is for all pages to achieve at least level 2 rating, although the circumstances of the person (ancestor) in question may prevent this (eg a scarcity of information meaning not all vital facts can be proven)

Rating 3 - Exceptional - the page has met community standards and is of major interest. A bit self explanatory. The majority of pages would not achieve this - being related to 'ordinary' people (ancestors)with littel interest to non-descendants A level 1 or 2 contributor can request a level 3 contributor verify the rating for a perticular page.

Is suppling ratings for contributors controversial ? The main issue seems to be of elitism. I propose only 3 levels. For most contributors it's 1.Novice and 2.Competent - which should be attained quite quickly if the contributor intends to use WeRelate often. Level 2 should be seen as the standard which underpins the reputation of WeRelate. This does not mean that all pages created by the level 2 contributor need to be of rating 2 quality. The person can create pages and leave them at level 0 or 1 until they are happy with the standards of that page. Most of us have many such "work in progress" pages.

Level 3.Administrator would be for those volunteers who provide excellent service to WeRelate across many areas. A contributor should not feel slighted they are not level 3 if they only contribute to the pages they are interested in

Yes I do hint at ownership, but only in a pragmatic way that unless someone takes ownership for something, it doesn't even get into WeRelate. In a way, the rating system is a way to relinquish ownership. That is Its "yours" if it remains rating 0, but more and more community owned as it gains rating points.

Perhaps "Carer" is a better term than "Owner"

Dale, how about "Watcher"?!?! Almost every page at WeRelate has people interested in the page, and they are identified on the Watchlist for any particular page. Forget "Owner" or "Caretaker" or the like -- if you hint at changing the very underpinnings of what makes WeRelate what it is as a public resource, your whole idea will be discredited and disregarded. Why not consolidate and abbreviate your rating scheme idea and post it as a recommendation to the WeRelate:ToDo List or its associated talk page to encourage a discussion there. --BobC 00:56, 17 July 2010 (EDT)

Do you think I'd get better feedback or interest in ToDo: Talk ? PS I was very careful to use the word "Contributor" in my submission.


Not sure if it would get better feedback or garner more interest there, but it would be at the page designed to hold items of future interest or ideas for improvement in WeRelate. At the top of the page it advises, "Discuss ToDo list items here," and it wouldn't be archived as quickly as keeping it solely as a discussion item here in the Watercooler would be.
Or you could create an article page for introducing your ideas, both generally and specifically. Take a look at the page entitled, "Proposal for Managed Pages." I think you could use that page as a template to more easily model your page on that one and create a more palatable, thoughtful, analytical approach to presenting your proposal. And then ask for and encourage discussion of those ideas, either on the same page or in the associated Talk Page.
As I said, I think your idea of a rating mechanism generally for WeRelate pages has a lot of merit and would be a value added change to WR, but as can be seen in the "ToDo List" pages (project page and talk page) I think many of the key WR users will find it low on the priority list of improvements needed and wanted at WeRelate at this time. But don't let that discourage your efforts if you have the time and interest.
Good luck. --BobC 11:01, 19 July 2010 (EDT)

How about something really simple to start: pages are rated by the number of sources they contain, and people are rated by the number of sources they've added to pages.

I realize that this doesn't capture everything that we'd want to ultimately capture in a rating system, but it:

  • is easy to understand
  • is objective - no disagreements on whether a page should be rated as a 2 or a 3
  • could be done automatically be the computer - people wouldn't have to spend time rating pages by hand
  • would be relatively easy to implement (rating pages based upon #sources would be easy; rating users based upon #sources added would take more time)
  • encourages good behavior - people improve their pages' ratings and their own rating by adding sources, an activity that most people currently aren't doing and would help them become better genealogists.

What do you think?--Dallan 18:13, 27 July 2010 (EDT)

I agree with your idea only if you define a source as something other than someone's gedcom or WFT # so and so etc.--Beth 21:28, 27 July 2010 (EDT)
As far as rating systems go, I don't mind, at least as a temporary measure. We would also have to define when it's acceptable to remove a source (because it's a gedcom or an untraceable MySource etc.). Also, having it be reasonably easy to meet the top level with basic sources (i.e. 3 sources maybe?) would reduce the incentive to add/not remove duplicative or not helpful sources just to up the rating.--Amelia 22:57, 27 July 2010 (EDT)
Amelia, I don't understand the need to define the acceptability of removing an alleged source. If the source citation fails to reference where one can verify the facts supported by the citation then the source is not of any use. --Beth 00:10, 28 July 2010 (EDT)
We agree on that. We may or may not agree on how certain that reference needs to be. Others here don't agree at all. I actually revoke my support for the idea in general. Way, way too much work and discussion would be required to define standards for it to make sense, and for no real benefit as far as I can tell. It's pretty obvious if a page meets the viewer's personal criteria for a good page, and to the extent those criteria differ, I'm not interested in having the community waste effort arguing about it. --Amelia 01:20, 30 July 2010 (EDT)
If we are going to have a rating system, then one based on number of citations seems appropriate. Anything to encourage source citation. And I agree that there should be some guidelines for removing someone else's citation, even if it's a gedcom. Possibly when citations to more reliable data are provided?--GayelKnott 09:43, 29 July 2010 (EDT)
Dallan, I think your proposal is a good starting point, if in fact you decide to implement a rating system here at WeRelate. But my underlying fear of the potential subsequent ramifications of such a system has already risen it's ugly head and has been expressed in words by another user above even before a decision point on the topic and implementation of the method is made -- talk of subjectively reevaluating and removing sources that don't meet some possibly idiosyncratic criteria, and the suspicion that junk sources will be used by the average user solely to boost ratings.
Instead, we should be identfying which sources will add value to genealogy pages, and only using those sources to increae ratings (possibly those identified as Secondary or Primary in "quality" level to make it more of an automated process). GEDCOM files (which may be classified in quality as either Unreliable or Questionable), may not warrant an increase in rating, because they might be considered basic, non-value added information. But they are still data references (if not actual sources -- as unreliable or questionable as they may be considered) that should be cited, recorded and maintained with the WeRelate page.
And about those evil "untraceable MySources," is my grandmother's Bible which records four generations of pre-1907 family births, marriages and deaths that are not recorded elsewhere, one of those? Should it be considered for removal as a source? Are the obituary notices that are recorded in my local newspaper for one day and on-line for possibly only seven additional days also considered as untraceable MySources"? And should they be removed as well? By its very nature a MySource is not publicly available, may not be readily accessible, and will probably not be traceable in the near future. Who is going to judge what is an acceptable MySource?
Whether or not a MySource adds to the rating value of a page is open for discussion, but please -- please stay away from talk of removing sources because of an unlying bias or suspicion. --BobC 13:12, 29 July 2010 (EDT)

My proposal is for a rating system to be as simple as possible.

I did not envisage downrating or removal of 'dodgy' sources in any way. I meant it to be positive.

Just to reiterate - what the rating should mean to someone viewing it - or seeing it listed in a seach report:

Rating () - page has been put in WeRealate but no-one has bothered to check or rate it. This is one of the keys - if apge has jist been 'dumped' it gets no rating

               (the page may be better than this but nobody has rated it)

Rating 1 - The page has been checked, probably by the page greator, and has met that persons personal standards. Or has been checked by an adminsitrator, and while the page looks good, meets basic standards, has not been checked or rated to be as good as it could be (WeRelate rating 2)

Rating 2 - Page (and the ancestor referred to) has been researched bey a 'competent' WeRelate conrtibutor and has met WeRelate common standards - that is the page is as good as it can be, and all lines of investigation have been covered. Possible Genealogical ambiguity has been researched and noted. The aim would be for all pages is for to reach this standard

please note that an ancestor of census era would have a lot more sources than one of Parish register era to meet this standard - so its not purely the numner of sources)

Rating 3 - Meant to be a rare rating. The page meets rating 3 standard and is also a page (ancestor) of particular interest - for example some of the feaured pages we have seen. To be awarded by advanced contributors or administrators only.

To a certain extent its self rating, but in order to rate your own conrtibutions at rating 2 or 3, the WeRelate community has given you apersonal ratinf which allows you to make that rating award. To recieve the competent award - you need three things - 1. An understanding of the Page rating 2 and the genealogical concepts behind it. 2. A better than beginner knowledge of the use of WeRelate 3. An undertaking to apply the standard consistently

I hadn't thought that, as you note, people might see the rating system as "Brownie points" for me the rating system would act as a kind of 'to do' list ie I have all these rating () I need to look at, and once that is complete, how many rating 1 pages can I re-look at to get them to rating 2 ?--Dsrodgers34 20:51, 29 July 2010 (EDT)

Dallan, I see your point - there are nearly 2 million pages to 'rate'

One thought I had was that administrators could be armed with tools which could produce an appraisal of a tree automatically. Tha dministrator could then sample some pages in the tree and then have atool which applies rating 1 to some or all of the pages in a tree.

By definition, Rating 2 could not be applied until a page (and ancestor) has been taken to a high standard and checked by hand.

Conversely, one of the 'uses' I envisaged for ratings was for them to show up in all references to a page - for example in seach results and when listed on a reltives page.

This is like when an image shows up in a search list now - it indicates to the searcher that a page will be interesting to look at.

You could bypass my idea completely and have the search results indicate if a page has sources and /or narrative !--Dsrodgers34 22:30, 29 July 2010 (EDT)

On a slightly different tack, how doo people feel about the categories for such a rating ?

The ones I came up with are:

1. Sourcing. Accurate, complete, and presented to high standard

2. Unambiguity. No logical faults with the info (including sources) No sources which could /should apply to another ancestor (and vice versa) OR where ambiguity exists, a thorough discussion for all alternate theories - links to the other ancestor(s) to which the same ambiguity applies

3. Narrative. Quality and casting the ancestor in a positive light as much as possible - more onus for proof for negative comments. Probably a more subjective category

I'm not an advanced genealogist. Surely there are other categories--Dale Dsrodgers34 23:08, 29 July 2010 (EDT)

I've been mulling this over and I keep coming back to the same question: Why do we need a rating system? Can someone explain to me in 100 words or less why and how a rating system would improve WeRelate? I'm just not getting it. -- Amy 07:47, 30 July 2010 (EDT)

If the system is not completely automatic based on published credentials, it is too susceptible to opinions, fads, and personal quirks. Some pages I have seen that rate websites as primary, and contemporary data as questionable (probably because the websites provides all the data about the person, while the contemporary data just gave one fact???) Dallan's automated proposal seems acceptable if he wants to bother.

This is hard, though, as all sources, even "primary" ones, potentially have all sorts of detailed issues (were vital records published from the original or the copy of the original, was the will the recorded one or an original document) and these issues would make any rating system either too simplistic or too onerous. And rating sources overlooks the importance of the separate act of applying that source to reach a conclusion.

Ultimately, you can't rate truth, and even the highest rating is no guarantee of correctness. So really, an interested person has to read the page thoroughly, and make their own judgment. Even for a bad rating, you have to analyze the page to ensure the stuff you want to add is better, or just more of the same. So, except as a way of educating users who don't know what a good source is, or think the first source they find is adequate, this doesn't strike me as being worth the effort. --Jrich 08:58, 30 July 2010 (EDT)

I'm agreeing with Amy. I can't see what this would add except more complexity and more things for people to argue about and cause hurt feelings. I have no idea how I would rate my own pages, or why I would want to spend time on this rather than working on the pages. This would be a distraction for me that could actually bring quality down.

I've recently seen a few gedcoms that vividly illustrate the point that a lot of sources do not equal good work. I think we get too caught up in quantitizing. The validity of the data AND the application of the data to the problem at hand can only be assessed by careful analysis. It's hard to try to make WR work like Wikipedia and other sites. An active genealogist is working with thousands of pages, not the small handful done by a wikipedia subject expert. We also need to realize that standards vary from person to person. Most people think they're 'doing good'. --Judy (jlanoux) 20:53, 30 July 2010 (EDT)

In my opinion, the idea of rating pages (at this point) may be better suited as an internal tool for nominating pages, where the automated method Dallan is proposing would serve as a helpful guide for Delijim and other administrators in highlighting pages worthy of further review and nomination by automating some of the Genealogy Well Done criteria factors.
Those criteria for "genealogy-well-done" include the factors listed below, most which could be quantified to some extent and computed automatically to come up with a point-value tally for further visual evaluation:
  • Makes good use of primary or original sources -- limited reliance on secondary sources; no reliance on tertiary sources.
  • Shows a reasonable exhaustive search of the relevant source records.
  • Provides analysis of the data to "make the case".
  • Considers alternative viewpoints, and addresses conflicting ideas.
  • Makes good use of narrative to "tell the story".
  • Provides background information to place the story in its historical and social context.
Add to that some of the other qualification ideas stated earlier here in this topic such as photo count, quality of sources, number of facts and events, watchers, and number of "What Links Here" links, and it might serve as a good shot in the arm for the featured page candidate process.
What do you think? --BobC 22:58, 30 July 2010 (EDT)

After reading the above comments, I think we're talking about two (non-competing) ideas:

  1. The original proposal: a way to highlight "genealogy well done" pages. This has to be subjective, would be conferred by a human being, and would put the page in consideration to be a featured page.
  2. My proposal: a way to encourage people to add sources by making a game out of adding sources, pictures, biographies to pages, where you get a point for every source/picture/bio you add to a page (but maybe only if the page has less than N items already).

Initially I thought we could kill two birds with one stone but after reading the comments, I don't think we should try.

I don't mind having a subjective way to highlight "genealogy well done" pages, and I think the criteria specified above are good. I'm not sure how many people will spend time reviewing other people's pages. But encouraging people to give "genealogy well done" awards to pages that they believe meet the criteria seems like a good idea. Bill has created Template:Genealogy well done, source use and has applied it to a few pages. It could be nice to expand this practice of giving awards as people have time -- increasing the pool of featured page candidates would certainly be nice. If people are interested in reviewing pages, we could say that any page that anyone adds to the WeRelate:Featured page nominations list would get reviewed by people in the "reviewers" group, and pages that meet the above criteria would be given an appropriate award. If anyone is interested in doing this, please let me know.

I could certainly use the criteria defined by User:BobC as a way to suggest pages that might be added to the featured page nominations list - this seems like a great idea regardless. We need a better way to find pages to nominate.

I do think having some way to encourage people to add sources/photos/bios is a good idea, but it's not synonymous with "genealogy well done". I wouldn't want to force people to determine whether a source was a good source or not, and I wouldn't want to encourage people to add bad sources to pages just to up their score. This is a long-term proposal, but I'm interested in people's thoughts on how to encourage people to source pages...--Dallan 16:40, 5 August 2010 (EDT)

I agree its a longer term, lower priority issue. I thank all for the feedback, I agree with all of it.

I just wanted to comment about the comment it would be extra work when theres lots of work to do on thousands of records.

Personally I would use it as a to-do list. In a way the ratings I described describe the 'progress' of a particular page. The maturity of the page as a genealogical document so to speak.

If I've uploaded a page, but not checked it, its not rated.

If I've checked it, and it seems to have a fair sprinkling of sources, which seem to be logical. and its well presented, before I save it, I give it a Rating 1

Later on, If I have returned to the page, and taken to its conclusion (eg as many primary sources as possible. I give it a rating 2

In rare cases, where a page is an outstanding example, plenty of narrative. It could be given the 3

Its self rating, but the rater needs to demonstrate certain standards themselves to award the latter two ratings. As WeRelate matures, the standards become better defined

As a 'to do' list, if I could list the pages I am interested in , I can see where I need to put some effort in on standards. At any one time we would have pages at different levels of maturity. This is an aid to seeing that. I suppose it could be done as a 'category' really - but I was just floaing the idea to see if others were thinking the same way.

Overall ? its a standards system which could be used to support claims to be a premier site in terms of quality, if not quantity--Dsrodgers34 05:52, 6 August 2010 (EDT)

How do I correct the google image location for a place? [27 July 2010]

The place 'Map of Bel Air, Fairfax, Virginia, United States' is off by a mile or so, SSW at Latitude: 38.85 Longitude: -77.167.
So is TGN.
Bel Air, VA. should be @ Latitude: 38.861937 Longitude: -77.174492
When I browse there directly by Google, it is correct.
What goes? How do I fix it?
--Wikid 14:42, 15 July 2010 (EDT)

You can fix the coordinates by clicking on Edit on the place page and typing the correct values into the Latitude and Longitude fields. --Jennifer (JBS66) 16:33, 15 July 2010 (EDT)
According to City-Data.com and the Washington Post, Bel Air is a neighborhood of Falls Church, Virginia, and according to current WeRelate placename policy would not be entitled to its own placename page. --BobC 20:17, 15 July 2010 (EDT)
On the other hand, Getty includes it, and Wikipedia calls it an unincorporated community in Stafford County. It seems like this one could go either way.--Dallan 18:13, 27 July 2010 (EDT)

Something wrong with this page ?? [6 November 2010]

There is something wrong with the Family Page Family:David Jackson and Mary Morrison (1) and I don't know what it is.
The children aren't listed as they are on other pages.
When editing the page, the whole window is too wide and one must scroll over to edit the page. Is very difficult to see the whole editing window and the scroll down button at the same time. I'm using IE7.
Can somebody tell me what to do to fix it or better yet, just go ahead and fix it! Janiejac 14:15, 24 July 2010 (EDT)

It is not clear to me exactly what is the problem you want fixed is.

The children look funny because none have birth and death dates except one birth date that is a year only and no places at all. This causes those columns to be very small since very little data needs to be displayed, but it appears that everything is present.

Some of the formatting issues in the original posting, the long lines and section header not working appear to have been fixed?

The only thing that looks wrong to me is the lack of the "Personal History" or "Family History" header, but that doesn't seem to appear on any page now that I check, so I wonder if this was a recent change by Dallan, or if this is a problem? It is not a problem until you add your own sections, like your "DNA", and then it means the first part is unlabelled, which looks a little funny. --Jrich 10:18, 25 July 2010 (EDT)

The page width looks OK; it is when I go to edit the page that the problem with the width shows up. It was when I added the DNA section that I had the problem and it is still a problem. (Yes, I figured out what was wrong with the DNA heading and fixed that.)
I want to invite the members of that DNA group to view the page; perhaps they will stay around to add something :)--Janiejac 15:55, 25 July 2010 (EDT)
It seems to me to be the same width as all the other Family and Person pages, which is wider since the new look appeared. I think it is too wide in that I have to position the editable text window just so to get all of it on my screen whereas before it seemed less wide, more like the lesser width that gets used when I edit this here Watercooler page. I thought when I looked at it yesterday, though, that it was way too wide, with a scroll bar across the bottom, and it does not seem to have that problem today. --Jrich 16:50, 25 July 2010 (EDT)
I just found a problem that could cause the Person and Family edit pages to be unnecessarily wide. I'll fix it later tonight. They will still be wider than I'd like, but fixing the bug will be a definite improvement. Later this year I plan to re-work the edit screens.
The system doesn't add a heading above the personal/family history section by default. I figured that maybe some people wouldn't want the heading, and if they did they could add one themselves. That might be a bad assumption though; should the system add a heading above the history section if the history section doesn't already start with one?--Dallan 18:13, 27 July 2010 (EDT)
Yes! The editing family page is much better width now. Thank you! And about the heading; I think it would be good to have them there automatically. It didn't enter my mind to add one myself. But it is not something I feel strongly about.

Tables [29 July 2010]

Hi all! Just noticed something weird happening to wiki tables on my pages. Borders that were once there are not showing anymore. On this page Lucy Courrege, the right borders are missing where they once were. Other tables have the bottom border missing. And others have the vertical line between table cells missing. I have tried to find a trend so that I can figure out what is happening. And what's weird is that they used to show the borders and I don't think I've done anything different. The tables work for me with straight text in them, but the borders start disappearing once I start putting line breaks or any code. Anyone else having this problem? Thanks is advance everyone for any help! :) UPDATE: I've been looking at other pages, and I'm seeing the same thing there. Do you think something might have changed in the wikitable class? Annette-- Aberksan

Can you tell me what browser and OS you are using? I just looked at the page in IE8, Firefox 3.6, and Chrome in Windows 7 and the borders all appear to be present. I made a couple of changes to the style sheet so the image galleries look better.--Dallan 21:48, 27 July 2010 (EDT)

I am using Firefox 3.63. It does seem to be ok in IE. It was looking ok until yesterday in Firefox. (Or maybe it was this morning that I noticed the difference.)--Aberksan 22:32, 27 July 2010 (EDT)

I'm not sure what's going on. It looks fine for me in Firefox. Can you tell me exactly which borders are missing? Also, can you try forcing a refresh (control-F5 on Windows or hold down the command key while clicking the refresh button on a Mac) and see if that fixes the problem?--Dallan 23:26, 27 July 2010 (EDT)

OK. This is really bizarre. I took some screenshots of the featured page of the week -- and the table borders are showing in the screenshots. screenshot. Yet, the border-right in this instance is not showing on my screen -- and the borders were showing before today. Very bizarre indeed. I guess if everyone else is seeing everything fine, then I won't worry about it. Thanks for looking into this.--Aberksan 23:52, 27 July 2010 (EDT)

I think I figured it out. I examined my code and cleaned up my styles in the wikitables. That fixed it. I've heard that Mozilla is not as forgiving of errors in code as other browsers. And I'm running the newest version of Firefox on Windows 7, so maybe the combination was not able to "forgive" my sloppy code. Thanks again! :)--Aberksan 23:04, 28 July 2010 (EDT)

Need help finding an example [14 August 2010]

I'm finishing up the Powerpoint for the presentation on WeRelate that I'm giving next week at the FGS conference. (I hope to see you there!) I'd like to find an example of a Person page that has at least 3-4 people watching it. If any of you could point me toward one, I would be most appreciative! -- Amy 22:38, 13 August 2010 (EDT)

Most of the Mayflower passengers have several people watching them. A good one is Person:Francis Cooke (2). --Jrich 23:03, 13 August 2010 (EDT)

I've found a few others:
Good luck and have fun. --BobC 00:03, 14 August 2010 (EDT)
Thanks, both of you! Those were just what I was looking for. -- Amy 07:06, 14 August 2010 (EDT)

Suggestion about deletion rules [25 August 2010]

Here is the log from a deleted page:Deletion log * 15:41, 24 July 2010 Siusaidh (Talk | contribs) deleted "Family:John Doane and Hannah Hobart (1)" (deleting tree) Page history * 15:36, 24 July 2010 . . Jrich (Talk | contribs) (Propagate changes to Person:John Doane (16)) * 04:05, 19 June 2008 . . Jrm03063 (Talk | contribs) (Propagating changes to a family member) * 04:05, 19 June 2008 . . Jrm03063 (Talk | contribs) (Propagating changes to a family member) * 20:59, 17 December 2007 . . Siusaidh (Talk | contribs) (gedcom upload) Three changes were made to this page because people changed pages linking to it, but they were not added as watchers because they only changed the associated pages, not this specific one. However, those changes were made based on this page being there. Otherwise,there is a good chance the people might well would have created it themselves. They didn't bother because it was there, with the expectation it would stay there. When this person takes their ball and goes home (deletes their page), it leaves a hole with loose ends dangling. This is frustrating.

I was wondering if deletion could be blocked if other people had propagated changes to the page, or at least, the data deleted but a skeleton page left in its place? Either that, or offer a choice to watch all pages we propagate changes to so we can protect them from removal? --Jrich 16:48, 17 August 2010 (EDT)

Yes, please! I'd prefer the former - I'm watching some 5-figure number of pages primarily to prevent their deletion already. I come across that user regularly, so I'm sure there are any number of holes now in various families I've worked on. --Amelia 16:58, 17 August 2010 (EDT)

The easiest way would be to establish rules along the lines of the following when a tree is deleted:

  1. If you're watching any member of a family, the family page won't be deleted
  2. If you're watching a family page, no member of the family will be deleted
  3. If you're watching a person, none of their direct-line ancestors will be deleted

We've talked about these rules before, but I haven't implemented anything yet. Are these rules what we want? Are there additional rules we should consider, like if you're watching any member of a family, no other member of the family will be deleted?--Dallan 11:58, 19 August 2010 (EDT)

I think that would answer the situation I posted so that's better. I might prefer if anybody else is watching any member of a family unit, the Family page won't be changed (i.e., any of its members deleted). So I am watching the husband, whom I might have added knowing he was father of one of the children, then even though I am not watching the family page nor the child in question, neither are deleted. But it may too hard to do that kind of check as you process the deletes. --Jrich 22:54, 19 August 2010 (EDT)

Ok, I'll also add:
  • If you're watching any member of a family, no other member of the family will be deleted

I'll implement these rules this Fall, either before or after the edit improvements.--Dallan 16:30, 25 August 2010 (EDT)

Proposal to edit matched pages after gedcom import is complete [26 August 2010]

Judy and I have been talking recently about how to address a couple of issues that happen during GEDCOM import. The issues occur when someone matches a person in their gedcom to an existing person, and then updates the existing person with the information from their GEDCOM.

  1. Uploaders sometimes make poor edits to the existing page, throwing away good information or replacing it with less-accurate information.
  2. Sometimes uploaders edit existing pages but then their GEDCOM is rejected due to quality issues. This leaves any MySource's that they've added to the existing pages as "red links".

A related problem occurs when, after you've matched and updated an existing page, you match one of the sources in your GEDCOM to a Source page -- the source is not changed on the already-updated existing page. (Similarly if you match one of the places in your GEDCOM.)

Here is the proposed solution: Allow people to match but not update existing pages during GEDCOM review. Once the GEDCOM has passed administrative review and been imported, a list of matched pages is generated as a user page. Each entry in the list has a link to a compare screen showing the GEDCOM information on the left and the existing-page information on the right so that the uploader can see the differences, and a link to a regular "Edit" screen for the existing page. There will also be a link that puts the comparison in a frame on the top of the screen and the edit in a frame on the bottom of the screen so the uploader can see the comparison while editing.

This new approach involves two major changes to the way things work now:

  1. You edit existing pages after the import is complete, not before
  2. You edit existing pages using the normal edit screen, not by checking and unchecking boxes.

The desired outcome is that by asking the uploader edit pages using the normal edit screen, and allowing them to edit existing pages at their leisure after the GEDCOM has been imported, the edits will be done more carefully and will reflect any source/place matching you've done during GEDCOM review.

Any feedback on this proposal?--Dallan 18:43, 19 August 2010 (EDT)

I get why, but my initial concern is that 1) this sounds like more work for those of us that know what we are doing; and, similarly, 2) more work for people who do not know what they are doing, who will thus not do the required updates. If those updates are more likely than not to be things we don't want, then I can live with more work (particularly given that it enhances the control), but are we at that point? Should we try more obnoxious warnings about editing first? Can a warning even fix the places/sources problem? --Amelia 23:58, 19 August 2010 (EDT)
I have mixed feelings about the proposal. First, there is both an advantage and a disadvantage to updating matched people after the GEDCOM has been loaded. The advantage is more control and more leisure to do it properly, as suggested (as well as this being a way to solve the problem with sources and places matched later). The disadvantage is that when I review the GEDCOM, I am already reviewing records to ensure the match is accurate and if there are discrepancies, I may have checked them out to ensure that they do not invalidate the match. I would like to complete the update while my head is still wrapped around the reasons for any discrepancies.
The other issue I have with the proposal is that it would require a normal edit rather than a version of the merge. This goes against the principle that the less data entry required, the less opportunity there is for data entry error. If you do change to require an after-load update of matched individuals, please do it in the form of a merge (using information from the GEDCOM file). I assume the user could always do an edit after the merge, as they would after a normal merge of duplicates to complete any cleanup.
In an ideal world, we might have both options - that is, the GEDCOM review would continue to work as is (with a few minor changes, as I will suggest below), and the new after-upload review would allow users to easily find all individuals/families that were matched/updated during the upload, and provide an edit button for each, for easy cleanup. If the latter review could exist even if the GEDCOM upload was rejected (or aborted), it would provide users a quick way of finding all updates (from matches) that need to be undone (or at least cleaned up).
Here are the changes I would suggest to the GEDCOM update. I used it for the first time yesterday and found it a bit confusing that no individual (People) matches were suggested until I had selected the Matched Families tab and processed each of them. My natural order, after doing one GEDCOM in Sandbox and one live, would be to process Matched Families first and then review People. So I broke the 'rules' that said to click on the tabs in order - and ended up with the unmatched source problem mentioned above. I would suggest changing the order of the tabs so that Warnings comes first, then Sources and Places, then Matched Families, then the rest. Unless, of course, I am missing something and don't understand what I am supposed to be doing on the People tab and why I should do it first. (I did not find the need to review each person, once I saw that the matches I had already approved on the Matched Families tab showed up and had checked a representative sample - was I supposed to do something else?) Then I would add notes in the instructions on why Sources and Places have to be matched before Families.
Another change, to help with the problem of not putting enough thought into a merge during the GEDCOM review would be to add another button for a match - 'defer decision'. This would allow someone to say that they are not ready to determine if a match is correct, but want to be reminded of it after the upload. It would do the same thing as 'not a match', but would add the potential match to a list for the user to review after the GEDCOM upload - just like a list of potential merges (and the user could then decide which to merge using the normal merge function). I know it seems redundant with 'not a match', but it might encourage people to think about deferring decisions that they are not ready to make - or even just to defer a complicated merge until later - and not require them to keep track on their own of required followup. I'm assuming that this would not be difficult to implement, as it would reuse existing merge functionality, and simply add a GEDCOM-specific (or user-specific) list as a front-end to the merge functionality.
I realize that my proposal, which still allows a merge during GEDCOM review, does not address the issues associated with rejected GEDCOM uploads (although by putting the Warnings tab first, it at least warns the user if there is a significant quality issue with the GEDCOM that might cause it to be rejected). Since I don't know how much of a problem that is, I can't comment on how important it is to resolve it. If you go with my proposed changes, you could encourage people to use the 'defer decision' button until they are familiar with the GEDCOM process and confident that the GEDCOM will not be rejected. I would have been happy enough to go that way for my first one or two small GEDCOM files, before starting to complete the matches during GEDCOM review.
I hope my suggestions are helpful in working towards a modified design. Thanks for what you have done so far, Dallan, and for being open to continued improvements.--DataAnalyst 10:45, 20 August 2010 (EDT)

I like that proposal if for no other reason than adding new pages is the least harmful activity, and then the harder activity of changing data is done after some experience comparing is gained. If the person gets discouraged half way through and leaves, less harm done. I also think it is in some ways more intuitive, since it is obvious that the adds don't get done until everything is completed, so one would think the modifies follow a similar process. I would think expectations of GEDCOM users would favor doing the edits with a merge screen rather than an edit screen, to transfer the new data with the click of a mouse rather than re-entering, however, selfishly I like that too, thinking it will require motivation to change existing data, and force them to absorb the whole page, rather than just consider opposing single-item boxes one by one. --Jrich 13:04, 20 August 2010 (EDT)

I agree that we need to reexamine the current gedcom upload process.

I feel that some of the issues with Gedcom upload could be reduced if we required new users to use WeRelate first, before uploading. I think this would be a greater teaching tool than Gedcom help pages or warning messages. There is just too much information on the screen for people to take in - especially those who have never used the site. People think the first step to trying WR out is to upload their Gedcom. Then we become frustrated with them or call it "junk". Instead we could mentor new users and ask that they fulfill a certain quota of manual edits and new page additions. This approach, in my opinion, is more agreeable then asking they take a "test" on their knowledge.

Regardless of whether we ask users to match pages before or after their upload, we need to make sure these users understand what WR is all about. I can't think of a better way to "teach" them then to have them learn by doing.--Jennifer (JBS66) 15:09, 20 August 2010 (EDT)

Personally, I would rather merge my matches after upload because I can see the whole record on the merge screen and can decide whether I want to just to add a note or perhaps the earlier record has better sources than mine. The upside is making GEDCOM upload easier and less confusing. The downside is what to do when folks don't bother to do the merging after upload. Is there a way to hold these potential matches 'in suspension' until they are merged after upload? --Janiejac 20:01, 20 August 2010 (EDT)

I have a few concerns that this proposal is trying to address...

1. New users register and immediately upload a gedcom. If they have a file with Family Matches they will plow on through without understanding the impact of their changes. I get bitter messages from people who pages got changed. But in the current system, the changes are made to the existing pages before any administrator sees the file. Even if the file is rejected, the changes stay.
2. A lot of Family Matches take time to do. And it gets confusing when the existing pages are in 'limbo' with the facts changed, but the sources haven't come along. People see their pages changing and start to re-edit before the import process is completed. A lot of mistakes get made at this point. It would work more smoothly if the automated portion was finished and then you could work on the updates. Consider that most gedcom imports are done by raw beginners, not experienced people like you.
3. It would be great if all new users got familiar with the system mechanics and philosophy first, but we have no way to judge when someone is ready. A user could review the system, memorize the help and be thoroughly ready to upload the minute he registers. Others may never understand the system without some mentoring.
4. To address Janie's last question: The potential matches would be held forever. A user page would be created listing them for you to work through. You can take your time, make notes, mark them when done. There's no time limit. It's your user page.
5. The current gedcom process lets a new user make changes to hundreds of pages with a few key strokes and they are unsupervised during this process. The idea of deferring updates until after import is that it will slow them down a bit and give you time for damage control. It is also much easier to make good decisions when seeing the real page. Merge check boxes may be quicker for you on the common list of facts, but do not work for content-rich pages. I think the proposed approach would get the new users involved in the community, rather than being considered a vandel by changing existing pages.
6. The ideal would be the user imports into a private wiki and then merges pages using the merge process. But that won't be ready for a while. We need something now to stop updating existing pages almost blindly with the gedcom import.

--Judy (jlanoux) 02:29, 23 August 2010 (EDT)

Understood that bad blind uploads are a messy problem when it happens. Can someone quantify it? I'm watching something like 13k pages, and I see newbie gedcom updates maybe once or twice a week to less than five pages, and I can't remember the last time someone changed something incorrectly, so I have trouble weighing the advantages of this fix v. its disadvantages.--Amelia 09:30, 23 August 2010 (EDT)
many files that I'm reviewing have family matches. I haven't counted the files. But the real quantification comes in that someone can blindly update 250 pages at a time. You don't even know it's happening until it's too late. And it happens before the admins review the file. Right now, we have having a spate of files that get rejected after the family matches have been done. This means that someone with poorly assembled families has possibly updated a lot of pages. --Judy (jlanoux) 22:57, 25 August 2010 (EDT)

Can't quantify it, and I am unclear how much this proposal will help. I do think it is non-intuitive that adds get saved up and done at the end, but changes are done real-time. From a computer design standpoint, this is a massive synchronization issue threatening data consistency in a big way. In terms of errors, I am in favor of anything that slows down people loading GEDCOMs. About once a month, on average, somebody messes up a family I have worked on (my watchlist very close in size to yours), or more. Lately it seems like there was a flurry, being three or four just in the last two weeks. One recent user messed up several families. More users, and this will happen more often. It won't take many such events to soak up all my discretionary time, preventing any new work. --Jrich 11:46, 23 August 2010 (EDT)

I like the idea of holding the match/merge until after the GEDCOM has been imported. As others have pointed out, it is not intuitive that edits and merges are done in real time while additions are done later. If there could be a list of possible matches that would appear on the person's user page (perhaps on Talk?), that could serve as a reminder that they should go back and review those. Would there be a way to automatically notify the watchers of the "possible match" pages that a new possible match has been uploaded? I know we can run "Show duplicates," but how often do people do that? If we could notify those people that one of their pages is a possible match for a new page, perhaps that would preempt some of the over-zealous merging that sometimes occurs. -- Amy 22:35, 23 August 2010 (EDT)

On reflection, I like this idea - don't even present matches for review (other than sources and places) until after the GEDCOM has been loaded. This addresses my concerns, and also solves the problem of sources being matched after families are matched. Assuming that Show Duplicates uses the same algorithm as the matching of a GEDCOM file, all you would need to do would be to put a reminder on a person's Talk page to run Show Duplicates (with a reminder that they have to wait a day). (I've never had results when I run Show Duplicates, so I am assuming there is an easy way to intiate a merge from the report.) In terms of alerting others to a potential match - that would be great if easy to do - especially if you could flag the page of each potential match and then automatically remove the flag when the merge is complete or when someone selects 'not a match'. This would probably require the 'flag' to identify the title of the potential match, so that it could be accurately identified for removal. (Hope you don't mind me going into 'detailed design' mode - I have trouble resisting.) --DataAnalyst 21:23, 24 August 2010 (EDT)

Modified proposal [8 October 2010]

Thank-you for your comments! (That's what I love about WeRelate - everyone pitches in with their ideas.)

I think we need to do matching prior to gedcom upload. We don't want to create duplicate pages and rely upon people to click on "Show duplicates" to clean them up after-the-fact. By requiring people to do matching prior to gedcom upload, duplicate pages generally won't be created. We can then instruct people to do merging -- updating the existing pages with information from their matched gedcom pages -- after gedcom upload.

For merging, we would create a list of all matched families on a user page. In this modified proposal, clicking on a link in the list would open up a 3-pane window, with

  • a list of family members down the left-hand side,
  • the existing wiki page for the selected family member on the top,
  • an update screen on the bottom.

A top-bottom separator bar could be moved up and down to show more of the existing wiki page or more of the update screen. Unlike the current update screen, the update screen would list the changes for just a single person -- the person selected on the left-hand side. The left-hand panel would also list the family page, and if the family page was selected then the update and wiki panels would be for the family page. Merging a family would involve doing the following for every person in the family: looking at the existing page and the changes from your gedcom in the update screen, checking the boxes in the update screen next to the information you wanted to add, and clicking the "update" button.

One benefit of this approach over the previous proposal is that you could either edit the existing wiki page or use the update screen to make your changes - your choice. And if you used the update screen you'd see the existing wiki page, both before and after you applied your changes. I'm wondering if this gives a good compromise between the speed of checking boxes and the need for people to see what effect they're having on the existing page.

We might also introduce the concept of a trusted uploader. A trusted uploader could be given extra privileges, for example:

  • Only trusted uploaders could use the update screen; other uploaders could see the update screen but would have to edit the existing wiki page and copy+paste their changes.
  • Only trusted uploaders could uncheck boxes on the update screen to remove data from the existing wiki page; other uploaders would have to edit the existing wiki page to remove them.
  • Only trusted uploaders could merge prior to importing their gedcom - with a warning about sources/places needing to be matched beforehand; other uploaders would have to wait until after their gedcom was approved and imported.

An uploader could either be considered trusted after their first gedcom was approved, or only if an admin manually gave them that status.

Introducing trusted uploaders introduces additional complexity though - we'd have to explain to people what a trusted uploader was and how they could become one - so another alternative is to not have trusted uploaders and say that:

  • everyone can use the update screen,
  • everyone can uncheck boxes on the update screen to remove data from the existing wiki page,
  • nobody can merge prior to import.

Regarding the tab order, I could move warnings before people and families (would others like to see this as well?), but I think it makes sense to keep people and families before family matches. The main purpose of the people and families tabs is to allow the uploader to see what their wiki pages will look like, and optionally edit them, prior to the import. I'll try to make that clearer.

Thoughts?--Dallan 16:11, 26 August 2010 (EDT)

Re Tab Order

I'm not sure I understand the interactions of doing them out of order. That's probably why gedcom imports seem random to me <g>. I do jump around. I find it best to do Family Matches (not updates) first. Then when I'm reviewing Person and Family pages I can see which are existing pages. At the end I go back to do updates if needed, but usually just edit the existing pages manually and exclude the person. It's only quicker to use the update on trivial pages with only dates.

Re Warnings

It is awkward that the Warning tab does not indicate if a page is excluded rather than edited. Could the Updated field indicate excludes too? When reviewing, some users are excluding the 'bad' pages intending to handle it later. I think this is a good approach to handling warnings. But when I review, I still see the Warnings as bad pages.

Trusted uploaders

One gedcom would not make a user 'trusted' in my book. Users become trusted by regular contributions of a positive nature. If we do it, I wouldn't advertise it. I think the three points under "not have" above are acceptable. Not worth the development time which could be spent on private wiki <g>. --Judy (jlanoux) 11:10, 27 August 2010 (EDT)

I think I like this better, but will ponder. In the meantime, I wonder: how would severely restricting the ability to merge on upload affect the long-awaited update function where people update their "own" data with a new gedcom? It sounds like trusted uploaders would work okay (if a user doesn't become trusted in between, then we aren't too heartbroken if they can't update), but without that, would updating be really difficult?--Amelia 19:42, 27 August 2010 (EDT)

Good point. I'm thinking that we would treat gedcom updates similar to matches to existing pages: "untrusted" uploaders would have to wait until their gedcom was approved and imported. Then they would see a list of all pages that they'd updated (along with any newly-matched families), and clicking on an item in the list would take them to a screen where they saw the wiki page on the top and an update screen on the bottom. The update screen would highlight the information that was changed for the person between their current gedcom and their previous gedcom. Trusted uploaders would see the update screen immediately and wouldn't have to wait for the gedcom to be imported.--Dallan 17:39, 1 September 2010 (EDT)

Captilization of dates [25 August 2010]

I can't quickly spot a discussion on whether or not there is a documented standard regarding capitalization of dates - for the qualifiers such as abt, bef, aft, est, bet/and, from/to, and the months. However, my sense is that the de facto standard is to have the qualifiers in lower case and the months with an initial capital (e.g., "abt Dec 1690"). This would certainly be my preference, as I find that all caps feels like shouting and I don't like being shouted at.

However, my genealogy software automatically puts all dates in upper case (e.g., "ABT DEC 1690") in GEDCOMs and I don't see an option to override that. Could I ask that you add to your list of many things to do, to automatically convert months to mixed case (initial capital) and qualifiers to lower case? Thanks.--DataAnalyst 12:24, 20 August 2010 (EDT)

I'll add both to my todo list.--Dallan 16:30, 25 August 2010 (EDT)

A Promotional Suggestion [22 August 2010]

Well, FGS 2010 at Knoxville is finished (and so are many of the worn-out attendees . . .). What a week. Considering that the WeRelate booth was rather small, and not in a very prominent position, and not what you might call "glitzy," we had an encouraging number of people come by and listen to the pitch and ask lots of questions. Amy's talk on Friday morning led lots of people to visit, and so did word-of-mouth. I'll have to watch and see how many new folks register in the next couple of weeks. (At least one lady registered with WeRelate during the conference and immediately began uploading some information on Civil War burial sites.)

Several folks who came and got the sales pitch turned out to be program chairmen for their local societies and were enthusiastic about doing a program for the folks back home about this site. Of course, they don't know much about it yet, and asked if we (or Amy, since she did the talk) had a "canned" PowerPoint presentation they could use as a jumping-off point. Amy and Judy and I talked about that during a lull and it might be an idea worth considering, that "we" (Dallan, us volunteers, whoever) think about putting together such a package for the use of local groups.

Back when TMG was new, and there were lots of proselytizing enthusiasts, we did something similar for the user groups that were starting up around the country. I can see problems with making sure people doing such a presentation get their facts right, and understand the theory behind the site, and so on. Obviously, someone with experience actually doing things at WeRelate is going to do a much better job than a novice, no matter how experienced they are at genealogy. Something to think about, though. --MikeTalk 19:09, 22 August 2010 (EDT)

That's a very good idea. Amy has said that she's willing to share her slides (thank you Amy!). Amy or I will post them soon and then let's see where we can take this.--Dallan 16:30, 25 August 2010 (EDT)

Pages too wide again [26 August 2010]

I've been waiting for someone else to complain about the pages being too wide for the screen again. It's been this way for about a week. It is too wide when using IE7 and/or AOL. --Janiejac 01:31, 25 August 2010 (EDT)

They are wide on Chrome, too. -- Amy (Ajcrow) 07:40, 25 August 2010 (EDT)
Would you mind giving an example URL or emailing me (dallan at werelate dot org) a screenshot? I looked at and edited a number of pages in Chrome, IE8, and Firefox just now and didn't notice any problems.--Dallan 16:30, 25 August 2010 (EDT)
Of course, now the pages are working ;-) I went back through my contributions from yesterday and none of the pages that were wide then are wide now. The exception being the pages like Wyatt Earp that have formatted tables in the source text area, but I would expect that they would force the page to be wider than usual. -- Amy (Ajcrow) 07:37, 26 August 2010 (EDT)
The only problem I've seen is a recurring one, which I had expected. On the Wyatt Earp page and elsewhere, I've been using the <code></code> tag to force the formatting of the census listings I'm copying into the source text boxes -- and when there's a long list of siblings and kids on the right, the two often overlap. I don't really know a way around this, except for very substantial re-formatting of the census listings. It also varies with your personal browser settings. --MikeTalk 10:00, 26 August 2010 (EDT)
Yeah, code tags, wide tables, and urls not written in brackets (any long line of text without spaces so it can't be wrapped) tend to push things out and make the pages too wide. Not much can be done about. In 1-2 years, after people have migrated from IE7 to IE8, there is a solution for code tags, which wraps code lines only when they become too long, but the IE7 doesn't support it.--Dallan 16:27, 26 August 2010 (EDT)

Ancestry Magazine article [1 September 2010]

For those users who don't yet follow WeRelate's Facebook page... I just posted a link there to an article in the Mar-Apr 2010 issue of Ancestry Magazine that features WeRelate. You can find the article here. --Jennifer (JBS66) 14:02, 1 September 2010 (EDT)

cool!--Dallan 17:39, 1 September 2010 (EDT)

Standard for place names [27 November 2010]

I've looked on the help pages, but I don't see anything that addresses how a place page should be titled when the place has a word that is commonly abbreviated. For example, should we use St. or Saint? Mt. or Mount? Ft. or Fort? There is a place page for Place:Mount Olivet Cemetery, San Rafael, Marin, California, United States and for Place:Mt. Olivet Cemetery, San Rafael, Marin, California, United States, both referring to the same place. It's easy enough to merge these, but what is the standard? -- Amy (Ajcrow) 22:31, 28 August 2010 (EDT)

There is usually an official web page for a place and we use the version that they use. We had this problem with the Louisiana parishes since so many of then start with St. It's not just to abbreviate or not, but also these days periods are being dropped more often as punctuation is being simplified. --Judy (jlanoux) 10:55, 29 August 2010 (EDT)
I believe that I followed how the place was listed in Wikipedia when the place pages were initially created. And unfortunately Wikipedia isn't very consistent. I could see benefit to standardizing, since it avoids duplication. Perhaps we should say that ideally we don't abbreviate? Would this cause problems if we list a place as Saint X but it's known by everyone as just St X? I'm ok with Judy's suggestion as well -- go with the how the official web page for a place calls itself. If we do allow abbreviations, we should probably try to be consistent in dropping the periods.
Anecdotally, I've lived in St Paul, MN for the past three years. I was surprised to find out just now that the city calls itself Saint Paul on the official website. I've been abbreviating it. So even though I live here, I'm unaware of the "official" name of the city. Maybe saying that we never abbreviate place page titles wouldn't be so bad.--Dallan 17:39, 1 September 2010 (EDT)
Doesn't matter to me as long as I don't have to go change a few thousand pages. Spelling it out does avoid the question of whether to use a period or not. --Judy (jlanoux) 20:28, 1 September 2010 (EDT)
Spelling it out or abbreviating, either one but consistently, is better than allowing one form in one case, another form in another case, in terms of autocomplete and alphabetization when places are listed in categories and other places. --Jrich 22:49, 1 September 2010 (EDT)
I agree. I think we need to come up with a standard one way or the other. Not only will that help with autocomplete, etc. but I've seen websites where they're not consistent in how they name the place, so I don't think we can go by "what the official website says." -- Amy (Ajcrow)
The other thing which is slightly amusing about this place is that there was an even more abbreviated version redirected to the slightly abbreviated version! I've altered the pages so that the abbreviated versions are both redirects to the unabbreviated version. The most consistent policy would be to have the fully expanded version of the name as the page itself with abbreviated versions linked to that page as redirects. This also has the advantages that full stops in the abbreviations or not can simply be accounted for by creating multiple redirects. David Newton 12:34, 3 September 2010 (EDT)
Good point about how standardizing also helps with auto-complete. How about we say that our standard is to not abbreviate? David, would you mind updating the help page? I'll eventually write a program to automatically rename abbreviated place pages so we don't have to rename them by hand.--Dallan 16:59, 7 September 2010 (EDT)

I inadvertantly created two pages with the same purpose: Jackson in Virginia and Jackson in Virginia, United States. I will merge the info, but I am wondering which to keep and which to discard. I do see other articles, even categories, both ways. Have we come up with a prefered way of naming either categories or articles? My preference is to keep them just at the state level as adding United States to all states causes categories at the bottom on a page to looked cluttered and seems so unnecessary. --Janiejac 17:43, 22 October 2010 (EDT)

I believe the standard is to leave out "United States" for US states. That's the way the automatically-generated categories at the bottom of person and family pages work.--Dallan 11:27, 5 November 2010 (EDT)
That is how the categories currently work, but articles automatically generated from User pages include United States. I thought that we were going to make all of this consistent to include the country. --Jennifer (JBS66) 06:20, 19 November 2010 (EST)
Thankfully the automatically-generated categories for the articles also omit United States so at least the category names are all consistent. I agree it would be nice to make the article titles consistent with the category names. It's a big job to change all the existing categories though. Someday...--Dallan 01:25, 28 November 2010 (EST)

FamilySearch Record Search source formatting [28 November 2010]

I've been working with the beta site for FamilySearch Record Search, and finding some great new info for my family trees. FamilySearch has set up Collections, such as "Maine Births and Christenings, 1739-1900," which consist of all the transcribed data to date (from numerous source microfilms) in this category. Each transcription includes a reference to the source microfilm.

Although the Collection title would accurately reflect where *I* found the data, it doesn't really reflect the data source with any specificity. Thus, I've been inclined to source this data using the film number to identify the original microfilm used in creating the on line transcription, and then On line database details in the Volume and page field. See Family:Horace_Marr_and_Alfaretta_Holbrook_(1) for an example of the WeRelate citation format I've been using.

There is no doubt that as a transcribed database, the FamilySearch Record Search data is one step additional step removed from the original data. There are transcription errors, based on sources I've reviewed where I have access to the original, not the least of which is the transcription of old-style dating into the modern calendar without any adjustment (i.e. 11th month is NOT November in 1698...). But in terms of helping someone find the data source to fact-check in the future, it makes more sense to me to provide a specific source of the transcribed materials, along with clear info that I've used an online database, not the original written source. When I have a chance in the future to review the Source:Georgetown, Sagadahoc, Maine, United States. Town and Vital Records, 1757-1940, for example, it would be a lot easier to know upfront which items rely on that source, rather than having them hidden in the "Maine Births and Christenings" conglomeration of records.

Does this make sense? Or should I be more truthful (and perhaps less accurate) and create citations using the name of the online Collection instead?

For examples of how this has been handled in other similar data situation, take a look at how we handle material from compiled Ancestry and NEHGS databases. Some have their own sources; others are cited by their original source and use the "online database" in the volume field to indicate where the person using the source obtained their info.

I'm not sure that any of these examples really get at the situation with FamilySearch Record Search, where numerous microfilm sources (some original town files, others transcribed books/indexes to vital records, are conglomerated into one large online index to a "Collection." Within a collection, there is often conflicting information regarding a particular piece of data; it is only by identifying the underlying microfilm source that one can make an assessment as to which source is more reliable.

So, what do you think? Has anyone else been working with the FamilySearch Record Search? --Brenda (kennebec1) 13:04, 27 September 2010 (EDT)

I too have been using this new online source gratefully. I would worry a little bit about say source "microfilm number X" as a source. I thought I heard that the Salt Lake Library on occasion changes the numbers on the microfilm. I too now have a long list of microfilm to order so I can get copies of the paper sources. I think so long as you are clear in the WeRelate citation it should be OK. I don't think we have a community source though for this. An example might be "Database name - XXX" +"Repository - website name" plus for the source "this cites LDS microfilm Title X, Page X, source listed as "John Doe married Jane Doe Date Location". That way you or others if they wish to order the film will know what to look for. Then after you order and make a paper copy of the microfilm source you can add the microfilm source. Since many of the microfilm have more than one item, I too try to add that in the citation. An example is that I need to one day order a LDS microfilm that has three different "church of england" items so I can make a paper copy of the marriage. The database does not list which is the right location of the church they were married in only that it is in one of the three. Looking forward to other WeRelate User's input. Debbie Freeman --DFree 13:53, 27 September 2010 (EDT)
I think the citation should distinguish between this source and the underlying records. Although a very useful source, I too have found errors, some less than expert interpretation of handwriting, even some intentions mistaken apparently entered as marriage records. So it is important to make sure people realize it is not the "official" record. I think noting that the record cites film such-and-such in the text area, or one of the other fields is fine, probably useful in fact, but the main title ought reflect the FamilySearch Record collection. While the same is actually true of any published vital record as well, my impression is that the incidence of errors is a little higher with this source, possibly because a diverse group of volunteers was used to do the indexing. --Jrich 14:08, 27 September 2010 (EDT)
You should provide the source you used, but you should always include any references to the location of the original. There are two ways to do the citation. I prefer to cite the source used and then include the reference. But it is legitimate to cite the original and then put something like "as viewed on <url and cite>". I think the first method is a lot less likely to be misinterpreted and is the form that has been used by authors for years. --Judy (jlanoux) 15:52, 27 September 2010 (EDT)

I'm inclined to agree that Family Search Record Search is really a Repository, as Debbie suggested, rather like the Family History Library. Then each data base within the Repository would have it's own name (which it does), and for transcriptions a note pointing to the original source could be added, as Judy suggested. On the other hand, that wouldn't be necessary for sources which are digital images, which many are. My question would be, if a Repository page is created, how do you handle the fact that this is a beta site, and would the url change when it ceases to be beta?--GayelKnott 21:25, 27 September 2010 (EDT)

I talked to FamilySearch about this at FGS. They were expecting to have the new consolidated FamilySearch rolled out by Oct at the usual address. If you create the repository, you can use the beta address and then change it when the new site is done. --Judy (jlanoux) 21:42, 27 September 2010 (EDT)
Thanks, Judy. Will do.--GayelKnott 15:12, 28 September 2010 (EDT)
I doubt it will be October. It will probably be December or January. (I did the back-end search engine for them, so I have some inside information :-). What you may want to do is use the Template:fscollection that I just created -- feel free to modify it or create a different template. To use it, insert {{fscollection|collection-id}} into any page, and you'll get a link to search the collection. Then when the URL changes, you just have to change the template and not every page. The collection-id is the 7-digit number following the letter "c" and before "&hash=" in the "Search this Collection" URL.
I agree that creating a new source for each collection seems to be the best way to go.

I appreciate the input, tho I'm a bit disappointed that the consensus seems to be that I should be creating a source for the FamilySearch Record Search databases, as that is a bit more work (!! I say, wryly...). It would be nice if there was a list somewhere at FamSearch of each of the source records/microfilms used in each of the so-called collections, as one of the things that makes using the Collections as sources a bit more difficult is that a good use of the sources ought to (I think) refer to the source microfilm as well, as that is a more "primary" source than the sometimes poorly indexed Collection, and if someone want to double check the info on WeRelate, they will get much better info by looking to the source of the online index than to just the index itself.

Anyway, adding info on the source microfilm in the text field involve a little more cutting and pasting, that's all. I'd like to set up source pages for the Collections that include as much info as possible about what is included in that collection; though perhaps a link to the FamilySearch wiki page for the collection would be enough in some cases.

That's what I would do -- let the FamilySearch wiki people go to the work of figuring out which microfilms were used in each collection. It doesn't seem to be a simple thing to do, and they're the ones in the best position to do it.

I know that for Maine, the vital records are divided into three collections: "Maine Births and Christenings, 1739-1900," "Maine Marriages, 1771-1907, 1739-1900," and "Maine Deaths and Burials, 1841-1910, 1739-1900." Each collection includes many individual town records (filmed at town offices) as well as other published compilations of records (i.e."Vital records of Georgetown, Maine to the year 1892."). In many cases, there is conflicting information from multiple sources (different towns, and town records vs published compilation records). Assessing the reliability of the information requires knowing where the index came from, it seems to me.

I'd like to set up a "How to use FamilySearch Record Search sources" help page; I think that could be useful to general WeRelate users. Maybe I'll try to draft something that explains a bit about the index and its strengths and weaknesses, and my understanding of how to cite items from FamSearch -- Does that seem useful to others? --Brenda (kennebec1) 16:38, 30 September 2010 (EDT)

Hello Brenda, Your plan sounds good. A tutorial on how to more effectively extract the information is a good idea. And how to go to the next step in your research is a good idea. It has amazed me for years how many people do not use the familysearch original website's library area. These new databases list the "Source Film Number". Then all you and I need to do is look up on the old website the "film/fiche search" to order the fische or microfilm, and find out what the source is. That makes my research more effective, and in the long term more affordable. Debbie Freeman --DFree 17:38, 30 September 2010 (EDT)
A help page seems like a great idea.

I'm a little late to this discussion, but I concur that citing both the "original" record (if possible) and a source page for the FS Collection would be ideal. My main reason though is one not yet cited -- the value of linking to the wiki page for the collection source. As discussed above, there are weaknesses in some of the collections that could be identified, but more generally, it would be really handy to have a description on the collection page about what's in the database, and how to figure out where it came from. I've been using familysearch.org since it came out, and thought I had figured it out, but I was completely thrown by the new format and I'm still not sure I've figured out how to find the source of the information (and certainly not without at least three more steps than it used to take). In addition, those who are less sophisticated in their sourcing, or who have not yet figured out how to figure out the "source behind the source" are going to want to cite the FS collection. We should have pages for them. (We should also list FS as a repository where it's appropriate too.)--Amelia 20:33, 30 September 2010 (EDT)

As usual, I'm finding myself more and more confused by the discussion -- which suggests that having a "How To" page would be a good idea. Are we talking about the FamilySearch Record Search, the FamilySearch Library Catalog, the FamilySearch Wiki -- all of which are different and under different menus in the current page and format? And, in spite of trying to learn the new FamilySearch page while it's still in beta, I'm not at all sure how all the currently different pages will translate (or disappear) when the beta version ceases to be a beta version. I know I'm still having trouble negotiating my way through the new catalog listings in the beta version having learned the current catalog version so well. On the other hand, the record search functions appear to be more fully integrated. As to what will happen with the "Guidance" pages, where the Wiki page currently is, I haven't really explored that. And I'm wondering if the new FamilySearch page will also provide access to what is now NewFamilySearch, and whether that will end up under "Trees" on the new page. Maybe my confusion about this discussion will help clarify what needs to be in the "How To" section?
And just a reminder -- not all the records on the Record Search pages are indexs or transcriptions -- there are a lot of really good digital images of original documents, and I suspect more will be coming eventually since all the Norfolk (England) Parish Registers have been digitized as a trial project, as have the Chicago (Illinois) Births and Marriages, and at least some census records.
I'll chime in here with what I know: beta.familysearch.org is scheduled to replace www.familysearch.org around the end of this year or early next. It will not replace new.familysearch.org (nFS) -- that will remain separate. It's not known when the information in nFS will become public. Everything you can currently search on www.familysearch.org and pilot.familysearch.org will be searchable on the new website, except the user-contributed records in the International Genealogical Index (IGI). Those records have been copied into nFS, but they may not be searchable outside of nFS once beta replaces www. I believe that all records in the IGI that came from historical record transriptions have already been copied into beta. Search at beta.familysearch.org is be broken down into three areas: historical records (which gets everything from pilot.familysearch.org and Internet Indexing), trees (which gets Ancestral File and Pedigree Resource File - only Ancestral File is currently loaded), and the Family History Library Catalog. The beta catalog search has a ways to go before it's as good as the current catalog. Hopefully it will be much improved in the next two months.

Oops -- Amelia seems to have come in while I was typing. I agree with her comments about a Repository Page for Family Search (one currently exists for Family Search Record Search, without much commentary because it's all going to change soon), but once it does change, probably all sources found there (as opposed to what is found in the catalog) should probably also end up as sources. Not a job I imagine anyone wants to undertake.--GayelKnott 20:52, 30 September 2010 (EDT)

I'd say my thought in suggesting a "how to use" page was to focus on 1) what can be found at FamilySearch -- what are the collections; images and indexes and the differences; etc. And 2) once you have found it, how do you cite it at WeRelate so that others can find your sources - i.e. how to look up the source film and identify the original source (validity testing, as it were). And yes, it does now take about three more steps then it used to take...one of the reasons a "how to guide" might help.
Might be a good idea to integrate some of this info into a Template to use on each of the Collections source pages, based on Amelia's comments. I suppose waiting 'till the new system comes out of beta makes sense as well...
Another question: does there exist a mechanism for adding "new sources since last update" to WeRelate from FamilySearch Catalog or Record Search? I've added a couple of new FamilySearch catalog items that I've run across in my research and I was wondering if we'll automate source updating again at some point, or whether that would just cause more duplicate source and source formatting issues. I am sure there are many new sources at Ancestry.com as well as at FamilySearch... --Brenda (kennebec1) 11:42, 1 October 2010 (EDT)

This would be really great, as negotiating the new FamilySearch search pages (Record Search, Trees, Catalog, Guidance) is going to take a while to learn/relearn. My only, admittedly nit-picky, request would be to please refer to the Record Search as FamilySearch Record Search, rather than FamilySearch, since FamilySearch refers to a much larger collection of pages.--GayelKnott 12:10, 2 October 2010 (EDT)

If you'll manually create a couple of Source pages for FamilySearch Collections, I'll have one of my kids create Source pages for the rest of the 450 collections at beta.familysearch.org, and post links to their "contributions" page so people can help me monitor them. Getting new collections out of Ancestry will be more difficult; I'll need to think about this some more.--Dallan 14:12, 5 October 2010 (EDT)

Illinois, Cook County Birth Certificates 1878-1922 and Illinois, Cook County Marriages, 1871-1920 already exist.--GayelKnott 16:06, 5 October 2010 (EDT)

Ok, thanks. It will take them some time, but I'll have them start on it. Once they've done a few, I'll post links here so people can make sure that they're in a good format.--Dallan 16:21, 5 October 2010 (EDT)
Dallan, here are a couple of example sources (of the multiple database type): Source:Maine, United States. Maine Births and Christenings, 1739-1900 and Source:Maine, United States. Maine Deaths and Burials, 1841-1910. --Brenda (kennebec1) 16:02, 14 October 2010 (EDT)
The examples are both collections with images; I'll create a couple of sources without images as well. Right now the links on the Cook County sources are generic (to FamilySearch Record Search search page), rather than to searching that particular collection, which makes sense as the site and the links are in beta, but isn't ideal in the long run. Do we want to set up all the sources now? or wait until FamilySearch figures out what they are doing?
There are several types of collections, and the different types may need to be handled differently in setting up source pages.
  1. A collection of documents/images created from the originals by FamilySearch (like the Chicago collections). This may or may not have been indexed, and I presume the images may be digitized from the microfilm or may be actual scans of the historical records. Some of the image collections are of primary records (vital records certificates); others are images of indexes to documents, such as Prince Edward Island Baptism Card Index, 1721-1885
  2. A collection that is an extraction from someone else's index or image collection. These collections may include links to images off-site, along with the index to the records. See England and Wales, Non-Conformist Record Indexes (RG4-8) (National Archives, England) or Civil War Pension Index Cards (Footnote provided the index and links to images, which are from the National Archive, US).
  3. A collection (actually index) created [by volunteers] from a microfilm or digital scans in the FamilySearch Library. The easiest type of collection is one where the index has been created from one microfilm source. This microfilm source could be original documents (like "Alabama Deaths)," or it could be an an index/compilation of records source. I haven't found any of the latter yet, but I haven't looked through all the collections!
    1. A collection (read index) created from multiple microfilmed sources in the FamilySearch Library. This is typically the case with many of the State-wide vital records collections, such as Maine Deaths and Burials, 1841-1910. These indexes combine information from primary records (such as town records) with secondary records (such as the compilation of vital records for a locality published in book form, which may include family records, bible records, and other sources).
This last type of collections should have a link to the FamilySearch Wiki for the details of the collection, and maybe the easiest thing to do is to add a FSWiki link for all of the sources. Of course, there may be other types as well...
Of course, all the fine details and distinctions between these sources could also be handled after the initial source is created, as users edit and update the sources. I'm perhaps being a bit overly-thorough at this stage of the process, I suspect --Brenda (kennebec1) 12:44, 8 October 2010 (EDT)
Yeah, I doubt my children are going to differentiate among these. I was thinking I'd just have them create basic sources pages, which others could add to. I had hoped to have them add a few last weekend, but it didn't happen. They should add a few tonight though.--Dallan 15:45, 16 October 2010 (EDT)

Some examples are below. Do they look ok? Does anyone have suggestions for improvement before (a lot) more sources are created along these same lines?--Dallan 23:27, 18 October 2010 (EDT)

Hi, I just now noticed this entry at the Watercooler, sorry! You may notice that I've changed these sources slightly, and added a few more FSRS collection sources. I think that what you had first done was fine; I just got onto a little project of tweaking these sources to my particular desire for detail... I think I've now got a basic "blurb" for the FamSearch Record Search collections that are indexes from a variety of sources. But my "blurb" references the catalog, and uses the "beta" page link, which won't be permanent. Can someone with more programming understanding than I come up with a way to insert a generic link to the catalog (like Dallan did with the link to the fs-collection?
If so, feel free to borrow my blurb or, Dallan, you and/or your children can keep using what you had originally entered, and I'll come along behind you (someday) and tweak the entries to be individualized (I like to try to show, for example, related sources when appropriate). Anyway, I didn't mean to ignore Dallan's request for comments, and my changes weren't necessarily meant to be seen as a suggestion for a change to the generic source setup; I can see that any language that is unique to a particular source (i.e. location) makes the process of adding new sources much slower. --Brenda (kennebec1) 20:54, 19 November 2010 (EST)
Brenda, nice job on your text. I used it to create Source:Michigan, United States. Michigan Deaths and Burials, 1800-1995. I created a template for the catalog link and used it in this page. The template is {{Fscatalog}} --Jennifer (JBS66) 06:24, 24 November 2010 (EST)
Thanks! I'll have my children try to follow this example as they add sources for the online collections (which has been slow-going lately). I found a list of FamilySearch wiki pages for their online collections, so I'll have them add that link as well.--Dallan 01:25, 28 November 2010 (EST)

Watchlist/What Links Here [5 October 2010]

My watchlist is getting pretty large, hence taking more and more time to return (sometimes I get in two games of spider solitaire waiting for it!) Even in another tab, WeRelate won't respond to any other requests until the Watchlist finally gets displayed. I hope this delay is just affecting me, and not all WeRelate users? I assume there isn't any easier way to get this information? With a change of work habits, I could rely on the email notifications more and my watchlist less.

On the topic of watchlists, I was wondering if having the ability to get notified when the What Links Here list gets changed would be useful, or just more noise? Most of the time, I suspect this would happen when a will abstract or some other data gets added for person A, mentioning person B, and a link is added to point to person B's page. People watching person B would get a notification and possibly discover something about the person they are watching that was generated by research on another person. It seems to me that for Source pages, watching the link list would notify you every time somebody references the source. For a category page, every time somebody is added or deleted to the category. For a family page, every time a child is added or deleted. I can imagine this would be useful sometimes. --Jrich 19:31, 2 October 2010 (EDT)

The MediaWiki watchlist code wasn't designed to handle thousands of pages, like many people have at WeRelate. It's one of the things I plan to fix, but in the meantime I'm afraid you'll have to put up with it :-(. Being notified of changes to category members or what-links-here is also a good idea, but it's probably not going to happen for awhile. Getting large watchlists to return more quickly is higher in priority I think.--Dallan 14:23, 5 October 2010 (EDT)

Family Tree Explorer/Tree Management [16 October 2010]

For some reason, I got it into my head to try and play with trees. I went to a few individual pages, went into trees, and created a tree of all (i.e. 20 generations) of their ancestors. Unfortunately this got into medieval stuff, which I am not interested in, and I started getting all sorts of change notifications about people I don't know or care about. This added about 2000 pages to my watchlist.

So I tried to undo this the same way. I went to the page at the limits of what I wanted and tried to turn off all upstream ancestors. I unclicked all Trees and tried to update all ancestors from that point up. I was hoping it would remove all those upstream pages from any of my trees and also from my watchlist. Of course, it gave me an error message that I hadn't identified which tree I wanted.

Does this screen need to be capable of removing pages from trees and watchlist in bulk, the same way it adds them in bulk?

Another problem is I can't even figure out how the page I am getting messages about is connected to anything I care about. The tree I built is a collection of four unconnected ancestor collections, and it could be any one of the four. I am a newbie at Family Tree Explorer, but I thought this might be the tool to help me figure that out. It seemed like the graphical Pedigree and Descendants view over several generations would make my search for the connecting path a little quicker.

But while I could get the medieval page in the list view, and on the right frame of the window, every time I choose the Pedigree and Descendants view, it is still centered one my recent ancestor, not the medieval one. What I expected to happen was that if I brought up the person in the right frame (traditional Person page), whichever view I am using in the left frame would center on that person. But that did not happen and I couldn't tell from the help page how to make that happen. I tried right clicking on the person in the list view, choosing the option to make them primary, back to the Pedigree/Descendants view, and it's still stuck on my recent ancestor. Did I miss something?

I always use the list view rather than the graphical view, for when I'm working my way through a newly uploaded tree, doing clean-up and such. But I believe in both cases, FTE opens to whatever page was open the last time you used FTE and closed it. It doesn't care which page you happen to be viewing "outside" when you open it. That's actually useful when you just want to pick up where you left off the last time. --MikeTalk 10:30, 11 October 2010 (EDT)

Since the tree function gives us the ability to add to our watchlist all sorts of ancestors we aren't even familiar with, is there a need for some sort of relationship mapper that will find a path between any two pages, if there is one? --Jrich 00:27, 9 October 2010 (EDT)

Ditto the wish to be able to unwatch as easily as they got on the list.--Judy (jlanoux) 10:18, 9 October 2010 (EDT)
I think all of the things mentioned would be worthwhile. Would you mind adding them to the WeRelate:ToDo List? I'll add unwatching all ancestors/descendants of a person to my short-list.--Dallan 15:45, 16 October 2010 (EDT)

Adding sources to Personal history narrative within pages [21 October 2010]

In moving from completely ignorant to merely dangerous around here, I'm starting to find my way around and have some ideas about how things work. Right now I'm editing narratives within some person pages which need some source citations and the like.

While adding a source on a particular person, there are narrative items to add, and I would like to cite the same source I have entered above on BMDB items (e.g., the S1 source I have added to Person:James_Veatch_(8) ).

Is there a simple way to cite the entered sources in the narrative section as well as for the BMDB items? I looked for a way to do this or a discussion about it, but I unfortunately didn't find any information. It would be nice to have a triple bracket notation option, for example, that would use a source already entered for the page, superscript it, etc. Such as this: [[[S1]]] Thoughts?--glamberson 20:25, 11 October 2010 (EDT)

Help:Formatting#How Do I create References and Footnotes? is probably the place to go. You will probably find some tools there useful. Take a look at Person:Francis Cooke (2) to see an example using some of this (edit but don't save to see how things are done). --Jrich 21:04, 11 October 2010 (EDT)

By the way, something I just found out, if you use [[#S6]] and one of the earlier sources gets deleted, S6 gets renumbered to S5, but [[#S6]] won't. Therefore, it is better to use {{cite|S6}} which does get adjusted appropriately. --Jrich 23:08, 11 October 2010 (EDT)
I could have sworn that used to work (because it would show up as [[#S5|S6]] because only the portion next to the # was changed). Did it break in the redesign?--Amelia 00:49, 12 October 2010 (EDT)
I tested it on the sandbox, but now I can't repeat it. I think you're right. Don't know what I did. Sorry false alarm, apparently. --Jrich 01:09, 12 October 2010 (EDT)
Well, hmmmm...., there are some problems. [[#S6]] does get renumbered if you delete a source above it, but as a link, it doesn't work, either before or after the delete. There is no target "S6" to jump to, so clicking on it does nothing.
Apparently, since sources and notes were combined into one list, it seems you have to use [[#_note-S6]] for source #6 and [[#_note-N3]] for note #3. A little ugly, but that would be fine, but there's a twist. These don't get renumbered when a source above it is removed. So if I delete source #3, the page will still show [[#_note-S6]], and it will effectively link to what used to be source #7. --Jrich 17:17, 12 October 2010 (EDT)
Thanks a lot. One thing I clearly haven't figured out is how to find things :-\ ...
Breaking the [[#S6]] and [[#N1]] trick for linking to sources & notes was an unintended consequence of the redesign. I didn't realize it until now. The {{cite|S6}} and {{cite|N1}} approach should still work. I just changed the cite template so that the links are now correct. An even better approach now is to use the ref tag: <ref name="S1"/>. Using the ref tag causes a link to be added next to the source or note in the references section that points back to the place in the text from which the reference is referenced. That is, next to the source in the "References" section a link would link back to the point in the text where you inserted the ref tag. I can't make the backward-link work for the cite template unfortunately. Both the cite templates and the ref tags get renumbered when you delete sources/notes. (Would someone mind updating the help text about this?)--Dallan 15:45, 16 October 2010 (EDT)
I am working on Help:Formatting --Judy (jlanoux) 17:48, 16 October 2010 (EDT)

Judy thank you for working on this; Dallan made some adjustments also. But it still took me hours to figure out how to do this; not your fault I just do better with examples. Anyway the sample page has both type of sources; ones that already have a source number and others that do not. I added one source to this page that may be easier for people like me to follow. Check this page and see if it is done correctly: Jackson in Surry, Virginia. One remaining problem is that the header for Footnotes is not created correctly. The header still shows the equal signs. Thanks.--Beth 22:08, 20 October 2010 (EDT)

I did the Method 1. Method 2, I left it alone, but it is intended to mix the two types. Now I see that it needed changing too because of the redesign and the result is a lot nicer. But your example brings up an important point. We were assuming a Person or Family Page where there are database fields for sources. Your page is an article where source boxes aren't available. So we do need another item in Help to take care of this. You did great at figuring it out. The only change I might suggest is to use the term "References" instead of "Footnotes" for consistency with the Person pages. But the example does say Footnotes because that's the way it used to be before redesign. Anyone have opinions whether we want to change the Help example to say References? I'll give the Help another go to try to make it easier to read. --Judy (jlanoux) 22:33, 20 October 2010 (EDT)
Thanks. I changed Footnotes to References but I still don't understand why the header still shows the equal signs, at least on my browser which is IE8.--Beth 22:54, 20 October 2010 (EDT)
It was because the references tag was on the same line as the section header. Also, you only needed a level 2 header (2 equal signs) not 3, but that didn't seem to matter. I fixed it and it displays correctly now. Sorry I didn't catch that before. BTW you aren't watching the page. --Judy (jlanoux) 23:29, 20 October 2010 (EDT)
Thanks Judy for solving my problem. Think the page is correct now.--Beth 09:28, 21 October 2010 (EDT)

Related Names [5 November 2010]

There is a long list of pages for 'related names' linked to my Jackson page. These related name pages are empty and no one is watching them. They are at the top of and cluttering up my 'what links here' list. Would there be any objections to me deleting those empty pages? --Janiejac 21:20, 18 October 2010 (EDT)

You didn't give us a link to the page in question so I can't see what the clutter is. But if these are surname or given name pages, they can't be deleted. Those are used in Search. --Judy (jlanoux) 22:26, 18 October 2010 (EDT)
Woops, sorry, here is the page Surname:Jackson. If you click on 'what links here' from that page you see all those links to empty 'related name' pages and must scroll down to see created pages that do link to the Surname:Jackson page. I was just trying to eliminate having to scroll down to see what actually links to that page. I think we got rid of unused categories, why can't we delete unused surnames? The search engine would just come up with no results and anyone wanting such a page can create it. --Janiejac 10:07, 21 October 2010 (EDT)
I don't think categories are used by the system, surname pages are. So there are several problems with your assumption because of the way things work. There has been discussion of changing the way matching works, but we have to deal with the way it is now. You can't tell if the pages are being "used" because it doesn't leave footprints. Someone puts a name into the search engine and the program uses the list to look for alternate spellings. New surname pages are not created automatically when a Person is added the way categories are. There was an effort up front to create all of the available (mostly-English) surnames just as there was for places and sources. Users can add new ones, but it isn't automatic. Since I have a lot of non-English names, I've had to figure all this out and keep the pages manually updated. Most users don't need to bother because the original list is working for them.
I see that you have removed the alternate spellings on the Jackson page. There are many spellings of Jackson, and they really should be restored to this page. For example, when I search for my ancestor "John Jackson", I would want to see pages for "John Jaxon" as the name was often written that way in Colonial documents. Someone may have created a page using that name. If you have removed Jaxon from the alternate list, I won't see them and we would have duplicate pages.
Why are you concerned with the "What links here?" results? I see that you have links to the surname in place pages.

--Judy (jlanoux) 21:55, 22 October 2010 (EDT)

Thanks Judy for responding. Sigh . . OK, I added 'Jaxon' to the Jackson page as a related name because that sounds logical to me, but the surnames 'Coletti' and 'Giacone' don't. If I ever ran onto to those names while researching Jackson, I sure wouldn't recognize them as Jackson. You aked "Why do I use what links here?" I'm sure folks use this feature for many reasons. Can you tell me a better way to see all the pages I've created? I tried to put a category 'JanieTree' on my pages, but the consensus was that we should not have personal categories, so I removed that category and still need a way to help me remember my pages. Also, that list is often a way to navigate from where I am to a page that is linked for some reason. But that long list of names requires that I have to scroll way down or to the next page of links. Perhaps the list of names could be put at the end of the list instead of at the top if they are only there for the benefit of the system. Those names are really in the way and I don't need them. --Janiejac 23:59, 22 October 2010 (EDT)

Those names do seem pretty far-fetched. I wonder how they got there?
I don't think "What links" to a surname page is a very useful way to keep track of your own pages. And you're right, categories (and surname pages) aren't the best way to keep personal lists. There are a few ways to take care of your need to keep track of pages:
  • Just add all of your pages to a tree. Then you can use FTE to see the list of pages.
  • Create a Jackson project page using either a user page or an article depending on whether it is of general interest or is just your personal checklist. It seems most useful to me to use a project page to organize whatever it is you're doing. I use project pages to define what I'm trying to do and to corral the collection of pages to help keep track of where I am. Examples of things I'm working on are: McLuen_in_America an article and User:Jlanoux/Elliott Project a user page for a project that I'm still developing. --Judy (jlanoux) 16:22, 23 October 2010 (EDT)
I agree with Judy. The "Related names" should contain a list of all variant spellings of the surname that should be included in searches for "Jackson".--Dallan 11:36, 5 November 2010 (EDT)

Pedigree chart [5 November 2010]

I think the chart is a terrific addition and I'm getting used to it as I am to the whole WeRelate concept. However, when, on the chart, a name is too ;ong for the box a slider is introduced which obliterates any attempt to see the name underneath. Am I missing asomething or can this be discontinued? Bigdeacon--Bigdeacon 20:49, 22 October 2010 (EDT)

Not easily unfortunately.--Dallan 11:38, 5 November 2010 (EDT)

Search results [1 January 2011]

I am very frustrated with search results. Search results for sources do not seem intuitive enough. If I know the last name of the author and the location he was writing about, I should be able to find the title! If I am at google search and enter a search for 'Chalkley' with other words 'Augusta, Virginia', the first item that comes up is Chronicles of the Scotch-Irish Settlement in Virginia. But when I try the same search at WR I scroll through fifteen (15!) pages of results and this author and/or title hasn't come up yet. Here at WR, what comes up is a whole list of sources whose author's FIRST name is Chalkley writing about a whole other area, then a list a sources mentioning Virginia even West Virginia, but not Augusta County and not by Chalkley.

So I tried another search to see if this was typical. I tried searching for 'Morton' who wrote about 'Bath, Virginia' and the first two searches that came up were Source:Callahan, James Morton. Semi-Centennial History of West Virginia and Source:Callahan, James Morton. History of West Virginia, Old and New. My question is 'why are first and even middle names getting rated higher than last names of authors?! People do well to remember the last name of authors; don't ask them to remember just exactly how the author's name looks on a specific title. What I expected for Morton with Bath, Virginia was Source:Morton, Oren F. Annals of Bath County, Virginia and Source:Morton, Oren Frederic Annals of Bath County, Virginia. --Janiejac 15:29, 8 November 2010 (EST)

Why not try using Google's site search? Click the advanced link to get information. --Judy (jlanoux) 19:01, 8 November 2010 (EST)
Source search is a known problem. It's on the todo list.--Dallan 16:19, 10 November 2010 (EST)

Search remains a puzzlement! When I search for Thomas Jackson born in England, why is Thomas Jackson (3), (4) and (5) all born in Tennessee, listed before Thomas Jacksons born in England? I don't see any logic in this. --Janiejac 21:41, 1 January 2011 (EST)

Suggestion: need add source button [28 November 2010]

I wanted to add a source so went first to 'search' for it to see if it was already there. It wasn't, but there is no button on that search results page to 'add source'. So I had to go to "Add source" to type the info in a second time. Why not put a 'add source' button on that search results page to eliminate the duplicate typing? I know there is such a button when you are trying to add a source from the person or family page - but I wasn't there. I came to the site today just to add the source and so went straight to 'search'. --Janiejac 08:00, 15 November 2010 (EST)

Good idea. I'll add it to my todo list.--Dallan 01:25, 28 November 2010 (EST)

Article and category extensions? [2 December 2010]

I've been pondering adding a type of extension to the titles of articles and want to ask if this would cause unintended consequences. I have transcribed several deeds and wills. I thought to name the articles with this type of extentions:

  • Jackson in Virginia, Prince William_Will_Francis 1781
  • Jackson in Virginia, Prince William_Will_Samuel 1790
  • Jackson in Virginia, Prince William_Deed_Samuel 1815

Then I would create categories such as:

  • Category:Jackson in Virginia, Prince William_Deeds
  • Category:Jackson in Virginia, Prince William_Wills

I do not want to make the articles into Sources. The source would be where I found the original information. Is an underlined space acceptible for this use? Or should I use a period or slash? This type of extension will make it much easier to find these articles later. Wording them this way also would put all Jackson wills in this locality all together in the search results page. Comments? --Janiejac 15:19, 15 November 2010 (EST)

Janie, maybe I'm not getting what it is you're trying to do, . . . but why would you want to create a category for a single item? To me, "category" implies a collection of things. Also, I thought a category was meant to be use to more than one researcher. --MikeTalk 15:11, 2 December 2010 (EST)
I don't know about unintended consequences, but if these articles are transcriptions of single wills, why not just include them on the person's page? -- Amy (Ajcrow) 09:44, 17 November 2010 (EST)
Hi Janie. FYI, I received your email inquiry but have not had the time to tackle it yet.
Pertaining to your situation above, I see nothing wrong with you either adding your transcriptions as Articles or as Sources. Although if it were me, I would add them as "MySources," because they are personal documents relating to your family line of research in particular. I would then link where you actually found the wills and deeds as "Repositories." Regarding the categories, why not just categorize the documents (whether you include them as Articles or as MySources) under the Category:Jackson in Virginia Surname in Place category without the "Deeds" or "Wills" moniker? It would effective categorize all those articles (or sources) accordingly. --BobC 22:39, 18 November 2010 (EST)

Possible duplicate source [2 December 2010]

It appears that Source:Genealogical Society of Pennsylvania. Pennsylvania Genealogical Magazine, Volumes 1-39 may actually be a duplicate of Source:Genealogical Society of Pennsylvania. Pennsylvania Genealogical Magazine. It appears that the former source is just a digital reproduction of the first 39 volumes of the latter source. Shouldn't it just be referenced on the page of latter source instead of appearing as a separate distinct source? Moverton 18:31, 29 November 2010 (EST)

Yep, it certainly ought to be moved to the text box on the more general page. In fact, we did a bunch of that sort of thing a while back. Good catch. --MikeTalk 15:18, 2 December 2010 (EST)

Urban sprawl and Place pages [30 November 2010]

There is a Place page for Dayton, Greene County, Ohio. Any part of Dayton being in Greene County would be due to urban sprawl. (Dayton is the county seat of Montgomery County.) Is it truly necessary to have Place pages like this? In this case, it is especially bad because it appears first on the drop down; I wonder how often it has been chosen because people stop at the first choice of Dayton as a city in Ohio. Also, if someone has "Dayton, Ohio" in a GEDCOM they import, which place does it get matched to, Montgomery Co or Greene Co? -- Amy (Ajcrow) 07:14, 30 November 2010 (EST)

I think this brings up a good point. I can think of an example that may warrant keeping a city placename in use even if it lies within multiple counties. I used to live in Appleton, Wisconsin. The geographical limits of Appleton were in three counties (Outagamie, for which it was the county seat; Calumet; and Winnebago). If I have a relative that was buried within the city limits of Appleton, in a cemetery south of Calumet Street and east of South Oneida Street, it would fall in Calument County; and if he was buried in a cemetery west of South Oneida Street, it would fall in Winnebago County. In those instances, to insist that we show my relative was buried in a cemetery in WeRelate's "primary" city placename for the city (Place:Appleton, Outagamie, Wisconsin, United States) would not be accurate.
The "Independent City" concept used in Maryland and Virginia helps alleviate that concern. --BobC 08:57, 30 November 2010 (EST)
I agree that there are, indeed, instances where cities (and even cemeteries) straddle county lines. My own suburb is actually in 3 counties. However, it isn't accurate at all to have Dayton, Greene, Ohio show as a place for anything in the 1800s (or even most of the 1900s). (As an aside, the source page for the registers of the Dayton National Veterans Home had both counties listed; I removed Greene County, as none of the Home is in Greene County.) My concern with this particular place is that it is being attached incorrectly. Again, how is "Dayton, Ohio" being matched on a GEDCOM import? On a more general scale, how can we keep pages like this from being linked to so frequently (usually erroneously)? -- Amy (Ajcrow) 12:35, 30 November 2010 (EST)

Would somebody decide to merge? [13 December 2010]

Would somebody decide if these two sources should be combined? It is the same source title and will be difficult to know which to match to when uploading GEDCOM. I do not see any difference in the external URL but search results bring up two different pages. A puzzle to me!

1967 Issue:
Source:Wayland, John W. Virginia Valley Records : Genealogical and Historical Materials of Rockingham County, Virginia and Related Regions (with Map)

1978 Issue different publisher:
Source:Wayland, John W. Virginia Valley Records : Genealogical and Historical Materials of Rockingham County, Virginia, and Related Regions (with Map)

--Janiejac 12:40, 8 December 2010 (EST)
I just tried that second link and it tells me there is no such title but I'm looking at it here:

I give up . . . I think wiki is not for me. --Janiejac 12:53, 8 December 2010 (EST)

Don't give up Janie!! The link above didn't work because your signature was right up against the link. I fixed that for you. The difference I see in these two is that one has Virginia, and the other has just Virginia (without the comma). I can merge these two for you. --Jennifer (JBS66) 12:56, 8 December 2010 (EST)
The GPC one is a reprint. That page should be deleted with the info about the reprint added to the page for the original. But we have to check for links first. --Judy (jlanoux) 13:06, 8 December 2010 (EST)
I created this merged source (without the original subtitle) Source:Wayland, John Walter. Virginia Valley Records. If reprints had considerable changes from the original, another source page can be created with the date of that reprint appended in parenthesis. I included the original publishing information on this source. --Jennifer (JBS66) 13:08, 8 December 2010 (EST)

Source for marriage not showing [9 December 2010]

I just noticed on the Person:Benjamin Denton (10) page that it shows the date of his marriage but not a source. It looks like there is no source for the marriage info. I checked the family page and the source shows for the marriage. Shouldn't that source info show where ever the marriage info shows?--Janiejac 15:45, 9 December 2010 (EST)

The marriage date and place alone show up on the Person page as a convenient summary that helps understand the Person's life, but you cannot change them from the Person page. All the marriage fields are stored as part of the Family page and may only be changed by editing the Family Page. Then, if necessary, the changes to date and place get pushed out to all affected Person pages. Other information about the marriage, including the description, sources, notes, and any narrative, do not get pushed to the Person pages.

Is there a reason why you want to see the marriage source on a Person page? Since a person may have multiple spouses, it could get messy to have all the marriage sources duplicated from all of the multiple Family pages. And you would still have to go to the Family page to change it, since the marriage source belongs to both spouses involved in the marriage, and it would probably cause trouble to have duplicate editable copies on both spouses' Person pages. --Jrich 18:46, 9 December 2010 (EST)

P.S., not date and place, only date, gets duplicated to Person pages. I was thinking of the wrong infobox when I added place to the list of attributes that get duplicated. --Jrich 20:29, 9 December 2010 (EST)

Marking Watched Children [14 December 2010]

I think that it would be a wonderful feature if on the family page the children/child that I am watching was marked. An asterisk or some other simple marking would make it much easier for me to follow a branch back to the leaf.

several families in my tree have multiple marriages and 13 more more children. It is very easy to get lost and hard to find your way back. This small change would make it much easier to travers up and down the branches of your family tree.

Gam3 17:26, 9 December 2010 (EST)

WeRelate is shared database so it isn't appropriate to put personal markers in it. However, the Family Tree Explorer is a tool that will facilitate your browsing. It works on a Tree that you create. If you wish, you can create a Tree with only your direct line ancestors. Use the My Relate, Trees menu item to see your existing trees or start a new one. Go to your most immediate ancestors who have pages (e.g. great-grandparents) and select Tree from the menu on the left to add all of their ancestors to a tree. I redo this periodically to pick up any new pages that people may have added. --Judy (jlanoux) 12:08, 10 December 2010 (EST)
I think I understand the original request, and it wasn't to permanently mark people in the database, but rather to use the Watched info to highlight people during display. Even if I use the Family Tree Explorer, I might want to include the siblings of my ancestors (as I do in my personal database on my desktop). In my desktop software, I can colour code all direct ancestors - this makes it much easier to traverse my tree (from ancestor to descendant). In WeRelate, as you say, it would be inappropriate to permanently mark individuals for one user's use, but it should be possible to indicate in the display whether or not the user is Watching each individual. Think of it as putting the phrase 'you are Watching' beside the person's name - but an asterisk is more practical, as it takes less room. --DataAnalyst 19:16, 13 December 2010 (EST)
Understand. But most people would be watching the children too, especially if they are in a tree. If you want to browse direct line only, the best way is to construct a tree for this and use FTE. You can have special-purpose trees. --Judy (jlanoux) 16:07, 14 December 2010 (EST)
I realized after I posted that I kind of made a circular argument, since you are right, people might be watching all the siblings. Nevertheless, some users might choose to watch only direct ancestors, and if they are traversing the database, the requested feature would come in handy. Personally, I am still in contribution and correction mode and haven't yet bothered with FTE as I'd rather see everyone when I am making updates. There is no harm in adding this feature, other than taking time away from other changes Dallan could be making. This could be a lower-priority item. --DataAnalyst 22:18, 14 December 2010 (EST)

The watchlist ends up being kind of a scattergun approach. Many of the long time users are probably watching more people they are not descended from, than those from whom they are, because they have merged and otherwise helped out on pages that needed it, rather than just focusing strictly on their personal research. Trees and FTE is probably the most efficient mechanism for what you are asking. --Jrich 23:05, 14 December 2010 (EST)

Opinion please [30 December 2010]

It has been mentioned by one admin that when we have nothing but the names of the parents (but no dates) of a person in our tree that we don't create a family page for the parents because lack of info makes it difficult for others to later know whether to match to that couple or not. He suggested this parental info should be put in the text of the child. I'm of the opinion that we lose the ability to search for the parental couple in the birth location by doing that. Is there a consensus on this?

I don't like to put this info in the notes in my desktop program; out of sight, out of mind. If I have them in my database (instead of just in notes), sometimes later I find more info on the parents. --Janiejac 18:06, 13 December 2010 (EST)

Usually all you know about the parents, in the case mentioned, is exactly the information given in the source for the child, so if you put that on the child's page as part of your source citation, you have noted it. Creating an empty family page has minimal added value. How will somebody know that Family page matches the couple they are working with? Only by visiting the child's Person page and finding out if they recognize that child. If, as is common, they only know one child in that family and it is a different one than the one that already exists, they will probably create a duplicate family page for the parents, not recognizing the empty family page that was created as the same people because there is not enough information to identify them.

However, if you can estimate a marriage date based on what you know of the children, or put some kind of location, that will help distinguish that couple from similarly named couples elsewhere when they come up amongst search results. Not the greatest, but if the child is born in 1800 and you put bef. 1800 for a marriage date, at least it puts the couple in the proper century. Likewise, even if the location is "Virginia" that helps versus, say Massachusetts or England, etc. A note on the page can make it clear the estimate is a wild guess.

If you don't know the marriage date frequently you don't know the wife's maiden name, which makes the result even less identifiable when shown with other search results. Seeing a search result for William Turner and Elizabeth Unknown, even if they have a son William, gives you very little clue what century or country they are from. If you happen to be looking for William Turner and Elizabeth Swann in Jamaica, who have a daughter Elizabeth, do you need to check that page as a possible match? --Jrich 19:07, 13 December 2010 (EST)

I'm tempted to agree with the original post that there may be value in adding a family record, for purposes of searching, and also for the future ability to link families together (albeit at some risk that the wrong people will be linked together). However, maybe for now you can 'hold that thought'. I've been thinking about searching and how much more difficult it will be when more data is added. I'd like to give it some thought over Xmas holidays. I know that Dallan plans to improve the search functionality, and there are a number of improvements I can think of besides the search algorithm itself (e.g., display christening date if no birth date, and burial date if no death date - maybe these are already on his list). I want to take the time to think through my suggestions (and look through other requests) before I put them together and put them out there for feedback. I'll try to remember to consider what impact changing the search might have on your question/dilemma. --DataAnalyst 21:09, 13 December 2010 (EST)

I can see both sides, but think I favor the minimalistic family page being created. If you don't create it, then if someone else finds a sibling, they are almost certain to not find your entry. If you create the entry, then the connection is much more apt to be found, you just run into the problem that you may get overrun with "possibles", and you may end up with multiple entries for the same family/person if people can't be sure they are the same. It seems to be a choice between find-ability vs tidiness, and I would prefer find-ability.

On a related note, one thing that I think the system needs is a way to mark that two records MIGHT point to the same people, but you are not sure. Merge should really only be done when there is a strong degree of surety that this is a duplicate, but often I find people where there is some evidence it is the same, but I really can't be positive, and you get much more damage to your data merging people that shouldn't be then leaving them separate. (And there is the flip side, of wanting to be able to mark two people with similar names/info as surely distinct) --Richard_Damon 23:24, 14 December 2010 (EST)

I also favor find-ability, but I think that find-ability requires enough information on the page to make it identifiable. A family page with just names and one sibling will be hard to identify as the parents of a different sibling. Just yesterday I was searching for the parents of a Mary Bowers, whose birth record says had parents of Joseph and Mary Bowers. Doing a search for Joseph Bowers and Mary to see if the Family page existed, I find Family:John Bowers and Mary Crow (1), which could be a match. To my benefit, on this page, there was a date and place, and I could tell right from the search results that this family in Tennessee was not a candidate for my family in Massachusetts. Otherwise, I would have to click on it, often having to then click on the children, and in actual practice even the grandchildren, to get an idea if this page could possibly match time-frame and location of the Family I am looking for. So I actually think name-only pages impedes find-ability by adding clutter that must be ruled out before you can say something wasn't found.
The only way name-only parents help is if somebody is looking for the child that already exists, since the identity of the parents helps identify the specific individual that is the child. But, hopefully the child has a birth date and place, maybe a wife and their own children, so that the differentiation from others with the same name is not solely provided by the names of the parents. I also have to wonder, if a richer identification than just names can't be provided, if the research is perhaps a little immature, and whether it might be advisable to wait to create the pages when the data can be more complete, and therefore more helpful to the reader, and probably more reliable. --Jrich 14:36, 15 December 2010 (EST)

Having thought some more about this, I am in favor of 2 things:

Create the family page
Include at least an estimated marriage date on the family page

The reason for creating the family page is to prevent inappropriate merging of records for two different people, which outweighs any consideration of having multiple pages for the same family. Consider: There are 2 John Smiths born in the same year in the same town. You create a page for one of them in WeRelate, without creating the family page. Someone else creates a page for the other John Smith (maybe through a GEDCOM upload, which only matches families, not individuals independent of families). They then look for potential duplicates, and decide that it is too much of a coincidence for 2 John Smiths to be born in the same year in the same town, and merge the two records. (Your notes and/or source citations about the parents of your John Smith do not show up on the compare page.)

If you had created the family page, the parents would have showed up on the compare page, and it would have given the person contemplating the merge pause - is John Smith son of James and Elizabeth really the same person as John Smith son of John? Maybe they did not have their John Smith's exact birth date, only the year (say from Torrey), and the father's name is the only thing that prevents them from merging the records. (Of course, if they don't know the parents of their own John Smith, they'll probably do the merge anyway, but at least you have tried to provide enough info to prevent an inappropriate merge.)

So you say, with a name like John Smith, they should be more careful before merging. But even uncommon names can cause this situation, because it is not unusual for cousins to be named the same, particularly in certain cultures at certain times.

The reason for including an estimated marriage date is to address the concerns that have been raised by others in this thread. The more records added to WeRelate, the more critical it will be to have dates, and to see them in search results. I just added the following to the WeRelate:ToDo List (under feature requests: search).

  • Ensure at least one date is returned in search results (if any dates are available):
    • If no birth date and there is a christening date, display the christening date
    • If no death date and there is a burial date, display the burial date
    • Display marriage date for each Spouse – I’d like to see what it looks like if displayed immediately before the names (after the label “Spouse:”), as I believe it might provide a quicker-than-reading visual cue to distinguish spouses from parents (except, of course, when there is no date). It is surprising the number of times I confuse parents with spouses in a search result, even though I am perfectly capable of reading the labels (I think my mind blanks out the labels because they are greyed-out).
    • If no birth, christening, death, burial or marriage dates, display any other date available in the record (eg., baptism, living, occupation)

With more records being added to WeRelate, being able to distinguish individuals by any means possible will be important - dates, places, and parents. Therefore, I would recommend creating the family page, and including a marriage date, even if it has to be estimated. Hope this helps. --DataAnalyst 16:51, 30 December 2010 (EST)

If a particular person has no dates, I don't know why they are being added at all (that's a whole other issue!). So I'm going to assume you can at least fix a person within a decade or two if you know the parents. In which case you can do the same with the parents, with an admittedly larger margin of error. If that's true, then I think you should add the parents names. Although there are are lots of John Smith and Mary families, there are also many more where the combination of names is almost certainly unique, and I'd rather have the data than not. By coincidence, the change notification from DataAnalyst came in immediately after I just added Person:Daniel Tompkins (2) to his parents, which someone else had added to a record for his brother. The dates for the brother had sloppy typos, but the names were so unusual that I could easily identify and fix them. I also have more than once connected couples that have very little info other than names and a place/time period to Great Migration immigrants, because the couple is identified in the GM profile. To the person who uploaded, that wife was probably a hard to research dead-end, but now has parents because I was able to identify the couple coming from the other direction.--Amelia 18:17, 30 December 2010 (EST)