As discussed over in bug 707294, we should move the strings in dom.properties that are overridden by the webapp runtime into appstrings.properties, since dom.properties is updated frequently but has no history of being overridden, while appstrings.properties is updated rarely and has long been overridden by other apps.

fzzzy: can you provide an update on the status of this? I know we've discussed it, but it'd be useful for this bug to contain a summary of where you're at, so other folks know the status.

The other option fzzzy and I discussed is implementing a mechanism by which a toolkit application (like the runtime) can selectively override strings in a platform l10n strings file (like dom.properties), so it isn't necessary to copy all platform strings into an application-specific file in order to override some of them. We discussed doing something like that in bug 707294, but we decided to implement a short-term fix for that bug, which resulted in this enhancement request. And although it seems straightforward, fzzzy suggested to me recently that it's actually more complicated, given the way various code accesses dom.properties and appstrings.properties. In any case, I'm ok with either approach. One way or the other, however, we should address this issue so the DOM hackers who touch dom.properties don't have to keep duplicating strings.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #2) > The other option fzzzy and I discussed is implementing a mechanism by which > a toolkit application (like the runtime) can selectively override strings in > a platform l10n strings file (like dom.properties), so it isn't necessary to > copy all platform strings into an application-specific file in order to > override some of them. This was one of Axel suggestions (bug 707294 comment 5), IIRC we talked on IRC and he said he wasn't sure how much effort was needed to fix nsStringBundle.

The web runtime has been removed in bug 1238079.