C# – Separation of concerns between repository and service in DDD with complex entities

This probably seems as an example of opinion-based question, but I'm actually looking for rationale on how to decide correctly, I believe there is a correct solution that can be backed by solid arguments (that's why I chose SO and hope is really not only opinion based, but I can be wrong; if you'd feel so, please leave a note in a comment). I can't decode how far to go with SoC in DDD and whether is ok to have mostly empty domain objects.

We have .NET, DDD, mainly use EF as our ORM in repositories, our application lives in Azure. For complex queries, we use stored procedures that return multisets (because of Azure SQL) – so one query = one round trip to the server (is's worth it, the query is performed usually on > 10 separate tables, no joins, so it would require many round trips).

For simplicity, imagine domain object called NavigationItem, that have multiple titles (in different languages), items are stored in one table, localized titles are stored in another table, where foreign key is the item title contains culture id.

The navigation object might look like this:

public class NavigationItem
{
    public int FileRecordId { get; set; }

    public int? ParentId { get; set; }

...

    public Dictionary<int, string> Title { get; set; }
}

So the domain object, returned by repository, is constructed (in repository) this way:

// load list of navigation items
var reader = command.ExecuteReader();
navigation.Items = ((IObjectContextAdapter)_context).ObjectContext.Translate<NavigationItem>(reader).ToList();

// process localized titles
reader.NextResult();
var titles = ((IObjectContextAdapter)_context).ObjectContext.Translate<TitleInfo>(reader).ToList();

// associate titles, so the whole NavigationItem is constructed
foreach (var item in navigation.Items)
{
    item.Title = titles.Where(t => t.FileRecordId == item.FileRecordId).ToDictionary(key => key.CultureId, value => value.Title);
}

This is simple example, just to get the point – my question is, wouldn't it be better to return just list of navigation items (where I should omit the Title property) and list of titles and combine that in a service layer, when creating DTD object? Repository is responsible for persistence and retrieving persisted data, and I'm not sure, whether this is simply "too much". On the other hand, the requirement on repository might be just "give me whole entity with titles". Separation of concerns is naturally a good way, but I'm not sure if this is still concern of the repository.

Please take this just as a simple example, my question is more general – in this example, each domain object NavigationItem contains Title, so it feels it's OK to do this in repository. But when we have more complex etities, there is another problem – e.g., each File has common properties, like Name. Some files have image properties, same have also pdf document properties, some have localized titles… some don't. In this case, it seems much more "natural" to have one entity (common File), and return List, List, List, … from repository and combine it in the service. Or on the other hand, do all the translation in repository, but it would mean that domain object (aggregate root) File will contain entities like ImageInfo, TitleInfo, etc., which will be in most cases null.

What approach – and mainly, why – would you recommend?

EDIT: To be more specific – from DDD perspective, is it ok keep Entity partially empty and sometimes in repository just retrieve few properties (or sometimes all of them), or is better approach to separate such entity to smaller ones and return one entity that aggregates lists of all possible entities? I believe that there can be reasonable answer, typically "yes, partly initialized entity is ok", or "no, it's wrong and you should always use as granular entities as possible", etc.