Oddbean

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

Don't publicly shame me! No, but I don't. I haven't really done any localization before, and I am still not sure why it should be done. Most websites seem to get auto translated pretty well by the browser, and when the copy is just button labels etc rather than copy, I'm not sure the juice is worth the squeeze except for businesses trying to aggressively capture an international market. TL;DR, correct me if I'm wrong, but i18n seems more hype driven than anything else.

🙈 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.

Don't worry about it, my shaming comment was a joke. I'm glad you brought it up. I mostly avoid the topic because I don't care deeply about it. I've traveled in other countries, and don't really mind being lost with the language, it's part of the experience. For software, I think it depends on what you're building. Centralized train ticket booking systems? Heck yeah, internationalize it! For social media (low stakes) on a protocol (alternative clients available, either localized or built by native speakers, e.g. rabbit), it seems much less important that the software be accessible. I do think l18n is in a hype cycle (regardless of the validity of the sentiment of wanting things to be accessible to non-english speakers), like TDD sometimes is. When certain aspects of software are hyped, they tend to displace other priorities at any cost. So for a practical example trade-off, I'd much rather add custom feeds to Coracle than Spanish language support, even though both are valuable.

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.

It’s better to translate the UI of a software when the feature design is stable. Otherwise every time you change the menu, you have to change 10 translations. English is the most widely used language. If we can’t even capture a large number of English users, we fail.

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.

I don't know if anything will come of it, but I want to do longform discussion that could replace delvingbitcoin I've done very little on it, it's 3rd in my priorities and I don't have much free time to begin with lol

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.

nostrmeet.me (wip) has had locale management built in from the start. (Only en until first public release … shortly) How do you track this? Should I have a specific structure to my locale URLs? Will I need to “register” my project with your repo?

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