A few weeks ago, a user wrote to Neil about DOM Inspector localization, including pain points. Before, DOM Inspector releases were on no schedule. (See bug 670224, comment 6.) Project-wide uncertainty around rapid release seems to have subsided. I intend to adopt a similar schedule for DOM Inspector's foreseeable future. I wrote an explanation of the approach I'm planning on taking. <https://wiki.mozilla.org/DOM_Inspector/Releases> It seems more complicated than it is, I think. Essentially, DOM Inspector has a two-stage process instead of mozilla-central's four. One is for regular development, and the other is for localization only. We will use branches for localization, so anyone who wants to contribute fixes/feature additions need not wait through a frozen development cycle, similar to what's possible with rapid release branches. You will notice that the April 24 merge date means that "the Wednesday on or before [then]" is today (it's still Wednesday in the Americas and just barely so in some parts of Europe and Africa at the time of this writing). As an exception, the first branching for localization under the proposed schedule will be off by one and instead occur next *Tuesday*, on the mozilla-central merge day itself. Sorry not to have written this up last week in order to have it ready to bring up during today's SeaMonkey status meeting. Until Tuesday, this plan is tentative and open for comments, but, barring any suggestions sufficient to sway things, I expect this to happen. Comments in mozilla.dev.apps.dom-inspector, please. This bug will be closed after the first release under the new schedule. (Which should be 2.0.12 on June 5.)

In the case of migrating to scheduled releases, Will DOM Inspector discard old versions of supported applications? Will we define an underline of support version?

When I first got involved, Shawn targeted compatibility back to 1.9.0. That's when 1.9.1 was current, but it's still the case today, and I don't have any intentions of changing that. There are a couple reasons. One is just incidental: remaining compatible with 1.9.0 hasn't meant anything has been turned away, and no approach has been dismissed for the sake of compatibility. Having said that, the other reason is that DOM Inspector is nearing EOL (as far as I'm involved, but that's really a matter for SeaMonkey to decide). I am starting work on a replacement, and by the end of Q2 2013, I do not expect to be working on DOM Inspector as it exists now. Where that's concerned, it's almost certain that anything prior to 2.0 will not be supported there. Compatibility on that project will be based on whatever Gecko ESR corresponds to, or maybe further than that, for the reasons above. There will be more on this over the next week, and I will be present at the next SeaMonkey status meeting, where I will bring all this up, if you're interested.

dom-inspector has branched for 2.0.12 localization. <http://hg.mozilla.org/dom-inspector/graph/1431> 2.0.12 is guaranteed to ship with support for at least 7 locales. <http://hg.mozilla.org/dom-inspector/file/af3dd47abfe5/resources/Makefile.in> Make sure to land any translations on the DOMI_2_0_12 branch, and (preferably) to default as well. If you do not land to default, or forget to use the DOMI_2_0_12 branch, no worries, they'll get picked up eventually (by me or anyone else who wants to step in). The next five weeks on that branch will be dedicated to bringing as many localizations as possible up to date before release. We'll see how this goes.

(In reply to Colby Russell :crussell from comment #0) > This bug will be closed after the first release under the new schedule. > (Which should be 2.0.12 on June 5.) Of course, I mean May 30 here. (Where June 5 is the mozilla-central merge date and May 30 the Wednesday before it.)

(In reply to Colby Russell :crussell from comment #0) > This bug will be closed after the first release under the new schedule. > (Which should be 2.0.12 on June 5.) 2.0.12 was approved yesterday.