Bug 33096 - I18N - AU shows NBMs from inappropriate locales
I18N - AU shows NBMs from inappropriate locales
Status: RESOLVED WONTFIX
Product: platform
Classification: Unclassified
Component: Plugin Manager
3.x
All All
: P2 with 1 vote (vote)
: TBD
Assigned To: Jiri Rechtacek
issues@platform
oslo, NbFeature1037
: I18N
: 50498 (view as bug list)
Depends on:
Blocks: 22948 33098 89627
  Show dependency treegraph
 
Reported: 2003-04-21 16:03 UTC by Jesse Glick
Modified: 2008-10-16 16:32 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-04-21 16:03:23 UTC
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.
Comment 1 Jesse Glick 2003-04-21 17:04:28 UTC
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.
Comment 2 Petr Hrebejk 2003-04-22 09:47:52 UTC
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. 
Comment 3 _ mihmax 2003-04-22 10:08:57 UTC
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?
Comment 4 Petr Hrebejk 2003-04-22 11:56:56 UTC
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 ...  

Comment 5 Petr Hrebejk 2003-04-22 15:02:27 UTC
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.

Comment 6 _ mihmax 2003-04-22 15:41:41 UTC
OK, I agree for such _immediate_ fix
Comment 7 Jesse Glick 2003-04-22 18:26:30 UTC
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.
Comment 8 Ken Frank 2003-07-17 20:28:32 UTC
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
Comment 9 Marian Mirilovic 2003-12-01 10:48:38 UTC
reassigne to Jirka - new owner of autoupdate
Comment 10 Jiri Rechtacek 2004-10-18 15:02:11 UTC
*** Issue 50498 has been marked as a duplicate of this issue. ***
Comment 11 Jiri Rechtacek 2005-02-09 13:10:00 UTC
Planned to promoF.
Comment 12 Ken Frank 2007-01-15 16:35:08 UTC
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
Comment 13 Jiri Rechtacek 2008-10-16 16:32:43 UTC
Localized NBM are not distributed by AU for long time. IMHO it should closed as wontfix.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo