Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 20 19:37
    pvgenuchten commented #877
  • May 20 19:28
    pvgenuchten opened #906
  • May 20 19:28
    pvgenuchten labeled #906
  • May 20 18:44
    pvgenuchten commented #902
  • May 20 13:00
    pvgenuchten commented #902
  • May 20 12:44
    pvgenuchten commented #901
  • May 17 03:39
    ksonda commented #901
  • May 17 03:35
    ksonda commented #901
  • May 17 03:34
    ksonda commented #901
  • May 16 11:08
    tomkralidis commented #902
  • May 16 09:44
    francbartoli commented #902
  • May 16 09:32
    GeoSander commented #902
  • May 15 16:38
    ksonda commented #577
  • May 15 11:30

    kalxas on master

    Update requirement.txt (#894) … (compare)

  • May 15 10:03
    pvgenuchten labeled #901
  • May 15 10:03
    pvgenuchten opened #901
  • May 15 09:52
    pvgenuchten commented #577
  • May 15 09:38
    pvgenuchten edited #900
  • May 15 09:31
    pvgenuchten edited #900
  • May 15 09:31
    pvgenuchten assigned #900
Just van den Broecke
@justb4
yes, thanks @tomkralidis !
Angelos Tzotsos
@kalxas
pygeoapi 0.10.0 deb packages are now available in UbuntuGIS experimental ppa
Tom Kralidis
@tomkralidis
thanks @kalxas !
Tom Kralidis
@tomkralidis
hi all: I pushed a couple of bug fixes and we will cut 0.10.1 as a patch release
Angelos Tzotsos
@kalxas
+1
Tom Kralidis
@tomkralidis
@GeoSander is #656 ready for review?
Sander Schaminee
@GeoSander
Yes it is! :)
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.
Angelos Tzotsos
@kalxas
Travis fails because we reach our dockerhub limit
Sander Schaminee
@GeoSander
Yes, but I've also had other issues. A timeout and a WFS provider test failure on one of the 2 builds (even though I didn't change anything in that provider).
Tom Kralidis
@tomkralidis
we can ignore the WFS provider error given it is a remote resource which results in issues we cannot control.
Sander Schaminee
@GeoSander
Yes, it might be good to build that into the tests somehow? Ignore failure if the WFS provider backend returns a 500 or something?
Tom Kralidis
@tomkralidis
Agree (cc @justb4). Would be great (in another PR) to mock that out somehow
Sander Schaminee
@GeoSander
true
Just van den Broecke
@justb4
pygeoapi.io and many others (at same provider) seem to be down, but are not. Looks like DNS-issue...
@GeoSander can we go with lang= instead of l= ?
Paul van genuchteG
@pvgenuchten
we took l=, similar to f=
Francesco Bartoli
@francbartoli
+1 for lang=
Tom Kralidis
@tomkralidis
I feel a bit weird that, in configuration, values are now either a string or a dict
Francesco Bartoli
@francbartoli
Where is a dict @tomkralidis?
Tom Kralidis
@tomkralidis

so in the config you can have:

 title: pygeoapi default instance

or

 title:
    en: pygeoapi default instance
4 replies
Francesco Bartoli
@francbartoli
Ah ok, agree that doesn’t look good
maybe we can just take the second as the default? So the first one would become no longer valid?
Tom Kralidis
@tomkralidis
I was thinking the same thing
it looks like the whole decorator pattern around headers and args has been fixed/improved
Tom Kralidis
@tomkralidis
@GeoSander why do plugins need a locale again?
Paul van genuchteG
@pvgenuchten
idea is that the provider can decide to return the neglish or french representation of the feature
Sander Schaminee
@GeoSander
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 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 of l= ?

I prefer lang too actually, but went with what @pvgenuchten suggested ;)

Tom Kralidis
@tomkralidis
is the core driver of this PR multilingual for the UI or the pure JSON API?
Sander Schaminee
@GeoSander

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.
Paul van genuchteG
@pvgenuchten
but the pr focusses on the json part, the ui part will be in a next pr
Sander Schaminee
@GeoSander
Note that there's documentation for users, maintainers and plugins developers included in this PR
Tom Kralidis
@tomkralidis
you mean JSON responses returned by the server, not by the provider, no?
16 replies
I’ve added @kalxas @justb4 and @francbartoli to additionally review this PR
Sander Schaminee
@GeoSander

you mean JSON responses returned by the server, not by the provider, no?

Yes (but indirectly by the provider)

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
Paul van genuchteG
@pvgenuchten
I deployed the multilingual branch here
Paul van genuchteG
@pvgenuchten
A sparql backend would typically return localized responses, for the traditional data formats, the python provider code could manage about it
For elastic, I’m not sure what the current localization support is