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.
Comment | File | Size | Author |
---|
Comments
Comment #1
Jose Reyero CreditAttribution: Jose Reyero commentedThis 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.
Comment #2
plachsubscribe
Comment #3
plachHonestly 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 tourl()
: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.
Comment #5
plachThe 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.
Comment #6
Dries CreditAttribution: Dries commentedIn #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.
Comment #7
plach@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 oflanguage_negotiation_get_switch_links()
.Comment #8
Lars Toomre CreditAttribution: Lars Toomre commentedThis 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.
Comment #9
sunAll of these can be shortened to the second condition. The combined OR condition is never TRUE for the first condition.
Powered by Dreditor.
Comment #10
plachSilly me :(
Comment #11
sunComment #12
webchickI 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])
toempty($links->links[$langcode]['href'])
and expands the test coverage to hit this part of the code.Comment #13
webchickOops.
Comment #14
Dries CreditAttribution: Dries commentedCommitted 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.
Comment #15
webchickFair enough. Thanks!
Committed to 7.x, moving back to 8.x and needs work.
Comment #16
plachThanks!
Comment #17
plachBetter title.
Comment #18
plachComment #19
Gábor HojtsyTagging for base language system.
Comment #20
YesCT CreditAttribution: YesCT commented@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.
Comment #21
plachThis is still badly needed: I was planning to work on it after feature freeze.
Comment #22
andypost@plach Please update summary with actual state, that you explained in #2325977: All links lead to same entity translations in translation overviews
Comment #23
plachIt would really be better to have this sorted out before beta, I have a semi-working patch, I will post it soon.
Comment #24
plachComment #25
plachThis will imply at very least an API addition.
Comment #26
plachLet's be honest about this.
Comment #27
mgiffordJust unassigning issues that haven't been developed for a bit in the D8 queue.
Comment #28
xjmThis 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.