To help me think about nuancing the filtering, can you explain which stage of the whole process it is applied?

In T436918#12288073, @99of9 wrote:

To help me think about nuancing the filtering, can you explain which stage of the whole process it is applied?

The naive solution was doing this in the orchestrator while creating ZObject abstractions. Any time it saw a Z12, it just emptied it.

I am thinking about a more measured approach, where the backend receives a list of "in-bounds" languages and keeps labels corresponding to those languages around. This would be a little ugly and definitely break functional purity. Also open to other suggestions. Ultimately, I want to balance the occasional need to access these items against the need for the backend to be more parsimonious in how it represents information.

I don’t believe that we can even begin to think about a set of allowed languages.

If the object can be fetched by Z828, complete with Z12’s, there should be no need for its Z12s to be retained more generally. (Just to make sure, Z828 could be enabled for callbacks.)

If the object cannot be fetched by Z828, I don’t see how its Z12s can ever be dropped. This is most particularly true of objects fetched from Wikidata but also applies to ad-hoc structures. For Wikidata items, Z6820 allows for only selected languages to be fetched, and I believe this could be extended to lexemes, if there is any issue there.

In T436918#12303651, @cmassaro wrote:

In T436918#12288073, @99of9 wrote:

To help me think about nuancing the filtering, can you explain which stage of the whole process it is applied?

The naive solution was doing this in the orchestrator while creating ZObject abstractions. Any time it saw a Z12, it just emptied it.

I am thinking about a more measured approach, where the backend receives a list of "in-bounds" languages and keeps labels corresponding to those languages around. This would be a little ugly and definitely break functional purity. Also open to other suggestions. Ultimately, I want to balance the occasional need to access these items against the need for the backend to be more parsimonious in how it represents information.

I suggest

1. enabling callbacks for Z828 or an improved successor
2. reducing or eliminating Z12s that can be fetched by Z828 or its successor
3. retaining all other Z12s, notably those fetched from Wikidata (selectively, as best practice for community functions)
4. an improved successor for Z828 might allow the object to be specified as a Z96 and might allow a list of required languages to be provided, similar to Z6820.
5. Z828 or its successor should be able return all available multilingual content, fixing T410501