Proposal: donation to Weblate

Hello,

As you might have seen elsewhere on the forum, we have moved all our translations from Transifex to App translations moved to Weblate.

We (@ByteHamster, @femmdi and myself) love that this service is provided to us for free, from open source project to open source project. The developer-owner (Weblate is largely a one-man-show) is also very responsive on questions on GitHub, which we appreciate a lot.

Given their free and open source service (in this technical niche domain), we would like to propose a donation to Weblate of € 2.5k. This would fall under category 5 Upstream & Peer contributions of our Donations Expenses Policy.

We currently have almost € 7.5k in our Open Collective which we don’t really need for other investments or expenses. We think that this donation can have a substantial impact for Weblate.

Now, when we started to use Weblate for our website (longer ago) and when moving our app translations to Weblate (recently), we did run into a few things. We now have workarounds where needed, but it would be great if things could be improved a bit to assist our set-up. So, while a donation, we would try and work with Weblate to address some of these points. That is also a reason for proposing a considerable amount (even though still below the median pay for a developer in Prague).

Some of the points we'd love for Weblate to improve (click to open).
  • For each file there is one component. While Weblate directly supports markdown files (which we use for the website), importing them all would mean we have tens of components in Weblate. They can be grouped, but settings still need to be applied to all those components.
  • To mark users as reviewer, we need to create a team. Languages can only be set a team-level, not at user level. So if we want to allow user X to review French strings and allow user Y review Italian strings, we need two teams. In other words: we’d need one team per language, thus a lot of teams.
  • Contributor agreements can only be set at component level. As we’d like to set the same agreement across the project, we’d need to copy-paste the same text to all components. And then still, translators would have to accept the same text for each component.
  • There’s no way to post string comments via the API. Consequently, we don’t have a way to move existing string comments (feedback) from Transifex to Weblate (apart from copy-pasting).

As per our Donations Expense Policy, we’re putting this proposal to the community. Please drop a line below to let us know if you agree, have doubts, oppose, etc (or click the heart if you’re feeling lazy :wink: ).

If there are no objections by Wednesday 27th, we’ll reach out to Weblate to kick of the process.

5 Likes

I agree with the proposal. I assume we are making the donation with no strings attached. Even though we would love to have Weblate fix the features we want, it would still be up to the developer to decide.

2 Likes

That sounds like a lot to donate, but it also sounds like we highly value the service and support we receive. I would support the donation.

2 Likes

Yes, the idea is to try and ask them to address those things. But if they don’t want to, to still donate the money.

2 Likes

Quick update here:
I’ve had a call with Benjamin from Weblate two months ago, they’re open for business :smiley: I explained a bit which things we’d like to have addressed, and he explained the process they usually have for these kind of things.

The process:

  • Have all requests defined on GitHub as issues
  • They’ll give an estimate for the costs of each of the requested items
  • Based on the estimate we determine what we want to prioritise and/or if we want to throw some extra money to it (e.g. if we’re just € 250 short)
  • We discuss and agree on priorities & delivery date
  • A ā€˜project’ is created on GitHub for the things that we want to sponsor so it’s clear what we contribute and can keep track

Our requests:
These are the issues that I created/updated:

Admin side

  • For each file there is one component. While Weblate directly supports markdown files (which we use for the website), importing them all would mean we have tens of components in Weblate. #14237
  • To mark users as reviewer for a specific language, we need to create a team. #14233
  • There’s no way to post string comments via the API. #14232
  • We can’t give a user the permission to post announcements. #8974 → This one was not in our list above & wasn’t discussed in the call, but since it’ll be helpful and they’ll first provide quote I figured we might as well get an estimate for this one too.

UX side

  • The same contributor agreements has to be accepted multiple times. #14231
  • When on a component, there’s no clear path/call to action to start translating that component. #11198

From the call I had with them it seems that they’d be open to address all the pain points we raised. The budget that we foresaw most likely won’t cover them all. But I just sent the list to them to get the quotes, so let’s see in the coming weeks :slight_smile:

1 Like

@ByteHamster I actually had the following in my notes as well, but didn’t submit that request to Weblate and don’t recall if I discussed it with them:

  • Reports (Translation progress reporting - Weblate 5.11 documentation)
    • New format: CSV (for easier Excel/LibreOffice import)
    • New filter: Component (so we can easily say ā€˜you translated 50% of the website and 90% of the app’)
    • New option in report period: All time
    • Open report in new tab, so that you don’t loose settings (especially annoying when using first time while experimenting to get desired output, have to set again HTML each time)

I’m thinking we didn’t discuss this internally, but linked to it: having a threshold for the translation PRs: Quantity translation thereshold Ā· Issue #3436 Ā· WeblateOrg/weblate Ā· GitHub

How about storing the incomplete translations in the repository, but with a different file name/path so that they are not discovered by the framework?

If they’re talking about storing them on Weblate’s side in another path, moving them to the main path automatically if the threshold is met so that it gets included in the PRs, I imagine that could work. WDYT?

This sounds more like they actually want to commit the files to the original repo. In that case, I would be sceptical.

1 Like

Thanks, replied accordingly.

Actually, I see now that the reports is really just about that, probably to acknowledge translation contributors in the app?

For acknowledging contributors we can use the git history. That also has the advantage that we can detect if none of the strings someone translated are in the app anymore

1 Like

Then we can disregard my earlier notes about improved statistics exports.

Update on the issues we had in mind to be addressed

Group Challenge Issue nr Agreement on solution?
Admin For each file there is one component. While Weblate directly supports markdown files (which we use for the website), importing them all would mean we have tens of components in Weblate. #14237 No. ā€˜Merging’ of MD files into single component not really an option (technically complex). However, we can probably agree to alternative solutions (@ByteHamster?):
* UX for user: add a setting for component groups to hide lower levels, although this might not be necessary since other changes to groups would already make individual components less visible (e.g. #11198)
* UX for admin: add more settings at component group level (e.g. contributor agreements; #14231)
Admin To mark users as reviewer for a specific language, we need to create a team. #14233 Yes: allow to define languages per role per user
Admin There’s no way to post string comments via the API #14232 Almost. Alternative API endpoint exists, tbc if that would work.
Admin We can’t give a user the permission to post announcements #8974 Unknown
UX The same contributor agreements has to be accepted multiple times #14231 / #10897 Almost (General idea to have some settings at project level seems OK, but exact working not specified yet. Also, not sure we would sponsor the full set of possible settings, mainly CLA relevant to us.)
UX When on a component, there’s no clear path/call to action to start translating that component #11198 No. Requested UX (single translate button that is smart when possible) doesn’t seem accepted. Maybe this should be discussed in a call, or dropped until the coherent UX review is done (at which point we can sponsor some of those).
1 Like

I feel like if the default page shows the languages, plus after selecting a language there is a large ā€œtranslateā€ button at the top (instead of having to click every single component individually), it should be okay to have many components (from a translator perspective).

That would probably be needed, yes.

Hmm, the longer this takes, the less I believe we need it. We are using Weblate since about 5 months already. Maybe it’s okay to leave the old comments on Transifex behind.

I think a single translate button is maybe the most important change. It looks like the issue now has a milestone attached to it. So maybe you convinced the developer?