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?).
dtonon / daniele
npub100…8vwqk
2024-09-09 13:09:59
in reply to nevent1q…cwks
Author Public Key
npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqkPublished at
2024-09-09 13:09:59Event JSON
{
"id": "fe76f6263549f45a1acd6c273e2cf0db7be2ab27fc8ccaa85b55bb9eceacdaa0",
"pubkey": "7bdef7be22dd8e59f4600e044aa53a1cf975a9dc7d27df5833bc77db784a5805",
"created_at": 1725880199,
"kind": 1,
"tags": [
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
],
[
"p",
"aa9047325603dacd4f8142093567973566de3b1e20a89557b728c3be4c6a844b"
],
[
"p",
"619af6a60b3fe4c733aaca061c522cc9c7cf1d87ef4c908facc5ed936d3bdf23"
],
[
"e",
"d6a53ecae0d1406f5e34e7182805953afe624df46d2f74ba54def5597d8919d2",
"wss://chorus.mikedilger.com:444/",
"root"
],
[
"e",
"a46ae4dd766a42ab7635563d6ab3109cb8b7059f17977f22819972007cc6ee9a",
"wss://nostr.wine/",
"reply"
]
],
"content": "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.\nIn 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.\n\nIn brief:\n\n1) When logging in and creating the account, the user can choose one or more languages.\n2) When browsing a feed the user can select a language to filter the notes.\n3) 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.\n2) 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.\n\nA 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?).",
"sig": "995b872592d83bf76dbc41b98976da1cfa5fb69a8e484f3c11a116a5adcc29309c1c70bcbe9862dd5aa2c1f18a2ed6a07cda399473f5a2c646d70786817eb1a4"
}