Closed Bug 1238767 Opened 4 years ago Closed 4 years ago

Localized Suite build fails in DebugQA

Categories

(SeaMonkey :: Build Config, defect)

SeaMonkey 2.43 Branch
Unspecified
Windows
defect
Not set

Tracking

(seamonkey2.43 affected, seamonkey2.45 wontfix, seamonkey2.46 wontfix, seamonkey2.47 wontfix, seamonkey2.48 wontfix, seamonkey2.49esr fixed)

RESOLVED FIXED
seamonkey2.49
Tracking Status
seamonkey2.43 --- affected
seamonkey2.45 --- wontfix
seamonkey2.46 --- wontfix
seamonkey2.47 --- wontfix
seamonkey2.48 --- wontfix
seamonkey2.49esr --- fixed

People

(Reporter: frg, Assigned: frg)

Details

Attachments

(2 files)

Attached file debugqa.txt
Trying to build a de localized comm-central suite under Windows fails when trying to compile debugQA. The extension does only use en-us files but the provided ones are not found when the locales directory is processed. I believe the build process does not look for them in the tree but in the l10n basedir from the .mozconfig file: ac_add_options --with-l10n-base=c:/seamonkey/l10n/l10n-central.

See .mozconfig and the relevant error mesages in debugqa.txt. I know I am not supposed to do a release build in comm-central:) but it doesn't seem to be relevant for this bug.
Depends on how you do a localized build. If you are not using l10n-merge, the build is not supposed to work at all.
I copied three missing files from the en-US directories manually into the l10n central directory:

\de\suite\chrome\common\help\images\mail_newmail_balloon.png
\de\toolkit\chrome\global\aboutProfiles.dtd
\de\toolkit\chrome\global\aboutProfiles.properties

The first one seems to be missing in all de repositories. 

Does the tool also look into the files and adds missing variables? 

Nevertheless I think it won't help here. The build tries to switch the language to en-US during the build just for this extension. If I hack the debugQA moz.build and comment the locales dir out I end up with a at first glance fully working de Seamonkey.
(In reply to Frank-Rainer Grahl from comment #2)
> Does the tool also look into the files and adds missing variables? 

Yes, it both adds missing files and missing strings in existing files.
This patch uses the en-US files but sets them to the current locale. Previously the build did set en-US and this ended up in the xpi. This is more or less how Firefox does it with the new pocket extension if it encounters an unsupported language. 

I am quite sure this also is a prerequisite for c-a and up to fix the first error in bug 1231349 '11:24:20 Error: Multiple locales aren't supported' because it discards one en-US occurence from an l10n build.

Tested with a de local build but without l10n-merge. It would be great if someone could check it if it also works with l10n-merge.
Assignee: nobody → frgrahl
Status: NEW → ASSIGNED
Attachment #8801573 - Flags: review?(iann_bugzilla)
I really think that the real problem here is the missing l10n-merge step. This step is mandatory - even for Firefox release builds it is being done. So I wouldn't try to fix something, that ain't broken...
Adrian,

you are probably right when it comes to my build error but the repack does not expect more than one language in the tree. Without the patch DebugQA does contain an en-US dir and the repack chokes with the multiple locales not supported error you have also seen.
(In reply to Frank-Rainer Grahl from comment #6)
> Adrian,
> 
> you are probably right when it comes to my build error but the repack does
> not expect more than one language in the tree. Without the patch DebugQA
> does contain an en-US dir and the repack chokes with the multiple locales
> not supported error you have also seen.

Who said that there will be more than one locale after l10n-merge in debugQA? As you can see e.g. in this build: https://l10n.mozilla-community.org/~akalla/unofficial/seamonkey/nightly/latest-comm-aurora-linux64/seamonkey-2.48a2.de.linux-x86_64.tar.bz2 , it still contains only en-US.
And even if we want to strip other locales out of our XPIs: we should start with DOMi first then - this is the only XPI that contains more than one locale.
Doing what this patch does and&/or stripping DOMi locales are very bad ideas. The real problem is that the new repack mechanism does needlessly try to repack those add-onns at all - it should just ignore them.

debugQA is only for debugging and therefore very intentionally never localized.
DOMi has to be shipped in a package that matches the one on AMO or we run into issues with updates.
Comment on attachment 8801573 [details] [diff] [review]
1238767-debugQA-locale.patch

As per pocket, couldn't this just be:
locale/@AB_CD/debugQA/ (en-US/*)

Either way this seems fine for DebugQA r/a=me

(no stripping of DOMi though)
Attachment #8801573 - Flags: review?(iann_bugzilla) → review+
https://hg.mozilla.org/comm-central/rev/7c2e6b4b08219dc2e2c2278d0fc645678166145e

> As per pocket, couldn't this just be:
> locale/@AB_CD/debugQA/ (en-US/*)

Probably yes. While this would save some lines and would make changing file names easier I actually prefer the current version eg. if you want to need to know where a file is referenced and search via dxr or with a file search tool its found here. So I left them as they were.

No need to uplift to c-a. Only two weeks till merge day and lets first see if this breaks something.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.49
You need to log in before you can comment on or make changes to this bug.