sweet, thanks for your post bernat!
the "translations"-tab contains mostly global settings, but its positioning inside the specific page implies a page-specific setting. (e.g. can i set the default language on a page-by-page basis?). the lack of a global settings UI is a generic silverstripe problem. tim/bernat, do you have any thoughts on this? doesnt necessarily have to be resolved now, just wanted to point this out as a usability issue.
i dont think we need an interface for adding a new "site language", in the rare case you come up with something like "klingon language" that we havent covered in the dropdown, we should have some _config.php-setting instead. otherwise we need a separate database table to store newly created site specific languages, which confuses more than its worth.
@tim: putting fields side-by-side requires a higher screen resolution, especially when working with more complex fields like multi-column tables - users might end up having to scroll even on 1280 res to compare original with translation. also, it poses quite a challenge in terms of CSS-layout (silverstripers might remember how we struggled with the same problem in the "inform fact finder"): e.g. if the field label of the translation is omitted, it is very hard to keep fields aligned, because we're using linear divs rather than table-rows.
its probably a good idea to somehow mark the framed original fields as showing the "default language", as not to confuse users which field actually contains the translation (and is editable).
i'd also prefer a way to set the currently edited language outside of the translation-tab, as its more a "global switch" that wouldnt be expected in the tab. tim proposed a setting in the (always present) editor toolbar. alternatively could be laid out like the "page view" tabs below.
