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.
According to netbeans i18n page and other information, localized gif files from a module should come from the module's localized jar file. For example, for ja locale or in ja windows, aa.gif would become aa_ja.gif and, if it had been in bb.jar, would go into modules/locale/bb_ja.jar, just as for messages and html files in that localized jar. Since some images will be localized for the Japanese release, it is important that this be fixed; before, images had not been localized as far as I know. Details: 1. I swapped 2 gif files, using just 2 jar files as an example. I did this in autoupdate.jar, the add and ok gifs, and in openide.jar, with the cut and copy gifs. (I could find no other cut or copy gifs in the release) So the image for cut.gif is now in copy_ja.gif and visa versa. And both these are added to lib/locale/openide_ja.jar at org/openide/resources/actions/cut_ja.gif org/openide/resources/actions/copy_ja.gif 2. But when I run in ja locale, as usual, the cut and copy images are at the same locations on the gui and with the same images as they were before. 3. I've unzipped the jar file and made sure the switched images are correct. 4. These are just examples; I think that the image finding is a general operation and is not per jar file thus am filing it in core. 5. I'll attach screenshot of the cut/copy toolbar and options area. ken.frank@sun.com 04/06/2002
Created attachment 5317 [details] see the cut and copy buttons - they are not switched
Ken, you misunderstand how i18n works in java. The convention of putting locale specific string into xxx_<locale>.properties works only for resource bundles not for general resources like image files. The IDE is not designed and written to handle the situation you described above (ie localizing the cut.gif icon by just creating a new image and naming it cut_ja.gif). We simply don't expect that icons would need to be localized. I am not saying that images are not localizable. The splash image is localized into Japanese but there is some code which was written to specifically handle it. To reiterate, icons are not i18n-ed by default. We can implement the feature but it will have impact on performance and I am not sure if it's practically useful. IMO we'd better to draw the icons in a way that they are locale-neutral. With the justification above I am turning this issue into a RFE.
Can I suggest that the netbeans i18n page be corrected or clarifed in this regard then ? http://www.netbeans.org/devhome/docs/i18n/#2.5 where it talks about images with names of xx_ja.gif and being placed in the locale specific files. ken.frank@sun.com 04/06/2002
The I18N page is fine in this respect - it says how to name localized images and gives one way to ensure that code can access them. Some code does locale-sensitive lookup of images, some does not. IMHO localizers have a right to decide when it is necessary and when not, and to file P2 DEFECTs when code does not do a localized lookup where one is needed. Remember that branding uses the same lookup mechanism as localization, so any icon which is localizable is automatically brandable too. This is a good thing. Trung, I am not aware of any significant performance penalty here, you will have to back that up with numbers.... Note that nbresloc: is commonly used for image loading from layers, so these are already locale-sensitive. Utilities.loadImage(...) does not do a locale-sensitive lookup. Actually I dislike this method because it accepts a String parameter and it ought to accept a URL optionally, so that you could pass nbresloc: etc. to it. For SystemAction's it is tricky to make the icon locale-sensitive; you need to append the locale suffix in certain locales, but you cannot have this be autodetermined, as far as I know, due to the design of SystemAction.iconResource/getIcon. The only way I know of is to call setProperty(PROP_ICON, (Icon)myIcon) in initialize(), which is annoying since it means loading the icon eagerly. Making SystemAction automatically localize its icon would be nice but would require the aforementioned enhancement to Utilities.loadImage. Ken, please file issues for each specific code location that needs a locale-sensitive image lookup, and please remember to use the I18N keyword consistently so we can search for these issues. A screenshot is always helpful to make sure it is clear where the icon is that you want to localize.
Please leave the I18N as part of synopsis - it is the way we track i18n issues here. I will certainly add i18n keyword if that is needed for your tracking, put please leave this as part of synopsis.
I am confused by some of the comments and am wondering if they can be clarified: An earlier comment said that the IDE is not designed to handle localization of all images in a general manner, using localized images placed in localized jar files. A later comment says that some code does locale sensitive lookup of images. Can you clarify for me which is accurate? Also, in the comment that said that some code does locale sensitive lookup, it suggested that bugs be filed for each image that needs it if that image is not found by locale sensitive lookup. I think it could be more efficient if you can tell us what modules have this feature and which don't, and is this implemented by module or by a specific gif image in a given module. I think this would save time vs needing to localize each gif that localization center might want to localize and then need to view it in FFJ just to see if it is one of those that can be found from the locale. Then bugs could be filed as was suggested in the comment. ken.frank 04.07.2002
NetBeans has the infrastructure - API calls as well as conventions - for localizing/branding images. Some code uses this infrastructure and so images loaded by it are ready to be localized by just adding the proper locale variants. Some code is not prepared in this way and must be fixed by a developer before the image can be localized. Giving you a list of which code already loads localized images is entirely impractical. It is not at module granularity, it is simply a matter of whether that particular developer that day thought to ensure that the image load was localizable. I cannot think of any easy way to scan sources to list each scenario, since there are so many different styles of code to load images. So, please (1) for each localized image you want, create the proper localized image file (e.g. src/.../resources/foo_ja.gif as a variant of src/.../resources/foo.gif), (2) ensure that it gets placed correctly into a localized JAR such as modules/locale/somemodule_ja.jar, (3) check whether the variant in fact works (would suggest that you do this step once for many images in a batch to save time), (4) if it does not work then file a bug marked with I18N keyword in the appropriate module asking for the image load to use a localized mechanism. I would recommend checking in locale variants to CVS as soon as you have them since this would make it easier for developers to confirm that their code changes actually took effect. Common idioms for loading an image with a locale- and branding-sensitive search include: - NbBundle.getLocalizedFile, producing a URL - directly creating a URL using "nbresloc:" URL protocol Unfortunately at the moment neither of these will interact properly with Utilities.loadImage which is the recommended way to load images using an intelligent caching scheme. So localizable/brandable images should just be loaded uncached or using the simple cache available from java.awt.Toolkit.
Target milestone was changed from '3.4' to TBD.
The only remaining thing of interest in this report is that Utilities.lI should support localization, perhaps as an optional 2nd boolean arg, so you can do a localized lookup and still benefit from the cache. Don't forget that SystemAction.getIcon should call U.lI in localized mode. Ken, for any *specific cases* of unlocalized images, please file specific bugs marked with the I18N keyword.
extracted from this report: Giving you a list of which code already loads localized images is entirely impractical. It is not at module granularity, it is simply a matter of whether that particular developer that day thought to ensure that the image load was localizable. I cannot think of any easy way to scan sources to list each scenario, since there are so many different styles of code to load images. So, please (1) for each localized image you want, create the proper localized image file (e.g. src/.../resources/foo_ja.gif as a variant of src/.../resources/foo.gif), (2) ensure that it gets placed correctly into a localized JAR such as modules/locale/somemodule_ja.jar, (3) check whether the variant in fact works (would suggest that you do this step once for many images in a batch to save time), (4) if it does not work then file a bug marked with I18N keyword in the appropriate module asking for the image load to use a localized mechanism. ------ Likewise, it is not really practical to localize many images to see if they come from locale, it seems that it would be similar to asking to localize every message and see if it comes from locale (assuming the messaging system was same as what appears to be in this situation - that if localized image comes from locale may or may not happen depending on code in each module.) I think this rfe was for having a generalized mechanism to have images come from the locale, just as bundle mechanism allows messages to come from locale. ken.frank@sun.com
"I think this rfe was for having a generalized mechanism to have images come from the locale, just as bundle mechanism allows messages to come from locale." - no, such a mechanism already exists. The only problem is that the caching system used in Utilities.loadImage, which is a little more efficient than the JDK's built-in mechanism, does not do automatic localization. loadImage is also used in actions (menu items, ....). So the image localization is not as convenient as it should be. "it is not really practical to localize many images to see if they come from locale" - no, of course not. On the other hand, unlike text messages, only a handful of images will actually need to be localized.
Changing to defect after consulation with nb QA and comments from nb strategy that some i18n rfes could actually be viewed as defects. Let me know if more details are needed. ken.frank@sun.com
Still not clear on how this became a DEFECT. Whatever, it is probably for me to implement.
Background commit: committed * Up-To-Date 1.18 openide/src/org/openide/util/IconManager.java committed * Up-To-Date 1.5 openide/test/unit/src/org/openide/util/actions/ActionsInfraHid.java Main commit: committed * Up-To-Date 1.89 openide/openide-spec-vers.properties committed * Up-To-Date 1.120 openide/api/doc/changes/apichanges.xml committed * Up-To-Date 1.110 openide/src/org/openide/util/Utilities.java committed * Up-To-Date 1.65 openide/src/org/openide/util/actions/SystemAction.java Added new Utilities.loadImage(String resource, boolean localized). I did not notice any measurable performance degradation in startup as a result of SystemAction looking for localized icons in toolbar buttons. There was a very small slowdown, but it was much smaller than the random variance between runs. (BTW someone who knows statistics better than me should fix apisupport/release/bin/unsupported/time-delta.pl to do a proper "statistical significance" test, e.g. "faster, p < 0.001".) nbresloc: protocol still does not use the cache manager. I don't think this is easily fixable anyway, since the URL protocol handler cannot know for sure how it is being used (can be used for non-images), and new ImageIcon(new URL("nbresloc:...")) gives the URL handler no chance to intervene. Code which looks like this: URL u = ...; Icon i = new ImageIcon(u); could be changed as follows: URL u = ...; Icon i; if (u.getProtocol().equals("nbresloc")) { i = new ImageIcon(Utilities.loadImage(u.getPath(), true)); } else { i = new ImageIcon(u); } or similar.
am verifying. Is there a sun alias that has all developers on it so we could communicate that this fix is available but they need to use it for localized gifs to come from locale ken.frank@sun.com