Posted by webchick on January 30, 2013 at 6:24am
7 followers
Jump to:
Issue Summary
If you enable the translation_entity module, go to admin/config/regional/content-language, and check all of the boxes there you'll get the following two errors:
At least one field needs to be translatable to enable Website feedback for translation.
At least one field needs to be translatable to enable Tags for translation.Tags and Contact categories do at least have a "title" field, so I'm not sure what it's barking about (I guess because they're not "real" fields), but in any case it seems like we should not be offering people options here that they cannot actually use.
Comments
#1
More accurate.
#2
Yep, exactly :)
Well, once we complete the migration to the Entity Field API, labels will be translatable hence this specific problem would disappear. However this might not always be the case, since the may actually be entity types where no field can be enabled for translation, hence we need to account for that. OTOH the language settings would still be there, so I guess we need to just avoid defining the translation settings (or gray them out), not sure about this. Perhaps we also need a warning message or something similar.
#3
#4
Ok, if this is just a temporary state, then this just comes down to a bit more robustness in generating the form, so downgrading to normal.
#5
Also, tagging Usability since they may have an opinion on the approach used here.
#6
Yes, we definitely need UX folks here.
#7
For taxonomy terms #1498660: Refactor taxonomy entity properties to multilingual is the issue to introduce translatable properties. That is being held up by the Entity NG conversions (currently focusing on nodes). This is targeted to get ongoing focus through the integration phase of Drupal 8's cycle. For contact stuff, if those are stored content entities now (?) then they should have their Entity NG conversion as well with their property conversion following :)
#8
I was wondering that too: I didn't see a storage controller for contact messages so I guess we should mark it untranslatable as soon as we sort #1446382: Need a reliable way to determine if a specific bundle for an entity type is translatable out and avoid listing it in the settings page.
#9
would it still have language settings, but not translatable?
(language and translation settings are both on that same page)
Also, I believe I noticed while testing that if go to the entity itself (like taxonomy vocabulary) can enable translation even though there are not fields that can have translation enabled. Then that causes problems when coming to the nice language settings page.
Can we allow entities to be marked translatable even if they do not (yet) have fields that can be translatable?
Or... we need to add the same check in the other place where the entity is.
#10
Well, if contact messages are not storable there's no sense to specify a language for them I guess. We probably need a generic API to tell if an entity has multilingual support.
And yes, we need the same checks in both places.
#11
@YesCT: in terms of vocabularies *themselves*, they are config entities, so they are not translatable with this system (and do not show up for configuration). For taxonomy terms, they are content entities and should get their properties translatable in #1498660: Refactor taxonomy entity properties to multilingual. It is still very much possible that there are content entities that do not have language/translation support.