The roads I take...

As bug 286110 states, we're working on getting the so-called "source L10n" approach working for SeaMonkey. This means that in the future, we want to be able to build localized SeaMonkey builds directly with localized strings taken from a mozilla.org repository, just with checking out the right l10n/ dir (usually via MOZ_CO_LOCALES) and adding the --enable-ui-locale configure switch.

We're planning to support that on the new, toolkit-based SeaMonkey configuration dubbed "suiterunner", and I have had "my" German suite localization in the tree for testing purposes for quite some time now. As MailNews locale files are in suite/ now and mozldap is as well, I tried building a German suiterunner test build this way recently, and the results look pretty good: A de.jar is placed in the chrome directory, containing almost all needed locale files that previously were in en-US.jar. That latter JAR file is mostly deserted in such a build now. We still need to sort out the few files that are left there though: P3P, for one, will be removed soon (I hope), wallet should get replaced by satchel, so those two are no big issues (and just turn up in the wrong language anyways). Files that lead to XML errors and breakage in the UI because they're not available consistetly in the selected language are the bookmarks UI files, for which I filed bug 377799 now, as well as global-platform/win/nsWindowsHooks.properties and global/typeaheadfind.properties are still there, we should get those out of global and somewhere into suite/, for which I filed bug 377801 due to this round of testing.
The built-in extensions like Reporter, DOM Inspector, ChatZilla and venkman stay untranslated for now, they can be cared about once the main suite works.

The good thing is that apart from those small issues, source L10n is about to start working for the toolkit-based "suiterunner" SeaMonkey builds on trunk.
Finally, an easier solution for localizers gets in sight also for the reborn suite application