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