Export panels_data to .csv

Hi,

My client requires front end translation via spreadsheet only, not via onsite methods like translation management.

We tried a few things and they’ve given us a potentially useful framework for translation, but there were a few snags which led to investigating a solution which may turn out to be better than our original one.

Seeing as the website has already been built with SO Page Builder, I think it could be possible to build a function to extract the content data, or assist WP All Export to extract the content data.

I’ve managed to export each page’s panels_data meta_key from the wp_postmeta table.

We are using WP All Export which has a Functions Editor, which seems like the best way to go to further target widget text content only, correct me if I’m wrong.

As far as I can tell I need to unserialize the string to extract what we need, namely only text content, nothing else (like HTML).

I’m guessing the SOPB plugin already does this when laying out pages, so perhaps it’s a matter of digging into it, renderer.php looking like the most likely candidate.

If I’m on the right track, and if you have a function on-hand that can extract only the text, then it would be great to lay my hands on it. Otherwise I can probably code it.

Then there’s the question of putting the translated text back into the serialized strings when importing the translated spreadsheet. WP All Import also has a Functions Editor, but how to make sure it inserts the translated content into the serialized data in the correct places is as-yet unknown.

Any ideas on how to do that?

Or is the entire method not ideal, in which case is there a good suggestion of how to accomplish WPML translation Export / Import using a spreadsheet? (or even at a stretch maybe something other than WPML?)

Many thanks!
Simon

Previous Potential Solutions
We already have a working method with Beaver Builder, ACF, WPML, and WP All Import / Export plugins.
We are able to extract content-only to .csv, send the spreadsheet to the translators, and then import all the language versions.

But there were problems which became apparent for reasons outlined below.
Not least because the site has already been created with SiteOrigin Page Builder.

So while technically-speaking the method would work with Page Builder, it would still require inserting ACF shortcodes into every single heading field, text field etc. to isolate them and allow translation to happen via ACF.

Problems with ACF fields
It’s not entirely ideal seeing as we have to create ACF fields for any potential items of content.
For each row, that is usually: Title, Tagline, Button

Repeater fields handle row instances, but sometimes the content varies, so we tried generic fields:
Field 1, Field 2, Field 3

But that too wasn’t ideal because sometimes an element would break the repeater rules, for example a slider within a row with title and text content for each slide.

Also, manually replacing the entire site’s content with ACF field shortcodes just seems like it’s defeating the reason for the invention of programming languages.