I wonder how well Asahi Linux performs, especially around battery usage. I used to dual boot Ubuntu years ago when MacBooks were using Intel chips and it did alright.
I’m on Damus Purple and some Thai notes translate to English automatically for me. Not all of them, though, which might just be a language detection issue, but I’m not sure. It also goes off of your list of preferred languages in iOS settings. If Thai is one of your preferred languages, Damus won’t attempt to translate Thai notes.
The logo at the top is part of the Ukrainian coat of arms, which is typically shown as a blue shield and golden trident. The man in the middle is a Cossack.
https://en.wikipedia.org/wiki/Cossacks
I’m hoping native signer app solutions will allow us to bypass these limitations, and also improve the subpar experience that we have with NIP-07 login extensions. It’s one of the things to do on my aspirational backlog.
Not at the moment because Damus app copy is not translated to Thai. If you’re interested in volunteering, we’re always looking for more people to join the translation team. Once Damus app strings are translated to Thai and the user chooses Thai as their preferred language, English notes should translate to Thai as well.
It was a bug in the implementation of Primal iOS not respecting the old spec, and also an issue of Damus not catching up to the new (not so new anymore) NIP-10 spec.
My fix on Primal and what needs to be fixed on Damus are two different things.
You can support reading old threads while support writing new replies using the new recommended part of the NIP-10 spec.
I looked briefly into implementing it in Damus a while back but it seemed like it was a non-trivial refactor requiring a lot of changes so I ended up not doing it.
Keeping translations up to date is a lot of work, even for a single language. The translations that exist so far for the tracked clients are mostly thanks to a wonderful group of volunteer translators. They aren't really getting compensated due to missing value-for-value mechanisms and processes. By creating this tracker, I'm hoping it brings awareness of how inaccessible some of our clients are to the non-English speaking user base and motivates more interest in non-developers to contribute to translations.
I've just pushed updates to the tracker per your feedback.
FYI I noticed that Nos localizes only 1 of the 4 xcstrings files. I had set it up to localize all four when I contributed a while back, but that seems to have been reverted to localize only one:
Configured to localize only one xcstrings file:
https://github.com/planetary-social/nos/commit/1a7894e1ec5869bcec04916718803a86ca0f78e3
All 4 xcstrings files:
https://github.com/planetary-social/nos/tree/07a9dd5ede5182ca45af7e83cdaf6ce4b3503ff5/Nos/Assets/Localization
I created a Nostr localization tracker on GitHub. It tracks how well localized Nostr clients are in different languages, and which ones support automatic content translations. Contributions are welcome. Let's globalize Nostr and make it truly accessible for everyone.
Disclaimer: it is by no means exhaustive in the list of clients or languages, and it does not keep track of percentage of translated strings or quality of translations.
https://github.com/tyiu/nostr-localization-tracker
🙈 Apologies, that wasn’t my intent to publicly shame anybody if it came across that way. I think Coracle is already amazing as it is.
I do truly care about global accessibility and empathize with people who do not speak English well. I come from a family of English as a Second Language speakers, and I speak multiple languages of varying fluency, so it’s always top of mind for me. When I travel to non-English speaking countries, I have difficulty navigating with my inability to read or communicate in their language and I end up needing to rely on translation apps and that really sucks. That’s how non-English speakers feel when they interact with software that doesn’t cater to their language in a first class way.
I forgot that browsers have auto-translation ability, so you have a point there that it’s different from mobile apps, though my experience is sometimes hit or miss. At the end of the day, without dedicated translations, non-English users will always feel like a second class citizen. I don’t think it’s just hype-driven. It’s about giving your customers the best experience, regardless of their language or culture.
Anyway, you’re not obligated to do anything. I’m just documenting the state of the world so that: 1) non-English speakers can easily figure out which clients do give them a first-class experience, and 2) give translators an idea of what localization gaps there are so that they might feel motivated to contribute to help their own community.
The new hotness is the String Catalog .xcstrings format that the new Xcode version supports, rather than the old .strings and .stringsdict formats. Crowdin seems to be a reasonable translation management system option that support the new file format. Nos, Amethyst, and Snort use Crowdin and I want to move Damus to it. They support open source projects.
Those are fair tradeoffs and I think they’re reasonable. My view is that it’s most easiest to i18n at the start of the project. If not, it gets progressively harder. But once i18n is done, it’s pretty straightforward to follow the established patterns for dealing with user-facing strings, and localization mostly comes for cheap afterward (to the developer at least - they just need to maintain the translation pipeline and ensure enough context is provided for each string). At that point, you just need to rely on the community to translate strings, if they care about wanting the client to be in their language.
Sure, but also internationalizing your UI so that localization can happen at anytime is even better. We can capture English speaking users and still cater to non-English speakers. I don’t think any of this is mutually exclusive.
It’s pretty manual. If it’s a web app, I check if there’s a dedicated language setting in the app, and if not, I try setting my browser language settings to prefer Spanish to see if that works. Then I check the code repository to see if there’s locale files and if there’s any mention of using a translation management system.
There’s no expectation of any structure, and you may optionally add an entry for your client to the tracker.
I’m hoping we can utilize translation progress status assets so that it is less manual. It seems like Crowdin might support it if the project owner opts into it.
If I’m understanding your link drop correctly, I appreciate the sentiment, but my two thoughts on this are:
1. Countries are not languages, and vice-versa. There isn’t a 1:1 mapping. There’s a whole bunch of negative cultural and political identity nuances when people attempt to assign a flag to a language. For example, English is spoken far and wide, not only in England. Spanish is spoken in the Americas, not only in Spain.
2. There’s already emojis for country flags if somebody needs to add them to text!
No, they shouldn’t have flags. It should just be at a minimum the name of the language itself as written natively. Here’s an example from the iPhone language selector. https://i.nostr.build/zd8Od.jpg
My main concern would be lack of strong consistency on an application type where consistency is expected when collaborating with multiple editors. If you’re doing accounting, you don’t want your numbers to be off because an event could not be fetched from a relay. But cool concept and might still work under certain circumstances.
Nostrica, Bitcoin Miami, and Nostrville last year were eye-opening experiences for me. I had no idea meeting Internet friends would be that much fun. I regretted not going to Nostrasia. But I’ll be at Nostriga and hope to meet you and others there!
Comingle iOS x Nostr SDK for Apple Platforms
Got the first integration working with reading real NIP-52 calendar events. Nothing fancy to look at, yet. The UI needs a lot of work. Just wanted to show off how easy it was to get something working with the SDK!
https://v.nostr.build/6Gx9z.mp4
Most devices require a password or passcode upon first startup so that would be fine. But it would be an issue if you had already logged in once, which they could force fingerprint or facial recognition authentication.
Nostr is permissionless, and with the right tools, everything can be opt in. It’s about giving the user as much choice as possible. The hostility is uncalled for. If people want to use your bot, they can. If they don’t, then don’t. It’s very straightforward. Keep doing what you’re doing.
Most devices require a password or passcode upon first startup so that would be fine. But it would be an issue if you had already logged in once, which they could force fingerprint or facial recognition authentication.
Hey, @Fabian Do you see a possibility where Nostur could migrate to use Nostr SDK for Apple Platforms? It’s a pure Swift library. We’d like to rally the Nostr Apple platform developer community to use and contribute back so that there’s consistency and reduced interoperability issues across Apple platform clients and build features where everybody gets it for free. I know you’ve refactored a bit of logic out from Nostur into a separate library, though.
https://github.com/nostr-sdk/nostr-sdk-ios
That would be great if it’s possible! It’s hard to maintain with just ~2 developers on it part time, but with more help, I think it’ll grow into an even nicer library.
Oddbean new post about login | logout
Notes by tyiu | export