Source/Citation Transfer from RootsMagic to TreeShare for Ancestry

[mikeb]

Creating source templates that follow the layered approach guidelines described in Evidence Explained (EE) by author Elizabeth Shown Mills have been relatively straightforward to create in RootsMagic. However, I have been having difficulty getting them to transfer acceptably to Ancestry trees via TreeShare. My goal has been to use TreeShare to post my research with well documented sources (hopefully) to Ancestry. I have not attempted to upload Ancestry developed source/citations directly into my RM files, as some of them are quite inadequate.

I posted a question to the Community asking if anyone knew how source/citation fields from RM mapped to the source/citations found in Ancestry trees, thinking that someone knew how the two were linked. I received responses from one individual, which has led me to believe there are probably a lot of other users like me, who don’t fully understand how information is being transferred. So, I have experimented heavily and have discovered some interesting issues that shed light on why I have had trouble.

1. Text for the source portion of the full footnote created from the RM source template appears to be transferred directly to the Ancestry tree in the “Other Sources” box under the headings “Source Information” and “Title”. There is a limit of 256 characters transferred for the title. Text formatting for italics, bold, or underlining is not done, however punctuation, extra words, and characters outside of the fields that are part of the source template are transferred. It is not necessary to include that information as part of the field text data. Simple switches to fill in default text for fields left blank are working properly. Special keyboard characters “<” and “>” in field text appear to be transferred to the “Other Sources” box on the Ancestry tree person view, but when expanding the box, those special characters are removed from the “Source Information - Title” heading. It appears that those characters pass through TreeShare, and then Ancestry strips them. Characters “<” and “>” appear to be the only ones where this happens.

2. It appears that the text for the citation portion of the full footnote created from the RM source template is not being used in the transfer to an Ancestry tree through TreeShare. It would seem intuitive that the citation should be handled the same way as the source, which is not the case. None of the punctuation or extra words and characters defined in the source template are transferred. Instead, citation fields from the RM source template are combined sequentially as they are defined in the template, separating each field with semicolons. This is a problem when source templates are set up with separate citation fields for the original item of interest, page number, line number, website author, database name, date accessed, image number, source-of-the-source, etc. For an EE style citation, these separate pieces of information are separated by commas. Semicolons are only used between the layers. The citation is then transferred to the Ancestry tree in the “Other Sources” box under the headings “Citation Information” and “Detail”. There is also a limit of 256 characters transferred for the citation. This is a problem for many citations, particularly ones for sources found on websites that require a layered citation to additionally identify the original information, the website information, and often the source-of-the-source information. Long citations are now truncated at the 256 character limit, leaving out a lot of important information.

3. In order to determine how TreeShare performs source and citation transfers, numerous changes to the source templates and the text used in the fields were required. It was during this process that I discovered that changes made to a source or citation did not automatically update the Ancestry tree source or citation when opening “TreeShare for Ancestry” window. The source citation icon turned red to indicate it had been changed. But when following the process to select the changed item then clicking on “Accept changes” did nothing. The source did not change in the Ancestry tree. I could delete the citation in RM, and then recreate it and the change would take effect in the Ancestry tree. But this required re-entering citation fields, a task I did not want to perform repeatedly. Luckily, I tried deleting the source from the Ancestry tree and found that following the change process actually worked. While this sped up the testing process, it does not seem logical that you would have to delete a source from the Ancestry tree to be able to edit it. I find that when I enter source and citation data, I have to see how it looks when creating the RM footnote and inevitably find that I entered a page number incorrectly or have a misspelled word. It would be much easier to not have to take an additional step to delete the Ancestry tree source to accomplish the change. Other data changes for names, places, facts, and dates are made automatically without having to make changes in the Ancestry tree first.

In summary, several changes could be made to make the transfer of EE based source and citation data between RM and Ancestry via TreeShare much better. It appears that some of these issues are attributed to how RM is sending information to Ancestry, and others are how Ancestry is converting the information passed.

Increase the number of characters for citations and sources. It seems important that the citation in Ancestry should be increased from 256 characters. Some of my sources, and the EE example sources I have examined would require this limit to be at least 500, but it would probably make sense to use a higher limit than that. The source limit may be acceptable at 256, but I would increase it also. Determine whether this limit is within RM or Ancestry API.

Modify the citation transfer so that citations follow the same process as the source. Transferring the citation footnote as created by RM will solve this issue. Simple switches should also work in the citation like they do in the source. This seems likely to be an RM issue.

Allow for characters “<” and “>” to be displayed within the Ancestry tree. The “>” character is used when describing the path used to locate source documents on a website. Based on my testing, this appears to be an Ancestry API issue.

Enable italics, bold and underline formatting. Item in italics are important for book and website titles in both source names and citations. When I attempted to use italics formatting within a field, the transfer showed an i before and after the associated field. This could also be an Ancestry API issue.

Enable edits to sources to be made without having to first delete the source in Ancestry trees. Doing this would make source changes the same as for names, places, facts, and dates. Determine whether this is within RM or Ancestry API.

[thejerrybryan]

Another formatting issue in notes is that blank lines in RM’s notes are lost on transfer from RM to ancestry. The blank lines are created in RM with carriage returns, and carriage returns apparently are not supported by the ancestry API. When I first started playing with TreeShare, I found the loss of blank lines amusing because I could transfer a note from RM to ancestry and immediately thereafter the TreeShare user interface told me the two notes didn’t match. I immediately knew I was in trouble.

In general, there is much data that doesn’t survive a one way trip between ancestry and RM in either direction, and which really doesn’t survive a round trip in either direction. In my view, the culprit is not any fault of TreeShare’s programming. Rather, the culprit is unreconcilable differences in the data models used by RM and ancestry, respectively. As a result, it’s not actually possible to map all data on a one-to-one basis from the one to the other.

[JohnEChambers]

As a user of both RM and FTM I can attest to the problems highlighted associated with source and citation data transferred to Ancestry from both applications. The problem largely appears to be at the Ancestry end. I guess the problem for software developers is do you create a product that specifically targets another party’s application or do you create a product with features that serve a greater purpose. In FTM I have largely overcome the placement of data issue by structuring my citations accordingly so within that application so that I don’t get truncation in Ancestry. Whilst the output in Ancestry may not wholly conform to EE!, at least the information is there. For RM I have yet to fully determine the best structure to ensure no vital data is lost in the transfer due to truncation. When all said and done Ancestry don’t really care about conformance to accepted industry standards, Ancestry just want to sell their services to as many people as possible. For the serious genealogist I suspect the old fashion method of family history publishing will always be the way in which data entry, particularly for sources and citations, in good software programs will been developed. RM certainly seems to be on the right track with respect to that aspect. RM8 has a way to go interface wise but it is slowly improving and has potential.

[mikeb]

I understand it might be difficult to get Ancestry to make modifications to their API, but it’s worth a try.

If there is one thing that could be implemented from my wish list for TreeShare improvements, it would be that the length of the citations be increased to say 1,000 characters. I think some of the other shortcomings can be dealt with. It would at least allow the important information to be transferred even though it wouldn’t be EE true form. I was able to add the full long citation to the Detail Comment under Citation Detail, text, media, etc. heading in RM8.

It transfers nicely to the Ancestry tree under Citation Information just below the Details in a separate section called Other Information. It is missing italics for one field, and I replaced the “>” character with the character “|”, which I have seen used to separate items in a website path. When I was testing, I found that the Other Information category could accept over 20,000 characters. I know, I went a little overboard. I was looking for a limit.

The only problem is that the truncated citation detail still shows up in the Ancestry tree. That information has to be left in the RM record so that reports will be created correctly.

[JohnEChambers]

I agree the character limit is an issue but I think it is an Ancestry issue. The exact same problem exists when you sync FTM 2019 with an Ancestry tree. In FTM 2019 they have two citation fields “Citation detail” and “Citation text”. The “Citation detail field goes to the same field in Ancestry as does the equivalent RM 8 field. FTM 2019 data gets truncated so you lose important information. Getting Ancestry to change anything is nigh on impossible having tried to get them to fix a bug with their IOS app. I share your frustration.

[mikeb]

My initial suspicion was that the character limit is imposed by Ancestry. Doesn’t the RootsMagic team work with Ancestry regarding TreeShare, and can’t they propose changes to the API? It seems like a relatively straightforward task to increase the size of a text based data object. No data should be lost. As I mentioned earlier, some of the other text data objects in Ancestry trees allow over 20,000 characters to be transferred.

[JohnEChambers]

I suspect it has to do with how Ancestry implemented the GEDCOM standard. Each line in the GEDCOM standard has a character limit of 255 characters including white spaces. To populate a field in an application the application reading the data has to be programmed to read successive lines lines and concatenate the subsequent lines. I guess they made an assumption that the particular field would never have more than 255 characters. The same issue is prevalent in the Ancestry tree syncing feature in FTM 2019. In FTM 2019 the Citation detail field which goes to the same Ancestry field as RootsMagic’s data is concatenated if the data in that field is greater than 255 characters. The problem probably has something to with the historical ownership of FTM by Ancestry. The behemoth that is Ancestry is very unlikely to change for either RootsMagic or Mackiev the owners of FTM.

[thejerrybryan]

I have no idea if ancestry’s problem is the 255 character limit per line in GEDCOM or not. But if it is, then they are doing a terrible job of understanding GEDCOM. That 255 character limit per line has nothing to do without how big a note can be transmitted in GEDCOM. For all practical purposes, the length of a note in GEDCOM is unlimited. That’s because a note can be encoded as multiple GEDCOM lines via judicious use of GEDCOM’s CONC and CONT tags.

These essentially are tags that let you continue a note. You have to be judicious in how the CONC and CONT tags are mixed and matched because that’s the GEDCOM mechanism for transmitting line breaks that are in the notes. An actual carriage return character will terminate a line of GEDCOM rather than being a new line in a note. That’s why separate CONC and CONT tags exist rather than having just one GEDCOM tag for continuing a note, and not all genealogy software processes the CONC and CONT tags in quite the same way.

[TomH]

@mikeb
The issue of compatibility of RM sources and citations when interchanged with other systems predates TreeShare is a longstanding one. See
https://sqlitetoolsforrootsmagic.com/source-templates/#A-Trio-of-Templates
for some of my study when GEDCOM was the only channel between an Ancestry Tree and a personal database.

At heart, TreeShare is likely a subset of GEDCOM and the Ancestry database structure for Trees shares much in common with GEDCOM but adapted, interpreted and extended to support online features.

GEDCOM standards before 7 have no support for templates other than what corresponds closely, if not exactly, to RM 's Basic Book Template. But here’s the rub: RM converts all source types to its Free Form type on exporting to just two of the several fields for sources in GEDCOM, same for TreeShare. The irony is that TreeShare downloads in Ancestry Record Template which is a modified Basic Book Template. When RM uploads to Ancestry, it is likely converting it to FreeForm putting the sentence sans citation detail into Title and the latter’s field values concatenated into Page as it does for standard GEDCOM.

[mikeb]

TomH

Thanks for the history. My main issues are for very long citations that follow the Evidence Explained layered format, where the first layer is the source title and the specific citation, the second layer is mainly identifying online database or image locations, and the third layer is for the source of the source. The layers are separated by semi-colons. Second and third layers are not needed for many book type sources. I believe the basic source information is transferred properly via TreeShare for many of my custom RM source templates being used. They seem to be using the long footnote portion of the sentence up to the first citation field. They add words from the template that are not part of the field values, but don’t handle font formatting for italics (also no bold or underline, although I’ve had no need for those). It’s the citation information that is concatenating all of the citation fields and separating them by semi-colons, which conflicts with the layered approach used by Evidence Explained. They also do not handle italics or extra words that are part of the citation sentence. It seems like if the same methodology is used for the citation as for the source information, that would make the citation on Ancestry look better. And of course, for long citations, they get truncated at 256 characters. Ancestry would need to increase the field length to accommodate them.

My interest is only in transferring my RM data to Ancestry, but if one is interested in downloading Ancestry trees into RM, they could always transfer the source in one long field and the citation in another, essentially making all Ancestry to RM sources free-form. I believe that is how it is working now.

[TomH]

Ancestry sources are downloaded in the Ancestry Record Template structure which is why we saw that template introduced when TreeShare was launched. It did not exist previously. See
https://sqlitetoolsforrootsmagic.com/ancestry-treeshare-impact/#New-Source-Templates-RM75-RM8

Set aside Evidence Explained and your concept of “layers”, at least insofar as there being more than two. GEDCOM and effectively all systems whose database structures are compatible with it have only two levels:
SOUR {SOURCE}:=
The initial or original material from which information was obtained. (e.g., the book)
PAGE {PAGE}:=
A number or description to identify where information can be found in a referenced work. (obviously, the page number in the book source)

An example from the GEDCOM 5.5.1 spec:

0 @1@ INDI
1 NAME Robert Eugene/Williams/
1 SEX M
1 BIRT
2 DATE 02 OCT 1822
2 PLAC Weston, Madison, Connecticut
2 SOUR @6@
3 PAGE Sec. 2, p. 45
3 EVEN BIRT
4 ROLE CHIL
…
0 @6@ SOUR
1 DATA
2 EVEN BIRT, DEAT, MARR
3 DATE FROM Jan 1820 TO DEC 1825
3 PLAC Madison, Connecticut
2 AGNC Madison County Court, State of Connecticut
1 TITL Madison County Birth, Death, and Marriage Records
1 ABBR VITAL RECORDS
1 REPO @7@
2 CALN 13B-1234.01
3 MEDI Microfilm

The lines
2 SOUR @6@
3 PAGE Sec. 2, p. 45
are the citation, combining the PAGE (Citation Detail) info with the SOUR (Master Source) info under
0 @6@ SOUR

All the softwares that produce sentences from these fields recognise the most common tags and make assumptions about the sentence construct. The ones in common use are Title, Author, Publisher, Publishing Place… for the Source plus Page for the citation. Evidence Explained was not written for software developers nor does it consider the constraints of GEDCOM; rather it is about recommended content and style for many different kinds of sources for authors to use.

So software developers are faced with trying to fit many different shapes of pegs into one round hole when they try to support both EE styles in their software’s reports and websites outputs and transport of the sources and citations to 3rd party systems using GEDCOM and its ilk (TreeShare). RM’s solution for export is to use only the TITL and PAGE tags, regardless of the template structure. That makes some sense but I wish they had left open the option for the Basic Book Format sources to be exported intact as that structure would be preserved by almost all software that I know of.

So imagine trying to take an EE template with a dozen arbitrarily named fields in the Master Source and a half-dozen in the Citation Detail surrounded by conditional switches with conditional and non-conditional text and punctuation and mapping that into the very limited set of tags in GEDCOM. Each source template would need to have its own export template to create something that would work well across many platforms. That is, a sentence template for the TITL tag and another for the PAGE tag. That has been requested long ago because RM has only the sentence template for its own reports, which you would still want. And so its solution was to export to TITL the sentence stripped of the Citation Detail field values and dependent text and punctuation and concatenate their values to the PAGE field. The other software then, hopefully, reassembles those as TITL, PAGE without extraneous stuff.

[mikeb]

My point regarding the layer concept is that the length of a multi-layer source/citation often increases beyond what is currently allowed in Ancestry trees. Both the source and the citation detail fields in Ancestry are limited to 256 characters. Therefore long citations created in RM get truncated. I can see that the construct of complex source templates would be difficult to program as part of TreeShare. I am not suggesting that additional layers be accommodated, but rather have the citation (or PAGE) include any additional layer information not part of the basic source (or TITL). If Ancestry allowed longer citations, that would solve the truncation problem.

It seems next to impossible to have Ancestry source/citations uploaded to RM with all the fields generally used in RM source template constructs. I like the way RM handles the footnote constructs for its own reports, but just wish the long footnotes would all transfer into Ancestry.

[TomH]

The length limitation is not just an issue with Ancestry Trees. It is an issue with GEDCOM and some other software as well. Arguably, it would be solved also if the software restricted data entry so that the output to a tag value (whether GEDCOM or TreeShare or FamilySearch Family Tree) was restricted to the maximum allowable length. But even Ancestry disregards that with its own generation of text for sources which can be truncated in the download via TreeShare or GEDCOM.

Within RM, the easiest place to apply that restriction would be on the FreeForm Footnote and Page fields but it should also be feasible to measure the aggregates from a templated source that would be exported individual tags or fields and prevent entry or give warning whenever it is exceeded.

Tom

[thejerrybryan]

On most any genealogy topic, Tom has more expertise than me so I’m reluctant to stick my neck out with a question. But here I go anyway.

It was a long time ago, but I did once upon a time spend some time studying the way GEDCOM deals with sources and citations. I came to the conclusion that there were four GEDCOM tags of interest. There were the obvious two, namely SOUR and PAGE which have been well discussed in this thread. But my conclusion was that you also had to deal with the ADDR and REPO tags to the extent that your sources and citations dealt with repositories.

With so many things online, I think the whole treatment of repositories needs to be re-examined. And even before things were online, was the real repository for a reel of census microfilm my local genealogy library or was it the National Archives? But in any case, it seems to me that footnote sentences sometimes include repository information that is outside the scope of GEDCOM’s SOUR and PAGE tags and which instead involves the ADDR and REPO tags.

To tell you the truth, I’m interested in reducing this down to just one GEDCOM tag - call it FOOTNOTE if you wish, even though that’s more than four letters. But I’m sure there must be a fatal flaw in my scheme.

[mikeb]

Looking at the GEDCOM created from my RM file, it appears that the source that is being transferred through TreeShare to my Ancestry tree comes directly from the 0 @S1312@ SOUR, 1 TITL and the two continuation lines 2 CONC shown below. This matches the source portion of the long footnote in RM.

0 @S1312@ SOUR
1 ABBR Finland, Oulu, Kuusamo Church Records, births & baptisms, 1837-1855
1 TITL Kuusamo seurakunta [parish] (Kuusamo, Oulu, Finland), Syntyneiden luett
2 CONC elo [List of births], IC: 5, 1837-1855, (also includes marriages and de
2 CONC aths).

The citation appears to be coming from the PAGE tag for this source shown below, which is 548 characters excluding the 7 characters of 3_PAGE_. This was all on one line in the GEDCOM and was built from the individual fields in my citation separated by semi-colons.

2 SOUR @S1312@
3 PAGE birth / baptism entry for Johan Kallungi, 28 January 1846 / 20 February 1846, unnumbered pages arranged chronologically by baptism date; Kansallisarkisto [National Archives of Finland]; Digitaaliarkisto [Digital Archives]; browsable images; Digitaaliarkisto ||http://digi.narc.fi/digi/puu.ka; http://digi.narc.fi/digi/view.ka?kuid=5583057; downloaded; 24 September 2021; > Kuusamon seurakunta > Kuusamon seurakunnan arkisto > Syntyneiden ja kastettujen luettelot > Syntyneiden luettelo 1837-1855 (IC:5); image 77 of 215

What seems to be transferred to my Ancestry tree is shown below, which is truncated at 256 characters not counting the 7 characters of 3_PAGE_.

2 SOUR @S1312@
3 PAGE birth / baptism entry for Johan Kallungi, 28 January 1846 / 20 February 1846, unnumbered pages arranged chronologically by baptism date; Kansallisarkisto [National Archives of Finland]; Digitaaliarkisto [Digital Archives]; browsable images; http://digi.nar

It appears to me that the SOUR tag and the following TITL and CONC tags may be used to transfer the main source, and the PAGE tag is used for the citation by TreeShare. It would seem that Ancestry truncates the PAGE tag to 256 characters. To me it seems natural that the PAGE tag for the citation could be created by RM to follow the same logic as the SOUR, TITL and CONC tags. My thoughts are that if the PAGE tag size could be increased by Ancestry, then all of the additional information used to create long Evidence Explained source/citations could be added as part of the citation portion. Then everything could be transferred with SOUR and PAGE tags.

As a side note, the GEDCOM file has a FOOTNOTE tag which matches exactly with the long footnote template from my RM file. All of the field names are also found in the GEDCOM file.

1 NAME __Church Records (online images)
1 DESC Church records; church & series as lead element
1 CAT [EE, QC-7, p314]
1 FOOTNOTE <[Church_Author]>< ([Location])><, [RecordSeries]><, [RecordBookID]><, [
2 CONC RecordType]><, [ItemOfInterest]><; imaged in< [WebsiteCreator], > [W
2 CONC ebsiteTitle]><, [ItemType]><, ([Permalink_URL] :>< [AccessType]>< [
2 CONC AccessDate])><, path: [Path]><, [Image_ID]><; citing [Citing]>.

[TomH]

@mikeb, yes, you’ve refreshed my memory and got what I described:

1. RM transmits (exports) data more or less in accord with the GEDCOM 5.5.1 spec
2. The specified maximum length of a GEDCOM line is 255 characters including the tag.
3. For Sources, RM transmits with the TITL tag the Footnote sentence constructed from the template variables and sentence template but devoid of the Citation Detail fields and dependent text and punctuation. The TITLe tag value can be extended with CONCatenation and CONTinuation (new line) tags. In the case of FreeForm, the entire value of the Footnote field (not the Footnote sentence) is sent to TITL. The spec’d maximum length of the TITL value is in the ballpark of 4000 altho’ I cannot find the reference (the spec shows {1:M}). edit: 5.5.1 set no max; the gedcom.org 5.5.5 fork spec’d 4095
4. For the citation, RM concatenates all of the values of the Citation Detail fields, separated by semi:colons, and appends the result to the PAGE tag (WHERE_WITHIN_SOURCE) whose value is spec’d limited to 1 line of 248 characters.

The limitations are a legacy of the specifications’ evolution from the earliest days of personal computers and the maintenance of some level of backwards compatibility. There may still be software in use whose database system has defined field or column widths determined by those limits. That is not the case for RM since v4 with SQLite but may have been in previous versions using a xBase engine. We know even less about Ancestry’s limitations.

So it is interesting that you found that RM exported a string 548 characters to GEDCOM as the PAGE value and Ancestry displayed that value truncated at 256. What we do not know is whether the truncation occurs because of a TreeShare specification that RM must abide by or because Ancestry’s Tree database is the constraint. You might try editing the citation in your Ancestry Tree to see if the value can be extended. I did this a couple of years ago but don’t remember and there have been many changes on that side in the interim.

What is also interesting is that the entire source-citation sentence could be accommodated by the TITL tag. Perhaps that is true also on the Ancestry Tree side and you might wish to try it and find the limit. If so, then it is another justification for the use of extremely split sources in RM. The footnote sentence is delivered complete, intact, exactly as generated in a RM report with very little risk of truncation (that would be a footnote longer than a page!).

Moving the mountain beyond 256 characters is not going to be easy. I asked Ancestry for it more than a decade ago. Easier and immediate is to adapt one’s practices to work within the limits.

And, re your side note, the FOOTNOTE tag is RM’s proprietary customisation of GEDCOM that only a few other softwares recognise. It is exported along with other custom tags when you check the option in the export dialog to include RM special features and is the means by which custom source template definitions can be transported between RM databases.

[TomH]

@TomH

Moving the mountain beyond 256 characters is not going to be easy. I asked Ancestry for it more than a decade ago.

That is one of the major things GEDCOM 7 sets out to do. It will eliminate the CONCatenation tag as it would be unneeded. So when both Ancestry and RM start exporting and importing GEDCOM 7 files, there is a possibility that TreeShare constraints would also be lifted. Are we anywhere close to seeing GEDCOM 7 from either of them? I doubt it.

RM official statement regarding GEDCOM 7.0

7 Jun 2021 - RM official statement regarding GEDCOM 7.0: Today, FamilySearch released the official specifications for GEDCOM 7.0, the standard file format for transferring and archiving genealogical data. With many others, we’ve played a part in guiding the development of GEDCOM 7.0. Since it was just officially released today, it may take some time to add support for GEDCOM 7.0 to our different products. We have no official timetable for when it will be available or what specific features we …

[mikeb]

TomH, Thanks again for your detailed replies.

I did try editing the citation in my Ancestry Tree and determined that the value cannot be extended beyond 256 characters. I also tried it with the source and it also is limited to 256 characters. In a different string on the RM Community, someone suggested using the Detail Text Comments field in RM for the additional source/citation layer information. It shows up in the Ancestry tree under the heading “Other Information” below the “Detail” in “Citation Information”. I tried that and it worked. I even experimented with it and found that TreeShare could transfer upwards of 20,000 characters into this field. If Ancestry can allow long text strings in this field, it seems like they could probably allow it in the source and citation fields. The GEDCOM file for this test named the field “NOTE” as shown below. This contains 404 characters.

3 NOTE ; imaged in Kansallisarkisto [National Archives of Finland], Digitaalia
4 CONC rkisto [Digital Archives], digital images, (http://digi.narc.fi/digi/vi
4 CONC ew.ka?kuid=5583057 : downloaded 24 September 2021), path: Kuusamon seur
4 CONC akunta | Kuusamon seurakunnan arkisto | Syntyneiden ja kastettujen luet
4 CONC telot | Syntyneiden luettelo 1837-1855 (IC:5), image 77 of 215; citing O
4 CONC ulun maakunta-arkisto [Oulu Provincial Archive].

This is how it looks in the Ancestry tree:

There is an option within RM that appends the Detail Text Comments to the end of the footnote, so this can be done as a workaround, but it kind of defeats the advantages using the source templates to create complex footnotes. I am not sure how this transfers in TreeShare when uploading an Ancestry tree to RM. I haven’t tested it yet.

[TomH]

@mikeb

There is an option within RM that appends the Detail Text Comments to the end of the footnote

That’s a Report option, not available in TreeShare.

Thanks for confirming that the Source is also limited to 256. That was my hazy recollection. So TreeShare is not even supporting the GEDCOM Source-Record structure which allows a value for TITL to be extended across multiple lines.

Have you looked at what happens when you TreeShare download your uploaded sources to a new database? Apart from the loss of template structure, I think the same Source for different people will be transformed into independent sources (unless RM is auto-merging duplicate sources).

[TomH]

@TomH

The spec’d maximum length of the TITL value is in the ballpark of 4000 altho’ I cannot find the reference (the spec shows {1:M}). edit: 5.5.1 set no max; the gedcom.org 5.5.5 fork spec’d 4095

5.5.1 is a FamilySearch specification (drafted in 1999, promulgated as a Standard in Nov, 2019)
5.5.5 is a GEDCOM.ORG specification created by an independent group seeking to clean up the somewhat higgledy-piggledy, ambiguous, inconsistent and loaded with historical baggage predecessor. Published in Oct, 2019 - did that trigger the Nov release by FS of 5.5.1 as a Standard?

From page 20 of 5.5.5:

The GEDCOM 5.5.1 specification did not set maximum length for the records concerned. The
GEDCOM 5.5.5 specification sets their maximum length at either 248, 4095 or 32.767 (2^15-1)
code units. This is in deference to the old (GEDCOM 5.5.1) rule that GEDCOM records should
fit into a memory of less than 32KB. A Unicode application using UTF-16 internally will need no
more than a 64 KB buffer to hold the largest legal values.
item maximum
IND.DSCR <PHYSICAL_DESCRIPTION> 4095
SOUR.AUTH <SOURCE_ORIGINATOR> 248
SOUR.TITL <SOURCE_DESCRIPTIVE_TITLE> 4095
SOUR.PUBL <SOURCE_PUBLICATION_FACTS> 4095
SOUR.DATA.TEXT <TEXT_FROM_SOURCE> 32.767
SOUR.TEXT <TEXT_FROM_SOURCE> 32.767
NOTE <USER_TEXT> 32.767

GEDCOM 7.0 also seems non-explicit with respect to the limit on the length of a line value (although a superficial read might suggest it’s x10FFFF or 1MB) or the maximum payload spread over multiple CONTinuation lines. From page 15 of FamilySearch GEDCOM 7.0:

Previous versions limited the number of characters that could appear in
a tag, cross-reference identifier, and line-value. Those restrictions were removed
in version 7.0. The CONC pseudo-structure, which allowed line values to have a
shorter length restriction than payloads, was also removed