bug(developer): removal of .keyboard_info from source means no way to split e.g. `und-fonipa` vs `und-latn`

[mcdurdin]

sil_ipa currently has und-fonipa as its langtag in .keyboard_info, which is the most appropriate tag. However, for compatibility reasons (e.g. #10754), the .kps lists und-Latn (which has its own problem #10727 but that's beside the point).

The problem is that we have eliminated .keyboard_info from the source of keyboards with 17.0. This means that there is no way to maintain this distinction. Potential fixes:

1. Include a fixup in the keyboard compiler to convert tags that we know will cause trouble to only include subtags in the holy lang-script-region triplet (minimizing as possible of course).
2. Just use und-latn in the keyboard search and shrug
3. Include the correct tag in .kps and .kmp, and include a fixup in all Keyman platforms for known problem cases (similar fixup to pt 1 above but at keyboard install time).
4. Use both 1 and 3 -- for v17 target keyboards, use pt 3, but all other keyboards use pt 1.

[srl295]

3 is where I was going but 4 makes some sense for compatibility. The downside is that for pre-v17, the fonipa information is then 'lost', I don't know what the user impact is though?

[mcdurdin]

3 is where I was going but 4 makes some sense for compatibility.

We need the back-compat approach because existing builds of Keyman don't have the fixup code.

The downside is that for pre-v17, the fonipa information is then 'lost', I don't know what the user impact is though?

Sadly, fonipa info will be lost in almost all cases because:

1. fonipa is not supported by Windows. We have to fallback to und-Latn (but that fails too, see OP), so we are almost back to the bad old days of Icelandic means IPA
2. Keyman for mac cannot currently set language tags (#2237, #11060, due to bugs in the macOS APIs for multi-language input methods). It's all 'mul' I think
3. On iOS and Android, Keyman does not currently set language tagging information (it should be possible, see docs linked in #2237?)
4. In KeymanWeb, in theory apps can use the language tag data, but in practice I don't know of any that do
5. On Linux, I think it might just work (but haven't tested recently but see e.g. #7728)

[mcdurdin]

I think for v17 we may have to go with option 1, and improve the story in v18 with option 4.

[mcdurdin]

I should note that there is some precedent for fixups in Keyman for Windows already, see #1285. It's all horribly messy.

[mcdurdin]

OK, so more wrinkles. Keyman Developer currently only allows lang-script-region triplet, both in the compiler, and in the UI. IMO, we are too far into beta to be making significant changes to the BCP 47 handling in Keyman Developer.

So I think that at this point, sadly, we are stuck with option 2 for v17. For v18, we'll go with option 4. The only real cost for v17 is that the keyboard search will not return anything for 'fonipa', but I suspect the number of users who try to search for that is vanishingly small.

(We need a better BCP 47 picker in Developer; the current one is stuck on lang-script-region and not actually terribly helpful even with that.)