clarify translation event

[dbu]

@ElectricMaxxx said:

my intention was to stay close to the normal events. So as an PostUpdate is fired after the flush
(when it is really really done) all Post*Translation Events should do same, or?
On the other hand a translation binding stays a little bit outside the persistence lifecycle, but is really > done after flush too.

the question that arose was: what exactly should the event tell? bindTranslation was called by the user? or translated fields changed (this would be weird, as that is part of the document changed, and i don't see a semantical difference between translated and untranslated fields in that regard)? i think what makes most sense is an event when a new translation was created or is removed. regardless of whether it was explicitly created or implicitly when a new translated document is first persisted.

Will have a look at the names and orders of translation events at the weekend again. Maybe we
can make it more clear (in the docs too). Change was done in this version right? BC-Break?

thanks. i think we need to be more clear what exactly the event signifies, re-thinking what a reasonable use case is. and as we added this in a previous RC of this version we can still fix it until we release the stable version.

see also the (now hidden) discussions in #556

[ElectricMaxxx]

To get an overview, we have the following events for translation atm:

    const postLoadTranslation = 'postLoadTranslation';
    const preBindTranslation = 'preBindTranslation';
    const postBindTranslation = 'postBindTranslation';
    const preRemoveTranslation = 'preRemoveTranslation';
    const postRemoveTranslation = 'postRemoveTranslation';

and i realized that the preBindTranslation/postBindTranslation just wraps the insert into the documentLocale mapping, no waiting for the flush. I can't remember why but i had it after flush as i implemented the events (created a memory mechanism for stacking the events), @dbu said something against it.
preRemoveTranslation/postRemoveTranslation is different. postRemoveTranslation is done a little bit later.

[dbu]

what if we would rename pre/postBindTranslation to pre/postCreateTranslation? and define the semantic that it only(but always) occurs when a new translation is created, even for the first translation?

[ElectricMaxxx]

You mean just rename, without any changes of the position? What would be the difference? What is the problem with *BindTranslation as the method call is DocumentManager::bindTranslation()?

[dbu]

we call bindTranslation from changeset calculation at some point in some situations. and the question is whether you want the event not only on creating but also on updating translations, and whether you also want it when normal saving triggers the method or not. if you care about translations being added, having a CreateTranslation event even when persisting a new document seems helpful to me.

[ElectricMaxxx]

@dbu then it would be nice to have a UpdateTranslation too, but we would need access the translation changeset. On the other hand: binding a new translation is a CreateTranslation too. And a update in the list of available translations.
Have no clue where to find the moments to fire them but i would suggest:

• preCreateTranslation before binding a new Translation - even on persist new
• postCreateTranslation after binding a new Translation - even after persist new
• preUpdateTranslations before every change on the list of Translations - create/bind and remove a translation
• postUpdateTranslations after every change on the list of translations - create/bind and remove translation

Doing that, we would have access to the lifecycle of the single Translation and on the collection of translations.

Edit:
i would suggest to pass a list of translations through the event.

[lsmith77]

i dont think that we should have a translation update specific event. events cause general overhead. there is an update event, it contains the translation fields and there is the metadata available to figure out which field is translateable.

[dbu]

agree with lukas that we should not need a translation specific update event. so maybe the way to go is to keep bindTranslation with its somewhat strange semantics of being triggered when the user calls bindTranslation but deprecate that, and add the createTranslation event with the new semantics. then we can remove bindTranslation later on, keeping a good naming and having the BC break very explicit (tuning the semantics of the existing bindTranslation seems like a bad idea to me now that i think about that)

[lsmith77]

that is not really possible .. the issue is that we are now calling bindTranslation in new cases, so there is a BC break already .. so to me the choice is leave name as is or rename to make the BC break more explicit

[dbu]

if we keep your logic that you added to supress the bind event in the bind method, it would not be hard to move to the old logic, no? if its too much pain, i would prefer renaming the event to make the BC break explicit and have a good semantic name (this needs a bit of refactoring i think, as right now bindTranslation is not triggered when a new document is persisted)

[lsmith77]

honestly I do not have sufficient tests to really know when the event was previously fired .. it may or may not only have been fired when a translation was added .. it might however also be fired in other situations.

[dbu]

lets rename and clean up the semantics and hope that not too many people have been using it.

@ElectricMaxxx did you rely on this being fired for non-creation?

[ElectricMaxxx]

There are tests for the translation events. Right in the test where the normal events are tested. Need to check them.

Normally the bindTranslation Events are fired around the setting of the translation to the changeSet - no flush before postBindTranslation. That Situation is hard to test as both events are fired when calling $manager->bindTranslation(). =