I have a longer response that explains why parameterizing the project around language isn't so straightforward. Nor does it necessarily make sense because the thing that SE brings to the table is English expertise.
All of the work in polishing an epub is the chore of transcription and then nitty gritty details like correctly tagging things like roman numerals and embedded poems and following some sort of standardization guide.
The thing that Standard Ebooks does, aside from being decisive over its standards, is then require the epub to go through a review process by its creator who is a domain expert in the craft. This expert bottleneck is a big reason why SE book quality is so reliable. Accepting other languages drastically changes and perhaps even relaxes this bottleneck and changes the whole organization.
In another comment, I think you suggest that it might be time to try to persuade him to accept non-English books:
> Agreed, it's worth bringing up again on the mailing list; will do this week and post here a link to my message.
But it's not really up to persuasion. Because it takes more than an idea to expand the accepted languages. It requires at least one reliable expert in that language who can stand up a completely new set of tools and standards and then steward that project to fruition. And that's such a big undertaking that it's really a whole new project, not just yet another egg under SE's wings, but a whole new chicken coop.
Suggesting that Standard Ebooks move to support other languages is 0.0000001% of the work towards that goal. People do that all the time, then claim "okay, I'll fork the project", and then fizzle out.
Another example is that whole swathes of code in https://github.com/standardebooks/tools, SE's core workflow, become useless once you're targeting something other than English. By browsing their style guide and that repo, you'll realize that SE's value really is its focus on English. It's more of a suite of English tools than it is a epub editing kit, as the latter is the easy part.
I've been monkeying around open source long enough to know veeeery well that "Suggesting [...] is 0.0000001% of the work towards that goal" , and I've been culprit of that myself :) .
Still, I like SE a lot and might be interested in doing the work. So, I'll make my point to the ML (expanding on A. points I brought here, and B. contradictions that you and other commenters wrote, thanks), asking if folks are convinced by the vision, and asking for technical advice to build the incremental path. Then if there's agreement, maybe I, or someone else, will commit to it.
Fair enough. But SE's creator is simply going to recommend that you fork the project. Not that I speak for them, I've just been following the project long enough to see the interaction many times.
It's also the only avenue that makes sense. As I said in a sibling comment, I've been working on a Spanish-language version of SE and I have some good ideas of how the tool chain could be parameterized for multi-language support, but it also feels like a pointless cherry on top (and a complication of an already non-trivial workflow) to bring everything under one umbrella. And it would require a loss of control for SE's creator.
I recommend epub'ing a few book scans yourself in your preferred language and starting a project around that. You'll find other people who have at least started a fork themselves that you might be able to round up under one org. I personally have aimed for 10 ~finished books and a domain name that hosts my own style guide + tutorial to prove that I'm serious about it (to myself) before I publish my efforts. And you need as much to appeal to any would-be contributors.
I think the only plausible place to be in 5 years is for a couple major sister projects to reach maturation and then form a sort of ring of "Check out lettres-libérées.org for a similar project for French works."
All of the work in polishing an epub is the chore of transcription and then nitty gritty details like correctly tagging things like roman numerals and embedded poems and following some sort of standardization guide.
The thing that Standard Ebooks does, aside from being decisive over its standards, is then require the epub to go through a review process by its creator who is a domain expert in the craft. This expert bottleneck is a big reason why SE book quality is so reliable. Accepting other languages drastically changes and perhaps even relaxes this bottleneck and changes the whole organization.
In another comment, I think you suggest that it might be time to try to persuade him to accept non-English books:
> Agreed, it's worth bringing up again on the mailing list; will do this week and post here a link to my message.
But it's not really up to persuasion. Because it takes more than an idea to expand the accepted languages. It requires at least one reliable expert in that language who can stand up a completely new set of tools and standards and then steward that project to fruition. And that's such a big undertaking that it's really a whole new project, not just yet another egg under SE's wings, but a whole new chicken coop.
Suggesting that Standard Ebooks move to support other languages is 0.0000001% of the work towards that goal. People do that all the time, then claim "okay, I'll fork the project", and then fizzle out.
Another example is that whole swathes of code in https://github.com/standardebooks/tools, SE's core workflow, become useless once you're targeting something other than English. By browsing their style guide and that repo, you'll realize that SE's value really is its focus on English. It's more of a suite of English tools than it is a epub editing kit, as the latter is the easy part.