How to translate an Excel file into another language

Translating the first fifty rows of a spreadsheet is not a problem. Row 18,000 is the problem. By then you have lost track of which rows are done, the same product name has been translated three different ways, and a formula somewhere quietly points at the wrong cell.

This guide is about that workbook: several sheets, a header row, some columns that are text and some that are identifiers, and more rows than anyone should paste into a chat window.

What is actually slowing you down

Almost nobody is stuck on the language. If you needed one paragraph translated you would have it already.

What takes the week is everything around the words. Deciding which columns are text and which are codes. Keeping the rows lined up so a translated description still sits next to its own SKU. Remembering that sheet four exists. Doing it again next month, when 300 new products have been added and the other 4,000 have not changed.

That work is not language work, and it is the part a workbook makes expensive. It is also the part that can be described in one sentence and then run.

What a workbook is, as far as translation is concerned

A spreadsheet is not one document. It is a set of sheets, each of which is a grid, and only some of the cells in that grid hold words.

Three facts about a workbook decide how the job should be shaped, and all three are different from a subtitle file or an app resource file.

Many columns can coexist on one sheet. So several languages can live side by side in a workbook, in separate columns. Most localization formats cannot do that. An iOS .strings file holds exactly one language per file, and translating it replaces the text in place.

The header row is not special to the file. In a workbook, row 1 is cells like any other. Your column titles are text, so they are visible to the job and they will be translated unless you say otherwise. That is a one-line decision, and it is worth making on purpose.

Only text cells are candidates. A cell holding a number is a number, and a cell holding a formula is a formula. Neither is collected for translation, so neither can be rewritten by it.

Each sheet is addressed by name, so a cell is identified by which sheet it is on and where it sits in that sheet, and nothing has to be renamed or flattened to be reachable. That is why a seven-tab reference document is one upload rather than seven.

The round trip, in five steps

Before the detail, the shape. Nothing costs anything until step four.

Step three is the one people undervalue. A plan that misread your workbook costs nothing to correct, so there is no reason to guess: if it says it is going to translate a column of part numbers, you say so in a sentence and it plans again. You can get to that plan without an account, which is the cheapest way to find out whether your file is shaped the way you think it is.

The columns decision, which is the whole job

Here is a real catalogue row and what should happen to it. Notice how little of it changes.

Say which columns to translate, by the names you already use. Not “the text columns”, which is a guess about your file, but “the description and the SEO title, leave the handle and the part number alone”. Those are your own column titles, and they are what the plan will report back to you.

The columns to keep your hands off are usually easy to name once you look: part numbers, product handles, internal ids, currency codes, country codes, anything that another system matches on. A translated identifier does not fail loudly. It fails at import, weeks later, on the row nobody checked.

One thing you get for free here, worth a sentence rather than a section: the formulas and the sheet structure survive, because only text cells are ever written and everything else is carried through, so a lookup on another sheet still resolves and a price is still a number.

You can scope it far more finely than a column

This is the part worth slowing down for, because it is the one thing the alternatives cannot do at all.

Naming columns is the coarse version. The instruction is free text, so it can also describe which rows, and it is evaluated against every one of them: “only the rows where the German column is still empty”, “only where the target is identical to the English, it is a placeholder”, “the description and the SEO title, but only for the rows added since the last export”.

That matters most the second time. A catalogue is never translated once. It grows, and next month’s job is four hundred new rows in a file of four thousand, so the difference between paying for the file and paying for the gap is the difference between a workable process and one you stop using. A machine translator has no concept of scope, and a chat assistant cannot hold one rule reliably down to row 18,000.

It is a big enough subject to have its own guide: translating only the rows that are still missing covers what “missing” means in each kind of file, where the sentence goes, and how to confirm the scope before you pay for it.

Three things worth fixing before you upload

None of these is required, and all three save you a round of corrections.

Give every column a unique name. Two columns both called “Description” force you to describe them by position instead of by name, and a position is much easier to get wrong in a sentence than a title is. Description EN and Description FR are unambiguous to you and to the plan.

Keep the identifier your destination system matches on. Whatever the row is looked up by, a product id, a record id, a slug, make sure it is in the file and then leave it out of what you ask to translate. Without it you have a translated catalogue you cannot merge back into anything.

Decide about the header row now. Column titles are text in row 1, so they are translatable. If the workbook is going back into a system that reads those titles, they must stay in English, and saying so takes six words. If a person is going to read the sheet, translating them may be exactly what you want.

One thing you do not need to fix: there is no reason to convert the workbook to CSV first. XLSX goes in directly, and converting throws away the two things a workbook has that a CSV does not, several sheets and formulas that survive.

A language per column, or a file per language

This is the one genuine design choice in an Excel job, and it is worth thirty seconds because changing your mind later means running it again.

If a human is going to read the result, put the languages in columns. Seeing “Solid oak desk shelf” and its French next to each other on row 412 is the difference between reviewing a translation and auditing one.

If a system is going to eat the result, use one file per language, because that is what it will ask for anyway, and splitting a six-language sheet by hand afterwards is exactly the kind of clerical work that goes wrong at file five.

You can also ask for a target column that is not in the workbook yet. It is created with your own header on row 1, in a column that was genuinely free, so nothing you already have is overwritten.

The two instructions, and why one of them fails in silence

This is the single most useful thing to understand about the product, and the mistake is invisible when you make it.

The plan instruction decides what gets translated. It is read once, against the shape of your workbook, and it is where scope lives: which sheets, which columns, which rows, into which language. The engine turns that sentence into code and runs it over the whole file, which is why the rule holds identically on row 12 and on row 18,000.

The string-level instructions are applied while each cell is written. At that moment the engine is looking at one cell, so these can only describe something visible inside one cell: the tone to use, a placeholder that must survive exactly as written, an alphanumeric code inside a sentence that must not be touched.

Put a file-level sentence in the string-level slot and nothing happens, and nothing tells you. “Only translate the Products sheet” written there does not fail, it just has no file in view to act on. The reverse is equally quiet: a rule about tone in the plan instruction shapes the scope decision and then is not there when each cell is actually written.

The plainest way to hold it: the plan decides what, the string-level instructions decide how.

An instruction you can copy

Here is one that works, written the way the product actually accepts it. Change the sheet names and the column titles to your own.

Translate the Products and Help articles sheets from English into French.
On Products, translate the Description and SEO title columns only, and write
the French into the empty "Description FR" column. Leave the SKU, Handle and
Price columns exactly as they are, and leave the header row in English.
On Help articles, translate the Title and Body columns in place.
Skip any row where the French column already has text in it.

Five plain sentences, and every one of them is a scope decision: the sheets, the columns, the destination, what to leave alone, and which rows are already done.

Then, at approval, the guidance carried into each individual cell:

Use the formal "vous" register. Keep any placeholder such as `{count}` or
`{name}` exactly as written, including the braces. Leave product codes and
model numbers unchanged inside a sentence.

Notice that the second block says nothing about columns or sheets. It cannot. It is read while one cell is being written, and one cell has no columns.

What happens to a very large sheet

A 40,000-row export is the case this was built for, and it is worth knowing that nothing about your side of it changes.

The cap is 50 MB per workbook, and each individual cell can hold up to 50,000 characters, which is roomy enough for a long HTML product description sitting in one cell. Past roughly two megabytes the engine stops loading the workbook whole and reads each sheet in windows, extracting as it goes and writing the finished cells back into the original file rather than rebuilding it. Untouched rows are copied across as they were.

The practical consequences are the three you would want:

• The plan still measures the whole file, so the word count and the cost you approve are the real ones rather than an estimate from a sample.
• A rule that depends on position still works. “Only the rows where the target is empty” is evaluated against every row, not against the first window.
• Nothing about the file’s own limits changes. Excel’s own ceiling is 1,048,576 rows per sheet, and you will hit the size cap a long way before that.

For an export that is genuinely bigger than one file can hold, the honest answer is to split it, either by sheet or by row range, and to keep one glossary across the pieces so the terminology does not drift between them. If your source system can emit CSV instead, CSV translation allows a larger file, because a CSV is plain text and a workbook is a compressed archive of XML. You give up the sheets and the formulas in exchange.

Keeping terminology steady across sheets and months

Consistency is where spreadsheet translation usually falls apart, and it is not a grammar problem. It is that your product is called one thing on the Products sheet and something else in the Help articles, and that last month’s file and this month’s file disagree.

Put the terms that must not drift into a workspace glossary once: product names, the house translation of a category, a phrase your brand owns. It then applies to every sheet in the workbook and to the next workbook too. That is the whole argument for building a glossary before the second file rather than after the fifth.

This is also where a general machine translator struggles, and the reason is mechanical rather than a matter of quality. Its glossary substitutes a term wherever it matches, so the sentence around the substitution is not reconsidered. Here the glossary is carried in as meaning while the cell is written, so the term inflects into the sentence instead of being dropped into the middle of it.

If you are weighing this against the alternatives you already have, the real cost of translating spreadsheets is rarely the per-word rate. It is the hours spent preparing the file, explaining which columns to leave alone, waiting, and re-importing. Our comparison of spreadsheet translation tools covers where each approach stops working.

Checking the file you get back

Two checks, and both take a minute.

Open it and sort by the target column. Any row that came back empty when you expected text is visible immediately, and it is almost always a scope decision you made and forgot rather than a failure.

Re-import a handful of rows before the whole file. If a destination system is going to object to something, it will object to twenty rows as readily as to four thousand, and finding out on twenty is much cheaper. Keep the original export until that import has gone through.

It is also worth remembering why the sheet exists at all. CSA Research, in its “Can’t Read, Won’t Buy” survey of 8,709 consumers across 29 countries, found that 76% of online shoppers prefer to buy products with information in their own language, and 40% will not buy from sites in other languages at all. If that workbook is a product catalogue, those two numbers are the reason it is worth doing properly.

Where a human still belongs

For one sheet of forty rows going on a homepage, ask a translator who speaks the language. You will get a better result and it will not take long.

For a catalogue of 4,000 products across six languages, the file handling is the whole cost, and it is not language work. Run the bulk through AI Glot, then put review where it earns its keep: the categories that actually sell, the pages people land on, anything where the wording is the product. Plenty of teams use it as a first pass and have a native speaker read the output, which is a good use of an expert and a bad use of a week inside a spreadsheet.

If you want to see what the plan says about your own workbook before deciding anything, the Excel translator will read it and tell you, and a free account comes with enough credits to run a real file through.

The limits quoted here are the ones in force when this was written: 50 MB per XLSX file, and 50,000 characters per individual cell. Sheet counts, word counts and costs always come from the plan for your own workbook, which is free to produce and free to correct.