The priority has been set on all the strings so that newer blog posts are shown first. Before, the oldest posts were shown to translators first. Hopefully this makes it much easier to translate blog posts.

You can join us in the following ways:

Source strings

3,912 Strings 100%
Browse Translate
107,206 Words 100%
877,146 Characters 100%
This translation is being used as source strings within this component.

Strings status

Strings Words Characters
3,912 107,206 877,146
All strings Browse Translate Zen
3,912 107,206 877,146
Read-only strings Browse Translate Zen
1,356 29,716 303,571
Strings with any failing checks Browse Translate Zen
2 82 483
Translated strings with dismissed checks Browse Translate Zen
3 221 1,445
Failing check: Unpluralised Browse Translate Zen
17 829 6,280
Failing check: Ellipsis Browse Translate Zen
1,344 29,028 299,148
Failing check: Multiple failing checks Browse Translate Zen
43 2,197 16,803
Strings with comments Browse Translate Zen
140 1,192 19,432
Labeled: do-not-translate Browse Translate Zen
3,772 106,014 857,714
Strings without a label Browse Translate Zen

Overview

Project website f-droid.org
Instructions for translators

See: https://f-droid.org/docs/Translation_and_Localization

There is also a mailing list for translators: [](otfl10n@googlegroups.com)
Project maintainers User avatar eighthaveUser avatar linsuiUser avatar uniqx
Translation license GNU Affero General Public License v3.0 or later
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository https://gitlab.com/fdroid/fdroid-website.git
Repository branch master
Last remote commit run tools/post-release-translation-merge.sh c9e960d1
User avatar eighthave authored yesterday
Last commit in Weblate Translated using Weblate: Chinese (Simplified Han script) (zh_Hans) by linsui <linsui@users.noreply.hosted.weblate.org> 2085fad8
linsui authored 6 hours ago
Weblate repository https://hosted.weblate.org/git/f-droid/website/
File mask po/_posts.*.po
Translation file Download po/_posts.pot
Last change Jan. 28, 2025, 5:17 p.m.
Last change made by None
Language English
Language code en
Text direction Left to right
Number of speakers 1,728,900,209
Number of plurals 2
Plural type One/other
Plurals Singular 1
Plural 0, 2, 3, 4, 5, 6, 7, 8, 9, 10, …
Plural formula n != 1
yesterday

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 3,912 107,206 877,146
Translated 100% 3,912 100% 107,206 100% 877,146
Needs editing 0% 0 0% 0 0% 0
Read-only 100% 3,912 100% 107,206 100% 877,146
Failing checks 34% 1,356 27% 29,716 34% 303,571
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

10 changes 0 changes 31 changes 65 changes 54 changes 13 changes 7 changes 9 changes 55 changes 60 changes 6 changes 0 changes 37 changes 0 changes 11 changes 52 changes 65 changes 2 changes 30 changes 21 changes 4 changes 28 changes 0 changes 48 changes
JanFebMarAprMayJunJulAugSepOctNovDec

Quick numbers

106 k
Hosted words
3,890
Hosted strings
100%
Translated
1
Contributors
and previous 30 days

Trends of last 30 days

+3%
Hosted words
+100%
+2%
Hosted strings
+100%
—
Translated
+100%
+100%
Contributors
—
User avatar None

Resource updated
The “po/_posts.pot” file was changed. yesterday
User avatar None

String added in the repository
This integrates nicely in how _fdroidserver_ works. It is structured as a pipeline, where packages are fed in, many processes are run on them to verify them and extract data. Anything that fails to verify is automatically deleted, so no further processing or publication will happen. `apksigner verify` serves as a strict gate on that pipeline.
This integrates nicely in how _fdroidserver_ works. It is structured as a pipeline, where packages are fed in, many processes are run on them to verify them and extract data. Anything that fails to verify is automatically deleted, so no further processing or publication will happen. `apksigner verify` serves as a strict gate on that pipeline.
yesterday
User avatar None

String added in the repository
The combination of the complicated X.509 and APK formats means that no implementation is going to get it right the first time. It is conceivable, based on the 15 years of experience in Androguard and _fdroidserver_, that no implementation will ever cover all the edge cases of the combination of these two formats. To keep the code maintainable, there needs to be something to limit the scope. The verification implementation of _apksigner_/_apksig_ seems to be the stricter of the two official Android implementations, so _fdroidserver_ uses `apksigner verify` as the gatekeeper. It has an official POSIX API that is dead simple: 0 on success, non-zero on failure.
The combination of the complicated X.509 and APK formats means that no implementation is going to get it right the first time. It is conceivable, based on the 15 years of experience in Androguard and _fdroidserver_, that no implementation will ever cover all the edge cases of the combination of these two formats. To keep the code maintainable, there needs to be something to limit the scope. The verification implementation of _apksigner_/_apksig_ seems to be the stricter of the two official Android implementations, so _fdroidserver_ uses `apksigner verify` as the gatekeeper. It has an official POSIX API that is dead simple: 0 on success, non-zero on failure.
yesterday
User avatar None

String added in the repository
Ultimately, the `AllowedAPKSigningKeys` is a piece of metadata that is designed to be easily used by any implementation that people want to use. A repo maintainer can add that metadata, then get _fdroidserver_'s built-in checks when running `fdroid update`. Then if that is not enough, it is easy to script up alternate approaches.
Ultimately, the `AllowedAPKSigningKeys` is a piece of metadata that is designed to be easily used by any implementation that people want to use. A repo maintainer can add that metadata, then get _fdroidserver_'s built-in checks when running `fdroid update`. Then if that is not enough, it is easy to script up alternate approaches.
yesterday
User avatar None

String added in the repository
Also, keep in mind, I know of no implementation of APK certificate pinning out there. I suppose Google Play has one, but that'd be secret. So we have to roll our own. And we want people to try to break it, and try alternate approaches.
Also, keep in mind, I know of no implementation of APK certificate pinning out there. I suppose Google Play has one, but that'd be secret. So we have to roll our own. And we want people to try to break it, and try alternate approaches.
yesterday
User avatar None

String added in the repository
* how many people are going to watch that, then switch away from Tomcat, Drupal, Wordpress, etc
he might be more security maximalist than Danial Micay.
* Like, sacrificing so much functionality in the name of security.
* I'll bet he hates Android too, since there are known vulnerabilities that GrapheneOS fixes...
* how many people are going to watch that, then switch away from Tomcat, Drupal, Wordpress, etc
he might be more security maximalist than Danial Micay.
* Like, sacrificing so much functionality in the name of security.
* I'll bet he hates Android too, since there are known vulnerabilities that GrapheneOS fixes...
yesterday
User avatar None

String added in the repository
It is an easy response to do quickly, and it doesn't mean we have to drop everything and switch to some other workflow.
It is an easy response to do quickly, and it doesn't mean we have to drop everything and switch to some other workflow.
yesterday
User avatar None

String added in the repository
I've been thinking about how I could have handled that response better. How about when someone dumps some bug report to the internet and claims "security", we just open issue to track it ASAP, then toot out that we are tracking it in our issue tracker? Then proceed from there?
I've been thinking about how I could have handled that response better. How about when someone dumps some bug report to the internet and claims "security", we just open issue to track it ASAP, then toot out that we are tracking it in our issue tracker? Then proceed from there?
yesterday
User avatar None

String added in the repository
* both APK and X-509 certificate are fluffy, endless specs that no implementation gets fully right.
v2 and v3 signatures are looking pretty tight, but they messed some stuff up with the v3.1 signer rotation (e.g. apksigner v33 bug)
* both APK and X-509 certificate are fluffy, endless specs that no implementation gets fully right.
v2 and v3 signatures are looking pretty tight, but they messed some stuff up with the v3.1 signer rotation (e.g. apksigner v33 bug)
yesterday
User avatar None

String added in the repository
so adding technical debt to support invalid APKs makes no sense.
so adding technical debt to support invalid APKs makes no sense.
yesterday
Browse all translation changes