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.

Bug 138273 - I18N - add #NOI18N comments to some bundle file entries for org-netbeans-core-windows.jar
Summary: I18N - add #NOI18N comments to some bundle file entries for org-netbeans-core...
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 6.x
Hardware: Sun All
: P3 blocker (vote)
Assignee: Stanislav Aubrecht
Keywords: I18N, SIMPLEFIX
Depends on:
Reported: 2008-06-25 19:20 UTC by Ken Frank
Modified: 2008-12-22 11:53 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2008-06-25 19:20:49 UTC
some items in a bundle file for this jar should not be translated - while it might
be clear to some that the word true should not be translated in this case it might
not be to others, thus if this section can be marked with #NOI18N comment,
it can help.

Comment 1 David Simonek 2008-06-26 08:50:48 UTC
Agreed, passing to Standa who implemented these customization features.
Comment 2 Stanislav Aubrecht 2008-07-14 15:20:00 UTC

Comment 3 Ken Frank 2008-07-28 21:35:26 UTC
reopening, don't see the fix in bundle file from 0727 trunk build.
that is, no #NOI18N comment is in the bundle file.
Comment 4 Lukas Hasik 2008-07-29 09:28:19 UTC
this is strange! 
When I look at the file at
then the #NOI18N comments are there but they are not in the bundle
(platform9\modules\org-netbeans-core-windows.jar\org\netbeans\core\windows\) from 07/28

Comment 5 Stanislav Aubrecht 2008-07-29 12:25:13 UTC
all comments are stripped from resource bundles when jars are built (i guess to decrease build size)
kfrank, can you get the I18N comments from source bundle files or do they have to be in jars as well? (the latter will
be a problem to implement i think)
Comment 6 Ken Frank 2008-07-29 15:14:57 UTC
l10n kit is built from product jars, not from source; thus its a very big
problem.  I do see in some jar files there are some #NOI18N comments
but it does not seem like a lot compared to what was used to.
question - does this stripping out apply to all nb modules jars or just to some ?

and also, would this be issue for nbbuild instead ?

I think its a p1 kind of situation in any case; let me know and I can file some
other issue or ask more to another team as needed.
Comment 7 Stanislav Aubrecht 2008-07-29 15:28:54 UTC
jesse, would you know what's happening with resource bundles when jars are built?
Comment 8 Jesse Glick 2008-07-29 23:18:59 UTC
nbbuild/templates/common.xml has

<copy todir="${build.classes.dir}">
  <!-- #58298: strip comments to save some space -->
  <fileset dir="${src.dir}" includes="**/*.properties"/>
      <!-- #61965: preserve #NOI18N and similar comments -->
      <replaceregex pattern="^#(?!(PART)?(NO)?I18N).*[\r\n]+" replace="" flags="gm"/>

The fault here is in the source bundle, which mistakenly uses

Comment 9 Stanislav Aubrecht 2008-07-30 09:37:08 UTC

Comment 10 Stanislav Aubrecht 2008-07-30 10:12:20 UTC
btw, i did a full text search across netbeans sources and found another 57 java sources with the invalid #NOI8N token.
i'll fix the three files in
Comment 11 Ken Frank 2008-07-30 15:48:46 UTC
does it mean that NOI18N comments are not stripped out when product jars
are built as mentioned before - that for this it was spelling of comment
NOI8N vs NOI18N ?

BUT what about other commented things in nb bundle files ? There are other
comments sometimes that don't use NOI18N or PART I18N - I know its not per spec
but they have existed - does it mean they are stripped out of bundle files for all
netbeans modules before jars are built ?  That is a problem if so.

are there really that many other comments besides #NOI18N in bundle files besides the license
which is still there, that comments need to be stripped out ? But in any case,
seems they would need to go back in so the other msgs to translators are there.

please reopen this or file new issue if applicable about this.
Comment 12 Ken Frank 2008-07-30 16:54:59 UTC
to clarify more last comments, there are some comments other than
#NOI18N that mention about to not translate or partially translate
some messages or labels; I don't know what they are or where they are
but it does have impact on translations so that is why asking
if the stripping of comments is really needed.

also, does this stripping apply to all nb modules in all clusters ?
Comment 13 Jesse Glick 2008-07-30 20:10:52 UTC
To Ken - yes stripping of comments is needed, to minimize application footprint. Only those comments beginning


are retained. Any comments about what to translate or not must follow this format. And yes this applies to all modules
in all clusters. If translators require other comments to be available in the L10N kit, that should be filed as an RFE
for the L10N kit; it is off-topic here.
Comment 14 Ken Frank 2008-07-30 20:58:01 UTC
sorry its off topic to you but this is important information to have and get and since
you mentioned about this stripping script here, then seems that asking followup about it
is too.

as to this stripping, as asked below, does it apply to all modules in all clusters ?

I don't know what you mean by if translators require other comments in l10n kit and to file an RFE ?

the other comments (those not NOI18N but yet that relate to do not translate this or that,  are put in by nb developers
or others who touch the bundle files,
not by translation team; they are the customer of kits, they don't control about the comments
but they need them,
and if things other than NOI18N are used, and if those comments are stripped then
seems like the stripping patterns should be expanded or not done or that the implementators
of the stripping need to tell the developers about it so they can correct their
comments as needed.

whats the category/subcat of the stripping script - we can file issue about this.
Comment 15 Jesse Glick 2008-07-30 21:08:08 UTC
Again: all modules, all clusters.

If translators need for the L10N kit to contain any comments in properties files other than those already present
beginning with "I18N" (with optional "PART" or "NO" prefixes), then they should request this of whomever creates the
L10N kit - not me and I do not know who, but I would start in the nbbuild component. The regular NB build would not do
for this, since it has stripped properties files, 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.
Comment 16 Jesse Glick 2008-07-30 21:28:40 UTC
Stando - thanks for the tip. I ran

hg loc -r tip -0 | xargs -0 perl -p -i -e 's!NOI8N!NOI18N!g'

and will push as: core-main #c5376858db0d, contrib #e8a37f50dc9a
Comment 17 Quality Engineering 2008-07-31 04:11:33 UTC
Integrated into 'main-golden', available in build *200807310201* on
User: S. Aubrecht <>
Log: #138273 - I18N
Comment 18 Ken Frank 2008-08-15 19:41:59 UTC

about the 57 other instances of the typo of the NOI18N comment, does it need another
issue filed ? if so, let me know details please.

am verifying this one about the original items mentioned.
Comment 19 Stanislav Aubrecht 2008-08-18 08:17:49 UTC
> about the 57 other instances of the typo of the NOI18N comment, does it need another issue filed ? if so, let me know
details please.

i believe jesse already fixed those, see his comment from  Wed Jul 30 20:28:40 +0000 2008
Comment 20 Ken Frank 2008-08-18 15:23:57 UTC
thanks for pointing out the putback msg with that Jul 30 comment with the fix
for the 57 other items.