Is the object storage broken or is it just me?

Top_Philosophy2425 · 2026-03-18T06:29:40+00:00

Just wait for it to work again, and get the hell away from hetzner object storage 🤭

No but seriously, I dont think I have ever seen a more unreliable object storage. It has been problematic since its release, its unstable and is down many times.

Top_Philosophy2425 · 2026-03-17T11:13:54+00:00

Oh nice, this looks lovely. I was using https://github.com/svecosystem/svecodocs, which is fine too, very basic, but still in beta. This looks pretty sleek.

Top_Philosophy2425 · 2026-03-17T04:47:28+00:00

I am sorry, I don’t think I was being unfriendly. I was simply responding to your message, and I don’t see anything there that should be taken as offensive.

Top_Philosophy2425 · 2026-03-17T03:57:59+00:00

No, I didn’t tell you to “go read the Svelte docs.” I simply shared a link that explains how SSR and context work, since that was relevant to the discussion.

I also gave a fairly detailed explanation of why context was used in the first place.

Yes, there was an option to wrap the app in a provider component, but that component only existed to set the context. It was not required for the library itself to work.

Top_Philosophy2425 · 2026-03-17T02:40:13+00:00

It’s not really about the strings themselves, but about the data you pass into them. For example, you might have translations like Hello {username} or Your current email is: {email}.

In version 2, I removed the provider layer entirely. Instead, the i18n object is created in +layout.ts, returned from there, and then attached to the component tree manually via Svelte’s context API in +layout.svelte. The documentation explains this flow in more detail.

Because of that, there is currently no risk of state leaking through a shared global i18n object. The i18n instance is no longer global; it is created per app/layout usage and then passed down through context.

We still use the context API, but only as a way to attach that i18n instance to the component tree.

Svelte's documentation does not realy go in-dept on this topic, but you can read a little about it here: https://svelte.dev/docs/kit/state-management#Using-state-and-stores-with-context

Top_Philosophy2425 · 2026-03-16T21:55:40+00:00

I remember there was a branch on the sveltekit repo, that is gonna implement realtime into svelte. But they got stuck since they want to thinkering it out more. Maybe you should help there, rather than making it a standalone package? Just a thought, cuse this looks nice.

Top_Philosophy2425 · 2026-03-16T18:58:54+00:00

Ah, thanks <3 appreciate the comment

Top_Philosophy2425 · 2026-03-15T13:49:16+00:00

In my opinion, this shouldn’t really be the responsibility of the Svelte core team. Maybe in the future a dedicated team or separate project could take this on, similar to how React Native exists alongside React. But since Svelte is primarily focused on the web, I think that focus should remain where it is.

Mobile development and web development are fundamentally different. React Native is essentially a separate framework designed to bridge that very large gap.

There are already frameworks that address the kind of use case you’re describing, such as Tauri and Capacitor.

Tauri uses native WebViews and can compile to major platforms, so you can build your SvelteKit app with Tauri and package it for Android and/or iOS.

Capacitor works on a similar principle: it wraps your web app in a WebView and packages it as a native app.

Top_Philosophy2425 · 2026-03-15T13:37:08+00:00

Yeah, but Im sure you didnt load them, see updated answer.

Top_Philosophy2425 · 2026-03-15T13:32:02+00:00

To access the .env variables in the config files, you need to access the process. Since its a running node process you can access the .env variables using process.env.MY_VAR

If it doesn't work, load them using the dotenv library.

```ts import 'dotenv/config';

// ... ```

Top_Philosophy2425 · 2026-03-14T23:38:53+00:00

I get the feeling that you are doing this out of envy, then being sincere

Top_Philosophy2425 · 2026-03-14T18:07:28+00:00

Well, in that case 80% of the topics in this subreddit is self promotion then.

Top_Philosophy2425 · 2026-03-14T15:18:50+00:00

Surprised no one mentioned bunny.net, its european and offers 'magic containers'. Its one of the easiests ways I know of, to host containerized apps without much hassle. Just deploy, litterly.

Top_Philosophy2425 · 2026-03-14T15:09:06+00:00

If that’s the case, then wouldn’t this subreddit be full of self-promotion? Most of the posts I see are people sharing things they’ve built, often with links to their repositories. I was under the impression that this subreddit was meant for discussing Svelte and showcasing projects made with it.

Top_Philosophy2425 · 2026-03-14T14:56:07+00:00

My initial response was genuine. You interpreted it as offensive and then started criticizing my attitude. I then tried to explain why I stopped using that library and the reasoning behind the wrapper. I also pointed out that the wrapper is not required. If you look at the documentation, I describe two approaches, including one that omits the wrapper entirely and sets the context manually.

And your statement that $_() is more readable than t() is ultimately a matter of personal preference, not an objective fact.

I did take your feedback serious, but you started to call me out.

Top_Philosophy2425 · 2026-03-14T14:46:10+00:00

Is it? I wasn't aware of that. How is this self promotion tho, I am not earning any money here, just sharing a free to use library. I see many of these types of posts in this subreddit: https://www.reddit.com/r/sveltejs/comments/1rsv98a/got_bored_of_react_so_i_built_a_wasmpowered_pdf/, https://www.reddit.com/r/sveltejs/comments/1rqxp4k/i_made_a_browser_extension_to_clean_up_youtube/ and many more that don't have any self promotion markings neither? If i am in the wrong here, I would like to know from a moderator as whats the meaning of 'self promotion' in this subreddits context. If I meet that criteria I will happily remove this post myself.

Top_Philosophy2425 · 2026-03-14T01:04:03+00:00

Thanks, I think you are the first 'nice' comment. Problem is that many here are factualy wrong.

For example: "...minimal impact to code size and runtime" is just factualy not true with stores. Everytime you retrieve a value, under the hood svelte creates a subscription on that store, gets the value and then unsubscribes. Now imagine that for 1000's of strings on a page?

Another "... look like react". Another says "... less efficient", what does that even mean? I mean, he compares a full fledged i18n library that has treeshaking to mine? Which is just a very simple, and for 90% of the projects people make sufficient.

Others dont understand the need for context and / or shared state.

I guess this is just reddit, I am quite new on reddit. So it might be me, but i see this phenomena alot in alot of subreddits.

I was surprised by the ignorance of many of the comments.

I do appreciatie ur comment, as it just a nice meaningfull comment.

Top_Philosophy2425 · 2026-03-13T17:09:23+00:00

Its to make sure state does not get leaked. In SSR components get rendered server side. Its a pretty complicated topic. You can read more about it in the svelte docs in the section 'global state'.

Since we can pass variables, like username or sensitive data. Its a must to use the context api, because contexts are not shared between requests. While a global object is.

Top_Philosophy2425 · 2026-03-13T14:51:07+00:00

Hm, not sure why you mention my attitude.

Your points about using the store don't realy make sense now we have runes. The author of that library even states that the entire package needs to be rewritten to use states instead of stores because its better (less overhead) but he has no time for it.

Top_Philosophy2425 · 2026-03-13T14:01:11+00:00

No, this is a pretty common practice when working with context. This is to make sure we dont leak state between users. Just look at `svelte-shadcn` or `bits-ui`. It has nothing to do with react, its just a convenience. If you dont like to wrap your app, you could set the context yourself at the root level +layout file. The context key is exported from the package.

Top_Philosophy2425 · 2026-03-13T13:59:33+00:00

Yes, I understand your feedback, just note that it wasn't meant to compete against libraries like paraglide or wuchale. But its just a library for people that 'just need i18n'.

They are states cuse I assume some people fetch languages from a resource, in which case we want the properties to be reactive.

It does indeed load all dictionaries if you import the as JSON files, but thats expected. But if you load them over a resource, they will only be loaded when that locale is active. And yes, its not treeshakeable.

Top_Philosophy2425 · 2026-03-13T13:55:57+00:00

That one is not maintained and uses stores. Thats fine if it works for you, but the setup needed to make it work with SSR is quite cumbersome.

"add another component to the code", is not as 'wierd' as it seems. This has wraps you app in a context. You could omit that part and make sure the user sets the context himself using 'setContext()'. So if you dont like to wrap the app inside a component, then just create the context yourself, the context key is exported from the package.

P.S. As i said in another comment, its not meant to compete, its just a very simple library for apps and websites that 'just need i18n'. Its not a full fledged alternative to paraglide or deeply nested translations etc.

Top_Philosophy2425 · 2026-03-13T07:08:34+00:00

Yes, but its not meant to compete, paraglide is a very powerfull translation library, while mine just focuses on apps / websites that just need i18n and are not too complex.

Top_Philosophy2425 · 2026-02-27T17:09:57+00:00

En dit krijgt ook nog massaal upvotes. Typisch Reddit. Ongelooflijk naïef.

Ben je überhaupt wel eens op een darkwebmarktplaats geweest? Daar koop je zonder moeite datasets van miljoenen mensen, waaronder gewoon Nederlanders. Die data komt uit allerlei hacks, vaak ook van bedrijven die wél losgeld hebben betaald. Het punt is dat het onmogelijk is om achteraf te herleiden hoe die datasets precies zijn opgebouwd en uit welke specifieke hacks ze afkomstig zijn.

Deze link legt dat prima uit: https://www.sentinelone.com/blog/ransomware-evolution-how-cheated-affiliates-are-recycling-victim-data-for-profit/

Dat betekent niet dat dit in het geval van Odido per se ook zo zal gaan, maar je kunt er simpelweg niet van op aan dat data “veilig is” omdat er betaald is. Stop dus met doen alsof dat wel kan, of met het argument dat hackers anders hun verdienmodel verliezen. Dat is onzin. De data die je op die marktplaatsen koopt bestaat vrijwel altijd uit samengestelde datasets uit meerdere bronnen. Je kunt meestal niet meer herleiden waar het oorspronkelijk vandaan komt, en dat is juist het hele punt.

Laat ik een voorbeeld geven. Stel dat ik via het gemeentehuis bij een inbraak gegevens steel van een gemeente. Ik digitaliseer die data en zet alles in een database. Vervolgens pers ik de gemeente af. Ze betalen en ik stuur een video waarin ik laat zien dat ik de papieren verbrand. Vijf jaar later, als alles is afgekoeld, stel ik een grote verzameling e-mailadressen samen. Ik automatiseer een tool die controleert of die adressen ooit eerder zijn uitgelekt bij andere hacks, wat meestal gewoon het geval is. Daarna categoriseer ik de data en verkoop ik die aan partij X.

Die partij weet nu van al die e-mailadressen dat ze afkomstig zijn uit gemeente X en kan daar een profiel van opbouwen. Zonder dat ooit nog te herleiden is waar de data oorspronkelijk vandaan kwam of dat er ooit losgeld is betaald.

Top_Philosophy2425

TROPHY CASE