How does this library handle transliteration of non-ASCII characters?

Question

RepoPilot · Accepted Answer

The sindresorhus/slugify library handles transliteration of non-ASCII characters through the `@sindresorhus/transliterate` dependency (listed in [package.json:L40]).

**Default Behavior:**
By default, transliteration is enabled. The library converts Unicode characters to their ASCII equivalents. For example, "Déjà Vu" becomes "deja-vu" and "я люблю единорогов" becomes "ya-lyublyu-edinorogov" (as shown in the README examples).

**Transliteration Process:**
In the main function [index.js:L46-L111], when `options.transliterate` is `true` (the default), the code calls the `transliterate` function with custom replacements and an optional locale:

```javascript
if (options.transliterate) {
    const customReplacements = new Map([
        ...builtinOverridableReplacements,
        ...options.customReplacements,
    ]);
    string = transliterate(string, {customReplacements, locale: options.locale});
}
```

**Locale Support:**
The library supports locale-specific transliteration through the `locale` option. For instance, "Räksmörgås" transliterates differently depending on the locale—as "raeksmoergas" by default, but as "raksmorgas" with Swedish locale (`{locale: 'sv'}`) [readme.md:L195-L234].

**Disabling Transliteration:**
When `transliterate: false` is set, non-ASCII characters are preserved as-is instead of being converted. This also affects the regex pattern used to clean the slug [index.js:L23-L45], where the `gu` flag is used instead of `g` to preserve Unicode letters and numbers.

FOLLOW_UPS:
- What built-in character replacements does slugify apply?
- How does the locale option affect lowercasing behavior?
- What happens with custom replacements when transliterate is false?