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

RESOLVED WORKSFORME

Status

Other Applications
DOM Inspector
RESOLVED WORKSFORME
12 years ago
11 years ago

People

(Reporter: Jason Barnabe (np), Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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.
(Reporter)

Comment 1

12 years ago
Created attachment 228006 [details] [diff] [review]
patch v1

Don't call compare-locales.pl and add back all locales to the build.
Attachment #228006 - Flags: superreview?(neil)
Attachment #228006 - Flags: review?(timeless)

Comment 2

12 years ago
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.
Attachment #228006 - Flags: review?(timeless) → review-

Comment 3

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

Comment 4

12 years ago
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

Updated

12 years ago
Attachment #228006 - Flags: superreview?(neil)

Comment 5

12 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 6

12 years ago
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

11 years ago
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.
(In reply to comment #7)
> Perhaps we should move the locale list into its own file named working_locales
> or something.

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

(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

11 years ago
(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.
Just throwing this out there, but what aboud just having language packages for the DOMI?  See Bug 285848
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. :)
Assignee: dom-inspector → nobody
QA Contact: timeless → dom-inspector
You need to log in before you can comment on or make changes to this bug.