Hi, I’ve started some translation. However I see some strings are very old (2+ years, e.g. refers to new UX in 2017). Are these still relevant? If not should they be removed? Thanks
2 Likes
In each individual string, right side there’s a Source information panel:
Source string age
2 years ago
Oh that, yes, we have apps from 2012 still in the repo. :))
I see…then should I leave those? I’m on the website posts component
Yes, as they are needed.
sorry another question, in my language there are different components that need translation. In particular:
Data, Website Posts, Website Docs. Which one is more important? So I can give priority to that. Thanks!
- Translations for “Data” will be used by the client as they happen,
there is no threshold that needs to be met. - For f-droid.org, “website” and “website-pages” need to be 100% to be
included. - For any particular page in any of the Website sections, it must by 80%
complete to be included, otherwise that page will be shown in English.
1 Like
great, thanks for the clarification! 
Also be sure to check out the docs: Translation and Localization | F-Droid - Free and Open Source Android App Repository
We keep all website strings available for translation, but not all must be translated. website-posts is all the blog posts since 2017. Some translators have gone back and translated them all, but most haven’t.
Currently only German and Polish nerds have bothered to translate the News section.
Prospects of improvement are poor. The Weblate database has about 2,700 strings with 64,000 words.
There won’t be a large number of translators who will do such an effort with the expectation to see their work when 80 % is completed.
I think one should seriously think about
- the policy and handle this section like Data - translations used if available -
or - a cut and remove all posts elder than a particular period (not from site but from Weblate)
1 Like
The 80% rule is per-page, not per Weblate component. For example, a
single blog post in “website-posts” that is 50% translated will still be
published in English, even if every other blog post in “website-posts”
is translated.
“website-docs”, “website-posts”, and “website-pages” have many pages in
them. Once “website” and “website-pages” are fully translated, then the
rest of the translations are included as they happen. So yes, kind of
like the “Data” section.
Curiously,
F-Droid - Norwegian Bokmål @ Hosted Weblate (top 10 translation coverage)
F-Droid - Icelandic @ Hosted Weblate
F-Droid - Esperanto @ Hosted Weblate
all qualify.
But the actual reason is, the build server can’t handle it, not enough people speaking those languages, the dropdown list on the website gets too long.
F-Droid - Korean @ Hosted Weblate
F-Droid - Chinese (Traditional) @ Hosted Weblate
F-Droid - Chinese (Simplified) @ Hosted Weblate
F-Droid - Ukrainian @ Hosted Weblate
F-Droid - Persian @ Hosted Weblate
F-Droid - Albanian @ Hosted Weblate
don’t qualify, but are still available, for similarly inane reasons.
I’m not changing anything related to how the languages are selected/chosen for the website. I just output whatever options are selected/chosen.
Just had a look and Icelandic is operational now? Under “/is/” option (here).
If those other two languages are ready then they probably need to be added to the _config.yaml also?
(The new drop down that I’ve developed is designed to scroll, so there should be no problems with the list being too long, but please do check it yourself by making your screen small).
1 Like
I’m currently the one managing the website language deployment, and I fully acknowledge I’ve made mistakes. It makes me happy to see all this translation activity, and pains me that I can’t just leave it up to the translators when a language is ready to launch.
FYI, I wrote a script for me to check which languages are meet the deployment criteria, its in the fdroid-website git repo, its called ./tools/print-language-status.py. Anyone can run it, but its not polished in anyway. Right now, it says eo, pt, and pt_PT are ready. I’ve been talking with the Portuguese translators about how to manage the 3 pt translations. Given limited resources, I’m hesitant to include Esperanto since by definition, basically all Esperanto speakers speak another language better. This is purely a practical concern, this is not a value judgment on Esperanto. My personal opinion is that people should be free to use whatever language they want.
2 Likes
You allowed a full translation of a whole language, one that is very tiny, and rationalize it shouldn’t be used because users of it speak another language?
That is neither the point of, or the way to do localization.
Just make better excuses, anything. It didn’t have to be that.
I’ve received a lot of criticism over that policy, but very few workable suggestions. I’ve tried to implement the feasible suggestions. If someone has a realistic policy that is better, I’m happy to defer to them.
1 Like