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.
Try the ml daily build e.g. builds/netbeans/6.1/fcs/latest/ml/. It includes Japanese localization. It seems that localized platform jar files will not be built and copied into the binary when Run JNLP apps. 1. Start IDE 2. New Project 3. Samples > NetBeans Modules > Paint Application 4. Run JNLP Application Localized jar files of NB platform should be signed and copied into the dist folder - <project>/dist/jnlp/local/netbeans/.
I don't know where to get an "ML daily build". Give me a URL if you want me to reproduce anything, and instructions for reproducing on an English-language computer. To test, I downloaded 6.0.1 ML from the public website and installed it. In a plain NB dev build, using JDK 6, I configured a NetBeans Platform with that installation (using the default mode "Harness Supplied with IDE", i.e. testing the same JNLP building code you claim does not work). I created an application suite using the new platform, then ran Run JNLP. The app appeared in English as expected. Then from a command line I ran javaws -J-Duser.language=pt -J-Duser.country=BR $thesuite/dist/jnlp/local/master.jnlp and the app appeared in Portuguese as expected. I do know that localization JARs will not be included if they are not enumerated in */update_tracking/*.xml in the platform. If these files indeed fail to mention the ML JARs, please reassign to mzlamal in nbbuild/code as this would be a production build issue.
http://smetiste.czech.sun.com/builds/netbeans/6.1/fcs/2008-04-21_18-33-08/ml/zip/ for internal location of recent ml bld. ken.frank@sun.com
Indeed the build you point to does not have localized JARs correctly listed in update_tracking/*.xml.
*** Issue 138056 has been marked as a duplicate of this issue. ***
*** Issue 157027 has been marked as a duplicate of this issue. ***
I have the same issue with NetBeans v6.5 and German locale. (See: http://www.netbeans.org/issues/show_bug.cgi?id=157027 ) Here is what I did to get a NetBeans Platform with German l10n files: - Download the NetBeans Platform src.zip and build it - Download the German NetBeans IDE and install it - Exctract the German i18n files from the German NetBeans IDE installation and merge them into the directory of the NetBeans Platform binaries - Uninstall the German NetBeans IDE (I think I also had to uninstall and reinstall the English NetBeans IDE) - Configure the application to use this built platform After this the German texts showed up when starting the application with the German locale - but only if I start the application "normally" from within the IDE. "Build ZIP Distribution" and "Build JNLP Application" do not include the localized platform jars! I tried now to manipulate one of the update_trackin/*.xml and the according jar was included in the war and the jnlp had the according resources entry. Is there an easy way to create all those files with the correct crc attributes in the file elements? (Though the crc attributes don't seem to be needed.) Or do I have to manipulate all these xml-files manually??? Neither the German nor the standard (default, ja, pt_BR, zh_CN) installation of the NetBeans IDE v6.5 do include any file elements for localized jars -> this should be fixed. I found almost no documentation about update_tracking -> this should be fixed It really should be simpler to internationalize a NetBeans Platform based application: http://www.netbeans.org/issues/show_bug.cgi?id=157031
I'll look into that.
Looking at nbbuild/newbuild/build-all-components.sh I see that ML artifacts are build in a special step (line 302): ant -Dbuildnum=$BUILDNUM -Dbuildnumber=$BUILDNUMBER -f build.xml -Dlocales=$LOCALES -Ddist.dir=$NB_ALL/nbbuild/netbeans-ml -Dnbms.dir=${DIST}/uc -Dnbms.dist.dir=${DIST}/ml/uc -Dkeystore=$KEYSTORE -Dstorepass=$STOREPASS build This step produces a number of locale jar files and does not create any update_tracking files nor modifies existing ones. Later in the build process, English artifacts are *copied* to the ml directory (line 247): cp -r $NB_ALL/nbbuild/netbeans/* $NB_ALL/nbbuild/netbeans-ml/ That also copies update_tracking/* files. Those files correspond to English-only files and does not update tracking information for localized files. One of the possible solutions is to re-generate update_tracking/* files after that. Hard to say whether we already have a specific ant target for that (probably that is netbeans-ml in projectized.xml) or should yet create another one. Reassigning to nbbuild owner.
BTW, this issue also happens with zips which are created in pack-all-components.sh using zip-cluster-config target.
Why is it 6.9_WAIVER_APPROVED? I haven't seen any requests about this issue on nb-bug-waiver-council.
A-ha, just saw "Automatic waiving of P2s which are not stoppers" in p-team minutes.
*** Bug 187872 has been marked as a duplicate of this bug. ***
simpatico - Version fields may be moved backward (if a bug is found to be reproducible in an earlier release than previously thought), but not forward; an open bug is assumed to apply to all later versions.
Why is this marked with "www" instead of platform?
(In reply to comment #14) > Why is this marked with "www" instead of platform? Because the problem is with build scripts, not the platform per se.
Perhaps related (if not, I'll file a new issue): directory "release" in a suite is not included in zip distribution.
(In reply to comment #16) > Perhaps related Not related.
pgebauer, did you send request for waiver as specified in http://wiki.netbeans.org/WaiverProcess ? If not, please do so ASAP. Thanks in advance.
(In reply to comment #18) > pgebauer, > did you send request for waiver as specified in > http://wiki.netbeans.org/WaiverProcess ? If not, please do so ASAP. Thanks in > advance. Yes, I did on Tuesday 22-Mar. The issue should be marked as waived today, in case of no objections.
agreed with waiver
3 years old, P2, 20 votes, 3 duplicates and still waiver :-)
*** Bug 199496 has been marked as a duplicate of this bug. ***
A comment on the waiver request for 7.0.1 from Jesse Glick: ----- > The fix is not likely to be trivial. I see this issue being repeatedly waived, with no real evaluation. > Users which uses JNLP with non-EN locales will be impacted. Also affects anyone creating plain ZIP distributions of NB-based applications. ----- Unfortunately, the time is running out for 7.0.1, and with Petr G on vacation, we have no option but to waive this for 7.0.1 as well.
We also had a problem in building a localized netbeans rcp app based on netbeans platform 7.0 that shall be distributed via Java Web Start. That is what we did: http://netbeans.org/projects/platform/lists/dev/archive/2011-07/message/246 The localized jars are not added to the generated *.war file. But the created ZIP distribution includes the localized jar files. Maybe because we added the localized jar-files to the netbeans platform directories manually before. Does anybody knows how to integrate all the localized jar files into the "build-jnlp" target?
>20 dups + votes -> P1 based on http://wiki.netbeans.org/BugPriorityGuidelines
*** Bug 169522 has been marked as a duplicate of this bug. ***
not a stopper for NB 7.1 Beta - but must be fixed for 7.1 FCS
The update_tracking/*.xml files are generate by the build-nozip target but the target generates only English bits. The multi lingual version isn't generated from java source but only locales are created from l10n repository and they are just copied into English bits. A re-generation of update tracking files ( proposed in http://netbeans.org/bugzilla/show_bug.cgi?id=133901#c8 ) isn't possible because all jar files from all modules are mixed in one place however update tracking files have to be generated for jar files per every single module. Does anybody have an idea how to generate update tracking files without complete rewriting of multi lingual build script?
(In reply to comment #28) > re-generation of update tracking files isn't > possible because all jar files from all modules are mixed in one place Should not be a problem; you can infer by its path that platform/modules/locale/org-netbeans-core-io-ui_ru.jar is supposed to be a variant of platform/modules/org-netbeans-core-io-ui.jar, thus owned by update_tracking/org-netbeans-core-io-ui.xml. Anyway that is only relevant if you want locale JARs to be associated with the individual module. This would not work if unlocalized updates were offered, which is quite likely given that translations are not even kept in the main source repository. A better approach might be to create one pseudomodule NBM for all localizations, or one per locale, or one per cluster, or one per locale x cluster, etc.; these could appear as regular plugins in Plugin Manager, or be invisible modules "recommended" by plugins. This technique would anyway be required by unofficial community translations. (There is a special <l10n> element permitted by the Auto Update DTDs - somewhat akin to OSGi bundle fragments - but I doubt this feature was ever fully implemented or tested, and is unlikely to work properly with either Ant- or Maven-based builds.) Whichever policy is adopted, the Maven repository and JNLP builds must be considered as well. I expect this issue will get waived for 7.1 once again. As a nontrivial change with possibly wide ramifications it needs to be planned for and addressed during the regular development cycle, not as a bug fix during stabilization.
> I expect this issue will get waived for 7.1 once again. I'd hope it will be addressed for 7.1.
Perhaps there could at least be a workaround documented somewhere. Someone developing a NB Platform based application will eventually want to distribute localised versions of his app. I am not aware of any documentation on how to do that. After a lot of searching I found someone describing how to hack the update_tracking files manually and download the localised jars seperately and put them in the right place. This is a very time-consuming and error-prone procedure that has to be repeated with every new version of the IDE being installed. It would be nice to have an official HOWTO for that. Even better would be a "pre-hacked" multilingual distribution to download that works right out of the box.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/428a24a0c939 User: PGebauer <pgebauer@netbeans.org> Log: #133901 I18N: Build JNLP App/ZIP Distribution will not include localized jar files
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/076bb8610593 User: PGebauer <pgebauer@netbeans.org> Log: #133901 I18N: Build JNLP App/ZIP Distribution will not include localized jar files
The issue should be fixed. Could somebody verify it? Bits are at http://bits.netbeans.org/trunk/nightly/latest/zip/
Thank you for working on it, it's great to include the fix into 7.1! I'm now trying 201111060600 build on Japanese Windows and here are the quick results: 1. create a NetBeans Platform Application project 2. create a sub module under it, added a empty Windows to the module 3. Start it on NetBeans message on splash screen and menus are localized : OK 4. Try JNLP message on splash screen e.g. Initializing, Staring Modules... are still English menus are localized 5. Try ZIP distribution message on splash screen e.g. Initializing, Staring Modules... are still English menus are localized
Masaki, could you please attache screenshots? BTW do you know a place in source tree where messages from splash screen (Initializing, Staring Modules...) reside?
Ran my existing NB platform app from within the IDE with --locale pt:BR, since that locale is apparently always shipped with the IDE. Result was that the splash screen was localised in Portuguese. Then I built a Mac OS X application and ran it outside the IDE: splash screen again in English. Ulrich
(In reply to comment #36) > Masaki, could you please attache screenshots? BTW do you know a place in source > tree where messages from splash screen (Initializing, Staring Modules...) > reside? I can see the message in platform/core/core.jar org/netbeans/core/startup/Bundle.properties:MSG_restore=Starting modules... When I checked ZIP distribution, platform/core/locale/core_<lang>.jar is not provided.
I take nb 7.0.1 with Czech jar files. Next I copy netbeans-trunk-nightly-201111060600-ml-javase over it. Start IDE under Linux with Czech localization. Menu in IDE are Czech. Build application and package as zip distribution. New application I run outside IDE. Menu are English.
(In reply to comment #39) > I take nb 7.0.1 with Czech jar files. Next I copy > netbeans-trunk-nightly-201111060600-ml-javase over it. Start IDE under Linux > with Czech localization. Menu in IDE are Czech. Build application and package > as zip distribution. New application I run outside IDE. Menu are English. The standard ML NetBeans IDE doesn't contain Czech locales. Only ja, pt_BR, ru and zh_CN are supported. Czech locales are handled by community builds.
http://hg.netbeans.org/main-silver/rev/a662c6b491e8 http://hg.netbeans.org/main-silver/rev/ec687ba12277
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/ec687ba12277 User: PGebauer <pgebauer@netbeans.org> Log: #133901 I18N: Build JNLP App/ZIP Distribution will not include localized jar files
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/daf7b1d2c905 User: PGebauer <pgebauer@netbeans.org> Log: #133901 I18N: Build JNLP App/ZIP Distribution will not include localized jar files
(In reply to comment #38) > When I checked ZIP distribution, > > platform/core/locale/core_<lang>.jar > > is not provided. It should be fixed. Masaki, could you please verify the result as you did in http://netbeans.org/bugzilla/show_bug.cgi?id=133901#c35 ? Thank you.
Checking netbeans-trunk-nightly-201111150600-ml-javase.zip. */update_tracking/*.xml look right. Make new NetBeans Modules > NetBeans Platform Application. Add to project.properties: run.args.extra=--locale ru and Run Project. Appears in Russian as expected. Package as > ZIP Distribution. Unzipped result, ran with --locale ru. Again appeared in Russian as expected. JNLP > Run. build/jnlp/netbeans/*.jnlp created with e.g. <resources locale='ru'> <jar href='org-openide-filesystems/locale-org-openide-filesystems_ru.jar'/> </resources> as expected. App appeared in English as expected. Ran javaws -J-Duser.language=ru dist/jnlp/local/master.jnlp and app appeared in Russian as expected. After excluding "JUnit 4" from the app (Libraries tab), and adding jnlp.platform.codebase=http://deadlock.netbeans.org/hudson/job/ide-jnlp/lastStableBuild/artifact/nbbuild/build/jnlp/ to project.properties, running Clean, then repeating the JNLP build, Russian locale is not available, since this job does not currently build locales out of the l10n repo. Whether this will work with http://bits.netbeans.org/7.1/fcs/jnlp/ (or whatever the final URL is) depends on what process builds those files - Petr is there some preview available of JNLP files? I guess that would be http://bits.netbeans.org/trunk/nightly/latest/jnlp/ but this does not currently contain locales. http://bits.netbeans.org/dev/jnlp/ (the same??) does not either. Cannot fully test Mac applications, but can observe that the result contains the expected locale JARs, so see no reason why it should not work as well. http://bits.netbeans.org/trunk/nightly/latest/uc/ contains locale JARs. NBMs in http://bits.netbeans.org/netbeans/trunk/maven-snapshot/ do not contain locale JARs. Petr - not sure if I should leave this FIXED and open separate blocking issues for the Maven repo and (prebuilt) JNLP, or if you will be fixing those as well?
(In reply to comment #45) > Whether this will work with http://bits.netbeans.org/7.1/fcs/jnlp/ (or whatever > the final URL is) depends on what process builds those files - Petr is there > some preview available of JNLP files? The following link http://bits.netbeans.org/netbeans/7.1/jnlp/ could be used as preview. It contains 7.1-beta bits. BTW Do I understand correctly that jar-files from the mentioned link should contain locales? (They do not contain any now) > Petr - not sure if I should leave this FIXED and open separate blocking issues > for the Maven repo and (prebuilt) JNLP, or if you will be fixing those as well? Could you please open a new issue? Thank you.
OK, I will open blocking issues.