You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 layerindicator {
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.
The text was updated successfully, but these errors were encountered:
A few ideas,
Preferred approach:
BilingualString
Object typeen
andfr
string fields,BilingualString
typesThe 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
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.The text was updated successfully, but these errors were encountered: