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.
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. Evaluation: 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.
This issue will be resolved in next release after NB 5.5.
Designer 1 has been removed. Therefore reassigning to Designer 2 module. Probably this issue will be resolved in the future.
Could you look at Denis. It may have something to do with Refactoring. Thanks
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.
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.