Am guessing here at subcat.
If zips/nbms of components that will be chosen by user into an installer
come from various RE builds of the packs, then this issue probably does not
belong her but under nbbuild and I can file separate.
What is needed is setup so that when its time for having ml installers, that
there is setup to use ml bits of all nb packs/componenets as well
as ml bits provided bt runtimes.
In past, ml builds were done by RE on each pack/product and installer
gets those and configured ml installer; I dont know if that is still the model
or if nbi does it differently.
But even if RE does it still, maybe this is valid for task of nbi itself setting up
if needed for future ml builds ?
Since it seems there will be langpacks and not ml builds, I'll file separate issue
about that; but if we will continue to have ml builds, we can use this
issue; please let me know which approach will be used.
Well, the process of building ML components (whether they be langpacks or whatever) is still relevant. I'm marking this
issue as a dependent on the langpacks one. It's also incomplete as the details have not been decided.
now I understand more - once RE builds/delivers a given langpack zip for some locale -
then installer team adds logic/data jar files and bundle files within them -and other things - and thats what this
issue is about.
In this case, the bundle files inside the logic,1.jar of the loccalized zip, will need to come from wherever
translation teams are told to putback
the translated files from the installer l10n kit - is this accurate ?
and can that location be the same translatedfiles/src as for
other product translated files ?
I can then get a test installer from a test web page or directly, that has some pseudo localized or even
empty langpack zip from BE, that then has had the en bundle files added to them, and can then
pseudo localize those bundle files and do early testing.
of course, the r
see nbbuild 98676 for the BE part of this.
now that there will be no langpacks for nb6, the tasks of this issue would be just
to get the one ml zip or zips (if by component)
and do the same tasks for that as described in this task.
I think incomplete keywd is still valid since not yet know about if one zip with all locales
or multiple component zips with all locales in each.
Close the task as fixed. The setup for handling ml runtimes (glassfish) was done for 6.1.