Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Steps to reproduce:
- Enable Content translation and more than one language
- Allow Panels nodes to be translated in content type settings
- Enable the language switcher block
- Create a panels node in English
- Create a panels node in $language
- View either of the panels nodes
- When clicking a language in the language switcher, the interface and URL prefix will change correctly (note 'no prefix' is correct for English), but the nid remains unchanged.
- With 'normal' content types, the nid changes too, showing you the node in whichever language you've selected.
Comments
Comment #1
catchCouple more things - language is set in {node} but tnid isn't. When editing a panels node, language information is reset to 'default' and the translation tab is lost.
OK, this is because panels implements it's own node form, so translation.module's hook_form_alter isn't interacting with it correctly:
http://api.drupal.org/api/function/translation_form_alter/6
Comment #2
cpelham commentedI'm having the same problem, with both nodes and blocks inserted into panel pages. Nodes inserted via a view DO change language correctly though.
Comment #3
TheRec commentedMarked #316733: "add translation" does not add a translation as duplicate. And subscribing.
I could not reproduce "Translate" tab disappearing.
Setting tnid to an unused value seems to work fine as a temporary fix, I have certainly not tested all the extend of this "trick".
Comment #4
catchOK, I worked out what the problem is, it's actual fairly simple (although I've not looked at fixing it yet).
When you translate a node, the tnid and language are taken via $_GET - because panels node creation is a multistep form, these get lost.
So creating a panels node, and adding those to the url, for example: http://d6.6/node/add/panel/onecol?translation=1&language=fr works fine.
Seems like the layout selection form would need to persist the $_GET parameters and pass them along to the node form itself.
Comment #5
catchPatched. What I've done is take $_GET, remove 'q', and pass it along to the calls to drupal_goto and panels_print_layout_link - this way it'll work generically for any hook_ nodeapi($op = 'prepare') which is pulling information from $_GET.
Comment #6
TheRec commentedI don't have time right now to test your code sorry. Reading it makes be think it's the right solution, but I am not sure it is recommanded to deal directly with $_GET. I guess the module maintainers will know better than me. Anyways, thanks for the patch, looking forward to test it.
I think your title does not describe exactly the problem but the solution you found. Hope this new title helps other people to find this issue more easily :)
Comment #7
catchSpoke to tha_sun in irc, re-rolled with drupal_query_string_encode and an extra space.
Comment #8
sun$options should have a argument default value, i.e. = array():
This will invoke a PHP notice on E^ALL, due to $options not being declared as array:
Whenever possible, avoid adding unnecessary blank lines or changes:
A good rule of thumb is to open and look at the patch file yourself after creating it. Most often, one is able to identify issues like the ones above in front of submitting it.
Comment #9
catchThat's tha_sun, should've spotted these before posting. This one should be a bit tidier.
Comment #10
TheRec commentedI tested this last patch and I played a moment with panels nodes translations and I didn't notice any problem. Thanks for this patch catch and sun :)
Comment #11
merlinofchaos commentedPanels 2.x for Drupal 6 is now deprecated and has been removed. All issues against this version of Panels are being closed.
Comment #12
R.Hendel commentedHello,
I found same problem in PanelNodes 6.x-3.2
I have tried /node/add/panel/onecol?translation=1&language=de but this does not give me a translateble node. There is no access possible to /node/nid/translate
So I will reopen this issue.
Has anybody an idea?
Thanks in advance,
Ralf
Comment #13
R.Hendel commentedSorry - was a false alarm.
I did forget to give the node a language. So it could not be translated. Not a problem of panelnode. More a problem of user ;-)
Comment #14
webcultist commentedI still have the same problem in 7.x-3.0-alpha3.
It's not possible to create a content translation for a panels node.
When I click the translate link, I simply stay in the translation overview interface.
Comment #15
Letharion commented@webcultist, this issue has been closed for over two years. Clearly, whatever your problem is, it's a different one, so please open a separate issue. Also, please note that Panelizer will be the future of Panel nodes in the very near future, so you may wanna look into that, instead of using Panel Nodes. Panel Nodes are unlikely to recieve many more bug-fixes. Here's the issue with an upgrade path, if you're interested: #1353542: Upgrade path from Panel Nodes to Panelizer
Comment #16
webcultist commented@Letharion, thank you for this information!
The panelizer and the upgrade path sounds like a good solution.
Comment #17
tommychrisOk, this is a 2 year issue, but what is the solution to fix it?
Now, I don't want to use panelizer, I want to use Panel Nodes.
Comment #18
merlinofchaos commentedPanel nodes are more or less deprecated in favor of Panelizer, to be honest. About the only thing that will ever be changed in panel nodes is when we get the migration path written; then they will be formally deprecated.
Comment #19
tommychrisI see, thanks.