Family Historian User Group

I'm a bundler.

I maintain a single source for FamilySearch.org.

I collect hundreds of references from FamilySearch.org.

Birth records, death records, marriage records, probate records, census records, etc.

When I find a block of text from the source I insert it in the "Text From Source:" block. It comes with the handy "..." expander and I can make sure the block of text looks right.

My source citation I insert in the 'Where within Source:" block.

But "Where within Source" doesn't have a "expander".

I'll assume because it's just for Volume and/or Page information.

But that's rather old school.

My "Where within Source" for FamilySearch.org looks like

"Iowa, County Marriages, 1838-1934," index, FamilySearch (https://familysearch.org/pal:/MM9.1.1/XJN2-B4V : accessed 23 Sep 2014), Henry B. Hoover and Lucinda Heckathorn, 11 Apr 1872; citing Creston, Union, Iowa, United States; FHL microfilm 1728321.

It's not really "Text" from the source. That would be:

Name: Henry B. Hoover; Spouse's Name; Lucinda Heckathorn; Event Date: 11 Apr 1872; Event Place: , Union, Iowa

The reason for an [...] edit box button for some text fields and not others is that there are two types of GEDCOM text field:

1. Long-text fields, such as the many Note fields, and the Text From Source fields, are completely unlimited in length, and allow multiple lines that clearly need an edit box.
2. Short-text fields, such as Place fields, and Where within Source fields, are required to support only a limited number of characters (typically 120 or 248) that must all be on one line, which means they are subject to the GEDCOM line length limit.
   However, those limits are often relaxed in most current genealogy products.

So, provided the text is all on one line, short-text fields can be quite long, and would benefit from an edit box.

I am thinking of creating Wish List entry to request and edit box for all short-text fields, but emphasize the need for at least Where within Source.

So far as I can see, Where within Source is 248 characters. Almost certainly umpteen programs can read much more but Mr Murphy will ensure that, while all Beta-testers' other software can accept more than 248, the first guys with the final version will have stuff that fails on longer lengths or in having a new-line.

So I agree that we need some user interface that validates length, lack of line feeds / new-lines (not sure exactly what should be prohibited!), while (a) allowing people (especially the Method 2 guys?) to enter long text and see it all at once and (b) giving them a visual clue that this is a single line item, not the multiple line one.

The other one I'd like to have this expansion is the Short Title of a Source Record. My latest record has "Monumental Inscription: XXXXX, YYYYYY, Woodlawn Memorial Park (Colma, California)", where I lose clear visibility in the Property Box of everything after the Woodlawn. I think this should only be 60 characters and my real version (the chap's name is not XXXX YYYY) is well over 60 characters! So I think that the validation on item length should be a warning only, not a rejection! If indeed there is any justification for changing whatever the current validation is.

Adrian, your requirement justifies my suggested request of an edit box for all short-text fields.

There is no problem inhibiting line-feeds/new-lines, because that restriction is already applied to those fields, and would carry over to the edit box. It is only line-feeds/new-lines (and perhaps carr.ret.) that need inhibiting in order for the text to remain in one GEDCOM line.

As has been discussed before, the GEDCOM character size recommendation is a minimum NOT a maximum.

GEDCOM 5.5 Page 37 says: The field sizes show the minimum recommended field length within a database that is constrained to fixed length fields. The field sizes are in addition to the GEDCOM level and tag overhead. GEDCOM lines are limited to 255 characters.

However, the existing short-text fields in FH can exceed those limits without any File > Validation complaints. I have experimented with short-text fields PAGE and ABBR with over 500 characters without any difficulty, and they are saved and re-opened in FH OK. The only slight risk is that some other products may enforce the GEDCOM lengths, but my experience is that they don't.

Agreed

tatewise wrote:I have experimented with short-text fields PAGE and ABBR with over 500 characters without any difficulty, and they are saved and re-opened in FH OK. The only slight risk is that some other products may enforce the GEDCOM lengths, but my experience is that they don't.

I have some Death Causes that are fairly lengthy, and I found that they were truncated in RootsMagic, which meant I had to abbreviate them for the Cause and put the full version in the Death Notes. These were in the region of 100-110 characters.

I was pleased to find that FH will accept the full phrase, though it is a bit frustrating that I need to expand the Property Box to around half the width of my screen in order to read it all.

Arthur

Arthur, the GEDCOM minimum length for the Cause field is 90 characters, so it's legitimate for RootsMagic to truncate it.

To see such long text in FH you can put the cursor in the field and use the left/right arrow keys on keyboard to scroll it.

However, an edit [...] button would be more convenient.

Wish List item Ref 545 Edit box for short Text fields has been added.

tatewise wrote:To see such long text in FH you can put the cursor in the field and use the left/right arrow keys on keyboard to scroll it.

However, an edit [...] button would be more convenient.

Yes, I'd worked out about the scrolling, but I'd much prefer a button as you suggest.