Skip to content

Integration of PlaceholderField with django-hvad (using translations with PlaceholderField) #1403

Closed
wants to merge 2 commits into from

7 participants

@bercab
bercab commented Aug 20, 2012

This is related to #1123

Fixes two things:

  1. 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

  2. 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)

note: javascript language selection will need pull request KristianOellegaard/django-hvad#76 accept (or similar) in django-hvad.

@bercab bercab referenced this pull request in KristianOellegaard/django-hvad Aug 20, 2012
Closed

Adds current language code for django-cms plugin editor #76

@travisbot

This pull request passes (merged 413ef22 into 4605250).

@KristianOellegaard

I'm just subscribing myself

@digi604
Divio AG member
digi604 commented Nov 14, 2012

needs docs.

@ojii
ojii commented Nov 14, 2012

I really hate how this is so tied to django-hvad. Is there really no sane other solution?

@evildmp
evildmp commented Nov 14, 2012

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.

@ojii
ojii commented Nov 14, 2012

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).

@digi604
Divio AG member
digi604 commented Mar 29, 2013

Wouldn't it be better to get the language from request.GET or request.LANGUAGE_CODE instead from some html parsing?

@rafadev
rafadev commented Mar 29, 2013

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).

@digi604
Divio AG member
digi604 commented Apr 6, 2013

@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)

@digi604
Divio AG member
digi604 commented Apr 9, 2013

fixed in develop

@digi604 digi604 closed this Apr 9, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.