Hi @craftzdog,
Well, we can always break-down “big unknowns” into “small achievables”, for example:
- Add
i18nlinter to scan the codebase for texts locations. - Implement
i18nlibrary and variables usage instead of texts in couple of iterations. You can view it as adding another coding practice or structure as you have done with plugins architecture. - Get help translating Inkdrop from the community via Weblate or another solution, same as you have done with Discourse for forums.
- As for the RTL support it can be divided into 2:
- Detection of RTL text inside the editor/view and applying CSS rules, if you are using a 3rd-party text-editor this option 99% already supported by the editor itself.
- Fully supported RTL UI — this is defiantly an overkill not worth exploring.
I understand the assumption for RTL being a small market, this might be true if we dismiss the Arabic world of developers, power users, note takers, etc…
Also, RTLCSS is a library worth mentioning while discussing RTL-LTR CSS support, basically it’s a parser that takes a style.css file and generates style-rtl.css file that compliments the original file.
From a business expansion point of view, UI i18n support for only left to right languages for starters as another channel of natural growth, like you have done with plugins and themes.
Yet, I can’t argue with developer’s logic for not wanting to refactor his codebase or add more people to make his code structured and clean. 
