Closed
Bug 485861
Opened 16 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)
Release Engineering
Release Requests
Tracking
(Not tracked)
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.
Comment 1•16 years ago
|
||
WONTFIX, IMHO. Folks that want many locales will most likely not want all, and I expect that AMOs bandwagon will serve those needs.
Comment 2•16 years ago
|
||
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
Comment 3•16 years ago
|
||
(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.
Comment 4•16 years ago
|
||
(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.
Comment 5•16 years ago
|
||
Please move the discussion over to .platform.
Comment 6•16 years ago
|
||
bug 331779 is helpful for history.
Comment 7•16 years ago
|
||
(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.
Reporter | ||
Comment 8•16 years ago
|
||
(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.
Reporter | ||
Comment 9•16 years ago
|
||
(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.
Comment 10•16 years ago
|
||
(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.
Comment 11•16 years ago
|
||
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.
Comment 12•16 years ago
|
||
Moving to Future for now.
Component: Release Engineering → Release Engineering: Future
Comment 13•16 years ago
|
||
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.
Comment 14•15 years ago
|
||
(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.
Comment 15•15 years ago
|
||
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?
Comment 16•15 years ago
|
||
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".
Comment 17•15 years ago
|
||
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.
Comment 18•15 years ago
|
||
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
Reporter | ||
Comment 19•15 years ago
|
||
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
Updated•14 years ago
|
Whiteboard: [l10n]
Updated•14 years ago
|
Priority: P3 → P5
Comment 20•14 years ago
|
||
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
Comment 21•14 years ago
|
||
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?
Comment 22•14 years ago
|
||
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?
Comment 23•14 years ago
|
||
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.
Comment 24•14 years ago
|
||
We may be getting a lot of this for free in bug 542579, but sure, I'll double check before I delve into this.
Updated•14 years ago
|
Whiteboard: [l10n] → [l10n][mozharness]
Comment 25•14 years ago
|
||
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.
Comment 26•14 years ago
|
||
Flagging as potentially Not Mine in triage at John's request.
Whiteboard: [l10n][mozharness] → [l10n][mozharness][triagefollowup]
Reporter | ||
Comment 27•14 years ago
|
||
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]
Comment 28•14 years ago
|
||
Note, Firefox doesn't support multi-locale builds in the sense that fennec does, and thus building them is a non-goal AFAICT.
Updated•14 years ago
|
Whiteboard: [l10n][mozharness] → [l10n][mozharness][triagefollowup]
Comment 29•14 years ago
|
||
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.
Comment 30•14 years ago
|
||
(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.
Comment 31•14 years ago
|
||
I don't either, hence the triage whiteboard flag :)
Assignee | ||
Comment 32•14 years ago
|
||
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.
Reporter | ||
Comment 33•14 years ago
|
||
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
Reporter | ||
Updated•14 years ago
|
Whiteboard: [l10n][mozharness][triagefollowup] → [l10n][mozharness]
Comment 34•14 years ago
|
||
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.
Comment 35•14 years ago
|
||
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.
Reporter | ||
Comment 36•13 years ago
|
||
Havent got to this in ages - flagging for triage after talking with coop.
Whiteboard: [l10n][mozharness] → [l10n][mozharness][triagefollowup]
Reporter | ||
Comment 37•13 years ago
|
||
(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.
Comment 38•13 years ago
|
||
Then file bugs to get that implemented for desktop? Because it isn't.
Updated•13 years ago
|
Whiteboard: [l10n][mozharness][triagefollowup] → [l10n][mozharness]
Reporter | ||
Comment 39•13 years ago
|
||
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.
Comment 40•13 years ago
|
||
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]
Updated•13 years ago
|
Assignee: nobody → kev
Reporter | ||
Comment 41•13 years ago
|
||
kev: anything left to do here or is this FIXED?
Reporter | ||
Comment 42•13 years ago
|
||
(In reply to John O'Duinn [:joduinn] from comment #41) > kev: anything left to do here or is this FIXED? ping?
Comment 43•12 years ago
|
||
There a lot of interest from the Kashubian community for locale switch functionality as well.
Comment 44•12 years ago
|
||
(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
Updated•11 years ago
|
Component: Release Engineering: Custom Builds → Release Engineering: Releases
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•