lang=
instead of l=
?
load_plugin
can call all kinds of plugins, I thought it would be best to at least have that locale passed on to all plugins.
l
query param or Accept-Language
header) to the plugin, as the plugin might support other locale(s) than pygeoapi itself
@GeoSander can we go with
lang=
instead ofl=
?
I prefer 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?
Both
Content-Language
header that matches the provider locale, if available. If the provider does not support locales, no Content-Language
header is set.
provider_def
has already has a languages
section 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_plugin
function can pass that parameter if it sees that the provider implements that base class.
query
functions. Why do we need it in the constructor?
fields
property is used, which is set at provider class init, while at other places, the function is used)
(I actually noticed that in some places, the
fields
property is used, which is set at provider class init, while at other places, the function is used)
We should be using just the .fields
property from pygeoapi/api.py
. There’s one of of get_fields()
in pygeoapi/api.py
that slipped in during the EDR API pull request. I can remove that once we have consensus on this PR