Closed Bug 372409 Opened 18 years ago Closed 16 years ago

Migration Wizard requires string change for home page selection

Categories

(Firefox :: Migration, defect, P1)

2.0 Branch
x86
All
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: cbeard, Assigned: Pike)

References

()

Details

(Keywords: fixed1.8.1.4, late-l10n)

Attachments

(3 files)

The solution to bug 371309 requires that we change the homepage migration text to be slightly more generic, and to explicitly not include the name of a particular distribution partner.  This requires a single string change with l10n impact.

We require a descriptive string that provides users with enough information to make an informed choice of start page. While the string we've decided on is not ideal, it works in all scenarios. That is, for distribution directly from Mozilla and from any of our partners. We're effectively asserting that "Firefox Start" means the home page that Mozilla has determined to be the best possible start page for each of our distribution channels. This should be viewed as a short-term solution.

We will absolutely need to revisit this as part of the branding architecture being proposed for Fx 3.

Current String:
"Firefox Start, a fast search page with search results by XXX"

New String:
"Firefox Start, a fast home page with built-in search"
Priority: -- → P1
So, we want to have corresponding patches to https://bugzilla.mozilla.org/attachment.cgi?id=257411&action=diff#mozilla/other-licenses/branding/firefox/locales/en-US/brand.properties_sec1 for all locales, right? I'd file bugs on those for all locales and made those block this bug, then.
We can make up our mind on which locales to block or not once we have a set of patches. Requesting blocking1.8.1.3 for this bug to track that.
Flags: blocking1.8.1.3?
plussing for now, we may push bug 371309 out depending on the lead time involved here

Axel, what's your best guesstimate on time to get Tier 1 and Tier 2 locales on board here?
Flags: blocking1.8.1.3? → blocking1.8.1.3+
I don't know. I guess we'll find out once we can actually point to a particular patch to port. See comment 1, if that is what we want for the branch, I can start collecting patches in separate bugs.
Depends on: 372889
Depends on: 372891
Depends on: 372892
Depends on: 372893
Depends on: 372894
Depends on: 372895
Depends on: 372896
Depends on: 372897
Depends on: 372898
Depends on: 372899
Depends on: 372900
Depends on: 372901
Depends on: 372902
Depends on: 372903
Depends on: 372904
Depends on: 372907
Depends on: 372908
Depends on: 372909
Depends on: 372910
Depends on: 372911
Depends on: 372913
Depends on: 372917
Depends on: 372918
Depends on: 372919
Depends on: 372921
Depends on: 372922
Depends on: 372923
Depends on: 372924
Depends on: 372925
Depends on: 372926
Depends on: 372927
Depends on: 372928
Depends on: 372931
Depends on: 372932
Depends on: 372933
Depends on: 372934
Depends on: 372936
Depends on: 372937
Depends on: 372938
Depends on: 372941
No longer depends on: 372941
Depends on: 372944
Depends on: 372947
Depends on: 372952
Depends on: 372953
Flags: blocking1.8.1.3+ → blocking1.8.1.4+
Depends on: 372929
Depends on: 372930
Depends on: 372941
Depends on: 372943
Depends on: 372946
Depends on: 372948
Depends on: 372950
Depends on: 372951
Depends on: 372954
Here's the patch of localizations that we have right now.

Exclusion: zh-CN, that patch didn't want to apply magically. I hand-fixed da and it.

Incorporate languages: 
af ar ca da de en-ZA es-AR es-ES fi fr fy-NL ga-IE gu-IN he it ka ko lt nb-NO nl nn-NO nr nso pa-IN pl pt-PT ru sl ss st sv-SE tn ts ve xh zu
Why is ro missing? We have a patch in bug 372935
Because Romanian will land this as part of the merging work, no need to fix this here. Somewhat arbitrary as a decision, but good enough.
Landed the rollup patch except for fy-NL which didn't apply (there was an intervening checkin).
hrm. odd, fy-NL has been unchanged since March 2006, http://bonsai-l10n.mozilla.org/cvsgraph.cgi?file=l10n/fy-NL/other-licenses/branding/firefox/brand.properties. Anyway, that makes

af ar ca da de en-ZA es-AR es-ES fi fr ga-IE gu-IN he it ka ko lt nb-NO
nl nn-NO nr nso pa-IN pl pt-PT ru sl ss st sv-SE tn ts ve xh zu

I'll add an fixed1.8.1.4 keyword to those, and add a comment to ask those bugs to be actually closed if they landed on trunk. I'll leave that landing up to the localizers.
Going to land the next round of locales now with this attachment:

be cs el en-GB eu fy-NL ja ja-JP-mac mn pt-BR sk zh-CN
Assignee: nobody → l10n
Status: NEW → ASSIGNED
Attachment #258556 - Flags: approval1.8.1.4+
Pushing out, we've not gotten enough of the locales in to call this a blocker
Flags: blocking1.8.1.4+ → blocking1.8.1.5+
Next round of landing, Hungarian and Turkish, self-approving for the MOZILLA_1_8_BRANCH, too.
Attachment #262754 - Flags: approval1.8.1.4+
Adding fixed1.8.1.4, we're not going to land more localization fixes for this for the .4 release.

Open and shipped localizations without a fix for .4 are Bulgarian, Kurdish, Traditional Chinese.
Keywords: fixed1.8.1.4
Added bugzilla query as URL for locales not fixed in .4
Kurdish (bug #372921) now has a patch, waiting for approval. Sorry for being late, it was not possible earlier.
Clearing "blocking1.8.1.5+" given "fixed1.8.1.4" marking. If more languages need landing in 1.8.1.5 it's probably better at this point to track that in individual bugs.
Flags: blocking1.8.1.5+
Assignee: l10n → nobody
Status: ASSIGNED → NEW
Putting this bug back on my radar.
Assignee: nobody → l10n
All dependent bugs are fixed by now.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: