Maybe it would make sense to only enter the language as message key instead of the full locale in the database if a message should be valid for all locales of that language, and enter the full locale if a message is only valid for one locale. In messages for which both a language-only and a full-locale entry are availabe, the full-locale entry would then override the language-only one (if it matches the specific locale that you are querying for).
I am sure that if it is stored this way it would be possible to write a smart query that does: "select all message keys with language en but prefer en_US if available" for en_US in this example. You could even add a "and if a message is only available in en_GB then I want it too in my resultset".
This way the initial translation could be generic for one language, and as soon as someone feels the need to localize it that can be done by adding the dialect variants.
The insight of someone who has experience with the way this is handled e.g. in GNU gettext would be a valuable input here. Or you want to look through this http://i18n.kde.org/, looks promising.
