Este script no debería instalarse directamente. Es una biblioteca que utilizan otros scripts mediante la meta-directiva de inclusión // @require https://update.greasyfork.org/scripts/471000/1226218/Itsnotlupus%27%20I18N%20Support.js
There are 2 kind of localized strings you'll find in userscripts:
- strings found in the original web page.
- strings used by the userscript itself.
To get the former translated, you will need to hook into the web app and somehow get a hold of the proper localized strings.
For the latter, you can rely on this library to ask Google Translate for some machine-translated strings.
It's not going to be flawless, but it should generally be close enough.
API results are cached locally to keep things friendly with Google.
Pass an array for strings found in the original page, and an object mapping ids to strings for your userscript strings.
Usage pattern:
await i18n.init({
stringsArray: [ <Array of english app strings> ],
stringsObject: { <Object mapping ids to english script settings> },
strings: ,
lang: "<language code ('en','fr','es', etc.)>",
callback: async (stringsArray) => return { <Object mapping english app strings to localized app strings> }
});
All of the object values are optional, but you'll probably want to pass at least one of the strings values.
document.documentElement.lang will be used as value for lang by default.
The callback function can be asynchronous and will be awaited correctly.
Only pass a callback if you pass an array of string, as it's useless otherwise.
Note that the .init() method is asynchronous and must be awaited before you can start using t`string`.
Afterward, you can use t`<english app string>` or t`<script id>` to get a localized string.
( setEnStrings, setLanguage and initLanguage are kept around for backward whateverability, but probably don't use them. )
MISSING: templating, pluralization, or really anything difficult. this is just a cheap stop-gap.
