Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Description • 14 years ago

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.

	Dave Townsend [:mossop] Assignee
	Comment 1 • 14 years ago

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.

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 2 • 14 years ago

(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.

	Axel Hecht [:Pike]
	Comment 3 • 14 years ago

Well, the language pack itself claims to be an "8".

	Robert Kaiser
	Comment 4 • 14 years ago

(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.

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 6 • 14 years ago

Dave, would it be possible to get this fixed for our next testday mid of June?

	Dave Townsend [:mossop] Assignee
	Comment 7 • 14 years ago

Standardises on locale.

	Blair McBride [:Unfocused] (UNAVAILABLE)
	Comment 8 • 14 years ago

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".

	Dave Townsend [:mossop] Assignee
	Comment 9 • 14 years ago

(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.

	Axel Hecht [:Pike]
	Comment 10 • 14 years ago

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

	Dave Townsend [:mossop] Assignee
	Comment 11 • 14 years ago

Landed: http://hg.mozilla.org/mozilla-central/rev/5ca801749b47

	Ben Parr [:bparr]
	Comment 12 • 14 years ago

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")

	Ben Parr [:bparr]
	Comment 13 • 14 years ago

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.

	Dave Townsend [:mossop] Assignee
	Comment 14 • 14 years ago

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.

	Blair McBride [:Unfocused] (UNAVAILABLE)
	Comment 15 • 14 years ago

Comment on attachment 450251 [details] [diff] [review]
Second Patch

Looks like this patch should also fix bug 571200.

	Ben Parr [:bparr]
	Comment 16 • 14 years ago

Also fixes Bug 571200.

	Dave Townsend [:mossop] Assignee
	Comment 17 • 14 years ago

Comment on attachment 450514 [details] [diff] [review]
Second Patch v2

Great, thanks

	Dave Townsend [:mossop] Assignee
	Comment 18 • 14 years ago

Landed the follow-up as http://hg.mozilla.org/mozilla-central/rev/63f5ac31b8c4

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 19 • 14 years ago

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

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 20 • 14 years ago

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.

	Blair McBride [:Unfocused] (UNAVAILABLE)
	Comment 21 • 14 years ago

Changing summary to reflect what was really going on.

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 22 • 13 years ago

Manual test covered by:
https://litmus.mozilla.org/show_test.cgi?id=15220

So the request for an automated test should be declined?

	Dave Townsend [:mossop] Assignee
	Comment 23 • 13 years ago

Tests were added as a part of bug 572561

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 24 • 13 years ago

(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.

	Dave Townsend [:mossop] Assignee
	Comment 25 • 13 years ago

(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

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 26 • 13 years ago

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.