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.
Discussion
what exactly do you mean by translation relays? how would that infrastructure work? how would clients query that relay without a language query parameter?
I actually suggested a language parameter to be added to notes though.
But how it would work, is that if you transmit a note to a translating relay, it would translate it and relay to clients requesting certain languages on that relay. It would store the translation for the same duration of time that it stores the note. "Memoization"
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).
Yes the translation would be a separate field in the event. It would have to be. The translation wouldn't be signed by the user.
But yes, add a language parameter!
I think my main complaint was focusing on using the language parameter for language filtering rather than translation. Seemed like a focus on enforcing a language barrier rather than working to remove it.