We "shouldn't" be storing translated text in the database: we currently generate a bunch of error messages in some arbitrary user's translation, then store the raw text. We should really store some kind of machine-readable representation of the error so we can render and display it to users in their own language.

We're generally pretty good about this, but do it here, and also do it in Audit (storing audit reasons as text). Those are the only two I'm aware of.

In this particular case, it would be helpful to show the fate of each individual target: X, Y were subscribed, Z and A had already been unsubscribed, B was invalid. But doing this in a translatable way was a crazy amount of work, and that work to get the translations right was "wrong", and we can't really show handles properly, so it would be an unintelligible mess of PHIDs anyway, so I just skipped it for now.

I think this will get easier once Herald eventually modularizes and these actions can be split out per class and have translations in them, similar to how Transactions work. This sequence of diffs moves Herald toward that, although we still have a way to go.

Eventually, I'd imagine the output possibly looking something like this:

RULE                TARGET         ACTION

H23 Example Rule    epriestley     Added subscriber.
                    btrahan        This user previously unsubscribed.
                    MLST           Invalid subscriber.
                    
                                        ^
                                        |
  These would be translated properly ---+