Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 02 17:30
    tomkralidis commented #829
  • Dec 02 17:06
    francbartoli commented #827
  • Dec 02 16:10
    jemrobinson commented #829
  • Dec 02 12:03
    tomkralidis commented #829
  • Dec 02 11:59
    tomkralidis commented #827
  • Dec 01 14:15
    jemrobinson labeled #828
  • Dec 01 14:15
    jemrobinson opened #828
  • Dec 01 13:59
    jemrobinson labeled #826
  • Dec 01 13:59
    jemrobinson opened #826
  • Nov 30 17:01
    justb4 commented #821
  • Nov 30 16:35
    KoalaGeo commented #821
  • Nov 30 11:49
    justb4 commented #821
  • Nov 30 11:06
    KoalaGeo commented #821
  • Nov 30 10:46
    justb4 commented #821
  • Nov 29 20:56
    francbartoli commented #821
  • Nov 29 20:03
    KoalaGeo commented #821
  • Nov 29 20:03
    KoalaGeo commented #821
  • Nov 25 21:21

    tomkralidis on master

    add invalid value to console er… (compare)

  • Nov 24 20:28
    Dylan-Pugh opened #824
  • Nov 24 20:28
    Dylan-Pugh labeled #824
paul van genuchten
@pvgenuchten
I deployed the multilingual branch here
paul van genuchten
@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
paul van genuchten
@pvgenuchten
2 replies
paul van genuchten
@pvgenuchten
just created this issue geopython/pygeoapi#663, it gives potential approaches to add multilingual support to the csv provider
Tom Kralidis
@tomkralidis
can we keep the multilingual out of providers by default? For those who need multilingual, it can be added in the provider_def dict that gets passed (which is the provider block in config
Sander Schaminee
@GeoSander
Yes, I have been thinking of adding that to the passed-in definition, but I didn't like the idea of manipulating the definition (which should be static imho) with a dynamic parameter that could theoretically change for each request
Tom Kralidis
@tomkralidis
good point
Sander Schaminee
@GeoSander
Note that the 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.
Tom Kralidis
@tomkralidis
What does MapServer do for language handling on data connections?
2 replies
as far as the backends, language would obviously be passed in the query functions. Why do we need it in the constructor?
Sander Schaminee
@GeoSander
That's an option too. However, get (for a single identifier) would also need it and possibly get_fields too
(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)
Sander Schaminee
@GeoSander
Since the provider class is reloaded on each request, it's cleaner to set the language once, I think. I wish I could do the same to the API class, but then people could set other people's language :D
We'd be forced to start using sessions then...
Tom Kralidis
@tomkralidis

(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

That's an option too. However, get (for a single identifier) would also need it and possibly get_fields too

If this removes the lang option from providers, I think it’s worth it, what do others think?

Sander Schaminee
@GeoSander
You mean the language parameter from the __init__ of the provider class?
Tom Kralidis
@tomkralidis
yes, only pass language to the query or get functions?
Sander Schaminee
@GeoSander
As yet another parameter... Well, I noticed you already started using **kwargs in the EDR provider, so we could throw anything at it, I guess :)
paul van genuchten
@pvgenuchten
no, i'm in favour to have language, like format and schema as explicit parameters
but we could add it only to the relevant methods and not to all
Sander Schaminee
@GeoSander
Me too. And having the base class deal with the logic to find the best matching look language is more elegant and easier to use for plugin developers
But I do like @francbartoli 's idea actually to make a language-aware base class that deals with this stuff that provider classes can implement. All current providers won't have to implement that so they stay the way they are now (no extra parameters).
paul van genuchten
@pvgenuchten
does it mean you pass in the (web)request object and the base class extracts the relevant language from it?
Sander Schaminee
@GeoSander
That could be an idea yes
paul van genuchten
@pvgenuchten
but what if pygeoapi is used outside a web-request scope
for example to render something in a desktop application
(not sure if that is possible)
the desktop app would need to mimic a web request to feed to the provider?
1 reply
Sander Schaminee
@GeoSander
Me neither :)
paul van genuchten
@pvgenuchten
to me parsing request parameters is something which should be managed in a generic module, not in a provider...
Sander Schaminee
@GeoSander
It is handled in the l10n module actually (using the get_plugin_locale function), but because the provider stores that locale property now, the provider calls that function
paul van genuchten
@pvgenuchten
but it makes sense to have some base-parameters wrapped in an object, which is send with every provider-call
Francesco Bartoli
@francbartoli
Parameters from the request are parsed in the api.py not in the providers @pvgenuchten
paul van genuchten
@pvgenuchten
makes sense
Sander Schaminee
@GeoSander
]
\
"{
:]
paul van genuchten
@pvgenuchten
but then i miss the point here,
Sander Schaminee
@GeoSander
[;
Sorry, that was my kid...
paul van genuchten
@pvgenuchten
:-)
Sander Schaminee
@GeoSander
Typing while I was away
paul van genuchten
@pvgenuchten
so language, like format, would be parsed in api.py and then sent to the provider with relevant calls?
these base-parameters can be wrapped in an object, so we wouldn't need to extend each of the calls when we add an additional property (like schema)
Sander Schaminee
@GeoSander
We could also find the best match for the requested provider language in api.py(we already have the provider definition there too) and pass that as a Babel Locale to the provider (e.g. in the query call). That would keep the providers "clean" while still keeping it semi-intuitive.
Sander Schaminee
@GeoSander
Experimenting a bit now...
How would you guys suggest passing the language to the query (and get) function? Simply add a language=None parameter? This means I'll have to change all the signatures for each provider query function. Then we'll have a parameter in there that most providers won't need. Changing the signature to just have **kwargs would also be a possibility and more future-proof, but we'll have to document this properly (like @tomkralidis did for the new XarrayEDRProvider), else developers will be in the dark as to which items are available in the kwargs dict.
Any other suggestions?