Why not set a specific language instead of LANGUAGE_NONE (undefined) in monolingual sites?

[klonos]

5498 brought me to #903, which at the time it was committed I could not understand. Now that I know more, I have to ask: why not be setting the language to whatever the language that the site was originally installed is? If additional languages are added in the future, the language of existing content/aliases would need to be updated anyway (because none/und will not be technically true then).

From #903:

The reason for this behavior is because the url_alias table will contain two aliases pointing at the same node. One is for "und", and the other is for "en". The latest alias in the table (regardless of langcode) will be the alias used in the URL. While the langcode that matches the node will be used in the node form.

That sounds like a bug that we should fix - it shouldn't be a reason to propagate something that is technically inaccurate. Right?

All of this is due to a shift in the way nodes are created by default on a single language site:

• Drupal 7: All nodes are LANGUAGE_NONE in a single-language site.
• Backdrop/Drupal 8: All nodes are the default language in a single-language site.

Right! Seems to me that Backdrop/Drupal 8 are doing the correct thing 👍🏼

It seems to me that node_update_1010() should be removed, and that we should add a new update hook that fixes things for monolingual sites that have already been upgraded to Backdrop. If that breaks things (because we have been doing the wrong thing - in order to accommodate the change in node_update_1010()), then we should also fix all these broken things.

My point is that even in monolingual sites, everything should have a language, because:

• There is no reason/point to be striving to be language-agnostic when there is only one language. Pretending that there is no language in that case is technically inaccurate.
• "undefined" as language only makes sense once there is another language added to the site, and even then it is there in order to accommodate for a very specific use case (AFAIK): to denote that a specific thing (piece of content, alias etc.) does not have a specific language ...which should be better phrased as "applies to all languages".
• Any monolingual site is potentially multilingual at any point in the future. When/if that happens, the assumption that the single language the site started with (and with which all existing content has been created) is "undefined" is technically inaccurate, and it will cause issues.

...unless we make sure that when a second language is added, we go through all content/aliases etc. and update them to actually have a language.

[klonos]

https://docs.backdropcms.org/api/backdrop/core%21modules%21node%21node.install/function/node_update_1010/1

  // Because this update may adversely affect sites that once were multilingual
  // but are now mono-lingual, we only apply if we're absolutely sure only a
  // single language is used, both in the configuration and in the node table.

Can someone please explain that logic ^^ to me? Why are assuming that there may be previously-multilingual sites that have been converted to monolingual (and how do we accurately and with absolute certainty tell that?), and why are we not considering how this may affect sites that start as monolingual, but may at some point in the future evolve to be multilingual?

Also, what is "adversely affect" referring to? Can someone provide one or more use cases where there is an actual problem? (that cannot be solved while at the same time making sure that a language is specified)

[argiepiano]

I'm not arguing with your reasoning, but just want to point out that, as a coder who has written many custom modules with forms for my sites for several years in D7 and now, porting them to Backdrop, if we proceed with the change you are proposing, all my modules that access fields -- you know, the usual field_name[LANGUAGE_NONE][0]['value'] -- in all my form submit and #default_value etc, etc, etc will now be broken. And this would be really bad.

What is to gain by this change? Unless I'm misunderstanding...?

[klonos]

To clarify: I'm not proposing that we arbitrarily change things without careful planing. See how I also said "If that breaks things ..., then we should also fix all these broken things."? ...what I meant was that we should make sure that the change is as "transparent" as possible, and as backwards-compatible as possible. We're all a smart bunch I trust, so we'll figure things out; I'm sure 🙂

[laryn]

In general it seems to make sense to tag content to the language it is, I agree. But, one thought to add on current/default functionality: if you have a monolingual site and then add a new language, at the moment all existing content (und) will show up in both languages. If your monolingual site specifies a language code for all content and then you add a new language, you'll see a completely empty site when browsing the language-specific URL. (This particularly comes into play when you are adding translation capability but only plan to translate a small number of specific pages and use the default content for everything else -- once you flip over to one of the few translated pages the site tries to keep you on the second language version, which will show nothing for most of the website.)

[klonos]

Thanks for chiming in @laryn 🙏🏼 ...the scenario/situation you describe is a perfectly valid one, and it could end up in undesired behaviour. However, I was under the impression that we provided an option to fall back to the site default language (original language the content was created in) if the content was not yet translated to the language being viewed. Right? If we don't provide that option, then we should.

So this seems like a workflow issue to me (making some assumptions for now - I will need to test how the defaults are configured in Backdrop OOTB). Consider the following scenarios:

• scenario one:
  1. install the site with a single language
  2. add content of that language
  3. decide you need either another language or more, and add it/them
  4. the fallback option is not enabled (either because it's not the default behavior or because you have intentionally configured things to be that way)
  5. you get into trouble with an "empty" site for the language(s) w/o translated content 👎🏼 your content editors/translators are in a rush to translate things 👎🏼
• scenario two:
  1. install the site with a single language
  2. add content of that language
  3. decide you need either another language or more, and add it/them
  4. the fallback option is enabled by default
  5. your content editors start translating the content at their own pace 👍🏼 ...in the meantime, pages fall back to the default language for untranslated content - no "empty" site issue 👍🏼

How we could improve things further in the second scenario is if we displayed a "not translated yet - content shown in its original language" message if we fall back to the default/original language.

[indigoxela]

Personally, I'd vote for LANGUAGE_NONE. I have both, monolingual and multilingual sites and the language neutral approach causes less work.

[laryn]

This is a related setting provided by i18n:

[klonos]

Thanks @laryn 🙏🏼 ...I haven't used i18n in a while, so I wasn't aware (or had forgotten) about that option. It's a bit confusing why the default option is not also the recommended 🤔

...the language neutral approach causes less work. @indigoxela can you please elaborate on that with some examples please?

[indigoxela]

@laryn pretty much describes the use-case:

This particularly comes into play when you are adding translation capability but only plan to translate a small number of specific pages and use the default content for everything else.