Making p.a.multilingual immune to careless editors

In my organization, editors are creating content which may have translations using p.a.multilingual. Some content may include logos and labels which themselves are available in multiple languages. This is accomplished by adding an images-[lang] folder in each language folder and mirroring its substructure across languages. In the content types, editors can select the images to include using a RelationList field such as this:

    <field name="marketing_labels" 
           type="z3c.relationfield.schema.RelationList" 
           lingua:independent="true">
      <description />
      <required>False</required>
      <title>Marketing Labels</title>
      <value_type type="z3c.relationfield.schema.RelationChoice">
        <title>Relation Choice</title>
        <portal_type>
          <element>Image</element>
        </portal_type>
      </value_type>
    </field>

This results in the same-language image becoming displayed in translations when available, and defaulting to the site-default language when not.

The actual images to select from are few and mostly remain the same. Over time, new languages may be added to Plone, and I create a basic mirrored structure. At some later point, editors will upload translated versions of the images. It has now happened multiple times that they simply add a new folder to the images-[lang] substructure, rather than translating from an existing language. To make matters worse, the images contained in such a subfolder are also uploaded rather than translated...

In a following step, editors translate existing content and select their newly added image. Helpfully, and rightfully so, Plone then replaces this image in all translations. No-one notices for a while, and after some weeks or months I receive an email that documents contain images in the wrong language...

Even after marking the folder and contained images as translations and updating the "site-language" document with the original image, its translations which used to reference the language specific version of an image will also have to be updated - a messy and tedious affair.

Now, I would like to prevent my editors from being able to score such massive own-goals in the future. My initial thoughts go towards adding a behavior to folders which are contained in a LRF. This would add a flag "allow creation" to optionally prevent the addition of completely new objects in the hierarchy.

Does this seem to be a viable approach?

-Norbert

edit: fixed code snippet wrapping

Some outside the box thinking: what if you could detect when a translated image is uploaded in your images subfolders and it does not have a translation-relation on it's object?

When you packge this in a content rule condition, you can create a content rule that mails any content editor who uploads a 'bare' image with an warning/notification that they probably want to do something else.

When the image is created through 'translate', the content rule should not trigger.

Not an answer to your question, just "brainstorming":

Would it help if you did not use RelationChoice, but made your own vocabulary which only looked for "right language" ?

Maybe a vocabulary like this?

def CorrectImagesVocabulary(context):
        images = api.content.find(portal_type='Image', language='current language')
        if images:
            terms = [ SimpleTerm(value=img.UID, token=img.UID, title=img.Title) for img in images ]
        return SimpleVocabulary(terms)

And in your field

<field name="marketing_labels" type="zope.schema.List" >


  <title>Marketing Labels</title>
  <value_type type="zope.schema.Choice">
    <title>Choose image</title>
    <vocabulary>my.addon.CorrectImagesVocabulary</vocabulary>
   </value_type>
</field>

Thank you both for your replies!

@fredvd triggering a content rule could be another option to explore, yes. I am a bit wary of letting the editors "remember" to create the language relation after the fact. With the behavior, I could run an upgrade step which simply marks the specific folders where uploading is not allowed (e.g. no ambiguity because the "Add New.." icon would be missing from the interface).

In some places in the site, creating a new language specific content type is the intended behavior (e.g. adding a new customer in country/language X), so there the folder would accept new content.

@espenmn the widget allows editors to select images from the language specific image folder as well as the multilingual "Images" ("Assets" in recent versions of p.a.m.). Having it flexible like that is something I wouldn't want to lose. I guess I could extend the vocabulary results to include those images as well.

However, the problem with creating new content instead of using Babelview has also happened in other places for other content types (with less dramatic consequences) - I figure the new behavior would also prevent some of those errors. In fact, here the method suggested by Fred may be more useful.

The context of the item you edit is passed into your VocabularyFactory. You can do whatever you want there, including quering existing p.a.m relations, the language etc. to generate the vocabulary you returned.

I once created a vocabulary where the results were shown in a selectwidget, but the choices were based on attributes set on all the parent folders of the item you were editing.