Translate Custom Fields

[Biont]

TLDR;

Let's add support for "public" post meta. There's no good reason not to!

Reasoning

This Issue is about providing an UI to translate all post meta that's not hidden (underscored). The kind of post meta data that is editable using the Custom Fields Metabox.

The ability to do so is already present for anyone that has capabilities to edit the remote post, so whatever bad could happen from editing these fields, would happen without any MLP involvement as well.

The presence of the Custom Fields Metabox pretty much guarantees that we're only ever dealing with simple strings, so there's little to fear when it comes to unpredictable third party code (ie. 'badly written plugins'). Any plugin that relies on a user-editable text fields to store complex data is simply not written in a sane way, and we should just ignore such an edge-case.

And as pointed out: Making unwanted changes to sensitive post meta is already possible for the User making the change. We can relax about this.

Adding this kind of functionality with a Plugin is very cumbersome at present. At the same time, this is a feature that's commonly used among people out there. It would be in our interest to make this as easy as possible for our users, or - as proposed - handle it ourselves entirely.

Implementation

(Will probably be expanded after more discussion/research)

If a Post Type declares support for 'custom_fields' and the corresponding Metabox is enabled in the Screen Options the Advanced Translator should display a similar element to translate any public fields

This Gist shows a (crude) way to make a number of meta values editable.

We should try make it quite a bit more accessible and then reuse it for the public post meta keys. If written with love and care, Plugin authors could later benefit from the resulting class as a dead-simple way to add support for their own private meta as well.

[Biont]

Since this goes beyond the scope of this Issue, I prefer to post it in a comment:

We could use this as an opportunity to rethink the API of the Advanced Translator. There could be a MLP_Advanced_Translator_Box that you can extend & register simlar to a WP Wdget. It would be used for our default elements, as well as any Plugin code.

I think there is quite some potential for avoiding unnecessary code and future headaches if we could advance this idea. And it might prove to be an invitation for plugin authors to add MLP support..

[thefuxia]

Keep in mind that you can bind (custom) capabilities to register_meta(). A user might have the capability to edit that specific meta value for that specific post on site A only, but not on the linked site B.

[kraftner]

I think what is really important here is to decouple things. The example you showed only works with an active Advanced Translator. (The relevant hooks aren't called without it being active)

But translation doesn't necessarily mean you want to do it manually. It might be an automated sync. In that case you maybe do not want to use the Advanced Translator or any UI at all.

There is a relevant Issue: #117

I also think it is a great idea to make the Advanced Translator more flexible. E.g. I just had a look if it is possible to hide the editor field as the UI is getting too massive with multiple languages. I wasn't able to as the creation of the view is hidden away inside the class with no filter or anything:

https://github.com/inpsyde/multilingual-press/blob/master/inc/advanced-translator/Mlp_Advanced_Translator.php#L91-L144

[Biont]

I agree with the points you raised.

One of the long-term plans is to get rid of the forced distinction between Advanced Translator and the regular one. It is a remnant of the free/pro split and will be an avoidable hassle in future development. The alternative would probably be that the Advanced Translator is enabled by default, and its UI elements and certain features can be configured (and extended). But that's another issue for another day.

The question here is where this issue fits in with that in mind. I don't think it's worth extending the regular translator at this point. So I guess it would be a good idea to tackle the Translator merge first

PS.: As an unpleasant workaround for hiding UI elements of the Advanced Translator, you could hook into top&bottom of the metabox and temporarily toggle Post Type support for elements you don't need. I had to do the opposite to fix 3rd party Post Types which replaced the default Editor by removing 'editor' support and filling the post content with a custom metabox

[kraftner]

:+1: on merging/refactoring the Translator before adding new features on top of the non-ideal current codebase.

(Offtopic: Thanks for the hint on the workaround)

[kraftner]

I have done some more thinking about the whole issue of translating custom fields over the last days:

Currently you can hook into the Advanced Translator to sync meta data. But it assumes that the data is coming from a field in the Translator MetaBox and therefore does all the handling inside the save_post action.

When targeting an automated sync approach this is a problem. As all this is done inside the save_post hook a lot of other plugins might not even have saved their data which is happening e.g. in a save_post handler that is called later on. So all we can do is work with the raw $POST data. As a lot of plugins put plenty of logic in between the raw $POST data and what goes in the meta (sanitation being the most obvious one) we are forced to duplicate all of this instead of just waiting for this to be completed and pulling the final meta data afterwards to sync to linked posts.

I am currently drafting a Meta Sync Plugin that works in multiple steps:

1. Collect meta data to sync. This can be done in various ways:
   • pulling from the raw $POST data as proposed by @toscho example and currently doable via mlp_pre_save_post_meta
   • hooking the plain updated_postmeta action
   • hooking various plugins. CMB2 for example announces updates so you can easily collect all changed metadata.
   • generating data from whatever other source. (Crazy example: Run the meta data trough some external translation API like Google Translate API.)
2. We then call a function on wp_insert_post. In theory we could also use save_post with a late priority, but because of #17817 as discussed in #96 this is safer. This action gets all connected posts and loops through them in the context of their site.
3. While already switched into the context of the other sites we now put all meta data through a filter before writing it. This way we can easily transform our meta-data based on data in the other site while already in that context saving unneccesary context switches. (This roughly translates to mlp_pre_insert_post_meta)

I think I have thought this through but haven't actually implemented or properly tested this idea. I'm just posting here as it might me interesting in the context of this issue for MLP itself. Looking forward to feedback.

[akincansenol]

Is there any news @kraftner?

[kraftner]

@akincansenol Sorry, not really. Haven't gotten any further yet than the initial thinking above.

[akincansenol]

It is very great and lifesaver idea, I'm facing problem with CMB2 fields also.

So did you took another action for this, like chosen another multilingual method or stopped using by custom fields?

On Fri, 4 Nov 2016, 9:15 a.m. Thomas Kräftner, [email protected] wrote:

@akincansenol https://github.com/akincansenol Sorry, not really. Haven't gotten any further yet than the initial thinking above.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inpsyde/multilingual-press/issues/125#issuecomment-258378703, or mute the thread https://github.com/notifications/unsubscribe-auth/AGsBwT8iqRIhfyYdEL30QM50Rt54xLVoks5q6vergaJpZM4FNAU5 .

[kraftner]

Actually neither. I started drafting an implementation but then the project I would have needed it for was put on hold. It will probably be picked up soonish, but don't hold your breath.

[akincansenol]

Actually I'm holding my breath for find a way to use multilingual with CMB2. This problem is one reason for me to start publishing my WordPress based project in these days

If any code drafts you have, please share them. This way maybe the authors/contributors start looking into too.

Regards, Akın

On Fri, 4 Nov 2016, 11:13 a.m. Thomas Kräftner, [email protected] wrote:

Actually neither. I started drafting an implementation but then the project I would have needed it for was put on hold. It will probably be picked up soonish, but don't hold your breath.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inpsyde/multilingual-press/issues/125#issuecomment-258405616, or mute the thread https://github.com/notifications/unsubscribe-auth/AGsBwdygpAsR_lkSyA2EdfFrcd_5cSUUks5q6xNRgaJpZM4FNAU5 .

[akincansenol]

I'm tried @JoryHogeveen 's gist https://github.com/JoryHogeveen/multilingual-press-custom-post-meta

It shows custom post metas to select for translate. But couldn't work on selected custom post metas. Nothing translated with it.

Did you try this add-on?

On Fri, 4 Nov 2016, 11:32 a.m. Akın Can ŞENOL, [email protected] wrote:

Actually I'm holding my breath for find a way to use multilingual with CMB2. This problem is one reason for me to start publishing my WordPress based project in these days

If any code drafts you have, please share them. This way maybe the authors/contributors start looking into too.

Regards, Akın

On Fri, 4 Nov 2016, 11:13 a.m. Thomas Kräftner, [email protected] wrote:

Actually neither. I started drafting an implementation but then the project I would have needed it for was put on hold. It will probably be picked up soonish, but don't hold your breath.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inpsyde/multilingual-press/issues/125#issuecomment-258405616, or mute the thread https://github.com/notifications/unsubscribe-auth/AGsBwdygpAsR_lkSyA2EdfFrcd_5cSUUks5q6xNRgaJpZM4FNAU5 .

[JoryHogeveen]

@akincansenol Keep in mind that this code was never fully finished. I never continued since there seemed to be no need at the time from MLP or it's user base. Also, it's not made for translating but for syncing.

[akincansenol]

Also I would like to syncing.

So have you look at @kraftner 's idea below?

It would be great if MLP support this idea as a dd-on or internal feature..

On Fri, 4 Nov 2016, 1:04 p.m. Jory Hogeveen, [email protected] wrote:

@akincansenol https://github.com/akincansenol Keep in mind that this code was never fully finished. I never continued since there seemed to be no need at the time from MLP or it's user base. Also, it's not made for translating but for syncing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inpsyde/multilingual-press/issues/125#issuecomment-258425515, or mute the thread https://github.com/notifications/unsubscribe-auth/AGsBwRb2vhl8E7yHMiJCX96Ue6CJcZByks5q6y1xgaJpZM4FNAU5 .

[tfrommen]

It would be great if MLP support this idea...

Well, @Biont, the author of this very issue, is one of the developers of MultilingualPress, so yes, we definitely support the idea.

So far, we didn't do very much in this regard for two reasons:

1. we are working on a complete refactoring of MultilingualPress, and only after that we will work on new features;
2. we are hoping for the Fields API to make it into Core soon, to at least have any sort of common ground for custom field UI.

Feel free to experiment with whatever comes to mind, of course. MultilingualPress itself will very likely not provide anything here within the next two WordPress release cycles, though...

[tyrann0us]

Hi @tfrommen, since the refactoring doesn't seem to be finished (is it #206?) and the Fields API doesn't seem to be in core either (last post is over a year old) is it correct that this issue has not seen any progress? Thanks.

[tfrommen]

Hi @tyrann0us,

yes, that's true, unfortunately. 😞

[Horttcore]

Is someone working on this?