The key portion of the entry-level localization concept is this:
How does localization fit into this picture? Instead of localizing text fields, as in the case of field-level localization, one localizes the reference field. This way, the article aggregate refers to one Article - Local entry in US-English and another in DE-German
It’s true the text is a bit confusing, but the idea is that only the reference field to local articles on the global article content type is localized and none of the fields on the local article content type are localized. Here’s a diagram which perhaps explains it better than words:
Regarding the API response, in order to find the desired local article you need to query for the global article and specify the desired locale to filter for the specific localized version of the local article you want.
For example, if I query for an entry of the global article content type with a certain name and specify that I want the English version, like so:
client.getEntries({
"content_type": "globalArticle",
"fields.name": "global article title",
"locale": "en"
})
Then the response includes only the English local article:
{
sys: {
...
locale: 'en'
},
fields: {
name: 'global article title',
localArticle: {
sys: {
...
locale: 'en'
},
fields: {
title: 'en local article title',
intro: 'en local article intro',
body: {
...
nodeType: 'text',
value: 'en local article body',
marks: [],
data: {}
...
Similarly, if you query for the German version like so:
client.getEntries({
"content_type": "globalArticle",
"fields.name": "global article title",
"locale": "de-DE"
})
Then the response only includes the German local article:
{
sys: {
...
locale: 'de-DE'
},
fields: {
name: 'global article title',
localArticle: {
sys: {
...
locale: 'de-DE'
},
fields: {
title: 'de-DE local article title',
intro: 'de-DE local article intro',
body: {
...
nodeType: 'text',
value: 'de-DE local article body',
marks: [],
data: {}
...
I hope this helps explain the concept better.