Running a French and English storefront when the item description lives in Acumatica

Yes, and this is worth stating clearly because the folklore says otherwise. Acumatica’s Locales and Languages help page, read on 20 August 2026, says “You can translate user input to multiple languages and store translations in the database”, and gives the example of General Ledger account descriptions entered in several languages so a localized trial balance can be printed. The page names rich text editors, and specifically the stock item description on form IN202500, among the boxes with multilanguage support.

The mechanism is per-box rather than global. Acumatica does not publish a full list of supported boxes on that page; it points at a separate list of boxes that have multilanguage support. So the first thing to establish for your own catalogue is not whether Acumatica can do it, but whether every field your storefront needs, description, short description, attribute values, category names, is on that list.

The translated values are stored in the database rather than in the field itself, which is why the community thread on this topic starts with someone who has the data and cannot get at it.

In Acumatica community thread 5165, in the Distribution forum, a user wanted to print a sales order report showing the item description in two languages at once. He had found the data, naming the table where the translations live, and could not find it in the Report Designer. The answer he got was a pointer to Acumatica’s S150 Report Designer training guide, pages 116 to 120, which covers translating a report into multiple languages, attached as a PDF extract.

That is a reasonable answer to the question he asked and it is not an answer to the question underneath it. Translating a report means rendering the whole report in one locale. Showing two languages side by side on one document, which is what a bilingual Canadian packing slip or quote actually needs, is a different job. The thread has a follow-up roughly two years later, which suggests it was never cleanly resolved.

Read that thread as a signal about where the effort lands. The translations exist in the database; the tooling for getting them out in the shape a bilingual business needs is thin.

We do not have evidence either way, and we are not going to invent it. We found no Acumatica documentation and no community thread confirming that the Shopify or BigCommerce connector exports a locale-specific item description, and none confirming that it cannot. There is a thread title in the Retail and Commerce forum about variant option names and language sync, which suggests the language dimension does not travel cleanly, but a thread title is not a finding.

So this is the single most important thing to test in a sandbox before you commit to an architecture. Enter a French description on one stock item, sync it, and look at what arrives. If the French value arrives, you have options you would not otherwise have. If only the base-locale value arrives, the decision below is already made for you.

Ask your VAR to run that test rather than to answer the question. It takes twenty minutes and it removes the largest unknown in a bilingual project.

For a French and English Canadian storefront the architecture that holds up is to split the job by what each system is genuinely good at. Acumatica owns the identity of the item, the price, the stock and the tax treatment, in one language, because those things are language-neutral or nearly so. Marketing content, which is where the translation work and the review cycle actually are, lives where translators can work on it.

Every commerce platform in the mid-market has a translation model. Shopify has markets and translated content, BigCommerce has multi-language storefronts, Drupal Commerce has a full content translation stack because Drupal was built multilingual. All of them assume you will maintain the translation there, not in the ERP.

The comparison below is about who does the work, not about which is technically possible. Both are possible. They cost very different amounts in the third year.

Two things that do not come up in the American-authored guidance. First, your obligations do not stop at the product page. Quotes, order confirmations, packing slips and invoices are documents your customer receives in the language they do business in, and those come out of Acumatica, not the storefront. A plan that translates the website and forgets the documents solves the smaller half of the problem.

Second, the item description is rarely the hard part. Attribute values, category names, unit labels and the words on the buttons in a quote flow are all content, and a platform’s translation model covers those while an ERP field-level translation does not. Scope the translation job by counting the strings a customer sees, not by counting the products.

If you are weighing platforms for a bilingual catalogue, the questions that move the answer are how many locales, whether both are equal or one is a fallback, and whether documents have to match. The Celeste diagnostic asks the first two and we would want to talk about the third.