The official website deploy is also done on a hardened setup, which is more limited in resources.
As for the frequency that staging.f-droid.org is rebuilt, the deploy process checks for changes, and only deploys if there is something new. It is not rebuilding every hour.
You can sort by these filter as o of now 
But you’ll read Matrix messages instead… RLY?
Matrix has everything properly formatted and categorized so yes
Wouldn’t it be better if we rather donated to weblate and agreed on getting all the premium features, we will also get more exposure on hosted.weblate.org
As far as I understand it, we already do have the required premium features for
setting up roles with specific rights.
Then let’s start with approving well established translators special rights. Get a translator to take on the maintenance on weblate to an extent.
When adding a german translation, I sometimes missed a screenshot of the UI. When there is a short, english string that has two reasonable translations it is important to see the surrounding UI. It would be nice, if it is supported to upload screenshots of the app and connect the screenshot to several strings and vice versa. The version string(s) (1.04a-1.9) of the app could be associated.
IFixIt.com supports marking positions in a picture in a browser.
Even crazier would be, if the english text would be removed from the picture and the translation appears in the picture.
The best thing would be to set up one team per language, with rights to:
But only for that language.
Then you could give access to trusted translators to this group, and even give them the possibility of adding or removing more users to their team, which will make the group pretty autonomous.
I set up all the existing language teams like @emmapeel suggested. I think this should be a big improvement in workflow. Any team member can now upload screenshots, for example.
I maybe don’t want to exercise the maximum control of 76 people, but instead take what are to me sensible risks. Also there are other ways to do some things, and not a whole lot of focus on authoritative quality. It doesn’t always hold true, but treating people like they have limited power means they consider everything else someone else’s problem.
It would be great to get the basics right, before attempting a rule by hierarchy (that hasn’t worked on any other translation platform. Those places curiously don’t have the functionality needed to hide the actual problems like Weblate does.
Going down that road I guess is what it is.)
0.Too few of the actual string statuses are available:
1.There is no knowing what strings are undone.
An “Add to workload” list, and a multi-project editor showing untranslated strings like Translatewiki has would solve most of this.
2.There is no knowing what strings changed upstream.
They are shown with green edits, and this is usually very low-hanging fruit in terms of the effort to get it right, and once in a while very important.
Easily missed.
3.It is not possible to tell what strings are new without extra effort.
As subjected to fewer eyeballs, new strings often need to be redone.
In projects that aren’t done, it all drowns in noise, like the WL docs for most languages.
This makes it harder to complete big projects. It is a lot easier to translate consistent material.
4.It is not possible to know which projects/strings are auto-translated.
5.It is not possible to find strings someone else reviewed.
Without this there is no functional trust in the reviewed status system, other than keeping
on top of things as they happen.
Per-reviewer status has been missing in Git/Weblate forever, and it is a total oversight.
6.The Zen editor doesn’t have full functionality, nor is it as efficient space-wise as it could be.
7.The Zen editor throws errors too early and often.
8.There are no group labels, like “Linux, SailfishOS, ecology, electronics, Nextcloud, etc. to click”. The others actually have this, albeit not the best implementation.
8.There are no per-language dictionaries.
9.The personal TM dictionaries are not checked against any common dictionaries.
10.Last I checked it wasn’t possible to add a non-allowed translation and a required translation of the same source string (Don’t know if this still applies.)
11.The regular navigation presents info in a way that means it changes between views.
12.It is difficult to know what projects have added links to source, and there is no automation.
13.The colours make the most of conflicting with the most common color-blindness.
14.It is hard to tell what the last entry of the regular editor history is.
15.The searchable history of edits falls apart once the same string has been changed multiple times.
16.Announcements are posted without the username of the person doing it, which leads to things like F-Droid @ Hosted Weblate which just says “I”.
17.The engagement page isn’t sexy enough, and doesn’t do much beside waste clicks compared to starting at the project level.
18.The search atop F-Droid @ Hosted Weblate doesn’t show project logos or user avatars.
19.The administration fields are (by default) only available to admins/group members.
Problems specific to F-Droid
1.there is a CoC
2.“F-Droid” is the name of both the client and the repo. Rename the repo.
3.Not evident that the website has no sensible rules for inclusion of even completed locales.
4.The blog articles are not changed even if MRs are submitted.
5.The official F-Droid client source strings are not polished.
6.Fdroid.org tries to trick the user into downloading F-Droid when searching for an alternative client.
7.Rules for inclusion by way nr. of avail. translations languages are not public (enough?)
8.Some analytics going on, which makes it very difficult to communicate F-Droid
9.A penchant for censorship and hastily made decisions in the commit access group
10. fdroidserver/common.py · master · F-Droid / fdroidserver · GitLab is not communicated anywhere (?) leading to devs overshooting it even in English.
11.As I understand it some users get more rights than others for some languages.
12. The component “Posts” is called “News” on the website. “Data” is what. "F-Droid metadata should be “F-Droid client metadata”?.
13. One project has a GPLv3-only license, and everything else is *-or-later.
14. Priviliged extention is the only component that is Apache-2.0.
15. 5 components have errors F-Droid @ Hosted Weblate
With enough users, catching people uploading bogus screenshots is taken care of.
With enough functionality to revert or prevent further action pending moderator review all is well.
Don’t lock threads here after 60 days. Nobody is flooding old threads(?), or?
Seems to be arbitrary lock or no-lock for topics discussed over multiple years (like this one).
Some other ideas:
Let the user know how completed the translation is for a browsed project in the client,
preferably before opening the listing.
Maybe an option to only show projects that have a translation in the selected locale(s).
Communicate how to add the link to the translation platform better, and streamline the process of setting it up on specifically Weblate. (There are no other alternatives.)
Communicate more clearly that the user can “help translate the app” in the app listing.
Add “help translate this”, to every part of the website etc. and turn on direct editing from Weblate for whatever supports it. Check what changes are made before building, (which I understand is done anyway.)
It’s great that we can translate the F-Droid on the Hosted Weblate but app developers can’t do so easily.
The Weblate have a free plan for the libre projects but it requires for moderation with a limitation:
This stops a new app developers from registering on the Weblate. The registration process and project itself is complicated enough. That’s why we have a lot of applications that doesn’t have translations: their developers simply don’t want for this burden.
We may have a situation when the app is already added to the F-Droid but still can’t use the free plan because it’s not passed three months. For this reason some apps use Codeberg Weblate instance that doesn’t have any limitations but they won’t send a PR to repo on the GitHub.
So @hans could you please negotiate with the Hosted Weblate a special rule: if the app is published in the F-Droid (or even any distribution repositories) then it doesn’t have such requirements? This will also increase load to the Weblate which they may not like and ask for additional financial support. Their prices are quite big so basically we may consider own server or even use any other proprietary services: Crowdwin, Transifex, Lokalise.com, PoEditor.com etc.
As a simpler solution we can create a Weblate Component for the app under the existing F-Droid project. This will be done by the F-Droid Team when the app is included to a repository. The Translations: in the manifest will be updated too. This will allow us to make the translations required but also create a translation teams on the Weblate project level and to be in control here.
As a downside it will be not so easy to set glossary which is a separate component but also the Fastlane metadata needs for a separate component. The last is probably easy to fix in the Weblate itself.
So could you please solve the problem?
F-Droid maintainers already have more than enough to do, so any solution here needs to involve taking things off of F-Droid maintainers’ plate, me included. As for easy signups on Hosted Weblate, we’re working with Weblate on a funding proposal to implement ideas to make things like that easier.
Thank you. In the simplest case if we create a component under the existing org it shouldn’t be to much burden. We may have a translations team or you may even assign me as an admin so I can do that. Not so many of new apps are added, so it should be a few minutes task.
I’m not sure if something needs for signup implementation on the Weblate, maybe it doesn’t worth it.
Since this may increase load to the Hosted.Weblate we may just use another instance.
There are some Weblate instances created by volunteers who can serve F-Droid too.
If I can help somehow please let me know.
Thank you
Just to clarify: many apps already have an intention to integrate with a translations service but their devs just don’t have enough interest or time to make the integration. Some or the feature requests are opened for years e.g.
If there are no any hard reason to use the Hosted Weblate then we can propose to use a community driven server. @yzqzss created an own server exactly for this https://toolate.othing.xyz/
We can show a list of servers to a developer to choice and even register a component/project for the new app. It’s should be highly recommended and eventually maybe even required for apps with many users.
See, for now most users of the FOSS apps were US and EU (mostly German) programmers who are concerned about privacy and ability to improve own apps. So some app developers even not consider to translate them.
But now the FOSS apps are more and more used by regular people and in mush wider geography. Especially this become important for kids (my main motivation as a parent).
For an estimate, the most populated region of planet is Southeast Asia with 8% all people of Earth. Eventually they’ll start migrating to FOSS app but languages of the region are underrepresented. This will be a huge amount of complicated translations and big load that we should prepare for.
Not having translations (even poor) is same as not having downloads. For most people this is stopper.