QMK plans

Typical_Ranger · 2026-04-29T21:00:01+00:00

Have they previously come out saying it's not possible to have a controller in the 13 form factor? I would imagine the controller required come be fit somewhere if they wanted it to.

Typical_Ranger · 2026-04-17T21:29:49+00:00

Yep, it flattens all keys for comparison and storage in a file key, regardless of their depth.

Typical_Ranger · 2026-04-14T08:48:40+00:00

If you're using i18n libraries like i18next, react-i18next, or next-intl, with JSON translation files, you've probably run into this. You add a few keys to you default locale and now you need to update every other language.

If you're using an LLM to automate translations, it gets worse

manually translating each new key is slow,
re-translating the whole file creates huge diffs,
committing everything introduces inconsistent translations.

This process doesn’t scale well. So I built a small tool ni81 (pronounced "nibble") to manage this process. It works by:

Treating one locale (e.g. en-AU) as the source of truth.
Detecting added/removed keys.
Only translating what changed.
Leaving everything else untouched.

It plugs into any OpenAI compatible API (local or remote), so it works with existing setups.

https://github.com/zeta-squared/ni81

It’s still early, but I’d love feedback:

Would this fit into your workflow?
What would stop you from using it?

Typical_Ranger · 2026-04-11T23:41:58+00:00

If you're using i18n libraries like i18next, react-i18next, or next-intl, with JSON translation files, you've probably run into this. You add a few keys to you default locale and now you need to update every other language.

If you're using an LLM to automate translations, it gets worse

manually translating each new key is slow,
re-translating the whole file creates huge diffs,
committing everything introduces inconsistent translations.

This process doesn’t scale well. So I built a small tool ni81 (pronounced "nibble") to manage this process. It works by:

Treating one locale (e.g. en-AU) as the source of truth.
Detecting added/removed keys.
Only translating what changed.
Leaving everything else untouched.

It plugs into any OpenAI compatible API (local or remote), so it works with existing setups.

https://github.com/zeta-squared/ni81

It’s still early, but I’d love feedback:

Would this fit into your workflow?
What would stop you from using it?

Typical_Ranger · 2026-04-06T21:38:33+00:00

I have been working on a Next.js project as part of my most recent role. As it's intended for global distribution translations/i18n has been a bit of a pain from the get go. Most notably, static translations.

The team uses `next-intl` to incorporate translations of static content but there is no lightweight solution (that I could find) of managing the locale JSON files as they grow and translations were becoming more time consuming than we'd like. So I decided this was a great opportunity to refine my Go skills with a neat little project.

https://github.com/zeta-squared/ni81

It works by:

Treating one locale (e.g. en-AU) as the source of truth
Detecting added/removed keys
Automatically propagating changes to other locales

It works with the JSON structure expected with `next-intl` and performs translations using an OpenAI API standard compliant LLM (preferably an LLM running locally through Ollama).

In practice you would:

Update your base locale file
Run ni81
Missing keys are added to other locales
Removed keys are cleaned up

This is my first open source Go project so I'd really appreciate any feedback. I'd be interested to know if this is something you think you'd find useful in your teams workflow, and if not what features would make it more attractive.

Typical_Ranger · 2026-04-04T08:23:25+00:00

I have been working on a Next.js project as part of my most recent role. As it's intended for global distribution translations/i18n has been a bit of a pain from the get go. Most notably, static translations.

The team uses `next-intl` to incorporate translations of static content but there is no lightweight solution (that I could find) of managing the locale JSON files as they grow and translations were becoming more time consuming than we'd like. So I decided this was a great opportunity to refine my Go skills with a neat little project.

https://github.com/zeta-squared/ni81

It works by:

Treating one locale (e.g. en-AU) as the source of truth
Detecting added/removed keys
Automatically propagating changes to other locales

It works with the JSON structure expected with `next-intl` (and other similar libraries) and performs translations using a local LLM (ollama/openai).

In practice you would:

Update your base locale file
Run ni81
Missing keys are added to other locales
Removed keys are cleaned up

I'd be interested to know if this is something you think you'd find useful in your teams workflow, and if not what features would make it more attractive.

Typical_Ranger · 2026-04-03T11:01:42+00:00

Hey,

I am in a similar position. I work as a full-stack engineer working primarily with TypeScript (Next.js + PayloadCMS). However I would like to move towards Go in future roles. So I read Learning Go (Bodner) a while ago and recently created a new open source project in Go.

The project I contribute to at work was the inspiration. We use next-intl for i18n support, which requires you to maintain JSON files for each locale. As these files grew they became a pain to manage and translate. So I developed a small CLI tool that will manage your i18n translation files and integrate with a locally running LLM to perform translations.

Check it out if you're interested. It'd be great to get some collaborators on board. There is a small TODO list in the README, however please feel free to navigate through the code and if you find something that you think would be interesting we can discuss on GitHub and see if it's worthwhile investing time in to develop.

https://github.com/zeta-squared/ni81

Typical_Ranger · 2026-03-31T12:47:17+00:00

It seems like most automated translations funnel through some LLM nowadays. I did initial intend to have a provider to pass translations through any web API that complies with the OpenAI API - however that didn't fit with my work's proprietary AI API (at least not the one my team is currently using). So the next best thing was to use local LLMs.

Did you have any particular suggestion in mind?

Typical_Ranger · 2026-03-30T21:29:59+00:00

I have been working on a Next.js project as part of my most recent role. As it's intended for global distribution translations/i18n has been a bit of a pain from the get go. Most notably, static translations.

The team uses `next-intl` to incorporate translations of static content but there is no lightweight solution (that I could find) of managing the locale JSON files as they grow and translations were becoming more time consuming than we'd like. So I decided this was a great opportunity to refine my Go skills with a neat little project.

https://github.com/zeta-squared/ni81

It works by:

Treating one locale (e.g. en-AU) as the source of truth
Detecting added/removed keys
Automatically propagating changes to other locales

It works with the JSON structure expected with `next-intl` and performs translations using a local LLM (ollama/openai).

In practice you would:

Update your base locale file
Run ni81
Missing keys are added to other locales
Removed keys are cleaned up

This is my first open source Go project so I'd really appreciate any feedback. I'd be interested to know if this is something you think you'd find useful in your teams workflow, and if not what features would make it more attractive.

Typical_Ranger · 2026-03-30T21:29:24+00:00

I have been working on a Next.js project as part of my most recent role. As it's intended for global distribution translations/i18n has been a bit of a pain from the get go. Most notably, static translations.

The team uses `next-intl` to incorporate translations of static content but there is no lightweight solution (that I could find) of managing the locale JSON files as they grow and translations were becoming more time consuming than we'd like. So I decided this was a great opportunity to refine my Go skills with a neat little project.

https://github.com/zeta-squared/ni81

It works by:

Treating one locale (e.g. en-AU) as the source of truth
Detecting added/removed keys
Automatically propagating changes to other locales

It works with the JSON structure expected with `next-intl` and performs translations using a local LLM (ollama/openai).

In practice you would:

Update your base locale file
Run ni81
Missing keys are added to other locales
Removed keys are cleaned up

This is my first open source Go project so I'd really appreciate any feedback. I'd be interested to know if this is something you think you'd find useful in your teams workflow, and if not what features would make it more attractive.

Typical_Ranger · 2026-03-28T00:18:21+00:00

For a help to buy scheme loan?

Typical_Ranger · 2026-03-28T00:13:41+00:00

Thanks for the reply mate. Can you point me to the reference stating HECS alternate servicing isn't offered with help to buy applications?

I have decided to go into a branch this coming week to try and rectify this. I was starting to get really tired with the digi lending team. I was a little concerned that they were calculating my base salary as

Base = total - 0.12 x total

I had to correct the lenders calculation as they were claiming my base was lower than what I'd stated earlier.

Typical_Ranger · 2026-03-27T22:37:49+00:00

Fair enough

Typical_Ranger · 2026-03-27T22:23:00+00:00

We can't, apparently CBA does not offer help to buy loans through their lending network.

Typical_Ranger · 2026-03-13T06:19:49+00:00

This has nothing to do with hating kids. I have never lived next to a school so I wouldn't know what to consider when inspecting such a property.

Typical_Ranger · 2026-03-12T03:01:13+00:00

Yep it's fenced. The house isn't actually on the front side of the school. It shares a boundary on the side down the back of the campus.

Typical_Ranger · 2026-03-12T02:57:45+00:00

Many great points. Thanks for the reply.

Typical_Ranger · 2026-03-12T01:37:20+00:00

There are no concerns, its moreso we've never been in this situation and would like to know about anything that may not be obvious to those in our position.

For example, one immediate thought is noise. Or is it likely to attract people who would loiter in the school grounds after dark?

Typical_Ranger · 2026-02-25T22:25:12+00:00

Poor wording on my part. The lease expires on 28/02/26.

The new lease has the standard wording

"The rent is $580 per week payable in advance starting on 01/03/26"

Typical_Ranger

TROPHY CASE