untranslated placeholders
33 views
Skip to first unread message
benzkji
Nov 25, 2016, 2:21:37 AM11/25/16
to django CMS developers
Hi there
I started working on "untranslated placeholder".
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
benzkji
Jan 10, 2017, 10:11:20 AM1/10/17
to django CMS developers
...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
benzkji
Jun 16, 2017, 5:12:39 AM6/16/17
to django CMS developers
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:
same for image/galleries
I really would appreciate a feedback.
Best
Ben
On Friday, 25 November 2016 08:21:37 UTC+1, benzkji wrote:
Reply all
Reply to author
Forward
0 new messages