Closed Bug 224194 Opened 21 years ago Closed 20 years ago

Locale Switching in UI

Categories

(Firefox :: General, defect, P3)

Product:
Firefox
Component:
General
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Firefox1.0beta

People

(Reporter: kinger, Assigned: mconnor)

References

Details

What Firebird is missing is a UI for switching locale language packs. This
exists in Mozilla at:
Edit->Preferences->Appearance->Languages/Content

As a result, the process is complicated for the end-user, and most likely will
turn some away.

I'm sure this is something localisers are itching for too so they can build XPIs
and not full installers each time.

See for more details:
http://texturizer.net/firebird/localize.html
This is a major enhacement and should be definitly a blocker for 0.8
sorry for bugspam
Flags: blocking0.8+
not blocking 0.8.
Flags: blocking0.8+ → blocking0.8-
The missing of this UI is really the most annoying thing for us localisers. As
long as we don't have this UI, we can't really offer languagepacks, because
installing by hand is way too dificult for most people.
It shouldn't be difficult to implement either, 'cause the backend is still there.
Still missing in 0.8.

Note -- there is an extension that adds another option panel called ttlo (Things
they left out), and this includes a lang switching panel. I can't vouch for it's
reliability however.
Flags: blocking0.8- → blocking0.9?
This bug makes firefox much less interesting for me:
1) Living Belgium, we have websites with multiple languages. I want to control
the language(s) served to me.
2) For testing internationalised sites, I need a flexible way to switch
languages. This works great in Mozilla 1.6 but is missing in firefox 0.8.
3) The humor factor when setting multiple languages is just to great. Several
sites will serve 1 page with, e.g., 3 languages intermixed <g>.

I tried the Language Menu extension, but it doesn't solve 1), only 2) but in a
quite convoluted way (to me at least).
Eric:
You're talking of something different here. We're talking of a panel that can
switch the browser's UI language ("Appearance > Languages/Content" in
Seamonkey). You're talking of a panel that can influence the languages the web
sites show ("Navigator > Languages" in Seamonkey; changing tha HTTP
Accept-Language directives).

That's two different things. Your issue may be a different bug, it's not this
one. Your issue is not changing the Language (locale) that the Firefox UI is
shown in.
Robert,

You are correct. I missed the point and found the bug I want is bug 181541.
Going over there to vote :-)
Do we have a new timeline when this will be implemented? We should offer it
lately with 1.0.

-> QA
QA Contact: bugzilla
We need to evaluate what we're doing wrt l10n/i18n for 1.0beta, but there isn't
time to do this right for 0.9, unfortunately

taking so that it stays on radar for 1.0beta
Assignee: firefox → mconnor
Flags: blocking0.9? → blocking0.9-
Priority: -- → P3
Target Milestone: --- → Firefox1.0beta
*** Bug 241395 has been marked as a duplicate of this bug. ***
Flags: blocking1.0?
Language switching for web pages is covered by a different bug. We won't be
doing UI language switching, at least not before 1.0, and not in the default
English Language builds. -> Extension.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
This is an essential part of the application and it makes more sense for english
builds then for others. People first download the english builds and change the
language later, when languagepacks are available.
Even if I don't agree with you, about the priority of this bug, I wonder why you
changed the status to won't fixed instead of changing the target milestone to
after Firefox 1.0 as you mention in your comment.
Ben, thanks for pissing int'l users and contributors off another time.
I'm getting more and more sure why I should just dump that piece of crap you're
seemingly prodicing labelled as this burning fox. Should it burn down, I won't
shed a tear if the developers are all acting like you.
Kairo, please keep arrogant and personal attacks out of Bugzilla.

Also, wouldn't the logical thing be to create a nice localizable extension that
can be bundled with the language pack install?  That way users who install the
langpack get the UI they need, and others don't have useless UI cluttering up
their UI?
Flags: blocking1.0? → blocking1.0-
the more I think about it, the more it makes sense to make that part of the
language pack install, instead of a core feature.

If someone distributes a native build, they don't need this UI either, its only
if you install an additional langpack, in which case leverage the extensibility
of the product and add the required UI at that time.

verifying WONTFIX.
Status: RESOLVED → VERIFIED
This approach is okay with me (I wanted to suggest something similar anyway),
but who will provide the extension? In my opinion this should be a mozilla.org
service, like the dom-inspector since it will appear like a core feature of the
browser.
When you install a Language Pack, it doesn't become the default one.

Mike, in case I install a LP, from where should i know how to apply/avoid it?

Mike. what about just a combo box to switch between LPs, that will be shown
*only* if I have more than one LP?
The extension could be written and made available as a part of whatever toolkit
the MLP provides.  If I find time to write/test something like this before 1.0 I
will, but that's not my current priority.

Asaf: the language packs are installed using XPinstall, and could easily be
adapted to also install a extension to provide this UI, with absolutely no need
for any core UI to be implemented.  That's the entire point: unless you install
a langpack, including the UI is pointless.  A function that keeps checking for
the presence of langpacks is bloat for the 95% of users who use native
localizations.
Asaf and Mike,
How about these?

Setting languages & locales by flyson.
http://fls.moo.jp/moz/lang-locale.html
(This page is written in Japanese.)


Yet-another language changer by me.
http://www.geocities.co.jp/SiliconValley-SanJose/9076/JLP/ya-langchange.en.html
(Sorry for funny English.)

I provide 'private version' Mozilla Thunderbird Japanese LP
with ya-langchange.



And I think adding locale switching feature to XPInstaller is good for many users...
(In reply to comment #20)
> The extension could be written and made available as a part of whatever toolkit
> the MLP provides.  If I find time to write/test something like this before 1.0 I
> will, but that's not my current priority.
> 
> Asaf: the language packs are installed using XPinstall, and could easily be
> adapted to also install a extension to provide this UI, with absolutely no need
> for any core UI to be implemented.  That's the entire point: unless you install
> a langpack, including the UI is pointless.  A function that keeps checking for
> the presence of langpacks is bloat for the 95% of users who use native
> localizations.

That OK, but you are ignoring that most of the LPs creators are NOT developers
and don't know how to implement all this stuff...

You didn't give attention to the option of enabling this UI only when there is
more than one LP installed.
> That OK, but you are ignoring that most of the LPs creators are NOT developers
> and don't know how to implement all this stuff...

You're making it seem like its horrendously complex.  Obviously there would 
need to be instructions, but its fairly trivial to implement this if you're 
already creating an XPI.

> You didn't give attention to the option of enabling this UI only when there is
> more than one LP installed.

"A function that keeps checking for the presence of langpacks is bloat for the 
95% of users who use native localizations."

There is absolutely no need to implement something in the core that would be 
enabled only if you install another add-on.  Especially if said add-on can 
easily piggyback the required function on its install process.
Mike. i'm not a creator of a LP, but as far as I know, LP's creators uses
Mozilla Translator in order to create the LP. Mozilla Translator doesn't require
a bit of XUL/JS knowledge.

i see no point in developing a language pack for firefox as long as there is no
official extention that can easily be added to the pack, that will add language
switching UI. as Asaf wrote, a translator can create a langpack XPI with no clue
in XUL or JS.
What about including disabled-extension with the offical release of Firefox.

I can nearly promise it wont be less usable than the DOM inspector...
What about including disabled-extension with the offical release of Firefox?

I can nearly promise it won't be less usable than the DOM inspector...
so if everyone's using Mozilla translator to create the XPIs, then we need to 
have that process include the extension content as part of the package.  This 
is a matter of doing things the right way, not the quickest way.  As an 
alternative, and less effective plan, we can make an XPI available via the MLP 
site that can be installed along with the language pack.

We are NOT going to bundle this with the main distributions under any 
circumstances.  This is bloat for 95% or more of users (most will use localized 
builds, not English builds with langpacks) and therefore is unnecessary.
(In reply to comment #28)
> so if everyone's using Mozilla translator to create the XPIs, then we need to 
> have that process include the extension content as part of the package.  This 
> is a matter of doing things the right way, not the quickest way.  As an 
> alternative, and less effective plan, we can make an XPI available via the MLP 
> site that can be installed along with the language pack.
> 

mozillatranslator is having some development problems now. it's creator
abandoned it for lack of time more than a year ago. a new leader was recently
found, but it is yet to be seen what will be the development rate.

> We are NOT going to bundle this with the main distributions under any 
> circumstances.  This is bloat for 95% or more of users (most will use localized 
> builds, not English builds with langpacks) and therefore is unnecessary.

i wonder, do you have a statistic about this, or are you just guessing? some
localizations don't produce a localized build, but only a language pack xpi. yet
others might want to use the english version until the l10n is released.
2 questions.

1. Does this locale switching extension exist?

2. Has anyone made an attempt to create an installable language XPI that also
installs a locale switching extension?

I think the idea that every language would also install a language switch
extension isn't that bad if we can make it easy to integrate the locale
switching extension into a langpack XPI.
Mike, as a translator I can tell you, that most of us don't know any programming
at all. It's not our Task anyway. We want to contribute to Mozilla.org's new
products, but Ben and you as the leaders of this projects don't make it easy for
us. We accepted that, because these products are in alpha or beta stage and the
l10n priorities are of course low, but we need some help from you in the future.
This extension for expamle is something we must demand from you. As you can see
from the comments, the tool we use at the moment isn't developed for 1.5 years
now. If you consider, that more than 100 localisation-teams rely on that tool
for building their languagepacks this is a shame and that's why I want to see
mozlla.org in charge for that extension. After all, more than 50
localisation-teams for Firefox and Thunderbird will and rely on that extension
and this teams want to concentrate on the translations not on software
development. Please consider that, when judging about l10n problems.
(In reply to comment #28)
> We are NOT going to bundle this with the main distributions under any 
> circumstances.  This is bloat for 95% or more of users (most will use localized 
> builds, not English builds with langpacks) and therefore is unnecessary.

What evidence do you have that most will use localised builds? Translators
prefer to work with XPIs, as proved with seamonkey. It is only when
Phoenix/Firebird/Firefox came out that they were "forced" to produce full distros.
mkaply: the extension I'd like to see doesn't exist yet, but I'm going to try to
bang something out sometime soon and post it to the localization newsgroups for
some testing.

http://www.mozilla.org/projects/l10n/mlp_packaging.html gives the instructions
for creating the langpack XPI, we'd just have to modify the base install.js to
also install the overlay jar and register the overlay appropriately, and provide
the jar (with the content only) for download.  There would be instructions for
creating the appropriate file(s) in the right place to be included in the ab-CD.jar.

Is any of this seeming too onerous to the localizers?  Its basically 1) download
an extra jar and b) put a file in the right spot and localize the strings, then
package pretty much the same.
actually, the firefox specific documentation and install.js file is at
http://www.mozilla.org/projects/l10n/mlp_howto_Firefox.html#XPI .
I think you are missing the point. I'm using an English browser. I install the
Japanese langpack.

Does it make firefox Japanese? How do I get back to English?

I can give you a REALLY good reason why you want language switching - bug
determination.

If there is no easy way to switch back to English, people can't determine if a
bug is related to the language pack or not.
(In reply to comment #33)
> mkaply: the extension I'd like to see doesn't exist yet, but I'm going to try to
> bang something out sometime soon and post it to the localization newsgroups for
> some testing.
> 
> http://www.mozilla.org/projects/l10n/mlp_packaging.html gives the instructions
> for creating the langpack XPI, we'd just have to modify the base install.js to
> also install the overlay jar and register the overlay appropriately, and provide
> the jar (with the content only) for download.  There would be instructions for
> creating the appropriate file(s) in the right place to be included in the
ab-CD.jar.
> 

i don't think this should go into the ab-CD.jar, but rather have it's own jar,
that will include it's own xul and dtd files, like other extentions. this will
reduce duplicates and conflicts between different language packs. already not
all packs use the same install script, and i assume you can expect to see some
variations of the extension too.
mkaply: who's missing the point?  The idea is to create something whereby the 
XPI installs an overlay which gives this UI (i.e. Tools->Switch Locale), or am 
I missing something here?  This must be a separate jar so that its availble to 
multiple locales, including English.  Localizing this is the tricky part, and 
there isn't really a great solution for that.

Tsahi: The jar with the overlay can't contain the .dtd files, since you might 
have four language packs installed, and each install would overwrite that jar, 
thereby horking the previous langpack's locale for said extension.
Why don't we at least make the localization for the locale switcher part of the
default Firebird set of DTD files so it always gets translated? And the add on
part will be the functionality.

This will solve the chicken/egg problem.
It should be an options panel, I'd believe.
And including the .dtd in the jar wouldn't be the problem, as we're able to
translate inspector, chatzilla, etc. and they have this as well.
It's a suboptimal solution if we have to install a seperate XPI but counting the
usual Firefox developer ignorance, even that there's talk about a solution makes
me think Firefox is not _completely_ doomed for people who actually want to see
solutions to their problems.
Easy locale switching is one of the big pros of a XUL environment, I believe.
Making that hard to access isn't the best way to highlight it. But well, life is
hard. If someone will provide an extension that makes *something* work there,
it's clearly better than what we have now.
/me wonders why this is still marked WONTFIX, when we're atually discussing of
how we can achieve a fix to the problem ;-)
bug 243113 filed as the followup for the work that will be done under the
auspices of the MLP.  This also is needed for Thunderbird langpacks as well, I'm
hoping the solution is easily shared (it should be).

Please carry on discussions there.
QA Contact: bugzilla → general
*** Bug 354067 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.