Hi,
when i create a node without publish, and clic on tab "translate" i get this error:
Beta 4
Notice: Undefined index: href in i18n_node_translation_overview() (line 46 of /my/path/modules/i18n/i18n_node/i18n_node.pages.inc).
1.x-dev
Notice: Undefined index: href in i18n_node_translation_overview() (line 64 of /my/path/modules/i18n/i18n_node/i18n_node.pages.inc).

i create a traslation and no problem, English (title "goob bye", content "good bye") Spanish (title "adios", content "adios"), now on the list of contents i check two nodes ( "good bye" and "adios") and select publish (clic UPDATE ), i get:

* One node translation has been synchronized.
* One node translation has been synchronized.
* The update has been performed.

now open both nodes, English (title "good bye", content "adios") Spanish (title "adios", content "adios"), well, i edit node english content to "good bye", now spanish and english have content "goodbye".

I not allow neutral language.
the only way to works is create a node and publish, next create a translate and publish it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jose Reyero’s picture

Title: Override node content for "not publish" nodes » Notices and wrong links on translation tab for unpublished nodes.
Project: Internationalization » Drupal core
Version: 7.x-1.x-dev » 7.x-dev
Component: Synchronization » translation.module
Priority: Major » Normal
FileSize
1.85 KB

This is actually a Drupal core issue (that i18n code was copied from translation.pages.inc).

The reason is the resulting links from language_negotiation_get_switch_links() don't have href element when nodes are unpublished.

The patch was the quick fix for i18n module, though I guess we need something better for core.

plach’s picture

Version: 7.x-dev » 8.x-dev
Issue tags: +Needs backport to D7

subscribe

plach’s picture

Status: Active » Needs review
FileSize
1.75 KB
4.07 KB

I guess we need something better for core.

Honestly I don't see any other possible fix. The problem is that the language_negotiation_get_switch_links() should not exist at all. My fault. It is a cumbersome way to obtain localized links. In D8 we might want to suppress it in favor of restoring the D6 behavior: simpy passing an option to url(): url($path, array($language_type => $language)).

Rerolled the patch in #1 and added tests. The test-only version is supposed to fail to prove that the tests actually capture the bug.

Status: Needs review » Needs work

The last submitted patch, translation-1137074-3-test.patch, failed testing.

plach’s picture

Status: Needs work » Reviewed & tested by the community

The patch in #3 is a simple reroll of the one in #1 which is RTBC. The testbot tells us that the added tests are ok.

Dries’s picture

In #3, @plach argues that this function should not exist in D8 and that there might be a fundamentally better solution. I interpreted that as follows: the patch in #3 should probably be applied to D7 while we work on a better solution for D8.

plach, what would be a better solution for D8 look like? It's always preferred to come up with the proper solution, but it is too much effort it might be acceptable to go with a temporary solution.

Is that something you could prototype or outline for us? That would help others (including me) evaluate what to do with this temporary fix.

plach’s picture

@Dries:

Well, this is the situation in my mind: we have a small but annoying bug that needs to be fixed before releasing D7.1 (we don't want our latest stable release to throw notices anywhere, right?). There is a quick fix that is far from ideal but it is the only thing we can get in D7, i.e. adding another check to be sure that the language switch links are always valid in the translation overview page.
Another issue is what I referred to in #3: having to make all these checks on the result of language_negotiation_get_switch_links() just to get a valid link is, at the very least, cumbersome. But this is a broader issue that concerns the language system queue more than the translation.module queue. Hence IMO we should fix this issue for D8 and D7 and then open a separate one to address the future of language_negotiation_get_switch_links().

Lars Toomre’s picture

This is an example of what @catch so elegantly refers to as a '7.x patch' in his excellent process proposal (#1050616: Figure out backport workflow from Drupal 8 to Drupal 7 #104 [#comment-4471480]). In short, this issue needs to be applied to D7 as a 'bug fix'.

Our current bug fix process requires us to apply it first to development (D8) and then back-port it to production (D7). This is done so that development always includes known bug fixes to the production code base. Hence, @Dries your proposal in #6 to apply 'to D7 while we work on a better solution for D8' very much breaks the spirit of why D7 patches need to be applied to D8 first. Is that really your intent?

@platch in #3 confirms with enhanced test coverage that this bug exists and that a solution exists that fixes the bug. (BTW @platch excellent work. All RTBC bug fixes should include both a complete batch and one only with enhanced tests!!)

It should not matter whether or not there might be a better way to solve the issue in development (D8). What matters for this patch is whether it will be included in D7 (@webchick approval) and that D8 be updated to at least reflect what was applied to D7.

Another 8-x only patch can later be applied with a better solution (that may include refactoring, API changes and/or new strings -- alternatives locked down in production code). Perhaps a new tag like 'Better solution?' should be added to this and similar issues after the patch in #3 is added to both D7 and D8.

sun’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/modules/translation/translation.pages.inc
@@ -37,12 +37,12 @@ function translation_node_overview($node) {
+      $title = empty($links->links[$langcode]) || empty($links->links[$langcode]['href']) ? l($translation_node->title, $path) : l($translation_node->title, $links->links[$langcode]['href'], $links->links[$langcode]);
...
+        $options[] = empty($links->links[$langcode]) || empty($links->links[$langcode]['href']) ? l($text, $path) : l($text, $links->links[$langcode]['href'], $links->links[$langcode]);

@@ -58,7 +58,7 @@ function translation_node_overview($node) {
+        $options[] = empty($links->links[$langcode]) || empty($links->links[$langcode]['href']) ? l($text, $path, $query) : l($text, $links->links[$langcode]['href'], array_merge_recursive($links->links[$langcode], $query));

All of these can be shortened to the second condition. The combined OR condition is never TRUE for the first condition.

Powered by Dreditor.

plach’s picture

Status: Needs work » Needs review
FileSize
3.97 KB

Silly me :(

sun’s picture

Status: Needs review » Reviewed & tested by the community
webchick’s picture

I think Dries's question in #6 is a fair one; often by brainstorming on solutions without the restrictions of working on stable release code, we can come up with elegant ideas that in many cases backport nicely, too.

However, it sounds like what the i18n folks are saying is that this is a really ugly, user-facing problem in our stable release, and since no one currently has any big ideas on how to solve it differently, getting a fix out sooner than later is a good thing. Exploring a great way to handle this for D8 in a separate issue could always be backported to D7 if it turned out to be viable.

I can get behind this, on this particular issue. It'd be nice if we could get this patch into 7.1.

The patch is pretty simple; it just changes checks for empty($links->links[$langcode]) to empty($links->links[$langcode]['href']) and expands the test coverage to hit this part of the code.

webchick’s picture

Issue tags: +webchick approved

Oops.

Dries’s picture

Version: 8.x-dev » 7.x-dev

Committed to 8.x. Thanks.

Moving status to 7.x for @webchick. Might want to set it back to 'needs work' afterwards if we want to continue brainstorming about a better fix.

webchick’s picture

Version: 7.x-dev » 8.x-dev
Status: Reviewed & tested by the community » Needs work
Issue tags: -Needs backport to D7, -webchick approved

Fair enough. Thanks!

Committed to 7.x, moving back to 8.x and needs work.

plach’s picture

Title: Notices and wrong links on translation tab for unpublished nodes. » Make obtaining localized links less painful
Component: translation.module » language system
Category: bug » task
Priority: Normal » Major

Thanks!

plach’s picture

Title: Make obtaining localized links less painful » Make obtaining language-aware URLs less painful
Status: Needs work » Active

Better title.

plach’s picture

Issue tags: +D8MI
Gábor Hojtsy’s picture

Issue tags: +language-base

Tagging for base language system.

YesCT’s picture

@plach is this still needed in 8.x?

If so, since there was a fix for that particular situation, I think we need new steps to reproduce and/or an updated issue summary.

plach’s picture

Priority: Major » Normal

This is still badly needed: I was planning to work on it after feature freeze.

andypost’s picture

Issue summary: View changes
Issue tags: +Needs issue summary update

@plach Please update summary with actual state, that you explained in #2325977: All links lead to same entity translations in translation overviews

plach’s picture

Issue tags: +beta target

It would really be better to have this sorted out before beta, I have a semi-working patch, I will post it soon.

plach’s picture

Assigned: Unassigned » plach
plach’s picture

Issue tags: +API addition

This will imply at very least an API addition.

plach’s picture

Priority: Normal » Major

Let's be honest about this.

mgifford’s picture

Assigned: plach » Unassigned

Just unassigning issues that haven't been developed for a bit in the D8 queue.

xjm’s picture

Version: 8.0.x-dev » 8.2.x-dev
Issue tags: -beta target

This issue was marked as a beta target for the 8.0.x beta, but is not applicable as an 8.1.x beta target, so untagging.

API additions should be targeted for 8.2.x at this point.

  • Dries committed 2f12679 on 8.3.x
    - Patch #1137074 by plach, Jose Reyero: notices and wrong links on...

  • Dries committed 2f12679 on 8.3.x
    - Patch #1137074 by plach, Jose Reyero: notices and wrong links on...

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

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now 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.

  • Dries committed 2f12679 on 8.4.x
    - Patch #1137074 by plach, Jose Reyero: notices and wrong links on...

  • Dries committed 2f12679 on 8.4.x
    - Patch #1137074 by plach, Jose Reyero: notices and wrong links on...

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.

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

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

  • Dries committed 2f12679 on 9.1.x
    - Patch #1137074 by plach, Jose Reyero: notices and wrong links on...

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

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.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.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now 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: 10.1.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, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.