Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 98676 - I18N - request to get setup for ml builds of all packs/components on RE queue
I18N - request to get setup for ml builds of all packs/components on RE queue
Product: www
Classification: Unclassified
Component: Builds & Repositories
All All
: P2 (vote)
Assigned To: rbalada
: I18N
Depends on:
Blocks: 118390
  Show dependency treegraph
Reported: 2007-03-22 15:43 UTC by Ken Frank
Modified: 2007-12-13 17:51 UTC (History)
0 users

See Also:
Issue Type: TASK


Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2007-03-22 15:43:01 UTC
This is just to get the setup for building of ml installers on RE queue -
since nb6 is all aligned with all packs/components going out at the same
time - can this one issue cover that for all ? 

I filed 98586 on nbi relating to ml regarding the things they do,
but they mentioned that the actual installers are obtained
from the different RE builds of nb, mobility, hula, vwp, etc.

I realize that we wont need ml builds/installers for some
time, but just wanted to get the task on official RE queue as a better
way of communication -- is this kind of request in an issue better for RE
vs separate mails ?  If not, I can close this for sure.
Comment 1 rbalada 2007-04-17 16:32:28 UTC
Changing to TASK. ML builds setup would natural step after component build
consolidation. Targeting for Milestone 11 for now.
Comment 2 Ken Frank 2007-06-05 14:58:28 UTC
Instead of ml builds as in past, there might be language packs, in which user will
be able to choose which locale(s) they want installed.
I think it would mean for each built component, there would be a separate kind
of ml component file/zip delivered for each of the locales, rather than
the way we have done of one ml build  file/zip with all locales in it.

Decision about having lang packs and details is still under discussion
Comment 3 Ken Frank 2007-07-20 21:07:28 UTC
decision about langpack was made by pteam; there will be one langpack zip per locale, not per component.
that is, the langpack has all nb6 localized files for that locale.

even if user installs not the full build, the additional localized dirs/files will still be installed for the
locale the user chooses to install (choice will be offered on installer web page and in installer itself.

1. for early testing, having even an empty langpack  for a few locales (with one file if needed) will be helpful since
that will allow installer team to add their own config files to it (logic,1, data,1 jar files, just as is done for en
components) -
this will allow installer ui and logic to be tested as well as does it install the correct locale langpack based on user

2. next step will be to get l10n kit and put back pseudo translated files to translatedfiles/src, so more accurate langpack
can be used and given to installer, so that additional testing can happen.

---> Can the basic implementation be started soon, so that we can move to step 1. for early internal testing ?

see installer issue 98586
Comment 4 Ken Frank 2007-09-12 20:29:44 UTC
Can there be setup some dummy localized files for at least one locale in translatedfiles
so at least there will be some files to use to construct these ml zips per locale ?

I won't be able to get kits and translate and put back to translated
files since nb6 is so large.

another problem is that l10n kits dont need to be completely accurate
until a few weeks after this issue is needed to complete on 10/1.
(but I'd like to verify it a few days earlier)

but if there was a list of files/locations of the files that would
be put back, or if perhaps each file in kit would just be renamed
if needed to it locale suffix name and put back ?

even if some missing files as long as enough to build each localized
jar would be ok.

and unless profiler has moved to nb cvs by this date, those files
could be missing, since am assuming the kit will eventually have them
and that translated ones will be putback to nb cvs translated files.

that would allow at least the ml zip to be built and verified
that its  accurate at least as to number of en vs ml jars.

--> do you have any ideas about this ?
Comment 5 rbalada 2007-09-27 21:58:33 UTC
I'm working on NB 6.0 multilangauge build implementation. Reassigning to me.
Comment 6 Ken Frank 2007-09-28 03:04:22 UTC

pseudo files for all 3 locales have been put back to translatedfiles/src to give something to build;
this is what we have done in the past.

I know l10n kit not yet completely accurate and not need to be yet, but i hope that at least what is putback
will allow building of all needed localized jars, but i realize some may not be built if all files needed
for some jar are not there.

profiler stuff is not put back since it has not yet come to nb cvs and thus not yet to kit
(profiler.tar in kit is old standalone profiler docs only and is not in product anymore).
Comment 7 rbalada 2007-09-28 09:08:18 UTC
Ken, thanks for the dummy data, it helps a lot.
Comment 8 Ken Frank 2007-10-11 19:47:32 UTC
as per 71985, gui sample project uses a readme in nb6.0/docs - do they need to provide
BE info about this as part of building ml jars ?

if so, can you add info to that issue; I asked about it myself in the issue but did not
get an answer.
Comment 9 Ken Frank 2007-11-08 16:50:18 UTC
I think this can be resolved - I am verifying accuracy of ml build and
communicating with nb-re about it in mail and they have fixed all known
problems to this time; only remaining problem is result of some missing
file in kit due to dev not adding it to list; and dev is working on that part.
Comment 10 rbalada 2007-12-13 17:51:28 UTC
Resolving FIXED. Partial build system updates on demand.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo