Prisma1: publish a way to localize specific fields

[dohomi]

Hi
It would be great if graph.cool would publish a way how to enable localization for fields. I think somewhere where the user enables constraints like unique it would be great to enable localization for that field. In the user settings the user should provide a setup which locales he is interested to use.
Hope this make sense to you.

[sedubois]

It would be nice to know your use case. I wonder if an API should be localized at all. Shouldn't localization be performed on the client, like rendering?

[dohomi]

I was more thinking about the backend of graph.cool, is this the wrong project for that? My usecase would be a content storage for a CMS, where fields needs to be localized.

[schickling]

Hi @dohomi. That's a really good point and a prime example usage for Computed Fields #56.
We've plans for implementing that early 2017.

[dohomi]

@schickling thanks sounds great. I will watch that feature and meanwhile playing around how to archive that with the setup

[schickling]

In the meantime I'd suggest you'd calculate the needed values in advance with the help of Mutation Callbacks or as @sedubois on the client side.

[sorenbs]

You could achieve localisation with the current api if you are willing to setup a slightly more complicated data model.

For example if you have an Article model and it should be possible to specify the title in multiple languages and use the english version as fallback if the proper translation is not available you could do it like this:

Content {
  text: String!
  locale: String!
  priority: Int!
}
Article {
  title: [Content!]
}

priority is only there to make sure the fallback language is not returned if the actual translation is available.

If you create an article with two title translations:

{
  text: "Highlights of 2016",
  locale: "en-GB",
  priority: 0
}
{
  text: "Højdepunkter fra 2016",
  locale: "da-DK",
  priority: 1
}

you could get the correct translation with a single query:

{
allArticles {
    title(first: 1, orderBy: priority_DESC, filter: {OR: [{locale: "da-DK"}, {locale: "en-GB"}]})
  }
}
returns: 
data: {
  allArticles: [{
    title: "Højdepunkter fra 2016"
  }]
}

{
allArticles {
    title(first: 1, orderBy: priority_DESC, filter: {OR: [{locale: "es-ES"}, {locale: "en-GB"}]})
  }
}
returns: 
data: {
  allArticles: [{
    title: "Highlights of 2016"
  }]
}

If you are building the backend for a cms, I think this is an important part of your application, and it would make sense to introduce this complexity in your api.

If you do go down this route I would love your feedback on how we could make the api more powerfull to better support this use case.

[sedubois]

Thanks @sorenbs for the workaround above. It would be great if Graphcool offered an API to query the proper locale using a variable:

query getArticle($locale: Enum = EN) {
  Article(locale: $locale) {
    title
    body
  }
}

or something like that. I think the form (locale: $locale) could be very helpful to the end-user. Any chance of having that?

[marktani]

I am not sure what that query would do, can you elaborate?. You certainly have more articles than one for a given locale, right? So allArticles seems like the better choice here.

[sedubois]

Also I don't see how to use the workaround above for having relations with other models, as different versions of the same article are actually not formally linked to each other.

For example I have types Course, Module, Session which all have different fields such as title, description, audio, etc. Each of these fields need to be localized and my views need to be able to query various combinations of these fields as needed.

NB: the localized fields are not necessarily of type String, e.g I also have audio files which are specific per language. In the future there might be other types like images with text content.

How do I achieve that? As a workaround I could just use separate fields like titleEN, titleFR, etc and just query all of them and select the right one client-side, but it undermines performance and doesn't scale.

[sedubois]

@marktani yes sorry, should be allArticles.

[sedubois]

OK I just familiarized with the @include directive and I think it gives a nicer workaround:

// schema
type LocalizedString implements Node {
  course: Course @relation(name: "CourseOnLocalizedString")
  en: String!
  fr: String!
  ...
}


type Course implements Node {
  title: LocalizedString @relation(name: "CourseOnLocalizedString")
  ...
}

// usage
gql`
  query courses (
    $en: Boolean!
    $fr: Boolean!
  ) {
    allCourses {
      title {
        en @include(if: $en)
        fr @include(if: $fr)
      }
      ...
    }
  }
`, {
  options ({ locale }) {
    return {
      variables: {
        en: locale === 'en',
        fr: locale === 'fr'
      }
    }
  }
}

At least I'm only downloading the concerned language and at the same time, the translations remain linked to each other in the schema which allows to build relations with other types.

But the query still needs to have an extra parameter for every language, which doesn't scale well.