WeRelate talk:Support/2019

Perennial questions / proposals [11 January 2019]

Maybe we need to have a Help section page that is akin to wp:Perennial proposals? --ceyockey 23:03, 10 January 2019 (UTC)

Your "akin to" link is broken. fbax.ca 20:07, 11 January 2019 (UTC)

You're right. I didn't account for the target page being in the Wikipedia namespace --> wp:Wikipedia:Perennial proposals. Thanks --ceyockey 03:23, 12 January 2019 (UTC)

Events without Citation ID [25 January 2019]

Is there a way to search for events without Citation ID (ie: no sources)? --fbax.ca 17:48, 12 January 2019 (UTC)

Maybe you could explain a bit more what you are trying to do. Events such as birth and death are searchable. Thanks for some examples / use cases. --ceyockey 02:45, 19 January 2019 (UTC)

I have a tree with 204 persons. +Tree:"Fbax.ca/Bax3"

• Person:Maria_Bouman_(5) does not have sources for *any* of birth/marriage/death.
• Person:Willem_Snoeij_(2) has sources identified for *all* of birth/marriage/death.

What would I add to search parameters to include Maria and exclude Willem from results? If I need to execute search for each event type separately that would be fine. --fbax.ca 02:54, 19 January 2019 (UTC)

There is a category Category:Sources Needed that lists pages with no sources, but that requires somebody has marked them as needing sources manually.

I can find pages with sources, but not sure how to find ones without.

Look at [1] which shows you the raw xml that describes the page. Notice sources are defined by source_citation tag.

If I search for Person given name Willem surname Snoeij, exact match, there are 2 found. One has sources, one does not. If I add source_citation to the keyword field and repeat, I get only one result, the one that has sources. Don't know how to ask for something that is not there though. --Jrich 06:32, 19 January 2019 (UTC)

Thanks!! Using keywords "source_citation" and "event_fact" appears to do the job:

+Tree:"Fbax.ca/Bax3" --> produces 204 results.

+Tree:"Fbax.ca/Bax3" +source_citation --> produces 72 results - all events have source.

+Tree:"Fbax.ca/Bax3" -source_citation --> produces 132 results - some sources missing.

+Tree:"Fbax.ca/Bax3" -source_citation -event_fact --> produces 25 results - no events.

+Tree:"Fbax.ca/Bax3" -source_citation +event_fact --> produces 107 results - some events are missing source.

--fbax.ca 20:14, 19 January 2019 (UTC)

Further research shows that with the above technique a Person/Family is not included in report if there are multiple events and any of those events has a source attached. :( Using action=raw that I read about elsewhere; I wrote a script to download all data for a tree into a directory; then ran

grep event_fact * | grep -v source

Works great! --fbax.ca 01:53, 25 January 2019 (UTC)

Preservation of content via Internet Archive [7 February 2019]

I have found that, given a set of linked individuals in a multi-generational family, if you place one page into Internet Archive, the IA engine will suck the rest of the family in via link crawling. Has any consideration been made about seeing if we can implement the english Wikipedia Internet Archive Bot to save WeRelate en masse to Internet Archive? --ceyockey 02:48, 19 January 2019 (UTC)

FWIW, I'd be happy to make the xml dump file with the contents of the current wiki pages available to anyone who wants to pursue this.--Dallan 21:47, 19 January 2019 (UTC)

We discussed this a bit a few months ago, Dallan, but I would be happy to make this happen. --Jdfoote1 15:46, 21 January 2019 (UTC)

How is a page added to Internet Archive? --fbax.ca 15:43, 21 January 2019 (UTC)

To add a page to the Internet Archive, put the URL into the entry box at https://web.archive.org/ and return. If it is already present in the archive, instances will be shown on a calendar view. If it is not already present in the archive, a link down the page will show up which will archive the page when clicked. That's the one-by-one method that I typically use. There are other methods using batch and automation functions. Wikipedia uses a bot to crawl references and add the references to Internet Archive, rather than the wikipedia pages themselves; see wp:User:InternetArchiveBot. --ceyockey 23:36, 21 January 2019 (UTC)

If we do this, we need to be reasonably sure that we don't have information about living people on any pages, since once the data has been posted to the Internet Archive, I'm not sure how easy it would be to take down. I haven't been browsing the site for possibly living people; have others noticed pages for living people lately?--Dallan 00:28, 22 January 2019 (UTC)

Yes. I am within one week of handling all the pages that actually say Living, but there are many more pages for living individuals - I have found and deleted several in recent months. I don't think we are ready for archiving yet.--DataAnalyst 23:26, 23 January 2019 (UTC)

So, I think that the easiest and most complete way to do this is to upload Dallan's XML dump. How much work do we think it would take until we feel reasonable confident that we can archive the data without having any personally compromising information.

My personal opinion is that just having living people's names and/or approximate birth dates in the data is not a deal-breaker. What we really need to avoid are things like SS numbers, etc. --Jdfoote1 01:48, 6 February 2019 (UTC)

The InternetArchive accepts URL's; one at a time. Rather than an XML dump; the functionality required to feed InternetArchive already exists! Access the search page; specify namespace=people and leave all fields blank; all 2.9 million results currently in database are returned! We could simply give InternetArchive the link with all GET parameters specified and it would do the rest. --fbax.ca 04:17, 6 February 2019 (UTC)

Archive-It is a subscription service that supports domain indexing in an automated manner. Don't know if this has an associated cost or not. See https://www.archive-it.org/blog/learn-more/ . --ceyockey 02:44, 7 February 2019 (UTC)

Archive.org also supports archiving things other than web pages. For example, this is a dump of 300K+ wikis from Wikia in XML format. In our case, an XML dump would be a much better format for the recovery of data in the future. --Jdfoote1 15:21, 7 February 2019 (UTC)

I would urge caution about pursuing this at this time. For one thing, WeRelate is still an active and growing (slowly) site. There is no need to archive the data yet. There are many pages for living individuals, as well as many errors yet to be corrected. As with any genealogical site, errors will always exist - why would we want to freeze them where they continue to be referenced and used but cannot be corrected? If it becomes impossible to keep WeRelate operating in the future, then we can consider an archive, but for now I only see the downside. --DataAnalyst 00:38, 7 February 2019 (UTC)

Internet Archive is not frozen; it will continue to crawl the website (on unpredictable schedule) and copy updates. --fbax.ca 02:12, 7 February 2019 (UTC)

The role of archiving at this stage would be in Disaster Recovery rather than Accurate Secondary Reference. --ceyockey 02:46, 7 February 2019 (UTC)

I agree completely. The goal here is to make sure that everyone's hard work doesn't get lost and is available for future generations. --Jdfoote1 15:21, 7 February 2019 (UTC)

1737 European historical events (in Latin) [21 January 2019]

I stumbled onto what looks like a note regarding world events in 1737 on this page (lower left side). Royalty in Russia, Poland, Spain and Saxony appear to be mentioned (but not by name). Anyone care to transcribe and translate?--fbax.ca 15:42, 21 January 2019 (UTC)

BUG? sequence of search results [25 January 2019]

When selecting the "Date last modified" sequence on search page; it appears that the desired result was to present recently changed pages first (DESCENDING last modified). This is not quite happening. Have a look at these results. My most recent changes to this tree were indeed made on 5-Jun-2018. If you visit the first and last pages for that date; you can see a last modified date-stamp at the bottom of the page. The search results for pages modified on 5-Jun-2018 are presented in ASCENDING sequence of time changed. My last change to this tree was actually Person:Rinnik_Krol_(1) not Person:Albertje_Oordt_(1)! Thanks for your time. --fbax.ca 13:31, 24 January 2019 (UTC)

Not that I can do anything, but if I understand what you are saying, it is that changes made on the same date (ties based only on "date") are not in the right relative order. Can't say what was intended but this would not be surprising. First, being derived from wikipedia software, WeRelate is very text-oriented, and so if the timestamp has a text form, it probably has a date part and a time part. Software meant to compare dates probably only looks at the date part. Then, in the case of the tie, it probably uses what appears to be the natural order of WeRelate, which is first page created first, (one might assume this natural order is based on the order actually placed into the database?) --Jrich 14:00, 24 January 2019 (UTC)

Interesting speculation. The list of recent contributions shows that descending sort by complete date/time is possible. If I close browser and reopen to go back and check something after 40 edits in a single day; I need to scroll down 40 people to find the last person I made changes to. Annoying! Granted recent contributions would do the job; but that page gets very cluttered if there were multiple edits to each person or I work on multiple trees in one day. --fbax.ca 01:30, 25 January 2019 (UTC)

Related pages? [8 February 2019]

The report on this Related Pages reports lists 7 items. As far as I can tell, every person listed in the report is in Bax3 tree. Am I missing something here? --fbax.ca 23:12, 24 January 2019 (UTC)

I think you're missing that Person:Jannetje vanDijk (1) and Person:Lambert Halem (1) are not in your Bax3 tree, only Person:Jannegje vanDijk (1) and Person:Lambert vanHalem (1) are in that tree. Note the spellings. --robert.shaw 03:53, 25 January 2019 (UTC)

Thanks! Both of these persons are redirects. I fixed Person:Jannetje vanDijk (1); but it looks like both Person:Lambert Halem (1) and Person:Lambert vanHalem (1) are in Bax3 tree only. --fbax.ca 13:54, 25 January 2019 (UTC)

OK! So I finally solved this riddle! If a page exists that has been renamed (redirect) and is currently not part of *any* of your trees; then when you click the "Trees" link in left sidebar; the system will automatically place a checkmark in one your trees (I think the last one you made a change in). If this is the tree you want to the page to be in so that it is not included in the "Related Pages" report; then you will need to click "Update" even though you haven't made any changes. This is because the system made a change (by adding checkmark) and you need to save that change. Problem fixed!! --fbax.ca 03:07, 8 February 2019 (UTC)

Billion Graves [8 February 2019]

The Source:Billion_Graves page suggests using {{Bgraves3|##|code|name}} wiki template. I tried this template for Person:Maartje_Akershoek_(1); but generated link is broken!

Also: there appears to be a redundant source page Source:BillionGraves_Index? --fbax.ca 12:39, 7 February 2019 (UTC)

From the instructions for Template:Bgraves3: "Billion Graves has changed the format of their URL, and it is not known how long the old format, that this template is based on, will work. Use Bgravesmem to access the new format of URL directly. The new form of the example given below is:

{{Bgravesmem|530346|John S. Durham}} " (which produces John S. Durham). --Jrich 14:21, 7 February 2019 (UTC)

Thanks! That works. --fbax.ca 03:08, 8 February 2019 (UTC)

The Source:Billion_Graves page has been updated. --fbax.ca 03:21, 8 February 2019 (UTC)

Ontario, Canada - Vital Statistics [16 February 2019]

On WeRelate; we have very messy titles for civil registration records for Ontario!

• Births Births, stillbirths, and delayed registration with indexes, 1869-1914
• Marriages Registrations of marriages (RG 80-5), 1869–1932; delayed registrations (RG 80-6-1), 1892–1919; and indexes, 1869–1932
• Deaths Ontario, Canada, Deaths and Deaths Overseas, 1869-1946

I guess these names originally came from the FamilySearch website:

• Catalog 517518 Births, stillbirths, and delayed registration with indexes, 1869-1912
• Catalog 530639 Marriages - registrations, 1869-1927; original index, 1869-1876; index, 1873-1927; and delayed registrations, 1892-1919
• Catalog 515541 Deaths - registration, 1869-1937 and index, 1869-1937]]

On the [Ontario Archives] website; civil registration of births, marriages and deaths are called simply "Ontario Vital Statistics". The "RG" codes used in WeRelate title for marriages are useful when looking for microfilm copies in the archives library in Toronto. They are not useful when using other repositories.

I propose renaming the above WeRelate pages (and titles) to:

• Ontario Vital Statistics - Births
• Ontario Vital Statistics - Marriages
• Ontario Vital Statistics - Deaths

Year range varies by repository and can be mentioned lower in page.

Any objections? Silence will be considered consent.--fbax.ca 19:07, 14 February 2019 (UTC)

Objection. The messy collections still exist and those are their titles. Best case: add a new source page. I'll leave it to someone who understands source titles to discuss what the new name could be, if needed, but I imagine it will start with "Ontario, Canada. <collection name>". --Jrich 19:23, 14 February 2019 (UTC)

Jrich - the messy titles were created by FamilySearch; they are a repository, not the owners of the collection. The owner is Ontario Archives and they call it "Vital Statistics". - added by fbax.ca 19:40, 14 February 2019 (UTC)

It is the title I see when I look at the records on their site. How in the world am I supposed to come up with your titles based on the information on the screen I am looking at. Unfortunately, the source system tends to think renames are errors, so it is difficult to create aliases. redirects are excluded from the drop-down list you get when you start typing the source name. You can't just make up "non-messy" names, you have to consider many things, one being what a user of a source is going to know about the source, and not know (such as there are many different repositories presenting the same images under different names).

Jrich, you said It is the title I see when I look at the records on their site. Which site are you referring to? For Births; I can find:
* Ancestry Ontario, Canada Births, 1858-1913
* FamilySearch Ontario Births, 1869-1912
Neither of these titles is the messy title used by WeRelate. --fbax.ca 18:27, 15 February 2019 (UTC)

If I access the data on family search, I see it titled the way they title it. All those other names are unknown to me. --Jrich 18:41, 15 February 2019 (UTC)

I did another search on FamilySearch. In the catalog; search for Ontario and select "Canada, Ontario". Near the bottom of long list is "Canada, Ontario - Vital records - Indexes ( 18 )". Click this link and you will see TWO entries for Ontario births, TWO entries for marriages and TWO entries for deaths. For Birth records:
* Births, stillbirths, and delayed registration with indexes, 1869-1912
Points to the list of FHL microfilm numbers
* Ontario births, 1869-1912
Points to an online index with links to scanned documents.
I expect that going forward most people will be using the online index; so perhaps a name change to WeRelate page is justified. - added by fbax.ca 19:40, 14 February 2019 (UTC)

I have little familiarity with Canadian records so don't follow your argument. Vital record indexes are different than vital records. People should cite what they use. If they use an index without verifying it is a correct representation of the underlying record, they should cite the index. Thorough genealogists will use an index to locate a record, but will actually look up, use, and then should cite the actual record. All indexes add some small number of errors no matter how carefully done, and as familysearch indexes were often built by volunteers with no special training working in an area and with families they were unfamiliar, they may not be the best in this regard. The Source:New Hampshire, United States. Index to Births, Early to 1900 was built by town clerks presumably familiar with the records of their town, yet it is still possible to find errors in their index (e.g., Person:Elisha Kimball (2)). --Jrich 21:42, 15 February 2019 (UTC)

Having looked at the birth records situation, I think I agree that WR's "Source:Ontario, Canada. Births, Stillbirths,...1869-1914" record would probably be best be renamed to "Source:Ontario, Canada. Ontario Births, 1869-1912". First, the predominant usage was/was/is FHC/FHL/FamilySearch and not via Ontario Archives (which I believe should probably have a separate source, cross-linked, because it goes to 1917 at present instead of 1912, but that's a whole other issue).

Second, FamilySearch essentially is now using "Ontario births, 1869-1912" and not "Births, Stillbirths..." pretty much everywhere. It shows up in general searches. The "...Stillbirths..." catalog entry links prominently to the "Ontario births" collection search page and lower down lists the hundreds of microfilm numbers and related image links. The "Ontario births" short catalog entry mentions its basis the "...Stillbirths..." collection. Following the online index link in either entry leads you to the same "Ontario births" collection search page. Searches using that yield results labelled as "Ontario births" and having generated citations for "Ontario births", e.g. 'Citing this Record: "Ontario Births, 1869-1912," database with images, FamilySearch https://familysearch.org/ark:/61903/1:1:FMC6-YVM : 16 July 2017), Gordon Roy Vancamp, 12 Dec 1878; citing Birth, Merrickville, Grenville, Ontario, Canada, citing Archives of Ontario, Toronto; FHL microfilm 1,845,216.' If one clicks onwards to the associated image page of the original document, it too uses "Ontario Births, 1869-1912" in its title and generated citation.

So uses of the 1869-1912 data is mostly through FamilySearch and that will almost certainly be now found under the "Ontario Births, 1869-1912" on FamilySearch, so it seemingly makes sense to use the same form on WR. I suggested the prefix "Ontario, Canada." in the Source: page because that seems to be the standard. (Dropping the second Ontario is probably inadvisable.) The rename to the new name should leave a redirect. The page text for "Ontario births" should include mention of the "...Stillbirths..." name and its association.

Note that FamilySearch actually also indexes these birth registrations in a separate index, one titled "Canada Births and Baptisms, 1661-1959". Obviously this has non-Ontario items, but it does include some, if not all of the 1869-1912 registrations, generally with links into the same original document images (but usually off by an image number or two). See Source:Canada. Canadian Births and Baptisms 1661-1959.

But wait, there's more ! It turns out there is already a page named "Source:Ontario, Canada. Ontario Births, 1869-1912" which is the title I suggested above. It is a redirect to a page Source:Ontario, Canada. Ontario Canada Births 1869-1912, which is a redirect to a page Source:Ontario, Canada. Ontario Canada Births, which is not a redirect but a minimal Source page about approximately the records I've been discussing. It hasn't been modified since November 2011. Despite having the Source page title "Ontario, Canada. Ontario Canada Births", the source title inside the box on the page is "Ontario Canada Births 1869-1913". This page has thousands of references from Person: pages, as compared to less than 250 references for Source:Ontario, Canada. Births, Stillbirths, and Delayed Registration with Indexes, 1869-1914.

I hope most everyone agrees the "Ontario, Canada. Ontario Canada Births" would better be replaced with the "Ontario, Canada. Ontario Births, 1869-1912" name. I also think the "...Stillbirths..." page should also be merged. Probably also the little referenced page Source:Ontario, Canada. Ontario Canada Births (MS329) which is a bungled reference to the same set of records, more or less. I think I might be able to be convinced that a separate page(s) might be good for the Ontario Archives films and indexes proper, since they now go beyond 1912 and will be extended starting in 2022. --robert.shaw 08:18, 16 February 2019 (UTC)

The post above does a good job of showing how broken the source system it, being unprepared for multiple collections of the same data, being clogged with existing redirects, and no help page explaining how a user is supposed to find a source if the name they see on the screen doesn't match any source page in the system.

"I hope most everyone agrees". I don't. The collection given by Source:Ontario, Canada. Births, Stillbirths, and Delayed Registration with Indexes, 1869-1914 still exists with that name here. That is the name the film number leads you to when you look the film number up in the familysearch catalog (film number usually given in image 1 if looking at a film).

The "I hope most everyone agrees" sentence has nothing to do with Source:Ontario, Canada. Births, Stillbirths, and Delayed Registration with Indexes, 1869-1914. Perhaps I should have made it its own paragraph to slow down skimming readers, but it was late and I failed to do that. --robert.shaw 20:12, 16 February 2019 (UTC)

It appears all the images in this particular film collection have been put online under a collection name "Ontario Births, 1869-1912", and that is given in the citation kindly provided by familysearch in the information tab. Of source, that citation assumes the reader will follow the link given since it does not provide identification of which book and which page the image comes out of, only of how to find it in the digital collection using the link, access to which requires a family search account. So it is not helpful to somebody accessing the collection in a different way. But most users will see the citation in the information tab and use that. (The same problem exists with familysearch citations for (U.S.) census records, which do not give you the universal page information such as enumeration district, etc., needed to locate the page in archive.org, only enough information to use familysearch's electronic resource.)

In the familysearch catalog, there is an entry for "Ontario Births, 1869-1912" which is called an electronic resource, and it references another catalog entry "Births, stillbirths, and delayed registration with indexes, 1869-1912" as being the associated film collection. Unlike this case, in general, it is not true that all images in a film collection are available in a parallel electronic resource. It appears that all the films in this film collection are fully viewable online, presumably all included in the Ontario Births electronic resource. However, there are many cases where a film collection contains some films whose images are available online, and *some that are not*, so the resulting electronic resource is not complete. Clearly for someone with access to restricted films there is a need to be able to cite them. So, *in general*, replacing film collections with electronic resource names is not a good idea.

If we use electronic resources, it would appear that we are tied to familysearch's organization and reorganization of online images. Film collections tend to be relatively stable being a physical object, and the film collection usually has enough information in the catalog to relate it to a physical record book (including images showing the title of those record books), so if perchance, somebody does have the ability to examine the actual record, you or they may be able to find enough information to locate the correct page in the correct record book, and not be limited to some link to some electronic resource arranged in some artificial collection.

So I think the old page for the film collection needs to be retained. If it is desired to add the name "Ontario Births, 1869-1912", presumably on the grounds that it is what a user sees in the familysearch-provided citation, then it should be a separate source page, just like it is a separate catalog entry in familysearch's catalog. --Jrich 16:21, 16 February 2019 (UTC)

Thanks, Jrich. Totally agree that film citations and digital image citations are both different sources, and should have different entries. This is based on my experience with trying to navigate the different collections, and communicating with people who have complained because they looked in the "indexed" collection and couldn't find a record cited by film number. --GayelKnott 16:52, 16 February 2019 (UTC)

Here FamilySearch helps a lot by providing reasonably explicit citation text (including specific, persistent URL) on the historical records they have. With this text I often just use "Citation Only" and avoid the "Source" and "MySource" options. The latter serve mainly as shorthands for showing source details and with the supplied citation text aren't needed. --robert.shaw 21:03, 16 February 2019 (UTC)

After all this all I can say is it's a good thing no one has inspected the Ontario Marriage and Death Records too carefully. First, death records were not collected until civil registration started in 1869, and very few records were made in the early years. Numbers improved around 1880, but around the turn of the century, the Registrar General's team decided to change the registration form. For the next few years all that was requested was the name of the deceased, the date of death, and the registration office. Very useless if you are chasing up a John Smith. Also, at this time, marriage information was collected over a double page with the groom's information on the left and the bride's information on the right. LDS aksed for transcriptions of each side separately and the index looks like they never got the two sides back together. Things improved around 1910. From then on the images provide all sorts of infomation, even the addresses of informants (deaths) and witnesses (marriages). --Goldenoldie 17:12, 16 February 2019 (UTC)

I know that there is a desire to avoid multiple source pages for the same set of records (what you call different repositories, though in truth all are different since they have different indexes which can make them in weird situations make using them different, etc.) However, this is exactly how the source system is broken, because it assumes everybody knows all the same information as the person picking the source name, instead of assuming they probably don't and just following a prescribed convention.

The convention is to name records that are government or church records starting with the place name. Thus the names needs to start with Ontario, Canada. --Jrich 23:53, 14 February 2019 (UTC)

Now you introduce new wrinkles! Repositories are separate from sources and indexes are different than original documents. Websites that combine indexes with original documents blur the line between indexes and documents. An original document for a BMD registration in Ontario might be found on various websites. The original document is a source; the website where you find a copy of that original document is a repository. If a website indexes those documents so that users can more easily find the original document; then that is a separate source; but I expect I'll fight an uphill battle on this point. On some websites; the "index" actually contains a transcription of many key data elements from the original document; if such a website also includes link to a scan of original document, the distinction between "index" and "original document" in even more blurry. The WR pages relating to various Ontario Vital Statistics include in the list of repositories websites that are really just indexes with no link to original source. These should not be included in a repository list since the original document is not there; but since they are helpful; I'll not push for removing them (or making a list separate from "repository") at this time. - added by fbax.ca 19:40, 14 February 2019 (UTC)

The distinction is not well-defined, a side-effect I assume of being designed when sources mostly meant a book in a library, and the distinction between source and repository was much clearer. The purpose of citing a source is to tell where the data came from so it can be confirmed (also so it can be assessed for quality as some sources are more authoritative than others). The information given to locate the source used is often different when using different "repositories". Thus for the familysearch collection Massachusetts Deaths, the location is a link to an image, but for the americanancestors.org collection showing the same images, the location information is a volume and page number. This volume-page information is not explicitly given for familysearch images, and in some cases would be some work to determine, such as when multiple volumes are filmed on a single film. And even if you had it, you wouldn't be able use it to direct familysearch to the right image very easily. Likewise knowing the film and image number in family search would not help locate the image in americanancestors.com It seems like every census repository shows the same images but the location information used to find that image is different. An article in a magazine holds an article at a certain Volume and page number, but an identical titled reprint may use its own page numbering, perhaps having the same number of pages, perhaps not, due to a different page size or new pagination needed to allow for additions since the original article came out. Not matter which "repository" a user gets their information from, they should be able to cite the source using only the information available to them. They should not need familiarity with the six other "repositories" and how they correspond. The knowledge about how they corresponds needs to be defined in the source system, somehow, instead of requiring such detailed understanding by each user when they may only use one source once for a single fact. --Jrich 18:38, 15 February 2019 (UTC)

It is important to add "Canada" after "Ontario" in this case. There is a town in California named Ontario, and Canada and California share the abbreviation "CA".

I was very new to WR when I attempted to sort out the Ontario pages 4-6 years ago. I wasn't sure how many toes I would step on. Today I would prefer to leave the task to someone more local who can check things out on the spot at Ontario Archives. Times have changed and it now can be reached by subway from the centre of Toronto, as well as by bus and car from places outside the city.

Regards --Goldenoldie 20:15, 14 February 2019 (UTC)

GoldenOldie - The collections that precede civil registration are also a mess! Most researchers distinguish between county and district marriage registrations in Ontario; but FamilySearch lumps these items and others into one big messy collection called Marriage Registers. - added by fbax.ca 20:52, 14 February 2019 (UTC)

"Forgey Descendants" Source - what do you think? [19 March 2019]

I've added a source that I've dubbed a 'source of clues', but it looks professionally done, though lacks the finality of a published work. See Source:Forgey Descendants. Thanks. --ceyockey 01:41, 19 March 2019 (UTC)

This appears to be a register report from someone with their data on Family Search. I rate these as a MySource rather than putting it in the community maintained Source file. The "Evaluation Copy" marks it as a first pass sent out to others for correction, etc. So someone's personal research and they aren't ready to distribute it yet. Many living people too.

If it were submitted as a gedcom through our process we would regard it as needing work, but that's what the site is here for. I don't like cluttering up the Source database after we spent two years trying to clean it up. (personal opinion) --Judy (jlanoux) 11:23, 19 March 2019 (UTC)

Are these Find-a-Grave sources considered candidates for cleanup? Should they point to Source:Find A Grave instead? --fbax.ca 22:21, 19 March 2019 (UTC)

Yes to both of your questions. If someone cleans up the references and adds a speedy delete template, I'll delete these source pages.--DataAnalyst 01:27, 20 March 2019 (UTC)

I see no issue with the "Forgey Descendants" Source; and do not understand why it might be considered "clutter". --fbax.ca 22:21, 19 March 2019 (UTC)

• I see Judy's point in that, at a minimum, there is no reliable attribution to who or what organization was involved in the publication of the material. My asking arose because I did have some doubts when adding it, though I still think it could be useful as a "source of clues" to be supported by more reliable sources. I'll go ahead and migrate it to the MySource space. --ceyockey 00:15, 20 March 2019 (UTC)

I created the page MySource:Ceyockey/Forgey Descendants and marked the original page for deletion. --ceyockey 00:28, 20 March 2019 (UTC)

Template:Pedigree4 color issue with link for Person #1 [31 March 2019]

I read that creating an ancestor chart is one way to link deceased persons that are connected by a living person. I created User:Fbax.ca/Ancestors. I guess that Template:Pedigree4 was expecting me NOT to use a link for Person #1; because the color scheme makes Nathan's name unreadable. Anyone have a suggestion to fix this? --fbax.ca 14:51, 30 March 2019 (UTC)

I've added Template:Pedigree4A which uses different colors in the top box so that the readability of the linked name is better. (Feel free to improve Template:Pedigree4A.) --robert.shaw 17:37, 30 March 2019 (UTC)

Thanks! Looks good. --fbax.ca 18:24, 31 March 2019 (UTC)

Date format conventions - conflicting info [5 April 2019]

Help:Style_guide#Dates states:

• Bet - the date is between (inclusive) the two specified dates (separated by a dash)

Help:Date_Conventions#Between/and states:

• The qualifier pair "Bet ... and ..." may be used ...

Which is it? a dash or the word "and"; or either? --fbax.ca 19:42, 5 April 2019 (UTC)

Ahhhhh - the Help pages (sigh) ... It has long been recognized that the WR Help pages contain conflicting and out of date information. It is one of the pitfalls of the open editing environment without enough hands on deck for oversight. There have been several attempts to clean up the namespace (and even to overhaul the whole structure), but all have withered on the vine for various reasons, mostly due to lack of person power and consensus.

For example, if you look at the top of the Help:Date Conventions page, you will see the status note that reads, "Revisions as of Dec 2016 are intended to prepare this page for being included in the revised Help." I don't think that project was ever completed.

So - to specifically address your question - to the best of my knowledge - here at WeRelate, "Bet" is meant to be used in conjunction with "and", so you enter "Bet xxxx and xxxx". Hth, --cos1776 20:10, 5 April 2019 (UTC)

In this case, the answer is "and". Why? because that is what GEDCOM says. See page 47 of standard. So if somebody exports the posted date using a GEDCOM file, it will have a valid format. Most software is pretty forgiving and may work properly with either case, but since the standard says "and" that is the safe thing to use. Obviously the software may already, or easily could, make such an adjustment internally so either form could be entered, but I am guessing it doesn't, since in general it doesn't seem to do any reformatting of dates.

Help:Style Guide was inconsistent, and has been corrected. --Jrich 21:04, 5 April 2019 (UTC)

Person:George Johnston (23) [2 June 2019]

Person:George Johnston (23) appears to have two WR pages. In one he has spouse Christian Forbes (8), 14 children but no details of year and place for birth and death. In the other he is known as "George Johnston, Laird" with dates 1544-1593 and has no spouse. Both are the sons of William Johnston and Margaret Hay.

The right-hand panels of the two records list Christian Forbes as spouse and the same 14 children.

In the marriage record of George Johnston, Laird, details of year and place for birth and death are given, but these are not on the page for George Johnston, Laird.

I am pretty sure both records refer to the same man, but I do not trust myself to make a merge correctly. Could someone sort out these records, please.

NOTE: The birthplace given for George Johnston is Caskieben, Aberdeenshire, Scotland. Caskieben is an estate still in existence in the parish of Keithhill and Kinkell. I have changed the birthplace for all the children from Caskieben to Keithhill and Kinkell, retaining Caskieben in the description. It would improve the story if the father's details could match.

/cheers, --Goldenoldie 18:34, 1 June 2019 (UTC)

There is only one Person:George Johnston (23); so no merge is needed. There could be a propagation issue (bug?) here with vital information between person and family pages.

There are two marriages Family:George Johnston and Christian Forbes (1) and Family:George Johnston and Christian Johnston (1). Are you asking to merge the marriages and the wives?

Wouldn't it make sense to move this discussion to talk page for George?--fbax.ca 19:01, 1 June 2019 (UTC)

I chose to put this question in Support because I doubted anyone would see the problem if I put it on George's talk page.

Starting at the page for [[Person:George Johnston (23)]], the list on the right-hand side shows his marriage to Christian Forbes and his fourteeen children, followed by a second marriage to Christian Forbes Johnston. (My feeling is that this second marriage never existed, but we are working on person and family pages without sources, so we do not know if this is true or not.)

However, on the page for this second marriage we find the birth and death years and place (Cariegen, Aberdeenshire) for George. These facts do not appear on his Person page. Also, Christian Forbes' parents are traceable on the first marriage page, but not on the second.

Cariegen is an estate that belonged to the Johnston family until it was sold in 1662 (ref: F. H. Groome's Ordnance Gazetteer of Scotland: A Survey of Scottish Topography, Statistical, Biographical and Historical (1882-1885), published online by the Gazetteer of Scotland). The estate (still in existence) is in the parish of Keithhall and Kinkell. I am trying to replace Cariegen with the name of the parish.

I would like to merge the records for the first and second marriages and link all the information we have on this couple together, but since most of my work on WeRelate is with places rather than people, I am not sure I can work it out myself.

--Goldenoldie 10:25, 2 June 2019 (UTC)

Hi, Goldenoldie

I merged the 2 marriages. I can't explain why George's years showed up in the second marriage but not on his person page. I've seen this kind of thing before, and I assume it is the result of a bug that occurred during the gedcom upload (which might have involved a merge). At any rate, there was no source for the dates (which also show up in Find A Grave with no source), so I found a published source and used its dates instead.--DataAnalyst 14:10, 2 June 2019 (UTC)

How to enter ambiguous place? [2 June 2019]

Today, I want to enter "Jersey City" as a place; but my source does not indicate where this place is; WeRelate knows about two of them (in NJ & NV). If I enter "Jersey City"; this website changes it to "Jersey City, Hudson, New Jersey, United States|Jersey City" which is not desirable. What is the correct way to enter this; so that WeRelate does not select a misleading default? Please advise.--fbax.ca 22:44, 1 June 2019 (UTC)

Hard to believe it can't be distinguished between NJ and NV, or is there more to it? If it is Person:Neeltje Bax (3), source #2 says Hudson County, NJ. Also a death in 1941 suggests she can be found in 1940 census. If there is more to it than this, details are needed. --Jrich 01:02, 2 June 2019 (UTC)

In this case, I solved it after asking my question. In the general case; my question still remains. How do we prevent WeRelate from choosing an incorrect place? --fbax.ca 01:59, 2 June 2019 (UTC)

I would suggest entering an ambiguous name in the description field instead of the place field. There is precedent for this, usually when someone knows the name of the town and the state but not the county (and there are 2 towns with the same name in the state). In that case, I've seen the state in the place field and the name of the town in the description field.--DataAnalyst 02:54, 2 June 2019 (UTC)

Assuming a source is the cause of the ambiguity, I would quote the source in the citation so as to communicate precisely how it states the location, possibly adding a note in brackets that the description isn't specific enough to distinguish between ..., and list the choices. Usually a little directed research can help make a guess, in which case entering Jersey City, Hudson, New Jersey, United States|probably Jersey City, Hudson, New Jersey, United States or similar is commonly used. If both choices can be located in one larger place, dataanalyst's method works well, enter the containing place in the place field and put the ambiguous place name into the description. But quoting the source and describing the quandary is needed so future readers understand, and don't simply "fix" the page. --Jrich 04:46, 2 June 2019 (UTC)

I dealt with something similar recently in relation to "Doylestown, Ohio" and Family:Oscar Wotring and Charlotte Everhard (1). I edited each of Place:Doylestown, Paulding, Ohio, United States and Place:Doylestown, Wayne, Ohio, United States to cross-reference one another for disambiguation, and left the place in the family record red-linked with a note N1 referencing both potential places. --ceyockey 14:32, 2 June 2019 (UTC)

Note though (for others trying this approach) that the only reason the page is red-linked is because the town name on the Family page is spelled differently (Doylstown) than both the Place names, and thus WeRelate could not resolve it to either Place page. I believe that if you had spelled the town name Doylestown, WeRelate would have linked to one of the Place pages on saving the Family page.--DataAnalyst 15:02, 2 June 2019 (UTC)

Note, though, that the spelling "Doylstown" in the source consulted. Another editor came along and "corrected" it based on Census information, but it leaves open the question of whether the source had a typo or it was referring to an alternate spelling. Ignoring the value in the source because it is not consistent with expectation is sloppy, in my opinion. --ceyockey 20:16, 2 June 2019 (UTC)

That is why there is a box for including information and content from the source: so you can specify that the source spelled it one way or another. Clearly, the source does not make anything true, and there is an official spelling of the town's name ([2] wikipedia:Doylestown, Ohio, and oddities like this are almost certainly anacrhonisms, typos, quirks of the author, etc. And I am pretty sure the post office in the pre-zip era of 1891 (when the source was published) would have delivered mail to Doylestown if you wrote Doylstown. All various spellings and such must be amalgamated into a single entry in a place field, and using the standard WeRelate place name seems the most reasonable approach. I think a census before and after the residence date placing the family in Doylestown is pretty clear. --Jrich 21:01, 2 June 2019 (UTC)

Regarding the general case, How do we prevent WeRelate from choosing an incorrect place?: There is at least one way of preventing the WeRelate software from linking a name in a place field to a default Place: page. That is to include a target name, then the "pipe" symbol (straight line, |, shift-backslash on many keyboards), then the name to be displayed. For instance, to avoid Jersey City being mislinked, one could put this in the Place field:

   (ambiguous place) | Jersey City

This will cause "Jersey City" to show as the place for the event on the Person: or Family: page. It will be in red because it be linked to a nonexistant page "Place:(ambiguous_place)". The text you supply for the link is largely arbitrary as long as it does not match the name of a Place: page now or in the future. So one could instead type (ambiguous Jersey City) | Jersey City into the place field of the event.

If one exports an individual with such a field to a GEDCOM file, only the displayed text (e.g. Jersey City) appears in the event record of the file. If one hovers the cursor over the place name of an event on a WeRelate page, the name of the target page shows in a pop-up toolbox (e.g. Place:(ambiguous place)).

I heartily agree with above commenters that one should explain in a source or note entry for the event why the place name is not resolved to a specific place. --robert.shaw 17:59, 2 June 2019 (UTC)

HTTP ERROR 500 [2 August 2019]

On Template:CohabitationWithoutFormalities page, click "What links here" produces HTTP ERROR 500.--fbax.ca 01:58, 2 August 2019 (UTC)

I tried that and also got the error 500. I then tried several other "Assertion" templates, and some worked and some failed the same way. Template:NoAcceptedHusband worked and Template:RefutedWife failed. --robert.shaw 22:07, 2 August 2019 (UTC)

Birth of child before marriage, partner unknown. [5 August 2019]

Aletta Maria van Lent had a daughter in 1843 (partner unknown) before her marriage to Pieter Visser in 1848. On Aletta's page; this "family" appears *after* the 1848 marriage. Is there any way to change the sequence?--fbax.ca 02:08, 5 August 2019 (UTC)

Yes. Open her page in Edit mode and notice that the spouse family pages are listed in the order shown when rendered. Change the order to move the unknown husband page above the other one and Save the page. Best wishes, --cos1776 10:42, 5 August 2019 (UTC)

search server is down (again) [19 October 2019]

All searches are producing this error. This error prevents adding new person to website.

There was an error processing your search, or the search server is down; please try a different search or try again later.'--fbax.ca 17:41, 19 October 2019 (UTC)

Problems with numbering in outlines [13 November 2019]

I am having trouble with the automatic numbering using what I think is called Organized List. This used to work well but now, for example, I get A F G H I C instead of A B C D E F. Strother Family Descendants is what I'm working on now, but it seems to also happen on other pages.

I've checked and rechecked that the opens and closes are all matched. Can someone please check and see what I've done wrong.

I also welcome any help adding Strother pages to the list. Thanks. --Judy (jlanoux) 00:03, 11 November 2019 (UTC)

I see no outline letter problems on Strother Family Descendants. For example, the children of William2 Strother d. King George 1732 m. Margaret Thornton show "A" through "F". The actual letter characters are not in the HTML but instead are filled in by the browser (Chrome, Firefox, etc). So maybe there's something odd/broken with your browser. --robert.shaw 23:36, 12 November 2019 (UTC)

Thank you for the reply. I do now see that it looks perfect in Chrome. But I was using Firefox. Is this something I can fix in Firefox with options or do I file an error report with them? Thank again for the help. --Judy (jlanoux) 12:57, 13 November 2019 (UTC)

I don't know much about Firefox (I use Chrome), but I poked around and it appears a bug was introduced in Firefox version 68 and a fix is not yet in planning or implementation. Technical links: Firefox bug report and a StackOverflow Q&A. --robert.shaw 16:12, 13 November 2019 (UTC)