nb pteam decided that all stable UC modules would be localized in the nb5 timeframe.
In addition, jse coco needs some of them for their own UC.
In discussions with NB RE, it was mentioned that it could be best to have
separate l10n kits for these than putting them in same kits as regular nb,
keeps it clearer for l10n, and since different people in l10n might be working
on some modules, since involves both nb and jse.
keeps it clearer as to building localized - since localized of these are
only for UC, not for product
Note 1 - some of the modules on beta UC will be moving to stable UC soon
like collab. Also there is a new one proposed.
Note 2 - as part of discussions with RE about this, it was decided that
a different l10n.list is needed for the UC only modules in each applicable
cvs, ie cvs that has code for both uc only modules and product modules --
otherwise the regular l10n kits would get uc only files and visa versa
and would also impact building of localized product jars vs localized UC nbms
--- so this would need to be done in parallel with this issue by developers.
Could we raise this asap to dev mgrs or pteam ?
Also, would there need to be a separate "uconly_translatedfiles" dir set up where
l10n would put back these translations for these UC only modules, since if in
the existing translaltedfiles, it would mix, for some modules, files that
are meant for the product vs for the uc only nbms ?
And then the build scripts could be set up to build these loclaized nbms
and assume they would be in same place on smetiste as en ones
(I dont know if localized nbms would live in own zip or same as en
since we have not localized nb nbms before, and I think it depends
on overall UC policy.
changing to version 6.0; this was not able to happen for 5.5 or 551.
same requirement as before - a separate l10n kit for stable uc modules, that will
be accuarate at certain points in time, such as when new module comes to stable uc,
or when a module leaves it.
RE implementation of 101067 - comments about it said that the new process could
be used to make a separate uc kit without developer involvement
(except I am assuming that they do their part of having needed
include/exclude special l10n.lists if needed; see spec of 101067
in other words, developers do not need to do anything else, and it will be assured
by RE process that
a. the uc kit will be correct at any point in time
b. the uc kit will have no product files
c. the product kit will have no uc only files.
NOTE - part of requirements for a nb cvs module going to stable uc is to notify RE about it
so that its files can be made part of uc kit.
---> RE, please confirm about assumptions above.
what is the process for how BE will know when additional modules will be on nb6 stable uc that will be translated
that they will need to add the translatable files of those modules to this uc kit ?
(or to add modules already on nb6 stable uc that are not yet in the kit)
or to remove modules that are in kit that are not on/will be on nb6 stable uc but might be on nb5/551 uc ?
I realize it can be a moving target but I think part of the solving of this issue is also about handling above questions.
Thanks - Ken