Last modified: 2011-09-13 03:35:13 UTC
As outlined in bug 30665, there is some wikitext that the JS parser won't accept. That's fine, but currently when it fails it breaks the page. That's probably bad, since the current expectation is that broken wikitext simply won't render. This caused Arabic UploadWizard to fail entirely because of a typo in the translation (and probably a few other languages as well, but I didn't test). I bet there's something that could be wrapped in a try/catch, and this would be fixed. It would even be fine if it failed to return the message entirely, but without halting JS execution.
What sort of breakage is happening, at what level? If it's a parse error in the PEG.js-generated parser, then there's not much more you can 'catch' than the entire 'yes it parses' / 'no it doesn't'.
Put in for example "{{SIETNAME}}" and it breaks.
Or, something like [ $1 is a foo] (note leading space). This doesn't render to anything in the php parser, fyi. It'd be fine to catch it at the level of "nope, doesn't parse." It could even throw an an informative error at the console, like "message [messagename] failed to parse". The trouble is when the entire page breaks, and it takes some time to even discover that it's a problem with i18n. If a single message is broken, I bet most users will still be able to figure out what to do.
*** This bug has been marked as a duplicate of bug 30707 ***