Then we could have a few core modules, that may be:

• locale, where we keep the the full functionality and interface for string management, and import/import of full translations or 'language packs'.
• i18n, which would handle the interface for maintaining and creating languages, and would be needed, in general, when more than one language is needed across the site, managing languages in the URL, and providing a block to switch language, etc...
• multilingual -content-, that would be a fully reworked and lightweight version of current i18n module, and would provide only some support for content types to be multilingual, like a language field for selective content types or for taxonomy elements. This one should be also responsible of joining language conditions when selecting content from the database.

Notice the distinction between having the site in a single language other than English, that should be managed by the core alone, and having more than one language enabled, for which we'd need at least the i18n module.

The support for multilingual variables, which is a very basic requirement of any multilingual implementation would be in this new i18n module, provided there are some spceficic hooks in the core functions for variable management.