This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
If you actually point AU to an update server with dozens of localized NBMs from various locales, it will show them all to you. Of course this is useless to you - you are only interested in plain-locale NBMs and NBMs which are localized to the locale you are running in. E.g. as an English-language user, I should see no localized NBMs on the netbeans.org alpha update server (when it is fixed: issue #32774). If I were running with -locale ru, I should see all the Russian NBMs, but none of the Japanese, French, Chinese Traditional, or Chinese Taiwanese NBMs. Etc. Marking P2 because there are *a lot* of these localized NBMs, and to an average user they will be quite overwhelming. For example, you see modules: Javadoc (fr) Javadoc Javadoc The first is French, the second Japanese, the third Russian. To avoid these you need to laboriously go through every line in the list of available updates and check the long description. There are many screenfuls of this. Fortunately the localized NBMs have a different icon, which will be somewhat helpful to an (observant) English-language user, though not at all to e.g. a Russian user who does want to see the Russian NBMs.
Ideally, the AU wizard would actually display localized NBMs specially (or not at all), and just automatically retrieve the localized version of an NBM if one was available. E.g. if the update center contains: java.nbm - "Java Sources" java_cs.nbm - "Javaske soubory" java_ru.nbm - "Java### #######" (some Cyrillic here!) and you are running in Czech locale, you should see just: + "Javaske soubory" |- Hlavni modul: 1.5 |- Prelozeny modul: 1.5 so you do not need to individually select java.nbm and java_cs.nbm. However this is longer-term; the immediate problem is the display of localized NBMs which cannot be of any use to the user downloading the list.
Hmm, I don't think this is a P2 defect. It is rather an enhancement. And even the enhancement is strange. I can imagine that someone running in NetBeans in one locale may want to sonload localization for other locales and then switch the locale. This would be impossible when we only show the loc modules for current locale. Maybe if the localizations contain large number of modules we should create specialized server for each of them. Or make at least folders for them on the server. I'm sorry but I don't think that I should do such change to the code three days before codefreeze.
Petr, are you sure this is a hard-all-involvable-stop-the- world fix with many possible outcomes in all other modules all over NetBeans? If not, please do the immediate change Jesse suggested: show ONLY the nbms of the User's locale, please While you as developer may think of it in terms of ENCH, from the user's point of view it's a serious usability defect. For what reason on the Earth I (the Russian guy) is proposed with Japanese, Frech and two different Chinese l10ns?
Well, I can imagine the usecases for dowloading different i18n than current locale e.g. testing or maintaining root install of NetBeans in multilingual environement. Anyway what do you have against folders on the server e.g: French I18N module 1 . . module n Czech I18N module 1 . . module m I think it's reasonable workaround. You would be able to select all the I18N modules for your locale on one click. This really isn't P1/P2 defect I'm sorry there is no data loss no deadlock ...
Adding Robert Novak on CC. He agreed to implement the tree hierarchy of languages on the NB server. I hope this will help users to select the l10n modules easier. I agree that having them all in folder is bad as one has to pick all of them from possibly pretty confusing list. Dividing into proper language categories should help as selecting whole folder will download all l10n modules available for given language. Hope this helps.
OK, I agree for such _immediate_ fix
Putting localized NBMs into language-specific subfolders sounds reasonable for now. I still think longer-term the update wizard's UI should do better. To Petr's scenario of a root install wishing to maintain multiple languages - perhaps, but this is a relatively rare case, and could be easily handled with a checkbox on the first wizard panel "Show All Locales" or whatever, unchecked by default.
I can only comment in general that its imporatant to l10n centers, and now we have both ja and zh localized nb and s1s releases, that the update sitauation as to how user is shown and gets localized autoupdate modules is viewed as important. So this RFE is one that is high on their list of i18n issues they feel important to implement/fix. Also, maybe not related to this, not sure, is making sure process that l10n center follows to receive and deliver localized info.xml is more automated. ken.frank@sun.com
reassigne to Jirka - new owner of autoupdate
*** Issue 50498 has been marked as a duplicate of this issue. ***
Planned to promoF.
Is this issue still applicble ? Latest decision as discussed by Jiri Kovalsky and Robert Novak, is that if user is running localized version of nb, they are directed to locale specific update center for that locale at that update center - if there are localized versions of some given module, those are offered if there are not, or not yet, localized versions of those modules, the english ones are offered But if user is not running a localized version of netbeans, they are sent to the english update center, where there will not be localized versions of modules offered, since the determination of which update center to use is defined in a property file of a localized jar. Would there however be cases where a user would have downloaded/installed english release but later wanted localized update center modules ? If so, then it seems that locale detection by ide would be needed so user was sent to a localized update center if it existed for that locale ? Otherwise, the current way as described above seems like it would be sufficient. ken.frank@sun.com
Localized NBM are not distributed by AU for long time. IMHO it should closed as wontfix.