The SubtleNotificationView strings have keys with borders around them, like "Press [Esc] to exit". The key names are expressed as pipe-delimited segments in the string like this:
"Press |Esc| to exit".
But in our localizable strings file, the key names are (at the moment) always substitutions, like this:
"Press |$1| to exit".

It's been questioned twice [1, 2] why we do this, instead of either a) hard-coding the key name in the strings file (e.g., "Press |Esc| to exit") or b) just using the substitution and not pipe delimited segments (e.g., "Press $1 to exit").

[1] https://codereview.chromium.org/1421813005/diff/1/chrome/browser/ui/exclusive_access/exclusive_access_bubble.h#newcode93
[2] https://codereview.chromium.org/1995893002/diff/1/chrome/app/generated_resources.grd#newcode12664

The truth is I basically took the middle ground here. (a) is preferable from a translation perspective (as estade@ and some localization people at Google I spoke to offline have recommended). But it's hard to do that because there are so many cases where we want to change the strings (e.g., sometimes you have to press F11 to exit full screen; in the "go back" notification view sometimes it's Alt, sometimes it's ⌘, we may need to swap ← for → depending on RTL). So we would have to permute all the strings with all the different possible keys. These changes can happen dynamically (based on run-time decisions), and also as the code evolves over time (we may want to fix RTL UI bugs without having to redo all the translations). That's why I chose not to do (a) at the time.

(b) is the opposite of (a); we change it so it's impossible to hard-code key names in the string and always use substitutions for key names. It also makes it impossible to use a substitution in these strings for anything that is not a key name. But it means we don't have to parse pipe delimiters, or tell translators to include them. I chose not to do (b) at the time because I didn't want to commit us to always using substitutions for key names when our localization team had told us that is undesirable. It also means SubtleNotificationView has to be strongly coupled with the localization system (as it is now, the client simply passes a pre-substituted string to SubtleNotificationView with pipe characters), so while it makes the code simpler, it makes the design more complex.

So in the end I kept both the substitutions and the pipe characters. It wasn't necessarily the best decision, and it could be changed if someone strongly thinks (a) or (b) are better than the current middle-ground. But TL;DR, localization is hard, and there were good reasons behind my decision to do neither (a) nor (b) at the time.