The state of translation

The state of F-Droid translations

Strings in the English Android client leave much to be desired, and are in some part erroneous. Attempted correction didn’t go so well.

Curiously this means users of the English version of F-Droid ideally get a sub-par product,
compared to the initiative of any prospective translator.

There is a policy in place for translation of components; one of thinking that if a certain threshold of completeness is met, measured in string existence, by the total of strings.
If any translation of the F-Droid client sees the 100% mark, it is deemed ready for every respective user thereof.

The string-base for the client is not that big, nor complex, and has good coverage in many languages, included with every download. Nobody knows for sure how actually good any of these translations are, unless having checked the whole thing themselves, staying on top of any alerts of changes. Even then, still pretty much as good a product as any single translator. Per reviewer review status is how to improve here, that is a matter for Weblate to implement.

The second problem is with employing that same arbitrary % policy for other components.

Other components range from small and neat, to large and bloated. Most of which belong to the collective website.

A lot of users will find no consistency between the coverage in the
most important component, the client, and the landing page of that website,
which leaves the paradoxical conundrum of where to get the idea from.

In actual fact it is somewhat down to the landing page not being translated. Rather because inclusion of a language onto the landing page, is subject to having coverage for many of the components on it. So translations do actually exist, just not anywhere that anyone would see them. To the contrary, German being the only language with 100% coverage, has managed to make work of the component that has all the blog-posts in it.

For smaller languages, the biggest impact lies in fixing the source strings.
That goes both ways. Any one translator can meet a bigger audience this way, and the bigger language efforts could help the smaller ones.

In terms of Internet presence, one of those is Shona. I dare say speakers of
Shona, the language, are not spoilt for choice when it comes to resources available in Shona, the language. To my knowledge there is just one translator.

I see the progress bar for Shona just sitting there. I don’t know if that is enough to get into the client.
What is a considerable amount of all the material in Shona available in any program.is just, there… That is one of the saddest things in F-Droid, especially for adoption.

I wonder what goes into a policy that says blog-posts dating back to however many one needs to translate to meet a percentage is a credible metric for holding back inclusion on the landing page, when the client isn’t in the same translate-wall.

If you like Norwegian Bokmål, get ready for 1052 strings, amounting to 9817 words for your viewing pleasure, available exclusively on the translation platform…
There are a lot more where those came from, most of which through no fault of their own, are marked “needs review” because there is an error in the source string.

I think imposing the 100%-bar encourages translators not to leave “needs work” checked, so you could argue the only meaningful tool to getting it out there, while pragmatically fixing issues, be it in source or translation, is not used. Downfall of the commons.
It could be easier marking source as “needs work” in Weblate, and the issue is being tackled.

My thinking is that it is downright counterproductive to enact the same
flat inclusion policy down for all languages. If a mere 5 strings are translated, that makes it possible to navigate between categories in the F-Droid client for someone who only speaks the one language.

That could be the difference between a user feeling confident enough to use it, and never seeing the software again. If it ever got to that, presumably from a landing page they can’t read either.

The different components have various policies beyond that, most of which is now available as an announcement in the actual translation platform.

For every translator F-Droid can get through the process of translation, there are prospective users. Very much relative to the size of the effort. More is unproblematic, and fewer can eat their own dogfood. If it can get done in Shona, which lacks words for much of what goes on, it can get done in any language. Being able to complain about it is about all the effort needed to do something about it.

Putting eyeballs onto the source strings thus is a process of action, and iterative grinding. Over time the threshold of its doing diminishes greatly. For this to happen, a lot of feedback-loops can amplify positive effort into greater results.

Those eyeballs are needed. One very cool thing is the “Translation” field, a little link in the description for each app on F-Droid for where to find the translation platform it is localized on. So far I have only seen it used for F-Droid in F-Droid.
From there one is bound to see the source strings, and they could get a lot better.

Right now it seems sending fixes for the short summaries, for some reason called “Data” in Weblate, is accepted.
Translation is ramping up too.

Hoping to see all apps available, not just 700 of them. Communication between translators has gotten a lot better by being able to mention people by name on Weblate. Links to source code is extremely useful.

Editing markdown is a new addition to Weblate, courtesy of the effort of Hans of F-Droid securing funds, and nijel of Weblate landing support. Fastlane support makes it possible to edit metadata for Android apps. F-Droid translators got to cut their teeth on very fresh code, and I messed up in having them do it twice. The max. length restriction still makes it sometimes impossible to do.

The sticking point is editing source strings. For some components it can be done directly, but not all. As the direct functionality is new, and has shown itself very beneficial to the source stringbase of for example F-Droid’s new Repomaker, one might ask why 10 years down the road of F-Droid, the same can’t be said for components that actually have been around as long?

The meta of time in memoriam will find me blogging a complaint about about a blog here.
The F-Droid blog does a lot to highlight other good features of libre software, but ends up hurting itself.
If you find an error in any of the F-Droid blog-posts, which all told is very hard to avoid, there is no fixing them. Even if taking to Git to submit a patch. Rejection is policy. Supported by a mindful in bewilderment of uncompelling logic. This is decided by one person, though happily contested by at-least two.

If there is procurement of usage metrics, why not get a firm number of how many read blog posts older than the 10 most recent? Some irony was avoided in making sure the most 2 recent ones were actually published.

The mere requirement for translation coverage across components to be offered a language in the drop-down menu of the website, is very daunting. Why additionally grind through the process for a few users to see in a small language, when the same capabilities could be put to use for English? Why not take advantage of the bigger efforts to at-least make it a bit easier to do? If English isn’t going to see any work, why not instead make sure as few people as possible see any of it? :wink:

Translating while using Git is clunky. All translation is done on Weblate, so using Git to do the related fixing of generational errors, is only for the components that need it.
However hopefully, though unlikely to happen; it is all down to policy, not effort, nor patches available.

It seems having a high bar on translations ensures quality translations, but
as far as quality goes, it is quite arbitrary, and functions on the technicality of ensuring no non-quality translations make it in, because no translations for smaller efforts make it in.

Ensuring your language has all components in F-Droid available for translation, is first looking at the English list of components, and then going about clicking each one of the missing ones in the translated language, to issue a request for adding the language component. Not really what anyone wants to wait around for when ready to do the work.

I know it doesn’t work, because not even all the languages that are included on the website have all the components.
As you might imagine, with new components this didn’t happen either, even for languages that are included on the website. How would anyone know if a component was silently added, after the effort looked as if it was completed? This can be solved by future change to how notifications work in Weblate. Notifications and announcements just got a whole lot better there, but I still can’t get my head around how notifications work for GitLab, where the source code of F-Droid is hosted.

Adding those components is done manually, by the same person who decides policy, and largely runs the back-end translation effort. For that I am grateful.

The plugin to do this same thing automatically breaks the staging page, and
various other things. This I regrettably know having done it thinking it was OK to do.
The staging page is nice if you want to see your translation, or show someone a semi-official translated site.

The real website got better just recently, as someone fixed the bug where selecting one particular language from the drop-down menu, meant others vanished from the list.

It Would be interesting to find out how many apps have it. Seems like something that could be added by anyone wanting to help.

From this, as of now still open MR, we find the .spelling file needs entries. One of which should be “Git”, and the names projects use. The latter alone is fine. There should be no doublespaces, as it pollutes the Weblate TM corpus.

As you may know, the “Latest” tab is now a manipulated feed. One of the requirements to enjoy the carousel is to have some translations, which is good, but I don’t know how I feel about it. More should be done to detail the process of setting up translation for app developers. Let’s write a guide?

Would love to be wrong on the Internet, join the discussion, and get to translating F-Droid @ Hosted Weblate

If this instalment proves beneficial, I can also do one on the state of design. Stay busy wonderful people of F-Droid :slight_smile:

TL;DR
Right now translation of F-Droid all amounts to a curious, and solvable concoction of considering what I imagine to be professionalism for its own sake, the current possible trend over future end result, and lack of developer time. Fixing the groundwork will set things into motion. This sentiment is encouraging. A lot more translator time could certainly be unlocked, enticed, and just put to better use.

Like everyone learning to row, without sticking an oar in the water, when we are all in the same boat, taking commands from a captain below deck.

1 Like

Fine summary, good points for discussion.

I maintain a language with very few speakers - and even fewer potential translators. This means prioritizing individual translation components, and even deciding which ones will be translated at all.
The F-Droid android client is of course a primary target, then perhaps the Privileged Extension, followed by Website Pages.
But there’s another angle; in each component I can decide to prioritize the strings most often seen by the casual users, and skip highly technical strings or seldom seen error-messages; the app would still be highly usable for the intended audience.
Translating all of the metadata, or any of the blogposts should not be a condition for publication of the webpages or release of the client; IMHO it should be a decision of the translation team.

2 Likes

@sveinki I agree wholeheartedly. It is the same for me, but your resources outshine even the efforts of a demographic of more speakers, like my own.

It is possible for F-Droid Weblate admins to hand-tune the weighting of strings, marking some as more urgent, or lower priority than others. The same argument of time applies to doing it, all the way down. Doing one thing before the other is a distinction lost to ultimately having to make sure all strings are “done”. Unless that policy is changed, time is best spent elsewhere for me.

I see why some developers don’t get along with the Wikipedia model of editing strings, fundamentally code is code, which is a different premise all-together, but that adjustment can be made, as (sanitized) strings fortunately aren’t. Perhaps a forgone celebration of the community, malice is near non-existent. That could be because people grew up after seeing it was possible on Wikipedia, translation platforms are still obscure, or because an account is required. Interestingly, to gain and maintain trust, the basics of translation is just one long CAPTCHA that is impossible to cheat.

The release cadence for software is, often a lot, slower, which cements potential mistakes. Saying the same potential is there now for translated language malice is a functional argument, but for reasons it shouldn’t be.

Translated versions of a program are not worth less. It is the real deal. Additionally it isn’t even a different download anymore, and the selection happens automatically.

Then of course it shouldn’t be easier to be malicious in translated languages, which is the main point. Solving it by entering a few days of post-stringfreeze only for extra reviews to tick in is possible. If they are per-reviewer, anyone could make their own list of shot-callers to decide release by. For source and translation alike. I am of the opinion that the more possibility available, the greater the result over time, which only leaves untimely instances of sabotage.

It would as you say make a lot more sense if the translators decided.
In my head there is always a rating for how difficult something is, what kind of state the string-base is in. Short of having a system to present that, it could be a lot easier to smooth it all out.

It would be interesting to see all the configuration made into a visible checklist. On Weblate right now, there is a thumbs up for libre software licenses, and an exclamation mark for any sort of merge issue.
If every step of the way, and potential config was laid out, with a green or red light, or other colour, it would be easy to see what to expect for translators, and easier to make sure everything is optimal for admins.

As a middle-ground to everyone being let loose on the source strings, maybe there could be a role for editing them directly. Moderators would have it by default, and maybe regular users should still be able to revert source string changes. (?)
There aren’t more string changes than any one person can keep up with right now, which is why I am not a fan of locking down trust.

TL;DR The source-editor role could be issued on its own to not have too many fingers on the button.

Would love for you to be a moderator at the F-Droid Weblate btw. Pending approval of @hans .

I really want F-Droid to be the one project that does localization right.

The standards for inclusion are based on a lot of factors, so there the rules can be quite different.

  • in fdroiddata, all translations are included via a manual import
  • In fdroidclient, when 70% of strings are translated, the language is included in releases
  • for the Website, we have technical limits on the number of languages we can use, so there are a number of requirements, including how big the audience is for that language (number of speakers, chance that they also speak English, and how big F-Droid is in those countries/regions) . Then there are also completeness requirements as documented here: Translation and Localization | F-Droid - Free and Open Source Android App Repository
  • @NicoAlt manages Repomaker, so he can say what those requrements are.

All of these rules are up for discussion and changing. The technical limitations must be respected, or the whole website can break, thereby not working in any language.

I’m not sure what “moderator at the F-Droid Weblate” means, but I’m definitely all for getting more people involved.

1 Like

@hans I meant that sveinki should be an administrator at F-Droid @ Hosted Weblate

How is anyone going to work out whether their language is included or not?
Does anyone check if requirements are met at any time?

What is the breakdown of speakers of fluency in English?

Website Docs and Website Tutorials needs Website and Website Pages to go live.
I take that to mean Website and Website Pages go live even if Docs and tutorials aren’t translated?

What about Posts, what are the dependencies and requirements there?

It is 53379 words in 1965 strings. Totalling 3202740 words in 117900 strings total.

Without any info presented as to what happens, the results are
German 100%
Polish 74%
Spanish 13%
Portuguese (Brazil) 8% and it tapers off from there

Polish isn’t available in the drop-down, but it is the second most translated language, sitting at 87% of total. Am I missing something?

Not that I think it should be a criteria, but it is a better one. What about where users actually are? What about which translators are available?

There are a lot of people I could ask to do something, that would result in activity, meaning translators from everywhere would come back and have a positive experience.
The ball needs to start rolling. Sinking in any heavy effort is not going to happen if it doesn’t help the project or users of it as much as it could. The heavier the effort, the higher the need to have direct editing.

Could the manual import be automated? Is there a reason why it is manual?

F-Droid client policy is not really the worst problem, since it is all fairly important, and the workload required isn’t that great. Unless you are Shona, which is 10% away from 70%, at 60. Lets at-least ease up the restrictions on less important stuff, and see if translators such as myself put their keyboards to work in solving the talking points mentioned above.

Getting “Docs” and “Posts” translated is a whole lot of work, those are to no surprise the two components with the least coverage F-Droid @ Hosted Weblate even by % of words.
It seems like languages with fewer speakers are less of a priority. (?) It may be some workload issue either in time or hardware, I don’t know.

However, there are three good reasons to treat smaller languages equally.

Historically it has been a bit lop-sided, with policy stacked against smaller ones in particular.

Two, any one translator has the potential to overhaul the whole source string-base, and doing so while translating is not only a whole lot easier, it makes sense, and happens in practice.
How many user eyeballs are connected downstream is secondary to the same argument of how many user eyeballs are looking at the source strings. We need every translator we can get, and currently a lot of them have other priorities for reasons this policy is what it is.

Thirdly, the amount of recognition, scales inversely with the amount of speakers. Having many translations available is testament to software someone cares about. Therefore I don’t think the drop-down list of languages is anywhere near ideally long right now. It respects browser headers/locale too, so it is mainly for Tor users?

Users really appreciate effort, respective to what can be expected, a few mistakes is a lot better than no translation. Translators appreciate effort too, and if treated well, will do great things.

Having the client in Shona, a feat in itself at any level, I imagine will alert people to how it is possible to even have anything in Shona. From there it is easy to direct prospective translators to Weblate. Having a good translation for a microscopic language really impresses people. I don’t speak a word of Shona, and I am blown away that F-Droid has translated strings in Shona.

Showing and appreciating effort is not a problem of how strictly professional a live translation is. What is there may predictably solve all the problems of being able to use it.

I don’t really visit old blogposts, if ever. If I did, my day would not be ruined if they were all in English. I would like to read them all somewhere that I could correct them while doing it.

Just like translation is subject to the effort/reward consideration of available translators, stuff like that happens all the time. Nobody reads any, or someone corrects all. Given more freedom here, more people will read more blogposts and documentation that is not only up to date, but improved.

Lets do the 3 last blogposts, and sort them to the top on Weblate, (don’t know if this is possible) and put top priority for those strings. (Maybe that does it) Faking it till it is all done seems like a quicker route to getting anything done. Otherwise whom? If someone, we already would see results.

Even for people that speak English just fine, having software available in their preferred language makes it welcoming. It is not home.

TL;DR
Docs and Posts are lagging behind and dragging everything else down. Technical aspects should be looked into, arbitrary restrictions should be eased.

The Play-store is fortunately bad at translation, F-Droid can and should be better.

Thank you Kingu for opening this thread and expressing some of my concerns much better that I ever could.

I do believe that the main technical contributors of F-Droid act in good faith, and that only because the project is badly understaffed some very necessary improvements get delayed too much. Being this the situation, it would be desirable to see a little more empathy towards those translation teams that are also badly understaffed but like F-Droid’s technical contributors make their best for a common goal.

Little steps are continuously given in the right direction, adding translation links for the apps distributed through F-Droid to the website is one of them, but it’s heartbreaking to see that even when the criteria for a language to be included in the Website is met, the promise is not fulfilled and those languages that benefit most of contributing to Free Software are left with little hope of seeing the work done acknowledged following the very same criteria of commercially driven projects.

I know that better solutions have been considered, Hugo has been looked at as a replacement for Jekill, it’s a big task but an overhaul of the website would certainly not harm F-Droid, and if it was to be done perhaps people that can’t contribute in the deepest technical level would feel motivated to help in the reorganization of the information or graphical design.

It’s also heartbreaking that proposing to add language information to metadata becomes a discussion about which languages can be removed using that information [1] and while the main reason for me not having continued yet are shortcomings on my side, a clear statement from F-Droid contributors denying that such contribution would be used to attack the weakest would help to clarify that we all share the same positive values.

F-Droid’s main motivation is protecting privacy, a value that possibly all contributors share, it would benefit all if F-Droid also shared the main motivation of some of their contributors. It would benefit all that instead of putting arbitrary obstacles to acknowledge some contributor’s work, and values in an arbitrary priority list, we listened better each other, all shared a common set of values, and all were considered as important and given a bit of the love share.

[1] Add human languages information to metadata (#1253) · Issues · F-Droid / Data · GitLab

Edit: *enacts > becomes

1 Like

kingu via F-Droid Forum:

How is anyone going to work out whether their language is included or not?

Does anyone check if requirements are met at any time?

What is the breakdown of speakers of fluency in English?

All good questions! Anyone can dig in, lead the discussions, and figure
out the answers.

Docs needs Website and Website Pages to go live.
I take that to mean Website and Website Pages go live if Docs isn’t translated?

Right, website and website-pages are required since they are
fundamental strings of the site. Few languages translate all of
website-docs or website-posts.

What about Posts, what are the dependencies and requirements there?

The same as website-docs.

Could the manual import be automated? Is there a reason why it is manual?

I’ve been working hard, putting weeks of work in and getting grants to
pay others to work on this question. I welcome more contributions here.

Sounds very reasonable, I understand the criteria for selecting languages for inclusion, even though I’d really like to see my dearest Icelandic be one of them.

So the next question is: Where precisely is the bottleneck for incorporating more languages?
Is it in the CMS (I doubt it’s due to Weblate itself), is it a memory problem in a VM or a hardware issue?

I have translated several websites through platforms like Weblate; some have no problem with publishing a bunch of languages, while some (like e.g. Tor) are very reluctant in adding more languages. Perhaps we should investigate similar setups and compare the components (e.g. is it Weblate → Git → CMS or straight Weblate → CMS?).

I don’t think I’m qualified for being an admin on Weblate, please see my answer here.

The current barrier is RAM usage of Jekyll/Ruby/polyglot. The RAM does
not seem to be deallocated, so it just consumes more and more per
language, until the whole process finishes;

There are three possible ways to fix it, not of them easy:

  • track down the cause of issue #78 above and fix it, so when a language
    is completely rendered, the RAM is deallocated

  • replace jekyll-polyglot in fdroid-website with another localization
    plugin that does not have this issue

  • replace jekyll in fdroid-website with Hugo, which is much faster

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.