[Tracking Requested - why for this release]: Reproducible : always Steps To Reproduce: 1. Install localization localized Nightly build (in my case ja build) 2. Open Preferences Alt > ツール > オプション (i.e, open about:preferences ) OR 2. Open NewTab Actual Results: All labels are in English Expected Results: Localized label should display

Regression window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cf3ee14023483cbbb57129479537c713e22c1980&tochange=380cf87c1ee3966dd94499942b73085754dc4824

Seems regressed by Bug 1459721 Nathan Froyd, It seems that your bunch of patches caused the regression. Can you look in to this?

I am having a really hard time imagining scenarios in which removing these bits from the build cause localization to fail. Did you bisect this to those patches?

(In reply to Nathan Froyd [:froydnj] from comment #3) > I am having a really hard time imagining scenarios in which removing these > bits from the build cause localization to fail. Did you bisect this to > those patches? I just assumed the patches causes the problem. may be due to others. There are no localized build between these build. And Mozregression seems do not support localized build(https://bugzilla.mozilla.org/show_bug.cgi?id=1401649 )

Both Services.locale.getAvailableLocales() and Services.locale.getPackagedLocales() regressed to just show ["en-US"] instead of [AB_CD, "en-US"].

... resource://gre/res/multilocale.txt regressed and only shows en-US instead of de,en-US

Could this be your changes from bug 1454912 in file_generate.py? Looking at my .deps/multilocale.txt.pp, I see a deps for "de", which is an argument, so you might take those away from toolkit/locales/gen_multilocale.py?

I can reproduce in Windows 7 32-bit. Build: Mozilla/5.0 (Windows NT 6.1; rv:62.0) Gecko/20100101 Firefox/62.0 Nightly 62.0a1 20180515220059

(In reply to Axel Hecht [:Pike] from comment #7) > Could this be your changes from bug 1454912 in file_generate.py? Looking at > my .deps/multilocale.txt.pp, I see a deps for "de", which is an argument, so > you might take those away from toolkit/locales/gen_multilocale.py? Yes, sorry. I didn't realize there were other file_generate actions in packager.mk. A new argument was added to file_generate to be the target for the dependency file, and so now the first locale is getting consumed for that argument. In this case I think we can just pass in $(MULTILOCALE_DIR)/multilocale.txt as the target to restore the original behavior.

I haven't started investigating, but it's possible that Bug 1460716 is relevant. That ticket changes how "built_in_addons.json" gets produced, and it's possible that New Tab (Activity Stream) is an addon. I don't think there's anything addon-y or feature-y about Preferences, though. And it should definitely *not* impact multilocale.txt, unless there's some unexpected interaction with ordering Make rules in l10n builds.

Comment on attachment 8976210 [details] Bug 1461881 - Fix packager.mk file_generate actions; https://reviewboard.mozilla.org/r/244394/#review250382 Thanks

Pushed by mshal@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b6306fd112d2 Fix packager.mk file_generate actions; r=Pike

Hello, I tried reproducing the issue on the build from the day it was reported (05/15/2018), by installing the nightly from link "http://archive.mozilla.org/pub/firefox/nightly/2018/05/2018-05-15-10-00-38-mozilla-central-l10n/". Using any of the installers there, the build from 06/04/2018 is being installed on my workstation. Even though the problem could not be reproduced due to the installer problem and given the fact that the steps to reproduce are easily understandable and hard to interpret wrongly, I will now validate this issue as it is not reproducing on Windows 10 and Nightly v62.0a1 (20180604220149).