...in the meantime. I've created a proof of concept repo (https://github.com/benzkji/djangocms-untranslated-placeholders), that uses the code from my pull request. some things I learned/discovered:
- it works already quite well - untranslated plugins are still added with a language_code. this would not be a problem, but... - when it comes to publishing, a page with untranslated plugins can only be published in the language the plugin was initially added (state/dirty problem). I don't see any other issues for now, but would be glad if some of you core devs could have a look at it - I remember a short discussion with ojii a few years ago, where he said it would be easy and a 10min job ;-) thanks for your time ben On Friday, 25 November 2016 08:21:37 UTC+1, benzkji wrote: > > Hi there > > I started working on "untranslated placeholder". > https://github.com/divio/django-cms/pull/5675 > > Quoting myself: This is a proposal, how a "untranslated" setting could be > added to the placeholder config. untranslated placeholders would just > ignore the language field on plugins, and always show all plugins. Typical > use cases: Header images, and other "non language specific content". I'm > aware that almost the same can be achieved with language_fallbacks, but IMO > it's worth it, as it makes the UI more clean for those use cases. Differences > to language fallbacks: Fallbacks need to be defined, untranslated just is > untranslated. Also, fallback plugins are not shown in edit mode (so one > could add a plugin, and no more fallback would be needed), wereas > untranslated plugins are visible in any language, also in edit mode. > > I can see Paulos point on complexity, as every feature you add will add > complexity. Concerning the performance hit though, I'm not yet sure which > way this would go. Sure, if you only have translated placeholders, and no > fallbacks, this will be +1 query on every page hit for getting untranslated > plugins. But. If you have at least one fallback placeholder, things will go > the other way quickly - depending how many fallbacks there are, there will > be more querys. amount_of_fallbacks * amout_of_fallback_placeholders, in > the worst case, as far as I can see. Compared to only one more query, when > using untranslated mode. > > The argument that it can be done with fallbacks is valid. But I had to > explain to customers "you need to change to the main language, to edit the > header image" when using fallbacks for header images (fallbacks are not > considered in edit mode, as one would expect), so this could be much more > cleaner, from an end user view. > > As written in the PR, I'm not really aware what more would be needed to > change to make this fully functional... > > > Cheers > Ben > -- Message URL: https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id Unsubscribe: send a message to django-cms-developers+unsubscr...@googlegroups.com --- You received this message because you are subscribed to the Google Groups "django CMS developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-cms-developers+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/django-cms-developers/84b97ddb-bc03-40af-80ba-38f8df320c77%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
