Internationalization strategies for Java?

Somehow I've gotten myself deep into migrating AppleCommander to be internationalizable ("i18n-able", I suppose). Not completely sure how I got here, but I am and I think it would be pretty neat to have an internationalized application.

[For those unfamiliar with this, this is accomplished with a Java ResourceBundle. This is a simple text file that contains keys and text strings. By having differently named text files, different text strings can be used by the application. I speak American English, so the keys will be in my native tongue. Thus, a key of "WelcomeMessage" would map to "Welcome to AppleCommander!" in the English file while the German file would map to "Wilkommen zu AppleCommander" or something close to that. It's been a long time since I've pretended to speak German.]

Anyway, I didn't want to place all the text into one resource bundle. I don't have anything more logical than my gut tells me it doesn't quite fit. I have kept the AppleCommander domain separate from the user interface. This has worked out in the last year nicely - there have been two command-line versions of AppleCommander released. The domain logic was just incorporated and the GUI version was essentially tossed. That is according to plan. I think that same reasoning supports my i18n intuition.

I'm somewhat surprised that some Googling didn't show other people discussing this. I admit I didn't try too hard, but I'd expect to find something.

I have separate internationalization files for the domain, the user interface, and actually have separated out the compiler piece. It feels a little bit weird, but I'm going to stick to it until I'm proven wrong. (c:

By the way, Eclipse comes through big-time in this arena. If the compiler generates a warning for non-externalized strings, all string literals are marked with a yellow marker. Pressing CTRL+1 gives as one of the choices the externalize strings 'wizard' which lists all strings in the source file. From there life is pretty easy! My only modification is to use my own "TextBundle" wrapper instead of the default Eclipse "Message" wrapper. I wrote mine before I realized there was a wizard, and am sticking with it since it fits my internationalization strategy pretty well.