Closed Bug 950730 Opened 6 years ago Closed 6 years ago

Update Metro Button Text on Holly


(Firefox :: Menus, defect)

Windows 8
Not set



Firefox 28
Tracking Status
firefox28 --- fixed


(Reporter: emtwo, Assigned: emtwo)


(Whiteboard: [good first verify])


(1 file)

Should be "Relaunch in *Brand* for Windows 8 Touch" instead of "Relaunch in Windows 8 style *Brand*"
Comment on attachment 8348122 [details] [diff] [review]
v1: Update Metro button text on Holly

Bug 924914 comment 56 has a request that we update this text
Attachment #8348122 - Attachment is patch: true
Attachment #8348122 - Flags: review?(mconley)
Attachment #8348122 - Flags: review?(mconley) → review+
Hi Yuan,

Does the updated Metro button text need to be uplifted to Aurora? I'm not sure if they'd allow a string uplift but if it would otherwise really confuse users or if there is a legal issue with the current button text then maybe we can request it.
Flags: needinfo?(ywang)
I thought we have shipped those string changes in the previous uplift. It's important to get the right messaging as soon as we can, so there will be no confusion branding-wise and interaction-wise. 

Flags: needinfo?(ywang)
Comment on attachment 8348122 [details] [diff] [review]
v1: Update Metro button text on Holly

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Part of Bug 924860. Branding was decided a little later than the code had shipped.

User impact if declined: Inconsistent branding / user confusion

Testing completed (on m-c, etc.): Is currently on holly and the new text shows up as expected.

Risk to taking this patch (and alternatives if risky): minimal risk, simply a string change

String or IDL/UUID changes made by this patch: New string switchToMetroCmd2.label is added and used instead of switchToMetroCmd.label
Attachment #8348122 - Flags: approval-mozilla-aurora?
Attachment #8348122 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee: nobody → msamuel
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
This bug is extremely confusing. We broke string freeze on Aurora, which I don't like but I can get, but why did this string land on Holly and not in mozilla-central too?
Flags: needinfo?(msamuel)
This string is not added on mozilla-central because we have different strings for the different UI 

On Australis we use these strings for the metro button:

The string here is actually not being used anywhere.
Flags: needinfo?(msamuel)
Two scenarios on next merge day:
* mozilla-central (Australis) is merged to mozilla-aurora, everything works fine.
* holly is merged to mozilla-aurora because Australis still has issues, localizers working on mozilla-central will end up with a missing string after merge day.

It's just one string so far, so no big deal, but this shouldn't become an habit: l10n is not tracking holly, just mozilla-central, so landing of string changes only on holly shouldn't be happening (IMO).
This hopefully shouldn't happen again. It was only because the Metro branding decision was made after the old strings had landed. Is this one string ok for localization or should I also land it on mozilla-central? (note it wouldn't be used there)
On mozilla-central there are already several unused strings (switchToMetroCmd.label is definitely one), so we'll need to clean up things anyway after Australis starts riding the train.

I don't know the actual status of Australis, but I think it's still better to land this on mozilla-central anyway, just in case something goes wrong. It also makes l10n merges between aurora and central less painful.
Whiteboard: [good first verify]
(FWIW, I added the string to the 'remove post australis' block as part of bug 966759 because I was reviewing the other discrepancies anywhere and it was cheap. There should be no more discrepancy even if we back Australis out of aurora and use holly instead)
You need to log in before you can comment on or make changes to this bug.