Closed Bug 285848 Opened 17 years ago Closed 12 years ago
Allow the use of locale packs for extensions (automatic find and install, manual install)
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
Please describe in detail what feature you request.
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 ;-) )
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?
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) ?
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
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... :-)
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.
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.
Whiteboard: summary in comment 8; detailed suggestions in comments 4,6
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 ?
A related bug I opened a while back: bug 280385
See this (http://kb.mozillazine.org/Manage_extension_updates_by_locale) for a partial workaround.
*** Bug 285847 has been marked as a duplicate of this bug. ***
Beltzner's going to write a UI spec for this. Want this for ffox 2 to fix problems with DOMI shipping all locales inline.
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.
I'll add my comments to the wiki.
Spec is up (mostly) -> robstrong for implementation. Rob, let me know how/whether I can help.
Assignee: beltzner → robert.bugzilla
Adding some calendar folks, as this will affect the localization stuff that is shared by Sunbird and Lightning.
QA Contact: bugs → extension.manager
Status: NEW → ASSIGNED
Flags: blocking-firefox2? → blocking-firefox2+
Target Milestone: Firefox 2 → Firefox 2 alpha2
Whiteboard: summary in comment 8; detailed suggestions in comments 4,6 → 7d
Doesn't look like this is going to happen for 2.0 though patches would be very welcome.
Assignee: robert.bugzilla → nobody
Status: ASSIGNED → NEW
Target Milestone: Firefox 2 alpha2 → ---
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.
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
No longer blocks: 460640
Summary: Extension manager should be able to manage the language of the extensions → Extension manager should support language packs for extensions
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.
(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.
Probably, responses to my comments now will be better addressed outside this bug and taken to another forum. Please email me at email@example.com. 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.)
(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)
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)
Summary: Extension manager should support language packs for extensions → Extension manager should support language update for extensions when not the same than FF locale
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...
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Summary: Extension manager should support language update for extensions when not the same than FF locale → Allow the use of locale packs for extensions (automatic find and install, manual install)
As the author of the specification, I support comment 30
You need to log in before you can comment on or make changes to this bug.