1462480 - Lightning l10n merge is not working in comm-esr60

Status: RESOLVED WONTFIX

(Calendar :: Build Config, defect)

Description

[Frank-Rainer Grahl (:frg)]

Building an l10n Lighting package will result in an xpi with en-US only strings. The internal merge step seems not to work correctly.

Comment 1

[Frank-Rainer Grahl (:frg)]

Attachment: .makex6417tb.sh

Build script

Comment 2

[Frank-Rainer Grahl (:frg)]

Attachment: .mozconfig-tb.x6417

mozconfig

Possible hints:
This still worked on May 9. Afterwards bug 1436662 was pushed and I needed to switch to mozilla as topsourcedir. 
Bug 1436662 currently breaks the TB installer but the merge step is still executed.

Only l10n-base needs to be definied now. The merge is done internally. I suspect this is what causes or contributes to it. Maybe REAL_MERGE_DIR is undefined.

This works on 61+ after bug 1439469.

Comment 3

[Frank-Rainer Grahl (:frg)]

After bug 1439469 got uplifted to esr60 probably fixed by now.

Comment 4

[Jorg K (CEST = GMT+2)]

I have no idea.

From TB drivers: There is an issue with langpacks not working for calendar (Bug 1469678), that I'm not sure what to do with.

Comment 5

[Jorg K (CEST = GMT+2)]

Sorry, "I" was Tom Prince.

Comment 6

[Frank-Rainer Grahl (:frg)]

> that I'm not sure what to do with.

If you don't want to open a can of worms probably nothing :) We are struggling with this stuff since 2.41 (hint now 2.60). To fix this I can only think to do a separate langpack for Lightning like ChatZilla in SeaMonkey (which currently breaks the merge if done). To really fix it get rid of the xpi unless it is now possible to do a multilocale xpi. Pocket should have the same problem imho.

Comment 7

[Wayne Mery (:wsmwk)]

Is there a new reality now that calendar is not an add-on?

Comment 8

[Frank-Rainer Grahl (:frg)]

Sorry for the late reply. With the integration it can be closed.