This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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, since 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. ken.frank@sun.com
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. ken.frank@sun.com
see http://deadlock.netbeans.org/hudson/job/l10nkit/
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 ken.frank@sun.com