I am working on the Content Migrate module to migrate field data from D6 to D7. Many things are now working nicely but I have a nasty problem that has erupted in various ways around what value to use for the 'language' in the fields that are migrated. Here is what happens on a fresh D7 install, without migration: - If you create new fields in the UI, all every field is created with the flag 'translatable' set to TRUE. There is no apparent way to create a field in the UI that has 'translatable' set to FALSE. - If you create new fields using field_create_field() 'translatable' is set to FALSE, unless you explicitly set a value for 'translatable' and set it to TRUE, This looks like a bad idea, having opposite defaults for the two methods of creating fields. So any process that uses the API to create fields will create fields that are inconsistent with fields created in the UI, unless it follows the UI pattern of forcing every field to be translatable. Plus every process that creates fields programmatically has to explicitly set that value to avoid unexpected results. Core has already been bit by this confusion -- the migrated node body field is marked as translatable but the migrated comment body is *not* translatable. Plus there really should be some way for a field weigh in on this. Things like number and date fields should probably not be translatable, but there seems to be no way a field module can control that. I have been trying to sort through the migration issues in http://drupal.org/node/1063852, if anyone wants to help. I tried to see if any core issues were filed around this but couldn't see any. I'm trying to get my head around which of these are 'bugs' and which are just things I have to work around. I do not even use translations myself, so it's very hard for me to be sure I am drawing the right conclusions. I hope someone who does understand the translation system can jump in here.