add multilingual capability

[tomkralidis]

Following on from opengeospatial/ogcapi-features#134, add capability to support multiple languages:

• support requests with Accept-Language
• support responses with Content-Language
• multilingual metadata in configuration
• handling hreflang in links in config
• other?

[pvgenuchten]

A thing to consider, adding a browser language override mechanism as url-param &lang=fr (and a language switcher in html), requires any override value to be included in all links

I guess we'll use web locales (en/fr/nl/en-GB/fr-CA), not iso (dut/fre/eng)

Consider to let admin set a default language, if requested language is not in available languages

There should probably also be localization files for hardcoded strings (and documentation)

[tomkralidis]

cc @francbartoli

Good points @pvgenuchten. One consideration is that of pygeoapi being integrated into arbitrary Python frameworks. For example, all of pygeoapi (assuming werkzeug) is framework agnostic except for pygeoapi.flask_app. So a Django wrapper need only create something like pygeoapi.django_app and implement the same thing obeying Django-isms. Still some work, but IMHO tractable and pretty self-contained.

Having said this, implementing i18n in pygeoapi would need some thought w.r.t. being as agnostic as possible. Options:

• text in Python code: implement standalone i18n in all Python code. Works anywhere
• text in Jinja2 templates: this differs between Flask and Django, and perhaps other frameworks. Any ideas? Would Flask's {{ _('text to translate') }} approach work in non-Flask frameworks?

[pvgenuchten]

Check out the inspire with wfs3 discussion doc with proposals to add a Lang parameter

[alpha-beta-soup]

Pingback to related #317

The corollary is that it might be important to consider the degree of equivalence between Accept-Language, hreflang and the potential URL parameter lang; and to consider standardising values around RFC 7231 (s5.3.5).

[francbartoli]

cc @francbartoli

Good points @pvgenuchten. One consideration is that of pygeoapi being integrated into arbitrary Python frameworks. For example, all of pygeoapi (assuming werkzeug) is framework agnostic except for pygeoapi.flask_app. So a Django wrapper need only create something like pygeoapi.django_app and implement the same thing obeying Django-isms. Still some work, but IMHO tractable and pretty self-contained.

Having said this, implementing i18n in pygeoapi would need some thought w.r.t. being as agnostic as possible. Options:

• text in Python code: implement standalone i18n in all Python code. Works anywhere
• text in Jinja2 templates: this differs between Flask and Django, and perhaps other frameworks. Any ideas? Would Flask's {{ _('text to translate') }} approach work in non-Flask frameworks?

That's not implemented in Starlette yet encode/starlette#279

[tomkralidis]

Note language support in OGC API - Features for INSPIRE download services: https://github.com/INSPIRE-MIF/gp-ogc-api-features/blob/master/spec/oapif-inspire-download.md

[jorgejesus]

I would consider something like having a high level language support in the config file

languages: ["en","fr","nl","pt"]

And then for the dataset maybe implement standard language, and optional ??

lakes:
        type: collection
        lang: nl

Then we could have other system/code/implementation to deal with language translation. Mainly different templates based on language??

I see the point of @francbartoli #100 (comment) and it would be very good to be language agnostic and put things on the side of web framework (better translation tools), but:

• Do we consider data to be language agnostic, and do we need to map data names into different languages?
• Being language agnostic would require that the used templates would have rely on translation tools from the web-framework being used, is this reliable if we want to be independent?

[pvgenuchten]

In config.yml imho there needs to be 3 aspects related to multilingual:

• A listing to indicate which languages are supported by the service
• Provide translations for the title/abstract of the service and datasets
• Indicate which attributes in the dataset are represented in which language

My previous comments was mostly related to point 3. Another option for point 3 would be to use the json-ld context file, which can indicate the language used in a field.

[francbartoli]

@pvgenuchten I’m not totally convinced of the support we are talking about.
I would expect that the multi language capability will be part of the OAFeat spec pretty soon since the risk is to take our own journey just in configuration/templates that will be hard to maintain in the long run.
Actually, this is IMHO a general consideration and concern when I see the HTML augmented as compared to the JSON representation of the same URI.

[pvgenuchten]

Totally agree we should adopt anything indicated by the standard, but the group also gets inspired by existing implementations, if we move a bit ahead of the group and show something is working well...

It's good to have this issue as a general discussion, but we probably need separate issues with concrete tasks, such as:

• a mechanism to identify the current language for the response
• a mechanism to store/import translations
• replace hardcoded strings in html by translatable keys
• a mechanism to define a language property of an attribute of a Collection or Item (e.g. Windmill.title_fr is in french), adding a ld-context could be the approach here
• If a language specific attribute exists, add it to html in favour of those in other languages

[pvgenuchten]

A nice i18n blog with babel is a flask plugin, so probably not generic enough for pygeoapi, but the blog describes a nice way to match the language accept header against any of the available languages

def get_locale():
return request.accept_languages.best_match(app.config['LANGUAGES'])

[tomkralidis]

Initial implementation in #664 now in master.

[jvanulde]

Has there been any work on multilingual templates (i.e. landing_page.html)?

[tomkralidis]

This is pending in #725.