Closed (cannot reproduce)
Project:
Drupal core
Version:
8.9.x-dev
Component:
content_translation.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
30 Jan 2013 at 06:24 UTC
Updated:
18 Dec 2020 at 08:48 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
webchickMore accurate.
Comment #2
plachYep, 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.
Comment #3
plachComment #4
webchickOk, 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.
Comment #5
webchickAlso, tagging Usability since they may have an opinion on the approach used here.
Comment #6
plachYes, we definitely need UX folks here.
Comment #7
gábor hojtsyFor 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 :)
Comment #8
plachI 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.
Comment #9
yesct commentedwould 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.
Comment #10
plachWell, 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.
Comment #11
gábor hojtsy@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.
Comment #12
gábor hojtsyComment #21
quietone commentedI tested this on 8.9.x and was not able to reproduce the error.
On a fresh install of 8.9.x I enabled content_translation, added a language and then ticked all the boxes available at admin/config/regional/content-language, No errors or warning were displayed and nothing in the logs.
The content types that are not translatable have a clear message on the page such as this one for the contact message
