Could you clarify your issue guy_schneerson? Is the issue that the node does not use localized urls from the node creation and waits for translation and why do you consider that a problem. Is the below account accurate?
nicxvan see #4 for more details

Problem/Motivation

On a multilingual site a node with no translations should default to the en/node/x format rather than node/x (assuming english is the default) Currently when nodes are created they do not receive a language designation:

$path['langcode'] = isset($node->langcode) ? $node->langcode : LANGUAGE_NOT_SPECIFIED;

Proposed resolution

Determine the language at node creation and utilize the localized url at the outset.
Allow for global url (a page that could be used in any language as it is instructional and has several languages already embedded.)

Remaining tasks

Determine feasibility.
Determine if solved already with default language settings in drupal 8 (e.g. using the node's author's language preference or allowing the user to select node's default language)

API changes

Unknown

Original report by guy_schneerson

currently the language used is the one used by the node

$path['langcode'] = isset($node->langcode) ? $node->langcode : LANGUAGE_NOT_SPECIFIED;

However as urls have no fallback mechanism i.e. will use node/x as a url and not revert to the node main language url if one is available.
This is a real problem as until all language translations are created you will have none structured urls (node/x).

The ideal solution is to have this fallback functionality so it is the same as the entity field translation system, use a localized url if one available and if not use the nodes language one if available.

If this is not possible (I haven't looked at that part of 8), it would be good to be able to set urls to All languages (i.e. LANGUAGE_NOT_SPECIFIED), this can be done using a configuration option or at list a hook or drupal_alter() giving modules the opportunity to control this.
This will solve many use cases where it is acceptable to have the same url .e. /en/post-about-multilinguall-sites & /fr/post-about-multilinguall-sites and structured URLs are needed for all nodes.

Comments

guy_schneerson’s picture

Title: Improved integration with multilinguall sites » URL Aliases - Improved integration with multilinguall sites
Issue tags: +D8MI

updating title and tagging

nicxvan’s picture

Could you clarify your issue guy_schneerson? Is the issue that the node does not use localized urls from the node creation and waits for translation and why do you consider that a problem. Is the below account accurate?

Problem/Motivation

On a multilingual site a node with no translations should default to the en/node/x format rather than node/x (assuming english is the default) Currently when nodes are created they do not receive a language designation:

$path['langcode'] = isset($node->langcode) ? $node->langcode : LANGUAGE_NOT_SPECIFIED;

Proposed resolution

Determine the language at node creation and utilize the localized url at the outset.
Allow for global url (a page that could be used in any language as it is instructional and has several languages already embedded.)

Remaining tasks

Determine feasibility.
Determine if solved already with default language settings in drupal 8 (e.g. using the node's author's language preference or allowing the user to select node's default language)

API changes

Unknown

nicxvan’s picture

Status: Active » Postponed (maintainer needs more info)
guy_schneerson’s picture

Status: Postponed (maintainer needs more info) » Active

Hi @nicxvan thanks for your input and help
It may be clearer if I run through an example case

Story

We have a site with English, French & Greek, localized using entity translations (one node with translatable fields) where the Title (using the title module) is set to translatable.

A new English node is created with a Title of "Test" and URL of "content/test:
The node will appear as following:
English:

  • url: en/content/test
  • title: Test

French:

  • url: fr/node/5
  • title: Test

Greek:

  • url: el/node/5
  • title: Test

As this node is not yet translated the title of French and Greek is comming from the English version (fallback) but the URL is not.
What would be better is if the url would use the same fallback approach i.e. fr/content/test, el/content/test.

This has the following drawbacks:

  1. node/x - is an unfriendly way of presenting content to users
  2. An English/source language version would be clearer then node/x
  3. Many sites use url structure to create context

Analysis


(This may contain some mistakes as it is based on my D7 knowledge)

Drupal provides two ways of handling aliases

  1. Language Natural (All) - The language is set to "All" and will be applicable to all languages
  2. Language specific alias - Alias is applicable to only one language

Currently the first is used for nodes that are set to be not translated and the second is used for once that are.

Proposed resolution


Option 1
Without having to make significant core changes we can make the second option available to localized nodes, this will mean that sites will need to take one of the the following approaches
  1. My users will take on translation of url (I am ok with node/x)
  2. A node will have the same URL for all languages but will not be translatable (I will never be stuck with a node/x)

Curently this can only be done by visiting "admin/config/search/path" and modifying each URL or by writing custom code that overrides the Alias after it is set (What I am doing)
At the list we can add a drupal_alter() allowing hooks to modify the language. This will allow a contrib module to implement the rest.

Option 2
Extend D8 core alias handling so it can handle "All" aliases as fallback, so if you have the following in your alias table:

content/test node/5 ALL
content/δοκιμή node/5 Greek

"content/δοκιμή" will show for Greek and "content/test" will show for all other languages.
I believe this will provide the best ux and can be configured to work as is by saving nodes with a language specific URL or as fallback by saving nodes with language "All". In both cases the translate interface would be the same allowing you to create the language specific versions of the URL

Remaining tasks


Determine if this is not resolved by other D8 developments (I doubt think it is)
Determine which if any of the above solutions are of interest and are feasible.
If there is interest would be happy to help with code.
guy_schneerson’s picture

Personally on most of our sites we never have published content with node/x while not having localised URL's is more acceptable.
If core does not provide this functionality we will find ways around the issue but I really can't see how I am the only one with this problem.

Please let me know if this is still not clear

guy_schneerson’s picture

Issue summary: View changes

Nicxvan: Clarifying issue summary

jeni_dc’s picture

I've had this issue in the past with content translation where when switching to a language that does not have a translated node you end up on a fr/node/5 type of path.

Option 2 makes sense for me, especially when it comes to URL context. As an example, let's say I have an English news node with the path news/my-news-item and I've set my language switching to have English as a fallback.

The site is also available in French but that particular node doesn't have a translation. If a user is viewing the English node and switches to French, the path is now fr/node/6.

Now let's say I had a block with the latest five news items set to appear on news/*. If a user then switches to the French that block would no longer appear.

jeni_dc’s picture

Issue summary: View changes

Updated issue summary.

quicksketch’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

replicaobscura’s picture

This is still a pretty big issue on a site we're working on. Many of our blocks use the URL structure to determine where to show, so switching to any language which hasn't been translated on a node often makes important blocks disappear, and also messes with my path-based breadcrumbs.

Have there been any thoughts about the best way to handle this in the past couple of years? Is there some better way to handle this now that we're several more releases in?

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.