Skip to content

Add Intl.Segmenter support #539

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Aug 1, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,11 @@ Broadly, jsdiff's diff functions all take an old text and a new text and perform

Options
* `ignoreCase`: Same as in `diffChars`. Defaults to false.
* `intlSegmenter`: An optional [`Intl.Segmenter`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Segmenter) object (which must have a `granularity` of `'word'`) for `diffWords` to use to split the text into words.

By default, `diffWords` does not use an `Intl.Segmenter`, just some regexes for splitting text into words. This will tend to give worse results than `Intl.Segmenter` would, but ensures the results are consistent across environments; `Intl.Segmenter` behaviour is only loosely specced and the implementations in browsers could in principle change dramatically in future. If you want to use `diffWords` with an `Intl.Segmenter` but ensure it behaves the same whatever environment you run it in, use an `Intl.Segmenter` polyfill instead of the JavaScript engine's native `Intl.Segmenter` implementation.

Using an `Intl.Segmenter` should allow better word-level diffing of non-English text than the default behaviour. For instance, `Intl.Segmenter`s can generally identify via built-in dictionaries which sequences of adjacent Chinese characters form words, allowing word-level diffing of Chinese. By specifying a language when instantiating the segmenter (e.g. `new Intl.Segmenter('sv', {granularity: 'word'})`) you can also support language-specific rules, like treating Swedish's colon separated contractions (like *k:a* for *kyrka*) as single words; by default this would be seen as two words separated by a colon.

* `Diff.diffWordsWithSpace(oldStr, newStr[, options])` - diffs two blocks of text, treating each word, punctuation mark, newline, or run of (non-newline) whitespace as a token.

Expand Down
1 change: 1 addition & 0 deletions release-notes.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,7 @@
* The context line immediately before and immediately after an insertion must match exactly between the hunk and the file for a hunk to apply. (Previously this was not required.)
- [#535](https://github.com/kpdecker/jsdiff/pull/535) **A bug in patch generation functions is now fixed** that would sometimes previously cause `\ No newline at end of file` to appear in the wrong place in the generated patch, resulting in the patch being invalid.
- [#535](https://github.com/kpdecker/jsdiff/pull/535) **Passing `newlineIsToken: true` to *patch*-generation functions is no longer allowed.** (Passing it to `diffLines` is still supported - it's only functions like `createPatch` where passing `newlineIsToken` is now an error.) Allowing it to be passed never really made sense, since in cases where the option had any effect on the output at all, the effect tended to be causing a garbled patch to be created that couldn't actually be applied to the source file.
- [#539](https://github.com/kpdecker/jsdiff/pull/539) **`diffWords` now takes an optional `intlSegmenter` option** which should be an `Intl.Segmenter` with word-level granularity. This provides better tokenization of text into words than the default behaviour, even for English but especially for some other languages for which the default behaviour is poor.

## v5.2.0

Expand Down
12 changes: 10 additions & 2 deletions src/diff/word.js
Original file line number Diff line number Diff line change
Expand Up @@ -58,8 +58,16 @@ wordDiff.equals = function(left, right, options) {
return left.trim() === right.trim();
};

wordDiff.tokenize = function(value) {
let parts = value.match(tokenizeIncludingWhitespace) || [];
wordDiff.tokenize = function(value, options = {}) {
let parts;
if (options.intlSegmenter) {
if (options.intlSegmenter.resolvedOptions().granularity != 'word') {
throw new Error('The segmenter passed must have a granularity of "word"');
}
parts = Array.from(options.intlSegmenter.segment(value), segment => segment.segment);
} else {
parts = value.match(tokenizeIncludingWhitespace) || [];
}
const tokens = [];
let prevPart = null;
parts.forEach(part => {
Expand Down
49 changes: 49 additions & 0 deletions test/diff/word.js
Original file line number Diff line number Diff line change
Expand Up @@ -209,6 +209,55 @@ describe('WordDiff', function() {
);
expect(convertChangesToXML(diffResult)).to.equal('foo<del> </del><ins>\t</ins>bar');
});

it('supports tokenizing with an Intl.Segmenter', () => {
// Example 1: Diffing Chinese text with no spaces.
// I am not a Chinese speaker but I believe these sentences to mean:
// 1. "I have (我有) many (很多) tables (桌子)"
// 2. "Mei (梅) has (有) many (很多) sons (儿子)"
// We want to see that diffWords will get the word counts right and won't try to treat the
// trailing 子 as common to both texts (since it's part of a different word each time).
// TODO: Check with a Chinese speaker that this example is correct Chinese.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello, @ExplodingCabbage, I'm Chinese, I can confirm that the meaning of these two sentences are correct.

But I'm not sure about the test purpose here.

I can see that

> [...chineseSegmenter.segment('我有很多桌子。')].map(({segment})=>segment)
[ '我有', '很多', '桌子', '。' ]
> [...chineseSegmenter.segment('梅有很多儿子。')].map(({segment})=>segment)
[ '梅', '有', '很多', '儿子', '。' ]

Not sure why '我有' are together, but '梅', '有' are separated, if you want test something similar you can change 梅有 to 他有(He has) or 她有(She has).

Copy link
Contributor

@fisker fisker May 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's quite strange...

> [...chineseSegmenter.segment('她有很多桌子。')].map(({segment})=>segment)
[ '她', '有', '很多', '桌子', '。' ]
> [...chineseSegmenter.segment('他有很多桌子。')].map(({segment})=>segment)
[ '他有', '很多', '桌子', '。' ]

'她' and '他' are the same, but one for male, one for female.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I'm not sure about the test purpose here.

Huh. What I wanted to demonstrate was that the "tokens" we split the text into are what a Chinese speaker or linguist would consider to be single words. But from what you write, it sounds like the tokens in this case aren't what you'd consider words, though, and Intl.Segmenter is giving an incorrect result? i.e. if I understand you right, you would say "我有" is two words ("我" and "有"), not a single word made up of two characters? Is there any kind of ambiguity about this - like, is there any reason a native speaker might argue that 我有 is a single word - or is Intl.Segmenter just completely unambiguously wrong here?

If so, it's probably worth a bug report to... whatever the underlying source of the segmentation rules is here. (ICU, I think.)

Anyway, for clarity I'll tweak this test to show an example where Intl.Segmenter manages to get the tokenization right. Thank you for commenting!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not a single word made up of two characters?

It's not something really "incorrect", people have different opinions. Just feels odd, it's inconsistent for things similar.

# I have money
> [...chineseSegmenter.segment('我有钱')].map(({segment})=>segment)
[ '我有', '钱' ]
# You have money
> [...chineseSegmenter.segment('你有钱')].map(({segment})=>segment)
[ '你有', '钱' ]
# He have money
> [...chineseSegmenter.segment('他有钱')].map(({segment})=>segment)
[ '他有', '钱' ]
# She have money
> [...chineseSegmenter.segment('她有钱')].map(({segment})=>segment)
[ '她', '有', '钱' ]
# It have money
> [...chineseSegmenter.segment('它有钱')].map(({segment})=>segment)
[ '它', '有', '钱' ]
# I love flowers
> [...chineseSegmenter.segment('我爱花')].map(({segment})=>segment)
[ '我', '爱', '花' ]
# You love flowers
> [...chineseSegmenter.segment('你爱花')].map(({segment})=>segment)
[ '你爱', '花' ]
# He love flowers
> [...chineseSegmenter.segment('他爱花')].map(({segment})=>segment)
[ '他', '爱', '花' ]
# She love flowers
> [...chineseSegmenter.segment('她爱花')].map(({segment})=>segment)
[ '她', '爱', '花' ]
# It love flowers
> [...chineseSegmenter.segment('它爱花')].map(({segment})=>segment)
[ '它', '爱', '花' ]

const chineseSegmenter = new Intl.Segmenter('zh', {granularity: 'word'});
const diffResult = diffWords('我有很多桌子。', '梅有很多儿子。', {intlSegmenter: chineseSegmenter});
expect(diffResult).to.deep.equal([
{ count: 1, added: false, removed: true, value: '我有' },
{ count: 2, added: true, removed: false, value: '梅有' },
{ count: 1, added: false, removed: false, value: '很多' },
{ count: 1, added: false, removed: true, value: '桌子' },
{ count: 1, added: true, removed: false, value: '儿子' },
{ count: 1, added: false, removed: false, value: '。' }
]);

// Example 2: Should understand that a colon in the middle of a word is not a word break in
// Finnish (see https://stackoverflow.com/a/76402021/1709587)
const finnishSegmenter = new Intl.Segmenter('fi', {granularity: 'word'});
expect(convertChangesToXML(diffWords(
'USA:n nykyinen presidentti',
'USA ja sen presidentti',
{intlSegmenter: finnishSegmenter}
))).to.equal('<del>USA:n nykyinen</del><ins>USA ja sen</ins> presidentti');

// Example 3: Some English text, including contractions, long runs of arbitrary space,
// and punctuation, and using case insensitive mode, just to show all normal behaviour of
// diffWords still works with a segmenter
const englishSegmenter = new Intl.Segmenter('en', {granularity: 'word'});
expect(convertChangesToXML(diffWords(
"There wasn't time \n \t for all that. He thought...",
"There isn't time \n \t left for all that, he thinks.",
{intlSegmenter: englishSegmenter, ignoreCase: true}
))).to.equal(
"There <del>wasn't</del><ins>isn't</ins> time \n \t <ins>left </ins>"
+ 'for all that<del>.</del><ins>,</ins> he <del>thought</del><ins>thinks</ins>.<del>..</del>'
);
});

it('rejects attempts to use a non-word Intl.Segmenter', () => {
const segmenter = new Intl.Segmenter('en', {granularity: 'grapheme'});
expect(() => {
diffWords('foo', 'bar', {intlSegmenter: segmenter});
}).to['throw']('The segmenter passed must have a granularity of "word"');
});
});

describe('#diffWordsWithSpace', function() {
Expand Down