[pygeoapi] i18n strategy

[Paul van Genuchten]

Hi, as just discussed on PSC meeting. We want to setup some guidelines on i18n of pygeoapi.
This is an effort to list some of the initial aspects of such a strategy.
Looking forward to hear your thoughts on following aspects:

- Use of Transifex is an option to allow users to translate to their language of choice. Transifex does support a variety of output formats. It is free of use to opensource projects (used by osgeolive, geonetwork, …) Ownership of the translated strings remains with the authors.
- Who can contribute i18n best practices from geopython world? 
- i18n in jinja templates. The templates for html generation provide an option to add translations via a jinja i18n extension: https://jinja.palletsprojects.com/en/2.11.x/templates/#i18n-in-templates <https://jinja.palletsprojects.com/en/2.11.x/templates/#i18n-in-templates>
- Jinja and python will share a single translation file, or each will have a set of translations, with risk of duplication of basic strings.
- A choice should be made to have the translation key as human readable english (so code can print the key if no translation is provided) or use human unfriendly keys and let the code look up the english translation in case no translation is available.
- Technical errors should not be translated, users should be able to copy paste it into google to find the best match possible.
- Are we also providing translation options for the documentation?

I recently made a translation guidelines document for the geonetwork opensource project at https://github.com/geonetwork/core-geonetwork/wiki/Translation-guidelines <https://github.com/geonetwork/core-geonetwork/wiki/Translation-guidelines>, probably some aspects are relevant to the pygeoapi project as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pygeoapi/attachments/20201221/d04e7e13/attachment.html>