Bug 169522

Did it work for you in previous versions of platform? If so, which was the latest?

It seems to me that there has never been support for building platform app with arbitrary localization (i.e. without
update_tracking/*.xml entries), correct me if I am wrong. See
http://www.netbeans.org/issues/show_bug.cgi?id=133901
http://www.netbeans.org/issues/show_bug.cgi?id=157031

I agree that this should be changed, but it is rather an enhancement than a bug. As a workaround for now, you can add
your localization files into ZIP distribution e.g. in overriden 'build-zip' target in your suite.

If you select language German when downloading NB 6.7 the german localization files are installed but they are not
registered in update_tracking/*.xml
And therefore they are not copied during "build zip distribution".

Sorry, this is not an enhancement, this is a real big bug! Billions of people all over the world have a non-english
mother tongue and the localization teams spend a lot of time in translating the bundles. If a NB user cannot create
a distribution with support for additional languages than NB is not usable for nearly 90% of the world!

The supposed workaround is very problematic because I would have to know which localization files I have to copy. I use
44 NB modules in my application and I really don't know which localization file I have to copy for which module. Is
there a way to find out which files I have to copy for a specific module to which location?

I understand your point, however this has never worked and there is no spec that this should work, so from my POW it is
an enhancement (even if it worked prior 6.0 as a side effect of more or less mistakenly listing 3 concrete localizations
in update_tracking).

Regarding the workaround:
I agree that it is not particularly simple to put together, so here it is for your convenience. Specify your desired
locale in your suite's nbproject/project.properties, e.g.:

    locales=de

And override 'build-zip' in your suite's build.xml, like this:

    <target name="build-zip" depends="suite.build-zip">
        <pathconvert property="l10n.files" pathsep="&#10;">
            <pathfileset>
                <path refid="cluster.path.id"/>
                <selector refid="zip.platform.included.files"/>
            </pathfileset>
            <mapper type="regexp" from="^.*[/\\](modules|core|lib)([/\\]ext)?[/\\]([^/\\]*)\.jar$"
to="**/\3_${locales}.jar"/>
        </pathconvert>

        <tempfile property="l10n.filter" destdir="${basedir}/build" deleteonexit="true"/>
        <echo file="${l10n.filter}">${l10n.files}</echo>

        <tempfile property="temp.dir" destdir="${basedir}/build" deleteonexit="true"/>
        <mkdir dir="${temp.dir}"/>
        <copy todir="${temp.dir}" failonerror="false">
            <pathfileset>
                <path refid="cluster.path.id"/>
            </pathfileset>
            <mapper type="regexp" from="^.*locale[/\\][^/\\]+_${locales}\.jar$" to="${app.name}/\0"/>
        </copy>

        <zip destfile="${dist.dir}/${app.name}.zip" update="true">
            <zipfileset dir="${temp.dir}" prefix="${app.name}">
                <includesfile name="${l10n.filter}"/>
            </zipfileset>
        </zip>
    </target>

I tested it and it seems to work, let me know if you encounter any problems. The target is a bit hacky and may break in
future versions of platform harness, but then hopefully RCP app localization will be more properly supported.

As VOC meeting [1] will be necessary define some spec about how IDE should work in this scenario. When we have this spec 
probably we can implement this maybe by NetDEV or NetFIX program developer.

Regards
[1] http://qa.netbeans.org/processes/voc/chats/transcript_090821.html

*** This bug has been marked as a duplicate of bug 133901 ***