I don't think this is about "magic words" - those are things like Fixes T123. This is about "regular" l18n: Differential is producing a form it can't read.

That's correct, there are no magic words in my diff message. The template I'm given when I create a new diff contains text (I assume because of the Pirate language setting I've chosen) that causes Arcanist/Differential to choke when the message is committed, as "Spies" isn't a valid heading in the Diff message.

We tend to combine similar issues into one so they are resolved at the same time by the same diff. The correct solution I believe here is the same as "magic words". That we need to maintain a list of words that are localized that trigger actions. "Spies" should get picked up and parsed as "Subscribers", just like "Fixin'" should be picked up and parse as "Fixes".

"Spies" should get picked up and parsed as "Subscribers", just like "Fixin'" should be picked up and parse as "Fixes".

Right; I forgot they were both Fields now...

This is sort of very vaguely related to T5586, although I don't know if the fix will end up being the same or not.

The fields we read are not translated:

public function getCommitMessageLabels() {
  return array(
    'CC',
    'CCs',
    'Subscriber',
    'Subscribers',
  );
}

One of the reasons this isn't translated is the same as the reason magic words in T5586 aren't translated: the number of values may differ between languages. For example, a language with several plural forms may want to provide a list like this instead:

Subscriber-one, Subscribers-few, Subscribers-many

If we just put pht() on those strings, languages would be forced to provide exactly as many translations as English does.

The field label we write is translated:

public function getFieldName() {
  return pht('Subscribers');
}

Some other general problems:

• Maybe commit messages should be generated in a single language in a repository? It seems undesirable to mix Emoji, Spanish, Russian, Pirate, and ALL CAPS in the same repository, for example.
• When reading a commit message, we have no explicit cues about which language it is written in.
• It's possible that the same word (say, "Abracadabreur") might identify two different fields in two different languages (say, it means "Subscriber" in Russian and "Reviewer" in German). In this case, we could not parse things unambiguously without knowing the language.
• If we parse fields in any language, it makes the problems in T11085 worse (we'll get a lot more false positives).

It might be reasonable to un-pht() the field names in the short term until this gets solved for real, although it would be nice to see a use case with a legitimate translation rather than Pirate.