Golang: Query a no specific language string@. - and pass it on with gRPC(protoc)

[JCzz]

I have a go client which query for users:

const q = `
    {
        all(func: has(user)) {
            user.name
        }
    }
`

All good, I get an *api.Response with:
resp, err := txn.Query(context.Background(), q)

Now if I print the fmt.printLn(resp) I get some char values in asci:
{\"user.name\":\"S\303\270ren\"}]}

Then after I json.Unmarshal I get the right language:

if err := json.Unmarshal(resp.GetJson(), &decode); err != nil {
        log.Fatal(err)
    }

The language specific char ‘ø’ in the danish name Søren
fmt.PrintLn(decode)
{Søren}

Now my question is, how handle languages
My plan is to protoc >> gRPC this to a Dart client using this proto:
https://github.com/dgraph-io/dgo/blob/master/protos/api.proto

If I want the right language to show in Dart client, should I then keep track of Dart client and dgraph @dk and pass that information between client ad dgraph back and forth?

Thanks in advance

[dmai (Daniel Mai)]

Predicates (including language-specific predicates) are handled the same way from the client’s perspective. The client sends the query to Dgraph and receives the response accordingly.

You can check one of the official Dgraph client implementations like dgo to see how client handles queries.

[JCzz]

Thanks Daniel

Yes, this must bee the way, as it can only be the client who knows the language used by the user - I see.

So just to be clear how to do this, in the best way; I can see from the example that the query returns “lang”:

q := `schema(pred: [name]) {
  type
  index
  reverse
  tokenizer
  list
  count
  upsert
  lang
}`

Now an example in pseudocode:

1. Client running in english
2. Request a string field name, in a query, including the language “en”.

	{
		all(func: has(user)) {
      user.name@en
		}
	}

3. The server(dgraph) returns only names with “@en” - well that was kind of what the query was asking for, so makes sense.

Therefore, should I always query for untagged string “@.” to be sure to get a value if the is no specified language edge?

	{
		all(func: has(user)) {
      user.name@.
      user.name@en
		}
	}

Sorry, I don’t quite understand the different between edge and predicate?

That or make a query to ask for what language is available?

Thanks again - and this must be the coolest db for cloud native

[jespersm (Jesper Steen Møller)]

Why can’t you forward the user’s preferred language tag to the query, and ask for that, as in

 {
    all(func: has(user)) {
         user.name@{{user_lang}}:en:.
    }
}

Or are you caching the response somewhere in between?

[JCzz]

Hi Jesper

I agree and that will be the way around, but I just want to minimise requests. First I thought of “@.” as a kind of fallback/default for untagged strings.

Scenario: a query for friends where you don’t know the language tagged upfront.

But I guess it is not a big deal, to make a second request with another language, than the language from the initially request.
But it will require some logic handling different language than the current user - if you use the scenario with friends.

Do you have a mental model of edge vs predicate?

[jespersm (Jesper Steen Møller)]

But name@en:. will match english first, then untagged, then anything (I’m assuming the first). If you allow your users to enter any number of language variants, that is obviously not quite good enough.

Perhaps you should consider using two predicates:
preferred.user.name@.
secondary.user.name@{{client_users_lang}}:.

That way, you could choose which is the best fit for the current client.

Predicates vs. edges: No, I not totally sure what the difference is… Predicates are the types, I suppose, edges are the actual triple (including any reverse edges, if mandated by the schema). Still evaluating Dgraph.

[JCzz]

Yes, I agree - that is my same thoughts.

Thanks Jesper and maybe I will see you out there in the region of Cph - good to know that we are more around here interested in dgraph.

I will keep this open for any other input - thanks in advance.