I answered a Directus question in August 2025 after running into a problem retrieving translated article content. It looked like a query problem. The important discovery was that reading an article did not automatically establish access to the related translation records.
The lesson from that debugging session was simple: check the relationship and the permissions independently. A more elaborate request will not compensate for a related collection the requesting identity cannot read.
Isolate the smallest useful request
Before combining nested fields and language filters, try to retrieve the translation record directly using the same identity as the failing request. In the example I was working with, the relevant collection was articles_translations.
That gives you a smaller question to answer. Does the record exist? Is it linked to the expected article? Does its language value match the one being requested? Can this identity read the collection and the requested fields?
If the direct request fails, there is little value in adding more complexity to the parent article query. Resolve the narrower problem first.
Make the nested request explicit
Once the underlying access works, ask for the fields you need and apply the language filter to the translations relationship. The following request illustrates that shape. Its collection and field names are examples, not a universal Directus schema.
curl --get 'https://your-directus.example/items/articles' \
--header "Authorization: Bearer $DIRECTUS_TOKEN" \
--data-urlencode 'fields=id,translations.title,translations.content' \
--data-urlencode 'filter[id][_eq]=YOUR_ARTICLE_ID' \
--data-urlencode 'deep[translations][_filter][languages_code][_eq]=ar-SA'Here, the top-level filter selects an article, while the deep filter constrains the returned translations. The locale must match the value stored by your application. Do not assume that ar and ar-SA are interchangeable identifiers in the data.
Directus documents field selection, filters, and nested query parameters in its query parameter guide. Check that guide alongside your actual schema when adapting the request.
Fix the permission that is missing
In my original answer, querying the translation collection directly helped expose what was wrong. The lasting lesson is not to grant broad access until the response appears. It is to establish exactly which read permission is required by the operation.
Keep the identity consistent during the comparison. A successful administrator request does not explain why a request made by the application fails. Test the operation in the context that is actually producing the error.
Keep the diagnosis separate from the final query
There are two useful artefacts at the end of this exercise: a small request that demonstrates access to the translation, and the application request that returns the desired article content.
Keeping both makes the reasoning easier to revisit. If the behaviour changes later, you can determine whether the failure is in access, the relationship, or the shape of the request without starting the investigation from scratch.