Recently, I have been taking a closer look at how to translate my addon FamilyTreeView (FTV, see the original announcement thread and (since it was split due to length) the current thread, as well as the Github repository). Thanks to everyone who gave me insights and pointed me to other resources on how translation of addons works!
Packaging the addon also creates a template.pot file (with about 300 entries). Currently this file is discarded. I will change the GitHub workflow to keep this file, once everything is prepared. My understanding of the subsequent process is as follows (please correct me if I’m wrong):
Translators can then use the template.pot file to translate the strings, e.g. with poedit (see @kmikkels post here, poedit’s GitHub repo or poedit’s website).
The resulting XX-local.po will be merged with a pull request.
When packaging the addon,
the subdirectories and the file locale/XX/LC_MESSAGES/addon.mo are created in the package, and
the addon is added to addons-XX.json in the listings directory.
Gramps will find these files when the user’s language preference matches one of the translated languages.
While FamilyTreeView is still under development, you should not rush to translate the whole addon into as many languages as possible, because some strings might change before the first non-beta release. Currently I’m more interested in:
Testing the workflow of translating the addon, from providing the template.pot file all the way to a translated string/label in the UI of an end user who installed the addon using the Addon Manager.
Finding strings in FTV’s code that do not yet allow translation, e.g. I forgot to add _(...).
Figuring out where strings need handling of singular/plural forms, masculine/feminine forms, and/or context, etc. to be translated correctly.
Compiling a list of volunteers who would like to translate this addon in the future.
The following people have already offered to translate FTV:
If you would like to help to translate FTV into another to other language, I (and most likely others who use your language) would be delighted! Ideally, there are multiple volunteers for each language to review translations.
(I’m also interested in general feedback from people using other languages/writing systems, e.g. UI/UX, RTL scripts, name abbreviations in other cultures. Feel free to post your feedback in the current FTV thread, open an issue on Github, or contact me privately in this forum.)
Summary:
Is the process described above (1. through 4.) correct?
Do you want to help to make FTV (better) translatable?
Do you know someone who can give some feedback on the process (1. through 4.)?
If not, do you think it would be okay to just try and error? (I’m somewhat optimistic that there won’t be any major pitfalls. In any case, since FTV is beta, no one should expect every new version to be without problems either.)
Do you know people who would be willing to help translate FTV into other languages, e.g. people who have translated other addons in the past and might have some free time to translate the addon in the coming weeks? (As I wrote above, full translation of the addon is not needed in the near future. The first step is to test the workflow with a few languages.)
Kaj @kmikkels would be an excellent person to work with when beginning the translation journey. He just finished his own translation experiments while writing the Historical Context addon gramplet, has been a translator for the main Gramps application for quite a while, and has been giving great feedback working through the growing pains of adapting the Addons to the Weblate systems.
You might want to talk to @GaryGriffin about publishing FTV as an experimental gramplet in the 5.2 addons-source repository. @Nick-Hall has created a Weblate project for that repository. It might be counterproductive to have translators start with the old manual process and possibly lose work switching over to Weblate.
FTV has a huge count of strings due to the extensive Configuration options. People might have some tricks for reducing the count of strings. There has to be a way to have a LLM compare the preliminary strings from FTV against the existing Weblate dictionary and suggest some which could be re-phrased to match.
Ah. Well it is probably better to beta FTV in the the 6.0 branch anyway. @ztlxltl can use the smaller group to see if publishing to the “official” repository process is livable. Or if keeping FTV in its own GitHub repository is its future.
I think I’ll keep FTV in a separate repo for a few more weeks/months until it reaches a mature enough state. This will most likely happen after 6.0 is released, so the switch to the new Gramps version will probably happen in my repo. In the current “open beta” phase, I’m pushing new features/improvements/bugfixes several times a week. Once this slows down, I’ll consider opening a pull request for the addons-source. I expect the review of the PR to take some time (currently over 11000 lines in *.py files, including comments and empty lines).
As I understand this post, the content of the template.pot and the XX-local.po files just have to be appended to the merged files (addons.pot, XX.po). Maybe the script also needs to be updated.
I think @kmikkels would have mentioned if there was an obvious flaw in the process. I’ll change the workflow to keep the template.po so we can proceed and see what happens. I’ll post here when the file is available.
You can submit your addon for inclusion in the third-party addons repository at any time. The review should be fairly quick. If an addon doesn’t write to the database, we are really just checking for malicious code.
It will write to the database as I plan to add the “Add relative” feature to create new people/families. But if only those parts are reviewed, it will only be a small part of the whole addon code.
@Nick-Hall Perhaps it could be adapted to a (developer/debug mode) bootstrapping tool that builds/freshens the .pot and .po files for a selected addon? So that developers and translators have help starting their translation process locally.
Likewise, another script could adapt the addons-source make.py to run against a list of installed addons. (Perhaps for registered addons where a name or email address is in the authors or maintainers attributes?) This would simplify managing local “Project” folders of download (.tgz) source code archives) and listings (addons-__.json) folders. Which would encourage developers (in experimental and beta stages) to share an Addon Manager compatible GitHub folder.
I have added two new commands to the make.py script:
python make.py gramps60 aggreagte-pot
This aggregates the template.pot files for every addon into a single po/addons.pot file that is used by Weblate. It needs the GRAMPSPATH environment variable to be set so that strings already in Gramps core can be excluded from the Addons Weblate component.
python make.py gramps60 extract-po
This extracts translated stings from the po/{lang}.po files back into the {lang}-local.po files for each addon. It will create new files if a new translation in a new language becomes available for an addon. It also identifies files with only header changes so that they can be excluded from commits.
Note: Merging po files into an updated template is now handled by Weblate. The local po files are now created using the --for-msgfmt option, because they are not intended to be translated directly by translators.
I changed the workflow and the template.pot file is now available for first test translations.
@PLegoux@geoglorus@kmikkels Could one of you pick 1 or 2 labels from FTV’s config window, find them in the template.pot file, translate them and open a PR with the resulting fr-local.po/da-local.po?
The next step would be to build the addon with the fr-local.po/da-local.po to generate the fr-local.mo/da-local.mo file and include it in the package. Then you can test if you can see the translated strings (especially if you install FTV using the Addon Manager).
French: @PLegoux (offered help here), @geoglorus (offered help here)
Danish: @kmikkels (offered help below)