Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 12:00
    tomkralidis commented #844
  • 11:43
    tomkralidis closed #845
  • 11:42
    tomkralidis assigned #845
  • 11:42
    tomkralidis milestoned #845
  • 11:42
    tomkralidis reopened #845
  • 11:42
    tomkralidis commented #845
  • 11:42

    tomkralidis on master

    fix OAProc relation types (#846… (compare)

  • 11:42
    tomkralidis closed #845
  • 08:25
    dthib commented #835
  • 03:04
    tomkralidis commented #845
  • 03:03
    tomkralidis milestoned #846
  • Jan 24 23:11
    jerstlouis edited #845
  • Jan 24 23:09
    jerstlouis labeled #845
  • Jan 24 23:09
    jerstlouis opened #845
  • Jan 24 18:37
    maaattes opened #844
  • Jan 24 18:37
    maaattes labeled #844
  • Jan 24 15:11
    doublebyte1 closed #843
  • Jan 24 15:10
    doublebyte1 commented #843
  • Jan 24 14:51
    doublebyte1 edited #843
  • Jan 24 14:49
    doublebyte1 labeled #843
Tom Kralidis
@tomkralidis
@GeoSander can we go with lang= instead of l= ?
paul van genuchten
@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 genuchten
@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 genuchten
@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 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?