Closed ghost closed 10 years ago
Nevermind, just ended up using gedmo strategy.
I urge you to reconsider. The Gedmo Translatable behaviour has a lot of issues. It's standard behaviour is terribly slow because it does not use foreign keys. It's personal translations are somewhat faster but has a lot of bugs and egde cases.
The Prezent Translatable and others like it (Like the KNP extensions) are much faster and less buggy. They work just fine with the Gedmo Sluggable behaviour. One of the goals in setting up Prezent Translatable is being able to use other behaviours like Sluggable. In Prezent Translatable, translations are just plain old doctrine entities, so all behaviours should work with them. I have used Prezent Translatable and Gedmo Sluggable together in several projects and it works just fine.
Yeah, I saw your comment on stackoverflow about that and that's why I decided to try other strategies. I will definitely check them out on the next project (or this one, will see). :)
@sandermarechal I'm trying to use this in my project together with the gedmo sluggable behavior. When I create the entity with the default locale the slug is generated without problems, but when I switch to another language and change the the name
field, which is the one I use for the slug, it doesn't update to the new locale. I'd like to have a different slug per language, but for some reason isn't working. I think maybe the sluggable listener is not beign executed.
Do you have any suggestions to solve this?
Thanks in advance!
Sorry! It's working fine. It seems that I already need to sleep.
Hello, I am trying to get Prezent package working with a2lix translation. I am also using Gedmo sluggable behaviour which expects (sluggable) fields in the same class, but Prezent's translatable behaviour requires these fields to be moved to the translation class. Is it possible to use both? Or should I just stick to Gedmo's behaviours then?