IssueTracker

Please provide following information which will help us to investigate this further,

* What is the desired behavior of the feature? (Be specific!)

* If relevant, why are current approaches or workarounds insufficient?

* If relevant, what new use cases will this feature will enable?

Desired behavior:
- if you add Latin to the inputType field of an EditText, the keyboard should switch to latin characters
- there are no current approaches...if you search stackoverflow, some other folks have requested the same thing but apparently never filed a feature request here; you can use an inputFilter on the edit field but then the user gets confused that they can't type anything in their asian or middle eastern keyboard
- use case is if you're in non-english countries and you need to fill out fields that have to be in english (e.g., your passport name and flight passenger name), it can be done w/o requiring them to switch device locale settings or without putting up an error msg that it's not valid

Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

* Probably the initial step to make this request actionable is to properly define what "latin" means.  If it is basically identical to "English", then you can already specify "en" to EditorInfo#hintLocales [1] to tell the keyboard that "English" is expected here.  If it's strictly identical to printable characters defined in ASCII, then you can already specify IME_FLAG_FORCE_ASCII [2][3] flag to EditorInfo#imeOptions.  If it's a bit more broader concept, e.g. characters like ä, ö, ü also need to be supported, then it'd be a bit more tricky because each application may require slightly different set of acceptable characters.  Therefore just defining one new mode without a clear spec may just introduce another compatibility problem.
 * Keep in mind that even with those hints, it's still possible that the user may just copy and paste any characters that are not supported by your application.  Autofill feature [4] may also inputs user's name without explicit typing.  It's also possible that the current keyboard does not support such a hint and completely ignore it.  Therefore, having such a hint does not completely solve the problem regarding inputFilter and user confusion you pointed out.  Application developers still need to take care of the case where unsupported characters are input and need to do their best to avoid user confusions.

 [1]: https://developer.android.com/reference/android/view/inputmethod/EditorInfo.html#hintLocales
 [2]: https://developer.android.com/reference/android/view/inputmethod/EditorInfo.html#ime_flag_force_ascii
 [3]: https://developer.android.com/reference/android/support/v13/view/inputmethod/EditorInfoCompat.html#IME_FLAG_FORCE_ASCII
 [4]: https://developer.android.com/guide/topics/text/autofill

The use case is anything that can be put on a passport holder name field, so it'd be any Latin characters including diacriticals, so for a Java regex, it'd be:
\p{L}+
for a first name field, etc.
Sounds like best bet is to add an input filter w/ the above regex and also hint the keyboard to english if an Arabic or Asian locale is detected for now.  Ideally, "latin" would mean anything matching that regex if you do plan to add this as an imeOption.

I didn't realize there was a hintLocale option to nudge the keyboard into showing a different locale.  I'll add this info to a few of the stackoverflow answers...thanks.  This is probably one of the most comprehensive replies I've ever seen in a ticket :-)

Once again, thank you for submitting the feature request. After following up with our product and engineering teams, the feature request will not be able to be considered at this time.