Support i18n in plugin UI #2597
Description
Feature Description
What is happening?
There currently is no support for internationalization of plugin UIs, short of using a custom user interface. This feels like killing a fly using a cannon.
What you expect to happen?
Provide a simpler way to support i18n.
Implementation suggestions
The package.json spec supports the directories/directories object which indicates the structure of the plugin package, which looks something like this:
{
"directories": {
"lib": "path/to/lib/",
"bin": "path/to/bin/",
"man": "path/to/man/",
"doc": "path/to/doc/",
"example": "path/to/example/"
}
}
Just add a property for an i18n directory:
{
"directories": {
...
"i18n": "path/to/i18n/"
}
}
In the folder path/to/i18n/, the author can provide i18n versions of config.schema.json, named config.schema.json.en, config.schema.json.de, etc.
In plugins.service.ts ...
... the code can check if there is a path/to/i18n/ folder and if there is a config.schema.json.xx file inside that folder, where xx matches the language used by Homebridge UI. If the folder or no matching config.schema.json.xx are found, then the default config.schema.json file is used.
...
const i18nPath = plugin.directories?.i18n
const lang = homebridge.i18nCurrentLang()
let schemaFile = resolve(plugin.installPath, pluginName, i18nPath, 'config.schema.json.' + lang)
if (!fs.existsSync(schemaFilePath)) {
schemaFile = resolve(plugin.installPath, pluginName, 'config.schema.json')
}
let configSchema = await readJson(schemaFile)
...
and in plugins.interfaces.ts:
add the directories and i18n properties:
export interface HomebridgePlugin {
name: string
...
directories?: {
i18n?: string
}
...
}
This is admittedly a little bit of a rough solution, but
- it is not requirement for plugins to support
- it is a minor code change to Homebridge UI
- it places the responsibility to maintain the
xxfiles on the plugin developer
Also at the moment there is no easy way to provide i18n support, but there doesn't seem to be a lot of demand for this feature either, so starting with a minimum effort feature makes more sense than supporting a massive code change.
If this becomes a popular feature and there is demand to simplify it, then a better architected solution can be designed.