Need an approach to have forms with languages in forms not supported in Django

[dpalomino]

Currently we are not supporting forms containing labels in languages that are not supported in Django (see list here). This is problem because the list of supported languages in django is relatively short and partners need to work with forms in many different local languages.

We need to do some research/testing to see if we can include a large list of iso-639 languages to be accepted by the platform, and see if it is properly showed in the platform and though the ODK/GeoODK apps.

[dpalomino]

@oliverroick Maybe something we can take a look as we will be upgrading to django 1.10? Thanks a bunch!

[oliverroick]

I thought about this a little and here's what I believe we need to do (I'm sure I'm missing some of the in-depth details here though):

• Find and implement a way to validate language codes provided with the XLSForms. Ideally, we would verify codes against a list of language codes, which also contains language names in different languages that we can use to populate an additional select field.
• Implement a way to change the labels based on the selection in the select field. First, we need to get the labels for a language from the backend, then match them to the existing labels and replace the existing labels with the new language. We currently render most of our UI in the backend, so we'd have to write a fair amount of JavaScript to allow for those changes and we'd have to write code for the backend to support serving new labels. Before we can do that, we should agree on a general architecture/pattern for the front-end and client-server communication so we build something sustainable that we can re-use again.
• When initializing the form, we should take into account, which language is selected platform-wide, check whether the language is supported in the XLSForm and switch to that language or fall back to the default language. This can probably be mostly implemented in the backend.

To sum up, I see this as a new feature, which needs requirements, design, and architecture, probably some prototyping before we can implement the solution. It's definitely nothing we can do whilst upgrading Django.

[dpalomino]

Thanks @oliverroick for the detailed analysis!

I think we have three different requirements here:

1. Showing in GUI the labels in languages that are not supported in Django
2. Showing in xfoms used by ODK and GeoODK the labels in languages that are not supported in Django
3. Being able to filling in forms in GUI using a language/script not supported in Django
4. Being able to filling in xforms in ODK/GeoODK using a language/script not supported in Django

(3) and (4) are definitely the most important ones. Then (2), and lastly (1).

Is there any easier way to cover (3) and (4)?

Again, thanks :)

[dpalomino]

Ok, so I've done this quick test:

1. Finding something written in a not supported language:
   

2. Copy and paste in a field from a testing project:
   

And it worked. So (3) seems to be covered. I will try to test (4) later on from an Android device and see what happens.

[dpalomino]

I've been testing also with case (4), filling forms in ODK/GeoODK using languages not supported by django and submitting to the platform, and they are accepted.

Then, we are only missing to show labels in other languages in GUI (1) and apps (2). Probably this has a lower priority for now.