Agreed, passing to Standa who implemented these customization features.

fixed

7d3015c28a31

reopening, don't see the fix in bundle file from 0727 trunk build.
that is, no #NOI18N comment is in the bundle file.

ken.frank@sun.com

this is strange! 
When I look at the file at
http://hg.netbeans.org/main-golden/annotate/7d3015c28a31/core.windows/src/org/netbeans/core/windows/Bundle.properties
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

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)

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.

ken.frank@sun.com

jesse, would you know what's happening with resource bundles when jars are built?

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>

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

#NOI8N

fixed

1bae1b475121

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 core.windows

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.

ken.frank@sun.com

ken.frank@sun.com

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 ?

ken.frank@sun.com

To Ken - yes stripping of comments is needed, to minimize application footprint. Only those comments beginning

#[PART][NO]I18N

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.

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.

ken.frank@sun.com

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.

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

Integrated into 'main-golden', available in build *200807310201* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/1bae1b475121
User: S. Aubrecht <saubrecht@netbeans.org>
Log: #138273 - I18N

Stan,

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.

ken.frank@sun.com

> 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

thanks for pointing out the putback msg with that Jul 30 comment with the fix
for the 57 other items.

ken.frank@sun.com