When a node is translated it's tnid is set to it's own nid. When this node is deployed for the first time (eg. via uuid_services) to a forward environment, the tnid is translated to a uuid when it is loaded for deployment but then that tnid is translated back to a normal nid in hook_entity_uuid_presave()
. This is too early, because the node itself hasn't been saved so the node uuid is not in the database yet.
There's no way of being certain of what nid the node will get when it's saved, so the localisation of the tnid in this scenario will have to move to hook_entity_uuid_save()
(after the node has been saved). However, this will require an additional db query, which is a shame, and in most cases this won't be necessary, as it is only an issue for new nodes that are a translation source.
I will shortly attach a patch that I think solves this reasonably efficiently.
Comment | File | Size | Author |
---|---|---|---|
#1 | localise-tnid-post-save-1795152-1.patch | 1.33 KB | jamesharv |
Comments
Comment #1
jamesharv CreditAttribution: jamesharv commentedIt's still worth attempting to localise the tnid in
hook_entity_uuid_presave()
since in most cases that will still work. If it fails the tnid property simply retains the uuid value it already had - no harm done.So then, in this patch, I check whether the tnid property contains a valid uuid. If it does then I translate it to a local nid and do a
db_update()
to localise the value in the database. In this way I avoid the second database operation unless absolutely necessary.Comment #2
jamesharv CreditAttribution: jamesharv commentedUpdating status
Comment #3
mgiffordPatch still applies nicely to the git repo. Internationalization is important for a lot of us. What's the best process for testing this module?
Comment #4
jrbeemanI have validated this patch in my deploy_test testing profile.
Comment #5
skwashd CreditAttribution: skwashd commented@jamesharv thanks for the patch.