Open jameshadfield opened 4 years ago
jameshadfield
commented
4 years ago In order to start discussion, especially in light of https://github.com/nextstrain/auspice/pull/953, I've made this figure to explain some of the complexities in language choices between the Gatsby app & auspice. I think we need to decide on the big picture before proceeding with https://github.com/nextstrain/auspice/pull/953. Comments welcome!
joverlee521
commented
4 years ago I feel like there should be one source of language between auspice and nextstrain.org. Auspice should have the ability to take in translated language from the server. Just like how Auspice loads available datasets from the Nextstrain server, it should also load available languages from the Nextstrain server.
Auspice can continue to have it's own translations just like show in https://github.com/nextstrain/auspice/pull/953, but the nextstrain server should be the ultimate source of truth for the website.
jameshadfield
commented
4 years ago After discussion with @joverlee521 and the work on nextstrain/auspice#953, here is a general plan for how we should proceed. It is based on the sketch in my previous comment.
1) auspice gets language support as per nextstrain/auspice#953, and we crowd source additional translations. Language can be set via a UI element in the sidebar (in dataset view), and results in a ?lang=... URL query (except if English).
2) Nextstrain.org’s Gatsby app gets language support (the exact details of how the markdown files are stored and how we deal with keeping things current are not considered here, but there must be precedent for this in other Gatsby apps). This is selectable via a UI element as well as resulting in URL changes (unsure about pathname vs ?lang=..., is one of these forced by Gatsby?)
3) A nextstrain cookie (or similar) reflecting the user language choice is set via code in Gatsby or Auspice (e.g. via the nextstrain.org auspice customisations injected at build time). This cookie is read by Gatsby or auspice to keep the language choice “in-sync” (this is points (iii) & (iv) in figure).
3) @joverlee521 has an implementation to use the browser’s language to inform what language we should be displayed. Currently this is used only to redirect the default nCoV sit-reps to the appropriate language -- code here. We will adapt this approach to be imported by Gatsby & the customization for auspice and it’ll trigger a change similar to (1) and (2), unless a cookie has been set.
4) Auspice adds the selected language (redux state) as a query to all existing charon API requests. This allows the server to deliver a narrative/dataset in the correct language if it can. To start with, we’ll use this to reproduce current behavior whereby a request for the nCoV sit-rep with no language specified will return the sit-rep matching the lang query-parameter if that language if available. There's a bit of complexity here as currently we encode the language in the narrative URL (e.g. https://nextstrain.org/narratives/ncov/sit-rep/de/2020-03-13) and I think we want to keep this.
5) We currently have a narrative-language dropdown in the nav-bar of auspice (note that this is via code in the nextstrain.org repo which is injected into auspice at built time). I think this can remain as-is, but be extended so that changes here also trigger a auspice redux action to change the language of auspice and update the cookie (e.g. going to the German narrative will switch auspice, and Gatsby via the cookie, to German if available).
crwilcox
commented
4 years ago Is there a sense of the languages that are most needed? Is this the same set of languages for sitreps and auspice?
jameshadfield
commented
4 years ago Is this the same set of languages for sitreps and auspice
Generally, yes -- it'd be great to be in a place where you can view a sit-rep in language X, and both auspice and nextstrain.org (docs, help etc) is also in that language. There are some complexities on syncing up that choice between the different moving pieces, which this issue tries to detail. Long term, more languages could be added, but right now we have 14 (wow!) translations of the sit rep and so getting these languages working well is the top priority.
There is currently no language support* in nextstrain. This issue is cross cutting between auspice & nextstrain.org, but is detailed here for both.
Brief background of nextstrain.org vs auspice
Nextstrain.org is the codebase which sits behind (you guessed it) nextstrain.org! Apart from server code, it contains the “static-site”, built using Gatsby, which contains the docs, help pages & splash page. This repo has auspice as a dependency & serves a customized client bundle for all of the interactive visualization (i.e. nextstrain.org/ncov is essentially auspice). Please see the readme for more information including how to build & develop locally.
Summary of where we want to go
This issue asks for guidance and implementation for how to incorporate language translations of (i) The nextstrain.org static site and (ii) Auspice. This includes a UI element to change between them, a consistent URL naming scheme (if the language is reflected in the URLs) and communication between the two apps (e.g. if nextstrain.org is loaded in Italian, and you then view the nCoV dataset, auspice should use Italian if possible).
Complicating factors
These are the potential quirks which must be taken into consideration (at least, these are the ones I can think of — I’m sure there are others):
Once we settle on the technical approach to using translations, we can create a number of issues asking for translations of various pages etc. We have a great opportunity now to leverage community contributions for translations at the moment 😃
[*] We do write narratives in different languages in the form of different markdown files. The nav-bar element which is injected into auspice at build time — code here — contains a dropdown which allows you to toggle between different translations. Auspice isn’t aware of the language change, it’s simply displaying a narrative which happens to be written in a different language.