[Plugin: Polylang] Quick edit still breaks translation linking of pages in 0.7.2

I can reproduce this behaviour every time by just clicking Quick Edit and then Update without any modifications in quick edit form. Bulk edit also breaks linking.

All other plugins are disabled, but even if they were not, none of them could interfere with saving of pages. I know because I wrote them.
The only point in which I’m hooking on save_post action is in my theme but there I check if post type is my CPT and if it’s not return immediately.
To prove this I just switched to twentyeleven theme and result is same.

I did direct SQL queries on wp_postmeta table that revealed missing or incomplete _translations values.
For instance – there are two pages linked as translations:
id: 67, language: lv;
id: 82, language: en;
(no tags, no other meta or anything)
before quick editing, query SELECT * FROM wp_postmeta WHERE meta_key='_translations' AND post_id IN(67,82)
gives:

271, 67, _translations, s:34:"a:2:{s:2:"en";i:82;s:2:"lv";i:67;}";
273, 82, _translations, s:34:"a:2:{s:2:"en";i:82;s:2:"lv";i:67;}";

now they are linked and all is right, but after quick editing page with post_id 67:

273, 82, _translations, s:20:"a:1:{s:2:"en";i:82;}";

It seems that Polylang_Base::delete_translation() is the only method where delete_metadata is called for _translations meta key.

Regarding quick edit support – it’s easy, but involves some JavaScript trickery which is exactly the way it’s done in original quick edit.
It is well explained on codex action reference page quick_edit_custom_box.
You could put your language codes as hidden elements in custom columns and then set up form elements in quick edit accordingly.

From PHP coders standpoint it may seem rather awkward to populate form fields from table cell text, but it works and reduces data amount from server.

Just checked and yes, Polylang_admin_filters::save_post returns as expected because $_POST['_inline_edit'] is there.

Polylang_Base::delete_translation is called always – even on quick edit.
added this in beginning of Polylang_admin_filters::delete_translation

error_log("calling ".__CLASS__.'::'.__FUNCTION__."($type, $id)", 0);

and after quick edit line popped up in log file:

calling Polylang_Base::delete_translation(post, 82)

*debugging, debugging, debugging*

using xdebug_get_function_stack revealed that Polylang_Admin_Filters::delete_post is called when deleting old revisions in following order: wp_insert_post -> wp_save_post_revision -> wp_delete_post_revision -> wp_delete_post -> Polylang_Admin_Filters::delete_post.
I skipped calls to do_action, but you get the point.

I usually set post revisions to low number and the older ones are deleted soon enough.
Currently I’ve set them to three in wp-config.php:

!defined('WP_POST_REVISIONS') && define('WP_POST_REVISIONS', 3);

afaik there is no other limit for number of revisions, but at some later point when revisions get deleted this bug could pop up and ruin day for many polylang users.

I’m looking at Polylang_Admin_Filters::delete_post and can’t understand why replace $post_id of revision with id of original post.
That is the point where it fails and deletes translation metadata of valid posts.