This is related to #1123
Fixes two things:
plugin editor js gets language from django-hvad current language tab (title on a span). This way plugin gets added in the correct language, if using django-hvad. Related to KristianOellegaard/django-hvad#76
As stated in #1123 , admin currently shows all placeholder languages. I have tried to implement the proposed solution from ojii (only admin part). But maybe is not the correct way and should be revised.
It works well for me (django 1.4 and django-cms develop trunk)
Plugin editor integration with django-hvad. Gets language from hvad c…
…urrent admin language tab
admin filters PlaceholderField plugins if placeholder is language_aware
This pull request passes (merged 413ef22 into 4605250).
I'm just subscribing myself
I really hate how this is so tied to django-hvad. Is there really no sane other solution?
We have a real issue with the CMS: there's this fabulous plugin/placeholder architecture at its core, and although it can be (beautifully) deployed in other applications, the lack of multilingual support in any application other than CMS is a significant problem.
hvad/nani looks like one of the most promising solutions to the multilingual issue, but unless I am badly misunderstanding this patch, it isn't going to address the problem that the CMS faces, at least by itself.
Just to make one thing clear: Placeholders already have support for i18n built in.
The problem with that is that there's no real way in PlaceholderField (or other APIs) to harness that power the way the CMS does.
If you have a model that uses for example django-hvad, the PlaceholderField should NOT be in the translated fields section, but rather on the shared model.
What we need is a good way to tell the placeholder what language it is in (in the admin), optionally what languages there are (for the copy feature).
The PlaceholderActions I introduced were a horrible idea and should be removed.
Then we need a good way to tell the placeholder what plugins to render in the frontend (usually d.u.t.get_language is fine, but sometimes we just want to ignore the language or override it).
Wouldn't it be better to get the language from request.GET or request.LANGUAGE_CODE instead from some html parsing?
I think not, digi604, because its not the current language of the request what is needed, but the language in which an hvad-translatable model is being edited... that's why its added to the currently selected language tab in hvad (KristianOellegaard/django-hvad#76).
@rafadev yeah i know but isn't the language give by a ?language=de url aka GET parameter? (never used hvad... ducks behind the wall)
fixed in develop