DevBlog

Changing How Development Is Documented

MGU website updates have generally been released on Monday mornings. Development itself has continued steadily, but documentation has not always kept pace with the amount of work being done.

Reviewing the MGU Logs exposed a noticeable gap between the period when I was developing the Business textbooks and the later period when work shifted toward revising the Malone Doctrine. A great deal of work happened between those two points, particularly approximately two months devoted to drafting foreign-language textbooks.

Trying to formally document every work session is becoming impractical. The new approach is to update the MGU Logs periodically when there is something useful to record, while reserving the DevBlog for larger milestones and structural upgrades.

A DevBlog entry every six to eight weeks, or whenever a major system reaches a meaningful stage, better reflects the actual development process. MGU work increasingly happens in concentrated periods of research, writing, coding, revision, testing, and restructuring rather than in neat daily development cycles.

Textbook Development Has Reached a Natural Pause

At 12:42 AM on August 17, 2026, I reviewed the current textbook inventory. MGU has now drafted 56 textbooks across seven broad academic areas.

For now, this is enough textbook coverage.

The existing books still need substantial revision. Some contain factual errors, inconsistent formatting, awkward sections, or coding artifacts left over from large-scale production. Future textbook development will probably move toward engineering, but I am not interested in beginning another large textbook-production cycle right now.

The choice has become simple: continue creating new books, or improve the books that already exist.

I chose improvement.

The current phase of MGU development is therefore becoming more focused on correction, standardization, restructuring, quality control, and strengthening existing material rather than continuously increasing the amount of published content.

The Evolution of the MGU Dictionary

The MGU Dictionary began in August 2025 as a single General English dictionary located at:

/library/dictionary/

I worked on the dictionary for approximately a month before development shifted toward course-specific glossaries for Corporate Science classes.

One example was the Economics 101 glossary:

/department/corporate-science/economics-101/glossary/

When I eventually returned to the main dictionary, several architectural problems had to be solved before serious entry production could continue.

Problem One: What Words Should Be Included?

The first major problem was vocabulary selection.

I experimented with several ways of obtaining large English word lists. I used Princeton's WordNet tools, PowerShell commands to download GitHub word lists, and other publicly available vocabulary sources.

This produced extremely large lists, but the size of the lists quickly became part of the problem.

Some lists contained misspellings, broken words, malformed entries, fragments, obscure forms, and strings that appeared to be gibberish. Other words were technically real but were so obscure that they added very little practical value to a general-purpose dictionary.

Simply possessing a huge word list is not the same thing as building a useful dictionary.

The original goal was to provide useful vocabulary in a clear and simple format. Overwhelming users with junk entries merely so the dictionary could claim a larger word count would make the resource worse rather than better.

This established one of the central principles of the dictionary project:

Quality over quantity.

The General English Dictionary should contain useful English vocabulary that is clearly written, properly structured, and worth looking up.

Problem Two: How Should the Entries Be Stored?

The next problem was architectural.

English contains hundreds of thousands of words. Creating an individual HTML page for every dictionary entry would eventually create an enormous amount of duplicated code.

Even if such a system worked initially, maintaining hundreds of thousands of separate pages would become impractical.

A traditional database could solve the storage problem, but building and maintaining a complete database system would introduce more infrastructure and complexity than the project currently required.

The solution was much simpler:

index.html
entry.html
a.json
b.json
c.json
...

The index.html page serves as the searchable dictionary index.

The entry.html page serves as the reusable display template.

The JSON files store the actual dictionary records.

Instead of creating hundreds of thousands of separate HTML pages, one reusable HTML entry page can display every word in the dictionary.

When a user searches the index, JavaScript reads the JSON files and determines which words are available. When the user selects a word, the entry page retrieves that word's JSON record and displays the appropriate data.

The record can contain pronunciation, grammatical information, definitions, examples, etymology, related words, usage notes, and other structured information.

Why JSON Works So Well

JSON files function like small structured databases. They store records as fields and values, similar to the data submitted through forms containing names, addresses, phone numbers, email addresses, and other organized information.

In programming, a structure that maps a key to associated values is often described as a dictionary.

That makes JSON an unusually good fit for building a literal dictionary.

{
  "word": {
    "lemma": "word",
    "partOfSpeech": "Noun",
    "pronunciation": {},
    "etymology": "...",
    "senses": []
  }
}

A word acts as the key, and all of the information associated with that word is stored inside its record.

The programming concept of a dictionary and the traditional language dictionary therefore fit together naturally.

Problem Three: Loading and Maintenance

Once JSON became the storage system, another issue appeared. Placing the entire English dictionary inside one enormous JSON file would eventually create unnecessary loading and maintenance problems.

The solution was to shard the dictionary alphabetically:

a.json
b.json
c.json
d.json
...

Each letter receives its own JSON file.

This allows the website to load smaller amounts of data and makes maintenance easier because individual alphabetical sections can be edited, checked, replaced, or expanded independently.

At 12:04 AM on August 17, 2026, I completed the General English Dictionary b.json shard.

It currently contains 374 B-word entries.

This is the first substantial completed shard using the finalized dictionary architecture.

Problem Four: What Information Should Each Entry Contain?

Once the storage and rendering system became stable, the next problem involved the entry template itself.

I would write dictionary entries only to later change which fields were displayed. That forced previously written records to be repeatedly rewritten.

Eventually I stopped producing definitions and focused instead on finalizing the structure of each entry.

The current record format includes fields such as:

lemma
tier
part of speech
pronunciation
variants
inflections
synonyms
antonyms
etymology
explanation
audio
difficulty
usage notes
related words
senses
examples

Once the schema became stable, entry production could resume without constantly rebuilding old work.

This was an important development because the dictionary was finally becoming searchable, reusable, and maintainable at the same time.

IPA and Pronunciation

During the period when dictionary production was paused, work elsewhere in MGU ended up improving the dictionary system.

I wrote an International Phonetic Alphabet textbook designed to teach students how IPA pronunciation notation works.

Dictionary entries can now display both formal IPA transcription and a simplified pronunciation guide. Readers who want to understand the IPA notation can follow the dictionary link directly into the IPA textbook.

This makes pronunciation part of a broader educational system rather than an isolated string of symbols appearing beside a word.

The same IPA resource can also support the foreign-language textbooks and future bilingual dictionaries.

From One Dictionary to a Dictionary Library

The original plan was to build one English dictionary.

While redesigning the dictionary index, I began adding links for future foreign-language dictionaries because the foreign-language textbook program had already created the educational foundation for them.

That expanded the planned system to 15 foreign-language dictionaries.

At the same time, another issue became increasingly obvious. English contains enormous amounts of specialized vocabulary from medicine, law, computing, engineering, economics, science, politics, music, business, and other disciplines.

Very early in the dictionary project, I had considered adding filters that would separate technical words by profession or trade.

A better solution eventually became apparent:

Do not force all technical terminology into one dictionary. Separate the dictionaries themselves.

Subject-Specific Dictionaries

MGU now plans 24 English-language subject dictionaries:

• Academic
• Acronyms
• Art
• Business
• Computer Science
• Engineering
• Economics
• General English
• Geography
• History
• Internet
• Law
• Linguistics
• Literature
• Mathematics
• Medical
• Military
• Music
• Philosophy
• Political Science
• Psychology
• Religious
• Science
• Sports

Combined with the 15 planned foreign-language dictionaries, the current system contains 39 planned dictionaries.

Only the General English Dictionary is currently under active construction.

Separating the dictionaries solves the technical-jargon problem much more cleanly than trying to force every specialist definition into General English.

Each subject dictionary can have its own vocabulary standards and its own level of technical depth.

The Same Word Can Belong to Multiple Dictionaries

Some words naturally cross disciplinary boundaries.

Rather than attempting to place every specialized meaning into one enormous General English entry, the same lemma can appear in multiple dictionaries where appropriate.

buffer
├── General English
└── Computer Science

bond
├── General English
├── Business
├── Law
└── Science

cell
├── General English
├── Medical
└── Science

The General English entry can explain the ordinary meaning and perhaps briefly acknowledge a widely encountered technical meaning.

The specialist dictionary can then explain the technical concept in the depth expected by students working in that field.

This prevents General English from becoming overloaded while allowing the larger dictionary system to become more precise.

Dictionary Development Timeline

• August 2025: Development began with one planned General English dictionary.
• Later 2025: Dictionary development paused while course-specific glossaries became the priority.
• 2026: Large external word lists were investigated and rejected as the primary vocabulary source because their quality could not be trusted.
• 2026: A reusable HTML and JSON dictionary architecture was established.
• 2026: Dictionary data was divided into alphabetical JSON shards to improve loading and maintenance.
• 2026: The dictionary entry schema was standardized.
• 2026: The IPA textbook created a dedicated pronunciation-learning resource.
• August 2026: Foreign-language and specialized English dictionaries were separated into their own planned resources.
• August 17, 2026: The General English b.json shard reached 374 completed entries.

Purpose

The purpose of this work is to create a maintainable dictionary and reference system that can grow without sacrificing usability or accuracy.

The goal is not simply to accumulate the largest possible number of words. The goal is to build useful reference resources that separate everyday English from specialist terminology while connecting pronunciation, language learning, textbooks, and subject-specific study.

Lessons Learned

More content does not automatically produce a better educational resource.

Large word lists can create the appearance of completeness while introducing spelling errors, broken records, meaningless entries, and vocabulary that serves little practical purpose.

Architecture also matters as much as content. Writing thousands of dictionary definitions before determining how they should be stored and displayed creates unnecessary rework.

Finalizing the JSON schema, creating a reusable entry page, dividing data into alphabetical shards, and separating technical dictionaries from General English were necessary steps before the dictionary could scale properly.

The same lesson now applies to the textbook program: there is a point where improving existing material produces more value than simply creating more of it.