Oddbean

The solution is quite obvious: let the user specifying his own language, use it in a tag, and let the user optionally filter/download only the selected content. Local bubbles can be a problem in the long term but are important for welcoming new users, especially if they are not able to speak a foreign language. Knowing that this option is standard, would make people more inclined to freely switch language when posting, truly enriching the linguistic and cultural presence in the network, and so promoting Nostro locally. Instead now most use only English, this proves something is not working right.

Has any client tried it? People have been talking about this language tag for more than a year now. I'd love to get some data to see if it actually works or if it's going to be more messy than a local relay. I don't think it will work because nothing that requires the writing client to change works in Nostr. But I am open to the idea.

I don't think any client has tried this. Such an experiment should be tested by a client with a large user base; or better with an interoperability orientation, by a pool of clients, so to bring in different types of users and points of view. In addition this is an addition that doesn't cause any incompatibility issue to the protocol, it can easily be deprecated by clients if it shows little utility. It's not even necessary to touch the NIPs, it's sufficient to take advantage of NIP-32 labels. In brief: 1) When logging in and creating the account, the user can choose one or more languages. 2) When browsing a feed the user can select a language to filter the notes. 3) When the user enters a thread from a filtered feed, the client shows all the notes by default, and if possible it translates replies to the original language used in the feed; in addition the user can force a language filter at thread level, too. 2) When posting a note the user can indicate what language it is using, by selecting one of the preselected ones; optionally the client can detect the used language and select it automatically, allowing the user correct the choice. A slightly more complex version, from a user interface perspective, may include not only the language but also the region; and this also is backward compatible using NIP-32 and simply *adding* an ISO-639-2 tag to the basic ISO-639-1 one (since relays cannot filter by prefix, right?).

I suppose that the tagging UI is quite trivial, you just need an single icon that iterates the languages in loop when pressed. And many users will have just one language, so they do not have to touch anything after the onboarding. Then using a service you cannot "upgrade" to the region labeling, and you have to manage the incorrect detection issue; finally a service have be manteined and be economically sostenibile. Better to offload this easy task to the users.

I am just trying to get a test out and the only way to test it is to have sufficient tags in all posts with all clients. One client doing this won't work because the user will miss a lot of posts that are not tagged. A service can test the idea ery quickly without modifying any client. If no one is willing to run the service, then I trully question if this feature is actually needed or if it is just a hollow feature that nobody actually cares.

Not really. I would do a service that creates 1985 tags with the language code using the same created_at the tagged post has. Then a client can just do a REQ for the latest 1985 tags and load all the event ids individually. A webpage could easily do that and I think it would work on Coracle right now, without any changes.

@dtonon @Vitor Pamplona If you need samples of NIP-32 label, there are already lot of tagged event in nfrelay.app including Language label. Feel free to test and use it. 🙂 nak req -k 1985 nfrelay.app , as examples.