Mobile OSes: Localization

[lucasmz-dev]

Currently, not all of OSes here support localization, it would be nice to have a column for this, especially if one is trying to give someone who doesn't know English, an older person, a phone with a private OS. Calyx does, Lineage does, DivestOS apparently doesn't but most things are from Lineage apparently, so it's mostly there except for a few things, but their own apps are also translatable. I'm not sure about the other OSes in the list.

[matchboxbananasynergy]

With every OS here being based on AOSP, 99% of the OS is translated to many different languages by default. The only thing that requires translation is OS-specific strings added etc.

In the vast majority of cases, people should be able to navigate through the OS despite that.

Also, on a more personal note, I'm wary of crowdsourced translations for such stuff. It's very easy for someone to unintentionally or even intentionally mistranslate something that can have a real impact for the user (such as mistranslating what a security critical setting added by the alt OS does, or changing it around so you think you're enabling a security setting when you're actually disabling it). If the translations are not high quality and vetted by professionals who are both technical and fluent, it isn't always a strict positive imo.

Especially for projects that focus on privacy and security and provide menus that deal with security and privacy related settings, messing with the translations would be a real attack vector as part of targeting someone. Most projects aren't considering that, and especially when it comes to less common languages, malicious changes of that nature have the potential to go unnoticed for a long time.

https://www.tomshardware.com/news/malicious-translations-target-ubuntu-2310-launch also comes to mind.

I think, if this is added, it should very clearly differentiated whether the translations are crowdsourced, or whether project members are making them officially.

[eylenburg]

With every OS here being based on AOSP, 99% of the OS is translated to many different languages by default. The only thing that requires translation is OS-specific strings added etc.

That's true. I don't think it's worth adding a row for this.

[lucasmz-dev]

99% is an unrealistic number. Sometimes not even AOSP is translated properly or fully. The impact that untranslated strings cause is not the same as the sum of strings that are or not translated;

On the crowdsourced comment, that's valid, things do happen in crowdsourced translations and as someone managing both CalyxOS and LineageOS translations for PT-BR, I have seen that a few times. But 1. There are multiple ways of doing crowdsourced translations, like having proofreaders in the case of LineageOS and 2. Even professional, paid for translators in a closed system make mistakes! I notice this on AOSP strings sometimes, and it's even more annoying because it's not like someone who notices this and is impacted by this can always contact the people in charge of it easily.

Localization is accessibility, and so it is important. It's easy to ignore this if you only know English.

AOSP is also merely a base, most things in the OS are usually replaced with proper apps, options, etc. These don't have translations that come from AOSP.

There's also the social privacy question, you want more people to have access to private tools, because if you share data with someone who doesn't use them, then that data that is yours is also at risk.

TL:DR; Not a great number, but valid point, though it can be minimized with proper tools

[matchboxbananasynergy]

But 1. There are multiple ways of doing crowdsourced translations, like having proofreaders in the case of LineageOS

Yes, meaning that you could perhaps crowdsource the bulk of it, but you still need trusted, competent translators to make sure those are correct, make sense, and that strings can be adapted at a moment's notice.

As an example, GrapheneOS in its latest release reinforced its USB-C port setting, and as part of that work, revamped the strings that explain what the setting does etc.

Now, how many languages do you think the project could be translated to that the new strings would be ready in time for the next release for? If the strings weren't ready, what do you do? Revert back to the English strings? Stay with the outdated, inaccurate strings for those languages until they're done? Withhold an update with security implications?

2. Even professional, paid for translators in a closed system make mistakes! I notice this on AOSP strings sometimes, and it's even more annoying because it's not like someone who notices this and is impacted by this can always contact the people in charge of it easily.

Of course, being a professional translator doesn't mean you're 100% perfect all of the time, which is why I mentioned that there needs to be redundancy and review for this to be done right. I wouldn't trust the most competent, professional translator to do this work on their own. What if their understanding of a feature is incorrect? etc. etc. And sure, even if multiple professionals, mistakes can be made. The point is that with having dedicated teams, those mistakes can be addressed swiftly and professionally. What happens if someone reports a mistake in a crowdsourced translation? Project members who don't speak that language put it in Google translate to try and decipher it? Wait for a new contributor to correct it? How do you verify that the correction is now accurate? And so on, and so forth.