Word count and match analysis: why two tools rarely agree

A client sends a file and asks for a quote. You count it, they count it, and the numbers differ. Usually nobody has made a mistake: word counting has no single rule, and a match analysis depends on settings neither side mentioned. This guide explains where the differences come from, so you can say which number you quoted and why.

There is no one way to count a word

The industry did write a standard. GMX-V, published by ETSI as GS LIS 004, defines word and character counts on the XLIFF <source> text. Its rules are precise:

• Word boundaries follow Unicode. Words are found with the word-boundary rules of Unicode TR 29, which separate words from punctuation and white space. “Can’t” is one word; a quotation mark on its own is none.
• Numbers are words, slashes split. The standard’s own example, “This sentence/text unit has a word count of 11 words.”, counts eleven: sentence/text is two words and 11 is one.
• Hyphens do not split words. “Italian-American” is one word.
• Chinese, Japanese, Korean and Thai are counted by characters, and the character count is divided by a factor to give a word count: 2.8 for Chinese, 3.0 for Japanese, 3.3 for Korean and 6.0 for Thai.
• Repetitions must match exactly, inline elements included: “text units with identical text but different inline elements are not repetitions.”

The same document is candid about how much this is followed. In its own words:

Current commercial practice varies from product to product. There is no unified method of providing an industry wide set of metrics.

So the places where two counts part company are the places where a tool has to decide:

• Numbers, dates and codes. GMX-V counts 11 as a word, and also gives “Auto Text” its own categories: “automatically identifiable text such as numeric values, date and trade marks or model names”. Whether those are in the total you quote is a choice.
• Slashes and apostrophes. Is “and/or” one word or two, and l'objectif? GMX-V says two for both: it splits at the slash, and in French and Italian it breaks between an apostrophe and the vowel after it.
• Tags. A tag is not a word, but it is work. memoQ, for example, lets you give tags a weight: “If you type 0.25, memoQ counts one word after every four inline tags”.
• Spaces in character counts. The same memoQ page notes that it “counts every space separately”, so two spaces in a row are two characters.
• Languages without spaces. A tool that counts every Chinese, Japanese or Korean character as a word gives a number about three times higher than one that applies the GMX-V factors.
• Segmentation. Repetitions and matches are found per segment, so a tool that splits a paragraph into sentences differently finds different repetitions, even when the total words agree.

Repetitions depend on what you count together

A repetition is a segment whose source text has already appeared. The first occurrence is translated in full; the later ones reuse that translation, which is why an analysis counts them separately and a quote can weight them lower.

What counts as “already appeared” depends on the scope. memoQ’s documentation gives the example plainly: if two documents in a project each contain the same segment once, the statistics for the whole project show one repetition, and the statistics for each document on its own show none. In Trados Studio, the Analyze Files task’s settings treat identical segments in different files as repetitions by default, and by default “only identical segments are considered as repetitions”; an option makes similar segments count as fuzzy repetitions too.

memoQ also documents why the scope matters for money. For a project shared by several translators it advises clearing cross-file repetitions, “because we don’t know who will translate a segment first - and they should get full compensation for translating.”

Match bands and weighted counts

When a translation memory is part of the analysis, each segment is compared with it and counted in a band by its best match. GMX-V has a single category for every fuzzy match; the percentage bands on an analysis report are the tools’ own. These are the ones xliff.ai reports, from the top:

“Context” is defined by each tool. Phrase’s documentation, for example, says that for 101% matches “the previous and following segments provide context”, or the segment’s key in formats that have one.

A quote then applies a percentage of the full rate to each band. memoQ calls the result a weighted count: “Each category has a weight representing how much work is needed (0% = no work, 100% = full translation)”, and gives the arithmetic: “A 90% match segment with 10 words and 50% weight counts as 5 words of work.”

Two consequences follow. The same file analysed against a different memory gives a different quote. And a segment that is both a repetition and a memory match must be counted once, so something decides which comes first. GMX-V says “Repetition matching is deemed to take precedence over fuzzy matching”; memoQ leaves the 100% case to an option, “Repetitions take precedence over 100%”, so that “repeated segments aren’t double counted.”

How xliff.ai counts

Open the file in the editor and click the word count beside the progress bar, or choose Word count and analysis from the ⋯ menu. The dialog shows the segments, words and characters in each band for the whole open file, each band’s share of the words, and how many words are already confirmed. Download CSV saves it as <file name>.analysis.csv for a quote or an invoice. Nothing is uploaded to do this.

The rules behind the numbers, so you can compare them with another report:

• Words are counted by spaces. A run of characters between spaces is a word if it contains a letter or a digit. Numbers count; a dash or a quotation mark on its own does not; Italian-American, and/or and l'objectif are one word each, where GMX-V would make and/or and l'objectif two.
• Chinese characters count one word each, kanji in Japanese text included, and so do CJK punctuation marks and full-width characters. Japanese kana and Korean Hangul are counted by spaces like other scripts, so a run of kana between two kanji is one word. No GMX-V factor is applied.
• Tags never count, and the text on each side of a tag is counted separately, so a tag in the middle of a word makes it two.
• Characters are the length of the source text, spaces included and tags left out.
• Repetitions are later occurrences of a source text already seen in the same file; the first occurrence is counted by its own match. Only the open file is counted, so there are no cross-file repetitions.
• Bands need a memory. A segment’s band comes from its best match in the memories loaded in the Memory panel. With none loaded, everything that is not a repetition is No match. Match values stored in the file itself, such as the percentages in an SDLXLIFF or MQXLIFF file, are not used.
• A context match (101%) is a 100% match, with no differences at all, whose memory entry also records the same previous source segment, in a TMX property such as x-context-pre.
• Each segment is counted once, in the first band that applies: locked, context match, repetition, 100%, then the fuzzy bands, then No match. A repetition therefore outranks a 100% match, the precedence memoQ offers as an option.

So for the same file, xliff.ai’s total will sit close to any count made by spaces, and apart from GMX-V on slashes, French and Italian apostrophes and CJK text. That is not a reason to distrust either figure, only a reason to quote from one tool’s report and name it.

Questions to settle before you quote

1. Which tool counted it, and with which settings? Ask for the analysis report, not just the total.
2. Which memory, if any? Without the client’s memory, your analysis finds no matches at all, whatever the client’s own report shows.
3. What is the scope? One file, or the whole project; with or without cross-file repetitions.
4. Are locked segments counted? They are usually not translated, but they may need to be read.
5. Which band rates apply? A weighted count is only comparable when both sides use the same grid.