Development Choices

Produce multilingual asset metadata with automation

Author
Joseph TrasattiMember of technical staff
Published
Section
No-Code
Length
7 min read3 sources cited

Generate each served locale’s description directly from the image, store it in a dedicated metadata field, and track completion per language. Route decorative images around generation so every locale emits an empty alt attribute. Leave unsupported locales empty, and retry one failed language without touching successful descriptions.

Prerequisites

Before building the flow, fix the list of locales the site actually serves. You also need a metadata schema you can change, a way for an editor or upstream system to mark an image as decorative, and an image-description operation that accepts both the image and a target language. A generator that can only describe in English does not meet the requirement: putting a translation block after it preserves the English description’s omissions.

Build the flow

  1. Classify the image before calling a model

    Add a decorative flag to the asset record and make it the first branch in the flow. This decision belongs before language selection or description generation.

    The W3C alt decision tree, updated 13 May 2024 says that a purely decorative image should use an empty alt attribute. That remains true in every language. When decorative is true, skip every generation branch and make the delivery layer emit alt="". Do not generate prose merely to fill a metadata field.

    The same classification step should keep functional and complex images out of a simple captioning path. A functional image needs text that communicates its action or destination; a complex image may need its information in the page content. Pixels alone do not provide that page context. Route those cases to an editorial task instead of pretending the generator has enough information.

    This branch is the necessary starting point for any broader alt-text generation flow. Without it, automation spends work on images that require no description and can produce an accessibility regression by making decoration sound meaningful.

  2. Select only the locales the site serves

    Pass the asset into a fixed list such as the locale configuration used by the publishing application. Do not generate every language offered by the model or translation provider. Locale coverage is rarely uniform, and unsupported languages create text that nobody is assigned to review or publish.

    Generate metadata for the languages the site actually serves and leave the corresponding field empty everywhere else. An empty field exposes a real coverage gap when a new locale is added; a weak or unreviewed description hides that gap behind apparently complete metadata.

    This choice also sets the execution count. For one informative asset and L served locales, the normal run performs L image-aware generations. A retry for one locale performs one more. No latency or price per run is verified here, so calculate the provider-specific bill using that invocation count and the method in the hosted automation cost breakdown.

  3. Create separate metadata and state fields per language

    Store each language in its own field: for example, alt_en, alt_fr, and alt_ja. Never use one alt field that the flow overwrites as it moves through locales. A shared field leaves the asset able to serve only the language written last, regardless of how many descriptions the flow generated.

    Add a matching state field for every description field, such as alt_en_state. At minimum, the state model must distinguish not attempted, in progress, usable, retryable failure, and deliberately skipped. The exact labels matter less than their scope: state belongs to the (asset, language) pair, not just the asset.

    Cloudinary’s structured metadata documentation, last updated 4 June 2026 describes typed fields that can be populated through the Media Library or programmatically, with validation and default values available. It also documents a maximum of 100 structured metadata fields per product environment. A schema with one description and one state field per locale consumes 2 × L fields, plus the decorative flag and any review fields. Count that budget before committing to the design. Do not make description fields mandatory, because unsupported locales and not-yet-generated values must remain empty.

    Separate fields cost more schema space and configuration work than a locale-overwritten value. They are still required when more than one language must be available at the same time. If the locale count makes the field model unmanageable, that is a concrete sign to consider moving the automation into code with a metadata store designed for locale-keyed records.

  4. Generate every description from the image

    Fan the same source image out to one generation branch per selected locale. Each branch receives the image and its target language, then writes only to that language’s description field.

    Direct, image-aware descriptions beat translating an English description after the fact. The English pass has already selected which objects, relationships, text, or visual emphasis to mention. Translation can restate that selection in another language, but it cannot recover visual context that the English description omitted. Generating from the image again gives every language branch access to the evidence it is meant to describe.

    Cloudinary’s sample multilingual alt-text PowerFlow, last updated 21 July 2026 uses an upload trigger, creates one caption, sends that caption through Google Translate blocks, and writes language-specific contextual metadata keys. Its trigger and per-language write pattern are useful, but its translate-after-caption mechanism is not the architecture required here. Replace that middle section with image-to-description branches that each receive the original asset and a locale instruction.

    The tradeoff is explicit: L locales require L image-aware generation runs rather than one visual description followed by translations. Do not claim that this is cheaper or faster. It is chosen because each result retains access to the image.

  5. Update text and state without touching sibling locales

    At the start of a language branch, change only that locale’s state to in progress. When generation succeeds, write the new description before marking that locale usable. If generation fails, retain any previously usable description and mark only that locale for retry. Never clear the other locale fields as part of error handling.

    This isolation is what makes regeneration safe. Regenerating French must not invalidate English or Japanese, so the retry trigger takes both an asset identifier and a locale. An asset-level generated flag is insufficient: it cannot express that two languages succeeded while a third failed, and it encourages a retry to rerun or replace every result.

    Treat a changed source image as a different event from a failed locale. A locale retry reuses the same image and changes one language. Replacing the image removes the visual basis for all existing descriptions and therefore needs a separate review or regeneration path.

  6. Keep the payload and fallback policy narrow

    Send the generator the image, the target language, and only the context required to describe the image’s role. Do not pass uploader details, internal notes, or unrelated asset metadata simply because the flow can access them. The practical review method in data minimization for no-code flows applies at every branch, because adding locales multiplies each unnecessary disclosure.

    At delivery time, read the field matching the page locale. Do not copy one locale into all empty fields to make the record look complete. If a locale is not served, leave its field empty. If the site begins serving it later, generate and review that locale before treating coverage as complete.

  7. Test the state transitions, not just the happy path

    Run a small matrix that proves each branch changes only the fields it owns:

    Test condition Expected result
    Decorative image No generation calls; delivery emits an empty alt attribute in every locale
    Informative image with three served locales Three image-aware generations; three separate description and state pairs
    One locale fails Successful locale fields remain usable; only the failed locale is retryable
    Failed locale is retried Only that locale’s description and state change
    Locale is not served No generation branch runs; its field remains empty
    Functional or complex image The simple description path stops and sends the asset for contextual handling

    Inspect the stored metadata after each run rather than relying on a green flow status. A flow can finish while one branch has written to the wrong field, overwritten a sibling locale, or marked an empty result usable.

Expected result

Done means every informative asset has an independently generated, independently retryable description for each locale the site serves. Decorative assets bypass generation and render with an empty alt attribute in every language. Unsupported locales remain visibly empty, and regenerating one language changes neither the text nor the state of any other language.

Sources

  1. W3C alt decision tree, updated 13 May 2024w3.org
  2. structured metadata documentation, last updated 4 June 2026cloudinary.com
  3. sample multilingual alt-text PowerFlow, last updated 21 July 2026cloudinary.com

See also