A few ideas,
Preferred approach: BilingualString Object type
- create a graphql BilingiaulString object type
- it has
en and fr string fields,
- 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.
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,BilingualStringtypesThe 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.
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.