Broken out from crbug.com/373324 - admins would like the ability to limit which languages and keyboard layouts are available in user sessions.
Max to prioritize this since primary use case is for EDU users.
In our case our students have been changing the keyboard settings during Spanish class to give them an unfair advantage. Would really like to lock this setting down.
we need US intl by default so the students do not have a access settings in order to switch from us to us intl. there shoudl be a way to control this on the admmin console
Doing Chromebook management for a K-12 district approaching 8000 Chromebooks this year...this request is no joke. If we want to stay productive with this product we NEED the ability to lock the kids' language settings inside their profiles.
This is still ongoing and becoming more of an issue for us, especially using Canadian Multilingual devices where the language picks up the settings of the previous user. This should be a high priority for EDU
School district with ~3000 chromebooks reporting in, this feature would be incredible. An option for default setting would be best for us, I believe. My best case scenario would involve the chromebooks reverting back to a default keyboard layout and language in both the sign-in screen and in-session after every restart/sign-out. Full locking might be nice for certain situations, but I know plenty of the students in my district will use another keyboard language/layout legitimately and I would like this option without keeping them from that ability.
Status: Fixed (was: Started) Summary: Allow limiting available languages within user sessions. (was: Allow limiting available languages/keyboard layouts within user sessions.)
Re Comment #26:
This issue has been splitted - support for restricting languages within user sessions as an administrator has been added on the client (but not yet on the Google Admin console).
bug 841301 adds support for restricting keyboard layouts within user sessions as an administrator. That part has not been implemented yet (but has been split off from this bug for tracking purposes).
I see that in the proposed Cl https://crrev.com/c/1071532 we are allowing only language codes that satisfy [ l10n_util::CheckAndResolveLocale(language, &resolved_locale) && language == resolved_locale ] condition. I.e. we do not allow language aliases.
This sounds like a sanity check to keep server and client data in sync, but we have keyboards for languages without UI support. This check will require users of some language variants to manually adjust their keyboard layout.
I don't think this is particularly bad , but it's just something to keep in mind.
This policy only affects the UI locale, which Chrome OS is displayed in. The user can still add other languages to his list of preferred languages or add input methods for those.
I renamed the policy and all occurences of this policy to reflect that only the UI locale is affected (https://crrev.com/c/1071532)
Re #32: My point was that UI language automatically enables default input method for this language. Language variant may have different default keyboard layout.
This probably only affects login screen and Guest session, but still this is something to keep in mind.
Checked using Yaps on
Google Chrome: 69.0.3486.0 (Official Build) dev (32-bit)
Platform: 10866.1.0 (Official Build) dev-channel kevin
Firmware: Google_Kevin.8785.264.0
Observation:
1. AllowedUILocales Policy is loaded.
2. Forced languages (de,en-US) are seen in settings and able switch between them.
Attached screenshots. Please take a look. Thanks.!
Deleted:
Screenshot 2018-07-13 at 2.57.44 PM.png
190 KB
Comment 1 by docon...@handcrossparkschool.co.uk
, Feb 22 2017