Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Currently for example the frontpage view shows just nodes of the current language, which is fine, unless you have entities which don't have a defined language, which could for example
happen somehow if people manually create entities via the API.
Proposed resolution
Not only show the current content language entities but also the ones undefined ones.
Comments
Comment #1
Gábor HojtsyEntities created with the API should have the default language applied properly as of #1966436: Default *content* entity languages are not set for entities created with the API. The use case of "entities with no language" is very narrow and it is highly unlikely the front page would have such nodes? What's a use case for a node that has no title or other textual field and only has language independent content to show on the front page?
The idea in D8 is all entities (content, config, etc) have a language assigned if at all possible. The use case for entities without a language is limited to cases where it was an explicit choice.
Comment #2
dawehnerMh okay, berdir suggested that we have this kind of fallback. I think people might accidentally create these entities so it wouldn't really harm anyone to also show them, wouldn't it?
Comment #3
Gábor HojtsyBTW #2333731: WebTestBase::drupalCreateNode() should not hardcode default values would fix tests so they test the assumed default behaviour instead of opting out of language on nodes in tests.
Comment #4
Gábor Hojtsy@dawehner: Crossposted. Unless someone explicitly specifies und, they cannot accidentally create nodes in und. Not even in tests thanks to #2333731: WebTestBase::drupalCreateNode() should not hardcode default values. I don't think its a good solution to make those nodes appear on the front page, that would just postpone figuring out that people did something wrong.
Comment #5
BerdirJust because entities are created with en by default doesn't make it is not possible to have it. We have that option in the language selector for a reason?
It makes perfect sense to me to show them on the frontpage. If I check Promoted, then I expect that node to show up there, no matter what language I select. There is no risk for duplicates, as they can not have translations.
Comment #6
Gábor Hojtsy@Berdir: apart of "why not" what is the use case for such nodes?
Comment #7
dawehnerWell the point is that it is an implementation detail that entities are saved as 'en' by default and we should try to not rely on implementation details, unless we have to.
It could easily happen that people actually choose to think that 'en' is not the value they want and booom entities don't appear anymore.
Comment #8
Gábor HojtsyErm, not really. Only configured languages may be results of language negotiation. Only configured languages may be used as translation targets in interface translation. Config and content entities can only be translated ever if they have a configurable language (not und, zxx or any other locked language that may be on the system). In the language system the non-configurable AKA locked languages are the outliers that you would use if you had absolutely no better idea. You may be used to Drupal 7 sites where there are lots of unknown stuff but that was due to bad defaults. I think Drupal has some responsibility to lead people to best practices. One of the great achievements of Drupal 8 is now whatever content knows to the field level its language(s). If users are to create whatever content without language information (which we know would lead to issues down the road when they attempt to export them as a web service, when displaying language metadata in the HTML, when serving them in a feed, when migrating to a multilingual site, etc) then making it appear like its all OK and part of the default behaviour not to stop that out of the gate is IMHO a bad idea.
We want people to assign actual languages to things whether for accessibility (so screen readers know which language reading to use), bots (so machines, your built-in search service, eg. solr knows how to stem, index, etc), and so on. Its not like you decide on a whim to use 'und' for fun and there are no repercussions. If we know the user is going down such a rabbit hole, should we stop it happening as soon as possible?
What's the use case?
Comment #9
BerdirSorry, but I disagree :)
It's not even an implementation detail, it's a configuration option.
It is perfectly valid for some content to not be language specific. We offer this, we even offer to set certain content types to not applicable or not specified by default. Why should we dictate our users to not use those codes?
This won't hurt anyone who isn't using them, the performance impact of a = 'en' vs. a IN ('en', 'und') should be minimal. But there is no reason to force-hide them?
Comment #10
Gábor HojtsyAll right. I don't agree with this, but I won't stop it from happening.