66909 - Shouldn't need restart to see new locale in View menu

Status: RESOLVED INVALID

(Core :: Internationalization: Localization, defect)

Description

[Robert Kaiser]

Currently, if you install a new locale via an XPI Language Pack, you have to
restart Mozilla to see it in the list in View > Languages and Web Content.

But as this works 'on the fly' with skins, I think also the locale menu should
be updated instantly so that you only need one restart for installing and
changing to a new locale - and that is the one _after_ selecting it (though it
woulde be nice to aviod that, too).

Comment 1

[Robert Kaiser]

This is actually an issue splitted from bug 57441.

As both restarts mentioned in that bug report are completely different nature, I
filed this one as a seperate issue, whcih should be easier to fix.

I assume this should also go to tao (like 57441), so reassigning.
Also adding intl keyword like in other bug.

Comment 2

[tao]

The UI menu needs to be refreshed!

Comment 3

[tao]

Hi, Dan:

I think two things need to done:
1. The installer script notifies the changes of the DS.
2. The UIs listens to the topic.

Any thought?

I'll reassign this to you and take it back when (1) is done!


thx

Comment 4

[tao]

BTW, I thought that installer will select the installed langpack when installation
is complete. Should I log a bug?

Comment 5

[Daniel Veditz [:dveditz]]

There is already bug 54904 about the inability for a xpi script to select 
chrome; for point 1. you could make this bug blocked by that one and then take 
this one back to cover point 2.

When implementing the installChrome (used by the Theme Park) skin selecting 
worked fine because there was a "RefreshSkins" command in the chrome registry. 
But for locale stuff I was told you have to call ReloadChrome, and then I was 
told not to due to crashes.

Comment 6

[tao]

>When implementing the installChrome (used by the Theme Park) skin selecting
>worked fine because there was a "RefreshSkins" command in the chrome registry.
>But for locale stuff I was told you have to call ReloadChrome, and then I was
>told not to due to crashes.

Right. For now, let's still do the select locale without calling reloadChrome().

Comment 7

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 8

[Andreas Becker]

Changing QA contact to [e-mail]

Comment 9

[Robert Kaiser]

I originally splitted this from bug 57441 'cause I thought the other restart
should stay a problem of the orginal bug.
Tao created bug 62174 for the second restart (after applying locale) and fixed
57441 for the smaller menu-refreshing issue, if I understand it correctly.

So I think this is now a dupe for the one it was orginally slitted off (57441).
Man, this gets somehow sounding strange...

As I see this one depending on 54904, I'm not marking dupe before asking. What
should we do?

Comment 10

[Jon Rubin]

The restart message currently (as of 07-07 Windows trunk and branch builds) says
to restart to use the new "preferred language setting" when selecting a new
region.  It should say "region setting" in the case of a region change.  Does it
make sense to fix this when restarting eventually won't be necessary?  How
difficult is it to customize the message for language and region changes?

Comment 11

[Robert Kaiser]

If bug 65241 is getting resolved the way that discussions in that bug showed,
the menu item "Languages and Web Content" as well as "Apply Theme" should go
away anyway, making this bug invalid (yes I hate bugs I reproted getting invalid
but sometimes the roads we take do not turn out to be the roads we envisioned
them to be...)

Anyway, if the menu item does go away, we won't need a different message for
region/content packs here...

Comment 12

[[e-mail] (away - not reading bugmail)]

adding myself to the cc list

Comment 13

[Andreas Becker]

mass change, switching qa contact from jonrubin to ruixu.

Comment 14

[Robert Kaiser]

this is 1) INVALID because we don't have that entry in view menu any more, 2)
working if you don't use DELAYED_CHROME (and that only has to be used on Linux
due to bug 109044).

Ergo, marking my own bug as invalid :-/
Well, it has been alive for 15 months anyway...

dveditz, I hope you don't feel upset when I invalidate a bug assigned to you...