Source file: version.properties
# NOI18N version=3.0.0 # test version2=3.0.1
There are no translations and generate target files.
Target file: version_ja.properties (in OmegaT 2.6.3)
# NOI18N version=3.0.0 # test version2=3.0.1
Target file: version_ja.properties (in OmegaT 3.0.2)
# NOI18N 3.0.0 # test
I checked [Remove untranslated strings in the target files] option in Java resource bundles filter settings and found it remains unchecked (probably keeping it's default value.)
Next I looked into ResourceBundleFilter.java and found these.
L289-295:
// Parameter in the options of filter to customize the target file String removeStringsUntranslatedStr = processOptions.get(OPTION_REMOVE_STRINGS_UNTRANSLATED); if ((removeStringsUntranslatedStr == null) || (removeStringsUntranslatedStr.equalsIgnoreCase("true"))) { removeStringsUntranslated = true; } else { removeStringsUntranslated = false; }
Since unchecked (and never checked before) option state represents null value, so removeStringsUntranslated variant will be set to true in my case.
I'm not sure if this behavior is as intended. I can't imagine but is there the pros in some cases?
And whether it is implemented as intended or not, I feel that banishing NOI18N keys is overkill.
No, that's a bug. The default value should be false. Thanks for noticing.
It has been like that since Maxym implemented the bundle filter in 2005 (prior to 2.6), partly for localising NetBeans. If only for that, it will remain the default value.
If that's an issue for you, you could implement an option translate NOI18N keys.
Didier
Fixed in SVN (/trunk).
Didier
The bug applied to Mozilla DTDs as well (same original code).
The issue is fixed in both filters.
Didier
Fixed in the released version 3.1.3 of OmegaT.
Didier