Closed Bug 969699 Opened 12 years ago Closed 11 years ago

Branding variable "brandShortName" not correctly replaced for non en-US locales accross the OS

Categories

(Firefox OS Graveyard :: Gaia, defect)

x86_64
macOS
defect
Not set
normal

Tracking

(b2g-v2.0 unaffected, b2g-v2.1 affected)

RESOLVED DUPLICATE of bug 996479
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- affected

People

(Reporter: u497809, Assigned: u497809)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140201074923 Steps to reproduce: I built a gaia debug profile with the following command: DEBUG=1 make And ran gaia with the latest firefox nightly build. With the firefox OS emulator, I scroll to the second page and click on the Settings application. Actual results: The second to last option on the page says "Improve {{brandShortName}}" Expected results: The selection label should have the template value filled in as "Improve B2G OS" if using the unofficial locale branding and "Improve Firefox OS" if using the official locale branding.
OS: All → Mac OS X
Hardware: All → x86_64
The reason this bug occurs it seems is that under /shared/locales/branding the branding files are now split between "unofficial" and "official" If possible I would like to claim this bug. I think by checking the PRODUCTION variable in the makefile we can choose the correct one and render the template correctly.
Assignee: nobody → erhlee.bird
Status: UNCONFIRMED → NEW
Component: Gaia::Settings → Gaia
Ever confirmed: true
Summary: In various parts of the Settings page, the template value "brandShortName" leaks through without being replaced. → Branding variable "brandShortName" not correctly replaced for non en-US locales accross the OS
Just noticed the bug was opened way before master was affected, but this is currently affecting master builds on Flame since a few days. Maybe dupe of another bug. Flod, you opened something?
The branding issue was fixed in bug 996479, the only pending problem was that we were still failing if we set a default locale different from en-US (we don't fall back), and that's bug 1030035. The issue came back in the last couple of days. For clarity I'm closing this as dupe of bug 996479, and keeping one of the other two open.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: