Problem/Motivation

The multilanguage support of panels is a bit limited. The only way to translate a static panel page title is to create a custom block, then use i18n module to translate that block, then include this block in the panel and configure Panels "Title Type" to "From pane", then finally assign the page title to the custom block.

Proposed resolution

Provide a generalized way to integrate the configuration fields (title & e.g. the content field of the custom content pane) of panes into the multilanguage system.
The most promising way seems to be an integration into the i18n module.

Remaining tasks

User interface changes

none

API changes

To make such a feature possible panels needs to add those new hooks:

hook_panels_pane_update() / hook_panels_pane_insert() / hook_panels_pane_delete()
CRUD hooks for panes.
For i18n_panels it would be possible to use hook_panels_display_save() for insert / update actions of panes.
But catching delete actions would be tricky. Thus I decided to implement this full CRUD set.
hook_panels_delete_display()
While there's already hook_panels_display_save() the one for deletion was missing.
i18n_panels needs to the new hook to clean up the translatable items.
hook_panels_pane_prerender()
First I tried to use hook_panels_pane_content_alter() to integrate i18n_panels but unfortunately then I've to trigger the whole keyword handling again. I think it's better to have this new hook and inject the new title before the keyword handling runs.
Another possibility could be to use hook_panels_pre_render() but I'm affraid that this could cause unnecessary pane loading.

Original report by cpelham

I can set the content within the panes to appear according to language environment. That's fine. but i cannot figure out how to translate the title or have a translated title show up in a menu. Is there a way. Someone in another issue queue referred to creating translations of whole panels but I don't see how to do this either.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cpelham’s picture

Status: Active » Closed (fixed)

ah, here:
admin/config/regional/i18n/variable

cpelham’s picture

Status: Closed (fixed) » Active

Oh, but checking pages there doesn't seem to create a form to enter a translation anywhere, at least not anywhere that I can find so far (like on one of the panels pages screens). there are no instructions on this page so Im' a little stumped.

merlinofchaos’s picture

Currently there isn't a translation mechanism available. People have been working around this by using _preprocess_panels_pane or hook_panels_pane_content_alter to run the title through t(). This isn't an ideal solution but it does the trick for people.

cpelham’s picture

Great. Thanks, Earl.

Max_Headroom’s picture

I need some help here please. I tried the following code to do translations on titles, but my titles still does not want to translate

function MYMODULE_panels_pane_content_alter($content, $pane, $args, $context) {
  $title = $content->title;
  $content->title = t($title);
  return $content;
}

Isn't $content passed by reference perhaps? I tried that to though, but does not work either.

jherencia’s picture

Subscribing...

jherencia’s picture

I've created a module that helps in this cases:
http://drupal.org/sandbox/jherencia/1280726

I know it should be fixed otherwise, but as long as there is no way to do it in Panels, it might help.

anruether’s picture

subscribe

jherencia’s picture

@merlinofchaos or any mantainer

Could you look at this module (http://drupal.org/sandbox/jherencia/1280726) and consider if it could be good to add it to Panels until a better solution is achieved?

das-peter’s picture

I would love to see an official 18n integration.
That shouldn't be that hard to achieve. Mainly we need to integrate it with i18n_strings. That way the title should be (at least) translatable via the translation interface.

If there are no concerns / other ideas I'll start with such an integration asap.

@jherencia: I took a look into the sandbox. It gives me already some idea about which hooks to use for the creation of a i18n_panels module. :) And we should definitely create a proper i18n integration - means not passing variables to / not using t() and relying on the already existing 18n stuff.

jherencia’s picture

Ok, great I did it that way because I need it ASAP in a project I was developing but I agree we need to do a better aproach. I'm gonna see i18n_strings.

merlinofchaos’s picture

Using t() is a fine hack which we're not really supposed to do officially. I would love to see an i18n_strings approach.

Letharion’s picture

Title: Is there a way to translate the title of a panels page? » Translatable panel titles: Implement i18n_strings
Category: support » task
Status: Active » Postponed
m_wiking’s picture

I'm really interested in this. Just noticed the problem today...

das-peter’s picture

Status: Postponed » Needs review
FileSize
7.4 KB

I've created a very simple module for now. It simply registers the titles of panel displays / panes in the translation interface.
The chosen naming allows to extend the i18n setup with other configuration items. Maybe we could introduce some metadata to define configuration items as translatable.

I've introduced several new hooks in panels itself:

hook_panels_pane_update() / hook_panels_pane_insert() / hook_panels_pane_delete()
CRUD hooks for panes.
For i18n_panels it would be possible to use hook_panels_display_save() for insert / update actions of panes.
But catching delete actions would be tricky. Thus I decided to implement this full CRUD set.
hook_panels_delete_display()
While there's already hook_panels_display_save() the one for deletion was missing.
i18n_panels needs to the new hook to clean up the translatable items.
hook_panels_pane_prerender()
First I tried to use hook_panels_pane_content_alter() to integrate i18n_panels but unfortunately then I've to trigger the whole keyword handling again. I think it's better to have this new hook and inject the new title before the keyword handling runs.
Another possibility could be to use hook_panels_pre_render() but I'm affraid that this could cause unnecessary pane loading.

If someone reviews the code please take a close look to the used / added hooks. I'll definitely appreciate smarter solutions :)
In my tests the pane and display titles were translatable and both have keywords support for the translated strings.

Open questions:

  • Shall we create translation items if the title is empty? If we see this as approach to hide the title, translation items aren't needed in such a case.
  • What has to happen to translation items if the title override is disabled? Keep or delete them?
Letharion’s picture

Assigned: Unassigned » merlinofchaos

Cool! Assigning to merlin for a review :)

broncomania’s picture

Your patch looks geat. Can you also offer a version for D6?

das-peter’s picture

@broncomania: Unfortunately not, I'm a D7 only guy. :|

Letharion’s picture

Even if the patch will be back-ported, we should agree on it's format in D7 first.

Kristen Pol’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
11.39 KB

I tested this and it works great! I applied the patch to 7.x-3.0-alpha3 and re-saved my panel page. Then the Panels text group showed up in the Translate interface form. I translated my panel title and a pane title and they both showed up as expected.

Thanks @das-peter!

Kristen

merlinofchaos’s picture

Status: Reviewed & tested by the community » Needs review

AT the very least we need to make an attempt to document all of these new hooks we're adding. That alone makes this not RTBC. :)

Kristen Pol’s picture

@merlinofchaos - what docs do you want... README.txt, d.o docs (where?), etc.

Thanks!
Kristen

merlinofchaos’s picture

Hooks are added in an MODULENAME.api.php file that is used to document hooks. I just noticed that while CTools has one of these, Panels doesn't actually have one.

das-peter’s picture

I'm already working on an API doc. But this will definitely need review ;)

das-peter’s picture

Here we go. This patch contains only panels.api.php.

Kristen Pol’s picture

Status: Needs review » Reviewed & tested by the community

@das-peter - The documentation looks good to me, so I'm putting back to RTBC.

Thanks!
Kristen

das-peter’s picture

Status: Reviewed & tested by the community » Needs review

I'd say we need another review of the basic translation approach from Jose Reyero (reyero) / Florian Weber (webflo) or any other i18n specialist.
I know that I'm just scratching on the surface of i18ns power here and it would be bad to use right from the beginning a suboptimal approach.
Thus for me this still needs review. :)

netsensei’s picture

Awesome! This works for me.

On a sidenote: the patch not only works with panes but also on displays. Meaning: it not only allows you to translate the titles of individual panel panes, but also the title of an entire page which is managed through ctools' page manager! Just what I needed! We might want to document this.

Also, I'm not very keen on manually re-saving a bunch of existing panels after enabling this just for the sake of registering the title as an i18n string.

Finally, I agree with you. It's an awesome start, but some advice from an i18n guru would be most welcome.

Great job again!

dimitriseng’s picture

I have tested #15 and now can translate panel titles etc, thanks das-peter and all! Agree with the comments at #28.

Kristen Pol’s picture

So, should the issue be tagged with something in order to make it easier for Jose et al to see it or should we just bring it to their attention or ?? I'm not sure what the protocol is here.

Kristen

das-peter’s picture

Spent several hours pushing this forward.
Because the whole thing grew quite a bit I decided to move it to a sandbox:
http://drupal.org/sandbox/daspeter/1444130

There are some really nice new features:

  • Custom content is translatable out of the box now
  • It's possible to make any ctools content_type plugin translatable by using hook_ctools_plugin_post_alter()
  • Plugin developers can extend the plugin definition to add translation support.

The biggest issue atm. is the fact that this solution isn't as generic as I would like to have it.
Basically the whole module should be called "i18n_ctools_conent_types" because the module handles more content_type configurations and not panels.
"Unfortunately" panels is required as container, to give each configuration and translation an unique id (pid).
This means other modules, which also use ctools content_types, need to provide their own integration.

das-peter’s picture

Silly me, of course there's still a patch necessary to integrate the whole thing into panels.
The attached patch contains these changes.
I think this are generally nice enhancements independent from the idea of i18n_panels.

andiart’s picture

I need this module and patch for drupal 6 and panels 6.x-3.9. Any plans to implement this or maybe you can give me advice how to do it?

das-peter’s picture

Unfortunately I'm a D7 only guy. Didn't use Drupal before and thus my know how is very limited.
Atm. I don't have any plans nor time to port this on my own - however if someone wanna give it a shot I'd try my best to support that.

dimitriseng’s picture

Status: Needs work » Needs review
Issue tags: -i18n compatibility

@das-peter - great work this is a really useful feature, thank you. Hopefully the final form that this will take will be decided soon.

I am using panels-7.x-3.0 and I have tested with your sandbox project i18n_panels and the patch at #32. At first this seems to be working ok and I can translate Panel titles successfully, but I have found that everytime that a "refresh strings" operation is carried out, the translations are removed! Is this working correctly for you? Below are steps to reproduce:

- "Update and save" a panel page.
- Go to the Translate Interface and limit the search to "Panels". The panel title is shown correctly.
- Translate the panel title using the edit link.
- Check and confirm that the the panel title now shows translated when viewing the node (all is working correctly up to here).

Issue:
* The translation is removed in the case of a "Refresh Strings" operation.
Steps to reproduce:
- In the "STRINGS" tab, Select "Panels" as the text group.
- Tick the "Clean up left over strings" checkbox and press the "Refresh strings" button.
- Go to the Translate Interface and limit the search to "Panels". Check the available strings for translation.
=> In my case, the translation is removed and also the panel title string is not showing in the Translate Interface. I have to go back and save the panel page again for the title to be made available for translation, which will be removed again if I refresh the strings again and so on. Can you please confirm that this is working for you or not?

webflo’s picture

Issue tags: +i18n compatibility

Tagging with i18n compatibility.

das-peter’s picture

Status: Needs review » Needs work

@dimitriseng Thanks for the feedback, I'll take a look at that asap.

das-peter’s picture

Issue tags: +i18n compatibility

Here we go, latest version supports the "Refresh strings" operation of i18n.

Edit: Reminder, coding happens now in a sandbox: http://drupal.org/sandbox/daspeter/1444130 :)

dimitriseng’s picture

@das-peter - I have tested with the updated version of the sandbox i18n_panels project and I can confirm that the "Refresh strings" operation of i18n is now working correctly, I have tested the procedure in #35 which was not working before. Great work thank you very much for fixing this quickly!

So, what is the way forward for this? Is this going to remain as a separate project or integrated to panels? Or would there be a different way to achieve this? If this was official more people would be able to test and RTBC so that we can get it in. Thank you.

das-peter’s picture

The current sandbox only works with displays / panels stored in code.
I give now the uuid patch in #1277908: Introduce UUIDs onto panes & displays for better exportability & features compatibility a try and if it works I'd say that will be another requirement.

das-peter’s picture

Updated patch to work with the latest i18n_panels integration.
The next version of i18n_panels will have following patch as an additional requirement: #1277908-15: Introduce UUIDs onto panes & displays for better exportability & features compatibility (uuid support)

Anonymous’s picture

das-peter,
Seems like the titles are working alright but I'm running into this problem for any panel with PHP enabled:
"The string panels:pane_configuration:67e9b16b-269f-1494-0998-a0e89999d561:body for textgroup panels is not allowed for translation because of its text format."

Which is perfectly fine! However instead of just ignoring that field and moving on, it replaces the output with a lowly "<".
Thoughts?

edit: after looking a bit, I realized that PHP was disallowed from translation. I fixed this and the error message in Panels went away, however the problem persists. It looks like the familiar spot where you throw PHP code into a Full HTML box and it strips everything past the first arrow out but it doesn't make sense that it would do such a thing to me.

mh86’s picture

I've just tested the i18n_panels integration, and first of all, thanks to das-peter for all the work!

Concerning the translation of custom content, I can confirm the problem reported in #42. For my plain text body only the first letter of the translation is rendered.
Furthermore I encountered a problem with exported pages. After I patched panels and installed i18n_panels, I updated the exported code and as long as the page manager page was still overridden, the title could be translated. Once I reverted the page, the title translation disappeared (also from the list of available translation strings), but the other translations from the custom content are still there.

I'll do some further testing now and will report back!

das-peter’s picture

Thank you guys for reporting these issues.
I've just pushed a fixed translation replacement - please fetch the latest code from the sandbox to check if the error is gone.

Anonymous’s picture

das-peter, that fixed my problems! thank you very much!

mh86’s picture

Did some more testing and the only architectural problem I see so far is related to reverting of features. In case a page is overridden, and then I perform a feature revert, all delete hooks are invoked and my translations will be removed, although the page will now be fetched from the code.
For feature reverts we should only perform updates (maybe check what has changed). In case that isn't possible, we maybe just shouldn't delete anything for overridden pages, and tell people instead to do a manual refresh and clean-up in the translation interface (well, not the best approach).

das-peter’s picture

Thanks mh86, this is very valuable input. I'll try to work on a solution.

das-peter’s picture

Just pushed a fix for the recognition of panels displays, exported in page manager pages.

mh86’s picture

Posted 2 patches in your sandbox issue queue as well, they seem very similar ;-)

das-peter’s picture

And another pushed fix in the sandbox. First attempt to figure out if a display to delete also resides in code and skip the deletion of the translations if so.
It seems to work but the code is a mess. :|
A review of someone familiar with the whole exportable stuff is desperately needed.

merlinofchaos’s picture

Wow, this is problematic. Unfortunately there is now way to tell if a panel is in code somewhere or not since there's no reliable source of them. What we really need are unique IDs for the display but those may not always be available.

You might be able to get some information via $display->renderer_handler->address which should help find the owner of it, and see if the owner is in code or not, but I don't think all of the main paths of that are properly supported yet.

That said, we could add support to all the paths for that and see what we get!

dimitriseng’s picture

@all, this is a really useful feature but I am not sure what the plan is. I have been using the i18n_panels sandbox up to #41 (also with panels 7.x-3.2) and is working ok for translating titles, however I have not tested further updates with #1277908: Introduce UUIDs onto panes & displays for better exportability & features compatibility as that included database updates as well. Can somebody please confirm what the plan is for moving this forward? Is i18n_panels going to remain a separate module or integrated with panels? Thank you for all the great work on this so far.

dimitriseng’s picture

Hi, is there any update on the plan for this? See my comments in #52, thank you.

das-peter’s picture

Well, I'm still working with the sandbox. Latest commit (3 days ago) fixed an edge case.
I know that the sandbox module is used in production on several websites, including the one for which I created the module.
However, atm. I don't see the module becoming part of panels soon.
Anyway, more important is that the patch in #41 and the one in #1277908: Introduce UUIDs onto panes & displays for better exportability & features compatibility get committed.
Without this patches it doesn't make sense to promote the sandbox to a full project.

lotyrin’s picture

If we don't see this becoming part of panels, could we make it a full project without a stable release, and a project page that refers to the issues in question. (Secure Pages comes to mind.)

Another option would be trying to get it into i18n. But any solution that makes it (part of) a full project (even with patch dependencies) would be nice.

liquidcms’s picture

Status: Needs review » Needs work

title for Custom Content panes are not translatable (with module/patch)

- but not sure of the version of the patch i have (i have the "big" patch which creates the module)
- and git clone for sandbox project does not work

sylus’s picture

Status: Needs work » Needs review

I believe you can clone this repo (as head is not set) with

git clone --recursive --branch 7.x-1.x http://git.drupal.org/sandbox/daspeter/1444130.git i18n_panels

Waiting for das-peter to review and accept the custom content panes patch liquidcms built then hoping we can set the status back to needs review and hopefully soon RTBC.

das-peter’s picture

Meanwhile I've created a dummy master branch.

sylus’s picture

Thanks das-peter! Also it looks like custom content panes is no longer an issue is there anything else is holding this patch up? ^_^

das-peter’s picture

I've updated the issue summary. I'd say the most important Remaining Task is to review the dependency: #1277908: Introduce UUIDs onto panes & displays for better exportability & features compatibility
That seems to only reason why the patch has to be delayed.
Whoever would like to see the i18n integration, should help to push the UUID integration first :)

Dentorat’s picture

Thanks das-peter, I didn't get much time to really poke and prod, but it all worked for me, the only thing I had to do was go through each of my panels and just hit save again, thanks for the work!

Anonymous’s picture

Great, it works for me too. Module from repo + patch. Thumbs up.

Anonymous’s picture

the patched panels* files get wsod, any help?

*version = "7.x-3.3+12-dev"
datestamp = "1353115759"

Peacog’s picture

I'd like to try out the i18n_panels module but there doesn't seem to be any code in the repo. I've tried the git clone command from http://drupal.org/node/1179034#comment-6168910 but there's nothing there. Can somebody point me in the right direction? Thanks.

das-peter’s picture

@Peacog Please follow the instructions in the Version control section of the sandbox page: http://drupal.org/sandbox/daspeter/1444130

Peacog’s picture

@das-peter Thanks for replying so quickly. I did follow the instructions on the sandbox page earlier, and then did a 'git checkout 7.x-1.x' as per the README.txt, but the only file checked out was the uuids patch. I've just done it again and this time the module files are there. Thank you!

sibiru’s picture

Hi @das-peter , i'm trying to clone your sandbox project here:
http://drupal.org/sandbox/daspeter/1444130

Enabling this module make other i18n string disappear..

Then trying to apply patch using GNUWin32
http://postimage.org/image/m30bqtpa5/

It seem nothing happen, how do i apply the patch that include in your sandbox project?

Thanks

liquidcms’s picture

Status: Needs review » Needs work

as far as i can tell the module and patch (not the UUID one as it is suggested this is only for Features which i am not using) do not work.

i have enabled the module and applied the patch "panels-add-hooks-to-integrate-i18n_panels-1179034-41.patch" and i have overriden panel pane titles which are not being translated.

liquidcms’s picture

i can actually see a new string in text group Panels with context: pane_configuration::override_title_text which sounded promising; but that translated string is not being used.

liquidcms’s picture

Status: Needs work » Needs review

finally got this working but not sure how much of this was used:

- i had to use a different content pane than the default one i was getting from OG. even though it was from a view i could not get the override title to be translated. i made a new view from scratch and this worked.
- i did need the uuid patch as saving my panel threw errors without it - even though i am not using features and see no reason i should need uuid to simply translate a panel pane title.

dimitriseng’s picture

It looks like the other issue #1277908: Introduce UUIDs onto panes & displays for better exportability & features compatibility that this patch depends on is not progressing. Is there any way to implement this functionality in a simpler way than requiring the other patch that involves UUIDs? Or if UUIDs are really needed, does anybody have the knowledge to help progressing that issue so that we can solve this one as well? Thanks for your great work.

sylus’s picture

Agreed with dimitriseng it doesn't look like #1277908 is going to progress at all anytime soon.

das-peter’s picture

Unfortunately I don't know any other way. Without #1277908: Introduce UUIDs onto panes & displays for better exportability & features compatibility there's no unique identifier for the translation.
And without unique identifier this is quite pointless as a change in panels would lead to lost translations.

dalin’s picture

I don't follow why a UUID is necessary. Once a Display/pane is saved to the DB its ID will never change correct?

Here's an initial stab that works for display titles. Not sure if the render function is the right place to put this to make things work with panels caching (which I'm not using). If this works the same thing could probably be done for Pane titles.

merlinofchaos’s picture

I posted on #1277908: Introduce UUIDs onto panes & displays for better exportability & features compatibility to try and move that forward so we can move this forward. It needs some work by someone familiar with UUID algorithms, however.

merlinofchaos’s picture

dalin: Sadly what you say is not true if the pane is exported to code. THen its id will be reverted to new-XXX.

RaulMuroc’s picture

I applied the Latest patch of this issue + applied patch of the other issue referred as "dependecy" as well as actived the sandbox's module: Panels I18n.

I am able to translated my "Override title: [title]" Pane titles. But they are just show in default website language (English in my case).

The UUID updated in DB has gone correctly. I have all panels with UUIDs.

lpalgarvio’s picture

does this issue also cover Taxonomy term's descriptions and other fields?

they are incorrectly displayed, always in the original language.

and the Content Type token?
#1934672: Content Type token not translated

lpalgarvio’s picture

oh, i think i ran into the wrong issue.

is there an issue covering these problems?

OnkelTem’s picture

This patch is combined from:

but re-rolled on the latest panels DEV.

I prepared it since those two patch don't apply simultaneously: they are patching same code. So I first checked out panels dev, then applied panels-uuids patch, then manually applied panels-add-hooks patch, then I've created this patch.

So, if you want to get i18n_panels to work, you need to apply:

RaulMuroc’s picture

Any test on that?

jantoine’s picture

I am currently using the patch from #80 and the related patches/projects without any issues. I was previously using the UUID patch for about 6 months.

stone_d’s picture

Hi there,

i was sooo lucky by using this! Works perfectly - besides it still cleans up all my translations when refreshing strings.
Which patch from the above ones solve this? So i can drill down to find if i did something wrong on this.

Thanks in advance and best regards,
Fab

saltednut’s picture

Issue tags: +demo_framework

A [META] issue would be extremely helpful here though I guess the i18n_panels page does provide those instructions.

Here is a makefile snippet if anyone needs this working right now and doesn't feel like reading two queues w/ a combined 200+ comments. :)

projects[ctools][version] = "1.x-dev"
projects[ctools][type] = "module"
projects[ctools][subdir] = "contrib"
projects[ctools][download][type] = "git"
projects[ctools][download][revision] = "e81da7a"
projects[ctools][download][branch] = "7.x-1.x"
; Introduce UUIDs onto panes & displays for
; better exportability & features compatibility
; (ctools patch from panels queue)
; https://drupal.org/node/1277908#comment-7216356
projects[ctools][patch][1277908] = "https://drupal.org/files/ctools-uuids_for_exported_objects-1277908-118.patch"

projects[i18n_panels][version] = "1.x-dev"
projects[i18n_panels][type] = "module"
projects[i18n_panels][subdir] = "contrib"
projects[i18n_panels][download][type] = "git"
projects[i18n_panels][download][url] = "http://git.drupal.org/sandbox/daspeter/1444130.git"
projects[i18n_panels][download][revision] = "37a796b"
projects[i18n_panels][download][branch] = "7.x-1.x"

projects[panels][version] = "3.x-dev"
projects[panels][type] = "module"
projects[panels][subdir] = "contrib"
projects[panels][download][type] = "git"
projects[panels][download][revision] = "2bb470e"
projects[panels][download][branch] = "7.x-3.x"
; Translatable panel titles: Implement i18n_strings
; https://drupal.org/node/1179034#comment-7216342
; Introduce UUIDs onto panes & displays for better
; exportability & features compatibility
; https://drupal.org/node/1277908#comment-6771122
projects[panels][patch][1179034_1277908] = "https://drupal.org/files/panels-1179034-41_____panels-uuids-127790-100__-80.patch"
Sk8erPeter’s picture

Priority: Normal » Critical

Any updates on this? I think this issue is critical, because many of us are developing multilingual sites, are using Panels, and would like to add custom translatable titles to Panels pages.
Thanks for all the efforts!

stone_d’s picture

Yeah - i already wonder that not 1000s of people writing to this thread already. Panels is a WONDERFUL thing - even more in combination with the "panels everywhere" theme - a powerful combination, but the lack of translateable panels is really a pity :/

RyanX’s picture

subscribe

RaulMuroc’s picture

I do not catch what stops to commit both patches of #80 (or #84) if they are working nicely.

I also have tested in two projects: little and medium size, and worked like a charm.

Thank you.

P.D: Ok, finally I catch what stops to commit... the dependency on a sandbox's project!!! (i18n_panels). Thanks for nice work.

das-peter’s picture

I simply don't promote the sandbox to a full project because there's a dependency on a patch to run the module.
What really stops this is the lack of feedback / progress on how to proceed with the UUID's. In the related issue there are some scenarios outlined that aren't covered yet.
Some of the scenarios could break panels configurations e.g. export and re-import a panel configuration would lead to duplicated UUID's. And that's a really bad thing.

das-peter’s picture

Issue summary: View changes

Updated summary

skyredwang’s picture

Issue summary: View changes
japerry’s picture

Status: Reviewed & tested by the community » Fixed

After months and lots of testing, I can say that we have i18n_panels committed!

http://drupalcode.org/project/panels.git/commit/6a47e27

Good work all =)

schifazl’s picture

Thanks! You're all great :)

A question: the readme says:

   9 Attention: Currently this module needs a patched panels version.
  10 Please apply the patches included in this module or visit:
  11 Additional hooks: http://drupal.org/node/1179034#comment-5664050
  12 UUID support: http://drupal.org/node/1277908#comment-5667824

Is this still needed?

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

gemalm’s picture

Cool! Thanks a lot! You made my day! ^^

  • Commit 6a47e27 on 7.x-3.x, 8.x-3.x authored by das-peter, committed by japerry:
    Issue #1179034 by das-peter: i18n_panels submodule
    
  • Commit f6a508e on 7.x-3.x, 8.x-3.x authored by das-peter, committed by japerry:
    Issue #1179034 follow up by das-peter: i18n support panelizer displays,...
jweowu’s picture

charrony’s picture

Similar to comment #35 above but only in specific cases. When I refresh the strings with the "Clear up left over strings" option checked, SOME of the strings disappear completely and have to be re-entered and saved again.

See sample below. Of the three, 2 disappear but one stays around when I refresh the strings. From my database, all strings that disappear are of the type "override_title_text". However, as seen in the sample below, many more that stay around are also of that type.

How can I tell what's the difference between those that do, and those that don't (disappear) so I can either file a bug or someone can tell me how to get this issue resolved?

From the "location" (e.g. panels:pane_configuration:0ec045d2-c964-4f58-a6da-9b425a97aa02:override_title_text), how can I tell where that string was entered (i.e. its origin, source of the original English string, backlink to source)?

Here is a sample:

1. Panels Add a comment
panels:pane_configuration:0ec045d2-c964-4f58-a6da-9b425a97aa02:override_title_text pane_configuration:0ec045d2-c964-4f58-a6da-9b425a97aa02:override_title_text fr edit delete
2. Panels Add a comment
panels:pane_configuration:ca90e213-ad34-403b-aaaa-56f8d58c956a:override_title_text pane_configuration:ca90e213-ad34-403b-aaaa-56f8d58c956a:override_title_text fr edit delete
3. Panels Add a comment
panels:pane_configuration:203ae7ac-c39e-49ba-8c46-0d899483b332:override_title_text pane_configuration:203ae7ac-c39e-49ba-8c46-0d899483b332:override_title_text fr edit delete

Any help is appreciated,
Thanks

drupal.bug’s picture

To find out more info based on the location (UUID), you can query the panels_pane table for a specific UUID:
"SELECT * FROM `panels_pane` WHERE uuid = '0ec045d2-c964-4f58-a6da-9b425a97aa02'"

ChristianAdamski’s picture

I'm confirming charrony from #98 (and therefore #35 as well). Panel pane override titles string disappear from the translation interface, no matter if translated or not, when refreshing strings.

What might be worth noting: The two strings/pane titles I am testing, are the same as in two other pane titles that do not disappear. Think of two panes A and B than coincidentally both use an overriding title "Hello World". One disappears, the other one stays.

Edit: Using latest -dev from ctools and panels 23.12.'14

ChristianAdamski’s picture

Hmm, so this is bizzare. I have two completely unrelated displays with the same UUID. The second is skipped because of line 318 in i18n_panels_i18n_string_list(). And I think that skip is fine, given that UUIDs should be unique as the name implies.

Oh boy.

ChristianAdamski’s picture

Okay so I was able to solve my problem, though it is surely not related to i18n_panels. The conflict seemed to arise from panels being present in code, but still being stored in DB with differing DID. A simple forced feature revert took care of that.

@charrony, could your problem be related to this?

lmeurs’s picture

Thanks all for the great work! Quick question, I was looking for a language switcher as offered by the Variable translation (i18n_variable) module, but cannot find one. Is it correct to say that Pane translating is done:

  1. through the UI at admin/config/regional/translate/translate or
  2. through .po(t) files downloaded from admin/config/regional/translate/export

Or are there other possibilities that I am missing? Any help is appreciated, thanks in advance!

kkalashnikov’s picture

This patch works for me.

shortspoken’s picture

Thanks @kkalashnikov. It works indeed for me too.

jespermb’s picture

I have cleaned up the patch from #104 since the paths in the patch prevented our make script from applying it. The only difference is that i have removed "web/sites/all/modules/panels/" from the patch other than that it works for me.

Regards,
Jesper

ptmkenny’s picture

This issue is marked fixed and a patch was already committed (Comment 96), so if there's still a need for a patch, please update the issue and explain what still needs to be done/what the new patch does.

kristiaanvandeneynde’s picture

Better yet: Make a new issue and link it to this one.

jespermb’s picture

Sorry about that, didn't see that it was applied to 3.4. The issue is that we have a site which is live with an older version of panels 3.3 and they need this patch applied, but since we are using drush make to deploy it won't apply the patch and our build fails due to the path in the patch. We will just host the changed patch our selves until we update their site.

Best regards,
Jesper

joseph.olstad’s picture

#2790717: Translatable panel titles avoid string refresh problems

^ followup in this issue ^

marked followup issue as RTBC, patch #106 was copied to the new issue,
great work @kkalashnikov and @jespermb

thanks

SaytO’s picture

Work's to me.
Apply patch #106.
Follows this issue, good work!

Thanks

joseph.olstad’s picture

@SayTO, this issue is closed and will not/can't be re-openned, please upload your new patch on the followup issue:
#2790717: Translatable panel titles avoid string refresh problems