Closed Bug 485861 Opened 15 years ago Closed 12 years ago

create Firefox repack containing all locales, in addition to the usual single locale repacks

Categories

(Release Engineering :: Release Requests, defect, P3)

Product:
Release Engineering
Component:
Release Requests
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: joduinn, Assigned: kev)

References

Details

(Whiteboard: [l10n][mozharness][partner-repacks]) 

Can we produce a repack which contains *all* the locale strings? 

I was thinking this could be produced, like all the other repack/locales, and placed in http://www.mozilla.com/en-US/firefox/all.html with all the other locales. Not sure what to call it, maybe "multi-locale" or "multi-lingual" or "all-locales"?

A user could then get just the locale-switcher addon, and easily switch from one locale to another - useful in multi-lingual environments. From email with bsmedberg, one possibility would be to include locale-switcher addon in the addon manager dialog, so user would not need to even get the addon. From email with Armen, another possibility might be to dynamically download other locales using a new not-yet-written addon.

Because of concerns about possible slower startup time, this would not be the default download, this would just be listed with all the other locales. We will need to confirm if this multi-locale build will have slower startup times, and if so, how much slower and why.
WONTFIX, IMHO.

Folks that want many locales will most likely not want all, and I expect that AMOs bandwagon will serve those needs.
I also suggest WONTFIX.  I think this can easily be done in an extension, downloading the language XPIs from the releases server based on Firefox version and OS (such as <http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0.8/linux-i686/xpi/af.xpi>), and if no one else steps up to create such an extension, I can give it a shot.  :-)

One point though, we need to fix bug 485860 in order for this extension to be able to switch to English (US).
Depends on: 485860
(In reply to comment #0)
> another possibility might be to dynamically download other locales
> using a new not-yet-written addon.
As far as I know Quick Locale Switcher (https://addons.mozilla.org/firefox/addon/1333) is doing just that. 

What can be a problem is that extensions updates are separated from product updates, and user might end with a broken application in case there are some added string since last product update (3.0.4 -> 3.0.5 for example) and he have not yet updated the langpack. There were some talks at #l10n on this subject.
(In reply to comment #1)

> WONTFIX, IMHO.
> 
> Folks that want many locales will most likely not want all, and I expect that
> AMOs bandwagon will serve those needs.

What's the downside of shipping with all locale packs?  Is it the amount of
space used by all locale strings?  Seems like you could restrict that problem
by limiting the set of languages to Tier1/Teir2 or some other subsetting
scheme.  Or is the problem one of handling updates for multiple lang packs?

Not having all locale strings prevents us from doing the right thing on Mac OS
X, namely displaying strings in the user specified locale (see bug 383523). 
Multiple accounts on a given machine can have differing user locale prefs,
there isn't the concept of a "system" locale, only a set of supported user
locales.  In situations where machines are shared (universities, internet
cafes) this is a real scenario.

Problems with language pack/extension dependencies seem like bugs that should be fixed.
Please move the discussion over to .platform.
bug 331779 is helpful for history.
(In reply to comment #5)
> Please move the discussion over to .platform.

Sure, no problem.  However, for this bug could you summarize the technical hurdles involved with doing this?  For example, "size of string files is too large" or "handling multiple locales together is complicated and/or is too slow".

Whether this is a desirable task for a future release is a fine topic for the newsgroups.
(In reply to comment #3)
> (In reply to comment #0)
> > another possibility might be to dynamically download other locales
> > using a new not-yet-written addon.
> As far as I know Quick Locale Switcher
> (https://addons.mozilla.org/firefox/addon/1333) is doing just that. 

My quick experiment with Quick Locale Switcher last week required me to manually download and install the xpi file separately. Maybe I was doing something wrong, but fyi.
(In reply to comment #5)
> Please move the discussion over to .platform.

ok, done. And also cross-posted to l10n and some others just in case.
(In reply to comment #4)
> Not having all locale strings prevents us from doing the right thing on Mac OS
> X, namely displaying strings in the user specified locale (see bug 383523). 

For exactly the same reason, to be able to show the browser using a user-chosen locale, Fedora ships Firefox with (almost?) all locales as add-ons. As a consequence of this, after any browser update on the first start the browser checks all those language packs for compatibility. It may take some time especially on netbooks and is rather annoying.
Re comment 4: creating a repack for all locales has little to do with shipping a multi-locale app on the mac. That should be a full app including the right search for the right locale etc. Which we don't have infra for. Nor does matchOS work in a way that we'd switch it on. Which brings the interesting artifact that matchOS probably has an additional (and repeating) impact on startup time.
Moving to Future for now.
Component: Release Engineering → Release Engineering: Future
I'm not particularly interested in letting people be able to switch at runtime, but for mobile where we might want to ship with a device targeted at any number of locales, being able to have a single package that contains all the locales would be useful.
(In reply to comment #13)
> I'm not particularly interested in letting people be able to switch at runtime

This isn't entirely what I meant to say.  If we could set the locale once I wouldn't worry about changing it at runtime, but we would need to select it at runtime at least once.
So that's first run locale setting, right?

Is mobile interested in an *all* locale build, or a specific selection of all locales?

Is there a scenario in which that first run locale selection needs to be changed?
I suggest filing a separate mobile bug related to this but with the Mobile team's needs from l10n and RelEng.   It seems like the premise of this bug related to shipping an "all-strings, multi-locale Firefox".
On the Mac, the locale that's used is based on the user's language setting at app startup.  All Apple apps (Safari, iPhoto) do this.  I don't think there's ever a requirement to switch locale after app startup.  If a user changes the language setting, it typically only changes apps that startup after that point.

For multiple users, this means that when UserA logs in with English as the default language, they see English.  When UserB logs in with Japanese as the default language, they see Japanese.  Same OS, same app binary, no reboot between changes of users.  Having multiple locales available would allow this to work.
Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Priority: -- → P3
fyi: we now do multi-locale repacks for Fennec. We learnt a bunch of mechanics doing that which should make it "easier" to do similar in Firefox.
Depends on: 377881
Whiteboard: [l10n]
Priority: P3 → P5
I'll take this bug with the scope of "create a factory that can create a multi-locale repack"; turning this on for specific platforms and branches can be filed as followups to this if wanted/needed.
Assignee: nobody → aki
FYI, Firefox still doesn't have infrastructure to do a real multi-locale build (search is missing, at least), nor do we have a concrete idea what that really is.

Re comment 8, could you find a link on google groups on that discussion?
I'm going to guess this is http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/83763197c4a420df?pli=1 .

As I mentioned in comment 20, I'm not going to make any decisions about whether to ship anything, or even whether to repack anything, just create a factory that's capable of placing multiple languages in one tarball/installer. Does that work?
I didn't find any posts by folks like beltzner, jay, christian (of course) endorsing the idea. You probably want to make sure that you're spending your cycles on this at the right time.
We may be getting a lot of this for free in bug 542579, but sure, I'll double check before I delve into this.
Depends on: 574473
Whiteboard: [l10n] → [l10n][mozharness]
Both Chrome and Opera has all shipped languages easily available in Prefs (Opera provides international installer by default and manages to pack everything in 8.5MB). This should be done in Firefox as well IMO. Locales should not be listed in add-ons, where they would clutter the interface (dictionaries already do that now) and would be hard to find. Language and dictionaries settings has nothing to do in the about:addons tab, it should be part of general preferences.
Flagging as potentially Not Mine in triage at John's request.
Whiteboard: [l10n][mozharness] → [l10n][mozharness][triagefollowup]
1) We already do multi-locale repacks for Fennec on maemo and android. This bug is about shipping a multi-locale repack of Firefox (called "multi"), in addition to the usual set of single locales that we currently ship.

2) From a user-scenario point of view, it could be useful to have this available for use in internet cafes, as well as for bundling Firefox in distros, or partner repacks, that contain multi-locales.

3) From a mechanical point of view, in RelEng, a lot of this work comes for "almost free" once we have our Fennec multi-locale release automation code consolidated with our Firefox release automation code. WebDev would need to add the new "multi" locale listed at the bottom of the website pages, after all the usual locales.

4) Once the automation code is in place, we appear to have a chicken-and-egg situation (no multi-locales without a locale switcherUI ; no locale switcher UI without a multi-locale repack to put it in). To unjam us here, I suggest we bundle a locale-switcher addon by default in this multi-locale repack to see if people use it. Or we could make the multi-locale repack available and have people install a locale-switcher addon from AMO themselves if they want to switch locales. We could then start getting usage data, and see if its worth continuing to generate this multi-locale repack.
Summary: create repack containing all locales → create Firefox repack containing all locales, in addition to the usual single locale repacks
Whiteboard: [l10n][mozharness][triagefollowup] → [l10n][mozharness]
Note, Firefox doesn't support multi-locale builds in the sense that fennec does, and thus building them is a non-goal AFAICT.
Whiteboard: [l10n][mozharness] → [l10n][mozharness][triagefollowup]
At risk due to tegra work / mobile 0.8 blocking work.  However, dependent on my mozharness changes in bug 628571.

(In reply to comment #28)
> Note, Firefox doesn't support multi-locale builds in the sense that fennec
> does, and thus building them is a non-goal AFAICT.

Noted. This is, however, still open as various people want this, and is on our q1 goals list because it's a releng old bug.


(In reply to comment #27)
> 3) From a mechanical point of view, in RelEng, a lot of this work comes for
> "almost free" once we have our Fennec multi-locale release automation code
> consolidated with our Firefox release automation code. WebDev would need to add
> the new "multi" locale listed at the bottom of the website pages, after all the
> usual locales.
> 
> 4) Once the automation code is in place, we appear to have a chicken-and-egg
> situation (no multi-locales without a locale switcherUI ; no locale switcher UI
> without a multi-locale repack to put it in). To unjam us here, I suggest we
> bundle a locale-switcher addon by default in this multi-locale repack to see if
> people use it. Or we could make the multi-locale repack available and have
> people install a locale-switcher addon from AMO themselves if they want to
> switch locales. We could then start getting usage data, and see if its worth
> continuing to generate this multi-locale repack.

(3) is *maybe* almost free and *maybe* a lot of hidden work. (4) is open ended and a little unknown in my mind.
(In reply to comment #29)
> 
> Noted. This is, however, still open as various people want this, and is on our
> q1 goals list because it's a releng old bug.

You should revisit that decision. I don't see you producing a working build in Q1, given how many dependencies you'll have on Firefox changes.
I don't either, hence the triage whiteboard flag :)
I like that it's not being left to wither and die, however. Aki, let me know if there's anything I can do to assist with rationale/impact outside traditional channels. I would love to see this in the (very) near future, but agree it's at-risk and is a non-goal.
In triage, re-reading comment#0, one possible solution would be to:

* take a standard single locale build (maybe en-US?)
* add the xpi files for other locales (which locales? all locales?)
* include a locale switcher addon
* package them all together
* add that packaged build to the bottom of list of localized builds on ftp.m.o

Talked with Aki; I'm taking to investigate.
Assignee: aki → joduinn
Whiteboard: [l10n][mozharness][triagefollowup] → [l10n][mozharness]
At least search, bookmarks and installer won't have feature parity. Not sure if that's an exhaustive list. Nor what product and UX would actually want.
I believe Mike Beltzner will have some opinions about this feature request.  He has expressed his viewpoints to me in the past when discussing this with him so I added him to the bug.
Havent got to this in ages - flagging for triage after talking with coop.
Whiteboard: [l10n][mozharness] → [l10n][mozharness][triagefollowup]
(In reply to comment #34)
> At least search, bookmarks and installer won't have feature parity. Not sure
> if that's an exhaustive list. Nor what product and UX would actually want.

Whatever is good enough for Fennec multi-locale builds sounds ok for desktop Firefox multi-locale builds too, imho.
Then file bugs to get that implemented for desktop? Because it isn't.
Whiteboard: [l10n][mozharness][triagefollowup] → [l10n][mozharness]
Met with Kev this week:

1) Kev confirmed he still has a need for a single Firefox install that can switch to different locales. Right now, he's thinking about OEM situations, where Firefox running in the locale of the host OS is desired. Not having this is hampering his bizdev work.

2) Kev does not believe he cares whether this is implemented like the multi-locale repacks of Fennec, or like the partner-build-suggestion of comment#0.

Therefore, we agreed to keep this bug open for now. Kev, coop and joduinn to investigate the partner-repack-suggestion as that seems easiest, and uses automation we already have.
From talking to joduinn yesterday, it's my understanding that Kev was going to try to set this build up as a partner repack.

Kev: let me know if you need any script changes/help to get this done. I imagine we'll need some kind of accessory script to refresh the included langpacks.
Assignee: joduinn → nobody
Component: Release Engineering → Release Engineering: Custom Builds
Priority: P5 → P3
QA Contact: release → custom-builds
Whiteboard: [l10n][mozharness] → [l10n][mozharness][partner-repacks]
Assignee: nobody → kev
kev: anything left to do here or is this FIXED?
(In reply to John O'Duinn [:joduinn] from comment #41)
> kev: anything left to do here or is this FIXED?

ping?
There a lot of interest from the Kashubian community for locale switch functionality as well.
(In reply to John O'Duinn [:joduinn] from comment #42)
> (In reply to John O'Duinn [:joduinn] from comment #41)
> > kev: anything left to do here or is this FIXED?
> 
> ping?

I'm going to reso/inco since no specific patches ever got attached/landed from this bug explicitly.  It has been over a year since joduinn asked :kev for info here, and no reply in-bug. We can re-open if this is still wanted.

(In reply to Jurk from comment #43)
> There a lot of interest from the Kashubian community for locale switch
> functionality as well.

Locale Switching functionality in the addon manager is entirely seperate from the goals of this bug, this bug was about the need/desire for Mozilla to produce a build of Firefox with more than a single locale embedded/bundled.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Component: Release Engineering: Custom Builds → Release Engineering: Releases
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.