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.
Originaly submited in Bugtraq as #4684578. Looks like there is a general problem in core, as Libor Kramolis pointed out. See attached test module. Problem is that the name of the template is localized but the file itself not. Yarda, please can you evaluate this asap. Thanks. Original comments: Japan localize Layer_f4j_ja.xml file in utilities_f4j_ja.jar to modify some URLs in Help menu. But it looks current build (5/7 ML build) does not use the file. It worked in Pilsen, so I assume this is a regression in Orion. To reproduce the bug: 1. Start FFJ4.0 Multilingual build 2. Select Help->ReleaseNote/Manual Expected result is to display http://www.sun.co.jp/forte/ffj/documentation/, but current behavior is displaying http://forte.sun.com/forte/documentation/ We modified Layer_f4j_ja.xml file like follow (changed only CDATA field). --- <file name="documentation-link.url"> <![CDATA[http://www.sun.co.jp/forte/ffj/documentation/index.html]]> <attr name="SystemFileSystem.localizingBundle" stringvalue="org.netbeans.modules.url.Bundle"/> <attr name="SystemFileSystem.icon" urlvalue="nbresloc:/org/netbeans/modules/url/empty.gif"/> </file> ---
Created attachment 5774 [details] testing module wit bookmark and template - both localized
Passing to Petr.
This is a blocking issue for localized release, since they do change the urls in Layer_f4j.xml to those of Japanese web sites. ken.frank@sun.com
I`m investigating this problem (may be problem in XMLFileSystem).
Really? I was guessing MultiFileSystem. But I guess XMLFileSystem does merging too. Come to think of it, the module cache might be at fault as well - it uses XMLFileSystem to do the actual merging, but locale switches can affect the cache validity.
AFAIK there is possible to avoid using cache -Dnetbeans.cache.layers=- and despite it the problem remains.
OK, so probably in fact in XMLFileSystem.
Definitely XMLFileSystem. It`s curious that nobody notice yet. Following patch should fix this problem: Index: XMLFileSystem.java =================================================================== RCS file: /cvs/openide/src/org/openide/filesystems/XMLFileSystem.java,v retrieving revision 1.58 diff -r1.58 XMLFileSystem.java 468,469c468,469 < retVal.urlContext.addAll(Arrays.asList(child.getUrlContext())); < retVal.content=null; --- > //retVal.urlContext.addAll(Arrays.asList(child.getUrlContext())); > //retVal.content=null; 503,505c503,507 < byte[] alloc = new byte[content.length]; < System.arraycopy(content, 0, alloc, 0, content.length); < this.content = alloc; --- > if (this.content == null) { > byte[] alloc = new byte[content.length]; > System.arraycopy(content, 0, alloc, 0, content.length); > this.content = alloc; > }
Just to clarify, does the fix mentioned fix the specific problem described in the bug -- and that, if fixed, localization can go back to only changing the CDATA lines with urls in the Layer_f4j.xml file (and put their in a Layer_f4j_ja.xml in a utilties_f4j_ja.jar) ? Jesse has given me a workaround which appears to work and which will be evaluated by localization center, but requires more hand editing of the Layer_f4j.xml file, so if this fix does fix the bug description problem and that fix could be in any next RC build, that would be good. ken.frank@sun.com 05/16/2002
Does this issue affect any other xml or other files that are localized ? (or not) There are a few other xml files, like in vcs and masterHelpSet and others, that are localized and we'd like to see if a workaround or fix is needed for those also. ken.frank@sun.com
Fixed in trunk - upper layers should mask lower layers. Content of shared file from upper layer should be returned from FileObject`s inputStream. Jesse`s workaround is acceptable, isn`t it ?
Jesse's workaround is acceptable and will be used for Orion. Does this fix mean that in future, we only need to localize CDATA lines again, or should we follow Jesse workaround also in future ? ken.frank@sun.com
Fixing category. BTW the two workarounds in question were: 1. In the Japanese layer, mask the English URL and add a new one. 2. In the English layer, replace the inline CDATA with url="nbresloc:/..." and localize just the external URL file, not the layer itself. #1 will be used for now, to avoid touching the English layer. #2 is nicer and ought to be used for the future - in fact is perhaps better than the current practice of localizing the inline CDATA content, even if this bug were fixed.
So perhaps rebroken by rollback; cf. issue #23609.
Mine to check up on, since fix may have been rolled back.
Unit test says it already works w/ Radek's patch.
I'd like to verify and close this - so just to be clear - is the fix for this to continue to do the workaround in the xml file as mentioned below -- or is there a fix that relates to all localizable actions being done in bundle file so loc center does not have to edit xml files ? ken.frank 09/03/02
Again, the following suggestion does not depend on this fix and is desirable even with it: "In the English layer, replace the inline CDATA with url="nbresloc:/..." and localize just the external URL file, not the layer itself."
Consistent use of the I18N keyword.
Japan verified and evaluated Layer_f4j_ja.xml file in utilities_f4j_ja.jar by using Sun ONE Stuido 4.2 (Nevada). Currently, *.url files specify the linking URL in Help menu and so on. We'd like to only make *_ja.url without editing Layer_f4j_ja.xml. that is to say, when Layer_f4j_ja.xml is described as follows, ---------------------- <file name="resources-home.url" url="nbresloc:/org/netbeans/modules/utilities/resources-home.url"> <attr name="SystemFileSystem.localizingBundle" stringvalue="org.netbeans.modules.url.Bundle"/> </file> ---------------------- and if system locale is Ja, then I hope IDE use automatically not resources-home_f4j.url but resources-home-ja_f4j_ja.url. As workaround, we edited the value of "file name" and "url" in Layer_f4j_ja.xml, and added message ID in Bundle_f4j_ja.properties. But I think this is not ideal i18n.
jf4jbug: I don't really follow what the last comment was all about but I am pretty sure it was something unrelated to this bug, which last I checked is still fixed. Please open a separate issue report describing in greater detail what you want to happen, what you tried to do, and what actually happened, and refer to this bug by # for reference. Probably should be filed in utilities module.
I'm sorry for my misunderstanding. I fond how to localize Layer_f4j_ja.xml correctly, and verified the file's i18n is worked. For l10n, I should edit only the value of url in Layer_f4j_ja.xml, like following: ------------------------------ <file name="resources-home.url" url="nbresloc:/org/netbeans/modules/utilities/resources-home-ja.url"> ~~~~~~~~~~~~~~~~~~~~~ (Specify ja-url file here) ------------------------------
Huh? nbresloc:/org/netbeans/modules/utilities/resources-home-ja.url makes no sense. You should only need nbresloc:/org/netbeans/modules/utilities/resources-home.url since that will automatically search for an entry org/netbeans/modules/utilities/resources-home.url in modules/locale/utilities_ja.jar (that is the whole point of the nbresloc URL protocol). Which probably means that there should be *no* reason to override <file name="resources-home.url" ...> in Layer_f4j_ja.xml, and perhaps there does not need to be a Layer_f4j_ja.xml at all - Layer_f4j.xml would suffice unless the Japanese variant actually adds, removes, or reorders some entries (as opposed to simply changing the URL or display name = menu item text).
The thing which we'd like to do is that japanese users can watch japanese web site from IDE's linking in the menu and so on. For example, currently, "resouces-home_f4j.url" in "modules/locale/utilities_f4j.jar" specify the us web site (http://forte.sun.com/ffj/). And "resouces-home-ja_f4j_ja.url" in "modules/locale/utilities_f4j_ja.jar" is the japanese site (http://sun.co.jp/forte/ffj/). But when we do not edit nbresloc:/org/netbeans/modules/utilities/resources-home.url in "Layer_f4j_ja.xml", then IDE links to "http://forte.sun.com/ffj/" Therefore, we need to edit it so that "Layer_f4j_ja.xml" may specify the *_ja.url files, like following: nbresloc:/org/netbeans/modules/utilities/resources-home-ja.url Because, the file "resouces-home-ja_f4j_ja.url" is not automatically read corresponding to ja locale, without no editing "Layer_f4j_ja.xml". We do not have the right to edit the en-file "resouces-home_f4j.url", so I think this is necessary l10n. Yasuhiro
No no, you made a typo. Not: resouces-home-ja_f4j_ja.url but simply resouces-home_f4j_ja.url is what should be in modules/locale/utilities_f4j_ja.jar in which case there should not need to be any edits relating to this file in Layer_f4j_ja.xml (nor indeed in Layer_f4j.xml). Please read the docs: http://www.netbeans.org/devhome/docs/i18n/index.html#5
Thanks for the information. "resouces-home-ja_f4j_ja.url" is not a typo. This file seems to have been renamed by a engineer in Sun's base product team. But I understand that this name was not I18Ned correctly and I do not need to edit "Layer_f4j_ja.xml", so I corrected all files that are named "*-ja_f4j_ja.url". I apologize for having spent your unnecessary time. Yasuhiro
Since there has been so much discussion about this issue and possible localization steps, I'd like to get definitive list for our S1S localization of what needs to be done and we'll go with that as you have more background on this issue and other related ones. Please provide steps and example.
It is really not complicated, nor anything that is not documented in the I18N reference; e.g. ---%<--- utilities.jar!/.../Layer.xml <!-- ... --> <file name="resources-home.url" url="nbresloc:/.../resources-home.url"> <attr name="SystemFileSystem.localizingBundle" value="org....Bundle"/> <attr name="SystemFileSystem.icon" urlvalue="nbresloc:/.../weblink.gif"/> </file> <!-- ... --> ---%<--- utilities.jar!/.../Bundle.properties Menu/..../resources-home.url=Resources ---%<--- utilities.jar!/.../weblink.gif <<usual icon>> ---%<--- utilities.jar!/.../resources-home.url http://www.netbeans.org/ide/faq.html ---%<--- locale/utilities_ja.jar!/.../Bundle_ja.properties Menu/..../resources-home.url=\u1234\u5678 ---%<--- locale/utilities_f4j.jar!/.../resources-home_f4j.url http://sun.com/whatever/faq.html ---%<--- locale/utilities_f4j_ja.jar!/.../resources-home_f4j_ja.url http://sun.co.ja/jp/whatever/faq.html ---%<--- Etc. The base Layer.xml, in utilities.jar, simply demonstrates that every visible aspect of the link - display name, icon, content - is individually localizable/brandable to your heart's content in the usual way. If you need to add, delete, or rearrange the basic structure of the URLs in the menu, then Layer_f4j.xml in utilities_f4j.jar could do that. For any more help, please take offline, as this issue is getting too cluttered.
Resolved for 3.4.x or earlier, no new info since then -> closing.