How We Built Multilingual Clerk Search with Drupal Commerce Pricing

Clerk search for Drupal Commerce becomes more complicated when the same product can have a different price for each customer and must be presented consistently across multiple languages.

That was the challenge we faced on Factory.yllw.com, an established Nordic B2B furniture marketplace. The existing Drupal search did not provide the product-oriented experience the marketplace needed, so we selected Clerk as the search foundation.

Clerk gave us instant results, a dedicated search page and customizable product cards. Our main task was making those results behave like the rest of the Drupal Commerce storefront: show the correct price for the current customer and stay within the language context selected on the website.

Why we moved beyond the existing Drupal search

The marketplace needed more than a list of matching titles. Customers expected search results to look and behave like real product cards, with images, prices, availability and direct links to the correct product page.

Drupal can provide this through Search API, Views and custom rendering. However, building the complete experience would also mean developing the instant-search interface, maintaining result templates and setting up the indexing workflow.

Clerk already provided that foundation. Drupal could synchronize its catalogue with Clerk, while Clerk handled indexing and returned the relevant products.

This allowed us to concentrate on the part that was specific to the marketplace: connecting Clerk to the business rules already implemented in Drupal Commerce.

How the Integration Works

1. Drupal synchronizes stable, localized catalogue information with Clerk.
2. Clerk finds the products that match the customer’s query in the active language.
3. Drupal Commerce resolves the appropriate price and availability presentation for the current customer.
4. The search result combines Clerk’s relevance with Drupal’s pricing, access and language context.

Keeping Drupal Commerce as the Pricing Authority

We separated the information needed to find a product from the information needed to present it to the current customer.

Clerk continues to receive stable catalogue information such as product references, localized names, images, categories, searchable attributes and translated URLs.

Drupal Commerce remains responsible for the current selling price, customer discounts, currency formatting, customer-specific commercial conditions and unavailable-price states.

When Clerk renders search results, Drupal provides the current price presentation for the visible products. The calculation follows the same pricing and access rules used by the rest of the storefront, and the resolved presentation is applied to the corresponding search result.

Search and the product page therefore no longer maintain separate versions of the pricing rules. They both rely on Drupal Commerce for the price that applies to the current user.

If Drupal cannot resolve a price safely, the result displays a localized “Price unavailable” message instead of falling back to a potentially outdated indexed value.

Keeping Customer-Specific Results Private

A price calculated for one customer organization must not be reused for another visitor. Customer-specific results are therefore kept private and remain within the current visitor’s context.

Drupal also remains responsible for deciding whether the current visitor can view a product. Clerk finds relevant catalogue entries, but it does not replace the commerce platform’s pricing or access rules.

Language Selection Was More Than Interface Translation

Pricing was one half of the integration. The other was language.

The marketplace operates across several Nordic language contexts. Changing the website language had to affect the complete search experience, not only labels such as “Search results” or “Show all.”

The selected Drupal language determines which localized product information is searched, which title is displayed, which customer-facing messages are used and which version of the product page is opened.

Without that coordination, a customer could search in one language, see product information in another and open a different language version of the product page.

Keeping Clerk Search Within the Selected Drupal Language

We designed the search catalogue to carry localized product information for every supported language and connected each search request to the active Drupal language. The content workflow behind those localized fields is covered in our AI product descriptions and translation case study.

This allows Clerk to use the correct product information for the current context. The result card displays the appropriate title and customer-facing text, while its link opens the corresponding language version of the product page.

Drupal also supplies localized messages for price and availability states. A dynamically resolved price therefore does not introduce text from another language into an otherwise translated result.

This was especially important because pricing and language could not be treated as independent features. The correct number was only part of the expected result. Currency presentation, supporting text and the destination URL also had to belong to the same regional context.

Testing Price and Language Together

Pricing and localization could not be tested independently. A price might be correct in one language context but formatted incorrectly in another. A product could appear under the correct translated name but open the wrong product URL.

Our main QA flow was straightforward:

1. Select a supported language.
2. Search for a known product.
3. Verify its translated title and result URL.
4. Compare the search price with the product page as the same user.
5. Repeat the process for different customer and currency contexts.

We also checked anonymous visitors, authenticated customers and internal users. Customer pricing and unavailable-price states had to remain consistent across both instant search and the full results page.

This testing exposed problems that would not have been visible by inspecting synchronized catalogue data alone. A successful synchronization confirms that the search service received information. It does not confirm that a real customer sees the correct price, language and destination.

What Changed for Customers

• Search results and product pages now rely on the same pricing rules for the current customer.
• The selected language remains consistent across the query, result content, messages and destination URL.
• When a valid price cannot be resolved, the interface shows a localized unavailable state instead of an outdated value.

What We Learned

The most important decision was determining which system should own each type of information.

Search indexes are well suited to stable catalogue data. Customer-specific prices belong to the commerce application that has the complete customer and regional context.

The same principle applies to language. Translating the search interface is not enough. The query context, product information, messages and destination URL must remain aligned throughout the customer journey.

For similar B2B e-commerce integrations, we would recommend:

1. Keep personalized pricing in the commerce platform.
2. Use the same pricing rules in search and on product pages.
3. Synchronize localized product information rather than translating only the interface.
4. Keep every search request within the active language context.
5. Verify where each result link takes the customer.
6. Test pricing and language together using real customer scenarios.
7. Prefer a clear unavailable state over an outdated or contextually incorrect price.

Clerk gave us the search foundation the marketplace needed. Drupal Commerce continued to provide the pricing, customer and language context that made each result correct.

The integration became reliable once we stopped trying to make either system replace the other.

Clerk finds the relevant product. Drupal Commerce ensures that the customer sees it with the appropriate price and in the appropriate language.

If your Drupal Commerce project needs to connect an external search service without duplicating the business rules you already trust, our custom Drupal development team can help design the integration around the platform.