Separate i18n from Trails core

[tjwebb]

Issue Description

Originally, I thought that i18n (internationalization) support should be a core feature of trails. Due to the complexity and diversity of options for i18n, I think it should be moved to a trailpack

[jaumard]

Yeah I don't see why i18n should be a core feature, so let's put it on a trailpack :) that will allow us to add more i18n functionalities without pollute Trails's code

[weyert]

Sounds like a good idea as it's cause a vulnerability in trails:

Cross-site Scripting (XSS)

Medium severity
Vulnerable module: i18next
Introduced through: [email protected]
Detailed paths

Introduced through: [email protected] › [email protected]
Overview

i18next is i18next internationalization framework. Affected versions of the package are vulnerable to Cross-site Scripting (XSS) due to not escaping variables as expected. When passing any interpolation options without including escapeValue, the function this.escapeValue will get set to undefined in Interpolator. Meaning values aren't being escaped even though users expect them to be.

[jaumard]

Maybe this can be planned for v3 ? Don't know if you already remove it @tjwebb