RFC: Allow language Tag support in GraphQL

[JatinDevDG (Jatin Dev)]

Thanks @amaster for detailed comment.

@amaster507

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.

1. If the user marked field with lang directive required then we can make the untagged field as required and language tag fields as optional.

2. Similarly we can apply @id directive to untagged value.

3. We haven’t think of this but may be we can add slice of strings in schema hreader which will contain all the common languages that user want to use and then use that in different fields across types.

@amaster507

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 see some problems with this design also .For example , we are passing single code to query/mutation but what if there are multiple fields with @lang directive. And putting @lang in query/mutation will complicate things.

So as of know we are thinking of supporting it through @dgraph directive and user needs to define all the fields which corresponds to different language tags that he want to use.

GraphQL design with @dgraph directive

User needs to define different fields for different language tags that he want to use.
Example:

type Person {
         name: String 
         nameHi: String @dgraph(pred:"Person.name@hi")
         nameEn: String @dgraph(pred:"Person.name@en")
         nameHi_En:  String @dgraph(pred:"Person.name@hi:en") //desn't generate for mutation 
         nameHi_En_untag:  String @dgraph(pred:"Person.name@hi:en:.") //doesn't generate for 
      
      }

We will add @lang in dgraph schema for the corresponding predicate automatically.
User needs to give dgraph predicate name of the untagged field(name in this case) in @dgraph argument of language tag field.
Dgraph predicate name for the corresponding graphql field typename.fieldname
For example, in nameHi: String @dgraph(pred:"Person.name@hi") we have Person.name which is predicate in dgraph for the corresponding field name in graphql. If user give some other field name in argument then it won’t work as expected.

Note

1. User needs to at one place either in all language fields in type or in the interface.
2. We won’t be adding fields in mutation patch which have multiple language tags , for example field nameHi_En: String @dgraph(pred:"Person.name@hi:en") can only be queried.

Interaction with exiting directives for language tagged fields:

schema directives

@id : not required now, can be added in future .
@search: applicable only on one field(tagged or untagged value) and will apply on all gql fields which map to the same dgraph predicate.
@lambda: doesn’t work with @dgraph directive
@custom : doesn’t work with @dgraph directive
@hasinverse: doesn’t apply on string fields

query directives

@skip: Work normally as with other fields
@include: Work normally as with other fields