Language of Event feature.

[cwant]

Summary of changes

This adds a "Language of Instruction" feature to events, as per #994 The languages supported are the 24 official languages of the EU: https://european-union.europa.eu/principles-countries-history/languages_en

Motivation and context

We (Canada) need this feature for the bilingual instance of TeSS we are working on, so thought it might be better to push this upstream too.

We'll see how this goes, and then add a similar feature for learning materials in the future.

Checklist

• [*] I have read and followed the CONTRIBUTING guide.
• [*] I confirm that I have the authority necessary to make this contribution on behalf of its copyright owner and agree to license it to the TeSS codebase under the BSD license.

[cwant]

Oops, looks like I have config.i18n.raise_on_missing_translations = true turned off here. Will have to either rework the failing test or do something else with the helper function.

[fbacall]

Thanks for this! Not had a chance to have a detailed review yet, but I was wondering did you consider using a gem to provide the list of language codes/names? e.g. https://github.com/xwmx/iso-639

[cwant]

I had not considered getting it from a gem. Some thoughts on that specific gem:

• Seems to only support French/English language names, which is fine for my specific use case, but lacks some generalization (it would be nice if the gem used I18n for the language names)
• I'm new to this, so I don't really know what the alpha2/alpha3 stuff is, or how (or if) it'll get used.
• For our cases, we will want to consider a subset of the languages anyways, so it's just as easy to list them. In my case two languages, in the EU case maybe 24? Having a menu with 487 languages (most of which are obscure) might be a bit much. I would assume that at some point this goes through a dictionary (app/dictionaries), so I don't know. I guess the gem could be used, then languages restricted in tess.yml. That said, I'd be happy to look into it deeper in the context of a review.

[cwant]

Thanks for the review!

• I've gotten rid of the controlled_vocabulary_or_nil business to use the allow_nil: true option of controlled_vocabulary
• I've made a method to handle the Event title facet logic
• I've used the I18nData for the localized language names. Some details and comments/questions about that:
  • I've flip-flopped on this decision, but I still keep a dictionary to handle the allowed language names (a list with hundreds of names isn't great UX). I can change this if need be. Another option I considered is listing some codes in tess.yml as being the allowable ones. The default I went with is the 24 official EU languages.
  • I'm not super happy with some of the design of I18nData. They go with iso-639-1 (two letter codes instead of three), but for some reason they decided to upper case the codes (e,g., 'EN' instead of 'en'). I decided to go with the lower case version in the standard, but this will be a deviation from the language field in the Trainer model. So yeah, this isn't great. What direction would you prefer to go? (consistency with the other table, or consistency with the standard?)
  • I capitalize language names in the form/facets, although this might be a deviation from what is done in some locales
  • Some of the language names from I18nData aren't great. Most noticeable is the Greek one:

[fbacall]

• I've flip-flopped on this decision, but I still keep a dictionary to handle the allowed language names (a list with hundreds of names isn't great UX). I can change this if need be. Another option I considered is listing some codes in tess.yml as being the allowable ones. The default I went with is the 24 official EU languages.

I think I like the idea of them being listed in an array in tess.yml, that way the order that the languages appear can also be changed. We can provide a default of the 24 EU languages in tess.example.yml.

• I'm not super happy with some of the design of I18nData. They go with iso-639-1 (two letter codes instead of three), but for some reason they decided to upper case the codes (e,g., 'EN' instead of 'en'). I decided to go with the lower case version in the standard, but this will be a deviation from the language field in the Trainer model. So yeah, this isn't great. What direction would you prefer to go? (consistency with the other table, or consistency with the standard?)

I agree it's not very nice, although the spec says they are case-insensitive. I think we should go with lower case. We can just down-case the keys from the trainers table when they are read to be consistent (or write a migration to convert the stored data).

• I capitalize language names in the form/facets, although this might be a deviation from what is done in some locales
• Some of the language names from I18nData aren't great. Most noticeable is the Greek one

How about we list the EU language names under a language key in en.yml, then when rendering the language name it checks there first and falls back to the I18nData name if it is missing?

[cwant]

This all sounds reasonable. I've integrated all of those suggestions in the latest push.