Max Rydahl Andersen wrote: So, if I understand correctly, trunk is still frozen for new work? Will the GA release will eventually happen from trunk, rather than the CR branch? Does that mean that the CR branch is not really a Candidate for [GA] Release? Why not call the branch the 3.0 branch, to be used for stabilisation/bugfixes now, and eventually to become the 3.0 maintenance branch? I guess I'm having trouble understanding the conventions of trunk/branches in this project. Perhaps there is a wiki page to cover this sort of thing? Do I need to hold off on string externalisation (JBIDE-3557) until after GA? I don't plan to break the trunk build (who does?), but even small changes need QA before release. (If you're just saying not to make architecture-breaking changes in trunk, then that's different.) Thanks Sean. -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat

Max Rydahl Andersen wrote: Couldn't you just use the "CR" branch for that? (By another name, preferably.) I don't really understand what changes would go into trunk but not into the branch. If the answer is "no changes", then the branch is redundant at present, is it not? Or are you saying there are issues which we intend to fix (in trunk) for GA, but not for the the CR? So far, excluding the "i18n" folder, everything I've done has been simple string externalisation, nothing *big*. Just lots of small changes. Looking at the changesets, I haven't checked in any .java changes. Even so, it may not be 100% safe, since I had to do most of it by hand (no wizards for some things). As much as possible, I have tried to smoke-test them in the GUI, but it's difficult to test every string when you don't know the GUI inside out. Most of the remaining externalisation will be the easier, wizard-driven type, except where I have to introduce MessageFormat. However, once I start externalising entire plugins, rather than targeting individual strings from the GUI, comprehensive testing will become much more labour-intensive. Is 18n a feature, or are unexternalised strings bugs? :-) -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat

Max Rydahl Andersen wrote: Okay then. Well, so far I haven't been working by plugins as such. I've externalised strings in all the manifest files, thanks to the PDE wizard. I also manually externalised strings I found in the Preferences GUI (whereever I found them in plugin.xml or .java code; various plugins) and a couple of other GUI aspects (Views and menus, from memory). Nothing really comprehensive, but I wanted to clear up the worst of the GUI-visible stuff. (I do plan to process the plugin.xml files more systematically by converting to Pyx format and applying a hideous-but-helpful grep to find anything which looks like English text.) I have made a small start on plugin-by-plugin externalisation of the code (using the Source/Externalize Strings wizard), but I haven't checked any of it in, and I've stopped doing more because of the code freeze. Short answer: none of the plugins are "covered" fully. -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat