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:
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
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
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:
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
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
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.
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,
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.
Localized NBM are not distributed by AU for long time. IMHO it should closed as wontfix.