Overview

iGEM Wikis require detailed documentation of all project activities. However, given the limited timeframe of one to two years for iGEM projects, beginning Wiki writing early poses significant challenges. Additionally, the coding process required for Wiki development can be quite challenging for beginners on the team. Furthermore, meeting iGEM’s evaluation criteria (e.g., image format specifications and GitLab upload requirements) is mandatory, yet human errors such as overlooking requirements can occur. To address these obstacles in writing and submission, we developed two integrated systems. Those systems are 1: The Editor, and 2: The Submission System. The Editor reduces the difficulty of Wiki writing, while the Submission System minimizes the risk of overlooking requirements. These systems enable iGEM members to submit their Wikis more easily and reliably, allowing them to allocate more time to enhancing content quality.

Wiki Submission System

iGEM Wiki submission involves multiple complex requirements that present both technical and time-related challenges. Basic HTML files must be submitted as GitLab artifacts, while all other files must be uploaded to a dedicated CDN. When using modern build tools such as Astro or React, the submission process becomes even more challenging, as files must be manually transformed to comply with iGEM-specified formats.

Our team chose Astro, a powerful static site builder, to construct our Wiki with high performance and security. Astro optimizes images, CSS, and JavaScript to generate lightweight and secure sites. This approach prevents rendering issues and ensures reliable Wiki display across all user environments. Given the critical importance of Wikis in iGEM competition evaluation, we adopted a strategy of embedding fundamental content directly into HTML to avoid frontend rendering complications.

However, this approach presented several challenges:

• Manual Upload Burden: Manually uploading Astro-generated files to GitLab and the CDN proved extremely time-consuming. With team roles highly specialized and Wikis requiring frequent updates, this manual process was impractical.

• iGEM CDN Specifications: The iGEM CDN had several problematic specifications:

  • Automatic conversion of images to WebP format.

  • Occasional failures in SVG file uploads (resolved by removing XML headers).

  • Forced conversion of filenames to lowercase.

  • Inability to upload or delete folders.

Additionally, the URL structure issued from GitLab artifacts (https://2025.igem.wiki/{team-name}) created significant routing difficulties.

Automation Through Custom Tool Development

To resolve these challenges, we developed a custom tool that automatically builds the Wiki, analyzes generated files, transforms them into CDN-optimized formats, and uploads them automatically.

This system initiates the entire process through a single button click in the editor.

1. Markdown Retrieval and Sanitization: First, we retrieve all Markdown files from the editor using Prisma and escape potentially dangerous characters.

function sanitizeMDX(text, slug) {
  if (!text) return "";

  // iframe/details/summary を先に保護
  const safeTags = [];
  text = text.replace(
    /<(iframe|details|summary)([\s\S]*?)(?:<\/\1>|\/>)/gi,
    (match) => {
      // ✅ iframe内の src="<https://...>" を src="https://..." に修正
      if (/^<iframe/i.test(match)) {
        match = match.replace(
          /\s+src=["']<([^>]+)>["']/i,
          (m, url) => ` src="${url}"`
        );
      }
      safeTags.push(match);
      return `__SAFE_TAG_${safeTags.length - 1}__`;
    }
  );

  // HTMLエンティティをデコード
  text = he.decode(text);

  // "**Word: **Text" → "**Word:** Text" に補正
  text = text.replace(/\*\*([^\*]+?):\s\*\*(\S)/g, "**$1:** $2");

  // KaTeX 数式部分を分離して通常テキストのみエスケープ
  const parts = text.split(/(\$\$[\s\S]+?\$\$|\$[^\$]+\$)/g);

  const sanitized = parts
    .map((part) => {
      if (part.startsWith("$")) return part;
      if (/__SAFE_TAG_\d+__/.test(part)) return part;

      return part
        .replace(/&/g, "&amp;")
        .replace(/</g, "&lt;")
        .replace(/>/g, ">")
        .replace(/{/g, "{")
        .replace(/}/g, "}")
        .replace(/~/g, "~"); // ← Escape tilde
    })
    .join("");

  // 保護タグを復元
  const restored = sanitized.replace(
    /__SAFE_TAG_(\d+)__/g,
    (_, idx) => safeTags[idx]
  );

  // 制御文字チェック
  const dangerousPattern = /[\x00-\x08\x0B\x0C\x0E-\x1F]/;
  if (dangerousPattern.test(restored)) {
    console.warn(`⚠️ Dangerous characters detected in post slug="${slug}"`);
  }

  return restored;
}

2. Astro Build: Next, we build the site with Astro. To prevent CDN loading issues, all filenames are converted to lowercase during output.

3. Link Verification: We verify that no unauthorized external links are present. Since iGEM Wikis must contain only approved links, Discord warnings are triggered when unauthorized links are detected.

4. File Conversion and Analysis: We analyze built files and execute the following processes:

   • Parse files linked from HTML and store them in CDN upload folders.

   • Rename files to numeric identifiers.

   • Update file references in HTML to reflect new names.

   • Remove XML headers from SVG files.

   • Change image file extensions (PNG, JPEG, etc.) to .webp (without actual format conversion, relying on CDN automatic conversion).

5. CDN Upload: Transformed files are uploaded to the CDN. This requires technical implementation including session acquisition, folder creation, and sequential file uploads. Individual API information was obtained through browser developer tools.

const baseHeaders = { Origin: "https://accounts.igem.org", Referer: "https://accounts.igem.org/", "User-Agent": "Mozilla/5.0", Accept: "/", };

6. GitLab Push: Finally, HTML files are pushed to GitLab, completing the process.

These automated cycles execute entirely on GitHub Actions, allowing developers and writers to easily trigger these functions through APIs or UI. This robust system significantly streamlined our Wiki submission process and achieved stable operation.

Editor

The iGEM TSUKUBA Editor is a rich-text editor designed for teams to provide a seamless experience from writing to publication. Even members unfamiliar with Markdown syntax or tool usage can edit content visually and proceed smoothly from preview to publication. Real-time collaborative editing reduces the overhead of comment exchanges and merge conflicts, eliminating the typical bottleneck of struggling with technical systems before refining content.

Additionally, addressing the challenge faced by Japanese teams of English language requirements, we integrated a workflow that accurately extracts text and translates it using AI. This enables reliable translation of content while preserving layouts including headings and tables. Consequently, reducing the person-dependency of translation work ensures quality assurance.

Furthermore, centralizing articles on a single platform ensures traceability of who edited what and when, and guarantees thorough pre-publication checks. This eliminates fragmentation in the workflow from writing to publication, enabling end-to-end task completion.

Technology Stack

We adopted the following technology stack:

Frontend

• Next.js

• TypeScript

• NextAuth

• shadcn

• BlockNote

Backend

• Prisma

• Neon

• Cloudinary

• PartyKit

• OpenAI API

Deployment

• Vercel

• GitHub Actions

The frontend was built using Next.js and TypeScript. For authentication, we implemented NextAuth with email verification and Google login. The UI library shadcn was adopted for modern design aesthetics. For the rich-text editor, we used BlockNote to achieve WYSIWYG (What You See Is What You Get) functionality.

The backend was constructed using Neon and Prisma. For storage, we adopted Cloudinary to achieve cost efficiency. Real-time collaborative editing was implemented using PartyKit with WebSocket communication. Additionally, we utilized the OpenAI API to automatically translate written content.

Vercel was used for deployment.

Features

The following features have been implemented:

Article Editor

This feature provides a comfortable rich-text editor for writers.

The following implementations are available:

• Text: Paragraphs, headings

• Lists: Bulleted lists, numbered lists, checklists

• Blocks: Quotes, code, tables

• Formatting: Color, bold, italic, underline, strikethrough, highlight, links, indentation

• Media: Images, videos, audio, files

• Other: Mathematical expressions, emojis

The editor supports real-time collaborative editing, allowing multiple writers to work simultaneously.

Below is a screenshot of the actual article editor interface:

Article List

This feature provides a table view where articles written by multiple authors are visible at a glance.

The following implementations are available:

• Article Information: Article name, content, creation date, update date, editors

• Article Search: Search by article name

• Article Operations: Adding and deleting articles

Each article corresponds to a specific Wiki endpoint.

Below is a screenshot of the actual article list interface:

Article Translation

This feature provides an editor for AI-based translation and proofreading of written articles.

The following implementations are available:

• AI Translation: English translation using OpenAI API

• Markdown Display: Display of written article Markdown

• Preview Display: Preview display of written articles

Here, we explain the mechanism of translation using the OpenAI API.

Directly submitting Markdown to the OpenAI API as a prompt results in layout corruption. This occurs because Markdown uses symbols (# and *) to mark up text. Therefore, only text must be translated.

The actual translation workflow is as follows:

1. Markdown Decomposition: Convert Markdown to an Abstract Syntax Tree (AST)

2. Text Extraction: Extract only text from the converted AST while preserving order

3. Text Translation: Translate extracted text sequentially using OpenAI API

4. Text Injection: Inject translated text by traversing the same AST

5. Markdown Assembly: Convert AST back to Markdown

Below is a screenshot of the actual article translation interface:

User Settings

This feature provides settings for comfortable usage, including profiles and notifications.

The following implementations are available:

• Profile: Icon, username, theme color

• Push Notifications: Article creation, article updates, article deletion

• Security: User role modifications

Below is a screenshot of the actual profile settings interface:

Below is a screenshot of the actual push notification interface:

Summary

For our team with limited engineering expertise, Wiki submission itself presented long-standing psychological and operational barriers. Article review, styling, and management all posed significant challenges for inexperienced members, with struggling with technical systems before writing content being commonplace. Errors discovered immediately before publication required corrections and resubmissions, causing delays.

Since implementing the iGEM TSUKUBA Editor, the workflow from writing through translation, preview, and publication has been unified, enabling even non-engineer members to proceed without confusion. Direct on-screen editing with immediate preview capability dramatically reduced time spent struggling with layouts. Consequently, we could focus on content quality itself, with visible reductions in review iterations and pre-publication revisions.

This editor shifted our focus from constructing the Wiki to communicating through it. The reduced pre-deadline chaos and increased accessibility for members to contribute their expertise in writing, proofreading, and translation were tangible benefits experienced throughout competition preparation. iGEM TSUKUBA confirmed this tool’s utility through actual deployment. If your team faces similar challenges, consider using this documentation as a foundation for implementation. It should reduce preparation stress and enable more time devoted to content quality.