On Feb 16, the FamilySearch Integration PR was opened:
I decided to start a discussion here, rather than on github, as I don’t think we all have agreed on exactly what the criteria for the integration is, and wanted to make sure that @SourceAirbender (and others) understood our agreed upon expectations.
First, a lot of work has already been done so far! Almost 19k lines of code.
My first concern is that almost all of the code is in gramps/gui/fs/. I think this would make the functionality difficult to use from, say, gramps-web. I would think the code should be separated in the same manor as the rest of Gramps: lib for object definitions, gen for other code. This would be a large refactor, and probably will take quite a bit of time to separate the GTK gui parts from the business logic of the rest.
The PR requires database changes (we also have another PR with schema changes, so we’ll have to coordinate those changes). But the upgrade code should be standalone in the gramps/gen/db/upgrade code, as it may require more changes in the future.
The schema change adds a new table. But it might make more sense to add that info as a JSON field in the Person table. That also allows added similar fields to other tables in the future.
It might make sense to break the PR into three or more parts: the database API, the objects, the algorithms, and the GTK code. We need tests at all three levels.
We are working closely with FamilySearch to meet their compatibility requirements and become a solution provider. This has meant that we have been willing to take their advice as far as the functionality is concerned. However, we do retain control of how the features are implemented.
I agree with two of your main points:
I would expect to see the non-gui code in gramps/gen/fs/. This may be as simple as moving files and changing imports in some cases.
It would be preferable to add JSON to the existing Person table rather than creating a new table if possible.
Discussions about how and when we deliver a FamilySearch compatible Gramps are ongoing. The outcome of these could affect our choice of splitting the PR or creating a GEPS branch.
Currently, the upgrade code is in self._create_familysearch_sync_schema() But we need that extracted like the other upgrade paths into specific functions for version 22. Why? What happens if we want to change the FS schema further? We need another upgrade that will take a user from 22 to 23 (and beyond).
It will also help us merge the other version 22 upgrade PR mentioned above.
wow! More than 300 translations needed. A lot regarding familysearch. Well, I have started.
That’s a LOT of translation churning. Could that this string expansion be run through LLMs? … to see if there isn’t some redundancy that could be optimized out.
Every eliminated string will immediately benefit more than 40 Weblate translators And reduce the WikiContributor burden for not only translators but also the composer of the original article.
Perhaps you could do a Weblate export, run the CSV through an AI translation and tweak the results. Then track down the source code to do some _string consolidation.
I am not suggesting that an AI do the translations… at least, not as a first pass.
I am requesting that the 300 terms/strings first be compared against themselves. And any closely matching strings can be harmonized to reduce the count. (This pass would give an idea of how internally consistent the new code is. If there is a high incidence of slightly differing strings, it is probably worth searching for redundant code that could be consolidated too.)
And the 2nd pass be compared for similar meaning strings that already have Translations in the Gramps core and addons. (After 25 years of development, it would hard to imagine how Gramps could be still be missing 300 genealogy related concepts. Or how there could be 300 string related to synchronizing tasks.) Then the new FamilySearch strings be changed to reuse existing strings.
I see what you mean. There are lots of strings because there’re lots of new interfaces and submenus. But you bring up a good point, it would be useful to reuse strings if and where applicable. I’ll do a pass sometime this week like you mentioned and see if there’s anything matching your criteria.
Just finished the translation. Not to much redundancy, but some. “Working” and “Working…” would be considered two different phrases.
“this” and “this (that)” might have been possible to do otherwise.
However what irritated me most was the number of times I had to type FamilySearch. I finally installed autokey on my mint box, and used the phrase option.
Anyways it took some time, but now it is done. I think a weblate training class would be helpful, because I found some “gold nuggets” I wasn’t aware of.
A reasonable outside observer might take this as an indication of potential acquisition of Gramps by the FamilySearch International non-profit. The February 9, 2026 formation of the Gramps Genealogy Foundation non-profit would lend credence to such wild imaginings.
(There will need to be a very public statement somewhere about the timing not being coincidental. But was a necessary prerequisite to gain FamilySearch API access.)
Which reinforces the thought that the FamilySearch logo should NOT be allowed to become a fixture in the status bar. It could be in any dialog that has a significant FS integration GUI. And the icon (or a 22x22 variant?) could replace the reiteration of “FamilySearch” in 95% (or more) of the strings occurrences. (Although the pervasive use of that logo could undermine the initiating relationships with other genealogical content providers.)
The use of external branding inside the application may need to a policy.
It might even be prudent to select a different icon for the Charts Category view mode for Pedigree to reduce diluting the “branding” of the Gramps logo. Or adopt new logos for the Gramps Genealogy Foundation, the Gramps for Desktops Gtk-based application, and the Gramps Engine. (Logos associated with Gramps or services that support it.)
icon (or a 22x22 variant?) could replace the reiteration of “FamilySearch” in 95% (or more) of the strings occurrences. (Although the pervasive use of that logo could undermine the initiating relationships with other genealogical content providers.)