Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 83140 - I18N Wizard doesn't work correctly with guarded blocks
I18N Wizard doesn't work correctly with guarded blocks
Product: javame
Classification: Unclassified
Component: Visual Designer
PC Windows XP
: P3 (vote)
: 6.x
Assigned To: Denis Anisimov
: I18N
Depends on:
  Show dependency treegraph
Reported: 2006-08-22 09:15 UTC by bugbridge
Modified: 2009-02-06 14:14 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description bugbridge 2006-08-22 09:15:21 UTC
Although NB i18n wizard can be configured to work with j2me files, it is may
cause data loss. The wizard replaces all strings in the editor (also in guarded
blocks) however the changes made in guarded blocks are lost when the application
is updated. We have to provide a fix (do the replacement in model instead of in
the source) or i18 wizard should be disabled in j2me project.

The problem is that guarded blocks contains hardcoded strings. I18N wizard
replaces it, but the guarded sections are regenerated after MVD model is changed.

The problem is partialy resolved by registering a MVD-i18n-support. This support
extends Java-i18n-support and filters all hardcoded strings which are in the
guarded block. So they does not appear in the wizard and are not replaced.

Still there is a problem that hardcoded strings in guarded blocks are not
replaced. It requires 2-pass walk through (1. mvd model, 2. the source outside
of guarded block), because mvd model must regenerate the source code to
propagate new strings that must be procedded before 2. step.
Comment 1 David Kaspar 2006-08-22 09:16:45 UTC
This issue will be resolved in next release after NB 5.5.
Comment 2 David Kaspar 2007-07-11 10:37:15 UTC
Designer 1 has been removed. Therefore reassigning to Designer 2 module. Probably this issue will be resolved in the future.
Comment 3 Karol Harezlak 2009-02-02 10:35:11 UTC
Could you look at Denis. It may have something to do with Refactoring. Thanks
Comment 4 Denis Anisimov 2009-02-06 12:45:55 UTC
I'm trying to implement J2ME I18N support that will skip I18N hardcoded strings in
guarded blocks.
Currently I18N is just not supported at all for J2ME files.
This will be fix for this DEFECT.
I18N improvement ( i18n inside guarded blocks ) should be separate issue and this is
not a DEFECT. This should be enhancement . It requires more work on this.
Comment 5 Denis Anisimov 2009-02-06 14:14:19 UTC
After investigation I realized that I18N requires not
only mobility source code changes.

Even if we want to internatiolize just non-gurded strings 
we need a way how to internationalize strings.
J2ME platform originally doesn't contain ResourceBundle class.
As result I18N NB support throws varios exceptions and generated
source code will be not compilable in most cases.

So the first things that needs to be done is *i18n java format definition*
for J2ME. It differs from Java SE format ( I mean smth like 
"ResourceBundle.getBundle().getMessage(key)" ) .
It is possible to set java format as option but in this case this 
option will work for any file ( java, nb java file ).
So there should be a way how to provide default i18n java format for J2ME
( default option value or even absolutely separate mechanism which 
doesn't intersect with general Java formats ). It requires some changes in NB I18N module
as a whole.

The second : i18n format should be based on some existing Bundle classes.
One need to decide how these classes should be created.
J2ME platform doesn't have implemented Bundle classes.
So we need to decide how to handle this situation.
The options could be :
1) Bundle class automatic creation on stage of i18n. It could be a problem becuase class with the 
name that we suggest could be already there ( with different functionality).
2) Ask user to create class by himself ( in this case he will need also to set up i18n format string ).
3) Providing additional J2ME library which will include something like ResourceBundle class
with appropriate functionality. I18N format string will be known in this case.
4) Something else..........

So there are too many problems related to this issue even with simple way to fix.
I suggest to set it as RFE because current situation is preferable against attempt of
simple implementsation I18N J2ME support with a lot of problems in generated source code
as result. Now it is just disabled for J2ME classes.

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