Also, is it intentional that the field name is wrapped in pht(...) but the field aliases are not?

Good catch on the array typehint, I think I just missed that. I'll add it in a followup.

The lack of pht() on the lists of elements is intentional, but tricky / nonfinal. There are two issues:

One issue is that there may be 3 variants in English ("Fixes", "Fixed", "Fix"), but, say, 6 variants in Chinese, 22 variants in Russian, and only 2 variants in French. Ideally we'd have some kind of pht_list(...) construct which allows translators to provide a list of different strings. A better example of this might be if we implement an emoji-suggestor down the road (where you type "boar" and get 🐗 suggested): an emoji like 🐗 might have many more names and associations in Russian than in Spanish. If we just pht() each English item in the list, each other language must have exactly that many items. A simple way to build this would be to just pht('a, b, c') and then explode the result on , and trust translators to figure it out. We might end up doing that, or something similar. But it would theoretically be nice to have something a little more formal.

The second issue is that commit messages are ultimately written to the repository and they can't be parsed unambiguously if we don't know which language they were written in. I don't have a solution for that, yet. Probably, putting a magical [@en_US@] marker somewhere in the commit body, I guess? Or a big mess of per-repository options and defaults and such. But if we have a commit message and don't know what language it's written in, we can't parse it: "El Plano de Testo" may mean "Test Plan" in Spanish and "Reviewers" in Korean. This has already caused some issues with the Pirate locale and "Reviewers" being written as "Me Hearties" or something, but we're just kind of faking our way through for now since essentially no one actually wants to write commit messages in a non-English language so far.

Thanks for the explanation.