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.
Form editor functionality is broken if i18n-form module is disabled. 1) enable i18n module (i18n-form is a bridge if get enable automatically) 2) insert some string into form using resource bundle editor 3) close the form 4) disable i18n module 5) open the form and see that all i18nized strings are not displayed Workaround: Enable i18n module.
I think form editor should not care about extending modules. From its point of view this is a missing property editor class, which is now correctly reported (recently improved) - just like any other error occured during form loading...
Sorry, from users point of view it is problem.
Sorry, but I don't think Form Editor should enable i18n module. It's the same like you would use a custom bean and wanted Form Editor to mount automatically its directory if you forget... I don't see a way how could form editor deal with this issue...
Would not help you introducing an i18n SPI? Something like: public Internacionalizable extends Node.Cookie { /** Scan data object for hardcoded string instances */ Enumeration enumerateNonIntenationalizedStrings(); /** Replace the instance with a keyed access */ internationalize(String hardcodedStringInstance, String key); /** Enumerate keys */ Enumeration enumerateInternalizationKeys(); }
But help with what? As I see it: - you cannot move whole internatialization to form module, - it will always be a separate (bridge) module, either a part of form project or i18n project, - if you disable this module, internationalized forms won't work. If we don't want to make form module dependent on i18n, and if we neither want to do explicit enabling of i18n and i18n-form modules (hardcoded in form module), what else can we do? I think this would have to be solved more generally by implementing some extending infrastructure in form module - all extensions of form module would have to specify how they can be set up to work when needed in some form being loaded (e.g. some jar must be mounted or some module installed). But working on such extending infrastructure is of the lowest priority now... Anyway, we can keep this as an interesting enhancement request.
In the proposed case you have data format under form control at least. I18N UI goes away but it does not matter. You can display it as "user code".
I think problem is missing i18n API (I mean openidex API, not the one exposed by module). I18n modules should be just oferring somthing like i18n service, taking case about filling the key and strings to properties files etc., but the code changing form itself should reside in form, thus form setting what exactly it means i18n-ize some string. The openidex API should connect together the funcionality, and not like now when i18n-form module has to hack the form module. Scenario: If module i18n would be switched off the service would disappear you could not currently internationalize it, but the already i18n-ized form has to work, since the form data would be held by form, and the data in properties files would be exist. Did you get the idea? I18n module would be just a service module needed only during the time of i18n-ization, and not as the holder of i18n-ized but form-specific data. The form i18n editor currently part of i18n-form should be in form hands.
Peter, thanks for your positive attitude!
Set target milestone to TBD
Closing an old RFE, I don't think we need this.