Closed Bug 562760 Opened 10 years ago Closed 10 years ago
Language packs do not show up as installed
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100427 Minefield/3.7a5pre There is no way to install language packs into Firefox. There is no entry visible inside the Languages pane. Steps: 1. Go to http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/ 2. Click on an XPI and start the installation After the language pack has been installed, no entry in the Language pane is visible, even not after a restart.
Looks like the UI is looking for add-ons of type "language" and the API is calling them "locale", not sure which makes most sense right now.
(In reply to comment #1) > Looks like the UI is looking for add-ons of type "language" and the API is > calling them "locale", not sure which makes most sense right now. CC'ing Axel to see if he has a promptly idea.
Well, the language pack itself claims to be an "8".
(In reply to comment #1) > Looks like the UI is looking for add-ons of type "language" and the API is > calling them "locale", not sure which makes most sense right now. Well, we've been using "locale" internally for ages, and the chrome URL and type for language support is also called "locale", so it would be most consistent to use that here as well, I guess. Just my 2c.
10 years ago
Duplicate of this bug: 565265
Dave, would it be possible to get this fixed for our next testday mid of June?
Standardises on locale.
Assignee: nobody → dtownsend
Status: NEW → ASSIGNED
Attachment #449293 - Flags: review?(bmcbride)
Comment on attachment 449293 [details] [diff] [review] patch rev 1 I assume we still want to keep it exposed to the user as "Languages", rather than "Locales".
Attachment #449293 - Flags: review?(bmcbride) → review+
(In reply to comment #8) > (From update of attachment 449293 [details] [diff] [review]) > I assume we still want to keep it exposed to the user as "Languages", rather > than "Locales". Up to Boriss really, and covered by bug 565300, but as Robert says we've been using locale for a long time internally so I think it makes sense to continue to do so.
My personal take on the naming - the correct technical term is 'locale', and IMHO, we should use that in the code. "Language" should be close enough for the UI, but a localization note on the somewhat ambiguous use would be good. I'll watch bug 565300, too
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
The patch that landed broke some things causing there to still be no visible entry for language packs: - language category is never shown even if a language pack is installed - localized header text of language category is no longer hooked up correctly (looks for "header-locale" instead of "header-language")
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is a very quick fix for both of the points I mentioned in the previous comment. The fix for the second problem is really just a band-aid for a larger problem: the Add-ons Managers uses "language" through-out the code (theme, localization, etc.). As Axel said, we should probably change the code to use "locale" to avoid stuff like this.
Attachment #450251 - Flags: review?
Attachment #450251 - Flags: review? → review?(dtownsend)
Comment on attachment 450251 [details] [diff] [review] Second Patch Thanks for catching this Ben, however rather than working out headerName let's just rename the string in the localization properties file for clarity.
Attachment #450251 - Flags: review?(dtownsend) → review-
Comment on attachment 450251 [details] [diff] [review] Second Patch Looks like this patch should also fix bug 571200.
Also fixes Bug 571200.
Attachment #450514 - Flags: review?(dtownsend) → review+
Landed the follow-up as http://hg.mozilla.org/mozilla-central/rev/63f5ac31b8c4
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Too late for a5. Moving TM to 1.9.3 until we have an own entry for beta1. Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a6pre) Gecko/20100610 Minefield/3.7a6pre
Status: RESOLVED → VERIFIED
Target Milestone: mozilla1.9.3a5 → mozilla1.9.3
Given the discussion with Blair for an automated test for bug 553483 we should probably also mark this for in-testsuite inclusion. It would simply be a part of the test for bug 553483. Beside those tests we will also have a manual test which will probably become an FFT test.
Flags: in-testsuite- → in-testsuite?
Changing summary to reflect what was really going on.
Summary: Language packs cannot be installed → Language packs do not show up as installed
Target Milestone: mozilla1.9.3 → mozilla1.9.3a6
Manual test covered by: https://litmus.mozilla.org/show_test.cgi?id=15220 So the request for an automated test should be declined?
Flags: in-litmus?(vlad.maniac) → in-litmus+
Tests were added as a part of bug 572561
Flags: in-testsuite? → in-testsuite+
(In reply to comment #23) > Tests were added as a part of bug 572561 Would that make the Litmus test obsolete? If yes, I would favor to remove it.
(In reply to comment #24) > (In reply to comment #23) > > Tests were added as a part of bug 572561 > > Would that make the Litmus test obsolete? If yes, I would favor to remove it. Yes, I would agree
Litmus test has been disabled. I think it's the right decision because finding the corresponding language pack will always be hard and error prone.
Flags: in-litmus+ → in-litmus-
You need to log in before you can comment on or make changes to this bug.