-
Notifications
You must be signed in to change notification settings - Fork 3
Description
A few ideas,
Preferred approach: BilingualString Object type
- create a graphql BilingiaulString object type
- it has
enandfrstring fields, - most user-text defined string fields get turned into
BilingualStringtypes
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.
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.