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.
please bear with me as explain why feel this is p1; I realize this situation might have been in earlier release but that does not make it less a problem. in 138273, it mentioned that before product jars are built, that all comments but #NOI18N or #PART I18N are stripped out, ie ------- Additional comments from jglick Tue Jul 29 22:18:59 +0000 2008 ------- nbbuild/templates/common.xml has <copy todir="${build.classes.dir}"> <!-- #58298: strip comments to save some space --> <fileset dir="${src.dir}" includes="**/*.properties"/> <filterchain> <tokenfilter> <!-- #61965: preserve #NOI18N and similar comments --> <filetokenizer/> <replaceregex pattern="^#(?!(PART)?(NO)?I18N).*[\r\n]+" replace="" flags="gm"/> </tokenfilter> </filterchain> </copy> BUT there are and have been some comments for translators related to don't translate this or that or other special instructions that dont use the words NOI18N in it, and that means bundle files in kits wont have these comments and thus translators won't see them. I realize perhaps that dev do need to use NOI18N though I don't know if its something all know or has been enforced. But in any case its a problem for translators. It was mentioned that comments stripped due to space requirements and size of jars. a. how can this be fixed so that kits have these other messages - I don't know scope of it or which bundles have them, saw a few just on some browse. b. jesse suggested but perhaps the L10N kit could be built from a special throwaway build created with a flag to skip the stripping step in projectized.xml. (Such a build would be functionally identical to a regular build, except being slightly slower to start up.) The I18N comments (which are relatively rare) are needed in the regular build even disregarding the L10N kit, in order for -J-Dorg.openide.util.NbBundle.DEBUG=true to work. c. I think adding more patterns to file to allow other comments not to be stripped would be a problem since how can all such strings be known ? ---> thats why its filed at p1 and although solution not needed this minute, it will help to at least have this discussed and proposed solutions in time for when actual translation starts. please change to p2 if it will stay on radar and be solved fairly soon.
Adjusting summary to better reflect the actual request, which is about the kit, not the production build.
some ideas for workaround until actually fixed: 1. add patterns to skip that are of these words/patterns: I8N (this has happened in 138273 and although fixed there, it might be in other components since it is a common typo in general i18n, i8n, l10n, L10N, L10n, I18n, i18N - other spellings used sometimes locale, localization, localize and upper case versions or patterns ocal and OCAL translate, translation, Translate, translators, TRANSLATE, TRANSLATION "do not" - some words that recall as being in some bundle files in past. (actually patterns anslat & ANSLAT would cover this. 2. mail could go to dev mgrs and nb-tech asking to change any such comments to #NOI18N 3. if kit created from special build, in which no comments have been stripped, assume however the bundle files would be exactly same as those in product build. 4. it also would mean that reverse process would need to happen, that before building ml the comments would need to be stripped off since in this case all comments would be in these bundle files. ken.frank@sun.com ken.frank@sun.com
#1 - no. #2 - yes, developers are required to use the standard naming pattern for message keys which are not intended for translation. #4 - optional but probably good for performance.
why no to modifying commented strings with certain additional patterns mentioned below - would that rather small set of additional commented lines really increase size that much ? as to yes to sending mail to nb-tech or dev mgrs, can you do it or at least send me mail with wording and I'll fwd - since think it will mean more for dev to see it coming from you.
No to #1 because the patterns are too vague, and the correct pattern is needed anyway for bundle debugging mode. I did not invent this system but: *Bundle*.properties are entirely localizable by default; any bundle key which should be ignored by translators in such files should be immediately preceded by #NOI18N Other *.properties are not localizable by default; within such files, any bundle key which should be addressed by translators should be immediately preceded by #I18N Also, #PARTI18N and #PARTNOI18N may be used for keys which contain some localizable content but which should be treated with care as other parts are fixed. In practice, only #NOI18N is used with any frequency that I know of, generally for brandable resource strings (progress bar colors etc.) which are irrelevant to language translation.
Comments are not stripped out of .properties files any longer.
As of bbc5329c3be5.