Closed benoitchantre closed 2 years ago
Good morning. Sorry for the late response (still in vacation :) ).
I guess it's fine to add wordpress-muplugin
-type to the supported list. Probably we shouldn't even restrict to types. Basically every custom composer type can provide translations.
Hm...the problem is, that there is no default WP.org REST Endpoint for getting translations from muplugins and we also have no API in WP Core to load translations for muplugins like theme/plugin translations.
So we probably need to decide to put the translation files into a muplugin
-folder in languages
and document down, that you can load them like the type library
. 🤔
Hey ☕
With the latest implementation of https://github.com/inpsyde/wp-translation-downloader/pull/27 (not released yet), it is also possible to configure non-predefined types. You can use for example:
{
"languageRootDir": "public/languages/",
"directories": {
"types": {
"wordpress-muplugin": "mu-plugins"
}
},
"api": {
"types": {
"wordpress-muplugin": "https://some-custom-glotpress.com/api/%packageName%/"
}
}
}
which will download your translations for mu-plugins into /{root-path}/public/languages/mu-plugins/
.
This was released with the latest 2.1 version. Check out the changelog: https://github.com/inpsyde/wp-translation-downloader/releases/tag/2.1 :)
@benoitchantre
At the moment, the following packages types are supported:
It would be great to add
wordpress-muplugin
to that list.