I'm not so lucky with Travis though. Often, one of the 2 builds fail for reasons beyond my control... But the tests should all pass.
@GeoSander can we go with
lang= instead of l= ?
maybe we can just take the second as the default? So the first one would become no longer valid?
it looks like the whole decorator pattern around headers and args has been fixed/improved
Providers need it if their backends support it and other plugins might need it. For example, it could be useful for formatters too, as Babel Locale objects also include info relevant for formatting.
But because
But because
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.
Regardless if it's useful to them or not
If it's omitted or None, the plugin will simply not have locale support but it won't break anything
Note that pygeoapi always has to pass the "raw" locale (as requested in the
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
But JSON responses returned by a provider for example get a
Content-Language header that matches the provider locale, if available. If the provider does not support locales, no Content-Language header is set.
I’ve added @kalxas @justb4 and @francbartoli to additionally review this PR
And thanks for taking the time to review and adding additional reviewers.
I'm open for any suggestions/improvements.
Need to go now, will check later for any messages
For elastic, I’m not sure what the current localization support is
Elastic i18n seems to have a number of options https://stackoverflow.com/questions/22153606/multilingual-elasticsearch-indexing-best-practice-experiences
2 replies
just created this issue geopython/pygeoapi#663, it gives potential approaches to add multilingual support to the csv provider