Replying to myself once more ;-) As I dont see much interest in this feature, let me tell the whole story. I have a bunch of old cms installs, where this feature was developed and used (pip install -e untranslated-placeholders-cms). The main reason there, was editor effectifness. I had the problem that editors were not willing filling out five languages of download sections, where only the download label needed translation. Also, "copy from language" and the like was not an option, because this means re-translating everything, when copied.
The solution I came up with, was untranslated placeholders, and, translated plugins (with hvad/modeltranslation/whatever). The editor fills the content (images/files/downloads!) only once. And only translates content that needs translation (ie TEXT). Only one plugin exists, for all languages. I wont get this specific client back to use normal cms behaviour. In the worst case, I'll again use a patched cms. In the best case, we'll have untranslated placeholders some time. But, most important, I can see a solution where untranslated placeholders could easily be achieved: Just always displaying fallbacks, also in edit mode! This could be a simple placeholder setting "editmode_language_fallback", next to the existing "language_fallback". It doesnt have to deal with page dirty/not dirty and other problems, then. Only drawback, more queries would probably be used, but I could live with that... some examples: https://www.welt-der-messer.ch/de/presse-partner/veroeffentlichungen/ https://www.welt-der-messer.ch/de/presse-partner/sknife-swiss-knife/sknife-pressemitteilungen-bilder/ same for image/galleries https://www.welt-der-messer.ch/de/info-service/engagement-leidenschaft/gusto/ I really would appreciate a feedback. Best 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 [email protected] --- 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 [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/django-cms-developers/4d365b45-0e96-4782-b507-bf8834c35d2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
