Add Spanish and Portuguese versions and support language selection via URL

[jrosindell]

for Azores Biodiversity portal and improved embedding in other sites.

[hyanwong]

See also #138 , #157 and #41

[jrosindell]

I think more broadly this is part of making all the 'settings' including language and colour scheme parsable via the URL

[hyanwong]

At the moment we use the web2py "way" of doing translations: we provide the person doing the translation with a login on the beta website, but without the role of "manager" (we should set up a role of "translator" or something). They can then access e.g. https://beta.onezoom.org/manage/edit_language/fr or https://beta.onezoom.org/manage/edit_language/de which should provide a list of strings that we use in OneZoom (wrapped in the T() flag) that need translating.

This works OK: we can verify that it all works on beta, then once the translations are done we can move them onto prod. But it's a bit non-standard, which is why in #138 we were encouraged to also allow this to happen using .po files, which are more-or-less a standard in the world of translating.

@lentinj had some thoughts about how to set this all up so that it works smoothly. Perhaps he could post the ideas below, and we could cost up how much it would be for him to implement it.

[lentinj]

Whilst they're stored as python files, that's really just a convenient serialisation format web2py uses. When reading/writing, it's reading/writing a dict:

https://github.com/web2py/web2py/blob/6da8479444031c6188d64382a7c785e96cd42323/gluon/languages.py#L166-L175

What if the seams were loosened here and it could as well as reading .py files, it could also read another format? Then all the translation machinery would just keep on working as you expect, and the translator can have a file to work with using their tools.

I couldn't see a way of getting this done without modifying web2py guts, we could try and upstream of course, provided they're interested---we could open an issue to gauge interest first? The other option would be scripts to translate to/from .py files, which would be a lot simpler to code but obviously more fiddly.

The other problem is there's quite a bit of impedance mismatch between .po files (which are basically a specialised programming language) to the web2py .py dicts---somewhat akin to translating LaTeX to Markdown. We probably want to look into other formats, e.g. Android string resources which look like a closer match to what web2py wants but again more popular, things like https://poeditor.com/ support the format.

I know a translator, I could have a chat with her and see what tools/formats are most common nowadays and easiest to work with if you'd like?

[lentinj]

@jrosindell
I think more broadly this is part of making all the 'settings' including language and colour scheme parsable via the URL

This has already happened via. #369 (well, it was already the case for language and half-the-case for colour scheme).

[jrosindell]

Yes I think URL parsing language is the way forwards for this - so it's probably done but can't be closed because we'll need someone to actually do the translations later after the mechanism for this is sorted out.