i18n module should also check for some hardcoded
chars as in above example. It requires precise
java source model rather than current REs.
Also note that replacement code is different for
this case i.e.:
Target milestone was changed from not determined to TBD
I'd like to add that setDisplayedMnemonicIndex(int) should
also be considered as a candidate for I18N.
I hacked FormI18NString & created FormI18NInteger and
FormI18NCharacter with respective editors, (I'll attach
And now I'm able to manually change the editor of Mnemonic
to "Resource bundle - Character", creating a key in RB,
and making it I18nable, but still looking around the
automatic lookup&replace - the algorithm in I18NFinder is
I'll try to patch the finder in a week in order that it
will be able to find not only hard-coded strings, but also
hard-coded chars and integers.
Max, the algorithm in I18nFinder is parametrized by regular expression
("RE"). It should be enough to provide:
- hardcoded mnemonic RE
- internationalized mnemonic RE
- replacement code format.
I'm not sure if anyone can design universal replacement code format
for both mnemonics and texts. Actual format need to be parametrized by
hardcoded string type and generate diferent code for mnemonics and
See also RFE 27009:
If it will be solved, no need in this ENCHANCEMENT ;)))
Created attachment 7299 [details]
The changed sources of i18n module
Created attachment 7300 [details]
Demo form, storing text, mnemonic & displayedmnemonicindex
The two attachments are:
i18n.zip - the changed sources of i18n module (changed from release34 tag)
demo.zip - the demo form, using the patched module, which stores all
properties (Text, Mnemonic & DisplayedMnemonicIndex) of a button in a
However, the change of storing the Mnemonic & DisplayedMnemonicIndex
properties in a bundle was hand-made ;( via changing the editors for them.
Please, take a look.
This enhancement is still needed because Form editor is not the only
tool for designing forms. In theory.
Leaving as low priority enhancement.
Patch accepted and integrated.
Thanks you Max.
Petr, I'm certainly proud that you integrated the patch, but that was
a buggy patch, I think ;(
For instance - Please take a look at FormI18nMnemonicEditor.java &
FormI18nIntegerEditor, they both contain non-i18nized strings, marked
with // NOI18N:
" - Mnemonic" and " - Integer" both in getDisplayName() method.
And they are just cut & paste from FormI18nStringEditor & FormI18nString.
Also, please update the @author tag to include me. If there will be
bugs, Peter Zavadsky & Petr Jiricka are not responsible much ;)
I fixed these before integration.
I'm responsible for bugs.
I18N should utilize them, and it can be achived only by modifying the
algorithm for searching, which seems to be a lot of rework, I18nFinder
seems to be hard-coded for Strings ;):
nextString, HcString, etc.
I have not closed the issue for the same reason, see above.
*** Issue 26253 has been marked as a duplicate of this issue. ***