nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z Does Amethyst support translations without Play Services?

Reply to this note

Please Login to reply.

Discussion

support Amethyst Services? Play without translations nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z Does

Bruh, I wanna that (idk)

No. It does not.

(I use the FOSS version.)

No, we are still local for local translation libraries that are open source. Right now, only Google seems to offer minimally good ones.

* looking for

I am planning to offer a translation API on Nostr.land soon.

Would it be possible to integrate this for users that want higher-quality translations and/or want an option that doesn’t require Play services?

This is also meant to be seamless to set up, no API keys :)

The hard part is to identify the language of the post so that a button can be added to the UI only when translation is needed. Amethyst identifies the language on every post it downloads, both on content and in each natural language tag.

I will provide an API to the users of the translation service that does language detection for free

Right but does the app calls the API in each post? Like 1000s of requests when the app is loading?

We also do that in private DMs. Do your users want you to see the encrypted content?

Yes and it can handle those requests just fine. Also, HTTP/2 is a thing, you know.

You can simply allow the user to choose if they want to send private DMs or not.

I am not sure... People already complain about data usage right now, imagine when each post gets 2 new payloads (up and down). I will need to do some tests.

Can you talk to the other providers (nostr.wine, etc) to make a single API spec for everyone?

There is already a spec it’s called ghe LibreTranslate API. The only difference with mine would be that it uses Nostr HTTP auth instead of API keys

Sure, that's a new spec

Only replaces the Authorization header

Still, if everyone in nostr does that, we can have the user choose the provider without having to implement custom variations for each one.

Yeah I’ll publish a spec

This would be a great feature if eventually supported