I think it would be better to focus on translation rather than filtering when it comes to language
Today we talked about search note15djknj3kh6szcj82pp6sm98vk3pw40fg8ajsx8mrpfg3zadyeqhqfmsl2n, what about language filtering (that can be a search params, too)? Nostr now is english centric, but with the progressive expansion a language filter will help newcomers to discover new content and raise the signal-noise ratio.
I found this PR about the matter https://github.com/nostr-protocol/nips/pull/182 by #[0] and I think the tag is the right approach, because can be used on other kind types, if needed.
Ideas?
Discussion
Translation is a completely different order of complexity, and it is a client job, I doubt can have any role in the protocol. However knowing the source lang helps the translation process, that otherwise have to detect it.
Search isn't part of the protocol either.
Anyway, I think client side translation makes sense, but it would cause increased network traffic. To obtain the same effect with less work, translation relays make the most sense. The translation itself is unsigned of course, but it can be extra data that comes with a note. Protocol side, marking notes with a language field could make all of this come together pretty nicely.
what if people who speak a language other than english don't want garbage translations dominating their feed?
I think only english speakers would prefer what you are suggesting.
Well first of all, you only get translated notes if you connect to a translated relay
Second, relays that reject other languages are possible
Third, "Only English speakers would prefer what you are suggesting" is very ironic. I'm much more used to Americans complaining about Spanish.
first, relays wouldn't do translation clients would
second, yes and the language query parameter would help with that
third, I agree americans complain about spanish which is why they would prefer to just have it translated for them. but don't totally understand your point here
That clients would translate rather than relays is not a technical limitation and is rather entirely your assertion. I don't recommend it because memorization really does help with performance.
And my point on the third was that your assertion that only English speakers would prefer translated notes rather than language filtered notes was merely that it seemed to me to be a strange assertion to make.
That clients would translate rather than relays is not a technical limitation and is rather entirely your assertion. I don't recommend it because memorization really does help with performance.
And my point on the third was that your assertion that only English speakers would prefer translated notes rather than language filtered notes was merely that it seemed to me to be a strange assertion to make.
its less an assertion about english speakers and more an assertion about people who speak a dominant language.
if you speak a dominant language (and have a mono lingual culture) you are likely more ok with not being able to filter by language (and solely rely on translation)
Why? Your observation is not something I've seen. I've rather seen a dominant language get angry and yell at other language speakers to learn the dominant language and shoo away translation efforts.
sure this is definitely a thing, I agree. but not what i'm talking about.
rn on nostr most conversation is in english. who do you think would prioritize language query filters more, those speaking english or those speaking something else?
I’ve been playing around with creating a nostr client focus on Latin American users and would welcome the language filter. Any way to increase the signal to noise ratio for users is a welcomed improvements in my eyes. 🤙
You really don't have to do this at the client level. I mean sure, a client with relay defaults that reject other languages or something, but you don't have to use the users processing power and battery life to do sorting.
In any case at least we all agree on a language parameter for both of our use cases and the protocol level is all we really have to agree on.
having a languages query parameter would mean clients can query for only one language of notes and don't need any processing power for sorting notes by language....
yes at least it seems like we all agree on that point which is promising!
LOVE this tag.l and potential to use it as query param. I’d like to browse English, German, and Spanish nostr separately as I am less than fluent and have a hard time switching back and forth rapidly.
You still have to do
if lang == english
return note
else
#implicitely drop the note
But I guess the argument is supposed to be that this check for every single note relayed to the user isn't significant enough to have noticeable performance issues for the user....
no the argument is that every note relayed to the user would already have lang === english. bc the client uses '["#l","en"]' query filter which means relays only send back posts with language tag of english.
ugh filter would actually be '{"#l":["en"]}' or something
You're still performing a check.
yes but its less checks bc client receives less notes
Oh so we're still talking about relay filtering then and not actually client side filtering. Yeah alright memorization can help there then.
i'm talking about the same query filters that search for hashtag or event thread. relays would still hold all languages (unless they want to be a specialized relay). standard query filters from clients would query the posts the user wants.
I think it makes the most economic sense for there to be specialized relays specifically language specific relays, but there's nothing keeping both from existing (except that maybe nonspecialized relays might go broke or switch to being paid services but I think we're moving towards paid relays or friend hosted relays either way)
yes, hard to know what the future relay landscape will look like. I do agree that languages specific relays will be a thing. I also agree that people would likely want translation relays and such.
all i'm saying is language query filter is first step and good short term solution to jump start language specific feeds.