So... For what it's worth, there are currently 4 different possible strings here (thanks to document.domain). This is for property gets. There are also 4 for property sets, and 4 for function calls. Total of 12. If we added differentiation as above (7 clarifying strings saying what didn't match), then we'd need 84 different strings, right? There's got to be a better way of doing this....
Oh, and in the code that constructs this there are actually more cases than the 12 I listed, because there is sometimes no object principal or some such....
We could treat the clarifying strings as separate l10n tags from the "what wasn't allowed" strings, concatenating them after translation but before passing to the console message constructor? Like what I did in bug 524223 for the clarification messages that couldn't be translated. And hopefully l20n gives us better options...?
Concatenation after translation is pretty chancy. It often gives .... suboptimal output.
I don't think that edge cases like this in the setup are really worth going into the trouble of adding tons of more strings, or ughly hacks in our current infra. We can revisit this once l20n is ready for production, though. That doesn't imply that I'm really convinced this is good to do even then.
This isn't an edge case, though. This is a fundamental issue of us reporting not-very-useful error messages when we have more information that could make them more useful... If it weren't for l10n issues, I'd do this in a heartbeat, using the approach from comment 3. Maybe we should just do that and ignore the l10n problems it causes?
You need to log in before you can comment on or make changes to this bug.