This was suggested several times: one, two (see dropcube's comment, not hotlinkable), and most importantly a whole discussion thread started by Jose Reyero at http://groups.drupal.org/node/151169#comment-507464.
The basic problem here is that strings are stored in the source code of Drupal projects, so (a) they all need to be written in English (b) when they are changed, all translations for those specific strings become obsolete (c) when you need to override them for English sites, you need to act as if you are translating the site.
The suggestion is to replace the strings themselves with keys, like
<?php
string('mymodule_hello_world')
?><?php
some_function('user.login-form.username.label');
?>There are various advantages to "externalizing strings":
(a) the module can originally be written in another language and can be later translated to English
(b) small changes like typo fixes will not invalidate translations
(c) no code patches required to change strings (or maybe yes, see below)
(d) code size will go down in some cases
However, there are a sizable set of disadvantages:
(a) you need to make up the string IDs for your module, how do you do that for a hook_help() which can have tens of strings? or a form definition or hook_form_alter() which can again have tens of strings?
(b) it reduces module readability because you cannot look up the strings in the module, you need a two step process to find where a string is used; it also disconnects placeholders from strings, eg.
<?php
string('user.login-form.username.link', array('@user' => $account->name))
?>(c) it slows down all language sites (while English worked best performance before), because you need a string lookup for English too
(d) We'd also need to figure out how does this play with database based editability of translations. Jose suggests module authors would get their initial strings imported in the db on install time, then they'd need to write update functions for string changes. Sounds like more complex to change things.
(e) if the translations are tied to modules, we loose the sharing feature of Drupal which worked fantastic in some cases, but did prove to have issues in others (for which context could already work)
To be honest, I'm not sure either way. We have a system which has its disadvantages, and we know them well. Also, the same system is used by other CMS like eZPulish and Wordpess (not necessarily the exact same file formats and processes, but the original English key based translations). On the other hand, string externalization can solve some of the problems of foreign language module developers and translators. Maybe we can somehow get the best of both worlds? Discuss!