RH26-Songlist: The README That Turns a Fan Catalog Into a Database
A tiny Markdown repo quietly solves bilingual mapping, version tracking, and future event planning for JKT48 Request Hour 2026.
- RH26-Songlist treats a song catalog as reference infrastructure, not as a casual playlist.
- The visible row order is only presentation, while the RHS codes behave like stable primary keys.
- Bilingual titles make the README useful for lookup, voting, and future tooling across languages.
- GitHub is the right home here because transparency, diffs, and human readability matter more than app polish.
Not a Song List, a Reference System
The surprise in RH26-Songlist is not that it lists songs. It is that the list behaves like infrastructure. The README is doing three jobs at once: it is the catalog, the interface, and the canonical record.
That matters because this is not a static playlist. It is a fan-built registry for JKT48 Request Hour 2026, where songs need durable identifiers, bilingual names, and links that can survive reorderings and later reuse.
| Kode | Judul (ID) | Judul (JP) | YouTube URL | | :--- | :--- | :--- | :--- | :--- | | 1 | RHS403 | #KuSangatSuka | #Sukinanda | Link | | 2 | RHS1 | 1!
How the README Works Like a Database
The table in the README has five fields: display number, code, Indonesian title, Japanese title, and YouTube URL. That looks simple, but it is already a schema. The row number helps humans scan the list. The code anchors identity.
| No. | Kode | Judul (ID) | Judul (JP) | YouTube URL |
| :-- | :----- | :------------------- | :----------- | :---------- |
| 1 | RHS403 | #KuSangatSuka | #Sukinanda | Link |
| 2 | RHS1 | 1! | 1! | Link |The visible order can change. The code is the durable identity. That split is why the README can be reordered for readers without breaking references for tools or future editors.
Why the Codes Matter More Than the Order
| Dimension | README approach | Conventional app or database approach |
|---|---|---|
| Setup cost | One Markdown file in GitHub | Schema, backend, and UI work |
| Human readability | Immediate in the browser | Often hidden behind an interface |
| Machine parsing | Simple table parsing | Structured but heavier plumbing |
| Edit workflow | Pull request or direct edit | Admin screens or migrations |
| Version history | Native Git diff | Depends on application logs |
| Trust and transparency | Fully inspectable text | Requires faith in the system |
| Maintenance overhead | Very low | Higher, especially for a niche catalog |
| Fit for a fan reference | Excellent | Often overbuilt for the job |
The strange-looking codes are the point. RHS403 can sit next to RHS1 because the repository is not trying to number songs in a neat sequence. It is trying to preserve identity across edits, sorting choices, and future additions.
That is a database instinct hiding inside a README. The list is optimized for stable references, not for aesthetic numbering.
Bilingual Mapping Is the Real Product
The practical value is not just that the catalog is readable. It is that one song can be found through multiple naming systems. Indonesian titles and Japanese titles live side by side, so a fan can cross-check a song no matter which label they know first.
| Lookup need | What the README gives | Why it matters |
|---|---|---|
| Local fan search | Judul (ID) | Fast recognition in the community language |
| Original title lookup | Judul (JP) | Matches the source naming system |
| Voting or setlist tooling | Shared code | One stable reference across both titles |
| External confirmation | YouTube URL | A direct path to the performance |
That cross-linking turns a plain list into a reference layer. The repository becomes useful not only to readers, but also to anyone building a fan tool later.
Versioning the Music Like Software
The "New Era" suffix is more than a label. It is a version marker for cultural assets. The repo needs to keep originals and re-recordings separate without pretending they are the same thing.
| Question | Simple list | RH26-Songlist |
|---|---|---|
| Are variants distinct? | Often merged by name | Yes, by entry and code |
| Can the same song be reused? | Not cleanly | Yes, without identity loss |
| Does version history survive? | Weak | Strong through Git and codes |
| Does the catalog explain itself? | Sometimes | Yes, directly in the table |
That is why the project feels more like software design than fandom paperwork. It is managing change without erasing provenance.
Why GitHub Is the Right Home for This
GitHub gives the repository what a small community catalog needs most: transparency, history, and a place where anyone can read the source of truth without logging into a separate app. A custom backend would add polish, but also friction.
| Workflow | GitHub README | Conventional app |
|---|---|---|
| Read the catalog | Open the repo | Load the app |
| Edit an entry | Change text in a pull request | Use admin tooling or a form |
| Review changes | Diff the Markdown | Inspect records through an interface |
| Trust the source | Directly visible | Indirect |
| Scale for this use case | Enough | Likely unnecessary |
The lack of scripts is not a weakness. It is a design choice that keeps the system legible to the people who actually maintain it.
The Next Logical Step
The current form is already useful because it is both human-readable and machine-friendly. If the project later grows into CSV, JSON, or a small app, that will be an export decision, not a rescue mission.
For now, the README does the important work. It establishes a canonical reference for the RH26 song set, and it does so in a format the community can inspect, edit, and trust.
