How We Built AI Product Descriptions and Translation for Drupal Commerce

AI product descriptions for Drupal Commerce can start with one OpenAI request. A useful catalogue workflow needs more: it must know which product data to trust, which language version to update and which existing content to leave alone.

We faced those questions while building Factory.yllw.com, a multilingual B2B furniture marketplace. Some products had detailed descriptions, while others had little more than a title. The project began as a way to improve that content and grew into a controlled process for generating descriptions, translating product fields and keeping localized pages consistent.

Existing product data → AI description → field-level translation → localized title, URL and metadata

Why the Catalogue Needed More Than Automatic Translation

Translating an incomplete description only creates the same incomplete description in another language. Before working on multilingual content, we needed a stronger source text.

The first version relied mainly on the product title and existing description. It worked when the source content was detailed, but sparse products left too much room for interpretation. The result could sound convincing while making the wrong connection between a product, its brand or its designer.

How the AI Description Is Created

The original product title is entered through the normal catalogue workflow. OpenAI does not invent or replace it.

When a product needs an improved description, Drupal collects the information already available for that product:

• the title and existing description;
• the product category;
• the brand;
• the designer or another relevant attribution.

Together, these fields form a small product brief. The category tells the model what kind of item it is describing. Brand and designer data help prevent one from being mistaken for the other. The prompt also prevents unsupported materials, dimensions, colours, options or environmental claims from being added.

The generated copy is saved in a separate AI description field. The original description remains available for reference and editorial review.

How Titles and Descriptions Are Translated

Description generation and translation are separate operations. After the improved description has been created, the system checks every target language and each relevant text field independently.

1. Product title. The existing source title is translated. OpenAI is not asked to create a new product name.
2. Original description. The regular product description is translated so the source information remains available in each supported language.
3. AI description. The improved copy is translated separately and stored in the corresponding language version.

Before requesting a translation, the system checks the current field value. An empty field can be filled. A field that still contains an untranslated copy can be repaired. A distinct existing translation is preserved.

Titles need one additional check. Brand names, model names and product series can legitimately remain identical across languages. An unchanged title is accepted only when it has been identified as a name that should stay the same. This prevents both missing translations and unnecessary changes to real product names.

Keeping the Whole Product Page in One Language

A translated description is useful only when the rest of the product page belongs to the same language. After a translated title is saved, Drupal can use it to create a localized URL. A customer should not see a translated name and then open a path based on another language.

Metadata follows the same rule. When an AI description is available, its summary can provide the localized meta description. The regular product description remains the fallback.

The resulting language version keeps the title, original description, AI description, meta description and product URL aligned. When an old URL changes, a redirect can preserve the previous address. Those localized fields also support the multilingual product discovery described in our Clerk search integration.

This is not a promise that AI content will automatically rank. It gives customers and search engines a more complete language-specific product page. The Drupal Commerce product architecture provides the multilingual foundation; the integration defines when and how the content is updated.

Processing New Products and the Existing Catalogue

Running the complete catalogue through OpenAI after every update would create unnecessary requests and make the work difficult to control.

New and changed products are handled individually. Drupal checks whether relevant source information changed and whether generation or translation is actually required. Historical products follow a separate backfill process, so improving old content does not delay a product that has just been created.

The work is divided into bounded batches. Duplicate requests are avoided, historical processing can pause when the website is busy, and a temporary API failure can be retried without blocking the original product update.

Why We Used Different Models for Writing and Translation

We used GPT-5 for original product descriptions because this task required more than rewriting a title. The model had to combine the available product context, follow catalogue-specific rules and avoid adding unsupported details. This was the part of the workflow where stronger reasoning and writing quality mattered most.

Translation was a different kind of workload. Once the source content had been generated or approved, translating product titles and descriptions became a more structured, repetitive operation across a large catalogue. We used GPT-4o mini for this work because it provided the required consistency at a considerably lower cost.

Using GPT-5 for every translation would have increased the cost without providing the same additional value. Both model choices can be changed directly from the Drupal administration interface without a code deployment, allowing the client to adjust the balance between quality and cost as the catalogue grows or model pricing changes.

For the client, the result was not simply more AI-generated text. It was a controlled catalogue workflow: stronger source descriptions, lower-cost translation at scale, preserved editorial work, and model choices that could be adjusted directly from Drupal administration.

Editors Still Control the Result

Catalogue automation should reduce repetitive work, not make editorial decisions invisible.

Content managers can review generated descriptions, choose prompts for different kinds of products and regenerate selected items. A corrected product does not require the entire catalogue to be processed again, and reviewed translations are not silently replaced during the next automatic run.

What We Would Keep on the Next Project

• Start with structured product data, not a title alone.
• Keep description generation and translation separate.
• Translate titles and descriptions field by field.
• Preserve existing editorial content by default.
• Treat metadata and localized URLs as part of translation.
• Process current changes separately from historical backfill.
• Keep review and selective regeneration available to editors.

Frequently Asked Questions

Can OpenAI generate product descriptions directly in Drupal Commerce?

Yes. Drupal can collect the title, description, category, brand and designer information, send that context to OpenAI and store the result in a separate product field. The source catalogue content remains available for review.

Does AI replace the original product title and description?

No. The source title remains the catalogue’s source of truth, while improved copy is stored separately. For additional languages, OpenAI translates the existing title and descriptions rather than inventing a new product name.

How do you prevent AI from overwriting correct translations?

Every field and language is checked separately. Empty or clearly untranslated content can be processed, while an existing distinct translation is preserved.

Can AI-generated product descriptions help with SEO?

They can make sparse product pages more complete and provide material for localized metadata. Their value still depends on accuracy, usefulness, technical SEO and how well the page answers the customer’s search intent.

How can a large catalogue be processed safely?

New product changes should be separated from historical backfill. Bounded queues, duplicate detection and load-aware pauses allow older content to improve gradually without delaying current catalogue work.

AI Works Best Inside Clear Boundaries

OpenAI handles the writing and translation tasks that Drupal explicitly assigns to it. Drupal Commerce remains responsible for the product, its language versions and the content that editors have already approved.

That boundary is what makes the automation useful. The catalogue can improve without turning every product update into an uncontrolled rewrite.