On Oct 15, 2:37 am, oth <[email protected]> wrote:
> Hello mate, yeah
>
> I'm taking up on a project I didn't started, they have 4 languages.
> lots of tables ( it's a CMS )
> They first thought all articles will be translated only to figure out
> later it's impossible. So when a visitor browse the website in a
> language ( say english ) and he founds arabic articles he gets
> confused.
> and that is understood. I should probably edit the behavior to behave
> as expected for some specific models.
I guess your least effort solution is going to be editing (or
configuring, if it is actually possible) the translate behavior to
remove the fallback content logic.
You could change the default translate language to be the current
locale - that would also limit the translate behavior to return only
articles in the current locale. I haven't tried that, but I'd expect
it to work (Tbh I have found the EAV nature of the translate behavior
to rarely be useful).
A hybrid solution which would allow you to leave your existing admin
functionality as is, and only require relatively trivial changes for
the public viewing would be to use a "materialized view" approach.
1) Save the sql cake is generating for a find all on the translated
table
2) tweak it if necessary a bit
3) run create table posts_ar as {sql from 1+2}
4) When looking arabic-only posts, look in posts_ar
That would mean only the admin users use the relatively-complex sql
the translate behavior generates, and all public queries don't use the
traslate behavior and just look in flat tables. Don't consider doing
the above using just a db-views - you can't add indexes to a view so
performance degrades as soon as you add a SORT or WHERE or JOIN that
turns the view into a query that requires a tmp table. The only
downside to using this kind of approach is the db gets bigger and the
materialized-views probably need to be treated as readonly (or updates
need to be done twice, once on the source and once on the materialized-
view).
As you can tell, I really favor making the public queries as simple as
posible and moving any complexities to be triggered by, and only
affect, admin users.
Anyway, food for thought.
AD
--
Our newest site for the community: CakePHP Video Tutorials
http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others
with their CakePHP related questions.
To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/cake-php
