04:28:44 Just have to run “pnpm install” to get the dependencies - it will be installed with the rest of the packages 05:08:13 can check if it installed after by running “pnpm lefthook check-install” 08:59:06 note that when using pnpm install --prod - it will install only packages required for building, developer tools & packages will be skipped 09:08:25 btw not localized yet > <@redsh4de:matrix.org> added @basses:matrix.org, looks pretty good 09:08:48 Ah yeah didnt add translation keys for arabic/cn 09:08:49 sec 09:10:26 from a grep search every string should be localization ready - but some translation json files may not have the translations added, so it falls back to the english json for that specific string 09:10:50 ok 10:52:08 Updated texts 11:29:03 plowsof: wen weblate 11:39:44 no updates yet sorry 15:33:08 plowsof: SARR 15:33:30 https://docs.astro.build/en/guides/middleware/ 15:33:36 i am about to DESTROY so much boilerplate with this 15:35:51 will let me define per-locale functions once in a global context, then just let pages use the global context functions 15:35:51 instead of doing shit like const locale = getLocale(Astro.url) for every page or component that needs access to locale info 15:35:51 can just do const { locale, dir, t } = Astro.locals and it all will be the same function instead of creating new instances every time 15:38:10 oh and can also turn the existing i18n utils into constructor functions and re-export them via the Astro.locals with the locale info already embedded 15:38:10 so calls like localizeHref(locale, url) can just turn into localizeHref(url) 15:38:30 the user won't have to worry about wiring in functions or locale parameters it will all happen in the background 15:38:31 peak 21:24:37 <321bob321> @basses:matrix.org: Lost in the ether - eum 21:38:35 redsh4de: how would middleware work together with a static website? 21:44:28 im supporting selsta question 21:44:41 afaik middleware is when using Astro in SSR mode 21:44:53 yes it's not something we can use 21:47:13 it is something we can use 21:47:35 astro's middleware in the SSR context simply injects variables in the middle of rendering the page 21:47:51 how? we don't want to run node.js on the derver 21:47:54 server 21:48:08 i see your point but it was assumed obvious by a lot that SSR was out because js is also excluded from server 21:48:27 yeah this 21:48:30 nvm, im confusing SSR with SSG 21:48:38 it works the same on SSG 21:49:10 press x for doubt (with all due respect to you and your work) 21:49:20 i tested this thouroughly and built this 21:49:55 ill find something from the docs to back this up 21:50:25 but its basically the same reason how we can have open-graph images generated at build time 21:51:08 in SSG, the middleware runs at build time as well only - the static pages are generated with the middleware running in the middle of the build process, because the build process is the only place that has JavaScript execution 21:52:07 if it works that it only runs on build time it's fine, I just don't want to increase our attack vector with a node.js server 21:52:31 Yeah no that was a non-starter from the start 21:53:34 built output is fully static & my current github actions explicitly checks for lack of presence of script usage 21:53:45 (in the build output) 21:55:11 https://docs.astro.build/en/guides/middleware/ 21:55:48 "...rendering occurs at build time for all prerendered pages" 21:57:54 also mentioned in the roadmap issue for Astro middleware, at the bottom: https://github.com/withastro/roadmap/issues/531 22:00:49 I don't know enough about Astro :/ 22:01:13 all good i only figured out that this can be used today as well 22:01:41 there had to be some way to not have to inject localization boilerplate function into every page and component that might need it 22:02:54 got rid of 250+ loc with this change across the codebase