@hodlbod @miljan @hzrd149 @Fabian Do you have any plans to localize your clients to non-English languages?
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.
Oh good! I'm glad I won't be the only one with an english-only nostr client lmao I do think i18n is very important, but when you're a one-man shop, you gotta prioritize aggressively.
Agreed. What are you building?
Yes but I’m not familiar with the translation management systems yet, I added Dutch manually through Xcode’s own translation thing
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.