Currently locales can set a whole range of things they should not be able to. A perfect example of this is the update URL. Another example is the year range for the copyright notice. These things are set by policy made at the app level, not the locale level. They shouldn't be duplicated since it makes updating them a chore. They shouldn't require localizers to set as it's another thing in a Long List of Things that can cause a localization to go bad and throw us into a tailspin during a QA and release cycle.

Example: bug 282070 - wrong release notes URL in about: and help start page The release notes link is defined in chrome/global/brand.dtd. I could see the utility of setting this if there was a separate release-notes page being maintained for that locale's version. Since for most locales there isn't, however, the ideal method would be to leave it undefined and have it be filled in by the value in the en-US locale (which is almost certainly going to be correct) during the build process.

If localizations should not be setting the param at all (e.g. the update URL), we should move it out of a locale package and into content/pref/hardcoded. I think that release notes need a little more thought... our build system is not set up to grab stuff from en-US into other locales, and I don't think it should be, at least until we have a much less fragile build system.

Shouldn't the update URL move out of toolkit alltogether? I'll never understand that story. For corporate deployments, IT depts probably will want to host their own, so this should be somewhere where a customization kit could play with it.

bsmedberg's recommendation for dealing with the release note URL and localization are in bug 287477

I don't believe the year range, nor the update URL are still in the strings given to localizers. Please re-open if any such insanity still exists.