feat(discover): filter by original languages

[developerwill]

Description

Screenshot (if UI-related)

To-Dos

• Disclosed any use of AI (see our policy)
• Successful build pnpm build
• Translation keys pnpm i18n:extract
• Database migration (if required)

Issues Fixed or Closed

• Fixes Ability to filter based on original language which content can be requested/shown #1687

[0xSysR3ll]

I think this PR #1802 kind of supersedes yours. It uses blacklist feature though.

[developerwill]

It solves the same issue, just in a different way.

My approach uses the existing “Discover Language” setting values and lets the user choose where to apply the filter, while yours uses the blacklist logic to filter content globally.

In the end, both achieve the same result — I’m just missing the logic to prevent users from changing the original language when using discover/tv and discover/movies. I was already working on a follow-up PR for that.

Who decides which one goes in? I’m fine with either solution 😊

[0xSysR3ll]

We decide as a team whether this should be merged or not. If you're okay with that, we'll close this PR as a duplicate, and you can submit a follow-up PR afterwards ?

[developerwill]

We decide as a team whether this should be merged or not. If you're okay with that, we'll close this PR as a duplicate, and you can submit a follow-up PR afterwards ?

I've just submited the feature that it was missing actually. The "Original Language" filter field on discovery pages is disabled if "Discover Language" has any other value than an empty string.

Let me know if the team still wants me to close mine 🙏

[gauthier-th]

I think this PR #1802 kind of supersedes yours. It uses blacklist feature though.

IMHO I find it more clean to implement it through the TMDB API if it's supported.
We used the blacklist for the tags (with a quite heavy job to list all items) because we had no other solution, since TMDB didn't allow us any other way of doing so.

[developerwill]

I think this PR #1802 kind of supersedes yours. It uses blacklist feature though.

IMHO I find it more clean to implement it through the TMDB API if it's supported. We used the blacklist for the tags (with a quite heavy job to list all items) because we had no other solution, since TMDB didn't allow us any other way of doing so.

TMDB API does not support this. Someone responsible let me know if I should close this PR or not 😊

[gauthier-th]

TMDB API does not support this.

Sorry, didn't look at the implementation details.

Anyway, if we implement it, I find it better to apply a client-side filtering instead of having a daily/weekly job that blacklist items and may miss some entries. And unlike the blacklist tags jobs, we don't need to fetch all items one by one. WDYT @0xSysR3ll?

Also, we always avoided to implement client-side filtering on top of TMDB (except for the blacklist). Is this a path we want to take now? @fallenbagel

[0xSysR3ll]

TMDB API does not support this.

Sorry, didn't look at the implementation details.

Anyway, if we implement it, I find it better to apply a client-side filtering instead of having a daily/weekly job that blacklist items and may miss some entries. And unlike the blacklist tags jobs, we don't need to fetch all items one by one. WDYT @0xSysR3ll?

Also, we always avoided to implement client-side filtering on top of TMDB (except for the blacklist). Is this a path we want to take now? @fallenbagel

Well, after giving it some thought, I think client-side filtering is the way to go here - since we're already using it for hideAvailable and hideBlacklisted features. So this PR fits better with our existing approach.

So yeah, I'd go ahead with it.
Mine, tackles a different topic (blacklist scanning config), so I think both can definitely coexist.
But I agree, for anything user-facing, client-side filtering just feels like the right move.

[developerwill]

TMDB API does not support this.

Sorry, didn't look at the implementation details.
Anyway, if we implement it, I find it better to apply a client-side filtering instead of having a daily/weekly job that blacklist items and may miss some entries. And unlike the blacklist tags jobs, we don't need to fetch all items one by one. WDYT @0xSysR3ll?
Also, we always avoided to implement client-side filtering on top of TMDB (except for the blacklist). Is this a path we want to take now? @fallenbagel

Well, after giving it some thought, I think client-side filtering is the way to go here - since we're already using it for hideAvailable and hideBlacklisted features. So this PR fits better with our existing approach.

So yeah, I'd go ahead with it. Mine, tackles a different topic (blacklist scanning config), so I think both can definitely coexist. But I agree, for anything user-facing, client-side filtering just feels like the right move.

Ok, great, happy to help. Let me know if there’s anything else I should do. What are the next steps toward merging this PR?

[gauthier-th]

What are the next steps toward merging this PR?

Merging of non-fix PRs is frozen until the Seerr merger is completed and the first version is released.