@renestalder, I have roughly sketched it out as discussed. Thanks for your help!!!

@ssandino Thanks. Gonna take a look at it.

@mkue I quickly wanted to prototype this, then noticed, we have some kind of custom setup with nextjs, as it doesn't follow the usual architecture of using pages/ folders. I also didn't find any note about this in our README.

Where do I begin to find out how this is configured, so I can adapt to that setup? I thought the next.config.js would give me some hint, but it just “magically” seems to work like it does.

It was answered by @ssandino via Slack. They have a "router switcher" hidden in the top section of the NextJS documentation, which I never noticed. My Google search always brought me to the documentation involving the other router.

@ssandino Is there any need for «region» translated journal entries? Or are languages sufficient enough?

Languages are sufficient – don't see a need to show journal entries based on region of a user.

I have now Storyblok connected on the branch im working on, including the setup for using the visual editor.

I'm now about to integrate the journal story type I've setup in Storyblok.

Another status update and why the ETA is difficult:

• While the connection to Storyblok works, to make the CMS useful, a simple content preview is necessary, to be able to check on whether content is rendererd correctly.
• As Next.js 14 uses the relatively new and experimental Server Side Components part of React, it assumes to render all content server-side per default.
• It's possible to define client-side only rendered components. For a preview, we need some kind of client-side rendering, so the unpublished content can be retrieved on demand.
• Traditionally, and also previously with Next.js 14, frameworks allow to use the same components for server-side rendering and client-side rendering, allowing to retrieve data on the client too and render it in the same components that previously were rendered on the server.
• As Next.js 14 isn't doing this the way it used to be (for the good and the worse), I'm currently trying to figure out how I can achieve this with dynamic routes/split routes.
• The alternative is to do everything twice; having every component as a server-side one and a client-side one.

It's quite a hazzle, as Next.js 14 is new enough for official documentations not covering it especially. All documentations cover Next.js 13, where this is somewhat «easy» to do as it follows well common known paradigms.

I keep you posted.

@ssandino @mkue Please somebody else with NextJS experience take that over. My journey with Next so far is a rather frustrating one and this burns completely through my spare time trying to fill the gaps that are missing from the react server components feature-list and NextJS gap-filling solutions.

Also, I get the impression, all tools that help me work in sandboxed environments, in particular Docker and Storybook, are not appreciated by anybody else and getting removed from the repository (Docker being removed a while ago). Which makes working with the code, at least for me, so much more time consuming.

I'll take it over.

Also, I get the impression, all tools that help me work in sandboxed environments, in particular Docker and Storybook, are not appreciated by anybody else and getting removed from the repository (Docker being removed a while ago). Which makes working with the code, at least for me, so much more time consuming.

Well, someone needs to maintain these tools/environments, and with very few people actively working on this repository, and nobody apart from myself actually committed to investing time into improving the dev experience, I have no motivation to keep everything alive for people who just spend a couple of hours per year working on this codebase. You are welcome to bring those tools back if you also commit to maintaining them.