Support slug translations in the API docs

[mindrones]

Fixes #2344

I tried some of the libraries investigated by @Ryuno-Ki here #2344 (comment).

I find limax quite good:

• it supports a lang option that in the future might be handy for i18n (if you don't specify it, it tried to auto detect the language);
• it's customizable (for example since it lets you define an array of allowed chars I've been able to exlude $ from being sustituted with usd, useful for $set and friends).

Here are some screenies:

[codecov-io]

Codecov Report

Merging #2404 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2404   +/-   ##
=======================================
  Coverage   91.83%   91.83%           
=======================================
  Files           1        1           
  Lines          49       49           
=======================================
  Hits           45       45           
  Misses          4        4

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e7f5467...c8b2941. Read the comment docs.

[mindrones]

Also, the duplicates slug Set was created in the .map function, so while processing each file, hence we weren't preventing duplicates in the same page, so I've moved the Set creation upper so that it's global and moved these functions in a utils/slug.js module.

[mindrones]

Hmm, this PR actually would fix the slugs for API docs only, I haven't looked at /tutorial and /blog.

If this is desirable we can then use utils/slug.js in those sections too.

[Ryuno-Ki]

@mindrones Happy to help :-)

[mindrones]

Added a processor to preserve unicode chars, seems to work!

[mindrones]

There are 3 options to go.

• To keep unicode chars in slugs, use:

  makeSlug = makeSessionSlugProcessor(unicodeSafeProcessor),

  where we can use:

  • nonUnicodeSanitizer [1], or
  • limaxProcessor [2], or

• To latinize chars in slugs, use

  makeSlug = makeSessionSlugProcessor(limaxProcessor)

makeSlug = makeSessionSlugProcessor(nonUnicodeSanitizer) would break for translations using unicode chars

[1] based on the previous code (no dependencies, custom/simpler)
[2] uses limax (adds a dependency but seems safer)

I can clean up and squash depending on our preferences.

[mindrones]

I've been thinking a bit about this and maybe the best option would be to have the main website using limax to make sure URLs conform to RFC3986 by latinizing unicode chars if any, but still giving the opportunity to translators to host a website with unicode URLs.

To do this we should pass an environment variable, say preserveUnicode, to makeSessionSlugProcessor:

export const makeSessionSlugProcessor = (preserveUnicode = false) => {
    const processor = preserveUnicode ? unicodeSafeProcessor : limaxProcessor;
	const seen = new Set();

	return string => {
		const slug = processor(string);

		if (seen.has(slug)) throw new Error(`Duplicate slug ${slug}`);
		seen.add(slug);

		return slug;
	}
}

and in _sections.js, we would do:

const makeSlug = makeSessionSlugProcessor(envPreserveUnicode);

taking envPreserveUnicode from a config file.

EDIT Implemented