Implement Locale Setting in Settings > Organization

Fixed in https://github.com/folio-org/ui-organization/commit/78ab8be3198db51c7f70e2192349e5d1571c64cc

I've frequently explained my viewpoint (including on your linked issue): stripes-core is a webapp that implements an app-running ecosystem. It's the OS-like thing from Filip's prototypes. I do not see the utility in factoring out the configuration for system-wide things that affect all apps anyway into some external module.

It was probably premature for loader to be a module, but it is self-contained enough and plausibly reusable.

Connect is a module because there is solid utility in making it convenient for React/Redux applications beyond Folio to talk to Folio services (eg. a fancy OPAC or something). And we don't really have to go too far out of our way to have that piece reusable.

Having apps directly importing files from stripes-core seemed a little cumbersome, makes documentation less straightforward/transparent, and might inhibit some types of test harness / running an app standalone. And so stripes-components (and stripes-logger and perhaps some other future stripes-utils) make sense as well-defined, purpose-constrained libraries that module authors consume.

App authors do not directly import the notification subsystem, the locale settings, the alt-tab-like app-switcher interface thingy, the future way we'll organise keyboard shortcuts, etc. These are tied into the core webapp and may have some state there, apps consume them via props that core passes. That is the current mechanism for inter-module coupling---there isn't any, if it's coupled, it's simply part of the core monolith. By keeping coupling between modules constrained to the shared set of backend services and the API surface of stripes-core we've been able to forestall a bunch of architecture and generalisation. And I'd like to continue putting that off until after MVP if we can at all help it. I think it has been really helpful as a constraint so far in getting us a system where apps can be readily developed by disparate teams.

Creating part-of-core X as a standalone module means, in addition to creating the how-apps-consume-X API we also need to devise the how-anything-embeds-the-bit-that-provides-X-to-apps API. Since we already have more than enough to do, let's do that later? I do think it's plausible we may eventually pull a bunch of pieces out of stripes-core so that one might build an alternative for it that will be compatible with the same apps, but I don't think we need to do that up front.

How does it contribute to our goals to factor the UI for locale selection out into a separate module? Do you forsee reuse? I just don't understand why this needs to live on its own?

Here we run once more into the long-running problem of what stripes-core actually is – see STRIPES-38. I have always believed that it is (follow me closely here) – the core of Stripes: the small, irreducible core of completely indispensible functionality that no Stripes-based application could work without. In Jason's vision, however, it's a big monolithic application, designed by Filip – one that he has often likened to an operating system or windowing system.

The concept of what locale is in effect obviously belongs in stripes-core, whichever of these interpretations one subscribes to. However, the UI elements used to choose a locale from among those present absolutely do not belong in stripes-core in my more minimal sense – among other reasons, because this process is dependent on back-end services.

All of this highlights why we should long ago have separated our so-called "Stripes core" code out into a smaller true stripes-core and a stripes-app; all Stripes-based UIs would be build on the former, but only some would be designed to work under the former.

Jeez, is it even theoretically possible to make a statement about Stripes that Jason won't contradict the moment he sees it? From now on, I am going to say the opposite of what I think, then wait for him to contradict it, then agree.

I think we surely do want it right in stripes-core! The locale is not an app. It's a property of the platform the apps run on. That's stripes-core.

Also, there is a general need for (yes, in stripes-core) some more infrastructure around settings. In addition to some settings inherent to the platform and visible to the apps we might consider something thicker than stripes-connect to pass into app settings components to handle settings persistence so we can, for example, have tenant (user group?) defaults that are overridden on a per-user basis.

eg. so an user can select a non-default locale