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.
> you only get translated notes if you connect to a translated relay
I never thought about an always on translations mode, I think that click-to-translate (like every service does) is the way.
But this can easily be a client preference.
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
Well like I said, for the kinds of people who would connect to translation relays, the aggregate of click to translate would cause unnecessary traffic to the translation service for duplicate requests.
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.
