Problem
- The entire module seems to consist of UI code and alter hooks only... even the batch to enable/disable translatability entirely consists of custom code... really, no API functions at all?
/**
* Tests URL aliases for translated nodes.
*/
class PathLanguageTest extends PathTestBase {
public static $modules = array('locale', 'translation_entity');
function setUp() {
// @todo Rewrite entity_translation module to provide proper APIs.
$edit = array(
'entity_types[node]' => 'node',
'settings[node][page][translatable]' => TRUE,
'settings[node][page][fields][body]' => 'body',
'settings[node][page][fields][path]' => 'path',
);
$this->drupalPost('admin/config/regional/content-language', $edit, t('Save'));
/*
// Enable entity translation for the entity type/bundle.
translation_entity_set_config('node', 'page', 'enabled', TRUE);
drupal_static_reset();
entity_info_cache_clear();
menu_router_rebuild();
// Enable field translation for the body field.
$field = field_info_field('body');
$field['translatable'] = TRUE;
field_update_field($field);
// Enable field translation for the default path field.
$field = field_info_field('path');
$field['translatable'] = TRUE;
field_update_field($field);
*/
}
Comments
Comment #1
sunAlas, the
drupalPost()fails, if there is only one content type configured... in that case, the form does not contain checkboxes for bundles...Meanwhile, I've spent a few hours now in order to get that PathLanguageTest to work, and I'm still stuck in the basic test setup :(
Comment #2
sunI was wrong... the checkboxes are not displayed, because the user needs the additional "administer entity translation" permission. Why is that a separate permission...?
But even after submitting that form, I still don't get the /translate tabs on the page content type.
Comment #3
sunComment #4
sunOne or more of these permissions was the magic bullet to make the /translate tab appear:
Comment #5
sunComment #6
plachIs this still alive? Honestly I wouldn't call this major: we are talking about a couple of functions after all.
Comment #7
sunYes, this is still a problem. Which functions are that?
If we want to make sure that entity/field translation works in D8, then we need to provide solid + simple APIs for developers and test authors, so they can verify that it actually works in tests.
If it's a problem to programmatically make an entity/field translatable, then we can be sure that no one will test that.
Comment #8
dave reidI admit I've looked for and wanted API functions too. Enabling translations for a field via update.php is not fun at all without it. What happens if someone toggles a field switch from untranslatable to translatable and deploys the field settings change CMI to production?
Comment #9
plachWell, the migration that now happens when switching field translatability is going away as soon as all entities are converted to NG, since those always store fields in the original language with the
'und'language code.If I understood the OP correctly, I'd say we need a function doing this:
and one doing this:
The latter should belong to the Field API.
Comment #10
gábor hojtsyComment #19
catchThere's now
ContentTranslationManager. Closing this as outdated.