Fully expanding I18n

[cwant]

As we explore a bilingual version of TeSS, we find places were the I18n support has been missed in the TeSS source code.
We intend to work on these areas on our own fork, but I though it would be good for this work to benefit your upstream project too.
This issue is meant for a discussion of how to handle the problems before the work begins.

Here are some places where i18n hasn't been handled, some are easier to deal with than others:

1. Strings directly in the view templates. These are easy to handle (just chuck in a <%= t(:whatever) %> as needed)
2. Strings returned by code (model, controller, helper) that don't go through I18n. These will take some searching to find, but are straightforward.
3. ActiveRecord model/attribute stuff. These will be harder to detect, as some things only show up during error messages, etc. The path to the translated string in the locales files looks like en.activerecord.models.<modelname>.attributes.<attributename>. Some attributes have been handled in the locales files, but this would be a small proportion of all of the attributes.
4. Facets from controlled vocabularies. These need some thought and design work.
5. Other stuff ... ?

For facets/dictionaries, we currently have things like: https://github.com/ElixirTeSS/TeSS/blob/master/config/dictionaries/difficulty.yml
What would likely need to happen is most of the content would be stripped out (leaving perhaps only the keys), and the English sentences get pulled out into the locales files (either put everything in en.yml, create a locale file for all of the dictionaries, or create a local file for each dictionary). The "Language of Event" feature (PR #995), does have an example of a facet value that goes through I18n (but is this the approach we want to take with each of the dictionaries/facets?).

Anyways, I'd seek some input from anybody that has an opinion on this matter. (Worst case: if this is too much, we'll just make sure our bilingual version of TeSS is fully I18n-ed).

[fbacall]

Expanding the i18n support would definitely be a welcome addition.

I think I agree with your difficulty assessment. Facets would indeed be particularly tricky to handle - it does make sense to filter using keys rather than values (e.g. de vs. Germany), and I wish it was done that way in the first place, but this would break a lot of links, API clients etc. Possibly we could make this behaviour configurable somehow (without making the code too complicated).

Do you have any plans on how to handle the language of the content submitted to your instance? e.g. what happens when an event with an English title, description, keywords etc. appears in francophone user's search results.

[cwant]

I suspect that the facet stuff will have to go in our fork (currently in our private GitLab -- still thinking about strategies for it to be in GitHub). If it goes well, maybe this will be something to consider upstream in the future (or not -- we have a commitment to a bilingual portal, whereas your English-only portal does not need it).

We only have a partial strategy for correctly handling language of event. One simplifying assumption we can make is: if it's not from Québec, it's probably English (so there are may be only one or two content providers we need to watch out for). In Québec there will be both English and French sessions, so we can either get those content providers to flag them, or do some form of auto-guessing (probably the first technique is the safest). Both English and French will show up in the francophone user's search results anyways, but we have the Language of Instruction facet so they can filter them.