285848 - Allow the use of locale packs for extensions (automatic find and install, manual install)

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Nicolas Mandil (:NicolasWeb)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.6) Gecko/20050226 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.6) Gecko/20050226 Firefox/1.0.1

Something like this :  "check for extension in my language", next "Do you want
to use [language] for those extensions ?  [list] "

Reproducible: Always

Comment 1

[Nickolay_Ponomarev]

Please describe in detail what feature you request.

Comment 2

[Nicolas Mandil (:NicolasWeb)]

Many times extensions are in English, or are easy to find in English.
The Extension manager should show the language used by each extension. A button
should be added to update extensions language (laguage switch) :
1) for the selected extension only
2) for all extensions (as the update softwear done).
I dont really know how to do an IU for it, but the idea is :
a) user (in Extension manager, maybe ??) or FF check for updates (special button
for laguage update ?? or with all updates)
b) All localized extensions are listed, the user select those that he/she wants
to be localized

The actual language should be determinated by the FF language (localisation ; UI
Language not Prefered language form web page ??). So the extension manager Check
for new language support, and present a list of localized extensions. After user
agrement it update extensions.
It's my idea of language update, but there is maybe a better way to do it :
Propose your solutions

Do you have enough with these details ? am I clear ? (English is hard for me ;-) )

Comment 3

[Nickolay_Ponomarev]

Why would you need to select languages for separate extensions? (Other than for
testing or because of bug 279952)

Or do you mean you want to deal with the situation when an extension does not
include the locale you need and you wish to install that locale separately?

Comment 4

[Nicolas Mandil (:NicolasWeb)]

I don't need to select languages for separate extensions, I just wish to tend
towards an UI in one language, for the comfort of the users.
I want to deal with the situation when an extension does not
include the locale I need and I wish to install that locale separately or
reinstall (by keeping settings ...) it automaticaly.

My wish is
1) I download & install an extension from update.mozilla.org (or other) so the
language is en-US or en-EN (not mine)
2) By the extension manager I can check if this extension has been translated in
my language
3) be able to change the extension language by mine

This because many times it's hard to found localised extensions so automiticate
this is important. This because
A) The extension is not localized yet, so the User will be warn when (if) this
happen.
B) The user have found the extension in an other language, and FF inform him
that he/she can use the same extension version in his own language.
C) The extension has been updated (security or power) and the user want it localized

Goals :
a) Update the extension laguage when an localization exist
b) The language update process should be done :
b.1) manually by using the extension manager
b.2) during the softwear update process (as for themes and security updates)

Maybe we have to define if when an update is realease in an other language we
should propose to the user to switch temporaly the language or to wait (if this
come) for the same update but localized.

Is that clear, because my english is very bad (so sorry) ?

Comment 5

[Nickolay_Ponomarev]

I now see your point. Thanks for clarifications.

See my comments in bug 285850 (the part I called irrelvant to that bug :) ). I
think that issue (putting separate locale packages for extensions) is closely
related to this bug. Actually since it's unlikely that Firefox ever
downloads/installs anything automatically from anything but update.mozilla.org,
I think that issue is a blocker for this. Tell me if you agree and I will file a
separate (UMO) bug on that.
That will (theoretically) take care of installing extensions. That is, if the
preferred locale for extension is available in at the moment of installation,
the locale will be installed automatically (initiated by UMO).

The issues that are left are about dealing with upgrades, like upgrade to a new
version of extension, and installing a missing language package when/if it is
available. I would put both of them to the updater, that is I don't see the
point of your b.1 ("language update process should manually by using the
extension manager").

Confirming.

Comment 6

[Nicolas Mandil (:NicolasWeb)]

1) I think we must propose the goal of the enhancement first, & an issue in
second. Because I hope other people to discuss this enhancement, and it's maybe
not the best way for doing what we want FF to do. Other people can agree the
idea but not the issue.

2) - My reasoning and its evolution for the issue - 
** Here I speek about a file (update.rdf) : see
"http://www.geckozone.org/articles/2005/03/05/74-ajouter-la-mise-a-jour-a-vos-extensions"
for know what file I'm talking about
[line:"<em:updateURL>http://serveur/chemin/update.rdf</em:updateURL>"]

2.1) I think using separate xpi for locale is not the best way for users :
having two files for only one extension... That's not easy (think about the same
thing in TB [download and after intall by opening xpi files]... not really good
!). Maybe the setup xpi file should have/can check a list of avaible languages
provided by the seconds xpi and links to these xpi. During the installation
process, FF should check for the avaibles languages & user language and next
download & install the second xpi if needed. I think that's a way to don't left
upgrade process, please see 2.2). But I think that some developpers will not add
this list, because it should be hard to keep it up to date (localization is many
times done by other people). Maybe it is necessary to make this list obligatory,
as for version min max in update.rdf. However, for an update by the updater, it
would be better to not integrate this file in the first/main xpi for it
independent update. It would be preferable to have a separated rdf file or to
integrate it in the update.rdf file (this last which can give a link towards the
separated rdf file why not, something like a locales.rdf... but I don't think
that's the best way). I think that the update.rdf file of the extension should
have lines
(<em:updatelocalizationURL><language1></language1><language2></language2> ...
</em:updatelocalizationURL>) that tell to FF the supported locales a) integrated
in the main (1st) xpi, like in IEview, or b) in a separate locale xpi file, and
the way to find them (link). So the update.rdf file should be checked during the
installation process.

2.2) For the upgrade process we always have to define what is the most imporant
for the user : the upgraded extension or the localized extension. I think that
as for FF the user can wait 1-2 weeks for a localized extension, but how to
manage the extension if the localisation of the upgraded extension is never
released ?? Maybe we need the user agrement for this, and ask him again 1-2 week
after if the localization isn't released.

3) FF download automatically its updates and themes&extensions updates, so I
don't know why it can't do this for its locales extensions updates ?? I wish it
uses the same process as the one used for themes&extensions updates.

4) 
4.1)I think that your left issues are THE MOST IMPORTANT ! so I don't agree with
you. FF should be able to change the extension language after the setup of the
extension.
4.2) However update.mozilla.org should have a blocker (I haven't found the
french translation for this word, but I think that's the same thing than a
filter).That's the goal of bug 285850. Althought, I agree to put the upgrade to
a new version of extension, and installing a missing language package when/if it
is available to the updater and not to the extension manager.
in comment #4 : b.1) manually means by the user in the extensions manager. But
now I think that a checkbox "extensions language" in option/advanced settings
should be better for users that want to check extensions language by they own.

5) what's an UMO bug ?? how to report one ??

6) I saw a list of enhancement in the wiki, maybe we have to post this on there ?

As usual tell me what you don't understant... :-)

Comment 7

[Nickolay_Ponomarev]

Generally I agree with you.

The point of comment 5 was exactly that we need support for "locale updates" --
in Firefox, update.rdf dictionary and UMO (UMO is short for update.mozilla.org,
"Update" product in bugzilla).

The other point was that instead of performing extension's installation in two
steps as you suggest in [2.1] (first installing unlocalized version, then
looking for "locale updates"), the site initiating installation (UMO) could
serve both XPIs through a single call to XPInstall. *This is meant to be an
optimization only, for Firefox*.

I suggest to hold the discussion at wiki.mozilla.org - bugzilla is not really
suited for it.

Comment 8

[Nickolay_Ponomarev]

Summarizing: Current support for locales not included with extensions is
suboptimal. This bug asks for improvements in this area.

Two common situations now are:
1) an extension's XPI includes *a lot* of locales (a headache for extension
author, and users are forced to download locales they don't need).
2) an official XPI doesn't include locale X, in which case an unofficial version
of extension with included locale X is distributed on localizer's site. If user
doesn't know about localizer's site, he can't find the localized version.

Comment 9

[Nicolas Mandil (:NicolasWeb)]

I agree with you, the site initiating installation could serve both XPIs through
a single. However mozilla-people can do it for UMO, but this issue do not solve
the problem of others extensions sites, some extensions are not provided by UMO.

I don't think that's a Firefox only optimization. For me an optimization for FF
can be used by other mozilla products. That's why I think we must think about an
issue compatible with Thunderbird.

I've used the wiki only for read information, I don't know how it works for
editing. If you want to move there, please explain me how to do or start first &
give me a link. I don't know were I've to write about this enhancement...

When we will have explain all, what will be the next step for this to be done ?

Comment 10

[Alex Sirota (iosart)]

A related bug I opened a while back: bug 280385

Comment 11

[Thomas Bertels]

See this (http://kb.mozillazine.org/Manage_extension_updates_by_locale) for a
partial workaround.

Comment 12

[Robert Strong (they/them - no direct email)]

*** Bug 285847 has been marked as a duplicate of this bug. ***

Comment 13

[Benjamin Smedberg]

Beltzner's going to write a UI spec for this. Want this for ffox 2 to fix problems with DOMI shipping all locales inline.

Comment 14

[Benjamin Smedberg]

beltzner: ping

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

When I was onsite I spoke at length with Rob Strong about this and have updated the wiki to capture our thoughts. We should be able to do this with a minimum amount of UI change.

Comment 16

[Axel Hecht [:Pike]]

I'll add my comments to the wiki.

Comment 17

[Benjamin Smedberg]

Spec is up (mostly) -> robstrong for implementation. Rob, let me know how/whether I can help.

Comment 18

[Dan Mosedale (:dmosedale, :dmose)]

Adding some calendar folks, as this will affect the localization stuff that is shared by Sunbird and Lightning.

Comment 19

[Robert Strong (they/them - no direct email)]

Doesn't look like this is going to happen for 2.0 though patches would be very welcome.

Comment 20

[Jez]

Might it be a good idea also to allow newlines and tabs in descriptions whilst fixing this bug, or would that be better as a new bug entry?  I noticed that these aren't allowed recently, and they'd be pretty useful in laying out the description better.

Comment 21

[Robert Strong (they/them - no direct email)]

Please refrain from making comments in bugs that have nothing to do with the bug as well as making the same comment in multiple bugs.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 24

[macias]

Because of the summary my 1/2 vote for, 1/2 vote against.

I think language switch is such basic operation that using extension manager to do it, will be overkill. It should be option (combobox) in preferences. See Opera for example, changing language is intuitive and simple. After all it is one of the parameter of the program.

Comment 25

[Jo Hermans]

(this was origanally ment for bug 559516)

Switching on-the-fly is a nice trick for technical users ("Look how many languages are built-in !"), but it's not the only solution, and it also bring its own problems (see below). Since most people will never change the language (I speak 5 languages, but even I would never do that), it's often easier for non-computer savvy users to provide pre-built executables with a single language.

If you give Firefox with such a language switch to a person that doesn't understand English, he/she won't always be able to find out how to change the language (not everyone can find back the Options). You have to ask before you use the application.

Bug 285848 is about making it easier to install and maintain those langpacks. I can imagine that it would be also make it much easier to deliver a en_US version, that would ask the user which language to use first (maybe download on-the-fly). But that requires that the basic version would be usable for the users, so that they can configure the basic configuration (proxyserver, helptexts, etc ...) even if they don't understand English. Try doing that in Opera : it's not so easy than you think. Many users would prefer a version that works out-of-the-box, without such a language-question. 

Besides, the size difference is not in the texts at all - it's in the spelling dictionaries that are built-in in the localizations. Also note that the default bookmarks, search engines, etc ... are also different between localizations (and I think even some default certificates, but I'm not sure).

Note that until recently, it was not possible to deliver all languages together in a single executable, because the localizations were often ready much later than the en_US release. It would have been very difficult to release a new version, if you have to wait on 70+ localizations. It's much easier now though, since most (but still not all) are now built together with the en_US version. Firefox 3.6 *still* has 9 languages that are not released yet, plus some that aren't even in alpha yet.

I think that easy management of langpacks is indeed important, but that doesn't mean that the separate localizations would disappear. Maybe an true international version with a few dozen langpacks might be built, but it would be much larger.

Comment 26

[Seth Bindernagel]

Probably, responses to my comments now will be better addressed outside this bug and taken to another forum.  Please email me at [e-mail].  Or, consider posting your response to the dev.l10n newsgroup for others to discuss.

(In reply to comment #25)
> Note that until recently, it was not possible to deliver all languages together
> in a single executable, because the localizations were often ready much later
> than the en_US release. 

Is that true?  We've always shipped all the localizations with en-US on the same main release day.  I am racking my brains trying to remember when we didn't do this.  And, I am trying to remember when l10n ever blocked an en-US release so all languages could meet that release deadline.  Perhaps this happened before the Firefox 1.0 days, which is as early as I started following or researching l10n stuff.

http://blog.mozilla.com/seth/2009/07/13/a-look-at-firefoxs-localization-growth-overtime/

> It would have been very difficult to release a new
> version, if you have to wait on 70+ localizations. It's much easier now though,
> since most (but still not all) are now built together with the en_US version.
> Firefox 3.6 *still* has 9 languages that are not released yet, plus some that
> aren't even in alpha yet.

You must be referring to the 9 in beta.  Those are not "official", but they are shipped on release day like all the others.  We just want users to know that we are still testing to make sure any potential translation errors are exposed and fixed.  But, they ship like everyone else and are included in the 70+ number.

We had 73 for Fx 3.6, including the 9 beta languages. (That does not include ja-JP-mac, which is not really a new language, but gets shipped like a localization. If you include, then the number is 74.)

Comment 27

[Nicolas Mandil (:NicolasWeb)]

(In reply to comment #24)
(In reply to comment #25)
I think you miss something important.
The initial aim of this bug is when an extension does not include the locale that is used by FF and to provide a way for users that have installed/are installing an add-on without they locale to
- 'redirect' them to the same extension with the right locale
- cancel the install process because they are warn there is not they locale
- upgrade them to they locale later when provided (and to be notified of it)
So, the extension manager should check for new language support, and show a list of extensions with new locale if the user's one is in. And a checkbox "ckeck updates of extensions languages" should be add to the FF pref dialog.
This because many times extensions are in English only/first.

So the aim is not to choose/switch language add-on by add-on, but to keep FF with only one language in the IU, for consistency.
Check again comment 4 (and understand b.1 as "when you click 'check for updates' it chek for languages of add-ons too")

So, this is not for technical users ;-) 

With this, you can install an extension without your locale because you need-it and then be warn and updated to your locale.

After, technically, do it as you (we ;-) want, with XPinstall and 2 XPI in 1 or a true international version... but the aim is not to have a 2 steps setup if your locale already exist or an international version without your locale (unlucky boy ;-) (Think about the cases of update/upgrade of add-ons and upgrade of FF more than a new add-on install)

Comment 28

[Nicolas Mandil (:NicolasWeb)]

Language pack is a solution, but not the goal of this bug ;-)
But the new title say nothing about a setup of a new add-on (warn before if the locale is not included, 'redirect' him/her if the user choose a wrong locale, download only the needed locale)

Comment 29

[Robert Kaiser]

Ugh, I don't understand why bug 429652 and bug 559516 are both duped, here, both seem to be about different things from what I see.

So, why does this bug (judging from the summary) seem to be tied to Firefox now and not general toolkit? Why only tied to other locales than the main application one? And where is the "reasonably support _any_ language packs for _any_ extensions independent of how langpacks for the main application are organized" bug now?

We can't even reasonably manage a German langpack for ChatZilla in a German Firefox or SeaMonkey build right now in the extension manager (let alone AMO, which has its own bug for that), and that's what I was looking for when I CCed myself here a long time ago...

Comment 30

[Dave Townsend [:mossop]]

This bug report seems to have changed so many times that it is probably worthless to keep open. Based on comment 2 (and the linked proposal) though it appears that the original intention was to have the extension manager search for locale packs for extensions and to allow users to manually install locale packs that would provide a locale matching the application locale for extensions.

This is not something we're going to support in the extension manager in the conceivable future so I'm closing this as WONTFIX. There are better solutions on the horizon with the new L20N work that Gandalf is working on. It is already possible to install a language pack for an extension into the application, it just won't look any different to a language pack for the application.

For anyone that was interested in a different issue please file a different bug.

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

As the author of the specification, I support comment 30