3 Jan 2025 @Nick-Hall starts a gramps‐devel Mailing List thread about possibly using Weblate for addon translating.
9 Feb 2025 Call for testing volunteers of experimental Weblate for Addons component.
It might be reasonable to suggest a couple strings for everyone to translate… as a stress test. But also to have a common experience for discussing UX of Weblate
The situation so far is that I have concatenated the template.pot files for each addon and then removed strings that appear in the main gramps.pot file. This new addons.pot file contains the strings that appear for translation in the Addons component on Weblate. The addons.pot can be updated using a script when translations change.
I have also concatenated all the local po files for each language. The copyright statements have also been combined. This was a one off process so that we don’t lose any strings that have previously been updated.
When changes are made in Weblate, combined po files for each language are updated by pull requests. Translations for each addon are then extracted using a script.
The first batch of changes appears to have been merged successfully, but we need to do more testing.
Feedback from translators and addon developers would be welcomed. We need to know if any strings are missing from the addons.pot file. Usability may be another issue. I’m not sure how easy it would be for a translator to translate a single addon for example.
1 Like
Is this for a specific branch of the addons-source?
Yes. This is for the gramps60 branch only.
1 Like
Is there a standard weblate query for a string?
Maybe there could be a developer gramplet that reads a selected addon’s template.po and displays the string and the localized string with a hotlink to the weblate string in the current language?
Example links:
It’s actually quite easy. You can use “location” in the filter.
For example, you could search for “location:DenominoViso”.
1 Like
There may be a problem with weblate for addons.
First I couldn’t understand that i have so much to translate, since I have done a lot of translating for addons recently.
But I started, and noted the some entries looked mixed up.
I always view the Swedish translation, to help me, and I then saw that weblate claimed a polish(?) sentence was swedish:
according to the po file it should be:
#: SVWebConnectPack/SVWebPack.py:42
msgid “Arkiv Digital estate records for Skåne”
msgstr “Arkiv Digital bouppteckningar över Skåne”
2 Likes
The Weblate translation was added 4 days ago. It looks like it was a mistake by the user.
The local po file is named sv_SE-local.po rather than sv-local.po. I’ll fix it.
Update: File renamed and Weblate updated.
1 Like
Danish is in the top 5. There are only 5 languages with more than 50% of string translated.
| Language | Translated (%) |
|---|---|
| Dutch | 100% |
| German | 93% |
| Croatian | 59% |
| Portuguese (Portugal) | 55% |
| Danish | 53% |
| Swedish | 50% |
Let me know if you can find any strings that are unused. I have excluded strings that are already translated in the Program component.
Perhaps we should prioritise the popular addons?
1 Like
Just a couple of thoughts:
Weblate claimes that there is something wrong with the addons weblate
And translation of forms, doesn’t that mean that people riscs ending up with Attributes that are wrong?
Does it really make sense to translate all the xml files in forms?
They are specific to each country, and should reflect what the sources say.
And the same goes for ??webconnect addons
I think that Weblate occasionally checks the project configuration. In this case, I suspect that our website was slow and didn’t respond within a 5 second timeout. I just cleared the warning.
1 Like
There is a good argument for not translating the attributes used in forms. Now we are using Weblate, any translator could translate these without realising the consequences of changing them. We should involve @RenTheRoot in this discussion.
Translating the long names, which are used in the tooltips, maybe useful though.
I don’t see a problem with translating the web connect packs. There aren’t so many entries to translate. Using a web site in a foreign language may be possible with translation tools on modern web browsers.
Ideally, web connect packs will be changed to use an external CSV (like the Historical Context gramplet does) or JSON file (like the SuperTool Help). Take those strings outside the Weblate set.
That would allow the different packs to be retired in favor of a more flexible system. (The Sync Associations would benefit from a similar change.)
The current hard-coded variants also suffer from the high rate of link rot and the different expectations for Association pairings. And it it too easy to accidentally break code
Update: There are now 7 languages with more than 50% of strings translated.
| Language | Translated (%) |
|---|---|
| Dutch | 100% |
| German | 100% |
| Portuguese (Portugal) | 100% |
| Ukrainian | 100% |
| Danish | 65% |
| Croatian | 63% |
| Swedish | 53% |
1 Like
whats the next step? Should we just wait for the translations approving?
Translations don’t have to be marked as approved. We use them anyway.
Everything seems to be working as expected so I’ll probably remove the experimental notice on Weblate. There were some comments about the translations of the Forms and Web Connect addons. We can start a discussion about those.
2 Likes
I do not understand all the need, but I just remember that most of my experimentations around addons, for command lines on translation files handling (maintenance), were also “stored” into a stand-alone ‘setup.py’ script.
It was more and less hosted under gramps-addons as an archive! Do not really look at coding style, the primary goal was to run all the commands lines via a python script. As far as I remember, there was a workaround for xml and glade files and/or an alternative to intltool (with pure python and GNU utilities), after a bug on some intltool versions.
Used methods are not the most important and comments have been added on my experimentations and strange sections. So, if this can still help.
Jérôme