Help translate the web interface via weblate

[aparcar]

Hi, for testing I created an OpenSource account on weblate which gives a nice interface to translate the PO files. To improve the process I'd install the weblate service integration (also available for GitLab an other services) which automatically a) add newly added strings to their translation web interface and b) creates pull request once every now and then when updates via weblate happend. If anyone is against this approach please let me know. Right now it looks like only 52% percent is translated.

[feckert]

I did a registration with github and proposed a change on a translation. I don't want to get too deeply involved for now. But to get a feel for how it works, can you please explain to me how this change I have made then goes into the master branch on github?

[aparcar]

I played a bit with the tool and it works surprisingly good!

From what I understand it is possible to manually trigger a commit (like https://github.com/openwrt/luci/pull/3190/) or set it to create a PR every x hours based on the recent changes. Instead of PRs we could also allow it to directly commit those changes, however I'd leave this off for now.

Cool thing is we can also host it on our own if weblate changes their policies, which I don't see coming anytime soon but still a requirement I'd say.

[feckert]

Thanks for clarification. I think directly commit is not an option.

I have done some translation in luci-app-statistics and saved this. CPU-Frequenz and Adressfamilie But nothing happens. No creation of a new pullrequest in the openwrt/luci :-( Do I miss something?

[aparcar]

Currently there are the two options to auto commit every 24h or perform it manually - as I just did. This however ended up in a somewhat messy PR as people started to translate also Portuguese and Russian files.

I set it up that from now on PRs are squashed by author, meaning whatever you do in 24h will become a single commit.

[aparcar]

It is possible to add the weblate git repository via

git remote add weblate https://hosted.weblate.org/git/openwrt/luci/ 

[jow-]

Seems to work well. Please continue with this in case further changes are needed.

[hnyman]

What is the mechanism here? I have received ~100 email during the night from PR 3197...

Subject: Re: [openwrt/luci] Update from Weblate (#3197)
From: Weblate (bot)
To: openwrt/luci
Cc: Push
Reply-To: openwrt/luci
Date: Today 06:41

@weblate pushed 2 commits.
    ea20df6 Added translation using Weblate (Korean)
    8c98352 Translated using Weblate (German)

Each new translation via weblate gets spammed to all LuCI committers?

(I guess we can unsubscribe this PR to get rid of the spam, but sounds strange if all future translations are still tied to that one PR. )

[aparcar]

@hnyman sorry for that! I will see how to disable these notifications! The weblate service updates daily a PR with a single commit per author. This way we don't end up with x unmerged PRs for translations.

@feckert wrote

@aparcar How can I add missing apps in weblate? Specifically I am talking about luci-app-mwan3?

The weblate team initially setup the service but made a small mistake, I fixed that and the missing components should now be available.

[aparcar]

Another 300 mails, but the storm is over and whoever survives the 200k new lines of PO files in the next git pull should look into a nicely translated future. I'll leave this open for further requests.

[castillofrancodamian]

I see that when translating an App (e.g. DDNS), a string that I modify is "Enabled" and is also modified in all apps with that word to translate. I mean, in one App it means one thing and in another it means something else even if it is the same word in English. I don't know if it can be deactivated or dodged.

[aparcar]

Hi @castillofrancodamian please don't crosspost issues, I responded to your forum.openwrt.org message.

[zorun]

How is translation supposed to work for release branches? I see that there were some updates to openwrt-19.07 after it was branched off (e.g. dd0c93224 and 83a7292a7), but not all translation updates seem to end up in the 19.07 branch.

I fixed several translation mistakes in 19.07.0-rc1 and it would be nice to have the fixes in the final 19.07 release.

[aparcar]

I think this depends on @jow- , I'd be okay with moving all translations over to 19.07 just before release freeze or set a public date for a 19.07 translations freeze.

[jow-]

I planned to do some scripting to sync 19.07 translations with master ones by using the master po files as translation catalogs for the branch ones. That should ensure consistency

[hnyman]

Hmm. I synced translations in master and that seem to have caused a few conflicts at the current weblate PR #3355

These weblate PRs have no clear author to be contacted, so I will likely fix those conflicts myself.

But I am not sure what would be the correct workflow in future. Probably merging the current weblate PRs before syncing translations files?

There has also not been much discussion how these should be handled daily. So far @aparcar or @jow- have mainly applied PRs, partially manually, I think.

Thus I wonder what is the actually the correct workflow with these weblate PRs:

• Simple merge of the PR without any changes at the merge stage?
• They can be merged at any time?

[aparcar]

I don't know what's the best approach but would be happy not being in charge of it :roll_eyes:

Maybe things are simplified by using the weblate github integration. Most issues (seem) to appear by weblate being out of sync, while the app (hopefully) triggers a rebase on every commit to luci.git.

[hnyman]

would be happy not being in charge of it

Well, you introduced it...

Can you at least answer my previous questions:

what is the actually the correct workflow with these weblate PRs:

• Simple merge of the PR without any changes at the merge stage?
• They can be merged at any time?

Apparently the conflicting commits from yesterday have been removed automatically. (Spanish, if I remember right). Probably they have been somehow pushed back for translation/checking. Is that supposed to happen?

[aparcar]

would be happy not being in charge of it

Well, you introduced it...

Fair enough. I think I wanted to say to distribute the merge capabilities.

what is the actually the correct workflow with these weblate PRs:

• Simple merge of the PR without any changes at the merge stage?

I wonder if the SoB line is important for translation updates. If not, the GitHub PR merge should be fine. The problem seem to be syncing.

• They can be merged at any time?

I think so, however it bloats the git log. Maybe we should only do so once a week? Maybe I got your questions wrong.

From what I understand using the Weblate-GitHub-App allows to set a push rate to daily or weekly, so the entire merging could be done automatically. I guess part of the issue is that when using PRs they stay open for multiple days and are out of sync at some point.

[MartB]

Is weblate borderline unusable for anyone else here? Their servers / software are always incredibly slow for me.

[aparcar]

@MartB I think it depends where you are, I tried it before in Honolulu and it barely worked, using it now in Leipzig works fairly well. Maybe we as a bigger project should consider to donate some money for faster servers. I'm against self hosting as it'd be yet another service to maintain... But this is just my personal though.

[MartB]

@aparcar Im sitting in germany <100km away from Frankfurt, so yeah not sure whats going on there. Submitting translations/suggestions and only displaying a certain language takes ages to load for me. Not sure what amount of donations would change their mind given that they have a premium service. The slow performance could be due to a deliberately low resource allocation from their side (i understand that from am business pov).

Self hosting would be a possibility but also requires money, time and an active maintainer/sysadmin.

[aparcar]

@MartB please report this problem upstream to the developer.

[urbalazs]

It seems, that Weblate has conflict and it could not merge the new translations. Can someone check it and try to solve the conflict?

[hnyman]

Well, the conflicts seem to be mainly due to the recent "typo corrections", either spelling or case changes...

Looks like the typo corrections have caused some 50 conflicts there, as they have been made in another repo at the same time as there has been translation going on in weblate.

Example of conflicts:

#: applications/luci-app-adblock/luasrc/model/cbi/adblock/overview_tab.lua:251
<<<<<<< HEAD
msgid "Topic for adblock notification e-mails."
msgstr ""
=======
msgid "Topic for adblock notification E-Mails."
msgstr "Sujet pour les e-mails de notification adblock."
>>>>>>> weblate/master

#: applications/luci-app-nut/luasrc/model/cbi/nut_server.lua:91
<<<<<<< HEAD
msgid "Maximum Retries"
msgstr ""
=======
msgid "Maxium Retries"
msgstr "Legtöbb újrapróbálás"
>>>>>>> weblate/master

[hnyman]

And some of those conflicts seem to be just header meta data conflicts. Too bad.

[hnyman]

@aparcar @jow- are there any config options on how often weblate tries to refresh upstream LuCI sources?

As a vanilla weblate user, I have not yet figured out how often/why/when weblate actually tries to pull new sources from us. I fixed a dozen conflicts yesterday and merged that, and weblate took maybe 20 hours to notice that we have new upstream LuCI sources. Now I have fixed the next conflicts from the translations done meanwhile. I currently wonder if it will take again almost a full day for the changes to get noticed at weblate, so that new conflicts will get generated in the meanwhile...

Likely the "free plan" (or whatever we currently have) has a pretty slow update polling frequency, but still sometimes weblate seems to try updating several times per hour, so the updating frequency varies.

So, can those who have some admin rights to weblate, please check if there is something to be configured to enable a somewhat more regular update trials.

Ps. who has any admin rights to the OpenWrt weblate instance? aparcar and jow?
(At least jow has been somehow able to lock/free the weblate instance during his conflict fixes.)

[aparcar]

It's me and jow, I guess you can have admin access as well.

The current frequency is likely based on the "create a PR every 24 hours with the latest changes" setting. In other words that's when it tries, fails and notifies.

Based on the documentation I added a webhook, however the it appears to be broke. I did not figure that as it doe not report an error even tho it fails.

I'll report an error on the weblate repo, but can"t yet figure out why it wont find the openwrt/luci repository...

[aparcar]

All right I found the problem. Apparently Weblate is a bit picky regarding leading slashes. Once removed it works.

Here the (really) successful hook

[hnyman]

Yep. Now it seems to also receive web notifications, as it reacted to the PR merge a few minutes ago:

[hnyman]

Ps. who has any admin rights to the OpenWrt weblate instance? aparcar and jow? (At least jow has been somehow able to lock/free the weblate instance during his conflict fixes.)

It's me and jow, I guess you can have admin access as well.

Might be good. I tried yesterday to force weblate pull via wlc and weblate api, but I missed the necessary authorisation.

Of course, if weblate will pick changes more quickly in future and do frequent rebases, there will be less reasons for manual interaction.

Great that you figured out the reason for the webhook's inactivity.