RFC: Allow language Tag support in GraphQL

This is not very clean in my opinion. There are two parts to this equation, supporting languages in queries and supporting languages in mutations.

Supporting languages in queries (if changed from dgraph directive) should be implemented by using a lang directive in the query itself.

queryStudent {
  fullName # untagged value
  fullName_hi: fullName @lang(code: "hi")
}

The main problem with this though is that the GraphQL spec does not support directives on inputs. So how to work around this? The only limited way it can be done is with multiple input fields. But that really adds complications to required fields. Here are some things that need thought through:

  • What happens if a user marks the field with the proposed lang directive as required? Are all language fields then required?
  • What happens if a user combines the @id directive with the @lang directive? Will this be supported or throw error?
  • How to support a set of languages easily across the entire schema. If I have hundreds of string fields across multiple types, I would want to support the same language set across all strings easily without adding a complicated schema directive to every field.

A better way might be to add the directive to the query or mutation itself. With GraphQL, I don’t really see the need for a user needing different languages at once. The client would have one preferred language. If the language directive was raised to the query/mutation level, then the rewriter could add the language tag to every string field (not @id)

query @lang(code:"hi") {
  queryStudent {
    fullName
  }
}
mutation @lang(code: "hi") {
  addStudent(input: [{ fullName: "एंथोनी मास्टर" }]) {
    student {
      fullName
    }
  }
}

The only thing this would not handle is setting multiple languages at once. But would a GraphQL client with a single preferred language have the information to set the multiple languages at once? I think that might be better handled with a language hook on a mutation that grabs the string fields and enhances the database with other language translations using a translation API.

I personally don’t use the language features, and don’t see myself using them in the near future. I would prefer users to use whatever language they prefer directly. Google Translate in Chrome does a fair job of translating content when needed.

1 Like