Add support for language hints in TextFields (Android only)

[bleroux]

Description

This PR adds support for language hints in TextFields.
This is supported only on Android for the moment and the property name, aka TextField.hintLocales, is based on Android's EditorInfo.hintLocales property, see https://developer.android.com/reference/android/view/inputmethod/EditorInfo#hintLocales.

Related Issue

Fixes Support for language hints in TextFields

Tests

Adds 4 tests.
Updates several tests.

[justinmc]

Thanks for taking this on @bleroux! It's always extra work to add engine+framework features like this.

Can you take a quick look at the iOS docs (if you haven't already) to see if they have a similar feature? I just want to make sure that what we're adding is more or less compatible if so. If you can reassure me there then LGTM.

@reidbaker Would you be able to back me up by reviewing the Android code in this PR?

[bleroux]

Can you take a quick look at the iOS docs (if you haven't already) to see if they have a similar feature?

I found https://developer.apple.com/documentation/uikit/uitextinputmode/primarylanguage which accepts one language tag instead of a list of locales. It looks like we would be able to provide this feature for iOS and macOS 🎉. The comment will reflect that only the first locale is used on iOS.

@justinmc Do you think we should keep the name 'hintLocales' or used something agnostic such as 'preferredLocales'?

[justinmc]

@bleroux Let's say we keep the name hintLocales but add iOS support later. Are you thinking that iOS will take the first item in the list since it only supports one? Are the strings compatible like that?

Overall I don't have a strong opinion about the name at the EditableText/TextField level. However at the TextInputConfiguration level I wonder if we can support both separately via different values in TextInputConfiguration? In order to give fine grained control to users that might want that.

Maybe it's such a simple feature that fine grained control doesn't really matter in this case, but that's the approach I generally try to take for these kinds of cross platform APIs.

[bleroux]

Let's say we keep the name hintLocales but add iOS support later.

Perfectly fine to me. 👍

Are you thinking that iOS will take the first item in the list since it only supports one? Are the strings compatible like that?

Yes, It was my thinking. And yes the strings are compatible because the string expected by iOS is the result of Locale.toLanguageTag().

However at the TextInputConfiguration level I wonder if we can support both separately via different values in TextInputConfiguration? In order to give fine grained control to users that might want that.

Great point! I will have to think about it and share my findings.

Maybe it's such a simple feature that fine grained control doesn't really matter in this case, but that's the approach I generally try to take for these kinds of cross platform APIs.

Very interesting, thank you for sharing this.

[camsim99]

Android parts look solid to me!

[bleroux]

Thanks @camsim99! 🙏

@justinmc Based on #165554 (comment) do you think we can proceed with this PR? Once merged I will work on the iOS support.

[justinmc]

LGTM with respect to the future iOS support 👍 . So this PR supports only Android and uses the native Android name hintLocales. Native iOS calls it primaryLanguage, and that name is still available to us in case we find some reason to use both. Otherwise we can keep everything under hintLocales.

[valerauko]

Is there an issue tracking the iOS implementation for this?

[bleroux]

Is there an issue tracking the iOS implementation for this?

I filed #172620 to track the iOS implementation.
Unfortunately, it seems this is not possible to force the IME language on iOS programmatically.