Bug 157031 - Easier I18N of NBM apps
Easier I18N of NBM apps
Status: RESOLVED WONTFIX
Product: apisupport
Classification: Unclassified
Component: Harness
6.x
All All
: P2 with 17 votes (vote)
: TBD
Assigned To: Jaroslav Tulach
issues@apisupport
: I18N
Depends on: 133901
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-19 09:30 UTC by puce
Modified: 2013-04-18 07:38 UTC (History)
2 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 puce 2009-01-19 09:30:01 UTC
As stated at http://www.netbeans.org/issues/show_bug.cgi?id=157027
i18n of a NetBeans Platform based application is very inconvenient.

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

I think there should be a more convenient way to get the localized platform jars.

In addition support/ documentation should be provided to the developer to choose if the localized platform jars should
be bundled with the application or if they should form a pluggable Locale Extension Archive Module, which could be
either bundled with application (but allows the user to disable/ uninstall it) or made availabe via the Update Center.

Maybe it would be good to have a Locale Extension Archive Module project template in general, which would aid the
developer in building pluggable locale support of custom modules. (The Form Editor should respect the location of these
files, too.)
Comment 1 puce 2009-01-19 14:22:53 UTC
As noted in http://www.netbeans.org/issues/show_bug.cgi?id=133901 also the update_tracking/*.xml files need to reference
the localized jars.

There should be an easier and pluggable support to create these entries.
Comment 2 puce 2009-02-06 18:26:12 UTC
Also localizing branded resources (eg. splash screen, window title, etc.) should be easier, without needing to duplicate
the branding-token in file names (eg. enhancing the branding-directory concept). 
Comment 3 lucbard 2009-02-20 19:31:31 UTC
Here is a work around I used to localize the splash screen.

1. Brand your application in the first language
   - Splash screen image
   - Bundle.properties (if other than english you can find more key to translate in the core.jar
(org/netbeans/core/startup/Bundle.properties) This way you can translate any text such as the "Loading module..." in the
splash screen

2. Build you app, you should find a file under build\cluster\core\locale\ called code_${branding.token}.jar
3.Copy this file else where
4. In your project.properties file change the banding token to something else in my case ${app.name}_fr
5. Do step 1 and 2 again but for the other language
6. How do we tell out RCP to switch branding depending on the machine's locale? We need to create a new main class that
will add a parameter in this case --branding <desired branding token>.
7. In that main class call then real org.netbeans.core.startup.Main.main(args)

Zip Distribution
8. Build a zip distro and make sure you copy all the needed file in
${youproject}\core\locale\
- Your 2 branding jar files and you jar file containing the new MainClass
9. Modify the conf file located in the etc folder: ${youproject}.conf

default_options="-J-Dnetbeans.mainclass=your.packace.MainClass"


Voilà, you will get a fully localized splash screen all withing the same RCP app. 
Comment 4 puce 2009-02-21 20:25:52 UTC
To change the branding token for each supported locale and write a custom Main class for such a basic and common thing
as localization is really very impractical. (If there is a better way please point to/ provide  the documentation.)

-> changing priority to P2
Comment 5 eclesia 2010-06-12 18:18:36 UTC
If i18N packs could also be deployed for maven RCP build that would be great.
Comment 7 jyoungman 2010-10-07 01:01:38 UTC
I would like to be able to switch locale (for the entire RCP platform) on the fly as different users login to my application. Failing this, an easier way to generate a zip distribution with all the main menu options etc in my selected language. I can easily take care of localizing my own code.
Comment 8 Jesse Glick 2010-10-07 14:11:27 UTC
Please do not change the Version field to a later value. It may only be changed to an earlier value, if found to be reproducible earlier than previously noted.

(In reply to comment #7)
> I would like to be able to switch locale (for the entire RCP platform) on the
> fly as different users login to my application.

Sorry, this will probably never be supported. Too many labels are preloaded.

> an easier way to
> generate a zip distribution with all the main menu options etc in my selected
> language

You do not need a special distribution; just pass the --locale option.
Comment 9 Jesse Glick 2011-10-25 18:27:22 UTC
(In reply to comment #0)
> I think there should be a more convenient way to get the localized platform
> jars.

This all comes down to bug #133901.

> a Locale Extension Archive Module project template [...], which would aid the
> developer in building pluggable locale support of custom modules.

http://wiki.netbeans.org/DevFaqMavenL10N shows how to do this for Maven-based projects; could be an archetype. Slightly trickier for Ant-based projects since you need to both customize extra.module.files and add a target to build.xml using <branding>.
Comment 10 Jaroslav Tulach 2013-04-18 07:38:28 UTC
I don't plan to work on this feature, but I am ready to review and possibly accept a patch, if it is donated. Meanwhile marking won'tfix.


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