twif is part of the Weblate component “posts” = “News” on F-Droid website
Hi,
like other translators said, I’m very happy with Weblate. It’s definitely better if compared with websites like Crowdin, Transifex or Launchpad. I only have two suggestions:
1 - adding the possibility to use Apertium’s engine in Weblate to get suggested machine translations, like you can get in OmegaT for some supported languages (ex. Sardinian)
2 - Launchpad seems to have a way to suggest translations using a TM generated automatically from strings in various github projects. For example, when translating Ubuntu programs I get suggestions from Exaile, a media player that I translated in Sardinian some time ago using not Launchpad but Weblate. I don’t know how they got those strings automatically in their translation memory. Adding something like that to Weblate would be a great thing, since it would allow us to get a lot more useful suggestions.
1 Like
Hi,
Above questions are more to ask to Weblate dev Team than here to f-droid community trying to improve its translation process.
Weblate already have “automatic translation engines” and for instance recently added support for Amazon Translate (see: Weblate 3.1 - Michal Čihař), you can suggest them to support your favorite Engine.
Actually, I have a suggestion!
Right now, after new content has been added to the website, there is an undocumented second step to update the translations, which also needs to be commited to the repository.
It would be great if this could be automated, so it cannot be forgotten, content authors can focus on writing good content, and content becomes available for translation asap.
yeah, automating the translation sync process of the website is a primary goal of this funding.
1 Like
I’ve added my suggestion here, with a minimal example explaining how it might look in this repo. In general, we should be automatically:
- Scrapping all the screens within the F-Droid client.
- Finding any English strings in there.
- Annotating the screenshot with any English strings that we found.
- Uploading that screenshot to Weblate for context, so translators can see exactly where a particular string is used within the app so that they can translate appropriately.
Such a toolchain would be beneficial to any other Android apps wanting to improve their translation workflow also.
2 Likes
Ok, I can announce the first improvement to this workflow: hourly rebuilds of https://staging.f-droid.org. If you are translating the website, the build process will check for updates once an hour.
6 Likes
Works great! I’m in doubt if such high frequency was really needed as Weblate syncs only once a day, but anyway.
Now I wish for regular feeding of Weblate with new strings not only from time to time.
And what I do not understand is why export from Weblate to https://staging.f-droid.org/ works fluently while sync between staging and official site is sluggish. What’s the basically difference? Where are the hurdles?
The main site hosts the F-Droid APK and other security-sensitive content. Therefore, changes need to be manually reviewed, and then tagged with a GPG-signed tag before they can go live.
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.
1 Like
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.
1 Like
The best thing would be to set up one team per language, with rights to:
- Manage glossary
- Manage screenshots
- Review strings
- Manage translation memory
- Automatic translation
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.
2 Likes
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.
2 Likes
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.
- There is no real knowing when translations are included, where to test them, or what stage the translation is at current. The overview from SecureDrop was good, but it took someone like loic to communicate it. Could be automated better, and even factored into what unfinished strings to present to the Weblate user. (Ref. 1.)
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.)
1 Like