most user-text defined string fields get turned into BilingualString types
query {
indicators {
name {
en
}
}
}
The only problem I find here is that, if they only want to fetch english or french values, they have to use different queries rather than supply a different argument. They _could_ do string replaces or something like that, but that's kind of a graphql anti-pattern because graphql strings should be statically analyzable.
It may also be annoying to constantly have to specify you want english data
## Alternative: Declaring a language in the root of the query, e.g.
```graphql
query {
extra_root_layer(lang: "en"){ # find a better name for this root layer
indicator {
name # correspond to name_en in DB
}
}
}
here, the root layer's resolver would add language:"en" on the context,
This seems like a quick and dirty fix, but it's kind of bad, because there's only one context and people might ask for 2 "root" objects of different languages. You could store this elsewhere than the context, e.g. a resolver decorator can look at the query's ancestor chain via the info argument, and infer the desired language, but that's also complex. Even if we did this, you also can't (easily) get data in 2 languages in one query.
A few ideas,
Preferred approach:
BilingualStringObject typeenandfrstring fields,BilingualStringtypes}
here, the root layer's resolver would add language:"en" on the context,
This seems like a quick and dirty fix, but it's kind of bad, because there's only one context and people might ask for 2 "root" objects of different languages. You could store this elsewhere than the context, e.g. a resolver decorator can look at the query's ancestor chain via the
infoargument, and infer the desired language, but that's also complex. Even if we did this, you also can't (easily) get data in 2 languages in one query.