[Editor note: Sharing the original thread Tyler started about localization from the Champions Slack workspace]
This may not be the right place, but starting somewhere. Does anybody have any patterns or lessons learned from incorporating localization into the graph? The caveat is that we don’t have (and don’t have a plan for) user or account-based settings to check within the graph. We’ll likely determine the locale based on the browser/device. I’d rather not have to include an input argument and pass it down through the resolvers, but maybe that’s the best (only? lol) option?
You could pass the locale as a header and ensure it’s propagated to all subgraphs. Arguably the locale is already there based on the
Accept-Language
header if you’re OK using the locale preferences of the browser/device.
Thanks, Greg - Are there any Apollo docs or talks on this that I haven’t come across in my searches yet that you would recommend?
Here is the accept-language header docs from mozilla: Accept-Language - HTTP | MDN
I have learned not to deviate from the standards. I am currently in the process of removinglocale
from our keys in our supergraph…
Depending on the platform you are building the subgraphs on, there is likely a prebuilt open source package to be able to parse the header for you to get the language(s) you can support
Our subgraph(s) will likely be built in node. But it sounds like the accepted approach is to leverage the
accept-language
header between clients and graph?Love this group for getting tried and tested answers
I’d say that is the current modern standard for locale selection from browser to server. I have just seen it done so many other ways and it has never played out as well as just letting the browser select the language and passing that through the system (specifically through the standard header) (edited)
I would say the only reason to do otherwise is if you have a locale selection UI in your client and some form of validation in the back-end. At that point, you’d want a more deterministic “what was the user’s valid locale selection” rather than use the
accept-language
header.Since you neither have nor plan to have such a client experience,accept-language
should be a good solution.
Hey @saurav_t, can you share how Expedia’s graph does this?
we started with passing the locale as an input arg since we had the philosophy that everything a query needs to resolve properly should be in the query itself. That did not scale over the years. (read auth/z, spoofing).Current approach is to pass it via standardized headers.
If you are planning or using entity cache on router level, if using federation and router, the headers are not taking into consideration building the signature to the record, so keep that in mind (edited)
Are you saying that the
accept-language
header is not used to construct the cache key used in entity caching?
Yes, I was planning to open a ticket with Apollo about this interesting case. I just have not had time yet, but I will do it tomorrow. However, this is likely the expected behavior because only entity caching uses the request body to construct the cache key.
I know the
accept-language
header is not being taken into consideration. I have already tested it, but I am not sure if any other headers are being taken into consideration (edited)
By default, I think you’re right that headers are not part of the entity caching cache key.If you were to read the locale from the header, then assign it to a field and include it as part of the key, then it would be considered for entity caching.
type Product @key(fields: "sku locale") { sku: String! """ From the accept-language header """ locale: String! """ Localized using the
locale """ name: String! }
That could result in its own issues, though, since you’d be creating a compound key.I also think you can define your own cache-key logic in the Router, but I don’t have experience with that. (edited)
So, there are two main ways to handle cache keys (I think) … The surrogate keys which I do not think in this case makes any difference but I would have to test it, and the customize key which might work if you do like sha generation using the headers value or something like that (edited)
Hey, Jay Anslow, - I know you didn’t give this talk, but Dominic’s account is deactivated and I figured you’d still be able to provide some insight.https://www.youtube.com/watch?v=jJoXS8f3yGoI’m working on creating a PADU for localization through the graph and came across this talk Dominic gave at Summit 22. How did this pattern work out for Babylon? Lessons learned? Things to avoid? Things that worked really well? Would you still recommend this approach (namely, “misusing” context as the entity key)?