343518 - Don't require localizations to be complete for DOM Inspector to build

Status: RESOLVED WORKSFORME

(Other Applications :: DOM Inspector, defect)

Description

[Jason Barnabe (np)]

When adding strings to DOM Inspector, currently all translations have to be present for it to even build. These leaves the following options:

- Break the tree
- Define blank or English strings for the other locales (Axel says this is bad in bug 109481 comment 28)
- Wait for all translations to be completed before checking in and/or
- Remove those locales from the build and add them back later when translations are complete

All these options suck, so instead let's change DOMI to not require complete localizations.

Comment 1

[Jason Barnabe (np)]

Attachment: patch v1

Don't call compare-locales.pl and add back all locales to the build.

Comment 2

[Axel Hecht [:Pike]]

Comment on attachment 228006 [details] [diff] [review]
patch v1

Just not running compare-locales doesn't fix this. If you want this to happen, you need to come up with something better that actually doesn't ship localizations with error messages.

Comment 3

[Axel Hecht [:Pike]]

... and I don't understand what sucks about not shipping broken locales.

Comment 4

[timeless]

if $(BUILD_OFFICIAL)
	@$(PERL) $(topsrcdir)/toolkit/locales/compare-locales.pl $(srcdir)/en-US $(srcdir)/$(AB_CD)
else
	@$(PERL) $(topsrcdir)/toolkit/locales/compare-locales.pl $(srcdir)/en-US $(srcdir)/$(AB_CD) || echo Error $(AB_CD) needs to be fixed or else it won't be shipped
fi

Comment 5

[Axel Hecht [:Pike]]

From a basic point of view, DOMI doesn't require the localizations to be complete to build, you can just remove them from the build. For broken localizations that is the *exaclty* right thing to do (independent of BUILD_OFFICIAL, too).

Though, for the time being, inspector will stay a localized extension, and that comes with a project management complexity.
From my experience with the management of the complexity of l10n I can give you the good news that your assessment in the initial comment is not true, there are far more options.

Which those are and how to make a better compromise between the requirements of l10n and the DOMI is a bigger discussion, which should be held in the newsgroup, bugs don't make a good forum. I suggest .l10n right away, you'll end up having to face those folks come rain or shine.

Resolving WORKSFORME, I expect we'll be better off with new bugs once the public discussion comes to an end. There's a dash of WONTFIX in my resolution, too, both are not really sounding nice, but that's bugzilla.

Comment 6

[Jason Barnabe (np)]

If reverting back to en-US-only every time a string is added is fine with you, I can live with that. All I really want is to be able to make patches without having to wait for translations.

Comment 7

[timeless]

i'd vote for leaving all translations out on trunk and forcing someone else do their own builds and enable it on branches when they're ready.

i'm getting very sick of the munging and i don't appreciate having to review changes to the makefile every time. and i most certainly don't appreciate that the version log for makefile.in is wasted on useless l10n work.

The reason Makefile.in is under a VCS is to show *meaningful* changes to DOMIs build system, not to show which locales didn't work at a given point in time.

Perhaps we should move the locale list into its own file named working_locales or something.

Comment 8

[Shawn Wilsher :sdwilsh]

(In reply to comment #7)
> Perhaps we should move the locale list into its own file named working_locales
> or something.

Bug 355793 perhaps?

Comment 9

[Marek Stępień [:marcoos, inactive]]

...and have the DOMi locales back in the l10n-cvs, like it was a long time ago with Firefox 1.0.

Comment 10

[Shawn Wilsher :sdwilsh]

(In reply to comment #9)
> ...and have the DOMi locales back in the l10n-cvs, like it was a long time ago
> with Firefox 1.0.

Is that a bad thing?  If so, why?

Comment 11

[Axel Hecht [:Pike]]

(In reply to comment #7)
> i'd vote for leaving all translations out on trunk and forcing someone else do
> their own builds and enable it on branches when they're ready.

"Someone else" is the very problem with DOMI. As long as nobody claims to own it, it will remain a broken and unhappy beast.

Comment 12

[Shawn Wilsher :sdwilsh]

Just throwing this out there, but what aboud just having language packages for the DOMI?  See Bug 285848

Comment 13

[Marek Stępień [:marcoos, inactive]]

Shawn: So, you would need to install a language pack to an extension that is installed by default in a _localized_ Firefox - no, that makes no sense.

The only good solution is to get back to the situation from around 1.0, when localizers could take care of DOMi without making timeless angry. :)