DEV Community: Arjan kc

QuestSloth: Local Gemma Turns Lecture Notes Into a Dungeon Quiz

Arjan kc — Sun, 25 Oct 2026 07:15:58 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

QuestSloth automates a chore teachers dread — turning dry syllabus notes into quizzes — and makes studying feel like a tiny dungeon crawl.

Teacher Forge — paste lecture notes. Open-weight Gemma 2 2B runs locally in the browser via WebLLM and emits a strict quest.json (quest title, boss name, five MCQs, answers, explanations).
Student Dungeon — play that pack with no AI inference: HP bars, combos, difficulty modes, consumable powers, achievements, procedural SFX + battle music. Correct answers hurt the boss; misses hurt you and show the explanation.

Slow and steady / International Sloth Day: the teacher stops inventing five MCQs by hand; students get a boss fight instead of a worksheet. Notes never leave the device.

Demo

Live app: https://arjankc.github.io/QuestSloth/

Forge needs WebGPU (recent Chrome/Edge). First Gemma download is ~1.5GB for the f16 build (or ~2.5GB if your GPU lacks shader-f16 and Forge falls back to q4f32) and caches in the browser.
Dungeon works without loading any model — try Play sample quest immediately. Unmute the header speaker for lobby pad / battle BGM / SFX.
Forge Play in Dungeon hands the pack over via sessionStorage (plus a short local quest stash).

Code

Repo: https://github.com/arjankc/QuestSloth

arjankc / QuestSloth

Browser-local Gemma turns lecture notes into dungeon quizzes (Hacktoberfest 2026 Week 3)

QuestSloth

Turn lecture notes into a dungeon-crawler quiz — entirely in the browser.

Built for Hacktoberfest Open-Source AI Challenge: Week 3 — Slow and Steady. Teachers paste notes; local Gemma 2 2B (via WebLLM) forges a quest.json. Students fight the boss by answering — no inference on the play path.

Why open weights?

Notes never leave the device (Forge runs on-device WebGPU).
No OpenAI/Claude bill for every quiz.
Students only need the JSON file — the dreaded “write five MCQs by hand” chore becomes a paste → download.

Stack

Vite + React + TypeScript + Tailwind CSS
@mlc-ai/web-llm · prefers gemma-2-2b-it-q4f16_1-MLC-1k (~1.5GB); auto-falls back to gemma-2-2b-it-q4f32_1-MLC (~2.5GB) when WebGPU shader-f16 is missing
Static host: GitHub Pages (base: '/QuestSloth/', HashRouter)

Modes

Mode	Route	AI?
Teacher Forge	`#/forge`	Yes — loads Gemma, emits strict quest JSON
Student Dungeon	`#/dungeon`	No — upload JSON, forged handoff, sample, or

…

View on GitHub

Worth a look:

src/lib/webllm.ts — Gemma load + f16 feature probe + q4f32 fallback + low-temperature JSON generation
src/lib/questSchema.ts — Zod validation + JSON Schema for constrained decoding
src/lib/difficulty.ts / src/lib/powers.ts / src/lib/progress.ts — Easy/Normal/Hard, Hint/Shield/Focus, XP + achievements
src/lib/audio.ts — procedural Web Audio (no sound files)
src/pages/Forge.tsx / src/pages/Dungeon.tsx — the two halves of the product

How I Built It

Constraints drove the stack: ~30GB free disk, 4GB VRAM, no Python/Ollama/Docker. Everything is a static SPA on GitHub Pages.

flowchart LR
  notes[LectureNotes] --> forge[TeacherForge]
  forge --> webllm[WebLLM]
  webllm --> gemma[Gemma2_2B]
  gemma --> pack[quest.json]
  pack --> dungeon[StudentDungeon]
  dungeon --> fight[BossFight]

Vite + React + Tailwind for routing and game state (HashRouter, base: '/QuestSloth/')
@mlc-ai/web-llm prefers gemma-2-2b-it-q4f16_1-MLC-1k (~1583MB VRAM). On GPUs that don't advertise WebGPU shader-f16, Forge probes adapter.features and loads gemma-2-2b-it-q4f32_1-MLC instead (~2.5GB) — same Gemma 2 2B IT weights, no Canary flags required. If the probe misses, a create failure matching shader-f16 triggers one automatic retry.
Strict JSON: temperature: 0.15, WebLLM response_format: { type: "json_object", schema }, then Zod parse + one repair retry
Code-split Forge so the Dungeon route never pulls WebLLM (phone-friendly play)
Game loop: difficulty tables, one-power loadout (Shield/Focus unlock at level 2), combos, level combat bonuses, achievements, CSS battle FX, lobby pad + battle BGM that speeds up on enrage

Small models love to ignore free-form prompts. Constrained decoding plus a validator kept the dungeon from crashing on bad packs — the same lesson browser-Gemma builders keep rediscovering (Touch Soil is a good peer example of schema-shaped WebLLM output).

The f16 fallback was a live-demo fix: WebLLM's f16-1k build hard-requires shader-f16, and shipping only that ID meant some Chrome/Edge users (especially integrated GPUs) got a Canary flag error instead of a quiz. Probe + q4f32 keeps Best Use of Gemma reachable on more hardware — the same pattern in-browser LLM posts keep hitting (WebGPU present ≠ WebGPU usable; ship a quantization per backend).

Why Does Open Innovation Matter?

Classroom notes stay on the laptop. Forge never posts syllabus text to a paid API.
Zero inference bill after the one-time model cache — important if you forge quizzes every week.
Students only need the JSON file. Schools with locked-down or low-end devices can still play the dungeon.
Swappable brain. The model id is one string in webllm.ts; any WebLLM Gemma (or other open weight) can replace it.

Lazy payoff: paste notes → download (or hand off) quest → share with the class. The chore of inventing five decent MCQs disappears.

Prize Categories

Best Use of Gemma — Teacher Forge runs open-weight Gemma 2 2B in-browser via WebLLM to generate every quest pack.

Local Listing Nepal: Bilingual Google/Facebook listing packs with Gemma in the browser

Arjan kc — Sat, 17 Oct 2026 16:12:21 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Local Listing Nepal turns a short Nepal small-business brief into a ready-to-paste listing pack for the places local shops actually need to show up:

Google Business short + full descriptions
Suggested categories and services
Facebook About / Intro
3–5 low-hype Facebook starter captions
Hamrobazar / marketplace title + description when it fits
Nepali (Devanagari) short + full descriptions
Honest local search phrases
Assumptions / questions instead of invented “facts”

Who would pay: shop owners, cafes, clinics, tutors, and service businesses in Nepal who currently pay an agency or freelancer for listing rewrites; freelancers who want a productized micro-service; agencies that need a faster first draft before human polish.

The problem: a lot of Nepal SMBs have weak or empty Google Business and Facebook listings — missing categories, generic English-only copy, no Nepali text, weak local keywords, no clear call-to-action, inconsistent name/address/phone. A full marketing retainer is expensive when they only need a strong listing pack.

I run client work through Gurkha Technology in Kathmandu and teach business/IT subjects. This is the reusable draft tool I wanted for that work: something I can operate from Nepal without depending on a paid API card for every generation.

How it works for the user: fill in business name, category, location, phone, services, optional differentiators, and language mix (English / Nepali / bilingual). Generate. Copy any section, copy all Markdown, or download a .md file. The UI states clearly that briefs are processed locally in the browser — nothing goes to a paid API by default.

Demo

Live demo (GitHub Pages): https://arjankc.github.io/local-listing-nepal/

Use a recent Chrome or Edge on desktop (WebGPU required). The first generate downloads ~1–1.5 GB of open model weights into the browser cache; after that it can work offline.

Try a brief like:

Business: Lakuri Hills Cafe
Category: cafe
Location: Lakuri Phedi, Lalitpur
Phone: your real number
Services: filter coffee, brunch, hiking snacks, outdoor seating
Language mix: bilingual

Watch the pack stream in under the fixed section headings, then copy what you need into Google Business or Facebook.

Repo: https://github.com/arjankc/local-listing-nepal

Code

arjankc / local-listing-nepal

Nepal SMB listing packs (Google/Facebook/marketplace) with Gemma in the browser via WebLLM

Local Listing Nepal

Turn a Nepal small-business brief into ready-to-paste Google Business Profile, Facebook Page, and Hamrobazar / marketplace listing copy in English and Nepali.

Open-weight Gemma runs in your browser via WebLLM + WebGPU. No backend. No paid API by default.

Live demo: https://arjankc.github.io/local-listing-nepal/

Who would pay

Shop owners, cafes, clinics, tutors, and service businesses in Nepal who currently pay for listing rewrites
Freelancers who productize listing packs for clients
Agencies that want a faster first draft before human polish

Features

Simple business brief form (name, category, location, phone, services, optional extras, language mix)
Structured listing pack with stable Markdown headings
Copy per section (navigator.clipboard.writeText)
Copy-all Markdown + download .md
Privacy note: briefs stay on-device; model loads into browser cache

Requirements

Recent Chrome or Edge on desktop with WebGPU
First generate downloads ~1–1.5 GB model weights into browser cache
Modest integrated GPUs work; pick…

View on GitHub

Stack in short:

Vite + React + TypeScript + Tailwind (static SPA, no backend)
@mlc-ai/web-llm for in-browser inference
Default open model: Gemma 2 2B (Qwen 2.5 1.5B and Llama 3.2 1B as lighter fallbacks)
Temperature 0.15 and a fixed Markdown heading schema so each section gets its own Copy button
MIT license

The WebLLM load/progress pattern (quantization probe, Gemma user-turn prompting) was proven earlier on a different product, Nepali String Localizer. This is a new repo and a new job: SMB listing packs, not UI string localization.

How I Built It

Open-source AI is not a badge on the landing page — it is the product. Without an open-weight model running locally, there is no listing pack.

I built this on modest hardware (aging integrated graphics). That constraint shaped every choice: smallest viable Gemma in the WebLLM catalog by default, clear download progress, streaming output, and a lightweight UI so the tab does not fall over.

In-browser inference with WebLLM + WebGPU. On first generate, the app loads Gemma 2 2B into the tab. It checks whether the GPU supports 16-bit float shaders and picks q4f16_1 or q4f32_1. There is no server of mine in the loop: GitHub Pages serves the static app; the visitor’s machine does the inference.

One strict prompt, one fixed output schema. The model is instructed to act as a Nepal SMB listing copywriter: never invent amenities, prices, awards, or hours; preserve name/address/phone and brand spelling exactly; use [Ask the business] for gaps; avoid marketing fluff; write natural written Nepali for business listings, not awkward literal translation. Output must use stable ## headings so the UI can parse sections for per-section clipboard copy (navigator.clipboard.writeText).

Gemma as the core model. Nepali + English listing copy is the hard part on a 2B-class model. Gemma 2 2B was the best of the small WebLLM options I could ship for Devanagari and bilingual packs. Gemma’s chat template has no system role, so the instructions travel in the user message — same practical detail as my earlier browser tool, applied here to a different prompt and product.

What I deliberately did not build: auth, CRM, billing, auto-posting to Google/Facebook APIs, image generation, ads builders, or competitor scraping. The MVP is a listing pack writer someone would actually pay a freelancer for — not an unfinished platform.

flowchart LR
  brief["Business brief"] --> prompt["Listing prompt"]
  prompt --> webllm["WebLLM"]
  webllm --> gemma["Gemma 2 2B"]
  gemma --> pack["Markdown pack"]
  pack --> export["Copy / export"]

Nepali String Localizer, context-aware UI translation for my fellow volunteer translators

Arjan kc — Mon, 05 Oct 2026 03:19:05 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Nepali String Localizer translates isolated English UI strings into Nepali, using context about where the string appears. It runs in a browser tab on an ordinary laptop, with no install and no API key.

I volunteer as a translator with Translators without Borders, and I built this for the people I volunteer alongside: Nepali translators who give their time to humanitarian and open-source projects. Their "friend" here is the whole community. I'm sure there are volunteers who can use this tomorrow, starting with me.

A lot of the software humanitarian teams rely on is open source. KoboToolbox, the data-collection platform that NGOs and field teams use for surveys and crisis response, is one example. Getting its interface into Nepali means someone, usually a volunteer, translating it string by string.

The problem: on localization platforms, a translator sees strings one at a time with almost no context. Take Deploy. Is it a button, a status message, or a heading in the docs? Each one needs different Nepali. A technical word like "Server" or "Submit" also raises a question: should it be translated, transliterated into Devanagari, or left in English? Volunteers make that call hundreds of times per project, usually alone and in their spare time.

What it does: paste the string, add a line of context (for example "Primary call-to-action button on the server settings page"), and get three options:

Formal: standard written Nepali, for docs and strict UI.
Colloquial: natural, conversational Nepali, for friendly everyday app text.
Transliterated/Hybrid: technical terms kept in English, written in Devanagari (सबमिट, सर्भर) or left in Latin script when translating them would lose the meaning.

The prompt tells the model to leave placeholders like {name}, %s and HTML tags untouched, so a translation doesn't break the app it goes into.

It doesn't replace the translator. It gives them three starting points to pick from or edit, so they spend their time on judgment instead of a blank text box.

My next step is sharing the link with other Nepali volunteers and collecting their feedback on which of the three styles they actually pick.

Demo

Try it in your browser: https://arjankc.github.io/Localized-String-Assistant/ (no install and no API key). The first translation downloads a ~1.5 GB open model into your browser cache.

To try it, type a string like Deploy Form, add context like "Primary call-to-action button on the form builder page that publishes a survey", and click Translate to Nepali. A progress bar shows the model download, then the three options stream in. Once the model is cached, you can turn off Wi-Fi and keep translating.

Prefer a desktop app? The same repo includes a Streamlit version that runs Gemma 3 4B locally through Ollama (setup steps in the README).

Code

arjankc / Localized-String-Assistant

Nepali String Localizer

Context-aware English-to-Nepali UI string translation for open-source localization projects like KoboToolbox.

Paste an isolated UI string (for example Deploy Form), describe where it appears, and get three Nepali options:

Formal: standard written Nepali, for documentation or strict UI.
Colloquial: natural, conversational Nepali, for friendly everyday app text.
Transliterated/Hybrid: technical terms kept in English, written in Devanagari (सबमिट, सर्भर) or left in Latin script when translating them would lose the meaning.

Placeholders such as {name}, %s, %(count)d and HTML tags are preserved as-is.

Why it exists

Volunteer translators on platforms like Transifex or Weblate see strings one at a time, with little or no context. "Deploy" on a button, "Deploy" in a status message, and "Deploy" in docs often need different Nepali wording. This tool gives a translator three context-aware candidates to pick from or edit, so they spend their time reviewing…

View on GitHub

There are two front ends that share one prompt:

docs/index.html: a single static page that runs the model in the browser (WebLLM + WebGPU).
app.py: a ~140-line Streamlit app that talks to a local Ollama server or Groq.

How I Built It

I built this on a 2018 laptop: an i5-8265U with 16 GB of RAM, integrated Intel UHD 620 graphics and no dedicated GPU. That constraint shaped everything. Volunteers don't usually have workstation GPUs, so if it runs on this machine, it should run on theirs.

In-browser inference: WebLLM compiles open-weight models to WebGPU, so Gemma 2 2B runs inside a browser tab on integrated graphics. The page checks whether the GPU supports 16-bit float shaders and picks the matching build. Qwen 2.5 1.5B and Llama 3.2 1B are there as lighter options. There's no backend at all: GitHub Pages serves one HTML file, and the model is cached in the browser after the first load.
Local inference with Ollama: for translators who prefer a desktop setup, the Streamlit app runs Gemma 3 4B on the CPU through Ollama. Ollama exposes an OpenAI-compatible endpoint, so the standard openai Python client talks to it, or to Llama 3.3 70B on Groq when more quality is needed. Switching between them only changes the base_url.
Choosing small models for Nepali: this was the interesting part. Nepali is a lower-resource language, and many small models were trained mostly on English and a handful of major languages. I leaned on the Gemma family. Gemma 3 was trained on 140+ languages, which makes it the Ollama default, and Gemma 2 2B is the default in the browser. The lighter 1B options are there for very weak machines, with the tradeoff stated in the UI. Because nothing is hardcoded to one model, swapping in a better small multilingual model is a one-line change as WebLLM's catalog grows.
Prompting: one prompt does the heavy lifting. It makes the model act as an English-to-Nepali software localization expert, keep placeholders like {name} and %s intact, stay short enough for UI text, and return exactly three options in a fixed Markdown template. A low temperature (0.3) keeps the output consistent from string to string. Gemma's chat format has no system role, so the browser version sends the instructions in the user turn.

flowchart LR
    user[Translator] --> web["Browser page: WebLLM + WebGPU"]
    user --> st[Streamlit app]
    web --> gemma2["Gemma 2 2B in the browser tab"]
    st -->|offline| ollama["Ollama: Gemma 3 4B on CPU"]
    st -->|online| groq["Groq: Llama 3.3 70B"]
    gemma2 --> out[Formal / Colloquial / Hybrid]
    ollama --> out
    groq --> out

Why Does Open Innovation Matter?

It runs on an old laptop, in a browser tab, with no internet. Volunteer translation happens on personal laptops, not fast office machines. Because the weights are open, a 2B model can be compiled to WebGPU and shipped as a static web page. After the first load, a volunteer can keep translating wherever connectivity is patchy or gone. A closed API simply stops working there.

Zero setup for volunteers. Nobody needs Python, Ollama or an API key. I can share one link in a volunteer group and anyone with a recent Chrome or Edge can use it. A closed model can't be shipped like that; it can only be rented through someone's server.

It costs nothing to run. This is volunteer work. Nobody should have to put a credit card on file for a per-token API to translate humanitarian software for free. There's no server to pay for either: GitHub Pages hosts the page, and the visitor's own GPU does the inference.

Unreleased strings stay on the translator's machine. Strings from unreleased features and internal admin screens never leave the device in the browser and Ollama versions.

We can swap models, and eventually fine-tune. Nepali is a lower-resource language, and different open models handle Devanagari very differently. Because the app only depends on an OpenAI-compatible endpoint, switching from Gemma to Llama to Qwen is a config change, not a rewrite. The next step is fine-tuning a small open model on the existing, human-reviewed Nepali translations from KoboToolbox's own translation files, so it learns the project's established terms. That is only possible because the weights are open.

Open tools for open tools. Humanitarian software like KoboToolbox is open source, and many of the people translating it are volunteers. It felt right that the tool helping them is open too. Volunteers working in other languages (Maithili, Newari, Tamang, or any language Translators without Borders supports) can fork it, change the prompt, and point it at whichever open model handles their language best.