Yeah, in package.json
you can tell Angular to build en
, fr
, de
and it’ll make them all in parallel, with (customizable) baseHref
settings so they can all be served from the same httpd. In an ordinary Angular CLI setup, you end up with dist/en
, dist/fr
, dist/de
, and so forth.
That part is super-smooth, but Capacitor (sort of understandably, I guess) assumes there is a 1-to-1 mapping from a top-level Ionic project to an Android or iOS project, which it then washes its hands of and hands control off to Android Studio or XCode. Since the actual responsibility for building anything past that point lies outside of Capacitor, it might be a tough sell to ask Capacitor to do anything beyond potentially making android-en
, android-fr
, android-de
, and frankly the utility of that feels rather minimal, especially considering how much bloat it induces.
I think it can be safely assumed that anything outside of the JavaScript payload (i.e. plugins and whatnot) is consistent across all locales, for whatever that’s worth. Android Studio works under assumptions that localization is done with Android string resources, which again is a perfectly understandable design decision, so I would be surprised to find anything on that end that could help me (also factoring in that we need XCode to play in this same sandbox if trying to go that way).