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 ).
If there are no objections by Wednesday 27th, weāll reach out to Weblate to kick of the process.
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.
Quick update here:
Iāve had a call with Benjamin from Weblate two months ago, theyāre open for business 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
@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:
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)
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?
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
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.
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.
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
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).
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?
).
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.