90% is much to high IMHO. When I started using Nethserver in German there were 60-70% translated but it felt likt that 90%. Even now, when the state of the German translation is just 93% but is quite difficult to find any untranslated strings in the UI.
I would never have startet using Nethserver in German and never starting translating and correcting the rest if German would have been no option to select and try. Therefore I repeat my suggestion to have a relative low limit to encourage other people to use it and translating the rest.
50% of all strings should be a good starting point, because it will cover 70-80% of the common dialogs already.
I suggest that there is a general settings for language, locale and timezone that is used by as many applications as possible, because nextcloud also has the wrong settings.
IMVHO the “perfect” way to achieve this is double. Both quite not-featurable…
Way 1: when you create a user, for every hypothetical module of NethServer, even one that’s not installed, the configuration step must force the systadmin to choose a language and create it into every app. The list of error codes could be quite titanic.
Way 2: when you install a module, it must look for any user locale and auto-configure it into the settings of the app. And this is quite worse, because the problems that this approach can generate through the version could be… ballistic. Errors of coding, change of approach by packages, change of setting position into configuration file-and/or-db, update and upgrade mayhem.
Both are multiple evocations for bad luck, issues, pain, regressions, overcode, error collect, message building. Quite like disassemble a tanker only with fixed wrenches.
For Webtop there is already such a setting, the only point here is that, German and other languages are missing in the drop down box and also that the Geman locale settings are wrong. A simple fix.
For Nextcloud there are to config-variables in NextCloud which have to be set for the default language and locale.
In esssence: An almost trivial change to solve the problem in the 95% case.
Actually I have set this format (HU, YMD) as default in the properties admin inside webtop, and worked fine. An update changed it back in the admin, but it did not affect current users.
Users see empty values at date settings (they can select the different values), but the actual date is displayed correctly everywhere.
At least the ISO yyyy-mm-dd would be great to have, or custom setting for advanced users.