Imagine reading “price correction” in an arcade’s history. You know a price changed, but still have to find which game and what the old and new prices were. As collaborative editing grew, short author descriptions became insufficient for this work. In March, we changed history to include differences calculated from the data before and after an edit.

Edit descriptions and actual changes

An edit description is useful for explaining a reason. A brief “information update,” however, may omit that the cabinet count changed along with the price. Without a description, a reader must find the difference in the resulting data. The information available for review depended on how thoroughly each editor wrote.

The earlier ticket display combined the label “Installed games section edit” with the author’s explanation. Readers still had to inspect the data to identify individual changes. Original Korean capture with English annotations.

Operators are not the only readers of history. Someone checking an arcade’s recent condition also needs to know which entries changed. The before and after values remain the same regardless of the description’s language or length, so we decided to produce that comparison in the service itself.

Field comparisons and item additions or removals

The comparison units are fields with defined meanings, such as name or address, and collections of items, such as installed games. We had already separated basic information, hours and games, with the arcade referencing its current values. Both earlier and resulting states were available to read and compare.

flowchart TD
    accTitle: Gaps in reviewing only an edit description
    accDescr: A short edit description still leaves the reviewer to find which items and before-and-after values changed.
    A[Short edit description] --> B[Can infer the changed area]
    B --> C[Inspect the actual data again]
    C --> D[Find changed items and values]

For example, changing a game count from two to three preserves that game and both counts in history. Fields record changed values, while collections distinguish additions, modifications and deletions. Even if the author omits the count change from the explanation, the data difference remains visible.

flowchart LR
    accTitle: Deriving changes from before and after
    accDescr: Compare before-and-after data to build structured history of field changes and item additions, modifications, and removals.
    P[Data before edit] --> C[Compare fields and items]
    N[Data after edit] --> C
    C --> F[Previous and next field values]
    C --> I[Item additions, changes, removals]
    F --> H[One change-history entry]
    I --> H

Presenting history in multiple languages

When applying an edit, the server connects the earlier and next states of the affected area. It compares names and addresses by field and game collections by item. Unchanged values are not listed as new changes; history concentrates on the differences.

The revised history groups differences in the before-and-after data as additions, modifications, and removals. Original English capture.

The interface groups areas and items and shows their before and after values. Storing the comparison as data and generating its explanation in the interface language lets Korean, English and Japanese readers inspect the same edit. It does not require translating a free-form explanation or extracting facts from it.

flowchart TD
    accTitle: Presenting the same changes in several languages
    accDescr: The same server-generated change data gets different descriptions for each interface language, while previous and next values stay the same.
    D[Structured change data] --> K[Korean description]
    D --> E[English description]
    D --> J[Japanese description]
    K --> V[Review previous and next values]
    E --> V
    J --> V

Reviewing changes and restoring earlier states

A short description can now be checked against the actual differences. Even when several games change together, reviewers can inspect added, modified and removed items separately. Earlier data also helps determine which part to restore when a change is wrong.

A comparison does not establish that a price or address is correct on site. That still requires supporting information, and the system cannot summarize every meaning in free text. Changes to the data structure also require changes to comparison and presentation. Reducing the work of finding differences leaves reviewers better able to examine whether the values are right.

Related history: Musecat’s development