Yesterday, Patrice referenced a rather long thread on Geneanet:
And in that thread, another user presents a Gramplet that can be used to search persons in the FamilySearch tree, import data, and maybe do some other things that I haven’t figured out yet. And that sounds very interesting, but there is a bit of a problem:
The Gramplet only speaks Esperanto and French.
And that leads to a question: Can anyone help to translate this in English (or Dutch)?
@PLegoux do you know whether the author is on site here too? I saw your name in the thread, and Eric Doutreleau, and even Jerome, but I don’t know their aliases.
Follow-up to @grocanar and @romjerome. Can you give your opinion on this, and maybe provide some help with translations? The Gramplet shows up in Esperanto here, which is a bit harder than French.
Does this gramplet allow downloading of their FamilySearch user account Contributions? Or just specific individuals in that tree? Or a number of generation limited pedigree/descendants of an individual?
If it did a person’s Contributions, this might be the “backup” tool many FamilySearch users have been seeking. (Or if it did JUST their contibutions of ‘living’ individuals. The ‘Private’ feature for Living on FamilySearch doesn’t have any known workaround.)
Well, at the moment, I can’t test much, because it speaks Esperanto to me, and that’s harder than French, even though my education in Latin helps a bit. I am used to the fact that add-ons default to English, when there is no Dutch translation available, but this one is written in Esperanto, and French, and it seems that it defaults to Esperanto, unless I tell Gramps to run in French.
At first glance, I see features to download a few generations, like get my ancestors does, and to synchronize individual persons. And I guess that the synchronization is one-way, meaning download only, because we have no license to write to the FS tree.
And selective backup, meaning download, is something that I haven’t seen in any industry FamilySearch app yet, so I guess that it’s not available. And I bet that FamilySearch doesn’t want that either, because it conflicts with the collective. We are Borg!
OK, I get it. I don’t have many private persons on it, but I would really love it to see a better way to monitor and sync persons that I’m interested in. Downloading updates with Ancestral Quest or RootsMagic and then merging things back into Gramps is a real drag.
If the gramplet is already translated to Esperanto, it should be Weblate ready. Unfortunately, the only person I know who has used Weblate in English is @Nick-Hall . He did the UK translations for Gramps.
Maybe if he does a UK translation for the Geneanet Gramplet, he can duplicate the strings for the default US?
The Isotammi group ( @kku@PeterPower@jpek-m@TimNal ) has kindly done US english translations of their Finnish gramplets, but I do not know if they are using Weblate either. They might want to do a Finnish translation of this Geneanet/FamilySearch Gramplet too. It fits their collaborative genealogy model.
The ‘problem’ here is that it’s written in Esperanto, meaning that not only the variable names, but also the text strings are Esperanto. So the whole translation issue is not US English to whatever language we speak, but Esperanto to … and that’s to French only right now.
I must add, that as a developer, I can detect a lot of things by reading the code, because Python itself is still English (made in Holland), and the FamilySearch API has English type definitions too. But the trouble is, part of those are also converted to internal types which are again defined in Esperanto.
I’m glad that I had 3 years of Greek too, so that I can recognize quite a few words, when I see them in context in code, but all in all, it still makes things more difficult.
I can of course fork it, and do my own thing, but it would be mich nicer to get the author on board.
I also don’t know much about Weblate, but I may use some tricks from Visual Studio, because in my heart, I’m still quite a Microsoft guy.
I wonder if weblate’s interface will ‘normalize’ to offering Translators english strings instead of a the esperanto as the ‘source’ once that translation is done? Or if it stays with the original to avoid error creep that could come with triple translating.
I really have no idea, and I’m afraid that it doesn’t fit my learning style, and my autism. I’m the type of guy that needs to download something, and then start exploring by trying things, in my own pace, bottom-up. And when someone, or some thing, like this weblate, starts pushing things on me, I give up right away, and start ghosting.
I just forked this Gramplet project, and pasted its URL on the weblate site. And then it asked me for things that I have no idea about, for the simple reason that I did not understand what it was asking.
Is there some sort of tutorial project, so that I can see how it’s done? Where I can learn by example, with baby steps?
It seems you also could write Gramps data into the FS tree: “création d’une fiche FamilySearch à partir de la fiche Gramps” (creating a FamilySearch record from the Gramps record)
Yes, I saw that too. I found that text in the language file too.
Did you try this yourself? I am a bit surprised, because I’ve always thought that programs need official certification, before they can write to the tree, and you would need a special key for that.
Note that for me, it doesn’t make much sense to maka an English translation, because my Gramps runs in Dutch, and I assume that the standard behavior is that it will default to the original language when the NL file is not found. And that original is Esperanto.
Sorry, that was from an earlier posting that tied Eric to this Gramplet. Or maybe my poor thinking that his Geneanet add-on was associated because the mention of the Geneanet announcement. But it looks like we don’t need to bother him. I don’t know if the gramplet author (jmichault) has an account here or on Geneanet.
A question: I note that the GitHub repository for this gramplet has “ReadMe” markdown files where the filename is translated to Esperanto ( LeguMin.md ) and another to French ( LisezMoi.md ). If your OS language is set to French, is GitHub smart enough to automatically deliver the LisezMoi.md instead of the English ReadMe.md when browsing a repository? (I doubt it … since there is a multi-lingual ReadMe.md with French and Esperanto branching links in this Gramplet repository.)
If so, that might give us some direction for Multilingual documentation organization. I was thinking that it would require adopting a language code notation in the filenaming. Like ReadMe.fr.md or ReadMe_fr.md ( Our MediaWiki prefixes the webpage with “fr:” That hasn’t been working too well for keeping our files tidy. This would not help with ‘tidy’ but we might have to comply with GitHub documentation delivery standards.)
The readme’s are not really translated, in the sense that their contents are the same. Only the French one has all the instructions that you need to download the Gramplet, either as a ZIP file or using Git, and how to use it.
It also mentions two dependencies, but it does not mention how to install those. I installed them with PIP.
What’s the best way to create a proper translation for this particular Readme? I can imagine, but haven’t tested this, that one can use Weblate for that, once you give that the right pointers, so that it can automatically generate new translations when you push a new version of the French version to GitHub.
The reason I am asking is that @Nick-Hall is expanding the help_url functions in the plug-in registration. (In 5.1.x, only ‘Gramplet’ type plug-in registrations support a help file. And they are not consistently defined. So NONE of the Tool, Report, import/export , etc. plugins have a help_url. This means either we have a fallback or DOZENS of plugin registrations need to be laboriously tweaked.)
Since GitHub is standardized on a README.md in each repository AND those documentation files tend to be included when addons are downloaded by the Plugin Manager.
So it seems like the local README.md would be a good fallback documentation if no help_url is included in the plugin registration file. (And the repository subfolder’s README.md would serve that purpose for the PreInstall. The archived one could even be extracted on demand … with some overhead penalties.)
Moreover, if GitHub has a language scheme, then the fallback system could be multi-lingual.
