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.