Judging by the low number of comments (zero AKA nil) on my post on how custom user editable data in Drupal 7 modules are now localized and my commentary and Drupal 8 proposal there, I've decided to reformulate the basics of the ideas explained there with more of a focus on high level architecture questions. Since I have not seen any planning yet on the UI of configuration for Drupal 8 (while the underlying configuration storage and handling discussions happen actively), but the UI portion is very important for the multilingual initiative, I'm cross-posting there too.
There are 14 submodules in the Drupal 7 version of Internationalization (see http://drupalcode.org/project/i18n.git/tree/refs/heads/7.x-1.x). Most of these modules do one or both of two things: (1) implement field-like features for certain Drupal core objects (2) implement entity-relation-like features for Drupal core objects. There is also a (3) which is providing APIs for other contrib modules to do (1) or (2) for their objects. But the code required there is so big that full modules like i18n_views exist to connect the views API with the i18n APIs. Why is it so big?
Fields for all of configuration
Drupal configuration is now done in all kinds of custom ways. Your blocks, your menu items, your contact module categories, your site name all stored in different places, edited in different forms, and so on. For those to be translatable though, i18n module needs to re-implement common pieces of field API. We need a way to mark "translatable fields" on each object (site settings, contact forms, menu items, etc). Then we need to be able to display the translatable fields in a form (using their "widgets"). Then we need to validate these fields with validation that makes sense for them (taking into account text formats and any custom validation that might apply). Then we need to store them somewhere. And finally we need to tie in to their "formatters" and use the right language value when display happens. Right, these are all fields concepts, and i18n module needs to implement all these for "object properties" such as site name, views empty text, menu item title or block body to be translatable. What's worse is that not only these use non-fields for form/validation/storage/display, they all use totally different systems for form/validation/storage/display. So we need pretty sizable code to tie the custom form/validation/storage/display to i18n's reimplementation of parts of the field API. (See http://groups.drupal.org/node/152929 for explanation of that API in Drupal 7 and many of its weaknesses).
All of the 4 aspects of fields re-implementations (widgets, validation, storage and display) have limitations as a result, i18n can only support text based field input, no custom widgets, its validation is very limited and sometimes not good for the field type at all, its storage is central (currently uses the locale backend, which is not at all ideal), and most Drupal modules don't let others to hook into display of these object properties, so i18n has a hard time to override all display of these "fields".
Now imagine if all of these configuration pieces would use fields. We could leverage the core built-in field translation features. Because fields have self-contained widget, display and formatter information, and formatters are actually used when the field is rendered, we could reproduce an equal input environment for translation like the original object, validate the value proper and use proper rendering to display it.
Woah, you might say, using fields for configuration is way overkill. Well, i18n module already does it. It needs to work around lots of Drupal limitations but it does need (almost) all the goodness that fields have to offer for these object properties, so if core does not do it, i18n needs to do it anyway. Of course now i18n uses a small subset of fields functionality and uses an entirely different API to do it, but the concepts stand. In fact to solve its bugs, it would need to re-implement much more of fields for these object properties. My gut feel is that now about 60% of i18n module is about this, and it will be a lot more if we need to work around core. Also, a contributed module like i18n can only do this in broken and awkward ways by definition.
Entities for all of configuration?
The other major thing that i18n module does is it supports translation relations of things. Like Drupal core does with translation module for nodes, but i18n module introduces a more generic "translation set" concept, that can relate things to each other as being translations of each other. This works for menu items, taxonomy terms and paths. You can mark 'node/5' a translation of 'taxonomy/term/sunscreens', so when you hit the language switcher on either, it goes to the other one for the appropriate language.
This feature should obviously be extended to blocks, views, etc. so yo can relate different items to each other as being in a translation set (for the cases when you need multiple copies). Now i18n module implements a framework that can relate arbitrary things, so there is no requirement for these to be entities. For configuration in general, @sun explains that we'd not need entities for configuration if we abstract off of Field Attach API: http://drupal.org/node/391924#comment-4575050 but he proposes that we can skip implementing something like entities for configuration that are equally fieldable if we just use entities.
Discuss!