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
Comment #1
guy_schneerson commentedupdating title and tagging
Comment #2
nicxvan commentedCould 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:
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
Comment #3
nicxvan commentedComment #4
guy_schneerson commentedHi @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:
French:
Greek:
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:
Analysis
(This may contain some mistakes as it is based on my D7 knowledge)
Drupal provides two ways of handling aliases
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
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.
Comment #5
guy_schneerson commentedPersonally 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
Comment #5.0
guy_schneerson commentedNicxvan: Clarifying issue summary
Comment #6
jeni_dc commentedI'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.
Comment #6.0
jeni_dc commentedUpdated issue summary.
Comment #7
quicksketchComment #11
replicaobscuraThis 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?
Comment #22
smustgrave commentedThank 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!