well in my mind, relays with the same/similar policies will be managed together in the same (named) grouping.
no way users can manage each relay policy individually, seems way too granular.
long term this is kinda how I envision the language param tag being used. based on the new relay list nip you could add criteria that automatically only posts to certain relays by the language that is used.
I guess i think its higher signal if you can filter which language you see from your follows (especially if you normally skip those weird languages)
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!
it doesn't prevent it from your follows. it does prevent it from the twitter general content it seems. like if you sign up for new account and have no follows you will only see your own language.
you've never used the google search feature that allows filtering by language?
as someone who has had to choose between paycheck and mission I might be super cynical at this point. my views are what they are.
just to be clear, i don't think ex twitter employees are bad people or 'compromised'. but they def put stability over values. as did I at one point.
I guess I assumed twitter has a lot of fancy algorithms for their curated content
ok yes in this scenario I think it is valuable. I guess I don't like it if its auto translated, but am not against it. and if users want it I def think it should be implemented
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 mean we all agree twitter is broken right? not functionally, but incentives are broken. and I can't say i trust the people that built those broken incentives.
obviously I am generalizing and there are exceptions. but would trust someone who quit more than someone elon fired.
oof i don't know how I feel about a new kind to group notes.
I was saying if you write a spanish note, you only broadcast to your spanish relays. english note, only broadcast to english relays. dont need to translate across notes, but def could be a nice feature
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)
hmm not sure if I like having users compose multiple notes for translation, but definitely could work
i was imagining translation to be done by client when displaying note. seems simplest.
and the translation would be in a separate field on the event then?
i'm not against a translation model like this. I just think a language query param should be first step (and seems to be needed in your suggested method as well).
what exactly do you mean by translation relays? how would that infrastructure work? how would clients query that relay without a language query parameter?
of course they will continue code. I just don't think their values align with nostr.
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