I’m just finalizing the start of a small, funded effort ($24,500) to streamline the translation process in F-Droid, with a specific focus on the website and the Android client. We will be working directly with Weblate as well, so that the whole process, from translation to publishing releases, works easier and smoother. We also aim to make this a prototype of a larger version of this across many communities and projects, and apply for much larger funding.
For this to be successful, I need lots of feedback from the translators, as well as users with main languages other than English.
What are the most painful parts of contributing translations?
What is working well?
Can you recommend specific features in Weblate/GitLab/gettext/etc that will improve things?
What is the best way for developers to communicate to translators?
Context is nice so we could benefit from more, specially on common words.
Not sure a about the rest, Weblate works ok, and I’ve been using Crowdin and Transifex too, for comparison.
Some gripes, I can’t tell it to shut up about “strings translated the same” eg. Transparent, plural strings that are the same (they just are) and such. Maybe add an ignore botton or something.
Something missing: Crowdin/Transifex have a way to sort the strings by translation status.
Eg.
I can see ONLY UNTRANSLATED (Transifex)
I can see UNTRANSLATED ON TOP (Crowdin)
Weblate doesn’t show them as a list, you can go one string forward/backward but you see one at the time, the list below has “nearby strings” which I don’t find that useful.
If you have specific, well described issues with Weblate, you should
file an issue in that tracker. First, search to see if it is already
there. If it is already there, then click thumbs on it. Paste the
issue links into this thread so I can track then.
The funded Weblate work will be tracked in their issue tracker, so I can
then easily bunch up the issues, and mark them as part of the funded
work. We should avoid filing wishlist and feature requests for now,
since this is a small funding pool. Hopefully we’ll get more funding
later on, then it would be time for bigger requests.
From my point of view Weblate is a great translation tool for translators (of course there is still room for improvements, see Better display of changes · Issue #1570 · WeblateOrg/weblate · GitHub ): easy to use, powerful search, real-time notifications, clear status for translations (including stats), fast integration with F-droid repos (both ways), comments on strings …
Yet I have 3 major concerns:
it’s sometimes very hard to guess “context” of F-Droid strings to translate. Some tools and projects always add screenshot to string which is hard for developers but very useful for translators
I personally rate english source strings for whole F-Droid projects with an average low quality … I strongly suggest developers to write “easy understandable and translatable strings”.
translating apps description is a pain. We must think how to initialize content with “upstreams” (Google Play description …) or we will miss one of our mission: promote FOSS.
One thing I hope to achieve with all this is to make the communication between translators and developers much smoother. I think that will contribute a lot towards improving the source strings as well, since translators often give good feedback on source strings as well.
Also, @ldmpub’s post just gave me an idea: it should be possible to use Fastlane automated screenshotting in order to generate a screenshot for every string in Weblate automatically. I don’t think I’ll have time to do that myself in the near future, but I’m happy to help someone if they want to take that project on.
Hi,
Thank you for pinging the translators. As @ldmpub said, Weblate is a great translation plateforme and I’m opennely against Transifex and Crowdin.
I contribute mainly in translating F-Droid client app to Arabic as an RTL language and Weblate is just perfect for that even on Mobile situations to push more new translations.
What are the most painful parts of contributing translations?
Sometimes HTML tags or %1$s if they are not well tagued in the source language. That makes translation in RTL languages like Farsi and Hebrew more difficult.
Longuer texts are not translated. Split kilometric-texts to units and make it short and direct
What is working well?
Everything is working fine, even screenshots are good and TM Translation Machine is better on Weblate and not slavering like in Transifex and Crowdin where translators are giving a lot of their work to these plateformes and receive a shit back when it comes to use TM.
*Can you recommend specific features in Weblate/GitLab/gettext/etc that will improve things?
Generally I go to Github and open an issue and Nigel Čihař generally answers all the questions.
What is the best way for developers to communicate to translators
If they want a proactive communication, they can post a message here in the forum and tag the translators group. Or come and join us on Mastodon
Anything else we should know?
Thank you very much and DataLove <3 that F-Droid exists
But here is a list of the languages that are also likely to not be in one’s device even if they might be in AOSP. (details in the issue, we might risk to derail this topic too much) And these are only the languages which now have a reasonably usable app translation (> 70% translated). So a lot of other living languages could be affected when getting an app translation. (someone considering starting a translation could be deterred)
What are the most painful parts of contributing translations?
Testing them in context. I was going to propose nightly builds but saw that they already exist, so perhaps mentioning this in the document related to translation is enough.
What is working well?
The whole process works very well for the Android app, the translations “automagically” appear in the next version of the app and translators can focus on translation.
Can you recommend specific features in Weblate/GitLab/gettext/etc that will improve things?
GitLab Pages (which I believe it’s whats used) accepts other static pages generators. Jekyll is generally considered slow and this causes problems to F-Droid’s website generation in several languages. Not sure if using Hugo which seems to be much faster generating the static pages is an option. I know that F-Droid has created a fork of Jekyll so this might not be super easy.
What is the best way for developers to communicate to translators?
For urgent and important things (like the heads up about this thread, thank you) I prefer a direct e-mail. For general talk I suggest a Matrix room (“F-Droid Translation” for example) or something that can be used in the computer and integrates well with a mobile phone. Weblate allows comments but they are often not seen or answered until another translator happens to be on that string, a GitLab issue might not be appropriate, the IRC channel used by devs already has an specific use case, and the forum generates lots of e-mails that I honestly don’t read.
Anything else we should know?
Weblate allows to include a component in your language without annoying anyone else, but it’s not obvious to me how to remove it or if it’s even possible. The old document about translation said that the component called “Website Docs” was a requirement for a language to be included in the website, it’s not and the document has been updated, I’d like to remove that project from our language.
Related to this, translators that start a new language might not have a clear picture about which components are the most important ones, where to start. This might be solved with documentation too (Transifex has an option to set priorities but I haven’t seen this in Weblate).
Riot from F-Droid (aka without Push) uses a lot of battery, even in an empty room, we have the Gitlab pages and this forum, I don’t feel the need for yet another “medium” to track chatter.
Just ask Google to implement the language, and they do it. It isn’t worse than that.
If you also put in the work for Esperanto, there is no question it will be included.
Edit: In my opinion the greatest and most time-critical functionality to implement is recording
the latest translator of a given string, possibly the whole translator-history.
That and the comments is all the reason there is to stay behind on the likes of Transifex or Crowdin.
@kingu please, stop with “just ask Google …”
A friend just pointed out that Occitan is not available in Andro-Oued 9 OS and I’ve noticed that they assigned Algeria indic-numbers ¿ What ? indic-number ?
The only thing that I can “just ask Google” is to stop smoking … and get outside of their office.
Depending on the OS locales excludes a lot of languages and I know people that are ready to translate apps to their language but only if the app itself includes the possibility to switch the language and not delegate to the system (Andro-Oued) to do it.
Just ask … about the just ask : I know people asked Google for years, please add a keyboard in our language. Google made it many years later, respecting no standard of letters disposal or layout, without any word suggestion etc
Just do, never ask
About the section comments in any translation plateform Transithing, Crowdong, Weblate, translators are not chatty, they translate and that’s all. If there was an XMPP chat on the side bar I don’t think they’ll go there, may be unless they think they can find the devs themselves live to ask them : what the heck is this strings, or can you explain me the context of this specific string.
Salutations,
Note : I used AndrOued instead of Android because Oued is just Wadi.
I’ve seen that you can configure the forum to send only emails from the Translation category. It was sending me notifications about the general activity of the whole forum.
If you think a language is dying, and playing a chicken and egg game, having neither is not a winning strategy. More translations factor into more value to be had from inclusion, and also contributes to the TM corpus.
It worked for me to ask them, on the forum that they no longer operate, but anyways.
If the issue with a keyboard being set up the wrong way, that code is available in AOSP, for which I assume patches sent are more likely to be included than patches not. If you have a resource or words that could be used for prediction, featuring a license that is acceptable, then that could work too.
@hans I noticed F-Droid/Website Posts — Norwegian Bokmål @ Hosted Weblate is sorted oldest to newest, meaning one is more likely to translate exactly the type of thing nobody sees, unless it is popular, and get to the time-critical stuff after it has been bumped down by newer posts.
As an app developer i would like if it is possible for translators to also translate the localized app description that is visible in the fdroid app store (and may be also on the app-s homepage).
Currently i manually convert src/debug/res/values_XX/fdroid.xml to fastlane format (i.e /fastlane/metadata/android/en-US/short_description.txt or /fastlane/metadata/android/de-DE/short_description.txt)
Since the fdroid team prefers to wait for implementing a translation standard “XLIFF” instead of a simple extra convention based app/src/debug/res/values-de/fdroid.xml it would be great if the web provider has some way to also provide translation capabilities for appname, apptitle and appdescription and provide some XLIFF output thas the fdroid scanner can use as source for localized descriptions
Some statistics of my apps to see how easy-to-translate-appdescriptions help to localize descriptions (see column fdroid >= 66%)
Syncing up descriptions is a central thing that I’ll be focusing on with
this small funded project.
As for XLIFF, you don’t need to wait to use it. Just convert your
custom XML file to XLIFF. All the translation platforms support it, and
there are many tools and libraries for working with XLIFF.
The most comfortable way for app-developper and translater would be tell my translaton provider (i use crowdin) : please use app/src/main/res/values_de/strings.xml (for the app texts) plus …somewhere/fdroid.XLIFF (for the fdroid description) and let the translator do it-s job in one project
can fdroid-parser already interprete some fdroid.XLIFF for app descriptons similar to the current fastlane path convention.
I as an app developer want as few additional tools as necessary so i prefer to manually translate my fdroid.xml descriptions to fastlane format than to have to add/learn additional tools for XLIFF.
Does anybody know how translation from my by convention-fdroid.xml to fastlane format (or any other format that fdroid alreaedy supports) can be done with a gradle script?
If a gradle script can easily hadle this we just need to document it and there is no need to spend the improvement budget for this.
