I’ve mentioned the aurhor on Geneanet about rhe current thread
1 Like
About the readme file, no I’ve got the three languages one
That’s a pity. A smart document delivery system would simplify so many problems.
There is no need to use weblate , with included .po file and Poedit the translation is easily done.
Very preliminary testing of gramplet raises doubts is it dangerous to import data with it?
I suspect so. Anything working with merge or sync is going to have hidden complexity issues. That’s one of the good reasons to start beta testing the Gramplet heavily.
Even if the gramplet doesnt have technical problems, the quality of data in the FamilySearch world tree is awful. (The same is true of WikiTree.) Although it is very good for collating research data and relationship theories. So many people are adding possible sources for each person/event. Many are mismatches … but good research is as much about determining what is ‘wrong’ as what is ‘right’.
You have winnow through the chaos after a download, then be selective about what you bring into your main tree. So always download into a new tree or a separate FamilySearch tree.
And I ALWAYS import a disimilar fomat into a blank Gramps tree. Then vet the data and structure before exporting a subset into .gramps xml format. I will only import a .gramps XML into my primary tree.
I like the possibility of downloading a set of “My Contributions” from FamilySearch too.
OK, I can download Poedit, and work on the Dutch version, and hope someone else does the English one.
But OTOH, conversations about Weblate suggest that that can do such things too? Or is that not the case, and is Weblate for documentation only? Documentation (and help files) has a clear stucture where you have separate documents (or chapters) per language. PO files OTOH always have two languages, so the tool must understand their structure, so that the source text isn’t changed.
OK, me too, but it points to other readme’s in Esperanto and French. And the French one can be used as the basis for other translations, because that’s the only one that has proper instructions, for hackers at least.
I didn’t do a real import yet, but I found a few problems, as far as I could test it in Esperanto.
-
For some close relatives, like my grandfather, I couldn’t register a match with FS, even though he was found in the tree (I put him there). I’m not sure about the cause yet, but it might be that he already has a couple of attributes, and the Gramplet can only add the _FSFTID attribute to an empty list. That is quite weird, but circumstances suggest it, because I could match persons without attributes, and saw that they got the proper _FSFTID attribute after commit.
-
Sending data to FS doesn’t work. And TBH, I am quite happy about that.
-
It seems like, when I search for a match, but don’t commit it, a database transaction is started but not closed. It doesn’t seem to cause any damage, but I found this when I tried a check & repair shortky after this, and got an exception, which didn’t go away until I closed Gramps and reopened my database. A subsequent check & repair then showed that everything was good.
I want to add that I really like the search feature, because it helps me check what I have against the Borg collective. Many Dutch parts of the tree have lots of sources attached.
I noticed that @emyoulation filed two issues on GitHub, but I didn’t see any response.
One had a Response. He discovered and replied that the gramplet wouldn’t load with the Windows AIO version of Gramps. There were incompatible prerequisites. When I recently switched to linux, the gramplet now loads.
But I wasn’t successful discovering where The Gramplet expected users to store the FamilySearch profile IDs. It was an Attribute and the docs listed an Attribute name for storing that value. But it didn’t work with the Attribute at the Person level. So I’m wondering if it is looking for a Citation attribute or other place? Got it to work with the info you posted.
OK, nice! I filed a new issue yesterday, because I got an error searching for a person who has a birth event with a place, and no date. And another user made a report for what I wrote about the problem linking a person who already has an attribute at the person level.
The French title says “Impossible to link if an attribute is already present”, and it was reported by @oliber .Thank you!
The author just fixed this, and the no date issue, and asked me to test these, and the fixes work here.
He also wrote that there are more fixes and additions in his dev branch, but for those, you will first need to apply a tiny patch to Gramps itself. And I prefer not to try that part yet, although I may try later this week.
@oliber have you tried that dev branch already?
I just opened a bug report about the patch 0012864: ListModel: checkbox won't work if list_mode=tree - Gramps - Bugtracker – Free Genealogy Software
But it causes problem only for the checkboxes (for the selective import) so you could test most ot the other features without changing gramps.
It’s definitely a bug in gramps: the file gramps/gui/listmodel.py allows 2 list modes but checkboxes work only with list mode. The least Gramps could do is catching the error and documenting that one shouldn’t use that feature.
PersonFS just reveals that bug in Gramps.
Does the problem exist without PersonFS installed?
That the problem occurs with PersonFS installed, maybe the PersonFS is breaking Gramps. If this is the case, the problem belongs with PersonFS.
We have several problems here:
1 - This plugin is not supported by gramps developpers.
2 - That plugin needs a key to interract with this proprietary company. We don’t have it.
3 - This plugin is written in spanish or esperanto. No developpers speaks spanish or esperanto.
4 - All our views work correctly with this list model.
So it is a plugin problem.
The path index with a column is not used in gramps. This is why we don’t need it.
The plugin must conform to our needs, not the contrary.
I guess there’s no point in going on here about the bug but I just added to the bug report a minimal reproducible example showing that bug prevents gramplet developers to use Gramps’ ListModel as a treeview if they want to use checkboxes.
If the developers of PersonFS want their app to integrate with Gramps, then they are the ones that need to make it happen. Gramps does not need to alter its code to accommodate PersonFS.
I think @oliber is noting that while the add-on could be changed (and “SHOULD be changed” for the 5.1 compatible add-on) to workaround a implementation flaw in the core, the core feature doesn’t work as documented.
It just hadn’t been used before.
So this issue should actually be reported & addressed separately in the FS GitHub repository for the plugin & in MantisBT for this incomplete core implementation.
It might be a necessary to keep some separation between a FamilySearch add-on and the Gramps-Project.
To make software that touches the FamilySearch API requires executing an agreement. And since the project doesn’t have a legal entity with signatory authority, we can’t do that and probably should NOT distribute this add-on through the Gramps add-on server.
People can download from a 3rd party and install on their own authority. Our software just touches the 3rd party software that touches the FS API.
It will probably be the same for any other big player with an API license that isn’t GPL compliant. (Incestry has consistently demonstrated predatory business practices: Buying non-commercial competitors while assuring continued access & platitudes, then dismantling or not maintaining the service. So we should carefully avoid getting entangled in any weasel-worded portions of their API licensing.)