kalxas on master
Update requirement.txt (#894) … (compare)
load_plugincan call all kinds of plugins, I thought it would be best to at least have that locale passed on to all plugins.
lquery param or
Accept-Languageheader) to the plugin, as the plugin might support other locale(s) than pygeoapi itself
@GeoSander can we go with
lang too actually, but went with what @pvgenuchten suggested ;)
maybe we can just take the second as the default? So the first one would become no longer valid?
I'd be happy to implement it like that (and keep the code a bit cleaner), but I thought it might be safer to have it support both for a while, as to not break any existing setups and not force people to use a multilingual configuration
is the core driver of this PR multilingual for the UI or the pure JSON API?
Content-Languageheader that matches the provider locale, if available. If the provider does not support locales, no
Content-Languageheader is set.
provider_defhas already has a
languagessection that states the supported languages. I could let the core find a best match for those languages and pass that along to the providers that need it. As @francbartoli already mentioned, I could introduce extra base classes that creators of multilingual providers can use. Then, the
load_pluginfunction can pass that parameter if it sees that the provider implements that base class.