Started to translate addons to Danish.
I am not fluent in git.
Could someone check that a da-locale.po exists for the following two addons?
No, these addons do not have an existing da-local.po . The only addons that have this file are:
Themes/po/da-local.po
Form/po/da-local.po
CalculateEstimatedDates/po/da-local.po
CheckPlaceTitles/po/da-local.po
EditExifMetadata/po/da-local.po
Those instances of da-local.po exist in the master branch for those addons. Kaj’s dansk additions are in the maintenance/gramps52 branch.
Are the translations coming from the right branch for the 5.2 Addon Manager?
Refreshed and yes, these 2 new da-local.po exist in the addons-source repo, maintenance/gramps52 branch. Users can manually download from there.
They are not yet merged into addons repo, master branch - which is where the 5.2 Addon Manager looks for the tgz and listing (json, txt) files.
The next step is to package the addon and add listing and then merge results (tgz, json files) into the addons repo, master branch.
Thanks.
I will continue to translate the addons and push to github for each addon.
Some time ago I started the same task, but didn’t push, got stalled and all finished translations disappeared probably during a fresh install of a new OS version.
I don’t want that to happen again.
The next steps to package and list is something the maintainers do, and I don’t have to worry about?
And sorry tor not being precise in my question.
Discovered the GitHub search is biased. It only returns matches from the current branch. CodeFarmer shared how to have GitHub search a different branch in a PM. Will convert that to a wiki article.
If you recall an addon where you had created a dansk PO file, you could go to that PO folder in maintenance/gramps52 branch. Then flip backwards through the branch selector for Gramps versions.
Maybe you could copy those old version PO files to your local plugins folders. It could save you some re-translation work.
Thanks. but the issue is that I didn’t push to repository, wanted to do it all in one big round.
I am wiser now 
Correct. You can send me a PM when finished to package everything if you want.
Thanks. Will do that
Perhaps we should use Weblate to translate the addons.
I have started to investigate the idea of concatenating all the pot files into a single file for translation. It is possible to split the translations back out again for each addon.
The only problem I can see so far is that the copyright details for contribution would be stored at the combined file level. Is this acceptable?
It is likely that initially we could have quite a few updates with translation changes only. This could be annoying for users, but would increase the visibility of addons to our translators.
Is there a workflow for checking your addon’s translatable strings against the core Weblate glossary?
With over 7,000 strings already in the Glossary, it seems like a lot of subjects will already be covered by only changing a word or two in your prototype’s strings.
I exclude entries that are already in the core gramps.pot file.
That’s extra work for you.
I tried to look up strings in Weblate while composing verbose hints and tooltips, trying to match existing strings. It was tedious and error prone. So I figure I am doing it the hard way.
If the single pot file approach causes user inconvenience due to unnecessary builds even temporarily, I’d be inclined to consider raising visibility in other ways.
A single pot file won’t cause unnecessary builds.
I create a directory with an addons.pot file and a po file for each language. When a language gets updated, I can merge the changes back into the po files for each addon changed.
So for example, if Kaj updated the Danish translations for three addons, then we would modify three po files. Then we would have to build and publish these three addons. Everyone would get the updated addons even if they are not interested in the Danish translation.
This is no different from our current manual process though.
Thanks for the clarification - it removed the misunderstanding I had about the impact of this proposal.
Having one place for all translations would be beneficial for me.
But if it is lot of work and/or cost I can live with poediting individual files.
Hopefully sometime I will have done all. I am currently on D
Someone on the github repo, suggested that I should make a pull request before pushing my da-local.po file to the repo.
Wouldn’t that be a lot of unnecessary pull requests?
And what are the actual rules for when you should make a pull request?
Generally pull requests are preferred, but there are a few exceptions:
Translations. Before Weblate, a translation maintainer was allowed to commit translation updates directly without a PR. This is still the case for addons. The reason behind this was that it was unlikely that the PR would be reviewed.
Package maintenance. We allow package maintainers to make changes in the directory related to the package that they maintain.
Releases. PRs are not required for commits relating to a release.
Branch merges. I don’t make a PR when merging bug fixes from a maintenance branch into the master branch.