Ping @jantimon, I think this would also fix #328?

// input
const pluralCodeFromKey = key => key === '0' ? 'en' : key === '1' ? 'de' : null
const mf = new MessageFormat(['en', 'de'], { pluralCodeFromKey })
compileModule(mf, ['{count, plural, other{EN}}', '{count, plural, other{DE}}'])

// output
import { de, en } from "@messageformat/runtime/lib/cardinals";
import { plural } from "@messageformat/runtime";
export default {
  "0": (d) => plural(d.count, 0, en, { other: "EN" }),
  "1": (d) => plural(d.count, 0, de, { other: "DE" })
}

Changes look good! I like this more explicit arbitrary mapping strategy as opposed to assuming normalization. Thanks!

Been punting this until "later" for a while, but ultimately I agree with the option rename suggested by @cdaringe. It wasn't so much the shape of the change that was tricky here, but the scope of what it doesn't do.

Specifically, this PR doesn't actually fix the exact issue that was originally reported in #359, which used the '*' locale and locale codes that include a region specifier. For usage like that, the best that's available is to set something like

const localeCodeFromKey = (key) => key === 'es-MX' ? 'es' : null

and then you'd get es rather than es-MX formatting.

However, the issue is fixed for language+region locale codes if the input list of locales is explicit, i.e. something like ['en-us','es-MX'].

If someone's interested in improving the former without breaking the API, then I'd be willing to consider a PR on it. But for now, I'm going to add the option as localeCodeFromKey, and package a new release with it.