The light theme looks more appealing and clean than the dark counterpart.

I don't know what it is, or how, but we need to improve the dark theme.

There are other things I'd like to add to the code blocks, but for those, I'll make another ticket.

By searching online how other people do this, I think only adding the css-variables theme is not enough; we might have to create a custom md plugin for this.

I wanted to do the i18n without external libraries to have more control and see how this works under the hood. It has its flaws, and we'll work on them eventually. The one we should tackle first is that we import both translation files, no matter the application's language. We should only bring one because the translations are not live; we do a full page reload when the user changes language.

So far, this is not an issue because we only have two languages, and there are few entries, but I can see this becoming a big problem over time, and it's better to work on this now or at least have a clear plan.

The sitemap integration is helpful, but I did it just for fun and testing, and it grew. It is still manageable, but splitting some of the utilities and adding tests around it will be nice.

This is one of the few real issues reported by Lighthouse. Although the page loads so fast that it is not very noticeable, there's a time when the custom fonts are not loaded, and the text is invisible.

We are using fontsource and the swap strategy, but it seems it needs to be fixed. Try to fix this. Self-hosting the font is a good solution, or manually declaring the fonts because we are already self-hosting.

On this comment I added a few images of this issue #20 (comment)

The featured post should be a popular, hot or trending one... it also should be easy to change without redeploying... maybe 😏

I only send an email, but the service might fail, or the email might end up in the spam folder. If we add a new integration with a service to record each sent mail, we can verify we are receiving and responding to everything. Also, it'll be a centralized way to verify people trying to contact me.

Astro is supposed to do this and only ship the necessary CSS for each page, but it's bundling everything on a single 404.cssfor some reason.

I see kobalte is bringing its i18n package with a bunch of languages we don't support, and if we plan to, we'll add our translations, that'd be an excellent place to start.

I also saw that Solid Headless bundle size might be smaller, so that's an option I'm open to considering if the improvement is substantial.

This is to allow non-js users to search the blog so the page should work without JS, but also to have a nice search box on Google results and so on. Probably we can create a Raycast integration too xd

Use simplified styles and classes by creating a "brand" theme. This should reduce the CSS size and HTML as well.

Related to #3

To fix the issue where FullWidhContainers added a horizontal scroll, I added an overflow-x: hidden to the HTML element; this overrides the overflow in the body when the modal (for search) is open.

This is from a WIP and discarded (for now) implementation for the testimonials. The current method is accurate but different from the natural reading pace. Find a better way to split the words.

If the time comes to work on this, I'll add more details.

I decided to redirect old links to the new links (i.e., blog/some-post => [lang]/blog/some-post) if an entry is found with that slug.

So far, this is one of the best decisions because the traffic keeps coming, and users do not see a 404, but it is time to make those redirect permanent (301 instead of 302).

We take the entry date, but that's unreliable as the lastmod key for the sitemap if we want to keep search engines updated. The idea is to use the git modified date for this.

I currently use the i18n module on the client side instead of build time, even when 90% of the text is not dynamic. I also bring both languages even it's impossible to use them at the same time, this will grow exponentially the more translations and languages we have.

Core Ideas

• Remove unnecessary client-side translation. Pass the already localized text from Astro at build time
• (extra) Remove calls to the unused language. For example, if we are on /es, there is no need to import the JSON translation.
• If we can split the translations from the actual i18n helper, even better.

The idea of the command bar (only search at the moment) is to be a hub to do things and hide easter eggs for the blog. Similar to VSCode Command Panel. We need to add support for keyboard navigation. The idea is to move between the options and scroll them to view when necessary without losing focus from the input.