How to Translate a Product Catalog in Excel Without Retyping a Single Cell

A product catalog is the most awkwardly shaped document most companies ever have to translate. It is not prose. It is a grid of two-word fragments, part numbers, unit abbreviations and the occasional paragraph of marketing copy, with formulas and dropdown lists pointing at all of it. When someone asks us how to translate a product catalog in Excel, the real question is usually narrower: how do I get the Spanish file back without breaking the workbook our ERP reads? That part is solvable, and it has more to do with how you prepare the file than with which translation engine you pick.

Why catalogs break before anyone translates a word

More catalog projects go wrong in preparation than in translation. Someone exports from the ERP or the PIM, sends the .xlsx out, and gets back a file that looks correct on screen and imports badly.

Part numbers are the most common casualty. Excel reinterprets anything that resembles a number or a date, and whoever is working in a copy of the file has no reason to notice. One distributor we worked with sent out a 4,100-row catalog where part numbers looked like 0045-12. They came back as 45-12, leading zeros gone, because the column had been retyped into a general-format cell somewhere along the way. Nobody caught it until the webshop import created 900 new products instead of updating the existing ones.

Row drift is the other one. Two people open the same catalog. One sorts by category so the descriptions group into readable blocks, translates in that order, and sends the file back. The other has been editing prices in the original order. Merge those two versions and the wrong description sits next to the wrong SKU. That error survives a casual review because every cell individually looks fine.

Then there is the quieter failure: nobody decided what "translated" means for this particular file. Should the unit column say pcs or the local equivalent? Should the category path be translated, or does the webshop match categories on an ID? Should dimensions convert from inches to millimetres? If those decisions are not made before the file goes out, they get made by whoever happens to be typing, and differently in different rows.

None of this is about translation quality. It is file hygiene, and it is why a catalog that takes two days to translate can take a week to repair.

Work out which columns are actually translatable

Go through the workbook column by column before anything else.

Identifiers and numbers stay untouched: SKU, EAN, supplier code, price, weight, stock quantity. Translating or even reformatting these creates work and never creates value for the reader.

Text written for humans gets translated: product name, short and long description, material, colour, finish, care instructions, warranty text, category path.

The third group is the one people miss. Lookup sheets, dropdown source ranges and hidden tabs feed data validation and formulas in the visible sheet. If you translate "Stainless steel" in the product sheet but leave the validation list in the hidden tab in English, every one of those cells is now invalid, and Excel will not tell you until someone opens the dropdown and finds their own value missing from it.

Units deserve a decision of their own. A column containing "in" or "kg" is not free text, it is a token that something downstream may parse. We keep unit tokens as they are and translate units only in display fields, where a customer actually reads them. Converting measurements is a separate project with its own review, and it should never happen as a side effect of a translation pass.

Write the outcome down as one line per column before you start. A note that reads "column F: translate; column G: leave; column H: translate values, keep numbers" takes ten minutes and prevents the argument you would otherwise have three weeks later, when the German product manager asks why the sizes are still in inches.

How to translate a product catalog without retyping a single cell

The rule is simple: never overwrite the source column. Translate into a parallel column, or into a separate source/target file that can be matched back by ID.

The parallel-column method works like this. Keep the identifier column, add a target column beside each translatable column, and fill the target columns only. The source stays in the file, so you can check any cell against its original, and you can re-run a single column later when marketing rewrites the copy without disturbing the rest of the workbook.

The second method is a neutral source/target export: a two-column file with the source string in one column and its translation in the other, carrying a reference back to the original cell. This is what a structured translation tool produces, and it is also the shape a CAT tool wants if you later need the content in a translation memory. The reference is what makes it safe. If the export contains only source and target, you are matching on text, and the moment two products share the description "Spare part, see catalogue" you have an ambiguity that a paste-by-position will resolve wrongly.

Two habits protect either method. Freeze the row order for the duration of the job and tell everyone the file is locked, so nobody sorts the shared copy to make their own work easier. And match back by ID with a lookup rather than pasting a block of cells by position. Pasting by position works right up until one row is inserted upstream, and then it fails for every row below it, silently.

If the catalog feeds a webshop, our write-up on translating ecommerce product listings covers the fields that also carry search and conversion weight.

Terminology is what makes a catalog read like a catalog

A catalog is repetitive by design, and that is an advantage. The material column in a 4,000-row furniture catalog might hold thirty distinct values. Colour might hold forty. Category, sixty. Translate those once, correctly, and you have settled a large share of the cells in the file before anyone reads a single description.

So we build the glossary from the closed-list columns first. Pull the distinct values, translate that short list, have someone who knows the product review it, and apply it everywhere. It is the fastest quality win available on this kind of file, and it is also the step people skip, because it feels like preparation rather than progress.

The reason it matters shows up when a catalog gets translated in batches. A furniture importer sent us a file where "finish" had been rendered three different ways across 900 rows, because three sections had been handled separately over a fortnight. Each version was defensible on its own. Together they made the website filter useless: faceted search treated them as three separate attributes and split the results across three dead ends.

Repeated sentences in the description columns need the same treatment. Warranty text, care instructions and shipping notes tend to recur verbatim across hundreds of rows. Settle the wording once and apply it, rather than letting each occurrence be decided independently.

This works best on catalogs with structured attributes. If your product data is mostly free-form prose written by whichever supplier sent it, a glossary helps less, and you should budget more review time per row.

Where AI does well on catalog text and where it misses

AI translation is strong on catalog descriptions and unreliable on catalog fragments. The difference is context.

A full sentence carries enough information to disambiguate itself. A cell containing the single word "Case" does not. Depending on the row it might be a shipping case, a phone case, or a unit of sale. We have watched "Case" come back correct in one row and wrong in the next, in the same column, because the neighbouring cells differed.

The fix is to send the row, not the cell. A workflow that passes the column header and the surrounding values as context gets short strings right far more often than a per-cell pass does. If your tool translates cell by cell with nothing around it, plan to review every short string in the file, which on a catalog is most of it.

The second recurring miss is anything that looks like text but is not: model codes with letters in them, brand names, chemical designations, size labels such as XL that happen to mean something in the target language. Lock these before the run, either as do-not-translate entries in the glossary or by keeping them in a column that is never sent.

Numbers are their own case, and the rule is easy. No silent conversion. If the German catalog needs metric sizes, that is a separate, reviewable step with its own column, not a by-product of translation. We would far rather see a size column that is obviously untouched than one that is quietly wrong, because the untouched one gets fixed and the quiet one gets shipped.

Checking the result when nobody in the office reads the language

Most companies translating a catalog have no in-house speaker of the target language. You can still check a surprising amount without one.

Start structurally. Row count in equals row count out. Every ID in the source appears in the target exactly once. No empty cells in columns that were full before. That last check catches the most common silent failure of all, where a batch times out and a block of rows comes back blank in the middle of an otherwise complete file.

Then look for cells where source and target are identical. For part numbers that is expected. For a 40-word product description it means something did not run. Compare string lengths between the two columns as well: a target that is a tenth the length of its source has been truncated, and one that is three times longer will probably overflow whatever field it lands in. Product-name fields in ERP and webshop systems are often capped at 60 or 80 characters, and a language that runs long, German being the usual offender, will hit that ceiling on a meaningful share of rows.

After the structural pass, a QA report and a quality rating give you an order of attack rather than a verdict. Read them as triage, not as a grade. Then spend the review budget where the money is: pull 40 rows from the highest-revenue categories and have someone who sells in that market read them. A distributor's own sales representative in the target country is usually the cheapest competent reviewer you have access to, and they catch the commercial errors, the wrong product name or the wrong register, that no automated check will ever flag. We went into that approach in more depth in checking translation quality when nobody on your team speaks the language.

A sequence you can repeat next quarter

The order we use, in full:

1. Export the catalog fresh from the source system, not from someone's desktop copy.
2. Freeze row order and announce that the file is locked for edits until the target columns land.
3. Mark every column as translate, leave, or translate-values-only, and write the list at the top of the sheet.
4. Pull the distinct values from the closed-list columns, translate and approve that glossary before anything else runs.
5. Translate into parallel target columns or a source/target export with cell references. Never over the source.
6. Run the structural checks: row count, ID match, empty cells, identical source and target, length overflow.
7. Have a native-speaking salesperson read 40 rows from your best categories.
8. Import into a staging environment before production, and diff the product count.

If you want the translation step itself to be structured rather than improvised, SnapIntel handles XLSX workbook translation with that preparation built into the flow: you upload the workbook, prepare a glossary and a translation prompt, approve both before the run starts, and get back a translated workbook along with a neutral source/target XLSX export and a QA report with a quality rating. The one-time trial covers 5,000 words over seven days with no card, which is enough to put a few hundred catalog rows through it and see how your own file behaves.

The catalog you translate next quarter will have the same columns as this one. So the hour spent writing down the column rules and approving the glossary is not overhead for this project, it is the setup for every update after it. Keep both artefacts: the column-rule note and the approved glossary. That is most of the difference between a two-day refresh and another two-week repair.