---
title: Weekly Log - May 16, 2025
canonical: https://www.mandalivia.com/ai-native-company/weekly-logs/may-16-2025/
---

## Key Lessons
- This week I attempted to build internationalization into the system. The goal here is to have the basics of internationalization for 2 languages built into the system from the beginning.
- We started with English and Espanol. I wanted to set up how we'd add new games and enhance them with translations and keys.
- Gemini 2.5 pro (05-06) was pretty great at figuring out the roadmap. We wrote up a pretty great ticket. 
- The internationalization threads got long and we got caught up in many long discussions and the context started to get large. I forked off many sub-threads.
- In the end it worked.
- But now I have an instability in the Astro system. And I have to look back to see where the change went wrong.
- If I want to build towards a system where I can use an agent and write tickets I need a better process. Gemini has a tendency to "get the job done"
- It will add comments like
```
// TODO: Investigate why Astro.locals.i18n is not populated as expected.

// Normally, 'allConfiguredLocales' and 'siteDefaultLocale' should come from Astro.locals.i18n.

// Using hardcoded fallback based on astro.config.mjs due to Astro.locals.i18n being undefined.
```

This is terrible. No one including AI is going to read this and do anything about it.
In another project I am doing Test-Driven-Development. I am not quite sure how astrojs handles that.

- You have to know what you're talking about
	- At one point Gemini suggested I move a script to the `/public` folder but AstroJS doesn't process those files the same way. If I hadn't known this already that would have taken us down a rabbit hole.


- Reverting all the way back. 
- Turns out the dev version was working but production was not working.
- I had to revert all the way back to the pre-i18N version of the branch.
- Thank goodness for Git. But I think we could/should do a better job of reverting.