WeRelate talk:Watercooler/Archive 2011

Archived single-topic discussions ending in 2011

Duplicate Review

Living People

Naming Conventions

WeRelate To-Do-List

FamilySearch news [12 February 2011]

It was announced today that FamilySearch and FSbeta are now merged. Whoever is working on the sources can now point them to the main FamilySearch.org site. --Judy (jlanoux) 16:09, 14 December 2010 (EST)

I edited Template:Fscollection and Template:Fsimages to reflect the new URL. --Jennifer (JBS66) 07:04, 19 December 2010 (EST)

Is there a difference between Repository:FamilySearch Record Search and Repository:FamilySearch? --Jennifer (JBS66) 10:28, 19 December 2010 (EST)

RecordSearch Pilot should have been merged into the new consolidated FamilySearch.org. The description of the FamilySearch repository could be updated. --Judy (jlanoux) 14:09, 19 December 2010 (EST)

I saw this posting today and thought it was something to be noted: New Country Code on New Family Search Posted by: "bob.penry" (email deleted) Fri Feb 11, 2011 12:04 pm (PST)

I recently requested that a new country code "Colonial America" be added to NFS as a valid entry. I just received an e-mail from NFS that this is being done.

The United States did not exist before 4 Jul 1776. However,in synchronizing places in the continental region of our country, NFS only recognizes United States. I have considered the problem for sometime as to the best way to cover places in what is now the continental U.S before 4 Jul 1776. The problem that using colony names such as Massachusetts Colony doesn't cover places like Maine which was Maine Province, Massachusetts Colony. Then how about the Northwest Territory or lands belonging to Spain, France and England? Why not just simply come up with a place name for the country that everyone would understand - thus Colonial America. The folks at NFS evidently agreed. This term will match any location regardless of the mother country in possession. --Janiejac 10:41, 12 February 2011 (EST)

Well, a historical name that is not historically accurate. Seems to me like this would make nobody happy, but maybe I'm wrong. Personally the fuzzy thinking that would allow people to understand and accept a name that never actually existed, like Colonial America, would seem to be the same that would allow them to understand United States with dates before 1776. I have to ask, what has been accomplished? Because presumably it means Colonial America that is now the United States, as opposed to say, Colonial North America. How is Canada handled? Do we distinguish between Canada under the French, and Canada under the British, and Canada as a country? --Jrich 12:59, 12 February 2011 (EST)

GRO certificates [8 January 2011]

I added an image of the death certificate to Person:William Overton (11), but afterwards I thought I should ask if there are any problems with doing that before I do very many of them. Since it is from the English government, do they claim any special rights that would prohibit posting those images on here?

A second question... Instead of typing <ref name="S1"/> into the text box (eg. when citing statements in the Personal History), is there a simpler method using a template? Moverton 21:00, 21 December 2010 (EST)

In general reproduction of UK BMD certificates of dead people online is perfectly OK. See here:

http://www.nationalarchives.gov.uk/documents/copying-bmd-certificates.pdf

David Newton 17:20, 26 December 2010 (EST)

Font Problem after source citation [26 December 2010]

The font changes after a source citation. See Person:Thomas Van Stone (4) for example. Also Person:Mary Van Stone (8). The font returns to the correct type after a break.--srblac 15:21, 24 December 2010 (EST)

Try this code instead of cite: <ref name="S1"/>. Dallan put a note on the Cite template saying that it is now obsolete, in favor of using the ref tag. --Jennifer (JBS66) 15:25, 24 December 2010 (EST)

The Cite template adds a space after printing out the cited source (presumably if you use it twice in a row, the two cites won't run together, and look like one). That made a sentence start with a space which causes the formatter to use fixed width font. Move the period that precedes the cite template to follow it instead, and that should fix the font issue. --Jrich 15:30, 24 December 2010 (EST)

I don't know about creating templates, but on further investigation of the actual template, it looks like a carriage return in the no-man's area between one closing </noinclude> and the next opening <noinclude> is therefore being included and causing this? Don't really want to play with it because of my lack of knowledge about templates. Same quick fix is available, just always follow any usage of the Cite template with punctuation or non-space character, and it rarely seems to cause a problem. --Jrich 12:47, 25 December 2010 (EST)

The ref tag is not equivalent to the Cite template. So calling Cite "obsolete" might be a little premature.

For one thing, the ref tag does not seem to work inside a source citation, but the Cite template does. So inside the S2 source citation, maybe as part of the analysis of that source, I might add a note that says something like "[Some sources disagree{{Cite|S1}}.]". Every time I've tried to do this with the ref tag, it hasn't worked.

On Template:Cite, the instructions give an advanced form, {{cite|S1|1880 Census}}. I use this form occasionally, because often I want to reference the same source but a different page number. So I will use a form like {{Cite|S1|S1,p.25}}. I don't know how to do this with the ref tag. It always seems to end up as a standard footnote to the existing source citation, so technically, I would need to create a second source citation for the different page number, and then use the ref tag with that second source citation.

Perhaps there is another parameter for the ref tag that will change the footnote text. Unfortunately you don't seem to be able to say Help:ref and find out how the ref tag works. Is there a way to ask for help on a tag? --Jrich 19:46, 24 December 2010 (EST)

The "obsolete" reference is technical in that this template is considered likely to break when new versions of Wikimedia are installed. It doesn't mean "there is no use for this template." So in this sense, it means "use at your own risk, but migrate to the preferred forms when possible."

I'm only now getting time to explore the ref tag. I found some documentation at Wikipedia footnotes. If you want to explore over there, keep in mind that we're not on the same software release as Wp so some things may not work here.

Comments and possible workarounds on your two issues:

1. I feel that discussions about differing sources should be upgraded to the narrative box. It is awkward to discuss one source from within the other's reference. I'm looking at the same problem on a page where the cite template made the text go wonky. Your explanation was helpful.
2. Perhaps an inline reference can be used to indicate a page number followed by the ref tag. (e.g. "On page 145 Jones says...." then use ref tag as usual.) Another thought: When using multiple cites from one source, I spell out page numbers in the source text box with an excerpt or abstract of what it said. If this was done, you would not need to worry about providing them in the narrative.

--Judy (jlanoux) 16:48, 26 December 2010 (EST)

Some of it is a matter of style. I like keeping analysis in the source box so if the citation is deleted, the now irrelevant analysis is not left as a non sequitur in the narrative box. I find it awkward to have to move the analysis out of the source citation and into the narrative box, often repeating the same information that is in the text box of the source citation to give the proper context to the analysis.

I notice the wikipedia page says "Named references ... should not be used to cite different pages in the same book", which makes me suspect the ref tag cannot handle the {{cite|S1|1880 Census}} case of the Cite template. Often the situations where I use this is when I am referring to a source in a different context than the essence of the source citation. Trying to abstract different sections of a single source all in one source citation would make it awkward and disjointed. Maybe the source citation references the summary of a person's genealogy on p. 56, but now I want to provide the text of the will in the narrative with a reference to the page in the appendix where it was found. I used to note the page numbers inline with the [[#S1]] method for referencing a source, until I found out that that form doesn't get renumbered. I usually don't want to just say "see page 145 of the Reed Genealogy" as it can be ambiguous (the John L. Reed one, or the Jacob W. Reed one? It would not be bizarre to cite both on one page), nor would I be excited about having to use the long form "see page 145 of Source:Reed, Jacob Whittemore. History of the Reed Family in Europe and America" if I have already cited that work as one of my sources. Because if I have cited that source as the first source, then "see page 145 of source #1" is clear and unambiguous - if there is a nice shorthand way of referencing source #1 that gets renumbered when source #1 gets renumbered. I don't see how using the ref tag will give you anything other than "see page 145 of ^[1]". --Jrich 18:04, 26 December 2010 (EST)

I have modified the Cite Template to fix the problem that I had suggested above, after doing some experimentation first on the sandbox, and it appears to solve the font issues people are having. The two pages in the original post look like they have no font problem any longer, plus other pages I was aware of.

The further discussion that followed the original post has brought to mind the possibility that some of my uses of the Cite template may break at some point. Usages like {{Cite|S3|S3,p86}}, may not survive source renumbering. Although the S3 in the first parameter (the link to the source citation) should get renumbered, the S3 in the second parameter (the footnote label) probably won't, leaving you with a footnote that says "S3,p.86" but takes you to source citation S2 when you click on it, or some similar inconsistency.

I was going to attempt to create a new template that worked along the lines of {{OpCit|S3|,p.86}} that would avoid this issue, but I realized I don't know how the source renumbering works vis-a-vis the transclusion of the template, so couldn't be sure if there is specific support for a template called Cite, or if a new template would automatically get renumbered even though it has a different name. So I decided to leave this for more knowledgeable people to think about.

None of this changes my feeling that the ref tag is pretty limited for reasons previously given. --Jrich 01:42, 27 December 2010 (EST)

Estimating birth year when no dates known [21 January 2011]

I've never been too keen on estimating birth years when I don't have some kind of data to support getting within a year or two, mostly because I've seen too many cases where an estimate was taken as truth. Also, an estimate made today may look absurd tomorrow when more information is discovered about a spouse, sibling or parent - and out-dated estimates do not always get updated.

However, I'm beginning to rethink this. As the number of records grows, I think it will become more and more important to have some kind of date associated with each person and each family. I plan to update all my records so that if I don't have any other date, I will estimate a birth year. I will likely also estimate a marriage year for every family where I don't already have a year.

So - guidelines, anyone?

In terms of calculation, I plan to use the following guidelines:

If I know dates for both a descendant and an ancestor, I'll estimate birth year so that generations are approximately evenly spaced.

Otherwise, I plan to estimate that a father is about 35 years older than the average age of his children, and that a mother is about 30 years older than the average age of her children.

In either case, I would then validate/correct against any known dates for spouses and/or siblings.

In terms of format, I believe that the de facto standard (supported by RootsMagic, which I use) is "abt" if there is evidence for a year, such as age at death, and "est" if not and there is a good chance of being wrong by 5 years or more. Does anyone disagree with this standard? (RootsMagic does not support "ca" or "say" - or I should say, it automatically converts "ca" to "abt" and "say" to "est", which works for me.)

Does anyone have any other suggestions / guidance? Does anyone else have thoughts about whether we should be encouraging all users to estimate dates where they are lacking? Thanks.--DataAnalyst 17:33, 30 December 2010 (EST)

I have use est and abt similarly. But I think we might include this in the guidelines to person pages, so that our assumptions are common ones.

I have also used "ca", but probably as a substitute for both est and abt (i.e. inconsistently). Whatever "rules" we decide to live by, perhaps they can be programmed into translation from GedCom? I don't know that there is any clear consistency in how various software programs use these words, either. I've also seen (and used) "calc" to show a date that is calculated from other dates,

An alternate way of implementing Judy's suggestion is for the use of these phrases in a date field to trigger a dropdown selection box, which would force either a text entry or a dropdown box selection (like "Availability" under a responsitory), describing how the date has been assumed. Here are some examples:

• based on evidence (abt) or (ca) (but not precise, i.e. death date based on probate date).
• calculated from other dates (calc); (such as a birth year based on age at death)
• estimated by family member ages (est); (as described above)
• estimated by software (I'm think of the horrible "WFT est 1900-1970" that I recall from early software, with really wide ranges);
• sourced, but not considered primary or reliable (covering a source book genealogy that doesn't provide a footnote for a date).

The default for an GEDCOM import could be "estimated by software" until reviewed by users for for one of the other categories.

I don't know if this is a great suggestion from a programming perspective :-), but even if an automated solution won't work, if we can agree on the definitions, such a list could be added to the help files for use as standard "text box" comments to be used when adding an uncertain date. We could even create templates for the phrases... --Brenda (kennebec1) 13:55, 3 January 2011 (EST)

Thanks for the feedback. I'd just as soon stay away from something like 'calc', which my software does not recognize. (Also, as a data purist, I would point out that 'calc' describes how a date was determined, not a characteristic of the date itself.) It would be good to use a set of terms that is recognized by as many software programs as possible - as far as I know, RootsMagic supports abt, est, bef, aft, bet/and, from/to. If most software supports 'abt' and 'est', I would suggest sticking with those. The exact meaning of each (of these two) is probably not determined within the software programs - what would they care? - so I think we are free to assign meaning as we see fit.

As a data purist, you probably recognize that GEDCOM is the dominant standard in this arena (not Roots Magic or any other single genealogy program), and according to GEDCOM, for approximated dates, there are three qualifiers: ABT, CAL, and EST. CAL, of course, indicates that, at some point in the life, you have documentary evidence of their age, such as a deposition or age at death, etc. Some of these have been shown to be generally inflated, but they are better than a guess. Every case is different, so it is difficult to say any one method of estimating a date is always better, and hence a note explaining the estimate should be, by courtesy, if not by software, required.

There were preliminary guidelines written at Help:Date Conventions but it is difficult to find the appropriate help for any topic, and then one always wonders how "official" it is (to borrow a term mentioned in a long-ago conversation on Help pages). Dallan has hinted that at some point he is going to force dates into a much narrower format, including consistency in case, and such. This will be heartily welcomed by me, even if I turn out not to be thrilled by the format he chooses because otherwise, the discussion could go on forever. --Jrich 22:56, 3 January 2011 (EST)

Thanks. The Help wasn't that hard to find - I don't know why I didn't search for it. I must have expected a discussion in the Watercooler, instead. I realize that GEDCOM is the standard, but I don't recall ever seeing "cal" on any date, so it doesn't look like that part of the GEDCOM standard was widely adopted (or maybe websites like RootsWeb automatically convert "cal" to "abt"). I had thought that "abt" and "est" (or "say") were de facto standards, but maybe I am wrong. I'll continue to use them anyway (at least for now), since my software does not recognize "cal", and from what I can see, using "cal" would only add more variation (rather than converging on a standard). The important thing, as you indicated, is to provide a source and/or note to indicate how the date was derived or estimated. I will try to be more consistent about that, now that I know that "abt" and "est" do not mean the same thing to everyone. --DataAnalyst 21:23, 4 January 2011 (EST)

I always use 'abt' if a date is calculated from other information (such as age on a census record), and my observation is that this appears to be relatively common usage. Then I include a source citation that hopefully makes it clear how the year was determined (although not always, because sometimes the source citation is just another compiler saying 'born abt 1700'). For an estimated date, I have done 1 of 3 things:

• cited a source that has an estimate (and then not taken any responsibility for how the estimate was determined)
• cited my own source I call "Assumed by compiler (Janet Bjorndahl)" - sometimes with a note indicating how I estimated the year, often not
• nothing (left the date with no source or note)

Maybe we should suggest that the basis for an estimated date should be noted in the source citation or a note (unless it was estimated by someone else and we don't know the logic - in many cases, though, an experienced genealogist could figure out the logic). Having a standard list would make it easier for people to describe such things as - "well, it fit into a gap in the family", especially when all birth dates in a family are estimated - change one and they all change. Of the suggestions above, it looks to me like the first, second and fifth would apply when using "abt", while the other two would apply to "est". When I think of ways in which I have estimated birth year (or seen it done), I come up with the following list:

• based on birth dates of children or other descendants
• based on known birth dates of siblings (to fit into gaps)
• birth dates for this person and all siblings estimated to provide reasonable gaps (relative birth order known)
• birth dates for this person and all siblings estimated to provide reasonable gaps (relative birth order unknown/uncertain)
• based on birth dates of parents or other ancestors
• based on marriage date
• based on other events (such as freemanship)

As I look at the list, obviously there could be multiple bases for one estimated birth year. Therefore, maybe we suggest some phrases that could be used in the source citation/note, as above.

We could implement guidelines (when to use "abt" and when to use "est", how to estimate, and how to describe the estimate) without any software changes (such as dropdown lists). Then, once it looks like we have a good list, we could consider a multiple-selection list in the future (with the results being stored in such as way that they translate well into GEDCOM - such as being put into a note).

I'm all for writing this up in the Help and/or templates, but I don't know where/how to do this. If someone else could take this on, that would be great. If you want me to draft something, let me know, or point me in the direction of where to add this to Help (but you might get something a bit wordy, as you may have noticed). But first, is there consensus on when to use "abt" and when to use "est"? I sense that there kind of is, but then, not many people have weighed in yet. Thanks --DataAnalyst 21:19, 3 January 2011 (EST)

Hi, I think you're right. The Help:Date Conventions is inadequate. This is a wiki. Everyone is welcome to edit pages and most of the help pages need updating. I think everyone would appreciate it if you took this on. I would vote for "abt" because I have seen it used more often.

An elaboration on "inadequate" would be useful in fixing the situation. The page is a little long in the tooth, dating from when dates were almost free-form text, qualifiers and double-dating were ignored. However, any attempt to update it will probably require a certain amount of architectural direction from Dallan, or whomever. Perhaps this has been stated somewhere, but I have not seen it. Without this, it is hard to see how one can do more than try to provide a simple explanation of GEDCOM rules for dates, since this is presumably the controlling standard.

Some questions regarding date formatting:

• Is it the desire that the date fields will be typed, meaning only valid dates are expected in the date fields, and if so, what is the definition of a valid date, meaning what forms is the computer able to correctly parse? One would think that any future plans to have search results ordered by date proximity, or calculate ages or durations, or in any way process the date field as a date would require this. One would assume that the formatting rules would be defined by GEDCOM.
• How much deviation is possible from GEDCOM? Since GEDCOM output is supported, and GEDCOM does not include, for example, some people's favorite date qualifier, CA, will the software take responsibility for converting CA to ABT to seem more friendly? Or are people expected to limit themselves to BEF, AFT, BET, ABT, EST, and CAL, etc.?
• What will happen if invalid date formats are used? Displayed in red and suppressed from GEDCOM exports? Popup error message preventing the save from completing? Errors reported during GEDCOM upload?
• There have questions posted about capitalization of ABT, use of periods, one two or four digits in double dating form, and other minor formatting issues. If the software always converted allowed variations into, and always displayed dates, in a single preferred format, there would not really be a need to give people detailed instructions to capitalize one way or the other, to add or leave off periods, etc., as it would be obvious and automatic. Or, is the system going to be a minimally restrictive as possible, consistent with any answers to the earlier points?

There are other issues that have been included in this discussion over the years, such as explaining estimates, providing the original form of interpreted/numeric dates in the source citation, how to arrive at estimates, etc., that are more along the lines of good genealogical practice, than date formatting. As a general rule, if these things were not done by the researcher when the person collected the data in their home system, they will probably be unaware of the need to, or unable to, comply with these conventions when inputting their data into WeRelate. --Jrich 17:01, 19 January 2011 (EST)

I have always used PAF as my desktop program because I assume it will always conform to the GEDCOM standards, since both are published by the LDS church. One program I refuse to use is FTM because they have taken great liberties with the standards and therefore have become incompatible with other programs. PAF converts date entry to dd mmm yyyy format regardless of how it is enetered, accepts BEF, AFT, ABT, EST, FROM...TO... and CAL, but not BET...AND...It will convert double dating to 4 digits. If an improper format is used it issues a warning. I assume that this is to assure compliance with GEDCOM and indicates acceptable formats. If this is not the case, let me know. I presume Dallan could restrict entry in a like manner into WR fields.--Scot 22:00, 19 January 2011 (EST)

Just a quick note on forcing valid dates. I use RootsMagic, which I think has made a very nice compromise. You can enter a date or non-date text into a date field. If you enter anything that the software can recognize as a date, it automatically formats it according to standards (DD Mmm YYYY), with appropriate prefix (e.g., abt), and sorts the event accordingly. If it does not recognize the date, it leaves it alone. That means you can enter something like 'young' for death date, or 'before marriage' for a residence date. WeRelate could do something similar, or could force dates to be dates and expect us to use the description field for anything else. If the latter, it would have to move unrecognizable dates from GEDCOM to the description field. --DataAnalyst 22:02, 20 January 2011 (EST)

GEDCOM upload with warnings [2 January 2011]

Having already had one GEDCOM file rejected; I'm gunshy about my next file. I've been doing a one-name study of Jacksons in Braxton County, VA/WV and realize I'm going to have a hard time getting past the warning percentage. Twins run in this family; I've already got 4 sets of twins and one set of tripletts. I've got six Jacksons who married distant (and not so distant) cousins, so they are Jacksons marrying Jacksons. I have the parents of all the marrying couples, so it is definitely not a mistaken married name. Is there any hope of getting this file uploaded or should I just put it on rootsweb? This file is not finished but I'm wondering how much more time to put into it. --Janiejac 23:14, 1 January 2011 (EST)

Janie, I would highly encourage you to upload your gedcom. Multiple births should not be causing errors. If they are, that is a bug that would need to be fixed. Also, spouses with the same surname will generate an "alert", but will not cause an increase in your warning percentage. Upload your file, and we can take a look at any reasons the file is causing a higher percentage of warnings that is leading to a "rejection" notice. --Jennifer (JBS66) 06:46, 2 January 2011 (EST)

You should include text tutorial link on front page [2 January 2011]

Due to being on satellite Internet, I can't watch videos. So I would appreciate a link on the front page to a text tutorial. This one is great: Help:Person pages tutorial. IMO the front page should say "Watch Video Tutorials Take a Quick Video Tour (or read text tutorial here)" --Cthrnvl 08:33, 2 January 2011 (EST)

Need info on Place Page [8 January 2011]

Oh I wish I knew how to do this and didn't have to ask for help! But. . .I just added an external link to Place:Hempstead (town), Nassau, New York, United States. The TOC is placed below some text copied from wikipedia and I think the TOC should be above the text. Also, this town has 22 villages in the town and how do I (or will somebody else please) fix it so those places show up as inhabited places? I could list them, but shouldn't this info come from wikipedia? --Janiejac 22:29, 4 January 2011 (EST)

To answer the question I'm pretty sure of: The wikipedia TOC is designed such that there's a lead (summary) paragraph . . . THEN the TOC (assuming you have four sections or more) . . . THEN the body of the article. In other words, it appears that way deliberately and by intention, and I don't think it can be changed, except by turning off the TOC entirely with the __NOTOC__ command (that's with two underscores, both fore & aft). --Mike^Talk 22:55, 8 January 2011 (EST)

Casper Hallenbeck [19 January 2011]

Hi, is there anybody comfortable with U.S. genealogy who might be able to clean up the duplicate spouses on Person:Casper Hallenbeck (3)? --Jennifer (JBS66) 16:35, 15 January 2011 (EST)

Done--Scot 17:23, 19 January 2011 (EST)

Thank you Scot! --Jennifer (JBS66) 18:46, 19 January 2011 (EST)

Duplicate sources vs reprint sources [10 March 2011]

I am puzzling over a very complex set of possible duplicates, and I'm hoping for some advice from the WeRelate source authorities. The original work can be found here: Source:Goodspeed. History of Tennessee from the Earliest Times to the Present, Together with an Historical and a Biographical Sketch of. A new user has created this "master" page and suggests that the numerous "reprint" editions noted on the page are duplicates and should be combined.

This is a mulitvolume work of the 1880s; the same "general history" of 700+ pages was used in each volume, followed by pages specific to a county or counties. The reprints have wisely reprinted the "general history" as one volume and the county sections as separate volumes (most reprints appear to match the original county groupings used by Goodspeed).

So here's the dilemma: There are numerous facsimile reprints of PORTIONS of the original work available; we have some of these reprints in our database, because the Family History Library has collected them. The reprints have different titles than the original works, mostly [but not always] because the reprints tend to call the work "Goodspeed's History of Tennessee..." rather than just "History of Tennessee."

I'm inclined to retain the reprints, even tho they are facsimile reprints, because they have different titles, and a user may well have only had access to the reprint - without the reprint title, they may not be able to find the WeRelate Source page. However, much of the original work is now available on the web via TN GenWeb. Not all the web page transcriptions reference the original page numbers, or even whether the source of the transcription is the original or the reprint (which shouldn't matter, if they are facsimile reprints).

But I hate to have a cluttered and confusing mess of a dozen or so reprint titles, presuming (apparently correctly) the content is the same as that found on the web versions and the original volumes. Is it sufficient to retain all the reprints as "redirect" pages to the master source page? Or should I retain the reprint editions, perhaps with a caveat such as I placed on Source:Goodspeed's General History of Tennessee? What if new pages are added for reprints that do not retain the original county groupings by Goodspeed? These reprints do exist, but are not yet in our database.

Thanks,--Brenda (kennebec1) 12:43, 30 January 2011 (EST)

A tough decision, but I think redirect now. Then work on future items when they come.--Sandralpond 13:03, 31 January 2011 (EST)

One question that might affect this - if we set up all the reprints as redirects to the main article, when someone searches for the title of the reprinted source, would one of the search results then be the main source? In other words, do searches also search the titles of redirect articles, but then link you right to the main source? That might help decide. Either way, you're right, what a mess....

I *think* that SEARCHES only bring up current sources (not sources that are now just redirects). However, "Dropdown" autofill options (that pop up when you ADD a source to a person page) do include all page names in the database, not just the current (active) ones. Someone with more technical knowledge than I can confirm that, but I just did a test to check and that seemed to be how it works. --Brenda (kennebec1) 11:42, 2 February 2011 (EST)

If I understand right, a patron could come to this source two different ways, does this sound right, or am I missing anything:

1. Those who have already found info in the source and are looking for it to cite on their person or family.
2. Those who are searching for sources to get ideas on where to research next

Doing redirects might confuse those individuals who fall under #1. But the #2 individuals will be helped by making sure that the source that's easiest for them to access and use is found..... That's not really a suggestion, I think you're already thinking along those lines, but spelling that out helped for me, I'll think some more on this too.... Vasquezjl 14:07, 31 January 2011 (EST)

Yep. You've got the dilemma precisely, and I think you said it more clearly than I did. Lots to ponder here. --Brenda (kennebec1) 23:38, 31 January 2011 (EST)

So, as best I tell, based on how WeRelate works (see above):

A person searching for source ideas (as in #2 above), for example, searching for sources for future research on Tennesee, would find only the current source page (not one with "redirect" on it) in results.

If a user is adding a citation to a fact on a person page (see number 1 above), the "dropdown" autofill function shows all source name options as you type, both current and "former" (now redirected) source page names, in I presume alphabetical order. Thus Goodspeed. History of Tennesseee shows up in the same area of the dropdown as Goodspeed's History..., but it isn't prioritized or highlighted in any way (i.e. no way to tell which is the "real" source). Redirect pages and regular source pages show up the same in the dropdown results, so it's just a question of selecting the title that reflects the actual source a person uses.

This would seem to be ideal, except that a person who chooses a redirected title may never open the full source page, and may not realize that in order for their citation to be complete, the details should include info on which reprint was used, the counties covered, page numbers, etc. However, the benefit of having the pages combined may outweigh the possible inconvenience or lack of clarity caused by the one source page for multiple reprints?? (Opinions, anyone?)

The other time when sources are reviewed by users is when a GEDCOM is uploaded to WeRelate, and I don't know how that works. I believe a user can only "link" their imported source to a current WeRelate source page. In this example, a person who has previously used Goodspeed's History (the reprint for a particular set of counties) would have to recognize that Goodspeed. History of Tennessee is the same source, and also review that citation later in order to add the details (i.e. the particular county group, reprint edition, and possibly page numbers for that particular citation). That may sound like a lot to ask, but it is often true that imported citations need to be corrected/updated, so that isn't unusual...

Does anyone else know how the Source Review part of the GEDCOM import works, technically?

--Brenda (kennebec1) 11:42, 2 February 2011 (EST)

You're right -- redirected sources don't show up in searches, but do show up in the auto-complete drop-down when adding source citations. I'm reluctant to include redirected sources in search results, but it would be pretty easy to either remove redirected sources from the drop-down, or to identify them in the drop-down as redirected; e.g., by following the source title with "(redirected)".

The source matching during gedcom import, which is pretty awful at present, is based upon search, so it matches only non-redirected source titles. The eventual goal is to use the Find/Add source functionality (which is also based upon search) to help the uploader match their gedcom sources. Upon selecting a source in the gedcom review program, the uploader would be shown a list of Source pages that potentially match their gedcom source and asked to select which (of any) of these sources match. If they don't select an existing source, they'll have the opportunity to create a new Source page. If they do nothing, their gedcom source will be added as a personal MySource, just like it is today.--Dallan 10:58, 9 February 2011 (EST)

Are indexes part of a source, or a separate source? [6 February 2011]

As part of the whole "Goodspeed" mess (see above duplicate/reprint source topic), another interesting question has been raised by User:Murphynw regarding the best way to handle indexes to books that were created (and published) separately from the original work they reference.

To date, WeRelate has listed these as separate source pages, following the practice of the Family History Library imports that are the origin of many of our source pages. When I have come across such volumes, I have added cross-reference links. For example, see

• Source:Wheeler, George Augustus. History of Brunswick, Topsham and Harpswell, Maine, Including the Ancient Territory Known as Pejepscot (1878 ed)
• Source:Schilly, Shirley Simington. Genealogical Surname Index to the History of Brunswick, Topsham, and Harpswell, Maine, by George Augustus Wheeler and
• Source:Greenleaf, Moses. Index to Moses Greenleaf's Survey of Maine
• Source:Greenleaf, Moses. Survey of the State of Maine in Reference to Its Geographical Features, Statistics and Political Economy

However, although these indexes to books have a separate bibliographic life, they are not very useful as WeRelate Source Pages - [I hope] a researcher is not going to cite an index to a book to support a genealogical assertion; instead, they will use the index to find what they are looking for in the main work, and create a citation to the main work. So, for WeRelate purposes, perhaps book indexes should be listed on the same source page as the main work, with their bibliographic/publication info included so that a user can find the index work.

I'm not going to address the plethora of Indexes to vital records or censuses... those are separate cases, and *ARE* often cited as genealogical sources in the absence of the original data (for better or for worse). But indexes to written histories (town or family) are a different breed; they don't generally provide anything other than a page number reference in the original work and can't really be used to document any genealogical data.

When I review sources, I provide cross-references to index works when I find them. Is that sufficient? Is it acceptable to just add index information directly to the main page being referenced (rather than creating a new Source Page)?

Example: In the Moses Greenleaf work, a sentence that reads "A typescript index (created 1975, author not noted) is available at the Family History Library."

Example: In Wheeler work, a heading "Index" and a paragraph reading, "Shirley Simington Schilly compiled Genealogical Surname Index to the History of Brunswick, Topsham, and Harpswell, Maine (Brunswick:Pejepscot Historical Society, 1985). WorldCat provides information on local libraries with copies of this title. This index is included in Source:Wheeler, George Augustus. History of Brunswick, Topsham, and Harpswell, Maine (1989 ed).

What do you think?--Brenda (kennebec1) 13:19, 30 January 2011 (EST)

I'm sure the librarians have views on this, but in my opinion source pages that aren't genealogical sources should be deleted. Thus the index sources for books should be deleted, and a link to the relevant FHL entry added to the source page for the book itself. As you note, they shouldn't be cited as sources, and if there is some need to discuss them, that need is more likely to come up (and can at any rate be covered) on the page for the book itself.--Amelia 18:56, 30 January 2011 (EST)

I see the index as a wonderful research tool that saves me so much time. I see a connection to the orginal as helpful. Would a link that connects each be a good option?--Sandralpond 13:17, 31 January 2011 (EST)

Meaning, as the first examples show? I'm definitely not suggesting removing the indexes - they are great tools. Some options are:

1. Indexes remain separate source pages, with a cross reference - so the Index source page has a link to the Main book source page and the Main book source page has a link to the Index source page.
2. Indexes are merged into the source page for the book they index, with a link to where to find the index. The index source page is redirected to the source page for the book that is indexed.
3. Either option remains acceptable, depending on the specifics of the index and the source. For example, some indexes are not widely available or don't have a separate commercial publication date or a known author (see Source:Church of Jesus Christ of Latter-Day Saints. Genealogical Society. Index to the History of Connecticut for an example). It seems to me these probably should be integrated in the Source Page for the book they index. Others have clear separate authors, are published, etc. See Source:Groves, Marlene Alma Hinkley. Index to Charles Edwin Allen's History of Dresden, Maine as an example - Marlene Groves has compiled indexes to several Maine genealogy books.

I'll note that one reason to keep a separate source page for these "non-genealogical" items is that the template for a Source Page for allows links for repositories and bibliographic info that otherwise has to be written out in a paragraph if the index is just added as a paragraph to the main Book Source page. Meaning, if a user is looking at WeRelate Source Pages for ideas for further research, having an index source as a separate source page (as long as there is a cross-reference link) might make it easier for the user to find that index source (i.e. the template for a source page ensures all the important info on where to find the book is collected).

On the other hand, although book indexes are great - essential, even - finding aids, they are not, in themselves, a genealogical source. Meaning, if you need to show where you found out that Jane Doe was born on Dec 11, 1910, you should be citing the book itself, not the index to the book.... However, indexes are certainly not the only "gray area" in our Source Pages, and generally I prefer we err on the side of inclusivity than not...

--Brenda (kennebec1) 23:35, 31 January 2011 (EST)

Two points: (1) A published every-name index to an earlier work is not part of that earlier work. (I compiled and published and sold a few of those myself back in the '70s, as adjuncts to fat 19th-century local history volumes that had no original index of their own.) A work like that is a separate book, with a separate author, so it needs its own listing. You'll find them listed separately in a library catalog, for instance.

However, (2) as Brenda says, a volume that is only an index has no business being cited in anyone's research -- and certainly not on WeRelate. It's a finding aid, not a "work of content." I would have no problem with deleting all works of that description from WeRelate's source library. --Mike^Talk 19:25, 2 February 2011 (EST)

Ah, Mike, that is precisely the heart of the matter... Of course, a published every-name index is a separate entity, from a library's perspective. BUT the WeRelate Source Pages are a special type of library -- designed to provide links to genealogical sources and information on those sources, not necessarily info on every book in the world.

Indexes may not be sources themselves, but if we just deleted them, we would be unable to provide users with info on these invaluable finding aids, which can really help when you are looking at an older historical genealogy work. So, is it better to go through the effort to INTEGRATE information on indexes (i.e. title, author, publication info, repositories) into the pages for the sources they relate to? or keep separate source pages for indexes that 1) provide a caveat that this is a finding aid, not a source, and 2) cross-reference the actual source (the book) that is being indexed, with a link. Maybe we could even use the "References/Cites" field?

Can you give me more info on what you think is best? And, should I interpret the limited response to this topic as likely to mean I should just use my best judgement when I come across this situation? There are, by the way, 20,945 sources with the word "Index" - a wild estimate is that perhaps 5,000 of those are likely to represent the type of indexes we are discussing (every name indexes to a book, versus vital records or census indices), based on the subject that has been applied to those titles. Not an instant fix, since it probably needs to be done manually. But not so many that it is impossible to review by hand, either.

--Brenda (kennebec1) 14:48, 4 February 2011 (EST)

Well I didn't think I had much of an opinion on this until today.

For years I've been researching what happened to four families who were involved in a town controversy (something akin to wife-swapping) back during the American Revolution. I have attempted to document what happened to each family-- where they went after they left town (or were booted out). One of the co-conspirators was a man named Amos Marsh. If you search around for this name you'll find that in western Massachusetts at this time, his name may as well have been John Smith.

One of my theories is that he and his consort (Jerusha Smith Doolittle) ran off to Hoosick, NY as there is evidence to suggest they went to NY and the 1790 census finds a man by that name in Hoosick, NY. But there are also many other candidates in Western MA in the 1790 census with the same name.

I just happened to find today this reSource: Index to Rensselaer County Surrogate Court Records

Browsing around, I found one Amos Marsh with a surrogate file involving his wife Jerusha, with the year of 1829. Other evidence I'd found in the past had me estimating the death of "my" Amos Marsh between 1820 and 1830. This evidence-- existence of a surrogate file-- absolutely is a source for me. So I would record it, and I think it should be separate.

Now, yes, I've already filled out the form to request the original file, but in the meantime, I want to make sure that I record where I found this information. So the index IS a source for me, if only temporarily.

But let's say I die tomorrow, and I hadn't recorded that "source". Without that "source" someone else researching that family might not find what I found.

So, I say, keep indices as their own source, and link to the source page of the "original" records as well.

My $.05

-- Jillaine 20:59, 4 February 2011 (EST)

That's a great of example of the "other" type of index - meaning an index to vital records/probate records/civil records/cemetery etc... any of those often-used genealogical resources that are a large group of similar records, and that are often only widely available as indexes - you have to order the original file to get the full record, or you have to contact the town or county directly to get the vital record, etc.

I'm not at all suggesting that this type of index should be merged or deleted -- they do "stand in" as sources, at least temporarily, and sometimes temporary takes a long time to change! I do like the idea of continuing to add cross-references to the "original" sources when they are available for this type of index, and I'll try to do that when I review such pages.

Just to clarify, tho, this question is strictly addressed to the question of "book" indexes - i.e. the later publication of an index to an earlier history or genealogy book. The examples I see tend to be geographic histories that were written in the 1800s and were not published with an index; a later author publishes a free standing index to the earlier work (the type of index that would normally be in the back of the book...). This type of index doesn't have birth dates, death dates, probate dates, or cross-reference names attached to an entry; it is, presumably, a bunch of page references to various surnames and/or other content in the original book.

I can see, however, that one would want to be cautious in presuming/assuming anything about an index, because there could be times when these two types of indexes overlap.

I like, however, that the value of an opinion has increased! Definitely worth $.05; more than the traditional $.02! [smiling!]

By the way, Jillaine, I really like the piece you have written about the Amos Marsh/Jerusha Smith Doolittle story (Spiritual Wife-ism in Colonial Massachusetts and God Love and Lust: The Tale of Four Revolutionary Families in Warwick, MA). I didn't realize until today that you have updated the PDF this year - I look forward to reading it. --Brenda (kennebec1) 17:55, 6 February 2011 (EST)

I think Jillaine's scenario still applies to any kind of index. For example, Google has implemented the full view privileges in a most inconsistent manner. There was a case a while back where I ran across the index to a book that was fully viewable, and it listed a person with birth year and death year (something I didn't have yet) and gave the page number in the book. The book was not viewable on Google, even though clearly the index was published no earlier than the book? Go figure. Anyway, it may be years before I track down a source, or it may be so difficult to access that I get no further, so I want to record the information.

There are ways to accomplish this that don't require creating a separate source page, though. Such a citation, for example, should be expected to be temporary. So first of all, I might put it in a note. Then I might give an informal citation for the index and explain that it says this information is contained in the source, for which I include a reference the book's source page. Then when I finally find the source and look it up, I delete the note, and add a proper source citation more in keeping with what Mike says.

Let's assume there is at least one person out there whose GEDCOM contains an index as one of their sources and they believe their research is mature enough to publish to the world as fact. I would guess that it will happen sooner or later. If there is a source page for the index, they will presumably match to it. What will they do if there is not? Match to the book? Or create a mySource for the index?

Maybe source pages for indexes can be created, but when someone links to it, the citation for the index can be made to include a warning that this page needs improvement? --Jrich 18:34, 6 February 2011 (EST)

Surname Category Table of Contents [9 February 2011]

Since many of our surname categories are difficult to maneuver (such as Category:Smith surname), I created a Surname TOC template. This template is currently in use for example purposes on Category:Jones surname. This TOC allows you to skip ahead to the Family, Person, Source, and User sections, as well as to the first letter of a name in both the Family and Person sections. If others find this template useful, we could edit the Category:Surnames instructions to include the use of this. --Jennifer (JBS66) 14:33, 9 February 2011 (EST)

This is great Jennifer! Much better than the single line alpha selector template. I have already put your template on Category:Jackson surname. --Janiejac 16:38, 9 February 2011 (EST)

Thanks Janie! The single line alpha template works well on pages such as Category:Surnames where the pages in that category are not prefaced by a namespace (like Family or Person). For the categories that do have those namespaces, finding anything in them is troublesome... --Jennifer (JBS66) 16:43, 9 February 2011 (EST)

Namespace counts [16 February 2011]

What happened to the namespace counts that, until fairly recently, were displayed in the sidebar at the left on (I think) the Search page? I thought it was interesting to know how many pages were currently in each namespace and, if nothing else, it was fun to observe WeRelate growing via those counts.--CGMoore 22:25, 13 February 2011 (EST)

Just use search Persons with everything blank. I just got 1,986,586 which is up 5,012 since the last time I looked on Feb 2.--HLJ411 08:45, 14 February 2011 (EST)

My bad. They're back now.--Dallan 15:02, 16 February 2011 (EST)

Source Review Page Edit Drop Down [14 February 2011]

While reviewing a source I found that the edit drop down on ? Type has Manscript Collection as a selection but that the selection drop down doesnot include it. Though this need to be corrected.--Sandralpond 13:54, 14 February 2011 (EST)

Thanks for noticing this. I corrected the instructions and removed the Manuscript Collection text. --Jennifer (JBS66) 14:04, 14 February 2011 (EST)

Transcripts that are not owned [23 February 2011]

Draft proposal now in Proposal for Transcript Management, discussion thread moved to Talk:Proposal for Transcript Management --Jrm03063 22:34, 22 February 2011 (EST)

Biology [24 February 2011]

I tried to add a rather large Gedcom and it didn't go through. I now see that it will be better for me to add one family at a time and that is OK. But I got some odd warnings and I want to go through them. Here are the things I think should be tweaked on the warning system: Mother is over 45. Well, menopause occurs in most women at 50. So it should at least be changed to 50. I had three warnings. So 3 pregnancies over the age of 45 in my family. And what about the future? Haven't you seen "Pregnant at 70" on The Learning Channel?? LOL Father over 80. Ok, yes, this actually happens and I have one in my family. Babies too close together. It is a common practice in some religions to baptize and name all children even if they are from a failed pregnancy of only one month. So that should be an alert but not a warning. Babies born before marriage. I had three of these in my family. It should be an alert but not a warning. Will alerts stop a gedcom from being accepted? Because if babies born before weddings will stop a gedcom from being accepted that is not going to work.

And you are all doing a great job so thank you! --Cthrnvl 09:56, 23 February 2011 (EST)

Alerts won't keep a gedcom from getting imported. And we're gradually relaxing the warnings as we see more valid cases where they occur. Currently, there's an alert when a mother gives birth at 45, and a warning at 55; an alert when the father is 65, and a warning at 80. Babies born before marriage are an alert 0-4 years before marriage, a warning 5+ years (maybe that should be an alert as well). I need to think more about turning the nine-months-between-births warning into an alert. Thanks for the feedback!--Dallan 18:14, 23 February 2011 (EST)

Thanks Dallan! --Cthrnvl 18:40, 24 February 2011 (EST)

FamilySearch sources [27 February 2011]

Since these are not widely watched pages, I just want to point out some changes that were made to these sources:

• Source:England. England Births and Christenings, 1538-1975
• Source:England. England Deaths and Burials, 1538-1991
• Source:England. England Marriages, 1538-1973

I added usage tips which provide ways of citing these sources. If you ever use the FamilySearch site for finding records, this may be of interest to you. Moverton 16:02, 27 February 2011 (EST)

What is Gussie Audrey Manlove's Story? [27 February 2011]

Did anyone see this on the web What is Gussie Audrey Manlove's Story? It's about some whippersnappers discovering genealogy. It got me thinking that it would be fun to have a contest here - throw out one name - the person would have to be long gone for privacy reasons - and then have a contest to see who finds the sources fastest. 10 points for a census entry. 50 points for a birth record. And so on. If everyone is trying to edit one page it probably would not work because it would jam the system. Any ideas about how we could accept entries the smoothest? A message board? What do you think? --Cthrnvl 20:14, 27 February 2011 (EST)

Personally, I think it would be cool to have some sort of concentrated crowdsourcing. (Genealogy really does give new meaning to that word! <g>) Josh Taylor did something similar via Twitter during the RootsTech conference a couple of weeks ago. It could drum up some excitement and some exposure -- both good things! -- Amy (Ajcrow) 20:45, 27 February 2011 (EST)

Sounds great fun! What every genealogist loves to do. --Beth 20:57, 27 February 2011 (EST)

Wikipedia as Repository [11 March 2011]

In my reviews of source pages in West Virginia,I have found a need to use Wikipedia as a hyperlink. I feel it should be use as a repository. Has there ever been a discussion on this idea? It is a complex site but is full of much that can be useful to genealogy research. ````--Sandralpond 13:31, 1 March 2011 (EST)

Your question is a little confusing. A repository is a holder of sources. Wikipedia is a source. Repository:Google Books (for example) is a place to go to access multiple sources which are scanned books. You don't cite books.google.com, you cite the book you used there, as the source. books.google.com is merely listed on the Source page telling people where they access the source being described. In contrast, you do go to wikipedia to get information, and cite it as a Source of information.

There are already many tools for linking to Wikipedia and even using the material from wikipedia. For example, [[wikipedia:Plymouth Rock]] to link to an article on Plymouth Rock. See also, Help:Guidelines for use of Wikipedia for pulling wikpedia content into a WeRelate page (like most Place pages do and many famous people).

How would making wikipedia a Repository even help? What exactly is the problem you trying to solve with this proposal? --Jrich 14:30, 1 March 2011 (EST)

I looked at Source:Wikipedia and have updated it to be more complete. I changed the Type to "Misc." to allow the populating of the publisher. One thing to note about the "Website" type is that it doesn't allow the population of the publication fields. Although that could just be considered a defect, I would contend that "Website" should only be used for repositories. This could be thought as logical since we are citing what is on the Web site rather than the site itself. Although I realize WeRelate doesn't follow any particular citation style, most styles do require the publisher for Web sites, as can be seen on Wikipedia:Citing Wikipedia. Moverton 16:19, 1 March 2011 (EST)

This has been discussed at least a few times of the last couple years. According to the Repository Portal "repository pages are for physical locations of genealogical material such as archives and libraries, and for significant virtual locations such as major genealogy websites." So my thought would be that a specific page within Wikipedia would be used as the source for the data used or referenced, and the source is maintained at Wikipedia, a significant virtual location and recognized as a major genealogy website (yes, a repository!). Let me make a comparison to simplify the concept -- that of a single book within a physical library: The book is the source -- the library is the repository for that source. Pretty easy for me to understand that way. --BobC 19:46, 1 March 2011 (EST)

I think there's semantics thing here. Since there only one wikipedia, it is a little difficult separating the where you go from the object itself. I would argue it is a single source with pages, like a book having pages or chapters. I would argue the Internet, or the ether if you prefer, is the repository. If you argue wikipedia is a repository, I would argue that you are in essence arguing that we need a source page for each wikipedia article. I don't see this approach translating well to other websites, either, like genweb sites that host multiple data collections. Are we going to make all of those repositories?

But whatever you want to call it wordwise, I don't see any value in making it a WeRelate Repository page. There is only one source page for all of wikipedia and that is the only source page that would be in the wikipedia repository. Is that necessary? What are we gaining by creating a repository called wikipedia? Still waiting on clarification of the original post. Since it said something about a lot of links, I was hoping the pointers about linking to wikipedia answered the question. --Jrich 20:36, 1 March 2011 (EST)

Taking your analysis to a physical state (non-Internet), it would be like me finding a source reference in my great-grandfather's civil war file at the National Archives and then annotating NARA as the source. The National Archives is not the source for the data, my grandfather's civil war file is the source; NARA is the physical storage location of the source, or the repository. If my grandfather's file is also scanned at Footnote, then Footnote too is a repository, not the source. If the file then too is discovered on FamilySearch or Ancestry, are they the source? I would say no, they are the "significant virtual location" -- or another REPOSITORY --- for the source. Regarding your statement of using the "Internet" as the repository, taking that to a non-virtual state, that would be like calling the Federal Government as the repository rather than NARA? I would say keep it to it's smallest identifiable level, both at the source level and at the repository level. It's more than semantics, it's proper categorization, utilization and identification of terminology.

As far as translating that thought to other online repositories, I would argue that just as you are not going to need every book or magazine in any city library to be identified as sources for your genealogical research, you are not going to need every website page as sources, whether than be Wikipedia, FamilySearch, Ancestry or the New York Times. You pick and choose your source pages, then annotate the appropriate repository where the sources were located, whether that be an actual physical structure or a major virtual location. Why is that so difficult to understand? --BobC 22:19, 1 March 2011 (EST)

It's all semantics. I would argue it's like an encyclopedia, so a source, and your NARA example is not at all analogous, since those are disparate collections that just happen to housed together. But it doesn't matter which view you want to take. The crux of the matter is what benefit will creating a page Repository:wikipedia give? How will it help data entry? What useful information will it convey that isn't on Source:wikipedia? If there's some benefit that I have missed, please explain it, but I don't see any. --Jrich 00:08, 2 March 2011 (EST)

Wikipedia is an online encyclopedia and should be cited as such. The repository in this case would be the Internet. Wikipedia outlines suggested citations on this page which follow standard guidelines for citing an article in a reference book. I will also add that the practice of creating Repository pages for libraries and bookstores is generally unnecessary. If a library has a specific database that cannot be obtained elsewhere, then fine - you can create a repository page for it. However, taking a quote from Evidence Explained "When citing books, film, and other published materials that are widely available, the name of the repository at which we used the source is not included in our formal citation. (Libraries holding copies of specific published works are identifiable through the Online Computer Library Center's World-Cat database, and similar resources.) In our working notes, we may wish to include the repository at which we found the publication, simply as an aid in case we need to reconsult it. However, a citation to the facility most convenient to us personally would be of little value to users of our work who live elsewhere."

In regards to JRich's question, which is a great one... an example of this intended use can be found here. It is my belief that this is not what is meant for the Repository field on a source page. This field is meant for locations where you can find this source, not for added details about the people who may be discussed in the source. That can be added in the text field below. --Jennifer (JBS66) 07:40, 2 March 2011 (EST)

I'm relatively new on WeRelate and have had a question about publishers' online bookstores. Is there a reason they shouldn't be listed as a repository? For example, some of the major genealogy publishers like http://www.genealogical.com and http://www.pictonpress.com/ usually maintain a webpage for each item they produce. My vote would be to add a new repository type called "Online Bookstore," and create links directly from WeRelate source pages to the parallel items on these sites. Would this be the easiest method for some folks to access the book/CD? Murphynw 11:42, 11 March 2011 (EST)

I think there was some discussion about adding more types to the repository type drop-down, but I don't think a consensus has been reached yet. In the meantime, feel free to create repository pages for the major genealogy bookstores.--Dallan 17:56, 11 March 2011 (EST)

Thanks so much for the information, and discussion. You have all helped clarify the use of Wikipedia. I was only wanting to use it as it was the only place I could find a copy of the orginal item for the source page I was reviewing other then the FHC. Now I can see that as a source it is much more useful.--Sandralpond 10:07, 2 March 2011 (EST)

Sandra, can post a link here to the source page and original item you are referencing? I'm interested in taking a look at it. Thanks, --Jennifer (JBS66) 10:17, 2 March 2011 (EST)

There's definitely a grey area between repositories and sources (as with so many other things). For myself, Wikipedia calls itself an encyclopedia which makes it more of a source than a repository. However, rather than attempt to draw a fixed line between the two (which would be very difficult to monitor), I think we can allow some things to be both.--Dallan 19:56, 4 March 2011 (EST)

Without escalating or prolonging the debate, I'd like to point out a page that discusses both sources and repositories in genealogy, albeit related to TMG usage, but very pertinent and relevant nonetheless. --BobC 19:04, 5 March 2011 (EST)

Sources, sources, sources [13 May 2012]

Argh!! This has been a frustrating morning. Do we have to educate every new user that comes to WeRelate about sources? It sure seems like it. If it keeps up, all the people that care about sources will leave and this will deteriorate to another WFT or similar, but with a mere fraction of the names. What use will that be?

At first, I thought it was only old pages that were input and abandoned, that surely the big notice on the home page about sources would help. But every day there are new pages input with no sources. Not just grandparents (who somebody at least remembers in their lifetime), but colonial pages, medieval pages. It just seems to be the typical modus operandi to collect genealogical data without bothering about sources. And not surprising, most of these pages have an error of some sort. [Plenty of examples on request.] People that don't take the time to document sources, certainly don't understand the idea of "exhaustive search". This kind of person is a sucker for the first website they come across, and so are prone to errors.

Isn't there some way we can get it across to users that WeRelate is different, that its primary purpose is not to stroke their ego by broadcasting what they have copied off other websites. You are working with others who may not agree with you in a collaborative process. The truth is unknowable, it may only be deduced approximately by the evidence that is left. WeRelate offers to benefit everyone, by combining lots of research tidbits into a collective "exhaustive search" that would be difficult and time consuming to do by oneself. If you don't provide your sources, your work will need to be redone, be it right or wrong. You have not contributed anything to the process by inputting data without sources. It doesn't matter what you "have", it matters what you can prove. It doesn't matter what you know, if matters how you know it. It strikes me as (pick one) discourteous (too much work to bother telling you my sources) or arrogant (of course I am right) or naive (it's on a website, it must be true) to think people should accept your data because you say so. --Jrich 16:01, 3 March 2011 (EST)

Well, who are the source gurus here? Who can a person ask for help? Is there a portal for source discussions? Example: I need to link to the Virginia Gazette as a source. In the sources there is a "Virginia Gazette (Williamsburg)" but when I checked it, it is a book about the Virginia Gazette. There are also indexes to the Virginia Gazette but they are for different years. Where do I go to ask about how to fix this? You say there is a big notice on the front page. You mean the notice that searches are getting easier? That notice doesn't even link to a page with more information. And also, I have more sources for my family. But, I am struggling with how to handle it. Is an obituary copyrighted? I suppose some are and some aren't. Who is the author? None of mine say. I thought WeRelate was for uploading a tree and then working together with historians and cousins to attach sources and collaborate. That is the way it is working for me anyway. I have already contacted a relative of the friend of my 18th century ancestor and we just got started today to collaborate on these two men, compare notes. She has a war pension application that has my ancestor as a character witness. We are preparing that to upload. Ok, here is another delay on one source I have, a document from 1778, which can be found online. I can't upload it here because the scan is copyrighted by the museum. I am hesitant to link to it because libraries and museums are notorious for moving things (including the LOC). I don't want to post links in werelate that will break next week. So while I ponder how to deal with that, all you see is a person with no sources. So, in summary, where is the Source Portal? (and also, there should be templates for the top of articles, just like Wikipedia, that say "this entry has no sources" and "this entry is disputed") --Cthrnvl 08:30, 4 March 2011 (EST)

The message on the home page changes. Last time I looked it said this. Obviously I don't look at the home page often.

For questions, post it on WeRelate:Support.

Obits after 1923 should probably be considered copyrighted unless you have intimate knowledge of its status. This does not prevent citing it, it only affect copying its content. Facts (birth dates, death dates, etc.) are not copyrightable and this is a large part of most obits, and I believe the fair use provision allows you to abstract information from a source briefly without running afoul of copyright law. If you compose a biography of your own creation on a person, you can certainly footnote it with references to the citation of the obit using the appropriate form of <ref name="S1"/>.

Don't know about the Virginia Gazette, but many of WeRelate's source pages were initialized from the Family History Library because it has information on so many, so the pages often reflect the filming of a source, as opposed to the source itself. This gets improved when a knowledgeable user fixes the Source page or creates one. More information at Help:Source pages.

If you don't own an image on the web, you can always include include a link to it the way I included the link to the past message on sources, above. [url display-label] The URL can be copied off your browser bar, a space, and then the text you want displayed as the link to the website. --Jrich 09:38, 4 March 2011 (EST)

What we experienced WeRelate users tend to forget is what it was like being a “newbie”. We need to remember that WR is not the easiest site in the world to use (though IMHO, it is the best for genealogical collaboration). Our help files are difficult to maneuver and we still have multiple versions of the same source. We can’t just assume that everybody has the level of experience that we do. There are times when I need to ask questions at the Support page, and I’ve been here a few years!

So, first: don’t be afraid to ask questions (best place is on the Support page)! Second, to the more experienced WR users reading this… please be careful not to “bark” at the newbies. I know it can be frustrating, but a simple “Hey, I see you are new here, let me give you a few tips and point you in the right direction” will be a lot more pleasant then some of the posts I’ve seen recently. Third, our help files… if we want new users to enter data/sources the “right way”, then we need to make it much easier to find what that “right way” is. That means clearing out the outdated conversations that are anything but helpful. Lastly, perhaps we need to add permanent text to the Main page that makes a statement about the need for sources in a collaborative environment. --Jennifer (JBS66) 13:51, 4 March 2011 (EST)

Re: "barking": I am probably going to continue barking until I give up on WeRelate. I remember what it was like to be a newbie, but what I remember was being scared of misleading somebody with incorrect data, not being the author of 3 separate websites all giving the same incorrect and unsourced family tree (as I ran across recently).

Anyway, this post wasn't aimed just at newbies (after all they come and see pages with no sources, so what's to tell them sources are valued - nor are they the only ones that create pages with no sources). Newbies are, however, a little more disturbing in the sense that it says we are not just correcting sins of the past, but that such practices continue unabated. WeRelate needs to develop a culture that expects, or demands, sources. Hopefully, communicated to brand new users right from the start. I think things could be done: more education as part of the enrollment process, more warnings and flags, a Missing-Source list like the Duplicate list, etc., etc. I don't see how collaboration can be done without sources. We have to stop polluting what could be an incredibly valuable data repository with error-prone, unsourced pages or you will only get new users that find that acceptable. --Jrich 16:09, 4 March 2011 (EST)

There, Jrich, your last statement, albeit unknowingly, agrees with my opinion in the previous thread subject, doesn't it? So if you can outright acknowledge that WeRelate is a repository rather than a source, why can't you see that Wikipedia too is a repository rather than a source. Are the individual WeRelate pages actually any more true sources of data than are Wikipedia pages? Both are compilations of data which are sourced separately and individually. Just an observation. --BobC 22:27, 4 March 2011 (EST)

How about a Sandbox WeRelate, totally separate from this site where people could practice in realtime? I have had a hard time getting started here and partly because it is hard to just jump in without fear of messing up someone else's work. If I could have practiced somewhere it would have helped.--Cthrnvl 14:10, 4 March 2011 (EST)

Info on that is buried in the Help files :-) Help:Sandbox has a link to WeRelate's Sandbox site. --Jennifer (JBS66) 14:13, 4 March 2011 (EST)

I think the big issue is that most genealogists (newbies or not) don't source their work, and so therefore most people who come to WeRelate don't source their work either. I don't mind this, because it's reality, and posting their material to WeRelate gives us a chance to teach them about the importance of sources.

The problem is we're not doing a very good job of encouraging people to source. How can we do this better? I'd like to see some concrete ideas on how to accomplish it. I'll implement the one or two ideas that most people favor. For example, I could show an alert box when I display a page without sources. Or I could add a blurb about the importance of sourcing on a help page (or the main page?). Does Ancestry's "shaky leaf" encourage people to add sources? I don't think we could add shaky leaves anytime soon, but I'd like to know if an effort like that would be worthwhile. Perhaps we could add links that take people to filled-in search forms on the major free websites: FamilySearch record search, Ellis Island, etc. Can we get some ideas started?--Dallan 19:56, 4 March 2011 (EST)

it would be helpful (at least for me) if we could filter the person and familysearch with sourced or unsourced next to watched and unwatched.--Klaas (Ekjansen) 04:58, 5 March 2011 (EST)

Certainly some clear policy pronouncement as part of enrollment that sources are expected with an brief outline of how they are expected to be used. Maybe some optional educational materials that are linked to.

I think maybe even consider gently saying that if they haven't been keeping track of their sources, then their time would be more productively spent going back and fixing that than entering unproven data into WeRelate. WeRelate will be waiting for them when they finish. (It's a great learning process, and unless you were told how to do genealogy before starting, it is probably a step you went through at some point.) But people that don't track sources are probably doing exactly the type of research that causes errors. It is rare not to find multiple errors on a Family page of children that have been entered without sources.

Another suggestion would be, when the duplicate list is compiled by the system, to have it compile a missing source list, so people can find all the pages on their watchlist without sources. When they login can they get a message if they have a non-empty duplicate or missing source list? Warning emails when the size of one of this lists gets over a certain number?

When a page is saved, if there is a non-empty date without a source or note tag attached, insert something like {{cn}} (^{Citation needed}) in the source field for that date. It's kind of arbitrary to pick just dates, but it seems like it would be easy to implement. The What Links Here for this template would provide a list of pages that people could try to work on to improve WeRelate.

I would be opposed to automatic flagging in this manner unless there was a way to override it. For example, here I sourced the birth in the text of the Personal History section of the page to be more clear what the sources referred to. Only one of the three sources for his approximate year of birth actually gave the specific location. Moverton 14:04, 6 March 2011 (EST)

There's no reason I can't see why you could not also tag the birth date on your example page. You'd have to explain why it would damage the page put the S1,S3,S4 footnotes for the birth field as well as tagging the statement in your narrative. Even if you didn't want to, it is one page against tens of thousands of pages with no sources. As an aside, your links to familysearch.org are all https which means a login is required to follow them. Since this data is all available to the public without a login, it would be a little more convenient to the reader is you used a public link, such as William Overton death record of 1857 aged 67. --Jrich 15:08, 6 March 2011 (EST)

JRich, I don't understand your comment about the familysearch link. I can view Moverton's link just fine without being signed in. Also, I thought the labs address was being moved to their main http://www.familysearch.org address (which, for me, automatically goes to https://www.familysearch.org). --Jennifer (JBS66) 15:19, 6 March 2011 (EST)

Sorry, thanks for pointing that out. This appears to be my mistake. It is working now. I must have been working on the old computer that doesn't/can't have a adequate version of Flash installed. I assumed the https indicated some kind of new Family Search login was used, which apparently was wrong. Sorry. --Jrich 17:00, 6 March 2011 (EST)

Ditto Jennifer. Plus, I prefer to be specific about which information is being sourced. I'm not sure that all users reading the page and seeing the source links would understand that all of those sources don't source both the date and location. Perhaps it doesn't matter, but I just don't like leaving any ambiguity. Moverton 15:27, 6 March 2011 (EST)

Well, there aren't separate source fields for both date and place, so while I understand what you are saying, by doing that, you are repeating a single fact in two places on the page, in the birth field and again in the narrative, which I believe is potentially worse. If eventually somebody finds the appropriate parish record and updates the birth/baptism date, hopefully they will remember to change the narrative as well, or else it will not make much sense. It seems pretty intuitive to me that a death record with age at death cannot have much authority about birth location, just like marriage intentions don't really say where a couple actually got married, etc. This is one of the reasons why I believe a source citation should at least include an abstract of what the source says. It would be far better in my opinion (to avoid having two copies of the birth date on the page) to simply annotate the source citation with a comment like "No information given as to location of birth" if you wanted to make that explicitly clear. After all, that annotation to the source citation about what the source says will be true and can remain even if the data is later updated and another source added to the page. --Jrich 17:00, 6 March 2011 (EST)

Different users will likely use different styles in creating their pages, and I don't think there is one right way to do it. I tend to view the list of dated items as a simple list with any descriptions kept short and to the point. The larger text field can be used to write a professional-looking biography (including restating the listed items) following the usual genealogical standards. However when the facts and sources are limited to only a few, I probably wouldn't bother writing anything extra. Moverton 22:52, 6 March 2011 (EST)

I'd like to see source pages for certain sources contain right in their citation a message to the effect "Help improve this page by providing a more reliable source". A template added to the end of the title box, or one of the other information fields could do this? This would give people some feedback that the quality is less than desired. If people aren't aware, they won't even realize unless told.

On a related note, the Help pages need some work. I think the popups that result from the questions mark next to a data entry field should contain a link to a detailed help page on that field. (Digression: I wish they were buttons instead of mouseovers - I activate them by mistake all the time.) It is difficult to use Search to find the correct help page. Half the time you want the massive Formatting help which doesn't cover individual items enough, and half the time the topic in on a page whose title makes it hard to associated with the name of data field on the screen. --Jrich 21:32, 4 March 2011 (EST)

I like the idea of awarding a carrot for effort and improvement rather than using a stick for laziness and noncompliance. Modifying, standardizing, objectifying and improving the featured page award has been and would be a step in the right direction. Educating and encouraging new contributors to add source references to their unsourced data or poorly sourced material may improve the quality of contributions. Giving subscribers more time to add to, research, reference and source their new GEDCOM data uploads, rather than deleting the files after some unprescribed time period at the whim of a WR Admin may also assist in that effort. Unsourced data or poorly sourced information should not be thought of as false, bogus or junk genealogy; it is just as yet unsourced or poorly sourced. While that is not ideal and should not be encouraged (as it may seem to be at Ancestry.com), it should not be automatically eliminated unilaterally. --BobC 22:59, 4 March 2011 (EST)

The carrot's fine, but if the people that need improvement don't see it, or don't care, it has no effect, i.e., it may not be very efficient. What people need is some feedback (the faster the better) that they are doing things wrong, since doing things wrong seems to be the accepted standard at so many genealogy websites. I have at other times argued that things should not be deleted just because they are unsourced. However, as I approach my third anniversary at WeRelate, the last two of which have been primarily trying to increase the number of pages with sources on them, I have become convinced that there is a high correlation between unsourced data and significant errors. As mentioned above, if you don't collect sources, you probably don't understand the GPS item "exhaustive search", you are probably relying on one source, and you probably stopped looking as soon as you filled in the blank, without trying to finding any corroborating sources. This is a methodology that practically causes errors. Just this morning: Person talk:Edith Adams (6). If the person had had to find a source for 24 Apr 1761, they would have either cited an Ancestry tree or discovered their error. If citing Ancestry caused the citation to contain a flashing flag that this is unreliable, they may have gone looking for another source. A few of those and they learn first hand. --Jrich 09:38, 5 March 2011 (EST)

The above comment about Edith Adams was posted Saturday. It is now Monday morning. Since that time I have found, researched and removed the following unsourced data as unlikely. In all cases a precise date was given with no source, which appears in actuality to be not only unproven, but actually unlikely. Sometimes, as in the Edith Adams case above, one can eventually figure out where the date came from, but in most cases, following GPS ideals of ruling out alternatives, one spins their wheels searching for the justification for this date with no luck. I am sure I end up giving this bogus data more time and respect than the original creator ever spent collecting it.

• Person talk:Jonathan Peck (1)
• Person talk:William Bradford (1)
• Family talk:Samuel Shattuck and Elizabeth Blood (1)

And although this was done a few days before (last Wednesday), I especially like this one: Family talk:Peregrine White and Sarah Bassett (1) about a Mayflower passenger! (Well he rode across the bay at least). Some of these precise dates are so far off, a GEDCOM upload may not be able to recognize these people as the same individual being uploaded. So, if not by strict logic, in practice, no sources very often does mean "false, bogus or junk genealogy". --Jrich 11:50, 7 March 2011 (EST)

Right now, a search groups together namespace pages along with their talk pages. So, if I search Help for 'sandbox', conversations on Help talk pages are also returned. Some of these conversations are outdated. I wonder if a user searching for help should be directed to the Help page - rather than any of the talk pages by default. --Jennifer (JBS66) 08:00, 5 March 2011 (EST)

Many of these unsourced pages are coming thru on the newer gedcoms that have been recently uploaded. We've got to find a way to increase the "quality" (dates, sources, etc.) of the newer gedcoms. A couple of weeks ago I reviewed a gedcom that was (in my opinion) poorly sourced, that had several successive generations with absolutely no dates or information whatsoever, and asked the contributor to go back and add dates and sources to the gedcom and re-load it. I was told that I was being "too hard" on the contributor..... Is it too much to expect for people loading gedcoms to limit them to those families that have been thoroughly researched (obviously those would include dates and sources) before they upload them to WeRelate? We do have a stated rule that we won't accept gedcoms without dates (which on the surface would indicate they know little about the family), when are we going to enforce this?

-- Jim

I think it's a little hard to apply a single standard for GEDCOM uploads. A GEDCOM could be riddled with weaknesses and problems, but if the user is taking it as a starting point for work it may be just fine. By contrast, an average or borderline quality upload that is abandoned may be pretty annoying. I've long felt like the right approach is to have soft quality thresholds that are somehow a function of the seeming commitment of the user to the community. In other words - if you've never done anything here before - then we expect a lot. If you are a long serving contributor - we can afford to be more soft.

My second point isn't just about sources, but general quality. The defects which are detected in GEDCOM uploads really should be detectable and reportable across the data base. Such defects could include unsourced facts and/or use of dubious/weak sources. In the same way we were able to clean up duplication we need similar support to start identifying and strengthening the database.

--Jrm03063 09:25, 7 March 2011 (EST)

Jrm, not sure I understand your post, but would one of the expectations of newer users be to only upload gedcoms that have birthdates, marriage dates (even if estimated), and at least SOME sources? Not talking about a "single standard", but how about we at least "raise the bar" from where we are now (where we accept just about anything). Without any dates, the gedcom review analyzing process can't find "errors" (children born before marriage date, children born before parents, children born 50-60 years after their parents, etc., etc., etc)..... I would submit that a user that submits a gedcom with several successive generations without at least birthdates and marriage dates has not done much research, and shouldn't be uploading that information to WeRelate. -- Jim

All I'm saying is that it's not as important where you start, as where you finish. I'm not lobbying for any particular quality standards - only saying that absolute metrics may not be appropriate for all sorts of users. Beyond that, we need to move weakness and inconsistency detection beyond the GEDCOM import phase and into the regular database space. --Jrm03063 11:51, 7 March 2011 (EST)

Jim, with all due respect, I don't understand where you are getting the idea that we are accepting "just about anything" from gedcom uploads. This is simply not true. I'd encourage you to take a look at some of Judy's recent notes to new users which clearly explain things such as " There are no events containing dates and places which will enable someone to identify the person. We will not be able to use this file.". In regards to the gedcom you previously mentioned, that file did have sources, many of which were in the text fields instead of being listed in the Sources tab. As long as the sources are there, we don't require that they be in a standard source format as this is not always consistent across software packages. --Jennifer (JBS66) 10:17, 7 March 2011 (EST)

--- You are correct, the file in question did have several pages with good sources and narrative. My objection was with several other person and family pages that had absolutely no dates, places or sources, in several successive generations. My original request to the submitter was to either add dates and sources to those persons, or upload a new gedcom without them. Not trying to bend anyone's nose out of shape, but if we are committed to raising the quality of submittals, we should to so as part of the gedcom review process, IMHO, and make sure that submitters understand that they should only submit their families that have been thoroughly researched (with dates) and sourced. I wouldn't upload a family that I at least didn't have birthdates, marriage dates, children's birthdates, etc., don't think we should accept them from others..... (again, just my opinion, which I believe we're still able to offer up on the watercooler....) -- Jim

I understand the frustration of having to deal with incorrect, badly sourced, unthought-out family information. (I’ve thrown a few tantrums of my own.) However, I don’t agree that shutting people out is always the best way to deal with it, especially if we want WeRelate to survive and grow.

1) As Moverton points out, we don’t always know why sources aren’t cited, and from what I’ve seen, I question whether anyone can claim they have no pages that lack source citations. As Jennifer (JBS66) points out, there is a screening process in uploading a gedcom, one of the things I like about WeRelate, but one of the things that does discourage other researchers, including some very good researchers. So while each page may not be perfect, we do need to keep in mind the question of survival.

2) Sharing and collaborating means that when you have a source to add to a page, then add it. If the information on a page is wrong and you have the documentation (note that sources and documentation are NOT the same thing), then add your source along with an explanation in the text field as to why you believe the other source is incorrect (or problematic), but leave the other information there, especially if there is a source citation.

Ideally, this might be correct. But in reality there are a few problems with it. What impression on potential users does it create when they browse an ancestor's page that they have investigated and find mistakes and no sources? They say, "I am going to get nothing out of this web site" and never start collaborating. The other issue is that because of the past expectations generated by read only posting of GEDCOMS, the number of people that don't post sources will overwhelm the fraction that come along and try to clean up after them. It is not about one page without sources (easy to do if you get interrupted), or the honest mistake (easy to do if that ground-breaking source in only in a library across the county), it is about people whose methodology is not to track sources, or think unsourced Internet information qualifies as a source. These people propagate mistakes, and generally aren't aware of it. They need feedback to tell them WeRelate expects more. They need feeback to help move them from the liability camp to the productive contributor camp. --Jrich 14:08, 7 March 2011 (EST)

This provides a form of education both to the other users of the page and to anyone who sees the page through a Google (e.g.) search. It may give an example of why some sources are better than others (and even the “best” sources are sometimes “wrong”), or it may provide an example of why analysis is an important part of “proof”. Providing the examples is one way to educate others. It will take time, since we are battling the effects of Ancestry and their money, but it is a fight that is being waged (gently) in more places than WeRelate (Salt Lake Institute of Genealogy, for one). Again, yes, it takes time. I just spent the better part of three days adding two wills and a probate record to pages that aren’t even “mine” in the interest of getting the information and examples of the process out there.

3) Has anyone looked at the Wiki etiquette page recently?

4) For Dallan, for now, maybe it would be possible to add a line to the “BlankFamily.ged Imported Successfully” message to encourage people to start adding sources, with a link to a page on why sources are important (something along the lines of The problem of the commons. Warning flags, like on Wikipedia, could come later, but how long did they wait before implementing that policy?--GayelKnott 13:29, 7 March 2011 (EST)

On the subject of missing sources: I've recently rec'd email concerning a John Jackson whose parents no one can identify. I know of several different researchers trying to find his parents but so far, lots of assumptions, but no one has found verifying documentation. The person who wrote me will share her family research and probably will give me permission to put it on WeRelate for her - but she hasn't saved any of her sources; said she didn't know at the time she was going to care about sources. But now she and I would like to put her info on WeRelate in hopes that other folks can add sources and related family. Now would Jrich rather we kept this to ourselves until our research is mature enough to be well sourced; or can we use WeRelate as a parking spot to contain what we know until someone knows more and/or better information??

I'm going to hang in here, but if I am able to pursuade her to upload her info and she gets 'barked' at - that would be the end of that relationship! She is 81 years old and will not come to WeRelate to be educated. So I'd like the administrators to decide and make it clear to potential viewers if they are not welcome without sources or they may be welcome but will be harshly corrected. If folks are welcome without sources, please find a more compassionate way to bring correction if necessary. This is a public site; perhaps some would rather it be a private place for only trusted uploaders. --Janiejac 14:28, 8 March 2011 (EST)

I'll give my personal response for what it's worth, since I seem to be the loudest barker at this particular moment. First of it, it's not just about sources, rather that their absence is such a good indicator of bad research methodology. But if you have sources, and they are all unsourced family trees from the Internet, that's no better, and shows no more understanding of the nature of genealogical proof than does no sources.

Secondly, if a reader is to treat what's posted on WeRelate with some respect (for example, to take the time to refute it by identifying contradicting evidence (with sources), rather than just throwing it out and replacing with their own data without any explanation), I think the poster needs to have the respect for reader to say where they got the data in the first place. Phony data wastes a whole lot of the reader's time, and is frustrating when it becomes clear that the poster was careless and lazy in their researching. The reader deserves to know there is a valid reason for thinking the data could be true before they spend their time trying to confirm or refute it.

I haven't seen the research you are talking about, and cannot assess its worth. (I take it you haven't either.) Therefore, none of my comments apply specifically to that research. Nor am I aware of the nature of John Jackson's controversy, though I have researched many controversies. I am hoping that some assessment will be made whether the research has value before posting it.

Some people's idea of research is just a collection of every wild speculative proposal that can be collected off various websites. I expect any WeRelate user is perfectly capable of using a search engine to find various websites mentioning a person, so I don't see that many readers will get any real value of this. Perhaps it even has negative value, elevating so much clutter to have an equal footing with serious research.

On the other hand, if this research identifies pertinent primary documents, maybe quoting a will here, a deed there, etc., even if it isn't recorded where it was found, then that would be valuable. If it

• documents what is provably known (eventually with sources)
• then adds to that any reasonable hypotheses that haven't been ruled out, giving the circumstantial evidence and explanations of why they are thought to be feasible (eventually with sources)
• refutes those disproven theories that appear in reputable sources (i.e., perhaps Savage) to keep readers from going down dead ends (evenutally with sources)
• avoids the noise (stuff with no sources)

then it will be an extremely useful addition, and bring it on.

And a note saying that a project is underway to resurrect the sources, maybe even soliciting help, is certain to illustrate the good faith of the researcher. I would even like to help. --Jrich 16:30, 8 March 2011 (EST)

OK, that clarifies the situation better. So it sounds like before I upload her information, I should make the effort to locate sources for her information. At least her info gives me a place to start. But because it is not my direct Jackson line, it probably will fall to the bottom of the to-do stack and may never get done. I just thought it was info that was worth keeping and hoped that someone could add to it. Her brother did participate in DNA testing so we know the results of that testing but it hasn't helped find John Jackson's parents.

Thanks for your offer to help, but I probably should spend my time getting my own line uploaded first. I tend to upload small bits of info instead, because it is easier than figuring out how to divy up my large database for uploading <g>. And yes, my own database has some info from certain rootsweb charts that I thought were well done. But I am careful where I take it from and make an effort to see that it is at least logical.

One 'trick' I learned when linking to rootsweb charts is to be sure I don't link to the actual person page because the link will change whenever the author updates their records. If you link to their index page, it does not change even when updated and so the info is still available. --Janiejac 18:52, 8 March 2011 (EST)

Re this trick - if you're talking about WorldConnect, that's not true in my experience. WC uses the user ID pulled from the user's own files in order to create the page ID's, so they stay consistent when there are updates. At least they should with most desktop programs. Doesn't help if the person is deleted, of course, but I'm positive that my pages have stayed the same over the years. --Amelia 23:40, 8 March 2011 (EST)

Just FYI, only about half of the gedcoms uploaded to WeRelate contain unique id's. I was surprised by this. It really complicates the gedcom re-upload capability that we're trying to add.--Dallan 17:56, 11 March 2011 (EST)

On the general issue, I don't think we can come to a generally applicable rule other than what we already have - talk to people about the general principles and hope they listen, which apparently they have since our growth rate is down so drastically (although that's also, and perhaps more, based on the programmed limitations). The problem is that we can't tell the difference, automatically, between nonsense culled from unreliable web and Ancestral File sources and the precious unique information copied from great-great-grandma's family bible, with only a single note on great-grandma telling us that. And if that note is missing, a human is hard pressed to tell the difference either without some digging. And most of it is somewhere in between, with the chances of greater reliability depending a lot on time period and and geographic area. So I think we have to keep relying on human intervention, and suggestions for improvement. So long as those suggestions are open to the idea of 'works in progress', I'm okay if they scare people off. I do agree, though, that all bets are off when there are multiple generations with no dates or places - I have no problem supporting a programatic ban on those.--Amelia 23:40, 8 March 2011 (EST)

I think we have to continue to be willing to accept gedcom's and online page additions that are not well-sourced. The reality is that most genealogists don't source. And how will they learn unless they participate in a community that teaches them? I think this needs to be one of the purposes of WeRelate: teaching people how to become better genealogists.

What do people think about the following:

1. Anytime an unsourced event is displayed, the sytem adds a citation needed template link. You can avoid this by linking to a source citation that describes the source or explains why you don't have one.
2. I'll add a sourced/unsourced checkbox to the Person/Family search screen so people can see which pages aren't sourced. The question is, what do we return when someone selects "unsourced": pages with no sources whatsover, or pages containing sources but where at least one event is unsourced? (I'm thinking the former.)
3. I add a "Show unsourced" option to the MyRelate menu that takes people to the search screen for people with both the Watched and Unsourced boxes checked.
4. I'll change the help ?'s to respond only to mouse-clicks, not hover.
5. I'll add an "include talk pages" checkbox on the search screen. This box will be checked by default. Talk pages won't be returned if the box is unchecked.
6. I'll modify the "your gedcom has been uploaded" message to include a reminder to use the "Show unsourced" screen and add sources.
7. We haven't discussed this, but what if I add a "Find Sources" link to the left-hand side of every person/family page, which opens a new window showing a pre-filled-in search at FamilySearch.org? They have 2B searchable names now.

Thoughts?--Dallan 17:56, 11 March 2011 (EST)

Re #1, would it be possible to only display 'citation needed' if there's no source or note (or maybe an image, not sure about that one). There are going to be lots of times where a birthdate can be estimated, and that's helpful to add, but it would be more appropriate to just free text explain the estimate rather than fake a source (the latter's possible if it's a programming problem, just not as simple and will cause unnecessary templates on existing pages).

Re #2, agreed that the former is more useful. Let's work on the low-hanging fruit first.

Re #7, I'm not a fan of any of those type of automatic searches because I think they're misleading a great portion of the time, although I won't deny that they're the popular thing. Have we added the FS 'collections' yet as sources? We can't expect people who don't know how to source to find the underlying sources from the film numbers, so we'd need to have the collections as sources before we did this.--Amelia 18:30, 12 March 2011 (EST)

I like all of Dallan's suggestions. BTW, Amelia, some of the FS collections do have Source pages. I'm a bit confused what you mean about people having difficulty finding the underlying sources from the film numbers, so that's why the collections need Source pages. If what you are using is the FS collection, that's what you're supposed to be citing. (Though I make the case that if you're using the digital image, that's what you cite.) But that question is probably going off-topic for this discussion. -- Amy (Ajcrow) 19:58, 12 March 2011 (EST)

I think a note should be good enough to bypass any flagging of a fact.

Either meaning of unsourced is acceptable. Believing every fact should be sourced, I lean towards unsourced meaning having at least one ^{Citation needed} on it. Add a checkbox to Search is good idea, nice and simple. A little less of an active notice than I would like perhaps, but it provides the basic functionality. --Jrich 18:55, 12 March 2011 (EST)

I have trouble following most Watercooler discussions – must be my advanced age – but the impression I get is that contributing to WeRelate is not going to get easier. Personally, I have found that it is better to import small (15 to 50 persons) gedcoms without sources and then add the sources that are already in the WR files. Reason? I found that the sources with my earlier imports ended up as cryptic MySources – just clutter. I think the KISS principle is best.--HLJ411 21:21, 12 March 2011 (EST)

I totally agree with Amelia’s comments, and also with HLJ411. I deliberately uploaded gedcoms largely without sources in part because they all ended up as very messy MySources and trying to convert them to meet WeRelate’s Source standards seemed impossible. I’m adding sources as fast I can, but I don’t believe that one or two references to vital records or a census or two constitutes good documentation, which seems to be the standard for many pages that are “sourced”. As a result, it can take several days just to document one person.

One of the reasons for the talk page is to ask people if they have sources. And I still don’t understand what is so awful about adding sources yourself if they aren’t already there. Isn’t that part of the reason there is only one page per ancestor/person? Isn't that part of what collaboration is all about?

I’ve also seen pages where sources are obviously scattered throughout text notes but not entered in the source fields. In at least one case, the person who originally created the page had obviously made an effort to enter sources using the WeRelate formatting language but without success. So should this person be penalized because they haven’t used “proper” sourcing?

Learning to use WeRelate is not easy. I’ve tried to get several people to participate in WeRelate, with relatively little success, primarily because they recognize that there is going to be a very steep learning curve. What they don’t realize is that the most difficult part of the learning curve is adding the sources from the WeRelate Source list. This is not easy to learn, especially if you have sources from a wide variety of repositories.

I believe in the importance of documenting research, and I think people need to be encouraged to add their sources whatever those sources are, but I also think we need to be careful not to appear so arrogant and snobbish that we turn away people who are willing to learn.--GayelKnott 00:59, 13 March 2011 (EST)

I disagree with several things that were said in the previous post.

"As a result, it can take several days just to document one person." Or a lifetime. Of course, like the odds of winning a lottery, the biggest return for your dollar is going from zero to one ticket, while one to two, two to three, etc., don't really improve your odds as much as that first one. Following the example of the Great Migration Begins documentation, the idea of pages alluded to is to provide the key/best known sources that support a fact. So generally two vital records, one for birth, one for death, and a reputable genealogist saying they agree with that attribution of those vital records is pretty good skeleton on which to flesh may be added later. The pages aren't done. I prefer to reserve the time-consuming search of land records, tracking down family letters, etc., for people in my own family tree, not the unsourced pages of others that I have been cleaning up.

"One of the reasons for the talk page is to ask people if they have sources." So few people respond to talk messages about changes I make, I almost don't need to reply to this. Second, why should I have to ask? If the source is on the page already, it saves time, which is considerate. And how is the need to ask going to help the person using this website twenty or thirty years from now? Third, how can I assess the credibility of the fact without a source? And this is something I always need to do, so what benefit is there in withholding sources? Out of respect for all posters, I would like to, not just overwrite their data with mine as if they could never be correct, but give the evidence that shows theirs is wrong, to demonstrate that I actually considered its possibility. To construct that argument I need to know what it is based on, and since it takes time to do this, I deserve to know that there is a credible reason for thinking their fact is true, and not because, as has been shown by my trying to reconstruct their sources for them, that they copied from somebody else that was as clueless as them.

"So should this person be penalized because they haven’t used “proper” sourcing?" First, what has been proposed is flagging items, just like wikipedia flags articles that need work. I don't see that this is penalizing, but it is feedback that more is desired. (Actually, my personal preference would be more punitive, to take away editing capabilities if people accumulated too many unsourced pages for the reason that follows.) Second, as has been the main topic in the discussion above, people that don't document sources have a very high error rate. For the most part, people that don't use sources are exactly the people that are propagating Internet myths, doing genealogy by matching names, and filling in the blanks as fast as they can. AFNs and PRFs of familysearch.org and family trees of Ancestry.com are not the model I had in mind for WeRelate. I humbly suggest, to people that do, to go to those sites instead. WeRelate has the promise of being the next stage in Internet genealogy, not just access to data, but a data repository built and maintained by the community reflecting, not one person's, but the community's consensus. It cannot achieve this by making the same mistakes those others made (such as not requiring sources, allowing people to post whatever they wanted).

"Learning to use WeRelate is not easy." Genealogy is far harder. If you spend the time to do the research, isn't it worth the time to make sure it gets communicated accurately? Actually, I think WeRelate makes a lot of sense. Where it is harder than other sites is precisely because of those features that make it better (merging into a unified tree, source citations). I think the difficulty is that WeRelate is different than one's home system and the need to document for the community is probably something new to many users. And they are disappointed because their informal research doesn't translate well to a collaborative environment. There are different requirements being part of a community family tree than when building a private family tree on one's home computer. It is not unique to WeRelate. At one point I wanted to start sharing my work with others in the hopes of it being improved on, and as a result, I had to spend a couple of years redoing a lot of my research so I could have some confidence I was not giving out false information. This may be the type of effort that is implied by "willing to learn" (your phrase below).

"I also think we need to be careful not to appear so arrogant and snobbish that we turn away people who are willing to learn." I think people shouldn't be so arrogant to think that five minutes searching the Internet for matching names is genealogy. Or that others should believe them just because they say so, because their judgment about which AFN to choose is so infallible. Or that their unsupported opinion is providing value to the readers of this website. At home, one can manage one's personal family tree however is desired. But how can a community family tree be based on any ideal other than truth? And that requires objective evidence (i.e., sources). The fact is, this may not be what all people are ready to sign up for. Those people are probably looking for a different website. Better they find this out early. --Jrich 11:31, 13 March 2011 (EDT)

• I won't add the citation-needed if there's a source citation, or note, or image.
• User:Spencer is working (slowly) on adding Source pages for the new online collections as FamilySearch.
• The "Show unsourced" search checkbox will show pages that have one or more unsourced events.
• I actually agree that using WeRelate is hard. Some of the difficulty is inherent in a community website (the need to check for matches before adding a person). But there are other problems as well, which should be solvable by a better interface (needing to create a family page and then a person page when you want to add a spouse for example). I'm slowly working on these things, but it takes time.
• I don't think there's anything wrong with uploading an unsourced gedcom and adding the sources after-the-fact if that's really the uploader's intent. The "Show unsourced" search checkbox should make identifying which pages need sources much easier.

I'll start working on the items 1 through 6 next week. I'm going to postpone item 7 (FamilySearch link) for awhile.--Dallan 20:52, 17 March 2011 (EDT)

War categories [5 April 2011]

I've noticed that the category Category:American Revolutionary War Figures has been defined as a category for everyone who fought in the Revolutionary War. This raises two issues.

1. ) Do we want separate categories for 'notable' people in a war (Washington, Stonewall Jackson, Robert E. Lee) v. everybody else? If yes, we need to unmix this one and set up a parallel set of categories.
2. ) Are categories that can eventually number in the hundreds of thousands of entries useful?

I personally think 'no' on #2, but I'm not sure what the current category structure has to say. Even if we keep such a category to serve as a search criteria or page marker, I also vote for separating them out from the Notable People categories; otherwise those categories lose all their meaning and people notable for their military accomplishments don't get highlighted.--Amelia 19:27, 3 March 2011 (EST)

I've been wrestling with this one, too. I agree that categories that could number in the hundreds of thousands are not useful. I hesitate, however, to have only "Notable" categories. Just thinking out loud here: how unwieldy would it be to have subcategories so that we can include everyone who served? For example, under the Civil War, we could have a subcategory for each state, then sub-subcategories for each regiment. The category structure would be U.S. Civil War figures -> Ohio -> 133rd Ohio Infantry. (Then the regiment category would be the one linked on the person's page.) As someone who looks for information on one Civil War regiment, I think that there is a need/desire to be able to find all of the men from a specific unit. For earlier wars, like the Rev War, it could be just by state, since the regiments weren't regularly named. --Amy (Ajcrow) 20:02, 3 March 2011 (EST)

I can see the value in sub-categories, I think we already have some, actually. How about having a "Veterans" category (I don't know what parent, maybe Notable persons for now, although that doesn't seem quite right), with a hierarchy Veterans -> U.S. Civil War Veterans -> Ohio Civil War Veterans-> 133rd Ohio Infantry. If we can define that as the sub-cat format (#, state spelled out, type of unit capitalized) it also lets us add the categories to people without looking it up every time. I also think these categories make sense for the sources out there, as well (general books in the national category, more specific ones by state). Anyone have a theory how we divide up the other wars?--Amelia 09:19, 6 March 2011 (EST)

I've been thinking more about this. We could have the "main" category be Veterans, unless there's a compelling reason not to. I like how you've delineated it for the Civil War. It would also work for the Mexican-American War, the Spanish-American War and the Philippine Insurrection. I'm not sure what to do about Rev War and War of 1812, since the smaller units weren't given standardized names. But we could try American Revolutionary War Veterans -> Pennsylvania Revolutionary War Veterans -> Captain McCullough's Company. (And do the same thing with War of 1812.) Thoughts?

I'd also like to see the links on the Person pages to use the sort key and put surname first. (Honestly, I'd like to see all the category links on person pages use some kind of sort key. Having everyone listed under P for person, then by first name isn't the easiest way to navigate the data.) These category pages are going to be fairly good size, and it would be a lot easier for users to scan by surname than to read by first name. -- Amy (Ajcrow) 16:24, 5 April 2011 (EDT)

Random page [4 March 2011]

Is there a way to view a random page? Even better, is there a way to view a random Person, Family, Source, or Place page? I think that would be a useful feature if we don't have it already. It would be a way that people could explore the site without having to do a search. Some people are just curious and want to poke around, but don't necessarily have something specific that they want to look for. Plus, it would be fun to just start browsing. -- Amy (Ajcrow) 22:26, 3 March 2011 (EST)

There is a way to do this, it's under Admin>Special Pages>Random Page. That link, however, will only find a random page in the Main Namespace. To find a random page in other namespaces, you can add a parameter to the link like this: http://www.werelate.org/wiki/Special:Randompage/Person. --Jennifer (JBS66) 05:37, 4 March 2011 (EST)

Thanks for the link, Jennifer. Being buried under 2 levels of menu doesn't make it easy or intuitive to find. (And how many people who aren't Admins or don't even have an account are going to look for something like that under the "Admin" menu?) I think there should be a "View a Random Person Page" link right on the main page. Let's encourage curiosity and give people as many ways as possible to start exploring the site. -- Amy (Ajcrow) 07:21, 4 March 2011 (EST)

Growth?? [8 April 2011]

March 22, 2010 – 1,821,417 persons, March 3, 2011 – 2,002,526. Growth rate of 1,000,000 every 5.23 years. Next milestones May 2016 – 3,000,000 then 4 million in 2021! Is this rate of growth sufficient for survival? What can be done to make WeRelate easier to use? I know it’s not comparable but Rootsweb claims 2.5 million added in about one month. Family Search volunteers have indexed 36 million records so far in 2011.--HLJ411 13:39, 4 March 2011 (EST)

The biggest challenge is lack of programmer resources to make WeRelate easier to use. Right now it's just me, and I work on it when I can in my spare time. If there are programmers out there who are willing to donate their time to work on WeRelate, please send me an email.--Dallan 19:56, 4 March 2011 (EST)

Dallan, can you clarify what type of programmers you are looking for? Knowledge of which programming language is necessary? You may also want to add a note to the Main Page News section about this as well. --Jennifer (JBS66) 06:28, 5 March 2011 (EST)

One thought I had was to expand the 'projects' angle and encourage people with extensive good quality data to donate here.

I had tabulated an entire english parish and was contemplating building a website. WeRelate covered 80-90% of my requirements - so I can save that effort and pit it into research. I am currently compiling two adjacent parishes.

I would like to investigate the issues that people with lots of already good data have, and help develop tools to import into WeRelate in the most efficient way. I found I had lots of 'fix-up' after importing.

It leads a bit into what I could call "pre-filling" ie if volunteers adopt a geographical area, and compile and solve as mamy of the records to that area they can. There would be no 'meat' on those bones but the bones would be arranged in the best possible system If a relative comes later with unique information, they find the records for that person already there.

Such a process would help WeRelate keep pace and enhance its reputation as a quality reference

Anyway, Dallan. Id like to explore helping out. Im not a full blown programmer and not strong in Web programming. I used to do a lit of lotus notes stuff and currently work as a DBA/systems admin/jack of all trades in IT. If you could point me in the direction of some relevant (to WeRelate)learning rescources I'll see if I can develop enough skills to be helpful, It'd certainly help my re-employment prospects were I to move on from my current employment.

Great work by the way !--Dsrodgers34 01:16, 5 March 2011 (EST)

Thanks! What I could really use are people who are good with Javascript (jQuery and jQueryUI) and to a lesser extent, people who are good with CSS. One of the things I would like to do is change the add-spouse and add-parents function so that they automatically create the family page and the person page at the same time, but to do this for parents we need to have an interaction where we first do a duplicates-check for the father, and then for the mother. Also, the auto-complete drop-down that I've been using has some bugs, and it would be nice to switch over to the new jQueryUI auto-complete widget. Other jQueryUI widgets that would be nice to add as well. If you're interested, please send me a note. I'll post a note on the main page as well.

Expanding projects is also a great idea. That doesn't require my involvement; please feel free to start on this anytime.--Dallan 17:56, 11 March 2011 (EST)

In terms of how to get growth, people need to know it exists - and at the moment pages don't come up in Google searches unless someone has put a link to it from a website outside WeRelate. I'd been thinking for some time that this sort of collaborative website would be a good idea, but was blissfully unaware that it already existed. Few more links from other sites' message boards (where it's appropriate to do so, obviously) might help increase people's probability of finding WeRelate in the first place.--RichardK 10:15, 8 April 2011 (EDT)

Descendants of Immigrant projects [5 March 2011]

Surnames in places like America often have several different origins. I belong to a Varner (Warner, Werner, Vernor, etc.) DNA project, and there are three distinct groupings of related people in addition to some unrelated individuals. The largest of the groups, descendants of the immigrant Johannes Adam "Hans" Werner and his wife, would like to have a project page in which to discuss among other things: individuals who descend from the immigrant, geographic spread within North America, Y-DNA variations and possible relationships, European origins of the immigrants, etc. Person pages could be created that all members of the project could edit and collaborate on. Has anyone created such a project page before? Would it be better as a separate project, or as a sub-page off the immigrant person page or family group page?--Parsa 15:42, 4 March 2011 (EST)

I don't think we've ever had a DNA-oriented project page before, but it sounds like a great idea. Feel free to create a project page. I would create the project homepage as a separate page, in the "article" namespace.--Dallan 19:56, 4 March 2011 (EST)

For inspiration or ideas you may want to look at a few pages with DNA-related content, information or references.

Here at WeRelate:

• The Howard Historian's DNA Project
• Trout-DNA Research Project Newsletter 04/30/06
• Edward, John, and Joseph Howard DNA Project
• John Howard DNA Project
• Mathew Howard DNA Project
• Morrow in North Carolina
• Notebook9:George Teater (1)
• Notebook:Walker Family in the Carolina Cradle
• Walker Family in the Carolina Cradle
• YDNA Signatures
• Notebook:Gunstocker John Walker
• YDNA:Snoddy
• Douglas in Scotland.

External Sites:

• RootsWeb DNA Projects
• Blanchard Family DNA Project
• Family Tree DNA
• RootsWeb GENEALOGY-DNA-L Archives
• Dean Surname Y-DNA Project
• Parker Family DNA Project
• West Family DNA Project
• Massey DNA Project
• Alexandria DNA Project
• Denny DNA Project
• The Irish Type III Website
• Johnson DNA Web Page
• Lindsay DNA Group
• Kimble/Kimmel Y-DNA Project
• Hope DNA Surname Project
• Overton DNA Project
• Farris Surname DNA Project Page
• Clan MacMillan DNA Project
• Williams DNA Project
• Phelps DNA Project

Good luck. --BobC 19:31, 5 March 2011 (EST)

Who was Amanda Malvina? [10 March 2011]

Amanda Malvina appears to have been a popular girl's name in the 19th century. I find it everywhere I research. There has to be a historical figure these girls were named for. But I have been unable to turn her up. Does anyone know who the original Amanda Malvina was? Maybe this would be a good challenge question? --Judy (jlanoux) 11:41, 10 March 2011 (EST)

Perhaps from the character Amanda Malvina Fitzallen in The children of the abbey. See also this source --Jennifer (JBS66) 11:53, 10 March 2011 (EST)

That must be it. Thank you very much, I've looked everywhere for that name origin. I found a Kindle edition so I'll check it out. --Judy (jlanoux) 14:10, 10 March 2011 (EST)

Original vs. Derivative Source Pages [17 March 2011]

I'd be interested in hearing opinions about a possible scenario for WeRelate's source pages. You folks may have already discussed this, sorry if I'm late in the discussion. I'm particulary interested in how this meshes with Board for Certification of Genealogists (BCG) concepts.

Possible scenarios. Should all original and derivative versions of a single source be combined into one source page? How would this apply to United States deeds? Let's say the original deed for a 200-year-old house is still kept at the house. A registered copy is in the deed books at the local courthouse. The deed books in the courthouse have been abstracted and published as books by two different individuals. Then these books were reprinted by a distinct publisher. Some of the deeds are abstracted in a local history. Others are listed in a genealogical society's periodical. How do we interrelate all these derivative sources? They are actually all based on one single original source. Should the page about the original source refer people to all the derivatives that are currently listed as separate source pages? Or should all the derivative pages be merged into a single original source page? Murphynw 11:54, 11 March 2011 (EST)

This was discussed in conjunction with the source redesign about 18 months ago. I think there are many ideas in the incubator, Including your next suggestion about teaming up with Family Search. Both good ideas. --Judy (jlanoux) 13:23, 11 March 2011 (EST)

This is my understanding of how it should be... The derived sources that are not exact duplicates should be separate from the original (eg. Source:England and Wales. Civil Registration Marriage Index vs. Source:England and Wales. Civil Registration Certificates). This includes indexes, transcriptions, abstracts, etc. However when the sources are the same (eg. reprints by different publishers) there should be one source page that mentions the first source was reprinted at a later date by the second publisher.

I do think it would be a good idea to link the original source to the derivatives (both ways). Perhaps the developer of this site could add additional entry boxes to the source pages to help facilitate this. Otherwise it can just be added to the general text of the page. Doing this might make it easier for people looking for sources. Moverton 16:29, 11 March 2011 (EST)

I'm open to this. Currently we have a "references/cites" field that isn't used much. You can enter [[Source:...]] in that field to get a link to another source. Could we use that field for citing the original source, and use the text area for adding links to derivatives? Or would we want a separate (multi-line) field for derivatives?--Dallan 17:56, 11 March 2011 (EST)

I created a trial page about Washington County, Tennessee marriage records: Source:Washington,_Tennessee,_United_States._Washington_County,_Tennessee_Marriage_Books,_Licenses,_and_Bonds. You'll see, it's rather absurd how many times these things have been published! I created a separate "original source page" for the source that describes the physical repository, as there are two versions of FHL microfilm. Then I added all the published abstract pages currently found in WeRelate. I'd love to hear your opinions. Murphynw 13:59, 14 March 2011 (EDT)

WOW - I just nominated this to be a featured page. This looks like a great way link to derivative/related sources. The next question is, how should the derivative sources link back to this page? Should we put the title of this page in the "References/Cites" field of the derivative source page, in which case this source will be included in the citation text of the derivative source? Or should we simply add a link to this source page under a "See also" section of the text of the derivative source?--Dallan 20:52, 17 March 2011 (EDT)

I added the cross-references in the derivatives back to the original source. I went ahead and placed them in the Cites/References box. Glad you liked the page Dallan. We've worked through some of these similar issues in FamilySearch Wiki. Murphynw 17:34, 18 March 2011 (EDT)

Family History Library Catalog version 2.0 [11 March 2011]

I should disclose that I'm a FamilySearch employee. As I understand it, the source pages on WeRelate are basically a Family History Library Catalog (FHLC) version 2.0 -- is that correct? Has WeRelate attempted to approach FamilySearch to integrate the FHLC with corresponding WeRelate source pages? For example, what if when you pull up a book on FHLC, there is a link that says "Add Comments" or something to that effect that links directly to the parallel WeRelate source page on that book... It would make for great advertisement for WeRelate's source pages. Murphynw 12:54, 11 March 2011 (EST)

I will just point out that it isn't a one-to-one relationship. Some sources like this one may have links to two or more entries in the FHLC. Moverton 16:31, 11 March 2011 (EST)

Great idea! We're having some discussions now in fact. Please bring up your idea to Diane Loosle at FamilySearch.--Dallan 17:56, 11 March 2011 (EST)

I'll do that. I think the two sites would work great together. Murphynw 13:59, 14 March 2011 (EDT)

Was William T. Phillips Butch Cassidy? [20 March 2011]

I have started my first genealogy contest. You can use your username at WeRelate to win points. Everything will take place on a shared Google Document. Read about the contest here and if you want to play, post your sources at the shared Google Document page. If you have any comments or suggestions for my game please put them in my WeRelate user talk. Thanks for playing!--cthrnvl 15:22, 20 March 2011 (EDT)

Question about name capitalization [23 March 2011]

I've been going through the name capitalization code and realized that we have three different approaches for capitalizing names in wiki page titles:

• Gedcom uploader: capitalize every name piece; e.g., "Van der waal" becomes "Van Der Waal" in the page title.
• Add Person page online: go with what the user has entered unless the name is all caps or lowercase, in which case capitalize every name piece; e.g., "Van der waal" stays "Van der waal", "van der waal" and "VAN DER WAAL" both become "Van Der Waal" in the page title.
• Add Source page online with an author as part of the title: capitalize most name pieces, except if the user didn't capitalize words like der, de, la, ter, etc., then keep those words lowercased; e.g., "Van der waal" becomes "Van der Waal", "Van Der waal" becomes "Van Der Waal", and "van der waal" and "VAN DER WAAL" both become "Van der Waal" in the page title.

I'm thinking that we should standardize on one approach for all three functions (gedcom upload, add person, add source) going forward. Would everyone be happy with the last approach?--Dallan 16:12, 21 March 2011 (EDT)

If one user enters Jan Van Der Waal (1) and another Jan van der Waal (1) - we will still have the issue of two same-titled pages being created that only differ by the capitalization. That can be a bit confusing. I do agree that we should have one approach for all three functions! --Jennifer (JBS66) 16:24, 21 March 2011 (EDT)

For the Dutch names it is unusual to capitalize de, der, te, ter, van ... and the French le, la, de, du ... are also never capitalized.--Klaas (Ekjansen) 16:31, 21 March 2011 (EDT)

I agree, though a quick google search on "de la cruz" shows pages with all sorts of capitalizations. I don't mind forcing a standard capitalization on everyone since it's just the page title and not the name field that's getting standardized. But if we do this, we'll have to accept that for some pages the standard capitalization will be wrong; e.g., we'll have someone who always wrote their name "De La Cruz", not "de la Cruz" as we standardized it in the page title. And I don't plan to re-title the existing pages that have been created so far (see below).--Dallan 16:47, 21 March 2011 (EDT)

The last approach would still allow "Jan Van der Waal (1)" and "Jan Van Der Waal (1)", if one user entered "der" and the other "Der". Is that ok? Or should we say that words like der, de, la, ter, etc., are never capitalized, so a user-entered name of "Edward De Bono" would get a page title of "Edward de Bono", and "Melissa De La Cruz" would get a page title of "Melissa de la Cruz"?

Something to keep in mind is that this is going forward only. Most existing pages have every name-piece capitalized in the title, so if we already have an "Edward De Bono (1)" page, this approach would create an "Edward de Bono (1)" page. Hopefully that's ok; automatically changing the titles of existing pages would be a fair amount of effort.--Dallan 16:40, 21 March 2011 (EDT)

As far as there is no strict rule to capitalize or not, I think the last approach is ok. Just leave it up to the users to capitalize or not.--Klaas (Ekjansen) 16:53, 21 March 2011 (EDT)

Actually, the whole business is even more complicated than that. French, German, Dutch, Spanish, Portuguese, and Italian all follow slightly different rules not only regarding capitalization of articles and prepositions in names, but also in which parts are considered part of the surname when it comes to alphabetization -- which, fortunately, is less of an issue on WR, with page titles following a forename+surname style. (In French, e.g., articles and propositions are never capped in "straightforward" style, but the name "Martin de la Tour" shows up as "La Tour, Martin de" in the phone book.) My own problem is with the tendency to run all the parts together: "Pierre Le Blanc" becomes "Pierre LeBlanc" or "Leblanc." Part of that is just natural variance over time, but part of it is conformist pressure to make names sort "properly" for computer use.

And that's just for French. Since there's a whole separate bundle of issues for the other languages I mentioned (and god knows what similar problems might exist in languages I'm not familiar with), I think the only reasonable recourse is to throw up our hands and make an entirely arbitrary rule for names in all languages, . . . knowing that it's not going to be quite correct for any of them. --Mike^Talk 09:35, 23 March 2011 (EDT)

Quick update on new functionality [12 April 2011]

• You can now merge one of your trees into another one, combining all of the pages into a single tree, by selecting "Trees" from the MyRelate menu, then "Rename", and entering the name of the tree you wish to merge into.
• The "?" tips (mostly found on edit pages) must be clicked on to view the tip; the tips don't show up anymore if you just move the mouse over them.
• Family pages no longer display a "Find/add another husband/wife" link when editing the page. This link was confusing because if one of the spouses re-married, you should create a separate family page, not add a second spouse to the existing family page.
• If a Source page has multiple surnames-covered, they are listed alphabetically in a comma-separated list.

--Dallan 16:21, 21 March 2011 (EDT)

Quick question on the ? tips - when hovering over - some have   in the text - can that be replaced with a space? --Jennifer (JBS66) 16:29, 21 March 2011 (EDT)

Yes. Do a search in the MediaWiki namespace for keywords that appear in the help text. You're looking for a page whose title ends in "Tip". Admin's can edit these pages and correct them. If you don't find the problem, please let me know which tip is causing it and I'll look into it.--Dallan 16:53, 21 March 2011 (EDT)

I found and fixed 11 of them (they were not in the tip box text - but in pages like MediaWiki:ChildOfFamily instead). The two I can't find are used on the User pages <UserResearching> and <UserText> --Jennifer (JBS66) 18:36, 21 March 2011 (EDT)

Thanks! I created pages for MediaWiki:UserResearching and MediaWiki:UserText (they were missing).--Dallan 22:47, 22 March 2011 (EDT)

More new functionality:

• When you edit a person (or family) page, the links to the families (or people) that you add must now point to existing pages. Furthermore, existing links can't be changed. They can be removed and new ones added in their place, but you can't edit a link. These two changes will hopefully help people to understand that you're supposed to enter a link to a page here, not just the name of a relative, and it will make it harder for newcomers to inadvertently ruin existing links by editing them incorrectly.
• I tried to streamline search results by removing the (id's) after titles and displaying the person's full-name in place of their page title.
• You can now show up to 200 results per page on a search. The default is 20.
• You can now sort search results by title even if you're not doing an exact search. If you do choose to sort by title, you have the option of filtering by the first letter of the page title so you can see all results that start with the letter A for example.

Please let me know if you encounter any problems with the new functionality.--Dallan 22:47, 22 March 2011 (EDT)

Ah! That explains the puzzling problem I was having last night, trying to edit/update the name of the Family Page for someone's parents. I had found the mother's maiden name and was going to edit "John Doe and Mary Unknown (1)" to "John Doe and Mary Roe (1)", but it wouldn't let me do that. But simply retyping the entire title of the renamed Family Page did work. I have no problem with that -- now that I know what's going on! --Mike^Talk 09:45, 23 March 2011 (EDT)

I love the new tricks. I was able to consolidate a lot of trees and now the list fits on one line again. And it is much easier to find things in Search. I'm able to check for duplicate people quickly now that one can see more than 11 results. --Judy (jlanoux) 11:52, 23 March 2011 (EDT)

I'm having problems with some new "features". I often create person or family pages by entering the name on an adjacent page, saving that page, then clicking on the red link to create. The site now refuses to check in the page, which isn't at all helpful. I can fight past the new feature by creating the page name in the browser and then doing the raw create in that way, but that's hugely annoying. The "add" page wizard for families would create hopeless page names in the medieval space - leading to a rename that I shouldn't be forced to do and a serious slow-down in my productivity.--Jrm03063 13:39, 23 March 2011 (EDT)

I've added the ability for admins to create links to non-existent pages, since I assume they know what they're doing :-)--Dallan 14:58, 12 April 2011 (EDT)

Elizabeth Taylor [24 March 2011]

I started a family tree for Elizabeth Taylor. No husbands added yet ;-) Please add to the pages. There's a lot on Wikipedia, but I hesitate to use it as a source. And if someone could add the proper category for her, I'd appreciate it. -- Amy (Ajcrow) 20:01, 23 March 2011 (EDT)

I will have a look for her Swiss ancestry. Her GGF Samuel Warmbrodt (1838-1921) came from Siselen, Canton Berne, Switzerland.--Klaas (Ekjansen) 15:15, 24 March 2011 (EDT)

Repository:WorldCat [28 March 2011]

The Worldcat page function just fine but there are extra letters on all the items at the top of the page except search and on one of the items on the left. If I knew how to correct this I would. Can anyone help? ThanksSandralpond 21:06, 26 March 2011 (EDT)

I don't see anything unusual. I assume you saw stuff like &gt; and &lt; etc. wrapped around menu items at the top. If so, this is a known intermittent problem that seems to happen when the server is busy, or something like that. It can be ignored. --Jrich 23:15, 26 March 2011 (EDT)

Thanks so much. Had not seen it before.Sandralpond 09:02, 28 March 2011 (EDT)

Baptism / burial as proxy for birth / death in search results [11 April 2011]

Hello - I'm new to WeRelate, and have just started putting in a few pages one at a time. I have a number of people I'd like to add, where I know baptism and burial dates but not birth or death dates. The individual person pages allow you to record baptism and burial dates, and the "Parents and Siblings" and "Spouse and Children" boxes will use the years of baptism and burials as a proxy for the birth / death. So far so good. Trouble is, when you search for a person, these proxies don't appear. Therefore, if you search (for example) for my Daniel Nicholls baptised 1782 and buried 1830, the search results come up with his name (and his parents / spouse) but no dates at all - thus increasing the likelihood of duplicate pages being created. I'm loath to start doubling up all the dates by putting "b. bef 24 Feb 1782" as a birth date then "ch. 24 Feb 1782" as a baptism. Also, if you do do this (I've tried) the "Spouse and Children" and "Parents and Siblings" boxes will change his dates to "bef 1782 - bef 1830", which whilst correct(ish) lacks the simplicity of "1782-1830", which is all I want in those boxes. Any thoughts?--RichardK 10:12, 5 April 2011 (EDT)

My approach is to enter the baptism and burial dates with source. The use abt1782 for the birth date. I generally read those as being "within a few years".--Judy (jlanoux) 11:30, 5 April 2011 (EDT)

Richard, your approach is correct. You're right that the baptism/burial at best should show up in search results - I think it used to, and search is on a continuing improvement program. But I'm reasonably sure that the data is searched for if you use the date in the keyword or birth field because I can get correct results to show up at the top that way, so that should help with the duplicates problem. Estimating dates in the birth or death fields when you know baptism or burial is discouraged.--Amelia 12:29, 5 April 2011 (EDT)

Repeating two old requests that pertain to the above comment:

The use of the baptism as a proxy for birth only seems to work if you add it as the "Christening", and not if you add it as a fact of type "Baptism". Since GEDCOMs, and perhaps some people through habit, seem to put baptisms in "Baptism", it might be nice if WeRelate treated the two equivalently.

The same request would be nice for "Marriage Bann", so if you have a published or intention date, it will be a proxy for the marriage date instead of having to enter Aft. 24 Jan 1763/64 in the marriage field, and also 24 Jan 1763/64 in a Marriage Bann. When only the Marriage Bann is known, it seems pointless to have to enter a marriage date, since it is obvious from the presence of the intention that a marriage occurred within a year later, and this particular marriage date offers absolutely no new information beyond what is already present in the record of the intention. But if you don't, no date shows up in the search results. --Jrich 12:34, 5 April 2011 (EDT)

Thanks - the link from Amelia was particularly helpful.--RichardK 07:11, 6 April 2011 (EDT)

I'm revising search right now, so I'll

• make Baptism searchable as a "birth-like" event along with birth and christening,
• make Marriage Banns searchable as a "marriage-like" event,
• (burial is already searchable as a "death-like" event),
• display christening/baptism in search results when birth is empty
• display marriage banns in search results when marriage is empty
• display burial in search results when death is empty

You should see these changes starting tomorrow for newly-indexed pages, and around the end of the month for all pages.

Are there any other types of events that people want searchable as birth, marriage, or death events?--Dallan 14:58, 12 April 2011 (EDT)

problem with adding sources on edit page [11 April 2011]

Is anyone else having problems with the source selection on the edit page? After typing in a partial title that I have used many times such as "Arnold, James N." the wheel spins and is still spinning 15 minutes later. Even if I type in the full title and then "save" the source hasn't connected to the proper WeRelate Source Page and shows up in red on the person or family page. I get the same result using 3 different browsers. --Susan Irish 02:28, 9 April 2011 (EDT)

I am having a similar problem. For me, the auto-fill doesn't work (wheel spinning and not bringing up titles). However, if I type in the correct title and save, the link to the source does work. --Jennifer (JBS66) 07:56, 9 April 2011 (EDT)

I didn't have any problems with it yesterday, but I am this morning. I'm seeing the same behavior as Jennifer -- the auto-fill won't bring up titles, but if I type in the correct title, it does link to the source. -- Amy (Ajcrow) 08:08, 9 April 2011 (EDT)

Dallan fixed a small bug, so source auto-fill is working again. --Jennifer (JBS66) 19:55, 11 April 2011 (EDT)

matching sources - a small change could help [12 April 2011]

I just reviewed my pending GEDCOM and tried to match places and sources. A small change here could help a whole lot!! When I am trying to match places I click to get to the find/add window. That window requires that I type in the place or source, then click find/add which brings up not only the search results but on the left side are my recent edits. If those recent edits would show on that first search window it would save me having to retype the same info over and over when I want to use the same place or source.

Since it took me this long to review this very small GEDCOM, I'm thinking I never will get around to uploading the whole data base - ugh! --Janiejac 18:58, 11 April 2011 (EDT)

I second this request. It's VERY startling to come to a blank search page. It's not expected. It also encourages error since it requires retyping. Jillaine 20:52, 11 April 2011 (EDT)

The problem is if you haven't edited the place or source page, it won't show up in the list, even if you just selected it a few seconds ago. Is that acceptable, or would people prefer having previously-selected places/sources show up on the first find/add search window?--Dallan 14:58, 12 April 2011 (EDT)

No, that's really not acceptable. If I've already typed it in, searched, and selected a source, I would like the select button to show up on the first find/add window so that I don't have to keep retyping the same thing over and over again. If I use the same source a dozen times, retyping it again starts to get old by the third time and by the fifth or sixth time, I'm ready to call it really bad names! --Janiejac 16:42, 12 April 2011 (EDT)

That's what I expected you'd say. So we don't really want places/sources that you've edited recently to show up, but places/sources you've selected recently. That's do-able. Let me see how complicated it would be and how much time it would take to implement.--Dallan 17:31, 12 April 2011 (EDT)

I hope it's easy to fix because it surely would help. I'm amazed that no one else has mentioned this! --Janiejac 18:37, 12 April 2011 (EDT)

A question about sorting [11 April 2011]

I'm planning to re-do how pages are sorted by title in search results later this month. Currently,

• Person pages are sorted as Person:givenname surname,
• All other pages (Family, Source, etc.) are sorted according to their title.

This has the effect that Family pages appear grouped together (they all start with Family), Person pages appear grouped together (they all start with Person), articles appear throughout, since they could start with anything A-Z, etc.

I'm thinking about changing this. I can think of two options.

Option "A":

• Person pages are sorted as Givenname surname
• All other pages are sorted according to their title without the namespace.

This would have the effect that people, families, sources, and articles would all be interspersed, so that all pages (people, families, sources, articles) starting with the letter "A" would appear next to each other.

Option "B" is like option "A" except that Person pages would sort according to surname givenname and Family pages would sort according to husband surname givenname wife surname givenname, so that people with the same surname would appear next to each other.

I'd eventually like to use this same sort order for the automatically-generated surname-in-place categories as well. Any thoughts?--Dallan 14:58, 12 April 2011 (EDT)

New Search Functionality [23 April 2011]

I've added new search functionality over the last few days. Here's what's new.

• Source searching should be better, with a couple of checkboxes to allow you to specify whether you want to include sources for lower-level or higher-level places.
• Keywords searching includes now words with the same "root word" in your search, so keyword searches for "directory" includes pages containing "directories".
• The exact, exact+close, and exact+close+partial functionality is new. In the past the default was exact+close+partial, and if you checked the "Exact"

checkbox you got exact-only results. Now the default is "Exact+close", which means that all fields you enter must match exactly, or in the case of names, match similar names.

• You can use ?'s and *'s wildcards when searching names. Previously you could put a * at the end of the name, but that was about it. You can now put ?'s (matching exactly 1 letter) and *'s (matching 0 or more letters) anywhere in the name, so long as you also have 3 or more non-wildcard letters somewhere in the name. So ?mit* works, but Sm* does not.
• Redirected Place pages no longer clutter up Place search results.

What didn't make it in -- these changes should go in around the end of the month:

• The "Unsourced" flag mentioned in an earlier discussion -- too many pages ended up being unsourced under the requirement that a source or note be attached to every event. I'm going to change the definition of "Unsourced" to just include pages without any sources, images, notes, or text to help people find the completely unsourced pages.
• The "exclude talk pages" flag - there was a bug so it will wait until the end of the month.
• Including Baptism events when searching on Birth, and Marriage Banns when searching on Marriage.
• Displaying Christening or Baptism when birth is empty; displaying Burial when death is empty; displaying Marriage Banns for Family pages when marriage is empty.
• Displaying counts in the left-hand sidebar for the number of matching search results by country and state. This will allow people to search on "Smith" for example, find out how many Smith's are in each country, and click on a country to find out how many Smith's are in each state of that country.

--Dallan 14:58, 12 April 2011 (EDT)

Are wildcards are no longer allowed in the keywords field? I thought this used to work and now I'm getting an error message. --Jennifer (JBS66) 08:43, 17 April 2011 (EDT)

Yes, wildcards are no longer allowed in keywords unfortunately. Here's why:

It used to be the case that if you searched for a keyword like "directory", pages with the word "directories" would not be returned. I've relaxed this by wp:Stemming the keywords, so that "directories" and "directory" are both automatically changed to "director" (or maybe just "direct"). This means that searches for "directory" now find pages with the word "directories". But it also means that a wildcard search for "direct*y" wouldn't return any pages, because the word "directory" is no longer indexed as-is; it's now indexed as "director". Because of this point of confusion, and because I wasn't sure if anyone was really using wildcards in keyword searching anyway, I decided to remove the capability.

FWIW, I added the ability to do wildcard searches on page titles. Titles are not stemmed; only keywords are being stemmed.

At this point we have three options: (1) leave things the way they are, (2) re-instate wildcard searching on keywords, with the caveat that they may not always work the way you expect, or (3) go back to the old way of indexing, without stemming keywords.

Thoughts?--Dallan 15:15, 18 April 2011 (EDT)

When I search, I tend to put everything in the keyword field using wildcards as necessary. One thing that is a bit frustrating is that when I search for a source from a certain location, say Ferwerderadeel, if I put that in the keyword field I get results. If I put that into the Place field, I don't. It seems I need to enter the entire place hierarchy for the search to return anything. Also, I often want to search generally for an item - with the word appearing anywhere on the page. It's for these reasons that I tend to use only the keyword field. --Jennifer (JBS66) 14:35, 19 April 2011 (EDT)

Currently, the place field assumes that you'll end the place with a country or US State. I'll change it later this week so that if you don't, it will search for the place anywhere in the world.

Assuming that I make this change, are wildcards in the keywords field more or less important than the ability to match words like directories when you enter words like directory? We have to choose between one or the other I think.--Dallan 16:44, 19 April 2011 (EDT)

I suspect the new functionality is too new for people to really have learned to appreciate. So I would guess there will be a bias towards wildcards being a tool that they know how to use effectively. That said, I would guess that searching is mostly for Proper Nouns and so wildcards may be more effective? I don't really use wildcards, but I use keywords either because I am doing a lazy search using the search box, or because I am inputting a town and I don't know exactly where on the page that town may occur (birth or death location), or a name because I think that person might be associated with my target. --Jrich 19:49, 19 April 2011 (EDT)

Stemming is pretty popular for keyword search on most websites, so I figured it would be a good idea to add it here. But perhaps as you say, for a website that people primarily search for proper nouns it's not such a good idea. If anyone has an opinion, please chime in now. At this point I'm leaning toward removing stemming and putting wildcard keyword search back in.--Dallan 22:17, 21 April 2011 (EDT)

I think I probably agree that wildcards are ultimately more useful, but, at least for clarity, this means that if I search for Springfield vital records and the source is called "vital record of Springfield" (no plural), it won't get returned if we don't use stemming? But I could use record* and it would work?--Amelia 00:51, 22 April 2011 (EDT)

That's correct.--Dallan 19:42, 22 April 2011 (EDT)

It appears that WP uses the MWSearch Lucene-based search extension. Both stemming and wildcards seem to be accepted. Is that something that might work here? --Jennifer (JBS66) 06:49, 22 April 2011 (EDT)

We use lucene here as well. Try doing a "wildcard" search for "direc*y" on Wikipedia. Notice that it doesn't behave at all like you'd expect -- you only get 7 results. Now do a search for "direc*". That behaves like you'd expect. We could enable "prefix" queries -- where there's just a single * at the end of the word, but not embedded *'s or ?'s. But if we enabled wildcard queries (with embedded *'s or ?'s, they'd break in unexpected ways just like they do on Wikipedia. I'm ok with saying you can do prefix queries but not wildcard queries on keywords. But I don't want to go the wikipedia route and pretend that we support wildcards on keywords when they don't work correctly.

Another thing to consider is that stemming doesn't work well on proper nouns and non-English words, because it just looks for endings like ed, ies, ing, etc. and removes them. So a name like Jared becomes Jar, which means that a prefix query of Jare* would fail to find it. I hadn't expected people to use keyword search to search for proper nouns. I would say that if we want to support wildcard or even prefix searching for proper nouns in keywords, then we're probably better off not stemming.--Dallan 19:36, 22 April 2011 (EDT)

Another option, which may turn out to be the best for us, is to create a list of words that are considered identical for search. So record and records would be considered identical in titles and keywords. It would take some effort to come up with a good set of words like this, but then we wouldn't have to stem to get "identical" words like records to match searches for record, and we could also have wildcard search.--Dallan 20:06, 22 April 2011 (EDT)

This is an interesting idea! My preference would be for wildcard as opposed to prefix-only queries. --Jennifer (JBS66) 21:09, 23 April 2011 (EDT)

Indexing Synonyms [27 April 2011]

If you're interested in keyword search at WeRelate, please read on. The next time I re-index the pages at WeRelate, in 3-4 weeks, I plan to use a set of words as "synonyms", so that when you search a page title or keywords for one word, pages with synonyms will also be returned. For example, if "directory" and "directories" are synonyms, then keyword or title searches for "directory" will also return pages containing the word "directories", and vice-versa. We'll use this in place of the current "stemming" approach described above.

I've created a list of indexing synonyms as a starting point. In addition to pairs of words like directory and directories, it also contains some foreign-language equivalents like catholic and katolicki, so searches for catholic would also return pages containing katolicki. I'm not sure whether we really want to include foreign-language equivalents. It also includes a few common misspellings, which I'm pretty sure we do want to include.

I'd appreciate any feedback and improvements to the indexing synonyms that anyone to give over the next several weeks.

I'll re-enable wildcards for keyword search early next week.--Dallan 23:49, 23 April 2011 (EDT)

Have you considered adding proper names to the list? Also, rather than adding every "single,plural" combination to the list could you just incorporate the rules of the language(s) instead? Moverton 01:24, 25 April 2011 (EDT)

We have other ways of identifying similarly-spelled names. That's what the "related names" on the given-name and surname pages are used for.

Regarding using the rules of the language, yes that would be ideal, but it's tricky. The hardest problem is not removing word endings from proper nouns: Someone searching for Johns may not want to match pages containing the word John for example. And if Johns were turned into John by the language rules, then wildcard searches for Joh?s would come up empty. But even for non-proper nouns the rules are tricky. Not all words that end in s are plural. You also have to worry about replacing ending ies with y, but not for words like dies or ties. Sometimes you should remove an ending ing, but not for words like sing or thing. Non-English languages have their own rules, so you'd need to figure out which language the text was written in to determine which set of rules to use. Also, using language rules would not allow us to mark foreign-language words or common misspellings as synonyms.

We're currently using language rules (stemming) in keyword search, but the issues it causes for searching proper-nouns are causing me to think that a customized list of synonyms for words that are common in genealogical research would be better.--Dallan 09:40, 25 April 2011 (EDT)

I added a few additions on the Indexing synonyms talk page. I like the idea of including misspellings, but I'm not so sure about adding foreign-language equivalents. --Jennifer (JBS66) 18:42, 26 April 2011 (EDT)

I noticed that currently, with stemming, if I type in "sortable" & Exact Match, I get results for the word "sort" as well. I don't really want 1800+ matches for sort, and because I chose Exact Match, I'd expect only the pages with sortable in them. So, when we use the Indexing Synonyms, are they going to be applied only to Exact & Close Matches and Exact, Close, and Partial? --Jennifer (JBS66) 07:40, 27 April 2011 (EDT)

Revolutionary War veteran categories [26 April 2011]

Amelia and I have been trying to come up with a category structure for American Revolutionary War veterans. The problem is that there aren't good, standardized names for many of the military units. (For the Civil War veterans, we've been putting the unit on the Person page, with the unit category then going under the state; see the American Civil War veterans category Talk page.) Having the Person pages link to the state category won't work long-term, as the categories would be far too large to allow for meaningful browsing. So there needs to be a level underneath the state category. But what?

Two possible solutions:

• Go with the unit names and try to standardize them as we go. (So if we see one category for Capt. J. Smith's Company and another for Capt. John Smith's Company, we would merge them.) Because many people may not know the exact unit in which their ancestor served, we would probably need to create a category in each state for "Company unknown."
• Go by the veteran's last initial (e.g., New Jersey Revolutionary War veterans - M would be the category you'd put on Peter Miller's page). The problem with is that you'd lose the ability to easily find others in his unit, though you gain the ability to find all the Millers in the category, for example. (Though one could argue you could do that through Search.)

Does anyone have any thoughts about these possible solutions or have any ideas for another way to approach this? Thanks. -- Amy (Ajcrow) 12:04, 14 April 2011 (EDT)

Not sure if this is a better idea or not, but what about having just the state-level category and use a template with links for each letter A-Z at the top of the category page, where the links jumps you to pages whose titles started with that letter? (You'd have to put the person's surname as the sort order to make this work though, as in [[Category:category name|surname, givenname]].)--Dallan 18:55, 14 April 2011 (EDT)

How big can a category page be? Does there come a point where it would become Page 1, Page 2, etc? As Amelia and I were discussing, there were over 80,000 pension applications, and just a fraction of the veterans applied for one. So lets say there's 130K vets (probably more than that) -- with 13 colonies, that's 10K per "state" category. (Yes, I'm thinking long-term here, but I don't think we want to have to re-do the whole thing later, do we?) -- Amy (Ajcrow) 22:14, 14 April 2011 (EDT)

Category:Smith_surname has over 25,000 people. And the template Dallan mentions.--Amelia 00:10, 15 April 2011 (EDT)

The Smith page is a good example of a TOC template's use, but I believe Template:CategoryTOC would need to be used instead (Category:Surnames uses this one). The template on the Smith page takes into account the namespace prefixes, so it won't work correctly with the sort keys you'll be using. --Jennifer (JBS66) 07:08, 15 April 2011 (EDT)

Since everything in this category would be Person pages, Template:CategoryTOC would probably work better. I'm not very good at reading template-ese. Would this template recognize the use of sort keys, such as [[Category:category name|Surname, firstname]]? If it's just going to grab the first letter after the namespace, then I don't think it's going to work on these pages. -- Amy (Ajcrow) 07:20, 15 April 2011 (EDT)

The template jumps you to a heading letter, not to Person:G, but to the section G on the category page. Here is an example of the template on a page whose contents have sort keys. --Jennifer (JBS66) 07:35, 15 April 2011 (EDT)

Thanks for that example. I see how it's working now. -- Amy (Ajcrow) 07:57, 15 April 2011 (EDT)

Amy, I'm way behind in this discussion, and much of the following I'm sure you know, but I wanted to make a couple of observations regarding the nature of service by unit in the Rev War. I have maybe a dozen direct and collateral ancestors with Rev War service (some could prove it for pensions, some couldn't), and I've researched maybe 30-40 other soldiers in some depth for various reasons.

For every soldier who served in the Continental Army -- which was the only thing resembling a "national" military organization -- there were maybe 10 or 12 soldiers serving in militia units, organized by state (or colony, really). Of the militia units, by my own experience, I would guess half had official numerical designations, and half were designated only by the commanding officer's name. The latter was esp true in frontier areas, like Kentucky, where the militia was most often called up for short periods to fight Indians or to guard a travel route against a specific enemy movement or campaign. I.e., those guys mostly stayed relatively close to home.

And it's very common to find a soldier being called up 3 or 4 or more times over the five years of the Rev War, and almost always serving in a different regiment or even a different company each time. Units were often formed ad hoc for the immediate situation and need, and might serve only ten days or so. And it's not that uncommon for a soldier to relocate (even to another state) between periods of active service, which confuses the issue even more.

This was also one of the main reasons so many veterans later had trouble proving their service in applying for a pension: They couldn't remember the names of all the captains they had served under, at only a few days each, and they may not even have known the name of the colonel that captain was reporting to up the ladder.

Finally (and this is the case with maybe half my own ancestors), soldiers on the frontier who served in roles such as "Indian Scouts & Spies" (the usual designation in the records and reports) weren't actually part of any unit. They went off, did their thing, and reported back to some designated officer in charge of intelligence work. No muster rolls for them, either -- only what survived in accumulated reports.

Because of all this, researchers generally refer to Rev War soldiers as "Continental Army" (followed by the full regimental & company designation) or as "[name of state] Militia" (followed by whatever other affiliation they can identify, depending on what musters have survived, what the pensions app says, etc). So I wouldn't worry too much, frankly, about creating subdivisions in the Rev War categories. Something like "[Soldier's Name], [State of Service] Continental Line, [Regiment]" would be adequate for those guys. And "[Soldier's name], [State of Service] Militia" for the rest. Details of service, dates, etc, go on the Person page, of course, and they should be sufficient to identify a soldier or to distinguish between two men of the same name. I don't think you can reasonably carry it much farther than that. --Mike^Talk 14:11, 26 April 2011 (EDT)

Sort results by Surname [16 April 2011]

Would it be possible to sort results by Surname? That could be very handy, for example if you've done a wildcard search so you could bypass the ones that you know you aren't interested in. -- Amy (Ajcrow) 12:31, 14 April 2011 (EDT)

Yes it would. That's the "Option B" that I described in "A Question about Sorting". Currently, when you sort search results by title, people are sorted by given name. I could change that so that when you sort search results by title, people were sorted by surname instead. (Similarly, families would sort by husband's surname.) Would this be more useful?--Dallan 18:38, 14 April 2011 (EDT)

Sorry, Dallan -- I completely missed the "Question About Sorting" above." (Long couple of days this week!) I would love to have the ability to sort by surname, firstname (I'd even go so far as to say I'd prefer that to be the default.) -- Amy (Ajcrow) 19:17, 14 April 2011 (EDT)

Just to be clear, if we go down this route then we'd have three sort options: relevancy, title (which would sort people by surname then givenname), and last-modified date. We wouldn't have an option to sort people by givenname then surname; it would be superseded by the option to sort by surname then givenname. I think we'd still want relevancy to be the default sort for an exact+close search, but I could make title the default sort for an exact search.--Dallan 19:55, 14 April 2011 (EDT)

Sounds good to me. -- Amy (Ajcrow) 22:15, 14 April 2011 (EDT)

I'd like to be able to sort by surname, but can we call it something other than "sort by title" then? Because it's not - it's sorting by name. Further blurring the difference between page title and name is only going to confuse people. I also think that relevancy should always be the default sort, even for (especially for) exact. And if it's a choice, I'd rather keep the ability to sort sources by title than get the surname search.--Amelia 00:15, 15 April 2011 (EDT)

I just realized that sorting by relevancy in exact search will bring the most-linked-to results to the top, so I can see its usefulness. Once I add relevancy as a sort option for exact, I agree that relevancy should always be the default - so we have fewer things changing without you realizing it.

Maintaining sort orders is expensive, so I'd rather not have to sort people by page title and also by surname if we can help it. What if we called the sort option Page title or person surname and say that it sorts by surname for person/family pages, and by title for everything else?--Dallan 11:37, 16 April 2011 (EDT)

Encouraging google to index more pages [25 April 2011]

Google has currently indexed around 175,000 of the roughly 4.5 million pages at WeRelate. Google does not guarantee that they will index every page of a website. There are two things we can do to increase the number of WeRelate pages that are indexed by google.

The first thing is I have just created a Google sitemap. Submitting a sitemap still doesn't guarantee that all pages listed in the sitemap will be indexed, but it allows a website administrator to tell google which pages are highest priority to index.

In the sitemap I've told google that the highest-priority pages to index are person pages, articles, user pages, and portals. Medium-priority are family pages and transcripts. (Transcript is a new namespace for storing document transcriptions that is still being worked on.) Low-priority are sources, repositories, and surname pages. That results in 3.6 million pages in the sitemap. Other pages (talk pages, mysources, images, category pages, help pages, etc.) are not included in the sitemap.

Also, I've given pages with more content higher priority than pages with less content. A low-priority page with lots of content becomes medium-priority, a medium-priority page with lots of content becomes high-priority, and a high-priority page with lots of content gets the highest priority. So if you want to encourage google to index your pages, add content!

I'm open to changing this priority scheme. Maybe family pages could be given lower priority or removed for example.

Finally, pages that contain copies of wikipedia content are excluded from the index, because google has announced that copying information from another website reduces a site's search result ranking (which makes sense), and our goal is to get as many of our high-priority pages indexed as possible.

The second thing we can do to encourage google to index more pages on this site is to link to it. I believe that google gives more priority to sites with more incoming links. So if you have another website or participate in other online communities, where appropriate and relevant, feel free to link to WeRelate.--Dallan 11:02, 16 April 2011 (EDT)

Re Wikipedia exclusion: Do you exclude only the pages with templates to copy Wikipedia content or all pages which have Wikipedia as a source?

Re User pages: Interesting that you give them high priority. I was about to write and ask that user pages and admin pages be hidden from Google when you posted this. Many of use user pages for our personal notes that aren't meant to go "primetime" in the regular space or aren't ready yet. --Judy (jlanoux) 18:31, 16 April 2011 (EDT)

Further WP question: are all pages with a WP template excluded, or just ones where that's the only thing? There are plenty of pages where it's one minor thing among a lot of other content on the page.

Ditto that user pages don't really need to be included, let alone as high priority. I'd say the same for portals, which basically have no content except internal links (unless that in itself is helpful to having other pages come up).

Also, I don't think family pages should be excluded unless the spouse name prompts the person page to come up - Google's so crowded than an easy way to limit searches is to include the spouse's name in the search, so it would be nice if our pages still came up when people do that.--Amelia 18:48, 16 April 2011 (EDT)

I agree with Amelia's points. The best way to get a focused result set on an Internet search is to have juxtapose multiple items in your query, such as husband and wife, or name and birth year (especially for dates in 1700's), etc., depending on what you know or suspect. So normally I would push the Family page, but I think this kind of matching would still happen on the Person page thanks to the infoboxes with the marriages and children. Consequently, my preference would probably be to see as complete coverage of the Person space as possible, even if nothing else was covered. --Jrich 09:25, 17 April 2011 (EDT)

I, too, agree with Amelia's point with one exception. I wouldn't exclude the Portal pages. They make excellent gateways into other parts of the sites. It doesn't have to be as high a priority as the Person pages, certainly, but it would be good to get more traffic drawn to those pages, IMHO. -- Amy (Ajcrow) 13:53, 18 April 2011 (EDT)

Currently any page with a wikipedia-notice template on it is excluded. I could try to determine if there was sufficient non-WP content to warrant indexing the page anyway -- something like "if the page has at least 2,000 characters of non-WP content, then index it". Does that work? If so, let me know.

I'll omit User pages.

I agree with JRich that the family infoboxes should get relatives' names to show up on the person pages, so it doesn't seem like we need to prioritize family pages.

There are only a couple dozen portal pages, so I don't think it will hurt to index them.--Dallan 16:41, 18 April 2011 (EDT)

Just a quick update: As of this morning, google says that they have indexed 348,745 pages at WeRelate, double from what it was a week ago. The new sitemap seems to be working.--Dallan 09:45, 25 April 2011 (EDT)

New sharing buttons [18 April 2011]

There are new buttons near the upper-right corner of each page for sharing that page with your relatives and friends on Facebook, Twitter, by email, etc.--Dallan 14:47, 18 April 2011 (EDT)

Very cool -- and very useful! Thanks! -- Amy (Ajcrow) 14:50, 18 April 2011 (EDT)

Very nice Dallan! Personally, I'd prefer the Twitter link in place of the 'send to Google' link though. --Jennifer (JBS66) 15:41, 18 April 2011 (EDT)

The buttons are provided by AddThis.com. They say that the buttons that show up are dependent upon the buttons you have clicked in the past, so if you tend to click on the Twitter button in the More menu, then the Twitter button will migrate to become one of the primary buttons for you. I did a very quick test and it seemed to work. Please let me know if it doesn't work for you. I agree that they should start out with Twitter as one of the primary buttons from the start though.--Dallan 16:51, 18 April 2011 (EDT)

Ah, that makes sense! Thanks for clarifying. --Jennifer (JBS66) 17:21, 18 April 2011 (EDT)

Trying out GetSatisfaction for support and feature suggestions [19 July 2011]

We're no longer considering GetSatisfaction

We have signed up with a trial account at GetSatisfaction.

GetSatisfaction makes it possible to find out if the question you have has already been asked (and answered) by someone else. Just like WeRelate, anyone can help out by answering your question.

In addition, you can use GetSatisfaction to share your ideas -- your suggestions for new features. If you find out that someone else has already asked for the feature you want, you can vote for their idea by clicking on the I like this idea button. Ideas with more votes are likely to be implemented sooner.

If people generally like it, then we'll switch over to using GetSatisfaction for tracking questions and suggestions for new features. This Watercooler page will likely remain so people can continue to discuss topics unrelated to suggestions for new features, but the WeRelate talk:Support page and the WeRelate:ToDo List would be replaced with GetSatisfaction.--Dallan 14:54, 18 April 2011 (EDT)

Regardless of the implementation, I would suggest that a link to the ToDo list be added to the Main Page, maybe as part of the left-margin link set. Apologies if the link is already on the page and it escaped my fleeting eye. --ceyockey 10:39, 17 July 2011 (EDT)

P.S. I tried out GetSatisfaction by posting this as an Idea. I like the fact that the site lets you set up an account in mid-submission without missing a beat. It would be good to know in the end whether the $228/year ($19/month) gives a satisfactory ROI. --ceyockey 10:44, 17 July 2011 (EDT)

If GetSatisfaction is set aside after the pilot, would the content be back-migrated into WeRelate so it is not lost? --ceyockey 11:02, 17 July 2011 (EDT)

Based upon the feedback, we're no longer considering GetSatisfaction. People didn't like having to create a separate account, and I didn't think it made sense to spend the money unless people really liked it. I took out some of the links, but I forgot to take out the link in this posting (sorry). Instead, I'm working on a home-grown solution: see WeRelate:Suggestions. Once I've added more functionality to that solution; e.g., finding similar suggestions, allowing suggestions to be moved around between high-priority and low-priority lists by renaming them, I'll add a link to it from the homepage. We'll try using the same functionality for WeRelate:Support as well, so that support questions that are really feature requests can be moved to the suggestions list. Furthermore, anyone will be able to use this functionality to add forums to any page at WeRelate.

Once the new suggestions functionality is in place I'll move everything from GetSatisfaction onto the suggestions list.--Dallan 14:41, 19 July 2011 (EDT)

Source page redirects no longer in auto-complete drop-down [18 April 2011]

Source pages that have been redirected no longer show up in the auto-complete drop-down for sources. This is to keep mis-named source pages from cluttering up the drop-down list. Sometime in the next month or two I'll be re-working auto-complete for sources so that it is not case-sensitive and allows you to start typing either the page title, the author, or the source title.--Dallan 20:17, 18 April 2011 (EDT)

Wow! that will be great. --Jrich 22:31, 18 April 2011 (EDT)

Dutch proofreading [20 April 2011]

On Image:1815 Netherlands, Westdongeradeel, Huwelijksakte 8.jpg I have included the transcription in Dutch and a translation in English using publicly available dictionaries. It could use some improvement by someone who understands the language much better than myself. If anyone who knows the language would like to take a look at it, thank you. Is there somewhere on this web site that is better for these kinds of requests? Moverton 15:41, 20 April 2011 (EDT)

We do have a Dutch forum, you may want to leave your question there as well. That may be a page you'd want to watch, as we'll sometimes discuss Dutch-related WeRelate issues like source and place page renaming. --Jennifer (JBS66) 16:04, 20 April 2011 (EDT)

Making finding and adding sources, places, etc. easier [26 June 2011]

Finding and adding sources, places, etc. has just gotten easier:

• Recently-selected sources, places, etc. (selected during auto-complete or find/add page) are displayed on the Find/Add page.

• Recently-selected sources, places, etc. are also displayed on the auto-complete drop-down. This means that places you've selected in the past show up at the top of the auto-complete drop-down now.

• When you view a source from your GEDCOM during gedcom review, a Find a matching Source button will help you find or add a matching source.

• When you enter a source title on a Person or Family page and click find/add, that title is (finally) copied into the Find/Add form. Other minor changes have been made to the process of finding and adding pages; for example, changes made to the form fields when you search for matches are now included if you click on the Add Page button.

--Dallan 18:38, 22 April 2011 (EDT)

Many thanks for all the improvements.--GayelKnott 23:39, 22 April 2011 (EDT)

New here, so if posting in wrong place let me know.

Love the drop down/auto fill feature ---- most the time. But it can be annoying when just putting in a state. It wants to find cities and kind gets in the way if I want to simply put "Texas, United States" for example. Maybe I am doing something wrong, or maybe it can be setup where the larger places (like states) are listed first instead of the smaller places. After all when we are getting into census records, lots of times we only know the state.

Thank you so much, lovin' the site.--EeVas 12:52, 25 June 2011 (EDT)

Good point. I'm moving to a different auto-complete tool later this summer; when I do I'll move countries and states above counties and cities in the auto-complete list.--Dallan 15:38, 26 June 2011 (EDT)

Deleting Unlinke MySources [23 April 2011]

The wiki has been getting more capable, as have I. I am going back and upgrading MySources to Sources, orphaning the MySources along the way. Is there any easy way to detect and remove the now unlinked MySources?--srblac 08:53, 23 April 2011 (EDT)

In the Search screen, set the namespace to MySource, and put "Srblac/" in either the page title or keyword field. Once you find a page, the "more" menu on the left margin should contain "Delete". --Jrich 09:08, 23 April 2011 (EDT)

There is currently not an automatic way to do this. In addition to Jrich's suggestions, you can also make sure that nothing links to the MySource by clicking on What links here from your MySource page. --Jennifer (JBS66) 09:12, 23 April 2011 (EDT)

In order to make this easier in the future, I think I should add a "Find matching Source" option to the "more" menu on MySource pages. This would help you find or add a matching Source and would redirect the MySource page to the Source page.--Dallan 23:49, 23 April 2011 (EDT)

Trouble with renaming pages [24 April 2011]

I was trying to rename a couple place pages, and after entering all the information, I press the submit button, and I get a blank white page. It's giving me a page: <http://www.werelate.org/w/index.php?title=Special:Movepage&action=submit> that appears all white. I tried using Chrome instead of Safari, and I got the same result. I waited quite a while in case it was a loading issue, but it never changed. I don't seem to be having problems with any other stuff like person or place creation, just the renaming thing. — Parsa 00:14, 24 April 2011 (EDT)

Sorry about that. It should be working now.--Dallan 01:35, 24 April 2011 (EDT)

Wondering about the ref tag [20 June 2011]

The workings of wikipedia's ref tag (documentation) seem pretty inadequate for the purposes of WeRelate. The main problem seems to be that whereas wikpedia didn't envision an encapsulated universe of sources, all being described by Source pages, WeRelate has that. So the ref tag ends up with very poor integration to the Source page system of WeRelate, and ends up causing more work, and less consistency in use than is probably desirable.

As an example of the awkwardness of this, I offer a former featured page Person:Stephen Hopkins (2), which has excellent footnotes, mostly done using the ref tag. Notice the following features of the references section on this page, which illustrates several features that I consider shortcomings of this tag:

• None of the references generated by the ref tag link to a Source page, though pages exist for them.
• The citation for the ref tag sources is dependent on the creator of the ref tag writing a complete and valid citation within the ref tag, and will not necessarily match the WeRelate citation for the same source. Thus, on this page, the Plymouth Colony Records citation is very sparse. But there is a relatively mature Source page in WeRelate just waiting to be referenced.
• The see also section redundantly lists sources that are already and separately cited as WeRelate Sources or references.
• The source citation for the mayflowerhistory.com website shows only one reference existing. But there are at least two separate references in footnotes, and it is not obvious that they refer to the same website because the citations look different.

I'm no expert, but I believe it is typical in footnotes to establish a short name for a source, such as Bradford-1991, and when a second footnote refers to the same source, the footnote may simply say "Bradford-1991, p. 120". The ref tag has a name keyword that can be used to refer to a previous ref tag, which frustratingly, almost seems designed with this in mind. But if you use two ref tags with the same name, according to the wikipedia documentation cited above, any attached text for the second ref tag is ignored. Consider one footnote citing p. 87 and another footnote citing p. 120 of the same source.
<ref name="Bradford-1991">full citation, p. 87</ref>
works fine, but
<ref name="Bradford-1991">p. 120</ref>
just creates a hyperlink to the first footnote and ignores the text "p. 120". This is pretty limited.

The ref tag name can be a string like "S1" to refer to source 1, but then the link in the footnote jumps to the source citation, and any attached text is ignored. So again, there is no chance to add a page number specific to just that footnote. You can only reference the source citation as a whole.

Now you can force the Cite template to get closer.
{{Cite|S1|Bradford-1991, p. 120}}
creates a hyperlink to the citation for source 1, but displays like this^{Bradford-1991, p. 120}. I don't find this esthetically pleasing and it would be completely inappropriate for any kind of longer footnote.

I have no idea what can be done in terms of modifying the ref tag for WeRelate, developing a custom tag, or developing a better template, etc. But some thoughts follow.

1. Even if a named ref tag was used more than once, could the text of the ref tag print out in the footnote accompanied by the name. Thus
<ref name="S1">p. 120</ref>
would add a footnote that says "S1. p. 120". The S1 would be a hyperlink to source citation S1. Effectively this is using the S1 source designation in place of a more standard designation like Bradford-1991.

2. What if a field was added to the source citation where the user could optionally define a shortname for the source, just within the scope of that page, instead of S1? Thus the Bradford source would be cited as a regular Source, and the shortname field set to "Bradford-1991". The source citation would look like normal, but "(Bradford-1991)" would be added to the citation somewhere to alert us that further references will use this shortname. A ref tag of
<ref name="Bradford-1991">p. 120</ref>
would create a footnote that says "Bradford-1991. p. 120.". The text "Bradford-1991" in the footnote would be a hyperlink to either the full source citation on the page, or else directly to the Source page.

3. Same as two, but the shortname (inline source reference) is defined on the Source page so that the shortname universe can be managed consistently on a global basis. Of course, in this arrangement, once a source was given a shortname of Bradford-1991 on its Source page, no other source could then use this same shortname.

Because the Stephen Hopkins page has a lot of footnotes, it shows different ways people would like to use footnotes. Notice how reference #2 actually contains references to two sources in one footnote, a NEHGR article and wikipedia. The ref tag has one name, so how can it be made to handle this situation? The simple approach is probably to require the use of separate ref tags for each source referenced, creating two footnotes in this case. Is there a way that the ref tag could be enhanced to support multiple names, so it could provide references to multiple sources within one footnote?

[As a further illustration of how un-integrated all this is, you may notice in this last example, that immediately underneath reference 2 (generated by a ref tag), wikipedia is listed again, as reference 3 (generated by a source citation). This seemed very confusing to me until I placed the page in edit mode and realized where all the references were coming from.]

I just offer these observations up to see if they strike a resonant chord in others, and maybe to get any feedback about alternative approaches. --Jrich 00:54, 25 April 2011 (EDT)

I would use separate references for each source rather than trying to combine them in one reference. But on to your main topic... Using the existing functionality could be done simply enough. (Although I agree that the ref tags could be enhanced.) Beginning with the following text:

Some text.<ref>William Bradford, Of Plymouth Plantation 1620-1647, ed. Samuel Eliot Morison (New York : Knopf, 1991), p. 441-3.</ref>

More text.<ref>William Bradford, Of Plymouth Plantation, p. 68-72.</ref>

Even more text.<ref>William Bradford, Of Plymouth Plantation, p. 87.</ref>

I would begin by adding the source to the list of Source Citations on the Person page. I would not include any page references on the source citation. But I would add something like "Hereafter referred to as “William Bradford”." to the "Text/Transcription location" box. Next, I would modify the previous text to look like this:

Some text.<ref>William Bradford, p 441-3.</ref>

More text.<ref>William Bradford, p 68-72.</ref>

Even more text.<ref>William Bradford, p 87.</ref>

Those references with page numbers will follow the references listed in the Source Citations. You could probably use the cite template (or another method) to link the references with pages back to the original Source Citation entry, but it would not be necessary. Moverton 02:49, 25 April 2011 (EDT)

It still would be nice to have better integration. For example, a person could look at the source citation and not realize how many footnotes are referring to it. So, not realizing, they remove one footnote and think the citation is now not needed. They delete the citation, and now the dangling footnote "William Bradford, p. 87" is borderline meaningless. Or they remove the only footnote and leave the citation that now has no use. Or the text/transcription box is actually used already for transcription connected with proving the birth date, so adding the "Hereafter referred to as “William Bradford”." is awkward. Plus all the organization has been provided by the person editing the page, which means inconsistency because people do it different ways and a bigger learning curve if somebody wants to use footnotes, so they don't.

Perhaps there are other ways of approaching the problem, too. If everything was done through source citations, with named ref tags, then when the page is saved, have WeRelate build a Bibliography section listing each individual source only once whether referenced as source for a birth, referenced in a footnote, or listed as a see also link. For example, if both birth and death are given on different pages of the same town's records, I create two source citations just like today, and WeRelate just lists the source once in a Bibliography section once. WeRelate essentially turns the page number and text/transcription fields of the existing citation into a footnote and attaches these to the birth and death respectively. I create a third source citation to the same source to support some point in the narrative section and add <ref name="S3">. WeRelate recognizes that it already listed the source in the Bibliography so doesn't add it again, but takes the page number and transcription box of the citation to construct the text of the footnote for me. I create each source citation independently, not caring whether the same source is used elsewhere on the page or how many times, and WeRelate integrates it all into an organized presentation. The Bibliography section has one record of the source with three links (1.0, 1.1, 1.2) to its three uses on the page. Each use on the page is a superscripted footnote, and the text of the footnote contains the page number plus any text from the transcription box. --Jrich 09:41, 25 April 2011 (EDT)

Combining multiple citations to the same source seems like a good idea. And encouraging people to use <ref name="S3"> tags to reference source citations in text also seems like a good idea. I worry though about listing the transcript in the superscripted footnote text because the transcript can get rather long. What if, when multiple citations reference the same source, we list the second and third citations directly after the first citation for the source, and use "Ibid" in place of the source title? So the second citation would be shown as "Ibid. p 34.", where Ibid in the second citation would be a link to the Source page.--Dallan 10:14, 25 April 2011 (EDT)

I agree with this. "Ibid." would work fine if the system was grouping them together. I assume that the entry for that would look like <ref name="S3">p 34</ref>. Moverton 11:39, 25 April 2011 (EDT)

I note that using Stephen Hopkins as a reference of the usage isn't a great, uh, reference point. I think the tags have been edited maybe once or twice, by me, in 2008, when we didn't have (or I didn't know about) any way to reference a source in the footnotes at all, and the source database itself was a mess, so there were probably six copies of PCR to figure out before linking to one.

For more current usage, I suggest Person:John Alden (1). It's not perfect, but it's also an example with a couple dozen footnotes and all the types of examples in Hopkins. But the difference is the use of the format

<ref>[[#S11|Bradford’s History]], 75</ref>

which is basically the short-name format above. It would be marginally easier if the system would support <ref name=S11> at 75</ref>, but it's probably easier for future editors to keep the former because it identifies what the source is. I'm under the impression that the "#S11" will automatically change to "#S10" if some deletes, say, source 4, otherwise this is all a disaster. The biggest weakness of this is that it still lists all the Bradford sources separately in the list instead of together as described in the last comment above, although I'm not entirely sure which I like better.

Another related issue is that we have no elegant way to cite a different page in a Source for different events (say the birth is on page 2 and the death is on page 4). I usually either move the page numbers into the source transcription or create a second source with a shortened title ([[#S11|Bradford’s History]]), but that seems awkward.

I'm not sure how ibid fits into this - what would trigger it? Multiple Source references or multiple ref tags? (The latter would be easier, actually - I don't want to create a separate Source for every single footnote.) --Amelia 10:25, 25 April 2011 (EDT)

Regarding <ref>[[#S11|Bradford’s History]], 75</ref>:

this is simple enough but two problems: one, the target needs to be #_note-S11, and two, as you hinted, they don't get renumbered. If source 3 gets deleted, this will point to the new source 11, instead of being adjusted to point at source 10. If there is no source 11 any more, clicking on Bradford's History does nothing. Also, no real indication on source 11's citation that a footnote is referring to that citation, so one could easily delete source 11 inadvertently leaving the footnote with nothing to point to. --Jrich 13:59, 25 April 2011 (EDT)

Well, huh. I only began using that format because Dallan explained it somewhere (and it's here, although I may have written that). I'm positive it used to work, but you're right that now it doesn't. The new required format is significantly less elegant and annoying to remember the exact underscore/dash thing. I'm also almost positive, although slightly less so, that it used to renumber, which was another reason I began using it. Did this break or was there a misunderstanding somewhere? Either way, there are now a bunch of broken pages out there that it would be very nice to fix programmatically. And does <ref name=#S11/> still renumber? If not, eek.

The main thing that worries me about deleting a source that footnotes point to is the difficulty in fixing it. Revert may also undo a lot of useful edits, and will be continually more annoying if it's not caught immediately. I don't think it's a huge problem in the first instance - it's an obvious mistake, as opposed to deleting a lousy source assuming, with some justification, that things will renumber. Some indication through whizbang programming would be fine, but I'd be just annoyed by a "fix" that requires more user work, like creating source citations for every footnote.--Amelia 15:34, 25 April 2011 (EDT)

I think the #S11-related changes happened back when sources and notes got merged on the display. Regarding creating a source citation for each footnote, this was mostly just trying to look at the issue from a different viewpoint. I don't think that it's actually all that hard to create a second source citation: you can copy the source title and record name, if there is one, from the first source citation. But, the problem, is that the source citation area is so far removed from where footnotes are likely to want to be placed, that you would continually be scrolling back and forth. And if you are editing only a section, not a whole page, I don't think you can even get to the part of the screen where you review existing citations or add a new one. --Jrich 16:46, 25 April 2011 (EDT)

Exactly (on the why it would be annoying part).--Amelia 16:51, 25 April 2011 (EDT)

---

FYI, the issues with [[#S1|Text]] not working and renumbering not happening for that syntax have been fixed. <ref name=#S11/> still does not renumber.--Amelia 12:53, 18 June 2011 (EDT)

Renumbering of <ref name=#S11/>has now been fixed.--Amelia 17:02, 20 June 2011 (EDT)

Cemetery pages [26 April 2011]

We now have almost 3,800 cemetery pages on WeRelate! That number has doubled in just over 1 year. Keep 'em coming! Don't forget the Cemetery Portal. There's also a section on the Place pages Help page about how to add category links to cemetery pages. -- Amy (Ajcrow) 12:33, 25 April 2011 (EDT)

That many?! Which reminds me to go back and add more history & description to all those cemeteries I've been creating for Red River county -- and to promote several dozen others from MySources to actual Place pages. --Mike^Talk 14:15, 26 April 2011 (EDT)

Articles as Sources [26 April 2011]

When a Source page is created to describe an article, one of the fields is page number. Most source pages for articles then proceed to give the full range of pages for the whole article.

On the other hand, the page numbers cited for a source citation usually refers to one, or a small range of, pages, focused on where the cited information may be found.

The problem comes about when the two come together: a citation citing one or two pages referencing a source page that gives the full page range of the enitre article. The way this is currently handled is that the page numbers from the Source page are given and then the page numbers from the citation are appended onto the end. Which looks kind of stupid and makes nobody happy. So people usually tend to erase either the focused page number in the citation, or the whole article page range on the Source page. In either case, a potential loss to the reader.

If a reader is interested enough to click on the Source link, they might very well be interested in the whole article. After all, articles such as Source:Bolton, Ethel Stanwood. Some Descendants of John Moore of Sudbury, Mass, Source:Tuttle, Charles W. Tuttle Family of New Hampshire, Source:Bartlett, Ralph Sylvester. Alexander Shapleigh of Kittery, Maine, and Some of His Descendants, and others, essentially serve as the authoritative family genealogies as much as books like Source:Libby, Charles T. Libby Family in America, 1602-1881 do for other families. And the user that bothers to follow the link to the Source page would probably appreciate finding out from the page range there that the article comes in five installments spanning multiple volumes of a periodical, as many of them do. So there is value in having the full page range of the article given on the Source page.

On the other hand, if you are interested in a spouse of a Moore, Tuttle or Shapleigh, you probably want the citation on that spouse's page to direct you to the single page where that spouse is mentioned, not to be given fifty pages across three volumes, of which, in the end, you will only care about one page.

So I don't think the full page range of an article necessarily belongs in the source citation. If the citation gives a range of pages, it is presumably much more focused on where the cited information may be found, and so that is what should be given for the page number in the citation. If somebody wants the full page range of the whole article, let them click on the source link. Is that reasonable? Is that doable? --Jrich 22:56, 25 April 2011 (EDT)

This is part of a bigger problem where bibliographic information (volumes, pages, etc) from the source page is making its way into the citation and it shouldn't. It just hasn't bothered me enough yet to bother Dallan about it. I'll put a report into Satisfaction for him. --Judy (jlanoux) 08:12, 26 April 2011 (EDT)

I'd like to add one thing to this - I don't think the References/Cites section should be coming through to the citation either. --Jennifer (JBS66) 08:15, 26 April 2011 (EDT)

Part of the problem for some of the mentioned pages is that they are type "Misc" instead of type "Article".

That can be fixed by the user. I have created the problem report for this issue of fields needing to be excluded from the citation. Thanks for bringing it up. --Judy (jlanoux) 08:37, 26 April 2011 (EDT)

I would also suggest changing the format of the "Article" type. The source title should appear within quote marks, and the periodical title should be italicized. Moverton 11:27, 26 April 2011 (EDT)

No longer considering GetSatisfaction [19 Jul 2011]

We're no longer considering GetSatisfaction for tracking enhancement suggestions, due to several issues:

• People need to sign in separately to GetSatisafction
• There's no way for people to "watch" the list of suggestions on GetSatisfaction and be notified of new ones.
• It's more difficult to add links to the wiki pages here.

We're experimenting with a couple of alternatives that will hopefully be better. One possible alternative is UserVoice. We're no longer considering UserVoice. Another is described below. If you're interested, please try them out and give us feedback.

Thank you to everyone for their feedback on GetSatisfaction and helping us to decide whether or not to use a different approach. The suggestions already posted to GetSatisfaction won't be dropped; I'll re-post them to whichever approach we ultimately choose.--Dallan 19:25, 26 April 2011 (EDT)

Sortable tables, tools for working with subpages, and more [26 April 2011]

I wanted to try an approach for tracking and voting on suggestions completely inside WeRelate as opposed to using a separate service like GetSatisfaction or UserVoice. I just created WeRelate:Suggestions. Please try it out and tell us what you think.

Creating this page required adding some new capabilities to WeRelate. You can use these new features on any page you like:

• Tables are now sortable!

To make a table sortable, just add class="sortable" to the top of the table. For example, the following wiki text

{|class="wikitable sortable"
!Name!!Birth date!!Death date
|-
|[[Person:Andrew Kennedy (5)|Andrew Kennedy, Sr.]]||1751||23 September 1811
|-
|[[Person:John Tuttle (10)|Ensign John Tuttle]]||1675||07 May 1712
|-
|[[Person:Stephen Vajda (1)|Stephen Vajda, Sr.]]||17 AUG 1898||06 Mar 1987
|}

results in the following table:

Note that dates sort correctly so long as you write them in day-month-year (or month-year or just year) format.

• You can insert the tag <addsubpage/> to any page to get a form where you can enter a title to create a subpage of that page. Edit WeRelate:Suggestions to see how this is done. You might want to do this if you expect to have a project or a transcript with several subpages for example. You could also use this tag to turn an article into a simple forum, where each topic had its own subpage.

• You can insert the tags <listsubpages></listsubpages> on any page to list certain subpages of the page. Only subpages whose titles are found between the <listsubpages> and </listsubpages> tags will be included in the list. This allows you to choose which subpages to list. This tag is particularly useful if you combine it with the addsubpage tag, because the addsubpage tag will automatically insert newly-created subpages between these tags. This allows people watching the "super" page (the page with the listsubpages tags on it) to be notified whenever anyone creates a subpage using the addsubpage tag. The subpages will appear in a sortable table, as described earlier.

• You can customize the table using attributes on the listsubpages tag. You can specify the initial order of the subpages using the "sort" and "direction" attributes. Edit WeRelate:Suggestions for details. Sort can be "title" (default), "created", "lastmod" or "watchers". Direction can be "asc" (default), or "desc". If you specify watchers="true", then the list will include a column for the number of people watching the page, but pages without any watchers will be excluded. Finally, if you want the table to show subpages from a different page than the one the listsubpages tag is on, set the super attribute to the title of the page that the subpages are for. Edit WeRelate:Suggestions/archive to see an example.

--Dallan 19:25, 26 April 2011 (EDT)

Sorting events by date when year is before 1000 [27 April 2011]

When events use dates after 1000, they are sorted by date in the person's display. When they use dates before 1000, the sorting does not work properly. I believe some people use a leading zero in an attempt to address the sorting issue, but I am pretty sure I tried that several days ago and it still did not sort properly - although I won't swear to it.

For an example, see page Person:Liegard De Mantes (7), which currently displays in order:
birth (est 925)
death (12 Nov 990)
alt death (12 Nov 991)
second marriage (aft Oct 947)
first marriage (940)

The Help:Date Conventions page says "the year is allowed to be 3 or 4 digits long according to the GEDCOM specification", although the Help talk:Date Conventions page says "years before 1000 should include a leading 0". I much prefer the option to use 3 or 4 digits - we don't normally write dates before 1000 with a leading 0, and it is not a standard in GEDCOM or on Wikipedia (for 2 examples).

Dallan - can you please fix the sorting problem so that events with dates before 1000 sort correctly, when you get a chance. Thanks. --DataAnalyst 23:11, 26 April 2011 (EDT)

Heraldry on WeRelate [23 June 2011]

I am not in favor of the improper use of heraldry and blazons on WeRelate. The current usage in the surname pages is the genealogical equivalent of pseudoscience. Every text on heraldry ever written will explain from the onset that there are no arms for a surname. A coat of arms is granted to and belongs to an individual, never to a family, and certainly not to an entire surname. The current situation is a misunderstanding by people, especially Americans, who do not understand how arms are awarded and used. The companies in the tourist malls that sell you a mug with your surname coat of arms are absolutely no different than those people who sell you a star in the sky. It's junk genealogy. The right to arms is more like your grandmother's wedding dress. She may have passed it on to your mother, and your mother to you on your wedding day. However, just because your name is "Smith" doesn't mean that everyone with that surname owns that wedding dress. You do, and only you. Arms are presented to individuals as a privilege of rank, and are inherited only as part of a hereditary title. In the United States, you can create your own arms, but there is no official body in that country that recognizes them as official (unless you make it your trademark, which is a corporate mark). The children of peers in countries like England have special charges called differences or brisures (the system is called cadency) placed on the arms of their father (see the arms of Prince William of Wales as an example—in this case on the arms of his grandmother, the queen). If a son inherits a peerage, then he generally bears the same arms as his father. The arms then go with the title, not the surname. The only appropriate place for arms is on the page of an individual who has the right to those arms. This is the example set by Wikipedia. For a source on my argument, read the first question in the FAQ of the College of Arms of England: College of Arms Frequently Asked Questions. You can view some of the College's recently awarded arms to individuals on the page Recently Granted Arms. Not only is the current use of arms on WeRelate incorrect, it may be illegal. For example, the unlawful use of an official coat of arms of an individual is a criminal offence under section 132 of the Danish penal code. I highly recommend that we remove the arms from the surname pages. — Parsa 12:12, 27 April 2011 (EDT)

I havn't done anything related to arms, but I know a lot of folks do. I'm sure we would appreciate guidance on how this can and should be done - it might even be appropriate for you to initiate a portal related to the subject. There have been some attempts to create structures that track hereditary titles (for example, Gilbert de Clare, 4th Earl of Hertford), which might suggest part of the way to do hereditary arms more correctly. Even though it probable offends your sense of correctness - we may want to allow or support some way by which an informal graphic label would be allowed to let someone tag related people for the convenience of their research (even if such a label isn't properly a grant of arms). Since graphics can all be tagged with an arbitrary amount of information, it should be readily possible to designate symbols which are properly understood as granted arms and which are informal tags. --Jrm03063 14:18, 27 April 2011 (EDT)

However, a web site like House of Names, All Family Crests, or Irish Family Coat of Arms or the hundreds of others are not reliable and verifiable in any way. They just made them all up. We could just as easily make up our own. Frankly, on the surname pages, I would rather see pictures of famous people with the surname. For instance "Washington" surname page (not created yet) could have images of George Washington, Booker T. Washington, and Dinah Washington. For a future info box, I think the surname would suffice. Many surnames have diverse origins. For instance the people with the surname "Varner" in America may come from Germans with the surname Werner, or from Irish with the surname Vernor. I can pretty much guarantee that nobody with the surname Varner ever had a coat of arms. It's mostly an American surname adapted for various European ones. People with the surname Cartwright probably come from some ancestor named Tom or John or Harry the local cart maker. My Chandler ancestors were candle makers. They weren't knights of the Round Table. It's really silly. — Parsa 14:41, 27 April 2011 (EDT)

By all means, I suggest you take your ideas up with the people doing surname pages and/or working on guidelines for how those pages should be constructed. If there are proper ways to do some of these things, we do actually endeavor to follow those practices, but sometimes it does take someone to bring the matter to our attention. --Jrm03063 15:11, 27 April 2011 (EDT)

Steven, I have a longstanding interest in peerage genealogy, though I don't have a drop of royal or noble blood in me to my knowledge, and that includes heraldry. (There's a decent, ever-growing annotated bibliography on the subject, by the way, in one corner of my website, Old Booksmith. Can't resist getting in a plug.) But I gave up long ago trying to convince patrons at the library that, NO, there is no "Smith Coat of Arms." People will believe any sort of nonsense if it makes them feel superior. If there are only a few people attributing arms far and wide at WeRelate, you might drop them a polite-but-firm note explaining that the goal is to make WeRelate a center of good genealogical practice for knowledgeable researchers with high standards -- and that they're not helping. I admit, I having paid a lot of attention to the surname pages (they're of limited interest to someone named "Smith"), but I'll keep an eye peeled.

I just did a search, by the way, in the Image namespace with "arms" as a keyword and turned up 20+ hits of the sort of thing I think you're talking about. A couple of them (like "Benedict") were uploaded by people of the same surname, presumably for pages of persons in their own ancestry. That's different, probably, from someone who might be uploading a bunch of similar images for random surname pages. The former need a friendly education, the latter might require a warning. --Mike^Talk 09:25, 28 April 2011 (EDT)

It seems some of these are appearing on featured pages on the Surname portal which makes us look as though we advocate & accept the practice. --Jennifer (JBS66) 15:23, 28 April 2011 (EDT)

I agree with Stephen that adding heraldic arms to Surnames is not correct - or not even useful. However the use of coats of arms officially granted to a person is really useful as a genealogical tool, as the Arms are passed down to sons, and grow in complexity if, on marriage, the husband's arms are "impaled" (ie the shield is split into two parts) with those of his wife. As the family passes the Arms down through the generations, more and more "quarterings" are added. You can imagine, in a family intermarrying with other armigerous families over the generations, the "quarterings" would double each generation. There's a wonderful illustration of the almost impossibly complex arms of the Lloyds of Stockton with 323 'quarterings' (p95 in Neubecker's work).

Also, as a Shield was supposed to be unique to a person at any one time, several armigerous men of the same family will have subtly different arms. These variations are a useful way to differentiate between branches of a family, or parallel families with the same surname. It also demonstrates the absurdity of there being a single coat of arms for a surname - Steven's original point. I have tried to use coats of arms (or more correctly, just the Shield) in the person pages I am creating for several inter-related Tudor families. I have also used the Shield as the primary image, instead of the rather Georgian looking silhouette. See Person:William Honnyng (1) for example. The six 'quarters' provide a miniature graphical ahnentafel for him, and I can use the single shields for his ancestors too. Despite a request from Wikipedia to add a photo (sic!) to my article on Honnyng I have been unable to find an image for most of the Tudor people I'm working on. That person's Shield is therefore, I think, a more useful and pleasing image to include. The only down-side is the length of time it takes to create each shield!

Rather than add heraldic information to Surname pages, but in addition to heraldic information in individual Person pages, is there scope or need for either a Heraldry portal, or a wider Family (as distinct from Surname) page (and as distinct from a 'spouse and children' page)? So the 'great' families that span many generations - like the Clare, Paget, Cavendish, Fitzgerald families - could have a central Family page or portal, to keep track of all the branches, as well as the family's hereditary and mutating heraldry.

What are your thoughts on using Shields as the Primary Image on person pages? Honnyng 04:08, 14 May 2011 (EDT)

The multi-generational family pages could be created as articles (pages without a prefix). I would prefer using a picture of the person (if available) as the primary image. But since I don't have any royalty in my ancestors, it isn't much of a concern for me. Moverton 11:53, 16 May 2011 (EDT)

Thank you for that suggestion, Moverton, about using an 'article' page to cover a multi-generational family; I shall attempt that soon. I also agree with you that a picture is preferable as the primary image; my use of the person's shield instead of the generic silhouette is only in those cases where there is no portrait available.

One additional benefit of using WeRelate to document heraldic shields is that we can use the photo 'notes' annotation to describe the separate parts of a more complex shield, as an aid to interpreting the arcane and anachronistic language used in heraldry. See Honnyng Arms for example. --Honnyng 17:02, 23 June 2011 (EDT)

Making it easier to add people and families [5 May 2011]

I just installed some changes that should make it easier to add people and families, especially for people new to WeRelate:

• You can now add parents or a spouse family to a person without needing to edit the person page. Just click on the "Add parents and siblings" or "Add spouse and children" links.

• When adding a spouse to someone, the search for matching family pages is skipped. You're taken directly from the Add screen to editing the family page.

• You can create pages for the husband or wife of a family, or add children to the family, without needing to edit the family page. Just click on the "Add..." links.

• Just as in the past, when you are editing a family, you can add pages for the husband, wife, or children. Unlike the past, you are now given an opportunity to edit those pages before they are saved so you can add additional information to them (e.g., source citations).

• You can re-order children without birthdates to change the order in which they appear by dragging them up or down while editing the family page.

• You can no longer add people to a family by typing the page title for that person. Actually, that's not quite true. You can click on the "Add..." link, then close the pop-up window, then start typing into the blank field that will appear. I did this because it seems newcomers get hung up on what to enter in those blanks. Now they're taken directly to the Add page screen.

• You can no longer add families to a person when editing the person. I took this out so newcomers wouldn't get into a situation where they were editing a person, adding a family to the person in a pop-up window while the person edit screen was still open, then adding another person in a pop-up window while the family edit screen was still open, then adding another family while the second person edit screen was still open, etc. Being able to add families when you're not editing a person avoids this loop and hopefully isn't too inconvenient.

Hopefully these changes will make it easier for people to enter information online. Please let me know if you notice any problems. Thank you!--Dallan 17:21, 28 April 2011 (EDT)

Just tried this for the first time.

First, regarding "adding a spouse to someone, the search for matching family pages is skipped". This sounds bad to me. I just merged two pages for John Hayden and Hannah Ames and Joseph Hayden and Hannah Ames. So, it seems if you spell a name different, add the person page, now you end up creating a duplicate family page because there's no checking? I create family pages all the time with neither person created. This would be a problem when somebody else comes along and starts creating one of the spouse's pages because they would never look for that family page that's already created.

The reason I skipped searching for a matching family page was because it seemed to me that the chance of there being a matching family, without a matching spouse, was rare. Suppose you're looking at a page for the husband, you add a family page for the husband and spouse, and there's a matching family page in the system. One of two things would have to be true:

• The existing family page did not link to any person page for the husband.
• The existing family page linked to a page for the husband, which was a duplicate of the page you had for the husband.

I thought these two conditions would be rare, so I thought that it would speed things up a bit to skip the search. But maybe I'm wrong here, and we should do the search anyway? If you're saying you create family pages frequently without creating person pages for the spouses, then I'm probably wrong and the search shouldn't be skipped.

I have a long explanation on my user page "Distinguishing People" basically complaining that pages with only names makes analyzing search results difficult. Too often I search for some person and get back results with no dates and no location, because pages are created that are just a name. Especially as so many people put "Mary Unknown", etc., in their GEDCOM and the upload process then creates name-only pages. So, if you are searching for John Q. Public and Mary Doe, you end up trying to decide, is it worth my time to check out these pages on John Q. Public and Mary Unknown that have no date or location? Having made that argument, I therefore try not to instantiate Person or Family pages unless I have data about those people beyond their name. Everybody has an edge to their research somewhere, and so this actually occurs a lot. For example, I identify somebody's parents as part of distinguishing that person from others having the same name, but don't necessarily study the parents enough to provide their birth and death dates. --Jrich 23:09, 3 May 2011 (EDT)

I've just installed an update that includes the search step for spouse-families.--Dallan 08:44, 5 May 2011 (EDT)

However, I could never add a spouse to a Person page, probably because of "You can no longer add families to a person when editing the person". I'm not sure. When editing a Person, there was no button to add either parents or spouse? Is that intended? To add either, I had to save and the add family as a separate step.

Yes, that's intended. When you add a family page, I'd like to redirect you immediately to the family page you just created, so you can add additional family members. This is especially important when adding a spouse-family page I think, so you're prompted to create the person page for the spouse if you want. I can't do this if you're in the middle of editing a person page when you add the family page.

I entered a guy who married three times. Even when I added one of the families, and use the add a husband link, I had no way to add his other two marriages. Because I can't add families from a person page, there was no way to add the subsequent marriages? After I was done, I had to go back and add two more families and link them to the husband.

You should have been able to navigate to his person page and click on the "Add another spouse" link while viewing his person page?

The search results for find/add were weird. They had all the input fields displayed including those obviously intended for sources even though I was adding a Person. The search results listed the people, but the page title of each of the results was not a link, just plain text. Sometimes if the summary is vague, I need to click that link and open the person in a separate tab to see if there is any additional information to help me decide if it is the same person or not. --Jrich 00:18, 30 April 2011 (EDT)

This has been highly-requested. I took out the links so that newcomers wouldn't click on them instead of clicking on the "Select" button and then wonder what to do next. I'll add the links back, with a message at the top of the page reminding you to click on the back button on your browser, then click "Select" to select this page. This will happen tomorrow; the other things we're talking about will be later this week.

Sorry, which was highly-requested? That they not be links? Or that the links be restored? I assume the former. I have no problem making the link harder to follow if people have problems, but I think something is needed, maybe an arrow icon way off to the right, etc., especially as the unique number of the page title is not displayed any more, and without a link I can't mouse over it and see whether I want John Doe (38) or John Doe (39). If that number was displayed, I can always open a new tab and copy the page title into the search box and get there reasonably quickly.

Also, since it wasn't mentioned, don't miss the comment about all search fields being visible, even source related fields, when I am searching for a Person, etc. --Jrich 23:15, 3 May 2011 (EDT)

No, the highly-requested feature was that the links be restored. They're restored in this latest version. You can now click on a link to view more details about a person before selecting them. If you do, you get a reminder message about clicking on the back button on your browser to select the page. Hopefully this addresses your comment about all search fields being visible as well?--Dallan 08:44, 5 May 2011 (EDT)

Yes, the search fields are now just those pertinent to Persons. I don't begin to know the software environment. Wondering if the various add links could bring up a popup (or some form of subordinate window) instead of a regular window, and if the software could be told to disable the add links when displayed in subordinate windows, effectively creating a recursion counter? So whether you start editing a Person or a Family, you have full edit access to one level of attached pages (even adding a Source page) without danger of infinite recursion. Hope that is described clearly enough to be understood, even if it has no basis in possibility. Anyway, just idle musings... Thanks for so much attention to the improvement of WeRelate. --Jrich 12:36, 5 May 2011 (EDT)

It's an interesting idea. Pretty complicated though :-). I think I'll leave it this way for awhile. I've gotten feedback that even the one level of editing I had last week (editing a person in a pop-up window while editing a family) was confusing/distracting. If people want to add more information they can always edit the page later.--Dallan 17:33, 5 May 2011 (EDT)

Ok, I just noticed the add spouse link/button under the marriage info box after you save. You might want to move it up on top of the infoboxes where the add parents one is, since a family with 10 children pushes it off the visible part of the screen.

Good point. I'll do that.

In the end I decided not to put the "Add another spouse" link above the first spouse family; instead I put back the "Add parents" and "Add spouse and children" when editing the family page.--Dallan 08:44, 5 May 2011 (EDT)

That is slightly easier than adding a family in that the link is done for you, but still there is a whole different mental partitioning of the work. Hard not to think, I need to add parents, well go edit the Person page. Especially when parents and birth date are so tightly coupled. Makes more sense to have this separation for the marriages because I'm used to dealing with a separate family page for each one. --Jrich 00:52, 30 April 2011 (EDT)

I hear what you're saying. The problem we need to solve is how to avoid: I click "add spouse family" while editing the Person page, I enter the spouse's name, a family page is created, but a person page for the spouse is not. I then need to save the person page, navigate to the family page, and click "Add spouse" again. It feels like you're making me add the spouse twice.

If I only allow you to add a spouse page while you're viewing the person page, then when it's added I can take you directly to the family page, where there's a big "Add page" link next to the spouse. This still isn't ideal, but it seems better. Maybe there's something even better than this though. Thank you for the feedback!--Dallan 20:52, 3 May 2011 (EDT)

I understand that you want to limit the recursion somewhat. And it's mostly just a matter of organizing the work different, which I am already adjusting to. For example, I locate a birth record in some town's vital records for a person whose page already exists. The old way, I go to the Person page, add the birth date with source, link to the parents. The new way I go to the Family page, add the child and when given the chance to edit the Person page, add the birth date and source. But to be frank, it only seems different, and I don't see the "better" part. There's still the same division of information between Person pages and Family pages, and whether data entry is Person-oriented (the old way) or Family-oriented (the new way), it still biased one way or the other. In the end, the user still has to understand how the two types of pages work together. --Jrich 23:09, 3 May 2011 (EDT)

I put back the ability to add parent and spouse families while editing the person page. A number of people had requested this. To limit the recursion, I took out the requirement/opportunity to edit pages before they get added if you're already editing a page, just like it was before. So if you're editing a person and you add a family, the family page is created and saved without your editing it, just like it was before. To address the family-person duality, I'm going to try adding a prompt when you add a family page asking if you want to create a person page for the spouse (or father and mother if you're adding a parent family). If you answer yes, the system would immediately take you through the add-person flow.--Dallan 08:44, 5 May 2011 (EDT)

Immigrants category? [17 May 2011]

Has anyone ever wanted to see a list of immigrants by surname? I've been wondering if it would be helpful to have a category just for those we know were the first of their line in America. I would like such a category but would others use it enough to make it valuable? I looked through the category index and didn't see anything like this but it might fit well as a sub-category of 'Category:Migration records of the United States'. Any comments? --Janiejac 01:53, 29 April 2011 (EDT)

That's not a bad idea. Except for 100% Native Americans, we all have theoretically identifiable immigrant ancestors. You could have a category called "Gateway Ancestors." Among other sources, you could mine Bob Anderson's "Great Migration" volumes for recognized "first arrivals." I've seen volumes listing the earliest German arrivals in Philadelphia, and there's Peter Coldham's similar books on Maryland. (Our son-in-law's immigrants, however, are turn of the 20th century.) How far would you want to go with this? Would you want to seek out and add at least the early immigrants to WR, or only provide a place to link those who already have pages? --Mike^Talk 08:28, 29 April 2011 (EDT)

The Category:Migration records of the United States is intended to contain sources of migration records. There is a Category:Migration of which the Category:Dutch immigrants to the United States that User:Ekjansen created is a subcategory of. --Jennifer (JBS66) 08:34, 29 April 2011 (EDT)

Besides native Americans, people still in Europe might not see the value either :-). While people in Australia might have a set of immigrants that is different.

Mea culpa. When I hear "immigrant," I automatically think "European migrant to North America" (since all of mine are). --Mike^Talk 16:00, 29 April 2011 (EDT)

Sounds like another category tree. You might have to provide a definition of an immigrant so people recognize the same individual as the immigrant. What if the child came first and the parents followed? What if the father came and then returned? What if umpteen brothers came but never the father? Is there a year range? For one surname I have a line that came in 1600's and an unrelated line of the same name that came in 1800's. The first one has a dozen generations, the second one only four. Is it surname related, or DNA related? Can it go on a surname page? What about women? William Mullins of Mayflower died and his daughter married John Alden so no Mullins left. Widow of John Wing (Deborah) came with three sons. --Jrich 09:00, 29 April 2011 (EDT)

Well, not everybody is going to see the value of every category; as long as some folks do, that should be sufficient reason to have a category. Just how it would be used would be up to the folks that wanted such a category. Right now I don't see any value in having a year cutoff date. I do see a value in having subcategories for the continent or coutry receiving the immigrant. I hadn't thought worldwide; but I guess it could be done that way. I would not care if the immigrant was male or female; as long as they came from somewhere else and settled here. Only the immigrants would be listed but if one is working on a descendant, it could be noted on their person page that he/she is a descendant of Person:John Doe (1) in Category:Immigrants of North America.

I hadn't thought of breaking it down by nationality. . .I would like to see the list sorted by surname. I probably wouldn't seek out and add a lot of immigrant person pages, but if the category is available, I would use it for those I do run onto. I seem to be casting my net further and further and it would be an easy way to find these folks again. I do use categories as a index. --Janiejac 09:31, 29 April 2011 (EDT)

Defining an "immigrant" probably is more difficult than a "gateway ancestor," which (traditionally) would something like this: "Earliest representative of a given lineage, of either sex, to set foot in North America [or wherever] from somewhere else, with the intention of settling." (As opposed to whalers, cod fishermen, soldiers not permanent residents, etc.) Gateway ancestors are those persons whose identification allows us Yanks to get back across the Atlantic. That's the goal of a lot of serious genealogists in the U.S., especially those whose families have been here for a long time.

And I would sort such a category by surname, not nationality, if only because we don't always know (yet) what "nationality" the immigrant actually is. Lots of people with German surnames were actually citizens of Austria-Hungary, or of the Ukraine, and a person with a French name might actually be an Alsatian German. I have a German line (iron miners) who lived for several generations in Sweden and migrated to the Swedish colony at Wilmington. --Mike^Talk 16:00, 29 April 2011 (EDT)

Immigrants has to be a parent category of many others; it doesn't have much meaning by itself. It would be too large to be of use just to look for "immigrants" of a particular surname. I'd recommend we just let it be populated by subgroups that people are interested in creating, which may not always be precisely parallel, rather than worrying too much about structure beyond perhaps dividing out various receiving regions. For the American colonies, there are already Category:1620s Immigrants and Category:1630s Immigrants (which themselves contain subcats for various ships) and Category:Great Migration Study Project, which has the heads of household from the Great Migration project. These are subcats of Category:Puritan Great Migration, which is a subcat of Category:Migration.--Amelia 18:24, 29 April 2011 (EDT)

I'm glad to see so much is already known about these immigrants!! But if the viewer is wanting to look to see the immigrants with a specific surname; for that purpose, the various subcategories are useless. Not knowing or caring what year the immigrant arrived, he would have to look in each of the separate years of immigration and do a 'find' on each of those pages to locate the surname he was looking for. Locating the surname is only possible by visually scanning each page or using the browser 'find' function. I think there should be an easier way to locate all the Samuel Smiths who immigrated. It would seem helpful if the persons on these pages were sorted by surname instead of being all lumped together under 'P' for person!

I agree, a list of immigrants by surname would be very long, but the pages could have the alpha template to enable the viewer to go directly to at least the first letter of the surname. --Janiejac 22:50, 29 April 2011 (EDT)

This is slightly a side issue. While thinking about immigrant-focused categories, I got to wondering if there was already a "Huguenot" category. (There apparently isn't, so I created one: Category:Huguenots in England. Ya'll feel free to include it for other protestant refugees who got from France to the American colonies by way of a stay in England.) But when I went back to browse through the Special:Categories list, just out of curiosity and looking for ideas, it was quickly obvious that the huge majority of them are of the SURNAME-in-PLACE variety. Since there's no page-number index or any other way that I can see to jump ahead in the list, you really can't browse. Very unwieldy. Is it possible to *automatically* create subcategories, via a script or something? (I would have no idea how.) It needs at least two -- SURNAME-in-PLACE and "Everything Else." The first one really needs to be sub-sub-ed alphabetically, too. --Mike^Talk 13:32, 1 May 2011 (EDT)

Special:Categories isn't the best list to find ideas :-) that is a list of all the wanted as well as the created categories. Many of those on the list you would never want as a category and are there due to place name errors on person and family pages. For an example of created categories, see Category:Surnames, Category:Surnames by country, or Category:Contents (the top-level category). --Jennifer (JBS66) 13:40, 1 May 2011 (EDT)

btw, the Category:Huguenots in England isn't really created, even though it appears to have content. A category page is created when it is given a parent category to reside in. --Jennifer (JBS66) 13:48, 1 May 2011 (EDT)

or when you edit it to add content, such as adding a line defining the purpose of the category so others will understand what goes into it and what doesn't? --Jrich 14:05, 1 May 2011 (EDT)

Very true. However, if a parent category is not added, then others searching for the category from the top-down won't be able to find it. --Jennifer (JBS66) 14:06, 1 May 2011 (EDT)

Okay, that seems a bit odd, but I've just added explanatory text to the category page to make it "real." But how would you know what "parent" category to put it under? Well, "Immigrants," I suppose. Maybe "Religion," if there is such a thing? But where does that process end? And what's the point? --Mike^Talk 15:13, 1 May 2011 (EDT)

I think a set of immigration / emigration categories would be useful, and, as a Europe-based WR user, not create it too America-focussed (!) Based on the above, and to help reduce duplicates and be more interesting historically, would the concept of "Gateway Immigrant" be useful - ie a bit like gateway ancestors, but defined as the first person or couple that started the lineage in the new land. Sub categories would be by destination country / colony (ie Gateway Immigrants into Virginia Colony).

This category would be mirrored with Gateway Emigrant pages - eg 'gateway' people Emigrating from England etc. If known, the Gateway migrant would be in two categories. It would also work for those other migrations - eg those of conquest, plantation or colonization. There are many 'planter' families such as Person:John Archdale (2) who is one of my "Gateway Migrants" emigrating from Suffolk, England; immigrating into Fermanagh, Ireland. A few generations later, his descendants became gateway migrants from Wexford into Australia.

Is there a way to have a dynamic category created on the fly, by selecting time frame (by decade / century); from place; destination place; and possibly surname. You could then generate, say 17th century migrant families from England to Ireland; or 18th century migrants from Yorkshire to New York etc. A sort of Migration selector page. Honnyng 08:10, 14 May 2011 (EDT)

I believe what most of us call a "gateway ancestor" and what you're calling a "gateway immigrant" are really the same thing -- though I admit the former term is America-centric. The term is used in the sense that the discovery of where the first immigrant in a lineage came from provides a "gateway" from the New World back into the Old. Basic genealogical practice, of course, requires starting with yourself in the present and working your way back generation by generation to the original immigrant -- and, with any luck, beyond that to the place of origin in Europe or elsewhere. Working downstream from an individual in the past to an emigrant heading west is rather a different thing. (Obviously, a lot of Europeans coming to the New World had/have no descendants in the 21st century.)

Also, I don't think "migration" means quite the same thing when it doesn't involve crossing the wide ocean. I have an old friend in Geneva, a professional genealogist and a very minor member of French nobility. He can trace his lineage back a thousand years as a consequence, as they wandered around western Europe. I doubt very much if he regards the first one to come to the canton of Geneva as being an "immigrant."

In regard to the whole categorization thing, . . . to be honest, I think we can very easily get carried away with that. One can slice-and-dice and refine categories to a ridiculous level: "Yorkshire farmers who moved to the Midlands, who became blacksmiths in Birmingham." As a librarian, I understand the impulse to catalog and categorize -- but it should be done for a reason. What is the category going to be used for by others? Amy's Civil War category project, for instance, makes perfect sense; you can (or will be able to) look at the list of names in the category and see who in a particular infantry regiment has had pages created. I've begun doing something like that for a couple of volunteer companies in the Texas Revolution. And I think I could make an argument for a Huguenot category the same way. But a lot of other categories I've come across on WR (and I'm not going to name them) don't seem to have much utility. I suspect they were created simply because they could be. It's an even greater problem over on Wikipedia, in fact, where the user population isn't even as focused as it is on WeRelate. I'm beginning to think the creation of a new category ought to have to undergo some sort of peer-review process in order to justify it. --Mike^Talk 09:01, 14 May 2011 (EDT)

Apologies, Mike, for I think I didn't explain correctly the suggestion about more granular migration categories. I agree with you that a proliferation of very specific sub-categories would rapidly get out of hand, be time consuming to create, and be of minimal use. My suggestion of a dynamic category would perhaps be better described as a specific search tool. The tool would search for people based upon their migration - linking to the event types of immigration and emigration. You can get a very approximate version of this by searching, say, on birth in England and death in USA. But a search mode more specifically tailored to migration would give more accurate results, pulling the place information from just those event fields defined as im/e-migration (along with optional date-range and surname filters). The example you gave, of Yorkshire farmers moving to the Midlands, could indeed be a possible search term, but never a fixed category. Such an ability would be useful - for example in finding the other families that made up a systematic plantation or colonization. And of course, if it were a search-tool instead of fixed categories, we Europeans could use it to map our little local migrations, even if they fall below the "crossing the wide ocean" criterion to qualify as 'proper' migration fit for American readers :) . As WR grows, such a migration search-tool would help identify and analyze migrations like the Normans into England; the successive waves of English into Ireland; of Irish back into England or escaping famine to the New World; religious and political migrations like the Huguenots mentioned above, as well as for example Polish and Russian Jews fleeing 19th & 20th century persecution - or French aristocrats fleeing Madame Guillotine... One of the fascinations of genealogy to me is the attempt to understand why some families stayed in the same village for 500 years, while others migrated round the globe restlessly. How easy would it be to create such a search option, as an alternative to a plethora of micro-categories? Perhaps a question for Dallan. Honnyng 18:59, 15 May 2011 (EDT)

A search tool as mentioned by Honnyng would meet my needs as well as or even better than a special category for immigrants! It would eliminate the need for specific categories for immigration. I'd like to see more consideration given to this idea. --Janiejac 21:16, 17 May 2011 (EDT)

Soon (by the end of the month hopefully), when you do a search you'll see counts of the places mentioned in the matching pages. For example, if you do a search for people born in England during a certain time period, you'll be able to see how many of them had other events (marriage, death, etc.) in Indiana, in Missouri, etc., and you'll be able to click on each state to see counts at the county level. I'm not exactly sure what kind of search tool you're thinking of, but maybe this will help.--Dallan 07:12, 18 May 2011 (EDT)

I find the the term "Gateway Ancestor" on this context very misleading. It is a term used widely to identify persons who can trace their ancestors to noble and royal lines. Sources such as Weis,AR7, Roberts RD600 Are studies to identify Them. This is the first time I have seen the term used to mean anything else. A Gateway Ancestor can be an immigrant, but not necessarily the other way around. I see no need to complicate the definition of immigrant beyond one who migrated. After all, Winston Churchill had ancestors who did so, in spite of what their descendants did.--Scot 13:30, 14 May 2011 (EDT)

This discussion highlights some of the downside of the Wikipedia style category system. Categories are set in stone and lack the flexibility that some might need when looking for articles. A better way of categorizing would be if articles could be tagged with specific words or phrases. For example, a German-speaking, French immigrant, Mennonite farmer could be tagged as "German language", "French person", "United States immigrant", "Mennonite" and "farmer". Each tag serves as its own category, and a person could get a single listing of all articles tagged as "German language", "United States immigrant" and "Mennonite" (what you might call a merged category). I sometimes wonder if the original creators of the wiki software ever really put much thought into the category system. Perhaps they never thought it would be used as much as it has been on Wikipedia. Moverton 12:26, 16 May 2011 (EDT)

You already have that, essentially, by doing a keyword search. As long as those words or phrases are on the page, you'd find them. The trick, of course, is getting people to enter more than the basic birth, marriage, and death info. -- Amy (Ajcrow) 15:22, 16 May 2011 (EDT)

And the keyword search will find words used in [user-created] categories themselves (i.e. "Civil War" brings up people with Civil War regiment categories), at least as far as I can tell. This adds some usefulness to categories that would otherwise be useless for browsing because they are too large.--Amelia 21:08, 16 May 2011 (EDT)

Articles category? [2 May 2011]

The discussion of categories and a discussion elsewhere of articles sort of cross-pollinated in my brain and I got to wondering: Is there not a category for the organization of articles? Articles are all over the map in terms of subject, and you can search them, but there seems to be no way of browsing a list of them. And there are 3,600+ articles. (Who's the Articles Czar around here. . . ?)--Mike^Talk 18:36, 2 May 2011 (EDT)

Changes to event/fact editing [17 May 2011]

You'll notice some changes to the event/fact edit screen. The sources, images, and notes are now on a separate line so that we have more room for showing places. Please let me know if there are problems.--Dallan 17:35, 5 May 2011 (EDT)

Looks good, but when you press the plus signs, the N1 goes into the description field, the I1 goes into the place field, and the S1 goes into the date field. --Jennifer (JBS66) 17:43, 5 May 2011 (EDT)

I just fixed it. Thanks.--Dallan 17:46, 5 May 2011 (EDT)

It appeared to me that auto-complete of the place was not turned on, and that various help notes that are normally hidden remained visible. Is this intended? The longer place field should help with aliases. --Jrich 19:31, 5 May 2011 (EDT)

Jrich, what browser are you using? I'm using Chrome 10 & Firefox 3.6 - place autocomplete works for me and I don't see any visible notes. Which notes are not hidden for you? --Jennifer (JBS66) 19:38, 5 May 2011 (EDT)

I tried it in IE8 and place auto-complete seems to be working there as well. The help notes that normally popped up when you hovered over them now open only when you click on them, and you need to click them closed as well. But they shouldn't be open without you clicking on them. In addition to your browser, can you also mention if you see a grey "Search" text in the search-box in the upper-right corner?--Dallan 19:46, 5 May 2011 (EDT)

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20. Firefox says there are no updates outstanding but the OS is old. No grey Search text. Just started between this morning and this afternoon. Works fine on Firefox on Windows XP (fine meaning yes to the grey Search text, no notes, and auto-complete works). --Jrich 20:33, 5 May 2011 (EDT)

Please try it again. I reverted one of the changes I made that might have caused the problem.--Dallan 14:38, 6 May 2011 (EDT)

All three symptoms appear to be fixed. Thanks. It is an old OS, and I know eventually I will have to move on, so do not allow this to suppress something desirable. Besides, I was working around it OK, assuming there were no unseen side effects. --Jrich 14:52, 6 May 2011 (EDT)

It's not a problem, at least not for now. BTW, I did some checking and it appears that the latest version of Opera will run on Windows 98. Firefox 2.0 is pretty old; you might want to switch to Opera. It's supposed to be pretty standards-compliant and fast as well.--Dallan 16:29, 17 May 2011 (EDT)

More changes to adding people and families [13 July 2011]

You may notice that if you're editing a person page and add a spouse family, you're asked whether you also want to add a person page for the spouse. Similarly, if you add a parent family, you're asked whether you want to create person pages for the father and mother.

In addition, the family infoboxes that appear on person pages now have red links for spouses whose person pages haven't been created yet. Clicking on one of these links takes you to the add page screen.--Dallan 14:38, 6 May 2011 (EDT)

On the first page of adding a family there are checkboxes for trees under Recently-selected Families. If I select a different tree or unselect them entirely, the next phase of the process does not remember my selection and defaults to the first tree. --Jennifer (JBS66) 07:29, 7 May 2011 (EDT)

I intended them to be checked only if you're going to select one of the families listed below. It wouldn't be easy to carry them forward. Any thoughts on how to make that clearer?

Honestly? Remove the entire recently-selected section on the Add a Family/Person page. What is the intended usefulness of this section? I think that most people who hand enter their data work upwards and don't necessarily have the specific family already on WR. These recently-selected buttons assume that not only is the family/person already on WR, but that the user has visited the page previously. Perhaps I'm missing the point of this, but right now I feel the entire section is confusing. --Jennifer (JBS66) 15:33, 22 May 2011 (EDT)

I can do that. The recently-selected-pages list was added for selecting sources, and I thought since it wasn't any more effort to show the list for people and families, I'd show it for them as well. But if it causes confusion, then it's easy to not show it for people and families.--Dallan 17:12, 28 May 2011 (EDT)

I'm not a fan of having the uncreated spouse page(s) be a red link. Thst screams "click on me and turn me blue by creating a page!" But there are lots of situation where I thought we don't really want people doing that - namely if nothing else is known about the person. Technically one could estimate a birthdate based on the child(ren), but thst's not worth creating a page for.--Amelia 11:59, 8 May 2011 (EDT)

I also don't care for the way the red-links are displayed. For example Family:Unknown and Trijntje Bosma (1) has a red-linked [1] in place of the husband's name instead of the page title text of Unknown. --Jennifer (JBS66) 12:34, 10 May 2011 (EDT)

I removed the red-linked [1]. Any thoughts on a different approach to help people understand that they can create a page for someone when they have additional information, without encouraging them to create a page when they don't have additional information?--Dallan 16:29, 17 May 2011 (EDT)

I do like this better without the numbers. --Jennifer (JBS66) 15:33, 22 May 2011 (EDT)

I find it annoying during the various Add screens to be offered a series of options that do nothing obvious. I would rather not have to cope with Recent selections or with Tree choices that are not going to be remembered anyway.

Others have mentioned this as well. I'll remove the recent selections and tree choices from the Add screen.

I am working on over a dozen Trees and I also find the default of the first (alpha) Tree being checked to be particularly annoying. I am wasting a lot of time just having to look at everything I do and un-checking that first Tree. I would rather only see Tree check boxes where they are going to be remembered and then not having any of them checked by default- rather than one that I am usually NOT working on at any given time.--Jhamstra 20:02, 24 June 2011 (EDT)

I could not check any of them if you have more than one, but that still doesn't seem like a great solution. What if we made the default checked tree something that you could set (and change whenever you wanted) in the "MyRelate > Trees" screen?--Dallan 15:44, 26 June 2011 (EDT)

I think the simplest way to do this would be if you could remember the last tree that I selected and use that one by default. I think in most cases one does not jump from one tree to another while working on multiple people. In many cases I am adding parents/spouses/children to an existing person or family record. if you could remember the tree(s) for that record when I click on one of the "Add" features you would usually get it right. Of course there will always be cases where I am changing trees - but they are much less common than when I am adding to the current tree(s). I have (s) here because some people appear in more than one of my trees.

Thanks, Jim--Jhamstra 21:51, 26 June 2011 (EDT)

That's a good idea. I could make that work without too much difficulty. I'll add that to me todo list.--Dallan 00:01, 27 June 2011 (EDT)

This has been implemented. From now on, whatever tree(s) you add a page to will be remembered and checked as the default the next time you add a page.

This ended up being a bit more work than I expected. I've tested it and I believe it's working correctly, but if you come across a case where it's not working as expected, please let me know.--Dallan 19:42, 27 June 2011 (EDT)

There is a bug with this. When editing a page that I am not watching, the system automatically checks the tree I last used, and I become a watcher on the page. This overrides the system preference of "Add pages I edit to my watchlist" (which I have unchecked). --Jennifer (JBS66) 12:23, 28 June 2011 (EDT)

How about a box for none, much of my edits are for people not in any of my trees and I have to keep unchecking the box.--Scot 21:51, 27 June 2011 (EDT)

How about if I don't check any trees when you have the "Add pages I edit to my watchlist" preference turned off? I'd rather do something along these lines than add a "none" checkbox.--Dallan 23:31, 28 June 2011 (EDT)

If you unselect all boxes once, it remembers that next time - which is similar to a box for none. I don't care for the box being automatically checked when I was never a watcher on a page and make a small edit. Perhaps the above solution would fix that. --Jennifer (JBS66) 10:07, 2 July 2011 (EDT)

Ok, I won't check any trees when you have the "Add pages I edit to my watchlist" preference turned off. That should keep them unchecked when you're not a watcher and you edit a page.--Dallan 11:45, 3 July 2011 (EDT)

Part of the challenge is there are so many different ways to add a page. Can you tell me exactly what you're doing? What are you doing when you uncheck the box? Are you adding a page by selecting Person from the "Add" menu, or by selecting "Add child" when displaying a Family page, or when you're editing a Family page? When it comes up and is checked again, what are you doing then? If I can repeat it myself, I can fix it.--Dallan 11:45, 3 July 2011 (EDT)

Let's say I have a person page for a man. Editing I click on add spouse and children which opens a search box for the wife I enter what I know and click search and I am presented with a list of possibilities headed by Add page button, if she is not listed I must click add page, to the right is a list of my trees with a check in the last tree I edited which I must then uncheck. As I add children, every new page requires me to uncheck the box each time.--Scot 17:54, 3 July 2011 (EDT)

When I edit a page and uncheck a box and save the page, it remembers the unchecked box the next time I edit a page. However, if I edit a page, uncheck a box, and preview the page - the box is checked again. It would be nice if the selection didn't change with page preview. --Jennifer (JBS66) 06:51, 4 July 2011 (EDT)

Thanks. I believe I have found the cause of both of these problems. They'll be fixed tonight.--Dallan 17:55, 13 July 2011 (EDT)

"Edit Section" link [22 May 2011]

The editing link that appears with each new section is, in my opinion, a bit cumbersome. WeRelate uses a rather large type face, and the link is written out completely as "edit section." Furthermore, it floats to the right, and with pictures, template tables, etc. it ends up floating all over the page, making the page look a bit messy. The English Wikipedia simply uses "edit", and it's rather small (Example). Even better, I've always preferred the edit link on the other Wikipedias, such as the German (Example) and French (Example), where it appears immediately after the section title. It's much cleaner looking, and it never has a problem floating all over the place. — Parsa 21:12, 7 May 2011 (EDT)

I like that. Could you add it as a suggestion?--Dallan 16:29, 17 May 2011 (EDT)

I like this too. I added the idea to the suggestions page. --Jennifer (JBS66) 15:39, 22 May 2011 (EDT)

Annoying advertisement banner [2 June 2011]

I now have an annoying advertisement for Lowe's/Chevy/... using up the top of my screen and making it hard to work. I understand the ads on the sidebar but this is much more annoying including it has sound, it flickers, etc.

Does it have something to do with the following lines in the page source code:

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>

  <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.12/jquery-ui.min.js"></script>
  <script type="text/javascript" src="/w/jquery.inputHintOverlay.min.1.js"></script>

Is there anyway to remove this?--Sparrell 08:48, 17 May 2011 (EDT)

WeRelate doesn't have top banner ads. My guess is that someone has inadvertently installed a toolbar on your browser. Does it appear on other websites as well? If so, try uninstalling/disabling it. The other thing you could check is that you're not viewing WeRelate through someone else's frame, like About.com's frame. Look at the URL at the top of the window. If it doesn't start with www.werelate.org, then change it.--Dallan 16:29, 17 May 2011 (EDT)

H2 style [21 May 2011]

Can we modify the style of the 2nd level headings (H2) to be more distinct from the 3rd level headings? In one page (don't remember where) I saw where they had made the H2 all upper case. I like that style better, though I would take it one step further. In this page I modified the style of the H2 to show what it would look like if they were both bold and small caps. I think this makes them much more distinct and easier to browse a long article with multiple levels of headings. Of course one could do it in a different way, but I assumed we didn't want to change the color or size of the H2. Moverton 13:47, 20 May 2011 (EDT)

Your sample page looks good, and the differences in levels are clear. Will try to remember this when adding headings. Thanks.--GayelKnott 22:32, 20 May 2011 (EDT)

I'm open to this if others would prefer it as well. In addition, I'm thinking we should "unbold" the other level headings, which would also help to make the H2 level headings stand out more.--Dallan 12:18, 21 May 2011 (EDT)

Tagging people and relationships with degree of certainty [15 June 2011]

It would help to support work-in-progress if one could tag people and relationships (marriage, parent/child) with an indication of degree of certainty - eg speculative, possible, probable, known from private data, known from public data, supported by citations? etc - whereas currently all data appears to be equally valid (or invalid?)

Notes in records only partly solve this problem - an ability to tag both persons and relationships should also be tied to rendering/viewing of family trees - eg restricting private view or public view to some level of certainty.--Jhamstra 23:51, 1 June 2011 (EDT)

First observation is that doing something like this in a community-created database would require some common level of understanding amongst the users. That does not seem to be present, judging from the --Jrich 23:31, 2 June 2011 (EDT)way various sources are rated primary and questionable on various pages, often exactly backwards.

Second observation is that this is a community genealogy, and not really meant to hold one person's personal research notes. It would seem to me, since the pages are being shared with users who have a community ownership of the data, that data entered should be somewhat more than possible, maybe at least at the probable level of confidence.

Third observation is that there is no concept of private views. So it is not clear to me what you are conceptualizing with that statement. This is a unified tree. By forcing everybody into one truth, it forces people to reconcile their data on a more objective level, to their own, and to other's benefit.

Fourth observation is that the level of confidence is pretty quickly discernable by the sources cited to support it. If there are primary sources, such as vital records, birth certificates, wills, deeds, or good secondary sources that reference primary sources, then usually the data is reliable. If, on the other hand, there are no sources, or the sources are some Internet dumping ground for unsourced GEDCOMs, then the data has a good chance of being wrong. And various levels in-between based on how reliable various secondary sources are. It is the sources that give the data its reliability, not a rating some unknown person places on a page. --Jrich 01:46, 2 June 2011 (EDT)

Jrich,

I accept your second and third observation.

Regarding your fourth observation I am drawing heavily from private sources - for example my grandmother who while living traveled extensively and interviewed others then living and took many notes - also some others from her generation who compiled substantial private books of family information. The fact that this information will never be published does not render it invalid. Also I have examples where the public records are known to be wrong - for example a marriage that occurred in New Jersey but was recorded in Michigan. There are also many cases where the public information was recorded with incorrect spellings or on the wrong day. Of course there are also errors in private records. Clearly one should try to reconcile public and private records where possible. But public records are not necessarily more authoritative than private records.

Regarding your first observation I would suggest simple and clear epistemological categories - eg Probable (uncertain), Certain (private records or personal knowledge of the facts), Certain (public records). Coupled with citations for sources this would seem to be helpful and not ambiguous. Whereas whether public vs private records are deemed primary could be a matter of interpretation.

Also I have not found a good way to annotate parent-child relationships. I can annotate the individual or the marriage but not the parentage. It is possible to prove that someone existed independent of who were their parents or children.--Jhamstra 07:14, 2 June 2011 (EDT)

Documenting the parent child relationship is a question that has been brought up before, and there is no perfect answer. Obviously changing the birth order affects the Family page most, while the Person page appears at first where one would add proof of who the parents are (i.e., the source field attached to the name), but if the proof is the will of the father, do you want to repeat a copy on each child's page? So for now, we seem to be in a trust-everybody's-judgment-to-do-the-best-thing mode on this question, and it is beyond the scope of this issue.

Regarding private sources, they must be documented so they become accessible and appreciated by other readers, else the readers, who don't know you or the source, have no basis to accept conclusions based on them. My own experience is that the error rate of such private sources is far greater than official records. For example, see the comments on MySource:Jrich/John Wheeler Bible, even though this has been a very useful source to me. I always think of presenting genealogy data in a public forum as trying to prove one's conclusion to a jury, and I believe with a jury of strangers, government records would be the de facto authority. So if the government records are wrong, you have to work especially hard to make your case. Too easy for private sources to be shaped by imperfect memories, or by a desire to perpetuate some useful myth.

Regarding categories, words have different connotations to different people. Certain is a word I hardly ever use in genealogy. The act of categorizing requires judgment. Since 90% or more of the Internet genealogists have an imperfect understanding of proof, as a general rule, I would deem them unqualified to assess level of confidence. Better to just document your sources, and if someone looking at the page you contributed to wants to assess their own level of confidence, they have the raw materials to do so. --Jrich 10:03, 2 June 2011 (EDT)

I would add my own emphasis to some of the remarks above. The most respectful thing you can do with the genealogical work of an elder or ancestor is to transmit it faithfully to other researchers and descendents. The value of such material lies only in the ability of others to use it in the context of ongoing research and new discoveries. I would encourage you, as a first step, to scan and, where possible, transcribe such original material as may be in your posession. We have examples of transcribed interviews (interview of James C Mason), family bible marginalia (family bible of Joseph Tuttle), 3x5 card files (Card file of Elizabeth Case), wills (Will of Helen Dennett), and more. We have a new namespace specifically for transcriptions, which may be of use. If your private materials are really is the foundation of your work, then preservation of that material is the right place to start. I would also add, that there really is no dishonor associated with findings and content that do not hold up in light of subsequent research - everyone does the best they can with the materials available in their time and place. Good work has never been easy. --Jrm03063 14:31, 2 June 2011 (EDT)

Jrich,

You wrote "I always think of presenting genealogy data in a public forum as trying to prove one's conclusion to a jury, and I believe with a jury of strangers, government records would be the de facto authority."

My daughter-in-law has discovered that her Social Security records have the wrong birth date and say she is a male - my son and her parents have personally attested to me that she is female. Seriously - public records are created by people who make some percentage of errors - believe me I have spent 40 years working in various segments of the IT industry and I know a lot about data quality issues. I agree that private records are also subject to error.

I would also point out that when dealing with people who lived on the frontiers and moved around a lot they may appear sporadically if at all in public records. If my grandmother and others like her had not visited a lot of people and places and captured their information I would be flying blind. And these people did not have access to photocopiers or scanners to capture source documents nor online databases to cross-check their results. Nevertheless her handwritten notes which were subsequently typed by one of my aunts have proven to be mostly accurate when they can be compared with public records. I agree with you that many family scribes want to prove or perpetuate family legends and my grandmother was no exception. I have been able to prove some family legends and disprove others which may or may not please some of my relatives.

My intent in joining this wiki was not to "prove one's conclusion to a jury" - rather it was to contribute what I know and link it to what others may know - and to accept the assistance of several helpful people in this endeavor. Also it allows me to publish my results in a manner that is accessible to my many relatives - other genealogy sites facilitate publication but do not facilitate collaboration. You and others can feel free to critique or ignore my contributions. But I do not think you should expect that everyone who contributes to this wiki must bring the same intents - that is not how wikis function - it is both a strength and a weakness.

All of the above dialog misses the intent of my original suggestion regarding some simple tagging system. The intended beneficiaries of this would NOT be people like you and me who habitually read footnotes. Rather the beneficiaries would be the friends and relatives who are curious about some branch of the family tree but do not care to delve into the provenance - in your parlance they have no interest in "jury duty".--Jhamstra 16:05, 2 June 2011 (EDT)--Jhamstra 16:10, 2 June 2011 (EDT)

Why not just add something in the text field ("Personal History") or in a note? I'm thinking of something along the lines of "There is uncertainty about the relationship between James and his purported father William. More research is needed." It's simple for the casual researcher to see and understand, yet opens the door for discussion among more serious researchers. No tagging, categories, or drawn-out ranking schemes necessary. Just my $0.02 worth. -- Amy (Ajcrow) 16:19, 2 June 2011 (EDT)

If people want to take the word of an unknown stranger, who happened to be the last person to edit the page, about that person's level of confidence is the page, without understanding the details that gave rise to that confidence, then they don't really care about the answer. Based on what I have seen people publish as their family tree, i.e., their own ancestors that they presumably care about, I wouldn't trust any strangers assessment of their level of confidence, and I don't see value in encouraging anybody else to, either.

The value of WeRelate is the community review, making it likely that errors are noticed and fixed, the latest research is incorporated, that people are investigated from different angles (some research them as a spouse, others as a child of the parents, others as historical figure) giving the whole picture of that person. Time and number of users will increase the level of confidence as more and more people look at the page and decide they have nothing better. How does a rating on the page reflect that?

On top of that, you are describing a need that I completely don't see being needed. If people don't want the details, only look at the infoboxes. If you want to know how reliable something is, you have to analyze the sources. What is the level of confidence? Well, until somebody comes along with information that improves it, apparently every page is the best of any contributors' knowledge to that point. User:w---- adds hundreds of pages straight from a book chock full of errors. Would that user rate their confidence in those pages as high? Sure they would, see, it says so right here in this book, and they'll be happy to do lookups for you since they have their very own copy.

We have talked in various discussions at WeRelate about having a way of flagging sources as good, bad, or absent to indicate pages that need work. But one major difficulty is always defining a good rating system that can be applied automatically and impersonally. Because having one person putting a rating of any kind of quality on a page that is the contribution of several other people is a potentially ugly situation. There is no way on WeRelate to measure a consensus opinion on a page. Your suggestion sounds like something one could do to one's own pages, but the pages at WeRelate are not one's own. They are all community pages. --Jrich 17:53, 2 June 2011 (EDT)

Jrm03063,

I have a privately published book containing the descendants of Anne Hamstra and Grietje Vellema and their spouses down through my children's generation (400 persons) - the current computerized database of the Hamstra / De Wind clan is approaching 1000 persons. In fact the family tree contained in the printed book was published online a number of years ago but then removed due to privacy issues. Since most of these people are still alive there is no way I will publish the source document. However I have drawn heavily from this book for my contributions to this wiki - as well as exchanging information with the living.

I have a privately published book containing the descendants of Gerrit Jans Bijker, Trintje Dates Loonstra and Grietje Sytses Huizenga and their spouses down through my children's generation (>200 persons). Since most of these people are still alive there is no way I will publish the source document. However I have drawn heavily from this book for my contributions to this wiki - as well as exchanging information with my living relatives.

I have a privately published book containing the history of the Schock clan from Germany through the Ukraine t0 North America down through my children's generation (>300 persons). I have not yet begun to enter this data into the Wiki but I will. And again I will not publish the source book.

I also have miscellaneous data from other family records passed on to me by elderly people who may well not live much longer - some of which I have entered and others yet to be done. For me capturing and preserving all of this for posterity is a primary goal - while my remaining elderly relatives still have their memories and can answer the questions that arise.

In total I have four clans of immigrants. Linking them back into their ancestral lands is a serious challenge. Fortunately I have found some people on this wiki who are very helpful in the case of my Dutch / Frisian relatives. For my German / Ukrainian relatives I hope I can be so fortunate.

Except for a few old photographs I have no intent to publish the actual source documents.

I am much more interested in making the information available online (as appropriate) to interested parties - where possible linking it to other data on the wiki. Where there are non-trivial discrepancies between private and public records I am adding notes. Beyond that I have neither the desire nor the time to "prove" that I am right on a wiki. I am after all an engineer and not a lawyer 8-)--Jhamstra 16:45, 2 June 2011 (EDT)

I was under the impression that you had a bunch of family papers/research. Privately published works at least rate a "MySource", so that someone who is really interested in lines that you're working at least has some remote clue where you got what you're presenting. At least if it was a "MySource", they might be able to find you to ask questions. We're awash in pages that are utterly unsourced and its very unfortunate for the folks who follow - they need to reinvent the research and are stuck guessing about whether the original information had value without anything to guide them. --Jrm03063 18:17, 2 June 2011 (EDT)

Amy,

It is not clear how to add notes (or citations for that matter) on a parent/child relationship?

From what I can see of the data model the only way I could do it would be to create an "event" on the Marriage object which might then propagate automatically to all the children (as Residence does). But this breaks if some but not all of the children are affected.

If I add an "event" to the child it does not propagate to the parent.

Bottom line is that the parent/child relationship is not modeled as a data object and therefore it cannot have all the goodies that a Marriage can have. In other words data must be attached to the Marriage or to the Person but not to the relationship of parent(s) to child.

Am I missing something here?--Jhamstra 16:58, 2 June 2011 (EDT)

I don't think you are missing anything. There are two types of pages, Person and Family, and the rest are basically support functions. Data is entered on one of those two types of pages. As a convenience selected summary data is propagated to pages that link to the changed one, mostly to support the infoboxes you see on the right edge of the pages.

I believe some of the limitation of this data model can probably be laid at the feet of GEDCOM and its limitations.

I believe (having just tested it on the sandbox system) that Residence on a Family page only propagates to husband and wife, not to the children. For the reason you hint at, it would be my opinion that propagating to the children would be a bug. Personally, I am not sure I am all that fond of some of these other facts, other that those specific to the marriage and needed for the infobox, propagating to husband and wife, because when looking at the Person page and seeing multiple Reference Numbers, etc., multiple Residence facts, etc., it can be hard to tell which page to edit to fix it. --Jrich 18:30, 2 June 2011 (EDT)

Jrich,

I do not know who developed or maintains this web site but if I had the time and access to the source code (I have neither) I would look at making a way for Events (or Facts as a generalization) to propagate to a group of People (eg but not always a Family). Important ones for me would be Immigration (actually sometimes Emigration and Immigration are two separate events) and Residence - Families (and extended Families) tend to live and move around together (with exceptions). One reason I am seriously dis-inclined to enter all of the Residence data I have found (eg census enumerations which I have consulted for a very large number of people) is that I have to do this many times over for families - sorry but I do not have the time for all that data entry. Same goes for Immigration - no Immigration Events for Families seems a curious omission since I can declare Residence for a Family.

Having worked with data modeling throughout my career I can tell you that disambiguating the Reference IDs is easily solved. Looks to me like the data model needs some upgrading but I know how these things go - once it is "working" nobody wants to touch it for fear of breaking things. But I can tell you that having to upgrade your product is one of the prices of success - otherwise people will eventually move on to something better. It is almost impossible to anticipate how people will use something - especially when it is "free" - look at what has happened to C and Unix.

I do NOT use GEDCOM despite requests from some of my relatives - for me it is built on a seriously limited data model that only made sense in the days when these records were kept on paper - and it wastes a fair amount of paper at that because of enormous duplication of relationship information. The principles of data model normalization have been well defined for 35 years now but it is amazing how routinely they are ignored.--Jhamstra 19:49, 2 June 2011 (EDT)

Dallan is the chief architect and developer. I have worked with data modeling at times, but in any real-life project you are always limited by the information that can be carried in your interfaces, and in this case, that means GEDCOM. So, ignore it at your own risk. Sooner or later, probably later, a better one will get wide enough acceptance to give us a chance of us thumbing our noses at GEDCOM, but at the current time, such an approach would only be figuratively cutting the nose off, as uploading and downloading GEDCOMS seems to be a highly requested feature.

Regarding census data, if you enter the whole household on one page, it then is relatively easy to cut and paste onto the pages of the other people in the same household. However, most people are happy just citing the census sources without giving the detail, knowing that all but the greenest genealogists know how to look up a census record, especially if a small amount of locator information is provided. A source-oriented data model might have had you enter the census data once and link many pages to it, but that is not what was chosen, probably because using sources is not yet the norm in Internet genealogy (sigh). (Actually you could create a MySource page with the census data from a single household and then cite that MySource as a source on many pages - haven't seen this done nor do I know how desirable it would be to create such small transcripts on a large scale. Ditto transclusion, which might be a performance issue if used on a large scale, since the link is followed real time when the page is displayed instead of being included at compile time, so to speak?)

I think some of the design must take into account changes over the lifetime of this project. Over time, many pages will become essentially read-only as most of the easy work is done and changes come rarely from then on. So optimizing for data entry is not necessarily the best approach as looking at, and navigating through, pages will be the dominant activity. Also the wiki software this is built on expects to be dealing with pages of text, which probably makes it hard to think too far out of the box. Just my observations from the outside. Dallan is the person who can address the reality of this. --Jrich 23:31, 2 June 2011 (EDT)

If you want people to enter source data references rather than simply importing from GEDCOM then you should create an optimal (for the user) method for entering reference - right now it is tedious and cumbersome. I just finished copy-and-paste just for immigration data on some Ukrainian immigrants - tedious when only four children came with the parents. I will not bother for another family where ten children came with the parents nor for census references - most of the early census records for McClean County ND are not indexed that i have found - I have had to go to online microfilm conversions of the original sheets. No way do I have the time to include all of these references.

It is well-known that it is more effective to design user interfaces to facilitate desired user behavior than to try to train users in desired behavior - positive reinforcement has more lasting value than negative reinforcement (eg telling me how / how not to use your system). In user interface design as in most other areas of human interaction actions speak louder than words. I will use your system for what it does well and avoid using it for things it does less well.

I rest my case.--Jhamstra 00:34, 3 June 2011 (EDT)

Jrich,

I have now touched people that you are watching.

In this area I have tried to identify my main (but not only) source which is an old genealogy book.

I have tried to clean-up some messes that I suspect were created by people blindly importing GEDCOM files or copying from other poorly documented web sites.

But I may have made a few mistakes of my own.

I suspect that the confusion surrounding the various near relatives of Henry Riddlesdale/Loker and Elizabeth (French?) http://www.werelate.org/wiki/Family:Henry_Loker_and_Elizabeth_French_%281%29 may be an example of trying to perpetuate family myths not to mention some very sloppy work. I see here a number of the same errors that I have found on other web sites. The two big legends here are that the Richard Newton who married Anne Loker was the uncle of Sir Isaac, and that the Elizabeth who married Henry Loker was Elizabeth French. I consider both legends to have been convincingly refuted on other web sites.

I am not sure how far I should go in ripping-up other people's contributions? I would appreciate your thoughts?

Also, I have created a series of MySource entries for my collection of private records and publications. I am trying to incorporate references where appropriate - typically at the family level but sometimes at the person level.

Probably not good enough to satisfy a jury of your peers but perhaps helpful for someone who tries to follow my work (and the work of various relatives on whose shoulders I stand).--Jhamstra 18:10, 10 June 2011 (EDT)

For dealing with common family data I have adopted the conventions that where a source applies to a Family I enter it once on that page only - whereas if it applies to only a single Person I enter it once on that page.

So for children who are residing with their parents you will not see the Immigration, Residence or Census facts or most References unless you look at the Family page for their parents.

In a few cases where I have unconfirmed hypotheses about a relationship I have inserted cross-linked references in the Personal History.

This allows me to create a trail that others can follow while avoiding most redundant data entry.

Disclaimer - some of my earlier work may not yet reflect these conventions - I will try to catch-up later.--Jhamstra 01:14, 16 June 2011 (EDT)

Need to unwatch an entire tree [10 June 2011]

I copied a tree to my user name and am now watching over 6000 pages in this tree. I would like to unwatch these pages. If I delete this tree from my trees it is my understanding that the tree pages will still exist on the page of the user who created the tree. But will I then be unwatching the tree pages or do I have to unwatch each page manually? --Beth 12:54, 8 June 2011 (EDT)

Yes, if you delete the tree, you'll no longer be watching any of its pages, and pages that are being watched by others won't be deleted.--Dallan 23:51, 10 June 2011 (EDT)

Seeing and printing one's tree [26 June 2011]

I am still frustrated with the inability to see and print a register of the tree I'm working on. I don't need to download it. I just need to see the whole picture so I can determine what is already dome and what needs to be worked on next. Since I rarely use FTE I thought that must be where I'm missing out. So I figured out how to see the folks in the tree but I still can't print it out from there.

I also see that because I've uploaded bits and pieces that I need to merge some small trees into what will be the main larger tree. Can that be done or do I need to add each page into the main manually?

As you can tell, I'm having a hard time knowing how to break up a large data base to upload just pieces of it. If anyone has a good system for that, please post some instructions somewhere! --Janiejac 01:00, 11 June 2011 (EDT)

Dallan recently added the ability to merge trees. I believe you rename the small tree to the same name as the main large tree. This will move all the pages from the small tree into the large one.

When you upload a new gedcom, it is not necessary to create a new tree. You can use the existing main tree to avoid this step in the future.

I use family lines to create pieces to upload. Either ancestors of a person or descendants of a person depending on what I've been up to. It depends a lot on the export capability of your program. Some people have one or two of the free programs to use for this purpose if they don't have the capability on their regular program. Just export the whole dataset to the other program and then cleave off the pieces you want. New work I just add manually since I find gedcom involves a lot of rework on my part. --Judy (jlanoux) 08:07, 11 June 2011 (EDT)

The method I've evolved for all this is probably more elaborate than most people need, but I'll lay it out for whatever use it might be. Because I have a lot of genealogical irons in the fire, I have more than 20 different trees, representing either specific chunks of my own ancestry or other projects -- my Dutch ancestors, my Hatfield line, my Smith line, First Families of Louisiana, my Red River County project, the descendants of Christopher Columbus, royalty & peerage, etc. I never hesitate to create a new tree, even for temporary use, but I have one big one called "Default" which includes everyone I'm actually, personally related to. Remember that any page can be included in any tree, so most of the pages in the Default tree are also in one (or more) of the smaller specialized trees. This allows me to open a particular project or branch of my family in FTE to work on without having to wade through gazillions of pages that are of no immediate interest.

When I import a GEDCOM (because I prefer to do most of my thinking and lineage-building offline in TMG), it goes into a temporary, special-use tree called "AAAtemp" (simply so it will conveniently sort to the top of the list of trees). Then I fire up FTE (using the "list" view) and go through the newly imported pages one at a time, cleaning up and reformatting and correcting errors and omissions. As I tidy up and rework each page, I switch it from the temp tree to whatever its final destination tree is going to be. That way, I can leave off and come back to the import-clean-up work later and see exactly what still needs to be done. I find that this systematic method helps a great deal in keeping track of what all I'm doing, especially as I tend to move from one area to another as resources become available or when we go off on a research trip.

In a few cases, I've decided later that a particular family-branch tree is too narrow to be useful and I've merged it with a larger tree. I used to have to do that one page at a time, but the new merging method Dallan introduced makes it much simpler and I'm probably going to streamline my tree list somewhat in the near future. --Mike^Talk 08:10, 13 June 2011 (EDT)

Thanks so much! I believe the idea of using a temporary tree and then moving folks from it as they are tidied up is going to be very useful. At least that keeps track of where I left off the cleanup process! Now I still need to work on devising a method of deciding how to break up this large 24,000+ data base and knowing where I left off uploading. That's not a WeRelate problem but it does affect whether or if my data gets uploaded or not. I'm nearly 82 years old and want to get this done while I still can! If I do, I may never get it all 'tidied up' but at least you'll have it. --Janiejac 09:59, 13 June 2011 (EDT)

Just a quick FYI on this, we're working on a "view tree" menu item that you'll be able to use to see multiple generations of ancestors and descendants on a Person or Family page, regardless of whether or not the ancestors/descendants are in the same tree. I'm hoping we'll have this ready by end of Summer.--Dallan 16:07, 26 June 2011 (EDT)

Linking images with sources [11 June 2011]

Hi,

Is anyone else interested in linking images with sources? I have images of U.S. Census pages that I found online and I would like to link these images with the sources I created for the census pages, or include the images within the sources. I consider the image of the page to be part of the source, or at least supplemental to it. Is there a way to do this?

Thanks!--KKuhn 23:43, 10 June 2011 (EDT)--Judy (jlanoux) 07:49, 11 June 2011 (EDT)

I use one of these methods depending on the circumstances:

• Upload the image, and attach it to the Person page. The edit the Person page and add the Image number to the source. See an example Person:Lucas VanArsdale (1)
• Create a MySource for your source. Add the image to the MySource page. This is particularly useful if there are several images or if the Person page would be slow in loading because of all of your source images or to reduce clutter. Here's an example of this: MySource:Jlanoux/William T Noel Entry. Delinquent List of Montgomery County, 1841-1850

I have moved your question to make it easier for people to find. Please use the Add Topic link to enter new items. We have a Support page for asking how-to questions. See Support on the Help menu.

--Judy (jlanoux) 07:58, 11 June 2011 (EDT)

"Citation needed" question marks [30 June 2011]

Hello - I notice that "citation needed" question marks have started appearing alongside all unsourced facts. I'm quite happy with this conceptually, as it helps flag up where further work is required, but have two reservations. Firstly, on person pages a question mark appears alongside any marriage, irrespective of whether the marriage is properly sourced or not on the corresponding family page. Secondly, a question mark is appearing alongside the person's name. How do you source a person's name if not by reference to the other dated facts? Thanks--RichardK 17:09, 24 June 2011 (EDT

Regarding the marriage, I will check to see if we can resolve this problem. The ideal solution would be to have the citation included when the marriage event is duplicated on the person pages when entered on the family page. In the interim you can copy and paste the source citation to the person pages from your citation on the family page.

you can copy the source to the Person page, the marriage is not available on that page to attach it to, though, so the marriage still looks unsourced.--Jrich 21:02, 24 June 2011 (EDT)

You cite the source for the person's name. Where did you get the name? As an example some of my names are from the birth certificate, death certificate, census enumeration, wills, pension applications, etc. If you obtained the name from the birth certificate and you have S1 as the citation for birth then enter S1 in the source field for the person's name. You may wish to adjust the text part of the citation to only include the name information. --Beth 20:39, 24 June 2011 (EDT)

agree with original poster, this is something I only do when presenting information about why alternate names are listed or to show parents when there is no birth date information attached, so find this unnecessary/redundant in normal case where birth source gives name of person and parents as well, IMHO. --Jrich 21:02, 24 June 2011 (EDT)

I've omitted the ?'s from names and from marriages on the Person page. I could add the ?'s back for marriages on the Person page only when they are unsourced, but you'd still have to go to the Family page to source them. Would people rather see ?'s on unsourced marriages shown on the Person page, or just when they are shown on the Family page?--Dallan 14:30, 25 June 2011 (EDT)

(I should add that the omitted ?'s may continue to show up for about a day because pages get cached on the server. They'll disappear if you edit the page or wait until tomorrow.--Dallan 14:31, 25 June 2011 (EDT)

Thanks Dallan - looking good now.--RichardK 07:45, 28 June 2011 (EDT)

I frequently encounter Ancestral File facts, and they all have question marks. This is largely unfixable, since the AFN is essentially its own source (which kind of points out why they are meaningless as sources). Doesn't bother me, since I feel it reflects appropriately on the reliability of AFNs, and if a person were to try to fastidiously remove all question marks, they would do the right thing, which is delete the AFN. But for thoroughness sake, I thought I'd mention it. --Jrich 09:29, 28 June 2011 (EDT)

It's easy to remove ?'s for AFN events. I'll do that later this week.--Dallan 23:35, 28 June 2011 (EDT)

Unless I'm misunderstanding the problem, the facts could just be linked to the Source:Ancestral File to remove the question marks. Moverton 00:44, 29 June 2011 (EDT)

Except that this would be incredibly redundant. Not that there's just one AFN per person, but documenting the association of a page with one or more AFNs by the AFN fact type already communicates everything there is to communicate. If the preferred way to document AFN is to create a source citation, then perhaps the AFN fact type should be done away with. After all, documenting the AFN fact has no use for the date and location fields.

That said, personally, I don't believe AFN should be a source citation, being essentially the same quality as GEDCOMs, FTW files, or Ancestry trees which we routinely delete as sources (the only good thing is that you can look up an AFN online and verify it was at least copied right). It clearly shows the impact on quality that comes when there is no review (i.e., watchers), or proof standards. I also don't like that the system seems to imply some value in AFNs by supporting the AFN fact type. But presumably the fact type was suggested by its inclusion in the GEDCOM standard. If it was filtered out I wouldn't shed any tears. --Jrich 09:35, 29 June 2011 (EDT)

I think I'll remove the ?'s from AFN facts because it doesn't make any sense to encourage people to source them (the source is obvious). As for removing AFN's from uploaded gedcom's, I could go either way. Would anyone else like to voice their opinion?--Dallan 00:06, 30 June 2011 (EDT)

I'd like to see the AFN put in a source field instead of in the event list. It does help to know where the data came from. --Judy (jlanoux) 11:30, 30 June 2011 (EDT)

For now I've removed the ?'s from AFN facts. I'll add putting AFN into a source field as a suggestion.--Dallan 22:25, 30 June 2011 (EDT)

Source fields in citation [25 June 2011]

It appears that changes have been made to which fields are included in the citation on the individual person or family pages. Can you point me to a list of the changes that were made?

Also, the Periodical/Series name should be included in the citation. Using this example, the government's record series would be needed for a complete citation. Moverton 20:02, 24 June 2011 (EDT)

Posted changes. See next topic.--Beth 20:57, 24 June 2011 (EDT)

I'm not an expert at citing sources personally. I made these changes at someone's request. If they're not correct, please let me know. These are easy changes to make.--Dallan 14:34, 25 June 2011 (EDT)

Changes made today 24 Jun 2011 [24 June 2011]

1. Sources can now have multiple subjects
2. The place type is now required to come from an auto-complete list. The contents of the auto-complete come from [[1]].
3. A red ? is displayed after every name and event/fact that does not cite a source, note, or image.
4. Source citations no longer include:
   1. Periodical/series name except for articles
   2. Volume/Film/Pages
   3. References/Cites
   4. Number of volumes

--Beth 20:15, 24 June 2011 (EDT)

How do you merge a page that has been edited while you were working on it? [27 June 2011]

I have just spent two hours editing a page which was changed by an administrator while I was working on it. I now cannot save my edits. The page says I have to merge my edits with what was done while I was working on it, but does not tell me how. Also, is there any way to let me, and/or an administrator know that more than one person is editing a page at the same time?--GayelKnott 15:57, 26 June 2011 (EDT)

I just undid the Administrator edits (which were very, very, very minor and part of what I would have been changing anyway), but that doesn't seem to work. Please, I would like an answer, as I really don't want to have to redo the work I just did.--GayelKnott 16:36, 26 June 2011 (EDT)

Hi Gayle, I feel your frustration and am so sorry. As I recall the information is in the top half of the screen that will be saved and you need to add your edits to this section to save them. I recall some instructions on the page. Are there no instructions on your page? --Beth 18:37, 26 June 2011 (EDT)

Thanks, Beth. I finally just gave up, cut and pasted my sources into word, and re-entered them from there. I didn't see any instructions at the top of the page, where it said I would have to merge my page with the revised page. They may have been some place and I didn't see them.

I guess the lesson I learned is that in the future it will be necessary to make lots of frequent saves when working on a page, which is likely to be annoying to anyone else watching it.--GayelKnott 20:23, 26 June 2011 (EDT)

I've had this happen too, and when it does it's annoying, but it's pretty rare -- I'm not sure I would change the way I work because of it. In case it happens to you again, you can copy the dates, places, and other information that you've entered, which will appear in a box at the very bottom of the page, up into the corresponding form fields at the top of the page. I know it's a bother...--Dallan 23:58, 26 June 2011 (EDT)

I've also had this happen and I couldn't figure out what to do about it. I was unwilling to spend the time to redo my edits so I just left in frustration with the page unedited. Not a happy situation. At least Gayle figured out a way to save hers. --Janiejac 10:43, 27 June 2011 (EDT)

Thanks, Dallan, for the suggestion. It's one I didn't think of, maybe because I was rather upset. Hopefully I'll not have to try it too soon in the future.--GayelKnott 19:17, 27 June 2011 (EDT)

One suggestion, if it stops and won't let your submit the page, open up a blank notepad, and copy and paste what you have written into it. Then when you abandon the page, you haven't really abandoned it, as you have a copy. --Richard_Damon 20:19, 27 June 2011 (EDT)

Recent change - Change to the Source citation source menu [1 July 2011]

When adding a source citation the drop down selection menu has been changed to Citation only, Source or My Source. Citation only replaces Select. Use of Citation only is recommended when your source does not meet the guidelines for Source or My Source or if you are unsure which source type to select. Citation only is not a namespace and does not create a new source page or link to an existing page. --Beth 19:43, 1 July 2011 (EDT)

Recent addition to place pages [13 July 2011]

Place pages may be created for military bases, present and historical. --Beth 19:47, 1 July 2011 (EDT)

I noticed that the drop-down for type includes such items as "church" and "place of worship". I thought creating those types of places were discouraged. Is that not true? Moverton 00:58, 11 July 2011 (EDT)

It is discouraged. The list of place types comes from MediaWiki:Place types, which was created initially from place types that are present on at least 3 pages. I'm going through it now to remove place types that are discouraged. Thank-you for pointing this out.--Dallan 15:48, 13 July 2011 (EDT)

News: WeRelate in top 101 websites news item (category) [19 July 2011]

It would be useful to include the category in which WeRelate appears in the annual 101 Best Websites listing because the listing is not that user-friendly to find specific sites. For 2011, WeRelate appears in the "Share and Store Alike" category. --ceyockey 10:35, 17 July 2011 (EDT)

I'll add this to the news item. Thank you for pointing it out.--Dallan 14:41, 19 July 2011 (EDT)

Redirects in the Source Namespace [5 August 2011]

As near as I can tell there are about 175 redirects in the Source namespace created for the purpose of providing a short name for a source. For example, Source:Arnold, 1891 points to Source:Arnold, James N. Vital Record of Rhode Island, 1636–1850. Most of these shortcuts have been documented on the main page under the heading "Inline Citation". Today, one of these inline citation sections was deleted on the grounds that this is not a good practice. Not being aware of a policy stating that, this seems a little out of the blue, so I thought maybe a discussion of the issue would be useful? Having seen these redirects being used by other users, I have made 5 or 6 on my own (not the above example, however), and would stop/clean up if this is deemed undesirable.

Presuming that the main purpose for these is to be able to place a reference to a source within a narrative without getting too disruptive to the flow, I though I should try to itemize the alternative ways of creating inline citations:

1. The ref tag, used for creating footnotes, is supposedly the more approved method for doing this. However the ref tag has some major shortcomings, notably that it is not possible to attach a unique page number (or elaborating comment) while still referring to a named source, i.e., you can't say <ref name="S1">p. 32</ref>. This makes it, in my experience, unsuitable for all but the simplest of cases. Also, it does not work inside a note or source citation. And when used for a source that is not cited, it requires basically creating the bibliographical citation manually, which is a lot of work, and where I've seen it used, tends to lead to an inconsistent mixture of citation styles.
2. To make an inline reference to a WeRelate source that was not cited in a formal source citation on the same page, one can use pipe aliases, as in [[Source:Arnold, James N. Vital Record of Rhode Island, 1636–1850|Arnold, 1891]] (i.e, Arnold, 1891). A lot of typing to get a short, less disruptive citation.
3. To refer to a source that is formally cited, you might use an inline citation of the form ([[#S1|Arnold, 1891]], p. 32) . However, this only became available very recently (within the last month?), as it wasn't being properly renumbered before.

There are reasons for not allowing redirects in the Source namespace just for creating short names:

1. The Source namespace does not have sequence number to distinguish like-named items. So it is not clear that using up a name other than the official one is a good idea. For example, did another author named Mr. Arnold publish a book in 1891 that will want to use this same short name? Normally these kind of abbreviations are used within the scope of a single paper, or book, having a finite set of sources, while WeRelate, for all intents and purposes, has an infinite universe of sources.
2. At a minimum, naming conventions are needed or everybody will be creating their own pet abbreviations, i.e., "Arnold, 1891" vs. "Arnold-1891" vs. "Vital Record of Rhode Island" vs. "VRRI".

There are reasons for allowing this practice.

1. What rule does it violate? This seems like a reasonable use of one of the wiki features. If everybody tries to stick to the same short name, this seems like it, works and offers convenience.
2. Given the number of source redirects created by renaming, it doesn't seem like traffic/performance/usage is an usage even on a oft-cited page like this one, but if it is, perhaps this should not be allowed at all. If there are thresholds below which this is okay, they should be spelled out, so decisions don't seem arbitrary.
3. Convenience. This is a practice seen often in the literature, and will be fairly intuitive, especially if the short names are guided by some type of rational naming guidelines. The link to the short name takes you to the same page as the link to the full name, thanks to the redirect, and citing a short-named source produces the same citation on the saved page as citing the full-named source.
4. There are certain short names that should be locked up, because using them for anything other than their common usage would create massive confusion, i.e., Source:TAG.

If source redirects are going to be allowed for this purpose, the Inline Citation section on the full-named source page is a good idea and should not be removed. In the Arnold case, I had to page through 6 pages, of 500 What Links Here links each, until I found the short name, since after the Inline Citation section was removed, I lost track of the exact punctuation used in the short link. (Sources that are redirects do not show up in searches or in the drop down list so I could not just search for it.) If the short name is not easy to find, people will be more likely to create their own short name leading to multiple such names.

If they are not allowed, then my suggestion, besides deleting the Inline Citation section, would be to place some sort of banner template on these short-named sources to notify the creators they are not or no longer allowed, giving a link to the page where the policy is detailed. At least then it wouldn't give the appearance of one person simply disliking that style of doing things. --Jrich 21:49, 19 July 2011 (EDT)

If cross-namespace redirects are allowed, I would suggest that people create personal shortcuts in the MySource domain. This would effectively segregate them from shortcuts created as assists for project administration. --ceyockey 23:11, 19 July 2011 (EDT)

I wonder why there hasn't been more discussion on this issue.

1. Cross-domain redirects are allowed for the special case of MySources redirecting to sources, so that's one possibility.
2. If we could come up with a standard abbreviation format, it seems that Source redirects are another possibility. Since redirects don't show up in search results or in drop-down lists, the abbreviation format would need to be pretty straightforward.
3. Using [[#S1|Arnold, 1891]] should work now.

Any more comments on one approach as compared to the others?--Dallan 00:37, 2 August 2011 (EDT)

I never got a Watercooler notification for this comment, so perhaps there was a hiccup causing a lack of response.

I don't find any of the reasons for having these as inline citations to be persuasive. To address the points above, it is just as easy (and shorter) to type "Arnold, J" in the source title box (which brings up the vital record source) and use <ref>[[#S1|Arnold]], page whatever</ref> than it is to remember or look up an inline citation. The result of the former is a proper footnote with the full citation on the same page. The result of using the inline citation is something in the text like "Source:Arnold, 1891" - that's 1) ugly in its inclusion of "Source" (unless one doubles the text, which defeats the point); 2) obtuse since one has to click through to the link to understand what's being cited - the form may be intuitive, but what is meant by "Jacobus, 1940" isn't going to be obvious; and 3) out of order - it's in the text instead of in the list of references, unless one uses the <ref> tag, which this is also trying to avoid

And it's argued that this form would be used after one has already looked up the relevant Source page and copied the proper inline citation. It is equally easy in that case to copy and paste the full name of the source, so the argument that it saves typing doesn't wash for me.

Another downside, in addition to creating a less understandable citation, is that it's yet another way to do citations to confuse new users with. I don't have a problem with users having these if they want (there currently being only a couple users that use them). But putting them on the Source page (especially a well trafficked/used page like Arnold) implicitly encourages others to use them when there is no good reason and the result is actually less usable and uglier than the existing methods that are described in the help and are used on most pages. We have enough of a learning curve as it is without this becoming commonplace. Similarly, we have enough of a maintenance burden without worrying about documenting these, rewriting the help, and policing their form (which has obvious potential for duplication).

It would be difficult if not impossible to prohibit these. They're less than ideal, not a problem per se -- unless they become commonplace, which is when the burdens outweigh the usefulness. What we can do is take the general position that these are a matter of personal preference and not a preferred citation method. They shouldn't be highlighted on Source pages, and they should be replaced where people are willing to take the effort to do so.

All that said, I do think that redirects are handy shortcuts when they don't affect the user viewing experience. So I do type "NEHGR" in the Source citation title box because that renders as the full citation for the Register, and is shorter than typing "New England Historical...<pause>" for the full title. Same with TAG, GMB, etc. The only thing these affect is the experience of the user when editing, which is why they make the most sense for common abbreviations, but it's not a big deal either way.--Amelia 01:38, 2 August 2011 (EDT)

One problem with these types of redirects is that they are not guaranteed to be unique. Arnold, 1891 might mean Source:Arnold, James N. Vital Record of Rhode Island, 1636–1850 to some people, but could also refer to a family history book published by John Arnold in 1891. Another downside to encouraging their use is that inline citations are not commonly used in genealogy; they are more commonly used in the sciences. (As a history undergrad who is finishing her Masters in library science, I had to "re-learn" how to do source citations in APA style.) I would hate to see WeRelate start to encourage practices that aren't widely done in the field as a whole. -- Amy (Ajcrow) 07:29, 2 August 2011 (EDT)

Personally, I dislike these inline citations because I suspect that some people will make horrible ones, like [[Source:W]] for Source:Wheeler, Albert Gallatin. Genealogical and Encyclopedic History of the Wheeler Family in America, or even good ones that don't work in a wider context, such as [[Source:Reed Genealogy]] meaning one of Source:Reed, Jacob Whittemore. History of the Reed Family in Europe and America or Source:Reed, John Ludovicus. Reed Genealogy, or possibly even some other one... As Amelia says, it takes fractions of a second longer to look up the correct one. So I think these inline citations should be discouraged by rule. I think Moverton offered a workable suggestion if people really think they are necessary, namely MySource redirects, but personally, I don't even think those are necessary. Until this is decision is "made", however, I think the Inline Citations documented on the pages for which this has been done should remain.

However, the existing tools in WeRelate need some enhancement. Not all things in genealogy are known. There are many times when I engage in long discussion comparing sources to justify a conclusion that is "fuzzy". A shorter example is Person:Susanna Packard (4). There are probably better ones, but hopefully it will be sufficient to show this. Whether in a note, narrative or on the Talk page, I think there is a need to do several things that some of the comments here do not envision.

The first is to refer to sources that are not cited in a source citation. Like the example, I may often want to mention a source that I think is wrong, and so, I am not comfortable citing the source formally as if it was required reading on this person. To be useful, I think cited sources should represent essential reading, much like the way GMB works, and not every single source that mentions a person, whether right or wrong, detailed or cursory. Once the discussion is no longer necessary because the controversy has been resolved by new data, this inline citing of a source should go away. It is not clear this would happen if it was done using a footnote to a cited source.

In such a discussion, I am often referring to multiple pages in single work. The classic example is when the parent's family is summarized on one page, but the child's own family is summarized on another page later in the book. Often the exact wording is critical (did it say on, about, or before?), and I want people to turn to the exact page and see the exact phrase I am referring to. Therefore, I think the ref tag needs to be modified to allow each reference to a cited source to also include unique text that give a page number or additional explanation that applies to that particular footnote. wikipedia developed the ref tag for a world that did not include a database of standard source pages and therefore I think their ref tag is insufficient for WeRelate uses.

A first cut at proposing what I would like to see for a WR_ref tag would be something like the following:

1. if no name keyword provided, work as the ref tag does now
2. if the name keyword is used and it is S1 or N1, in the footnote, create a link (an uparrow? "See S3."?) to the indicated source citation, and then append the text between <ref> and </ref>.
3. if the name keyword starts with Source:, put the full Source Citation in the footnote and than append the text between <ref> and </ref>.

--Jrich 10:11, 2 August 2011 (EDT)

Just to be clear, you'd want the text between ref and /ref to be appended to the superscript citation, as in

text followed by a named ref tag^{[ 1 text between ref tags]}?

I think that may be do-able.--Dallan 18:51, 3 August 2011 (EDT)

If that rendered as you intended (i.e. words in the superscript), then no, at least as I understand it. I think the request is that code like this

text about something<ref name=S1>p.1</ref>

would render like this:

Text about something^[2]

References

1. The source in S1

2. The source in S1, p. 1.

As Jrich notes, it's only really needed for when adding the source to the source list isn't desireable (using one's own name rather than S1, something I know is supported on Wikipedia), since otherwise, one can use <ref>[[#S1|Short name of choice]], p. 1</ref>, which is just as easy, and cleaner in the reference list. --Amelia 20:00, 3 August 2011 (EDT)

Addendum: I went back and reread the request, and was going to edit my comment to match it more precisely, but I couldn't figure out how 3 would work, so this is a little modified:

text about something<ref name=Arnold>[[Source:Arnold, James N. Vital Record of Rhode Island, 1636–1850]], p.1</ref>. Some more text. <ref name=Arnold>p.2</ref>

would render like this:

Text about something^[1] Some more text.^[2]

References

1. Arnold, James N. Vital Record of Rhode Island, 1636–1850: First series, births, marriages and deaths. A family register for the people. (Narragansett Hist. Publ. Co., 1891), p. 1

2. Arnold, p. 2

We can sort of do this now, but it requires hand coding the citation, and doesn't make use of the name tag, so this would save some work.

Wikipedia permits a little something different - you can specify your own short name, but reuse is limited to the exact form of the cite you used the first time, that's actually not very helpful. --Amelia 20:20, 3 August 2011 (EDT)

The following was written while Amelia was adding her comment and does not reflect her input. I believe she has interpreted it pretty close to what I was trying to say.

No. I was thinking the text between tags would go into the text of the footnote in the references section, not as part of the superscript (which is kind of ugly).

One of the reasons for wanting something like an inline-citation is the idea that a source should be cited once, even if referenced many times. So the first use establishes an abbreviation like Arnold-1891, and all the other references simply use that convenient shorthand. In our case the abbreviation is S1. In the narrative, I would like <ref name="S1">Page 23. He served under Captain Jones.</ref> to create footnote text that said [[#S1|S1]]. Page 23. He served under Captain Jones. or something along those lines.

<ref name="Source:XXX"> was just an extension of the above which was trying to leverage the full citations stored on the Source page when creating the footnote text so that the citations inside footnotes were consistent with the citations in the sources section. But the syntax gets ugly with real life examples so it may be better to abandon this? An example would have something like, <ref name="Source:Bond, Henry. Family Memorials. Genealogies of the Families and Descendants of the Early Settlers of Watertown, Massachusetts, Including Waltham and Weston (1855)">Page 212 gives the wrong wife for John Doe, because Bond confused John of Plymouth with John of Weymouth.</ref>, which I envisioned creating footnote text something like Bond, Henry, M.D. Family Memorials. Genealogies of the Families and Descendants of the Early Settlers of Watertown, Massachusetts, Including Waltham and Weston (1855): To Which Is Appended the Early History of the Town. With Illustrations, Maps and Notes. (Boston, Mass.: Little, Brown, and Company, 1855). Page 212 gives the wrong wife for John Doe, because Bond confused John of Plymouth with John of Weymouth. ?? --Jrich 21:15, 3 August 2011 (EDT)

I think that using something like <ref name="Source:XXX">some text</ref> can be difficult to read, and just isn't really necessary. However if you wanted to allow the option to do it, I would modify it to appear like <ref name="ShortName" source="XXX">some text</ref>. This allows you to create another reference to that same source elsewhere without needing to specify the source a second time. Using Amelia's example, it might look something like this:

text about something<ref name="Arnold" source="Arnold, James N. Vital Record of Rhode Island, 1636–1850">p. 1</ref>. Some more text. <ref name="Arnold">p. 2</ref>

--Moverton 13:03, 4 August 2011 (EDT)

I don't have any particular feelings about the redirect issue, but I do have about inline citations. I recall that this came under discussion some time back but was never resolved. Amy points out what I said back then: The use of inline citations is fine for a microbiology journal, but it has no history of use and no recognition in genealogy. Genealogy (like history) belongs mostly in the humanities, not the sciences. If you want a model for source-citation, look at NGS Quarterly or NEHGS Quarterly, or go to Elizabeth Mills's Evidence! -- those are the standards in our field. --Mike^Talk 15:11, 4 August 2011 (EDT)

Tried to add this a bit ago: I'm with Amelia on this one. For one thing, her suggestion is closest to standard citation methods, and for another it is closest to current WeRelate practice and would not take any significant relearning.--GayelKnott 15:17, 4 August 2011 (EDT)

The citation plugin from Wikipedia that we're using is designed so that if you use name attributes in the ref tags, just one citation per name is generated. It's certainly possible to change, but it's not a quick enhancement unfortunately. Would someone add it as a suggestion so it doesn't get forgotten and can be prioritized with the other suggestions?--Dallan 00:55, 6 August 2011 (EDT)

Gedcom upload and duplicate alternate facts [4 August 2011]

I am sure this has been discussed previously but can't locate the discussion. Duplicate alternate facts are being created as a result of the gedcom upload. I don't know if this is a user error or an error inherent in the gedcom upload system. Alternate births, deaths, burials, etc. seem to be created simply because the month is in all caps in the gedcom. So if the birth date is 20 Apr 1886 on the original created page and the birth date is 20 APR 1886 in the gedcom an alternate birth fact is created. --Beth 10:19, 25 July 2011 (EDT)

Are you going through the matching process in GEDCOM review? Caps/lowercase will create a "yellow match" rather than a green (i.e., identical) one, but if you uncheck the box, it shouldn't create an alt fact. --Mike^Talk 11:03, 25 July 2011 (EDT)

No, a user uploaded a gedcom that merged with many of the pages that I am watching. When I checked my email this A.M. there were 2 pages of emails from WeRelate regarding changes to the pages. Some were legitimate changes, although none of the changes are documented by any legitimate sources; but many were simply because of the case differential in the month. Is it possible to eliminate this option in the gedcom upload process?--Beth 11:35, 25 July 2011 (EDT)

It is possible. But we have an influx of new users loading vary large gedcoms. They don't take the time to review and clean up their pages and they don't take care with the merges. --Judy (jlanoux) 12:25, 25 July 2011 (EDT)

I think it was mentioned somewhere before about possibly adding rules to the types of values that can be added to the date fields (eg. using specific abbreviations or capitalization). Maybe this would be a good time to add that to the pipeline for development. Moverton 15:44, 25 July 2011 (EDT)

I'll second that! I use bef, aft and btw without caps and would like to see it on WR that way. Capitalization or the lack of it shouldn't be something that delays an upload. Is there a way to automatically change the case to whatever case rule is decided upon so it doesn't delay their upload? Case differences are so minor they shouldn't generate edit notices. --Janiejac 09:39, 31 July 2011 (EDT)

There seem to be a couple of ideas here. Perhaps someone could flesh them out and add them as suggestions to WeRelate:Suggestions?--Dallan 01:08, 2 August 2011 (EDT)

I'm not sure how much rule-making is worth the trouble in this case, frankly. When I create a GEDCOM in TMG, it comes out with dates and abbreviations in all caps. That's just the way TMG does it. (It may even be the GEDCOM standard, I don't know.) That offends me aesthetically (don't laugh, guys . . .), but since I handle each and every page after import, double-checking and doing clean-up, I change the case at that time. However, most people don't bother. I see all sorts of weird punctuation & spelling, peculiar notes, and odd comments imported into the standard fields -- all in red, of course -- and none of them have been changed or corrected since the original GEDCOM was imported. But there are still a great many variations that technically aren't "wrong," and not just in casing. I spell out the names of states but many people use the traditional abbreviations -- or two-character postal codes. Likewise with spelling out months. Many people put dates in month-day-comma-year format. Some people use a plus sign to mean "after." I use a hyphenated date instead of "between." Nobody's right or wrong on those choices -- just different. Are you really going to insist your own way is the only right way? I'd rather we didn't do that. --Mike^Talk 15:28, 4 August 2011 (EDT)

Census pages [17 September 2011]

Categories

The census category pages show a mix of source pages that use a sort key in the link to the category and some that don't (often within the same category). The 1870 Indiana census uses them. The 1880 Ohio census doesn't use them at all. The 1880 Indiana census has a mix.

The Help page for Source page titles doesn't mention the use of them, but apparently there are those who find that they would be useful. (I tend to agree, as the use of the sort key does make the page easier to scan.) What is everyone's thoughts on the use of the sort key in the link to the category on census Source pages? -- Amy (Ajcrow) 08:15, 31 July 2011 (EDT)

Support.--Beth 10:12, 31 July 2011 (EDT)

Support an automated solution that ignores the "Source:" (prefix before ":") in page sort order in categories; this would eliminate the need for most manually placed indexing terms. --ceyockey 11:25, 31 July 2011 (EDT)

These are categories that only have one kind of page listed in them. It's not worth the effort to put sort keys in when it's not going to change the order - they'll still sort by the first word of the title, the county. An automated solution won't affect this problem, but I think it's kind of in the works with the category/source redesign Dallan's working on.--Amelia 11:45, 31 July 2011 (EDT)

The sort order doesn't change, but you do get the subheadings, which greatly adds to readability. Without the sort key, everything is under "S," which isn't very intuitive. I realize that Dallan is working on something for sources, but we don't have an expected date for that. -- Amy (Ajcrow) 13:00, 31 July 2011 (EDT)

Maybe for categories with lots of entries, but these are counties. There's maybe 100 of them per state and often far less. Adding 26 subheads makes it worse in my opinion (I'd argue most people don't even see the "S", since everything's already in the expected order). And, specific to this issue, the difference certainly isn't large enough to justify going back through several hundred pages to make this change, as well as several hundred other pages in categories where the same logic applies.--Amelia 17:05, 31 July 2011 (EDT)

Templates [26 September 2011]

Regarding census templates: I finally figured out how to create a census template. I've only done 1850 US Federal for now. How's it look (does it work everywhere, or just for me? I tried it on a few pages, and it did aokay. Is the Usage section too hard to understand?)? --Obstinatesnooper 03:35, 17 September 2011 (EDT)

If you want to use something like this, I'd recommend adding information on the full place -- both county and town(ship)/district/ED in addition to state -- so it's clearer when looking at it where the people were found. This also shouldn't replace the source citation, which should also have that information as well as the page number. Personally I think this is a lot of effort and real estate for a fairly minor set of facts that's better placed in the source detail (particularly if done for multiple censuses), but it is nicely done and it's a template syntax I didn't know we could do but looks really useful.--Amelia 13:53, 17 September 2011 (EDT)

Thanks, I'll go play with that and see how it can look. I never even thought that people would try to substitute that for a source; I'm citation-crazy myself. I was considering building <ref name="S{{{SourceNumber}}}" /> into it; I'll go ahead and do it. (Actually, in TMG, my censi have relatives: the NY Cayuga 1850 Census is the child of United States 1850 Census and NY Census, etc.). Using the template is a lot of effort, but I've been typing it out in the bios by text since I started with werelate, so I figured it's about time I figured out how to make one since I couldn't find an existing one =). I'll also remember to add 'optional' to the source pages themselves when adding the template link.--Obstinatesnooper 16:20, 17 September 2011 (EDT)

I added a reminder to add a source citation, but it looked tacky. So, I just put in the reference tag, and if they don't create one, it automatically adds a link as if one existed. That can serve as a reminder.--Obstinatesnooper 17:16, 17 September 2011 (EDT)

This is cool!--Dallan 10:30, 23 September 2011 (EDT)

thanks. the source doesn't stick around though, if they don't create it. i tried skipping the creation and saving it, and it knocked it off.--Obstinatesnooper 00:46, 24 September 2011 (EDT)

Right - you'd have to add the source citation and the template as two separate steps. I can't think of an easy way to do it in one step unfortunately.--Dallan 14:02, 26 September 2011 (EDT)

Template lifecycle - deprecation [31 July 2011]

I have created a new page for central discussion of templates which have reached the end of their lifecycle and which are candidates for deprecation (delinking and deletion). See WeRelate ToDo/Deprecated templates for this page, and Template talk:Googlemap for some discussion leading up to the creation of this new page. Discussion about the utility / benefits / problems of this page could be added to here or to the page's associated talk page. --ceyockey 11:23, 31 July 2011 (EDT)

Marriage source ended up in template [31 July 2011]

Egads! Help me figure out what I have done wrong. See Family:Samuel Skelton and Susanna Travis (1). I created a new template from another template and added it to the page. Everything okay. I then added a marriage source which is now inside of the template on the family page but not on the template page. --Beth 17:33, 31 July 2011 (EDT)

It appears you were missing one end of table code |}. I added it to the template, and the page looks ok now. --Jennifer (JBS66) 17:37, 31 July 2011 (EDT)

I was simultaneously working on it, by converting it to use the Ships template, which is much easier to edit after initial creation and harder to muck up when you forget how tables work, like I do all the time!--Amelia 17:44, 31 July 2011 (EDT)

Thanks so much. I knew you could figure it out quickly. I don't know HTML so it would have probably taken me 24 hours to figure it out.--Beth 18:58, 31 July 2011 (EDT)

Are Naturalization documents copyrighted? [4 August 2011]

Passiac County, NJ has a website that contains Naturalization documents in pdf format. They do not allow linking to these documents, but do allow them to be downloaded. I thought that U.S. Federal documents are not copyrightable and are in the public domain. The Declarations of Intention and the Petitions for Naturalizion appear to be Federal documents, does this mean they are in the public domain? There is no copyright information on their website, and I am wondering if these can be uploaded to WR. --Jennifer (JBS66) 11:53, 1 August 2011 (EDT)

Although they might say they don't allow linking to the documents, it's actually a matter of you *can't* link to the documents. The way they have it set up, the URL is not specific to the document, so if you try to bookmark or link to a specific document, you'll get an error message of "Document not selected." I'm not a copyright expert, but in the US, government documents are generally considered public domain. Where they aren't is in the case where metadata or other types of finding aid has been added. In this case, however, it looks like a pretty straight index has been added. Personally, I think adding them here could be considered fair use. Again, that is just my opinion. -- Amy (Ajcrow) 12:05, 1 August 2011 (EDT)

Government records are (in general) Public Records and freely available to the public with bounds established by privacy rules, thus there is no copyright on the original documents. Copies and collections of these may have a derivitve copyright for that particular embodiment (for example, Ancestry hold copyright for their photographic copies of many of the documents if they did the actual photography) and you need to read their rules for what they consider "fair use". In this case, it is a Government Body who appears to have taken and published the images, so it appears that these copies are also Public Records --Richard_Damon 12:55, 1 August 2011 (EDT)

Thank you Amy and Richard for your comments, they were very helpful! --Jennifer (JBS66) 06:25, 3 August 2011 (EDT)

Just for the record (and because I used to have to explain this to library patrons all the time): In the U.S., documents created by any federal agency are 100% in the public domain from the instant of their creation, and always have been. This includes the courts of record that used to handle all naturalization paperwork. "Public domain" doesn't necessarily imply that you can do whatever you like with them -- but for our purposes (since we're not involved in national security or in court cases under review by a judge), that is what it means. This is not the case, however, with documents created at the state or local level. The federal policy on copyright/public domain doesn't apply there and there are many, many variations and exceptions from one jurisdiction to another. And in the UK, Crown Copyright is another kettle of fish entirely. Ditto in other countries. --Mike^Talk 15:39, 4 August 2011 (EDT)

New ad from Archives.com [13 August 2011]

We're trying out a new ad from archives.com. 50% of the page views now display the archives.com ad; 50% continue to display the google ads. It's graphical and may be more distracting than the google ads (sorry). We're going to try it for two weeks to see how it performs compared to the google ads. At the end of that time we'll decide whether or not to keep it.--Dallan 18:11, 3 August 2011 (EDT)

I'm getting the same image each time. It does not seem to affect page load speed. But I do not like that there is nothing identifying this as an advertisement. It's not clear that this isn't an endorsement either. The Google ads at least have the word ad at the top of the column. --Judy (jlanoux) 19:40, 3 August 2011 (EDT)

I have the same concern as Judy. There is nothing indicating that it's an ad. It looks like it's part of the WeRelate site. Since it doesn't slow down load time and doesn't affect the layout of the page, I'm not opposed to it. However, I would feel much more comfortable if there were a heading like "Advertisement" above it. -- Amy (Ajcrow) 19:43, 3 August 2011 (EDT)

And I forgot to mention that there is nothing that identifies the company which I also find to be a problem. But, like Amy, I do not object to having ads. Just that people should be able to recognize them as such. --Judy (jlanoux) 19:48, 3 August 2011 (EDT)

I, too, would want to see a display frame or something with "ADVERTISEMENT" at the top. Also, I note that the image itself doesn't link to the site. I wanted to go and take a look at what they have to offer, but the only way to get there, apparently, is to fill out the form and click "Search." I say "apparently" because it doesn't actually seem to be working. I've tried to run that little search several times in the past couple of hours and keep getting the "can't load the page" alert in the browser. Not very promising. --Mike^Talk 15:45, 4 August 2011 (EDT)

I thought about putting "Advertisement" above it, but then I thought that the graphic nature of the ad screams advertisement anyway. Tomorrow I'll put a small "Advertisement" heading over it just to be clear.--Dallan 01:03, 6 August 2011 (EDT)

From Dallan, WeRelate is terminating the ad for Archives.com.--Beth 21:12, 13 August 2011 (EDT)

WeRelate's relationship with Wikipedia [6 August 2011]

This is probably going to upset a few people but I feel the considered need to vent just a bit: Researching some architectural history today got me to reading about Waddesdon Manor, which took me to the Rothschild Family article at Wikipedia. There are articles there on numerous members of the family. All well and good.

So I got to wondering what we had so far at WeRelate on the more genealogical aspects of the family (thinking I might add material from the numerous published biographies out there), and I found here the article on Mayer Rosthschild. Every word on the page comes from the Wikipedia article. I followed the links to a number of his descendants. Every word on EVERY page is simply sucked up from Wikipedia. There's not a single fact or reference or source on any of these people at WeRelate that doesn't come from Wikipedia.

In effect, the Rothschild material at WR constitutes a mere mirror to the complex of articles at WP, and that's all. It reminds me, frankly, of a 7th Grader copying out an article from World Book and turning it in as his own work. What is the point? Why should we bother? If this is all that WeRelate-ians can provide on the subject, then all that's really needed is a single, very short page titled "Rothschild Family," with the only text on it being "See Wikipedia." And we all know that a similar problem exists on WeRelate with a large number of other individuals who are famous enough to have articles at Wikipedia.

I see discussions at WR all the time about how to inhale most efficiently the work of other people at Wikipedia -- people who are not genealogists and whose motives are not the same as ours, and who are largely anonymous to boot. That puts them in nearly the same category as One World Tree, as far as I'm concerned. Yes, I can see using Wikipedia as one source, but I truly believe some of the folks on WR have developed a nearly idolatrous dependence on Wikipedia to do all their work for them. WeRelate is not and OUGHT NOT to be merely a subsidiary of Wikipedia.

Sorry, friends, but this has been building up in the back of my brain for some time. --Mike^Talk 15:18, 5 August 2011 (EDT)

WeRelate should definitely not be secondary to wikipedia on genealogical matters. My opinion is that wikipedia isn't really even a good source for genealogical information. The specialization of WeRelate really requires a much higher level of proof focused specifically on genealogy than wikipedia readers probably want to read, or than is generally found on wikipedia pages. I am sure genealogy is not what makes wikipedia:Thomas Prence and wikipedia:Mary Walcott worth creating wikipedia pages for, but it would almost be better if the wikipedia authors just didn't dabble in non-essential genealogy, rather than take on challenges some of them are apparently not prepared to handle.

That said, I see how trying to write a narrative for famous historical figures (say, George Washington) would seem a little intimidating to a WeRelate contributor and recognize the value of just being able to leverage a brief bio from wikipedia. Hopefully, though, the WeRelate contributor would still add the specialized genealogical sources and genealogical discussions rarely found on wikipedia (like how the saddle in widow Prence's inventory shows Thomas Prence must have married four times or how the two marriages shown for Mary Walcott are mutually exclusive). --Jrich 17:03, 5 August 2011 (EDT)

I agree. I prefer to use the moreinfo wikipedia template (which just adds a link to Wikipedia) rather than the template that pulls over the actual content. However, on more than one page, I've had people change the template because there wasn't any other text on the page. There were several facts/events, but nothing in the free-text field. That apparently was their criteria for using the full template rather than just moreinfo. Personally, I don't see why not having any other free text on the page rules out using the moreinfo template. -- Amy (Ajcrow) 17:33, 5 August 2011 (EDT)

I agree completely! I will also add that I dislike the requirement of titling pages exactly as they appear in the English Wikipedia. If we are going to insist on keeping this policy, then I would suggest that we consider using the localized version of WP instead. Having pages with titles like so-and-so of the Netherlands makes WR look plain silly. I have also been replacing the WP text from Netherlands place pages with the moreinfo template as I edit them. I would much rather see a sparse page with specific genealogy-related resources on a place then a page filled with WP text. --Jennifer (JBS66) 17:50, 5 August 2011 (EDT)

I do not feel there is any benefit in titling identically. Each resource has distinct page titling policies and we should do what works best in the local context. (anyone who has notions on how to achieve a semantic web relationship between Wikipedia and WeRelate ... drop me an email or a post on my talk page. I work in the semantic framework space at my employer, albeit in the policy, requirements and informatics domain rather than the IT coding domain). --ceyockey 18:56, 5 August 2011 (EDT)

The benefit in titling after WP is two-fold. First, it sets a rule so we don't have to. For example, I just checked a bunch of English kings, and all have at least three names - their King title, their house, and usually a nickname. Which should be the title? When do we use a comma, the word "of", England v. Great Britain (and every other variation in place name or spelling), duke v. earl when one is both, etc., etc. We could have an endless debate about this minutiae and still not cover all the cases, and we'd have a long list of rules someone would have to consult to name a page. Second, and the reason the rule was originally adopted, was that in the massive effort to clean up the royal/medieval space, a firm rule made it possible to easily link pages together. For example, when cleaning up a page for Edward III, one could enter the names of all of his children per Wikipedia, and they would either show up immediately or as they were cleaned up, without having to search the database for whatever name was used by the person who uploaded the page. This is still true for projects like succession boxes, allowing the names of preceding/succeeding monarchs to be clearly and quickly determined. So using WP's policies is best for us, at least in the pre-surname context.--Amelia 19:33, 5 August 2011 (EDT)

Well reasoned. Thanks for the historical perspective. --ceyockey 20:07, 5 August 2011 (EDT)

The template which brings content over from Wikipedia only brings over the introductory content, that which appears before the first heading. If there are articles which expound everything without nary a heading, then it is perfectly within our editorial remit to revise the Wikipedia article so that the introduction brought over is, in fact, an introduction and not a treatise. Our relationship with Wikipedia should be one of mutual enhancement rather than hoovering to create a mirror on which to build. P.S. I might have a skewed perspective as I'm an admin on Wikipedia and a contributor here, while most people here are, I think, not prone to much editing on Wikipedia (tell me I'm wrong if I am - thanks). --ceyockey 18:45, 5 August 2011 (EDT)

Hiya, Courtland---

I've been contributing on Wikipedia for eight or nine years -- not always heavily but steadily -- in everything from writing the original articles on Chili & various Civil War generals from Texas, to adding paragraphs in the histories of Venice & Baton Rouge, to large amounts of rewrite on articles I happen to read in order to make them more coherent. I'm a librarian & editor as well as an historian, so all of that is automatic for me. (In fact, I'm constitutionally incapable of resisting it.) As noted above, though, what I object to is not using Wikipedia as a source but kow-towing to it as either the only source we need bother with, or as the preeminent possible source -- which it isn't, and certainly not in genealogical matters. We're the experts in that regard, not them. (And by "we," I mean the serious contributors on WeRelate, not the drive-by GEDCOMers.) As for "mutual enhancement": How many regular contributors on Wikipedia do you think are even aware of the existence of WeRelate? Many of the authors of history articles there (the ones I've discussed this with) seem to sneer at genealogy as a hobby for those interested only in collecting royal ancestors whom they can brag on. They obviously don't understand what we're up to. (And I suspect many of them are pretty young and have been trained to think this way by their professors.) In any case, I'm strongly of the opinion that there's a great deal more that WeRelate can do (in theory) to inform Wikipedia in the field of family history than the reverse. --Mike^Talk 05:38, 6 August 2011 (EDT)

I used to have similar reservations. But now I frequently add WP templates and find them useful for several reasons:

1. Just as WP editors aren't very good at genealogy, many WR contributors aren't very good at history. I've seen many WR articles on historically notable people like presidents where there is only a note that they grew up in X town. Or maybe paragraphs and paragraphs copied from six different sources that haven't been synthesized, and you can't tell without reading carefully that the person was a governor and senator. The introductory paragraphs from the WP articles identify the person's notability to history immediately and succinctly. While one could take the time to read the WP articles and all the sources it cites and craft one's own summary, that's a lot of unnecessary work. (And I'll probably get slammed for saying so, but I trust the WP article on George Washington, which has been viewed probably millions of times and edited by hundreds of people, over anything any of us could come up with.)
2. The WP templates import not only the text, but also the links to other pages found on WeRelate. The intros typically mention notable family and associates. I've found this a fun way to just stumble around WR, from so-and-so governor to his brother-in-law the senator to his niece the abolitionist. This function is lost with the moreinfo template unless you do a lot of additional work.
3. WP is much better sourced than the typical WR page, particularly older noble and royal pages. Most WR gedcoms containing those pages are a mess of Ancestry/web nonsense, and WP provides a framework to make sense of it all. Then once cleaned up, it's available to catch further gedcoms. It's far faster - 10s of thousands of pages have been done already - than researching every one by hand. (These are the pages mentioned by Mike that are now pages with only WP content. The pages were probably originally a mess (or these are pages added to connect such pages.) Deleting them as "pointless" would just have the void filled by junk the next gedcom down the line.

Yes, theoretically we could have pages that are better and more genealogically focused than WP. Anyone who wants to improve on them should do so. But using the WP templates allows us to very quickly leverage a tremendous amount of work that has already been done. Let's not make the perfect the enemy of the good.--Amelia 19:33, 5 August 2011 (EDT)

On the topic of anthroponymy and biography [6 August 2011]

I am a member of Wikiproject Anthroponymy over on Wikipedia and I have been adding wikipedia templates to surname articles over here. My question - where do you think that anthroponymy (the study of name origins and evolution) should reside ... in a genealogical resource or in a general encyclopedia, as is Wikipedia. I am all in favor of a deeper collaborative relationship between Wikiproject Anthroponymy and WeRelate than simply an us-and-them conjunction. There is likewise an opportunity to interact more closely with Wikiproject Biography based on shared interests. --ceyockey 18:52, 5 August 2011 (EDT)

I'm open to the idea. Do you have any thoughts on things that could be done together?--Dallan 01:10, 6 August 2011 (EDT)

That's very interesting. I've dabbled in anthroponomastics over the years, mostly from being a librarian, and I used to spend way too much time browsing in Hanks's Dictionary of Surnames. (Anyone working the ref desk regularly gets that school report question, "What does my name mean and where did it come from?") And I've worked quite a bit on the origins of Gastineau, Frakes, & Winstead in my own family as a means to localizing the origins of actual family members. So the subject obviously is useful as a genealogical tool -- but I'm not sure what application the broader (academic) subject would have on WeRelate. I have a particular interest in prosopography myself, and I'm applying the methods genealogically where they work, as in the Red River Project I started a while back. But, after considering it, I decided it wouldn't be especially useful to expound on the subject itself at WeRelate. Not to say I might not change my mind about that. I'd be very interested to hear what you might have in mind. --Mike^Talk 06:02, 6 August 2011 (EDT)

Surname help [10 August 2011]

Hi, I need some help from y'all. I would like to create a page for the family of Anna Caldham and a Pawflyn. I can't find any reference anywhere to a surname of Pawflyn. Maybe a bad scan result. There are many Pawflyn's in this text. See this book: [2]

What is this surname? Thanks. --Beth 19:40, 9 August 2011 (EDT)

I'm not sure this is what you are looking for, but could it be Flemish? Or a corruption of a Flemish name? (With variant English spellings Pauflin, Pawflym, etc.) There were no similar names on Free BMD between 1838 and 1900, but according to Wikipedia, Braintree (basically the other end of the street, according to GenUki) had a large influx of Flemish weavers in the 1600s.--GayelKnott 20:47, 9 August 2011 (EDT)

Hi Gayle, I actually found an image of the original. Now if you can just interpret this for me. The link is here [3] and is in the last column for August 1635. I just don't believe that Pawflyn is correct. Thanks. --Beth 20:52, 9 August 2011 (EDT)

In the English script of that era a prominent "f" descending below the line in the interior of a word was actually an "s" like today's "integral" symbol which was shorthand for summation.

For example see the Declaration of Independence where is says "in Congrefs".--Jhamstra 21:10, 9 August 2011 (EDT)

This book doesn't appear to use long s. Google has hits for Pawflyn in Essex. Why wouldn't you think that is the name? You didn't provide the page so I can't check your specific entry. --Judy (jlanoux) 21:41, 9 August 2011 (EDT)

Hi Judy, I did provide the link to the digital image of the original entry; maybe you are referring to the link for the long s which is generally a backwards f. I guess it could be the true surname but if so I guess it died in Essex because I cannot find it on any surname list or any other references to it. Thanks --Beth 22:04, 9 August 2011 (EDT)

Click on [3] in Beth's previous comment to see the original which is what I looked at.

I am not saying this must be long-s, only that the possibility should be considered.

I have seen a number of transcription errors from old handwriting because the transcriber did not carefully study the script/calligraphy style of the writer.

Admittedly script is not always easy to decipher which is why I consider multiple possibilities.--Jhamstra 22:05, 9 August 2011 (EDT)

---

17th Century English handwriting is definitely not my best thing, but I'm inclined to suspect Jhamstra may be right. The "fly" ending to the surname (I'm looking at the left-hand column, October 3, Gulielms P__fly & Maria) doesn't look like any long s I'm used to, but if you look across the column on the original to Robertus Tayler and (what looks like) Joma Hamserfly (married 8 April 1634), that has been transcribed as Robertus Tayler and Jana Hamsersly (p. 216 of the transcription). Why the transcriber would treat one character as an f and an apparently identical character (unless I'm missing something) as an s, I don't know. Unless he was going on "local knowledge" of what the names "should be." And Judy is right, there are Pawflyns in Essex in the late 1500s, John Pawflyn, for example.--GayelKnott 02:34, 10 August 2011 (EDT)

Adding to the consensus... I would transcribe it as “Gulielms Pawflyn et Anna Caldam nupti 11.” —Moverton 03:48, 10 August 2011 (EDT)

Help design our new familytree widget [19 August 2011]

We're about a week away from having a new family tree widget for person and family pages. Every person and family page will get a family tree link, and when you click on the link this widget will slide down on the page.

This widget will eventually replace the "Family tree explorer" and the pedigree portion of "Pedi-Maps". Don't worry - I won't get rid of the Family tree explorer until I've also developed an alternative way to list everyone in your tree

If we were a commercial website we'd have a team of graphic designers to design the new family tree widget. Since we're not, you get to help design it (all the better I think).

Here's an example:

werelate.org/w/familytree.html?id=Person:Augustine Washington (1)

Feel free to replace the part of the URL after the id= with the title of any person or family page if you want to look at someone else.

Here's what you can do with the tree:

• click on "+" nodes to expand families, or "-" nodes to contract them
• drag the mouse over the background to move (pan) the tree
• use the zoom wheel on your mouse to zoom in and out
• click on person nodes to go to those pages
• hover over person or family nodes to see more information about them, and click on names in the popup boxes to go to those pages

Here's what's planned for late this week:

• map controls like google maps has for panning and zooming
• when displaying a tree for a family, show the marriage date and place in the root node instead of "-"
• better styling of tree nodes and popup boxes

Here's what you can do:

• test the widget in different browsers and let me know if there are browsers it doesn't work in
• give feedback on any changes you'd like to see in the tree nodes and popup boxes -- additional information, different colors, etc.
• if you have a bit of artist in you, draw what you think an ideal tree node or popup box should look like and upload it on the internet somewhere so we can all see it. If you upload it here, you can refer to it using a "[[Media:...]]" link instead of an "[[Image:...]] link and we'll be able to click on the link to see your drawing without it showing up as an image in your comments.

For the technically-inclined, this widget is based upon the excellent Javascript InfoVis Toolkit and uses popup boxes from Poshytip.

I'm hoping to gather feedback over the next several days and add this to person and family pages early next week.--Dallan 16:14, 10 August 2011 (EDT)

Very nice! I have two thoughts on possible improvements. I would like to see the tree display more generations initially. Also, there is a quirky bug with cousins who married. One example is this page. Is it possible to repeat the family rather than grouping them together? --Jennifer (JBS66) 17:36, 10 August 2011 (EDT)

I can have the tree display another generation initially - would others like that as well? I'll fix the bug when cousins marry sometime tomorrow

I'm afraid when I click on Augie's link, I get only a blank screen, after several attempts. . . . --Mike^Talk 21:13, 10 August 2011 (EDT)

I just fixed a bug that could have caused a blank screen in some browsers. Could you please clear your browser's cache and let me know if it's still a problem?--Dallan 22:14, 10 August 2011 (EDT)

Okay, NOW it works. --Mike^Talk 10:40, 11 August 2011 (EDT)

Overall, it looks good. I looked at in Chrome, Firefox and Safari and didn't see any obvious browser-related quirks. I agree with Jennifer -- at least one more generation should be shown from the start. (I think 2 generations would be even better if you could get them to fit.) The delay on the pop-up info box could be a breath shorter. In that pop-up box, would it be possible to list the place of birth and place of death along with the dates?

Something else that might be nice as an enhancement later on would be the ability to navigate through both ancestors and descendants. For example, if you look at the tree for Ann Stevens, you can click on the + to the left of her box and get all of her children. It would be nice to have the ability to show all of the children of David and Rebecca (Dickinson) Stevens. It certainly isn't a deal-breaker, but it would be nice to have at some point. -- Amy (Ajcrow) 08:06, 11 August 2011 (EDT)

Once the target is specified, the descendants are always descendants and the ancestors are always ancestors, even though you move around. So the ancestors show the spouse, but the descendants and target don't (except in the popup). If the target is a person of interest, one may certainly want to browse back through their spouse's tree? Or they have multiple wives and have two plus signs to the right, but even when you descend into the children of one of those families, the spouse never shows up (except in the popup).

The display appears a little confused when cousins marry. Example . --Jrich 09:19, 11 August 2011 (EDT)

First reactions:

1. I agree, you could start with more generations. There appears to be plenty of horizontal room for 4 or 5, even with the WR frame eventually added around it.
2. Hovering over a plus sign on the left shows that person's spouse & kiddies, which makes sense. However, hovering over a plus sign on the right shows that person's parents & siblings, which I guess seems counterintuitive. Not what I was expecting, anyway.
3. It might be nice to display the birth/death dates in each person's box; after you've done some surfing up and down the generations in a tree, it can be difficult to remember where exactly you've stopped -- especially if there are a number of "Sr." & "Jr." listings.
4. I'm not a graphics designer and I can't draw a better node -- however: It's all awfully pale and awfully blue. I would recommend a darker color for the outline of the box, like black or dark blue. And I would recommend a darker and more contrasty color for the connecting lines, like maybe Chinese red. (Also, I personally would make the connecting lines turn square corners instead of using curved braces, but that's probably just me. I don't like curved connectors on charts -- they make it harder to scan across, in my opinion.)
5. Do you have in mind some way (eventually) to print out this sort of chart? WYSIWYG or otherwise? --Mike^Talk 10:40, 11 August 2011 (EDT)

Thank-you for your comments! Today I added the map controls. Tomorrow I'll:

• add another generation. I initially started with 3 generations so that the tree would load fairly quickly - the system has to read roughly 15 person/family pages to load the tree. Adding another generation increases this number to 31; adding two more generations would increase it to 63. Let's go with 4 generations, so 31 pages to display the initial tree.
• shorten the popup delay -- Should I shorten it for Family pages too? I was actually thinking about increasing it for family pages a bit since the family popup tends to get in the way when I click on the family nodes to expand them
• add places to the events in the popup boxes
• regarding showing descendants of individuals other than the "root" individual, you can see all of the children of David and Rebecca by hovering over their family node, but I'm thinking you meant you want to see all descendants. One way to see all of David and Rebecca's descendants would be to control-click on the "Family" link in their popup window, then view the family tree widget on their Family page, but that's a bit inconvenient. Another possibility is if you double-clicked on a node, that node would become the new "root" node for the tree. If you wanted to see the ancestors of a spouse for example, you would start by double-clicking on the family node for that spouse. A tree could have only one "root" node (a node with both ancestors and descendants) at a time, but you could change which node was the root by double-clicking. Would that fill the need?
• fix the "when cousins marry" bug
• think of the plus sign on the left as the spouse family; the plus sign on the right as the parent family. I don't know if that helps.
• add year-ranges to the boxes
• see if I can draw straight lines instead of curved
• I'm not a graphic designer either. I haven't spent any time tweaking the colors; I'm hoping that someone with good ideas in this area will post a screenshot. Otherwise I'll do what I can on Monday.
• I'll see what I can do about printing, but it would likely just be printing a screenshot of the nodes displayed on the screen. Is that sufficient?

--Dallan 00:54, 12 August 2011 (EDT)

Something unexpected came up on Friday so I wasn't able to post an update, but I posted one today. It has everything listed earlier with the following differences:

• I shortened the popup delay for people but lengthened it a bit for families.
• I added a "Set as root" link to the popup windows instead of double-clicking.
• I fixed a bug that occurred when you resized the page.
• I'll work on the color and hooking the tree into the Person/Family pages tomorrow.
• It's possible to print the tree using the browser's print function in Chrome, Firefox, and IE8. Sometime soon (but probably not tomorrow) I'll add a function to open the tree in a tab all by itself, which will result in a nicer print-out.
• I added an "Open in new window" link to the popup windows. Tomorrow I'll change this to "Open in new tab", since it appears from the table below that most browsers open the page in a new tab (thank you!). I'll also try to figure out what's going on with IE7.

--Dallan 00:57, 16 August 2011 (EDT)

I much prefer the squared lines, nice! I agree with Mike that having the boxes outlined in black would be preferable to blue. Also, as you zoom in and out, the birth and death years move from next to the name to below the name. Is it possible to keep the dates consistently on the second line? The boxes may need to be a bit wider to accommodate more of the person's full name. --Jennifer (JBS66) 08:32, 17 August 2011 (EDT)

I'm having that problem even without zooming in and out. When I open the tree, some boxes have the date below the name and some boxes have the dates starting on the same line as the name. For readability, I think having all of the dates starting on a second line would be preferable. -- Amy (Ajcrow) 09:48, 17 August 2011 (EDT)

When I Right click on the "open in new tab" link from the box that pops up when hovering over a name, and I choose "open link in new tab", the Family Tree opens in a new tab instead of the Person/Family page. If I simply click the "open in new tab" link, or CTRL click on it, the Person/Family pages opens correctly.

Using Chrome, when I first open a Family Tree, the invisible "wall" still appears sometimes. If I close the tree and reopen it, it works ok.

When pressing minus to remove a listing of children, nothing happens (for example Family:Jouke Miedema and Foekjen Kampen (1), pressing the leftmost minus to remove the 7 children does not work).

As for fitting the dates into the boxes, I would be curious to see how making the name 1 pixel smaller looks. Also, might it save some horizontal space to make the plus/minus signs and the gap between them and the adjacent lines a bit smaller? --Jennifer (JBS66) 11:08, 19 August 2011 (EDT)

Browser compatibility [18 August 2011]

please feel free to add more instances to this section; the null hypothesis is that "all's OK" or "all is as expected"; only exceptions from null are noted

This is quite nice, Dallan. Thank you.

• I ran into a situation I can't reproduce where I was able to "minus" my way all the way down to just a "plus" with not person shown. Wish I could reproduce it, but maybe someone else can come up with this.
• It would be useful to provide a "re-link at root" function which would provide a URL for the root at which you are now. As it is, the URL you start with will not change due to this being a Javascript action series. This means that you could get quite far away from your starting point and would potentially like to "save your place" by grabbing the URL for the present root. I do not think that providing that current-root-url need be a default, but rather a link in the margin or corner entitled "now-root-link" akin to "permalink" in the OpenStreetMap and OpenStreetBrowser interfaces would be sufficient.
• In some future iteration, it might be useful to consider a set of layers or overlays which could cover things like place-of-birth, place-of-death, occupation, supporting evidence, etc. If you can establish a framework which would be sufficiently flexible to be able to overlay just about any type of information, that would be massive.

--ceyockey 00:21, 16 August 2011 (EDT)

It used to be the case that you could get a "plus" all by itself by setting the root to a family page, then clicking on the family page to close it. I thought I had stopped that from happening; I'll check into it tomorrow to see if I can reproduce it.

When you say "re-link at root," do you mean a link that would take you back to the original root that you started with? If so, would it make sense for the "home" button in the map controls to reset to the original root? Or do you mean being able to get a link for the person who is the current root? If so, couldn't you get this by opening the current root in a new tab?

By overlays, do you mean allowing people to select what types of events and sources to include in the popup windows? That may not be all that difficult actually. I'd be happy to talk more about this if people are interested.

--Dallan 00:57, 16 August 2011 (EDT)

I'm having only one small problem. There is a line across the screen about 1/4 from the bottom. When I push the tree around, it acts like it is sliding behind a wall. The bottom quarter of the screen stays blank. Firefox 3.6.18 under Windows Vista. --Judy (jlanoux) 12:36, 17 August 2011 (EDT)

In Firefox the decision of whether to open a "new window" spawned from an existing page as a new window or a new tab in the existing is controlled by a user option. The default is that it opens as a new tab.

The Firefox behavior should be the same for Versions 3, 4 and 5.--Jhamstra 14:28, 17 August 2011 (EDT)

So now the new tree widget appears but there are several inconsistencies.

It seems to have broken the display of children and sibling relationships in the right-hand side of the window.

Examples:

[4] shows two sons but [5] and [6] do not show the sibling Joseph [7] under Parents and Siblings. Likewise [8] does not show the son Joseph [9] under Spouse and Children.

[10] shows the son Joseph [11] however [12] does not show son Joseph [13] under Spouse and Children.

Some of these Josephs do not show up in the tree display depending on where you start.

Note that there are four successive generations of Joseph Mixers in a correctly formed tree.--Jhamstra 14:44, 17 August 2011 (EDT)

It seems to be working for me. Possibly you used the back arrow and are looking at a cached version of the page? I do that a lot and wonder why my changes aren't showing up. Try refresh and see if it helps. --Jrich 16:34, 17 August 2011 (EDT)

I have hit Refresh many times - opened in new tabs, etc.

I will try logging out of WeRelate and closing my tabs.--Jhamstra 17:30, 17 August 2011 (EDT)

I'm seeing it too. It was looking OK when I go to the page directly from your link, but then I open the family tree, and then close the family tree, and I start getting missing information when I go back to the page. In one example, I had the same page up in side by side tabs, and they were displaying with different information: One had the spouse and children, but the parents were missing, in the next one the parents were there with no children, but a spouse and children block was there displaying the husband even though he wasn't listed in his proper place in the parents block. weird. --Jrich 19:40, 17 August 2011 (EDT)

Thank-you for pointing out the caching bug! That could have been difficult to track down, but the URLs you gave really helped. I believe I've fixed it now. I hope I've also fixed the bug with the bottom 1/4 of the screen being blank. I've been unable to repeat it myself, but I think I know what was going on and I've fixed that. I've also fixed a problem where control-clicks didn't open links in new tabs. Also, if you're displaying a tree for someone, edit one of their ancestors in another tab, and you want the tree to reflect the changes you just made, you just have to close (click on the Family tree link again) and re-open the tree.

I've moved the year-range to a separate line. If the name is too long to fit on one line, the year-range doesn't show up in the box now unless you zoom in a bit. We can do one of four things at this point:

1. Decrease the font-size for the names by 1 pixel; this will allow most names to fit on one line. This works for me, but my eyesight is still pretty good.
2. Increase the length of the boxes. This means that 4 generations won't quite fit anymore on a 1024 pixel screen.
3. Don't force the year-range to be on a separate line (put it back the way it was).
4. Leave things the way they are; if people want to see the year-ranges for people with long names they can always zoom in a bit.

Thoughts? Also, based upon a comment above, would people rather that the boxes (and lines?) be black, as opposed to the current blue and pink?--Dallan 13:44, 18 August 2011 (EDT)

• The bottom quarter display problem is fixed. Thanks.
• I hated the pink and blue boxes when the old family tree maker invented them, but here they are light and not filled with pink and are unoffensive so I don't mind. If the lines were black, it might make it clearer that the names are links. But then the dates would blend in with the lines. Don't really have any preference so far.
• Positive comment: it's FAST! good performance makes it fun to use. I love being able to open all the +s and push the tree around to study various parts and plan research targets. This is the only place I have ever been able to do this. I like being able to open a Person in a new window.
• One problem had me puzzled. Person:Katherine Dednam (1) has a + but don't get anything when I click it. Thought something was broken. But when I went to the parent family page, I see that her parents don't have Person pages. So I assume that the + indicates the existence of a parent family page, but only parents with pages show up on the tree. Don't know if this needs fixing or just documenting.

--Judy (jlanoux) 14:12, 18 August 2011 (EDT)

I just had an issue where the bottom half or so of the family tree box was blank - if I moved the tree around I could see it, but any parts below that artificial line disappeared. It happened when I was clicking around the generations with the + and - and now I can't recreate.

A more concrete issue: if the person has a chr. date instead of a birth date, the chr date shows up in the popups as "b. <date>".--Amelia 14:07, 18 August 2011 (EDT)

I was also getting the invisible "wall" in Firefox 4.0 but it seems to be fixed now.--Jhamstra 11:13, 19 August 2011 (EDT)

I think I've addressed all of the issues that have been reported:

• I was able to reproduce the invisible wall and I believe I've fixed it. At least I can't get it to show up on my machine anymore.
• chr is used as the label if the birth line comes from a christening event; likewise, bur is used as the label for death line from a burial event.
• If you right-click on the "Open in new tab" link and select "Open in new tab", it opens in a new tab.
• I've decreased the space between the boxes a bit, increased the width of the boxes a bit, and decreased the font size for the name by 1 pixel. The names are more likely to fit on one line now so you see the year-ranges more often. Let me know if the decreased font size makes reading the names uncomfortable.
• When you're looking at a family, you can't click on the family node to hide the children. Since the family is the "root" node in this case, clicking on it would hide the parents as well and you'd be left with just a "+" on the screen, which is not what you want. Changing this behavior would be fairly difficult, so I've changed the root family node to display as a "dot" to indicate that you can't click on it.
• I've changed families without parents to also display as a dot so you can't click on them.

--Dallan 16:28, 19 August 2011 (EDT)

Trees and copying trees to user page to prevent deletion [15 August 2011]

I need clarification. It was my understanding if I copied a tree; the user who initiated the tree could not delete the tree. Because all of the pages in the tree that I copied disappeared, I assume that my assumption was incorrect. --Beth 20:53, 13 August 2011 (EDT)

Any pages you were watching should not have disappeared. I'm not sure if tree copy adds the pages to your watch list. I use build-a-tree rather than copying someone else's tree in entirety. This does add them to my watch list. By build-a-tree I mean using the tree link from a Person page and adding ancestors or descendants. --Judy (jlanoux) 14:10, 14 August 2011 (EDT)

Copying a tree should add the pages to your watchlist.--Dallan 00:57, 16 August 2011 (EDT)

Gedcom deletion impact [15 August 2011]

Recently a gedcom upload connected to some of my watched pages. The user deleted the gedcom the next day to clean up some of the problems in their genie program. The gedcom deletion left certain items on my watched pages. Is this the planned result? Alternate dates still remain and the MySource was in red on the page before I deleted the My Source. The child added to a page was deleted but I guess the child is floating around somewhere in red letters. --Beth 21:27, 13 August 2011 (EDT)

This seems related to the last question. The user can remove pages that no one is watching. In the case you describe, he edited your existing page. Removing a tree or gedcom does not remove every edit a person has done. Edit includes merging data from the Family Match screen. --Judy (jlanoux) 14:12, 14 August 2011 (EDT)

If the person page for a child was deleted, but the link from the family page to the person page for the child turned red instead of being deleted, I'd like to know about it. The links to the deleted child should have been removed as well.--Dallan 00:57, 16 August 2011 (EDT)

Welcome, new users! [22 August 2011]

This past Saturday, Sunday and Monday (August 13-15) saw a 100% increase in the number of new users over the previous Saturday-Monday (Aug. 6-8). Welcome, new users! Look around, explore, ask questions. We're a friendly bunch here! We believe collaboration is the best way to solve genealogical problems and to share our findings. --Amy (Ajcrow) 12:26, 17 August 2011 (EDT)

On all the message boards I am on I say "Please meet me at WeRelate.org to collaborate on this person". Then I include a url. 100%? Woo-hoo! That's fantastic! --cthrnvl 19:46, 22 August 2011 (EDT)

Search was down today [23 August 2011]

Due to a lapse in judgement on my part, search was down today for 30-60 minutes. I apologize for any problems this caused. I believe that everything has been fixed. If you notice something that is still not working, please let me know.--Dallan 21:07, 23 August 2011 (EDT)

source vs repository [27 August 2011]

While looking for help with sources, I ran onto this Source:Allen_County_Public_Library The writeup is very good - but shouldn't this be a repository and not a source?--Janiejac 12:44, 27 August 2011 (EDT)

Yes. It was written far before we had repositories and I guess wasn't caught in the source project. I'll rename it.--Amelia 12:51, 27 August 2011 (EDT)

There is another Repository page for the Allen County Public Library: Repository:Allen County Public Library, Fort Wayne, Indiana. --Jennifer (JBS66) 12:56, 27 August 2011 (EDT)

Almost identical, thankfully. Combined and the source one redirected.--Amelia 13:06, 27 August 2011 (EDT)

The one Jennifer mentioned is the most current version. --Amy (Ajcrow) 13:08, 27 August 2011 (EDT)

FGS Conference in Springfield, IL [1 September 2011]

Any WeRelate users going to be at the Federation of Genealogical Societies' conference next week? If so, would you like to arrange for a GenSpiration session? -- Amy (Ajcrow) 18:06, 30 August 2011 (EDT)

The Program has been published online @ http://www.fgs.org/2011conference/program/ ... maybe one or more WeRelate contributors are speakers? --ceyockey 23:40, 31 August 2011 (EDT)

I'm a speaker (Wednesday: "Finding and Keeping Volunteers" and "Building an Effective Society Website." Friday: "After Mustering Out: Researching Civil War Veterans." Not sure about other contributors -- sometimes the screen name doesn't translate to the real name :-) -- Amy (Ajcrow) 07:32, 1 September 2011 (EDT)

creating category pgs [17 September 2011]

There is a 'red' category with one person in it. When I click on the category, it tells me "There is currently no text in this page. To create the page, click on the Edit link at the left." OK ... but I don't have anything to say or type about the category; I just want the page to be created. It has one person in it and will have others. I guess I could just leave it alone, but this kind of small puzzlement causes folks say they don't understand this site. --Janiejac 15:05, 2 September 2011 (EDT)

As you noticed, just adding a category link on a page doesn't create the category. Any text that you add to that page will "create" the category and any pages with that link will start to appear there.

One thing to remember, however, is that a category page should be nested into a larger category. For example, I add a lot of category links to cemetery pages, such as "Category:Cemeteries of Fairfield, Ohio, United States". If the text is red, I'll click the link and on the new page I'll add the link to the parent category; in my example, it would be [[Category:Cemeteries of Ohio, United States]]. That's all the text I needed to add. -- Amy (Ajcrow) 16:23, 2 September 2011 (EDT)

The interesting thing about red-link categories is that they do function as partially implemented categories, meaning that multiple pages can be grouped via the category without bringing the category into existence by adding text to the page. This is an advantage, in that categorization can take place without instantiating the category, and a disadvantage, in that there are many categories that have multiples pages in them but have not been instantiated. This is one reason that I create surname categories on site by placing them in Category:Surnames; some late-made categories have had several dozens of pages mapped into them due to the auto-categorization functions which are active. --ceyockey 18:57, 2 September 2011 (EDT)

Hmph! I learned how to 'create' a category turning the red category into blue! Click 'edit', and put one period in the text box. Mark it a minor edit and save. The period does not show on the category page. Don't forget to remove the ck mark on 'watch this page' or you'll be watching more than you want!

However nobody should do this. If you aren't going to take the time to set it up properly (putting it in the proper parent category), then don't bother. Having a red category link isn't the end of the world.  ;) --Moverton 18:59, 6 September 2011 (EDT)

I agree with Moverton. Making a category page by adding random text just so the link won't be red does a disservice if that category is supposed to be in a structure. For example, if I see a Civil War category with a red link, I know it hasn't been created, so I go in and create it within the structure it's supposed to be in. OTOH, if the link is blue, I'll probably skip right over it, as I don't have the time to check that each Civil War category was created in the right place. By just adding random text, that category page isn't going to be in the structure where it would be the most useful to researchers. -- Amy (Ajcrow) 07:29, 17 September 2011 (EDT)

Tables or wikitable formatting in source text [8 September 2011]

Hello - does the table / wikitable formatting only work in the main body of a page? I wanted to include some in the "text / transcript location" box in a source citation and it didn't like it, but it has worked cutting the exact same script and pasting it instead onto the main body of the page. See Family:Joseph Palmer and Elizabeth Marriottt (1) - I'd really wanted the table to go under the reference. Any ideas? Thanks.--RichardK 12:54, 7 September 2011 (EDT)

I've struggled getting formatting to work in those boxes; some work-arounds are needed unfortunately. First, instead of using wiki formatting, HTML formatting works better. Second, the table cells need to be left-padded in Chrome, so you need to add a "citation-fix" class to the table. Try something like:

<table class="wikitable citation-fix">
<tr><td>cell 1</td><td>cell 2</td></tr>
</table>

Someday I'll re-visit the boxes to see if I can improve things. In the meantime, let me know if you run into any problems using HTML there.--Dallan 14:48, 7 September 2011 (EDT)

Thanks Dallan - that seems to have got tables working in the boxes, although some stray coding text appears after the table which I can't seem to remove - see Family: Alfred Edwards and Caroline Palmer (1)--RichardK 16:57, 7 September 2011 (EDT)

It works now. I added closing td and tr tags to get rid of the stray coding text, and I also removed all line breaks (carriage returns) to get rid of some extra vertical space at the top of the table. I know it's really odd that you'd need to do this. I'm using the references plugin from Wikipedia in a non-standard way, and it and I have been fighting about citation formatting for awhile now :-). At some point I'll probably need to rewrite it.--Dallan 17:36, 7 September 2011 (EDT)

Thanks Dallan - that's great. Many thanks.--RichardK 01:32, 8 September 2011 (EDT)

place names and cemetery pgs [9 September 2011]

There is a Mount Croghan, Chesterfiled, South Carolina. This place can be found by searching for "Mt. Croghan, Chesterfield, South Carolina" because that is given as an ALT place. Why can't I create a cemetery page in Mt. Croghan, Chesterfield, South Carolina? The system insisted it didn't have a place Mt. Croghan and I had to leave the cemetery page uncreated. --Janiejac 20:50, 7 September 2011 (EDT)

Sorry - the system requires you to use the title of the place instead of an alternate name when naming subordinate places. So you could create Cemetery name, Mount Croghan, Chesterfield, South Carolina, United States using Mount, not Mt.--Dallan 19:06, 9 September 2011 (EDT)

General Site and Wiki advice [16 September 2011]

Please be gentle as I am dipping my toes into Wiki waters for the first time and it is very definitely a whole new world for me; I admit I thought understanding would dawn a little sooner seeing as I am an IT Specialist. Your Help section is great and doing its job well however I am finding that useful advice from Admins / Users can be hidden away in response threads ten-miles deep. Is there currently a way to tag a topic (or article, excuse me while I get used to the terminology) as containing within it some very useful advice? Or a Bash.org equivalent where useful “stuff” could be copy/pasted as articles and perhaps tagged with topics that it pertains to? Cheers--Wongers 22:10, 7 September 2011 (EDT)

Well, the general Help and FAQ are pretty extensive. Beyond that don't forget about the Sandbox for testing/playing and that you can open any interesting page for editing - simply to see how the layout was done.--jrm03063 23:30, 7 September 2011 (EDT)

Are you thinking about tagging an article just for yourself, in which case, would a bookmarking feature help? Or are you thinking about tagging it for others as well, in which case, would you be up to copying & pasting the useful information onto a more prominent position on a help page, or perhaps adding a link to it? We'd welcome help to improve the help pages.--Dallan 19:18, 9 September 2011 (EDT)

I'm not sure an on-site bookmarking feature would provide much benefit (I can use the browser for this?) although as a usability feature I could see that the idea would have merit for the MyRelate area. I'm up to giving what assistance I can (including jQuery) however I am finding it a bemusing experience to be such a complete novice with something minorly technical (wikis) and feel I need to spend some time "playing" before I start pushing buttons that break things. I can of course copy / paste to Help pages, or add links; I guess that is the obvious answer to my original question (and thanks to Jrm03063 as well).

Ok, after you get more experience with the site, and if you're still interested in helping out technically, please drop me a line.--Dallan 17:59, 16 September 2011 (EDT)

Links to Family Search Images and Source:Ohio, United States. Ohio, County Marriages, 1790-1950 [22 September 2011]

Good morning. I just discovered that the links to the images on Family Search for Source:Ohio, United States. Ohio, County Marriages, 1790-1950 do not work. I suspect this holds true for all of the Family Search Images but I have not tested other images. When you select the link, the Family Search image page says that the image is temporarily unavailable. If you sign in the image is still not available. However, if one goes to the view image page the image is available. I suggest that we link to the view image page in the future.

Also, just in case any of you are sometimes temporarily brain dead like me, I also figured out that some of the Ohio County Marriages' images actually give the birth date for the bride and groom. They say something like the groom was 21 on the 7 Sep 1921 and the bride was 18 on the 18 Jun 1921. The record is showing the age on their last birthday prior to the marriage date. So subtract the age from the year and you have the birth date. Have fun with your research. --Beth 08:51, 13 September 2011 (EDT)

It appears that FamilySearch changed the structure of the URL for the image pages. For example, on Abby Guthrie's page, the link to the image had been in this format. When I clicked on it, I got the "Image not available" message. When I did a search to find the image, I discovered that the URL for the image page is now in new this format. I changed the link on her page and it works just fine. Too bad FamilySearch didn't map the URLs so that they would automatically redirect. -- Amy (Ajcrow) 09:44, 13 September 2011 (EDT)

Thanks Amy for figuring out the change in URLs. Lately I have entered direct links but on previous occasions I entered the general URL for the website. I find broken links annoying. Not sure of the best approach.--Beth 10:39, 13 September 2011 (EDT)

For records found in these FamilySearch databases, I usually create a more explicit reference to the original source (eg. here). Because FamilySearch doesn't appear to be using permanent links the way some sites do, I suggest at the very least including the film number, digital folder number, and page number from the indexed record in your reference here on WeRelate. When you do that, if the link ever breaks, a person can more easily find the image by browsing the appropriate image collection. --Moverton 12:07, 13 September 2011 (EDT)

Well, I repaired the broken links existing for this source only. The Family Search view image page links still worked so I am going to link future citations to the view image page rather than the image page.--Beth 12:35, 13 September 2011 (EDT)

Success with Alt Name Options [23 September 2011]

I just wanted to say that I have been having great success sorting out one family where almost every individual spells their surname differently. I just added every spelling for each individual when I found a grave stone, newspaper article, military papers. Then when I found a new source it was very easy to find the matching person. Which has been nearly impossible to do with 3 X 5 cards! Now I am going to go back and add alt surnames to some of my difficult people, now that I know how useful it is. And I would encourage everyone to remember your alt spellngs even if they seem slight (like Abel/Able). (The family is Abel > Able > Auble > Aubel > Auvil of New Jersey.) Thanks WeRelate crew! --cthrnvl 20:50, 19 September 2011 (EDT)

I always make it a point to add the married name of the wife to her Person page. And although I can do a search for it and have that page returned in the search results, the little summary provided in the search results won't show the matching alternate name, which can make it a little more difficult if I have multiple items returned in the search results. --Moverton 11:21, 20 September 2011 (EDT)

Don't the search results show the spouses of the person? Searching for a family page is always the most likely way to get a focused result, and I assume it also has the benefit of allowing the surnames of both spouses to be processed for alternate spellings as determined by Surname pages, but even if searching for a Person Page, the married name just needs to be put in the keyword field, assuming you have the right spelling. I always assumed that married name was for cases where the married name might have been different than expected, and personally, I have actually been removing the redundant ones that add no information beyond what the spouse listing makes clear, because they are likely to become inconsistent in the event a marriage is ever removed, changed or spellings changed (i.e., delete the wife from a Family page, and insert the correct one, without ever looking at the Person page). --Jrich 13:00, 20 September 2011 (EDT)

What Jrich said. Plus women that marry into families aren't expected to be in the category pages for that family, and that's what adding the married name does.--Amelia 13:08, 20 September 2011 (EDT)

I don't know that any requirement has been spelled out that the "married name" alternate name is reserved for odd exceptions and not to be used when a Family page exists. On the other hand, I wouldn't make it a requirement that people have to add the married name to the Person page. I never use the surname categories, but... If a woman has taken her husband's surname, it can be argued that she should be categorized in the same category as her husband because her maiden name is no longer a part of her actual name, and she is likely only using her married name. All that aside, I try to be thorough and add the names she would have used during her life. And when I am adding references I add a source link to the name that is actually used on the source. (As an example, this person currently has only one reference which is linked to the married name used by it. However, another married name and her maiden name are both known, or rather believed to be correct, though no sources are currently given. Other than needing more sources and info about her other marriage, I consider it to be properly filled out.) --Moverton 17:50, 20 September 2011 (EDT)

If there is no marriage date on a Family page, then that spouse is not listed in the search results. Of course, the right answer is that nobody should create a Family page without at least an estimated marriage date, but that isn't going to happen. So (attn: Dallan) is there anything that be done to fix this? --Jrich 12:40, 22 September 2011 (EDT)

Possibly a better thing to do is to create Surname: pages for each variation, linking all the other alternative spellings on each one. It is okay to list a page's spelling on itself, so this is easier than it sounds. Just build one such page witho all reasonable alternate spelling, including that page's own spelling, then cut and paste the entire list of alternate spellings to all the others. This involves doing it once on a Surname page instead of adding all those alternative spellings on each and every single page with any variation of those names. Helps you and also people that come along later. For example, Surname:Merrick. Givenname: pages work similarly, e.g., Givenname:Mehitable. --Jrich 22:13, 19 September 2011 (EDT)

It might be helpful if we all had a better understanding of how adding surname variants to a Surname page would help in searching for a particular person or alternate family members with a variable surname. I'm also wondering how many variants could be added before the usefulness of a Surname page becomes diluted.--GayelKnott 22:55, 20 September 2011 (EDT)

Dallan has mentioned a couple of times trying to improve searching for similar spellings. So this may change. But if you add alternate spellings under the alternate names section, search should treat finding any of those names the same as finding the title of the page. The entry in the alternate names section is <alternate spelling>|<comment>. Usually the comment after the pipe is some text describing where the alternate name came from. To quote the support page, "You don't need to include misspellings, only the variants that people used." (Pages are supposed to be created with the most common spelling, generally, so misspellings shouldn't be a problem.) I always make the spellings point both ways, so on Surname:Smith, I would add Smyth, and on Surname:Smyth I would add Smith. There may be a lag after editing the Surname pages as changes work their way into the cache. Givenname works the same way. --Jrich 00:28, 21 September 2011 (EDT)

Thanks. I know that adding alternate names on a Person page means that a search will find that person with any spelling in the alternate name section, which is what I understood cthrnvl to be saying. I was just wondering if adding variant forms to the Surname page would also ensure that a search would turn up all variants even if they weren't included in the alternate name section of the Person page.--GayelKnott 02:33, 21 September 2011 (EDT)

It is easy to run a test and convince yourself. For example I search for "William Myrick". Several pages for "William Merrick" are returned because I have previously edited those Surname pages to list this particular alternate spelling combination. I checked a couple of William Merrick pages that were returned and the string Myrick doesn't occur anywhere, not as an alt name, not as the parent name or any of the children, yet this page was still returned. So it works. One detail: you have to do an exact&close match, the exact only match will not find alternate spellings. --Jrich 08:50, 21 September 2011 (EDT)

I just searched for Matthias Able and got Matthias Abel in the returns even though Able is not in his alt names (but is in the Able surname page related names list.) So I am following what you are saying. So, for example, if Joe Abel's (name from birth certificate) name is spelled Able on his gravestone I add "Joe Able" to his alternate names. But if the name Abel is often mis-spelled Aubel I would not add that to Joe's alt names unless I found a primary source using it. "Aubel" mis-spelling would go in the surname Abel "related names" section. Is that how you would handle it? --cthrnvl 10:16, 22 September 2011 (EDT)

Exactly.--Dallan 10:30, 23 September 2011 (EDT)

Can't this too wide screen be fixed? [25 October 2011]

I checked to see if I could figure out what is causing the text to be so wide and didn't see anything I knew how to fix. Can someone else pls try? I notice this same problem on several other pages - even user pages - and can't help but wonder why they are left that way! I know it happens when someone doesn't know and so indents a paragraph or pastes a dif font but what else causes it? For a site that is so exacting, this just doesn't sit right. --Janiejac 12:06, 22 September 2011 (EDT)

What page has the problem? --Judy (jlanoux) 13:33, 22 September 2011 (EDT)

Sorry, my fault. It was this page this topic, I didn't post anything because I thought it would be obvious the problem was fixed [of course, once I fixed it, nothing was obvious any more, doh!]. It was a long URL, but since the structure of the URL seems to be germane to the posting, instead of adding a display alias, I wrapped it in <small>...</small>. Probably too small to read but one can always right click on it and copy the link. --Jrich 13:51, 22 September 2011 (EDT)

But it is still not fixed. Doesn't this bother anybody else? --Janiejac 17:38, 24 October 2011 (EDT)

The page is displaying correctly for me. Are you sure you're looking at the most recent version of the page and that you've refreshed your screen? - Amy (Ajcrow) 17:45, 24 October 2011 (EDT)

Also, if you're looking at the "difference screen" comparing the changes between the historical version of this page with the long lines and the current version, the page will be too wide. But it should be normal-width if you look at the current version of this page.--Dallan 18:12, 24 October 2011 (EDT)

Strange. I hit the refresh and it is still too wide. I have tried Mozilla Firefox 7.0.1 and IE7 v 7.0.5730.11 and get the same results. The scroll bar doesn't even go 1/3 of the way across so I scroll right quite a bit just to get over to the edit button. I'm looking at the regular page, not the dif screen. --Janiejac 20:13, 24 October 2011 (EDT)

I've just edited that topic to put the url's inside links. Hopefully the screen isn't too wide now.--Dallan 16:35, 25 October 2011 (EDT)

Sorry to bother everybody....it's still too wide. I checked the two other computers in this house and this WeRelate page looks fine on the other computers. So it must be something about my computer that hasn't shown up on other sites. I'll have to work on it from this end ????!! If I find out what it is, I'll let you know just in case it comes up with anybody else. --Janiejac 17:43, 25 October 2011 (EDT)

Les Archives Départementales du Bas-Rhin [29 September 2011]

Hello to everyone. Hope you are having fun on WeRelate. I am attempting to improve some of our community pages and need some assistance. I found two records online from Les Archives Départementales du Bas-Rhin that I believe relate to 2 person pages. Need someone to transcribe the records into English. Thanks. --Beth 22:23, 26 September 2011 (EDT)

I use http://translate.google.com for translating text. They're not perfect, but they seem to do a reasonable job.--Dallan 23:13, 29 September 2011 (EDT)

USGS Historical Map Release [29 September 2011]

Apparently the USGS is in the process of scanning their old map collection for distribution via the internet free of charge (for the most part). For more information, see this blog posting at "Mapperz - The Mapping News Blog" → http://mapperz.blogspot.com/2011/08/usgs-historical-map-release.html . --ceyockey 23:34, 29 September 2011 (EDT)

I resized an image! [11 October 2011]

ok, don't laugh - but I was so happy I figured it out all by myself. Actually did a search on the MediaWiki site.

You can see the results here:

User:Dixonge--Dixonge 22:09, 10 October 2011 (EDT)

Possible Wall Street Journal article on WeRelate [16 December 2011]

I spoke with a freelance journalist today doing an article on genealogy for the Wall Street Journal. She seemed to really like the idea of a collaborative website for genealogy.

She'd now like to talk with a couple of users who've had good experiences using WeRelate - collaborating with others, finding new information, etc. She'd like to talk with them sometime over this weekend.

If you're interested in talking with her and have an interesting story to share about using WeRelate, would you please let me know? It could be really good publicity for us. Feel free to leave a message here, on my talk page, or email me directly at dallan at werelate.org.

Thank you!--Dallan 18:14, 10 November 2011 (EST)

That was a great article - I was led here by the article, and I've been taking a look around over the last few hours.

This is great software! I'm very excited to get my trees on here, and to start participating. Jdfoote1 16:33, 2 December 2011 (EST)

Thank you. Welcome to WeRelate!--Dallan 01:10, 3 December 2011 (EST)

Thought it would be appropriate to provide a link for others to read the Dec 1st article, so here is the link to the WSJ article. Was that really an accurate quote of your comments Dallan? --BobC 18:23, 15 December 2011 (EST)

The reporter and I talked for about 20 minutes. Once during the conversation when she asked if people ever had difficulty using WeRelate, I said that some people got frustrated when others corrected their work, the same as when an academic submits their paper for peer review, or a reporter submits their story to an editor. And that's the quote she used. Not my favorite quote, but at least she included our emphasis on sources. Next time I'm going to be more careful. (I'm sure glad I don't run for public office.)--Dallan 00:10, 16 December 2011 (EST)

Page layout [13 November 2011]

Is it possible to override the default layout for a Category page? After X number of links have been added, it goes to 3 columns. However, for something like the census categories, it would be easier to browse if the links remained in one list (since the consensus has been not to add a sort key to alphabetize by county). For example, the Category:1920 Massachusetts census page is easier to read than the Category:1920 Connecticut census. Even if you would have a page with all of the counties in a state represented, most states have less than 100 counties. The eye follows a list that is lined up much easier than it follows items that are multi-line and then multi-column. It makes it much easier to see the name of the county when the link is all in one line. -- Amy (Ajcrow) 05:47, 12 November 2011 (EST)

Sorry, I'm not aware of a way. I could override the default for all category pages to be one column fairly easily, though I'm not sure we'd want that for all categories?--Dallan 21:23, 12 November 2011 (EST)

I don't think we want to do that with all categories! It is just harder to browse multi-line items when the thing that you're looking for is in the middle of the line. Sort keys would have helped solve that. (Looking for Greene County? Look under "G" instead of having to read every link starting at the top.) But apparently that decision has already been made. -- Amy (Ajcrow) 08:09, 13 November 2011 (EST)

Categories for World War I and World War II veterans [14 February 2012]

I wish to create a category of some sort for World War I veterans. I have just started a project to recognize Alabama veterans who were killed in action in this war and their families by creating pages for them on We Relate. Goal is to finish this project and then add the veterans who died from wounds and then the veterans who died from disease. Hopefully I will finish by the centennial anniversary of the armistice. I chose Alabama because this is my home state and also the Alabama Archives has a Gold star database that is under construction that helps with connecting the veterans to their families. The Gold stars were awarded to mothers after their child's death hence the name.

So need advice. Is one just supposed to lump the veterans of these 2 wars under Veterans? Thanks. --Beth 21:06, 28 November 2011 (EST)

IMHO, there needs to be at least one more "level" to the categories. Otherwise, you could potentially have thousands (millions?) of people in those categories. Something that large would unwieldy to the point of being meaningless. (We need to think long-term, as I don't think anyone would be interested in having to re-categorize all of those pages when the categories become unmanageable.) Not sure what the best hierarchy would be, though. By regiment/unit probably wouldn't work, as many descendants don't know that information (especially for WWII service since the fire in St. Louis destroyed so many WWII-era records). Maybe by the state they served from? You could have Veterans > World War II Veterans > World War II Veterans of the United States > World War II Veterans of <state>. (Adding the country in there so that we can accomodate veterans from other countries.) Not sure this is the best way, but it might be the simplest yet still somewhat manageable. -- Amy (Ajcrow) 06:54, 29 November 2011 (EST)

What would be most useful from a genealogical point of view? Some people fought in Europe, some in the Pacific. Some people fought in significant battles. Some lived, and some died. People could also be grouped by surnames (eg. "Doe in World War II"). There are different ways to group them besides the usual geographic areas. -Moverton 11:48, 29 November 2011 (EST)

Surname and geographic categories are not mutually exclusive, and could prove to be good complements to each other. For example, one user might want to find everyone with the same surname, while others might be more interested in finding those from his/her area. There's nothing saying you couldn't have World War II veterans of <state> as well as Surname <initial> in World War II. (Breaking it down first by initial might be a good way to group them together.) -- Amy (Ajcrow) 12:17, 29 November 2011 (EST)

If you meant having "Category:Doe J in World War II", I would probably lean toward instead doing "Category:Doe in World War II|John" since most surnames probably wouldn't be overcrowded. -Moverton 18:22, 29 November 2011 (EST)

Actually, I meant "Category:D Surnames in World War II". So, Veterans > World War II Veterans > World War II Veterans by Surname (maybe? is this level necessary?) > D Surnames in World War II > Category:Doe in World War II (which is the link that would be on the veteran's page). -- Amy (Ajcrow) 18:32, 29 November 2011 (EST)

Okay, the idea is then to have 2 categories for each veteran. One for geographic location and one for surname. Okay with me. Y'all decide on the surname concept. I am anxious to move my veterans' pages who are presently in the Military category.--Beth 19:21, 29 November 2011 (EST)

I realize that the civil war was different - with most soldiers being volunteers in state militia units - but I'm wondering why the regimental organization isn't appropriate here as well? It has the advantage of allowing us to key off unit pages that often exist in wikipedia that provide a unit history (hence, a good jumping off point for the history of members of the unit). --jrm03063 21:44, 29 November 2011 (EST)

Isn't the long-term goal to use search to aid categories? So that we'll be able to choose a category and search for all of a surname within it? In that case, the effort to set up the category surname hierarchy would be wasted. The place hierarchy, on the other hand, requires human intervention because where someone enlisted from is not necessarily where they were born or died. But, and this is the real question, is where one enlisted from--and the fact that thousands of others also enlisted from that state-- really a useful or interesting fact? I think no - it would just be a way to break down what would be a gigantic category. I agree that units or ships would be most interesting, but also difficult for most users to determine, so we need a backup. And come to think of it, even if search and categories aren't changed, right now you can search for "civil war" and a surname and get everyone with a civil war category and that surname (it's not precise, but good enough). I recommend therefore that the default rule be just a "World War I Veterans" category - with subcategories for things like famous leaders (which we already have, I think) and units as they are identified.--Amelia 22:58, 29 November 2011 (EST)

Throwing in my 2 cents here: In the Civil War, most troops were raised by the states and maintained a state designation. In WWI, that was partly the case, but it changed to a "national" army pretty quickly. In WWII, there was no state designation that meant anything. My father (a career officer), served in the Philippines in the late '30s, in WWII, in Korea, and in the early part of Vietnam. In between, he lived in California, Iowa, Ohio, Michigan, Colorado, Missouri, Texas, and several places overseas. So what state did he "serve" from?

I would recommend going with the Army's own internal organization, largely because it already exists. Especially in WWII, one generally stayed in the same regiment throughout the war. Though the higher command structure morphed as needed (corps, army, etc), the levels below division were more "atomic" and didn't often change. I think most people who know their relative served in WWII in the first place, know at least what unit he was in. And remember that there were a huge number of regiment-level & battalion-level unit histories written and published, beginning in 1946. (And division-level, too, but they don't have much detail on individual soldiers.) Charles Dornbusch did a couple of lengthy bibliographies of those -- same guy who did the 5 vols of Civil War regimental bibliography.

I have to admit, this discussion seems a bit odd to me. It's a matter of age. I was born in the middle of the war (well, you know what I mean), so it doesn't really seem like "history" to me. --Mike^Talk 04:40, 30 November 2011 (EST)

I'm not convinced that going by regiment is the best for WWII. There are so many ways of describing the unit in which someone served. For example, where do you put this person or this person? Let's take this back a step -- what purpose does the category hope to serve? With such a huge number of people we would be dealing with (at least for WWII), is there a way to make a category meaningful? -- Amy (Ajcrow) 06:57, 30 November 2011 (EST)

Well, Amy, it's only confusing if you've never been in or closely associated with the military. Private Martz was a member of the 129th Military Police Battlion. (A battn-size MP unit would ordinarily supply police & security function for a division of infantry, or whatever.) PFC Carter was ground crew ("AVN") in the 372d Squadron, Army Air Force. (Aviation units, like the navy, are harder to quantify in terms of the number of actual people they include, since it's the technology that's important and the people serve the machines.) Anyway, it's no more difficult than any other technical field and there are a number of quite good articles at Wikipedia that describe military organizations for all you civilians. . . . :-)

Whether categorization of WWII vets is a 'useful thing to do is a whole other question and I'm not really convinced it is, for the reasons you note. There were something like 16 million American military personnel in WWII -- out of a 1940 total population of ~132 million. That's compared to a little over 3 million in the Civil War, on both sides. --Mike^Talk 15:02, 1 December 2011 (EST)

I've spent a little time on this today, and while the unit types seem pretty confusing once you get past the civil war, the truth is that any large armed force is going to consist of a relative handful of the "smallest" type of independent unit. For WW2, this looks like (at least) regiment, battalion, ship, squadron. I think we're really on the hook to learn enough about the organization of the period military in order to do this right - it's the only way that assignment of individuals to a category is going to assist in lining up a relevant unit history with an individual. I think we need to find one or more folks with period-specific military expertise to suggest what the appropriate groups should be for the Army, Army Air Corps, Navy, Marines, and Coast Guard during each of the world wars. --jrm03063 16:28, 30 November 2011 (EST)

I created categories for WWI and WWII since there is a consensus on these 2 categories. Waiting for us to make a decision on any other further divisions of these 2 categories. Not sure how we should proceed. --Beth 12:01, 1 December 2011 (EST)

Relating to the subcategorization of military units, I've thought about it for awhile and suggest categorizing it by unit type (i.e. Armor, Artillery, Infantry, Squadron, etc.), by country (i.e. United States, Great Britain, Russia, etc.), and by war or era (War of the Spanish Succession, US Civil War, World War II, etc.). We could also add military service branches (Army, Marines, Air Force, Navy, Coast Guard), but that may not be necessary with the other subcategorization by unit type which would for the most part categorize it into it's service branch, either by its type or by its name. Your thoughts are welcome. --BobC 12:12, 14 February 2012 (EST)

Developer Help Wanted? [14 December 2011]

I'm not sure if this is the appropriate place for this discussion, but I had a few questions, that I was unable to answer with a quick search of the site.

First, this is really great software! I keep finding really cool new tools (e.g., today I found the pedigree map view), and I think that you are doing great work. My first question is how much of the software is open source? It seems like other family tree sites could reuse some of the great work that you are doing.

My second question is whether or not there is a way to contribute as a developer? I'm a beginning programmer, but I have some experience with MediaWiki templates, bots, etc. If there are simple tasks that I could help with, I think it would be fun.--Jdfoote1 13:51, 10 December 2011 (EST)

I'd be very interested! I haven't open-sourced the software mainly because it has a lot of moving parts (mediawiki extensions, gedcom uploader, solr indexer and search server, and a bunch of shell scripts, all written in php, java, flex, and even some ruby). It's non-trivial to get it installed and configured, and I don't think I have the bandwidth to help people with the installation. Also, I think having a bunch of WeRelate-like websites would kind of go against the vision of having one connected place where people can collaborate.

But having said that, I'm slowly open-sourcing pieces of WeRelate, without the WeRelate dependencies. See the similar names project for example, which I hope to announce officially next week. Also, I'm just starting work on a robust, open-source gedcom parser based upon the parser we've been using at WeRelate but with the WeRelate-specific code factored out. And soon I'll start work on a "place standardizer" - given a genealogist-recorded place text, map it to a standardized place with latitude and longitude. I've been asked to give talks on these three projects at RootsTech in February. All of them are written in Java.

Specifically pertaining to WeRelate, the next feature I would like to implement is a dynamically-searchable and sortable list of people in your tree. Take a look at this SlickGrid example, and pretend that each row represents a person in your tree, and when you click on the plus sign next to a row, it expands the into the person's parent and spouse families, and when you click on a plus sign next to one of those families, it would expand into the members of that family. Typing something in the search box would filter the rows displayed, and clicking on a column header (which is turned off in that example) would sort by that column. SlickGrid is especially useful here because it efficiently handles lists of thousands of items. If you wanted to write the javascript side of this, I could provide the api calls to fetch everyone in a watchlist, fetch families associated with a person, and fetch people belonging to a family, including fields like given name, surname, birth date, death date, etc. And I could write the API calls using JSONP so you could develop and test the javascript on your own server.--Dallan 17:15, 10 December 2011 (EST)

That sounds great. Like I said, I am a beginning programmer, but I do have a project that used DataTables, which looks similar, so I think I could at least give it a try. I will get started pretty soon, and then let me know when you have the API calls ready, and I will play plugging those in.

I definitely understand the thinking behind not open sourcing the entire application - open sourcing just pieces seems like a prudent way to do it, and more useful for the community.

P.S. Best of luck at RootsTech - that's awesome. Jdfoote1 00:48, 11 December 2011 (EST)

Great! I should have the API's ready sometime next week. I'll let you know.--Dallan 01:03, 11 December 2011 (EST)

I've been playing around with this a little bit, and it looks like it's (hopefully) doable for me. :) I did have a question about the UI, though. It seems like it could be confusing for the plus sign to open the person's parents and siblings. It seems like an expand like that usually just goes deeper into a tree, and it seems like it could be confusing to go both up and down the tree at the same time, but maybe I'm missing something? -- Jdfoote1 12:40, 14 December 2011 (EST)

Good question. I can think of a couple of other possibilities:

1. We pick one direction: clicking on a + by a name displays either the parents or the children
2. We have two buttons: instead of a plus button to the left of a name, we have something like a ◁ button for descendants, and right next to it, a ▷ button for ancestors; when the user clicks on one of the buttons, it turns into something like a ▼ and displays children or parents as requested

I'm open to other thoughts as well. I've been working on the back-end code. I should have a first-cut at an api for reading data ready tomorrow. I'll send you an email as soon as it's finished. Thanks for working on this!--Dallan 23:52, 14 December 2011 (EST)