Hi David.
I just started to review your commit:
http://source.jalview.org/gitweb/?p=jalview.git;a=commit;h=4cea7a0328724b90a6a7c16ae8c926e0cc12cedd
I'm afraid it's really too big for me to review quickly, and now it's been pushed, there isn't much that can be done, except withdraw any of the patches in subsequent commits, which always looks a bit ugly in the project's source history. I guess that can't be helped this time, but I think we can do better.
As a general strategy for future commits, please get into the habit of committing much more frequently, rather than do several hours of work and commit all the lines in one go. I'm sure you know all this, but I thought it worth repeating anyhow.
Please also use an informative commit message ... '(basic i18 support)' is not enough, you actually need to explain specifically what you did and/or why you patched the code.
More specifically:
* if you used an i18n refactoring tool to replace bare strings with new i18n lookups for a set of classes in a package, say that (and include the package name).
* if you changed GUI logic in order to allow formatted i18n messages, say which part of the GUI was affected
* do not combine i18n changes from different parts of the GUI into one commit unless they are directly related (e.g. an identical bit of code and keys used in all GUI elements).
Generally, a commit is too large if you can't come up with a short sentence explaining the where/what/why of the commit (in the context of the JAL-XXXX issue).
If you have got lots of changes, then use an interactive commit tool to select specific hunks that relate to each other (e.g. applying i18n string extraction to a particular window, and then committing the updated GUI code and the new keys added to the Message bundle). Eclipse isn't particularly good at this type of commit, so I'd recommend you try using 'git gui' from the command line, or download Atlassian SourceTree (or if you have a Mac, try GitX, which is far simpler and about as good !).
One final thing to remember: commits should (wherever possible) not introduce compilation errors, and the compiled system should be more or less functional. If you have a series of interdependent commits, then it should be obvious from the commit message (one or more common JAL-xxxx ids, etc).
It is *extremely important* that you get into these habits, because otherwise, it takes me much longer to review your work, and it makes it much harder to identify new bugs introduced from your commits.
apologies if I sound hectoring ! Writing this email has prompted me to begin documenting the coding guidelines on the wiki 
Jim.