July 10, 2026

• Proceeded with converting official documentation to JSONL using the Markdown → JSONL Converter, increasing the collection from 1,180 to 1,230 items.
• Found that the multilingual translation pipeline is delayed more than expected, confirming that stabilization may take a long time.
• Tested the multilingual document synchronization pipeline in a private repo, and established the following criteria.

Document structure criteria:

• Use the Korean document as the reference document.
• Multilingual documents are placed in docs/<lang>/....
• Sub‑paths that were directly under docs/ are considered Korean reference documents and are moved under docs/ko/....
• Language codes use standard codes such as ja, zh, pt-BR rather than arbitrary codes like jp, ch.
• The root README.md remains the root document.
• Translated READMEs are also handled relative to the root.
• Ensure that modifications to README.md do not incorrectly propagate as file changes inside docs/.
• Existing language folders such as docs/en, docs/ja must not become nested like docs/ko/en.
• When testing compressed files, only extract and apply changes to README and docs.

Link and path criteria:

• Update README and internal docs links to match the target language. For example, a Korean README link docs/ko/... becomes docs/en/... in the English README.
• Relative paths between documents inside docs are also changed according to the target language.
• Keep image paths, sub‑directory links, and relative paths intact during translation/synchronization.
• Language links in the README should be presented so that users feel they are moving to or switching to the document in that language.

Automatic synchronization criteria:

• When a file is added to docs/ko, create corresponding files in the other languages.
• When a file is deleted from docs/ko, delete the corresponding files in the other languages.
• When a specific file in docs/ko is modified, only the corresponding files in other languages are regenerated.
• Do not translate the entire set from scratch each time.
• Do not re‑translate languages/files that have already succeeded.
• Do not delete successfully generated outputs even if some translations fail.
• Remove only the failed target files and regenerate them on the next run.
• Skip language folders that already match by comparing file counts or simple version files.
• Use simple version identifiers like v1 or a number rather than complex JSON/hashes.

Translation processing criteria:

• Test translations with the actual API.
• Do not use mock‑success handling.
• Determine chunk size based on the model’s official context/output limits.
• Prioritize truncating output so that the actual translation does not exceed max_tokens rather than the input context.
• Inspect each chunk immediately after translation.
• Queue any failed regions detected during the immediate post‑translation check.
• For queued failures, increase depth, split further, and re‑translate/re‑inspect.
• Avoid a structure where all chunks are combined and inspected only once at the end.

Inspection criteria:

• Verify that no Korean text remains in the translation result.
• Check that whitespace has not been lost.
• Ensure the Markdown structure is preserved.
• Confirm that code fences, links, images, and headings are retained.
• Do not judge languages like Chinese solely by length reduction.
• Read the output to ensure there are no oddities compared with the source.

Failure‑log criteria:

• Distinguish failure causes such as HTTP 429, 504, RemoteDisconnected, finish_reason=length, empty responses, etc.
• Log response headers, body, latency, model name, input size, and token usage.
• Prevent a single failure from halting the entire pipeline or deleting outputs.
• If failures repeat, analyze the cause first.

NVIDIA API usage criteria:

• Test the translation pipeline using the NVIDIA API.
• gpt-oss-120b accepts up to 128k input context, but NVIDIA API policy caps output at roughly 4,096 tokens.
• Even if large inputs can be provided, output limits may cause truncation, so set chunk size based on the 4,096‑token output limit.
• Attempt up to 40 calls per minute; if errors occur, apply back‑off and retry policies.

Hard‑coding criteria:

• Use structural rules such as docs/<lang>, markers, link regexes, and code‑fence parsing.
• Do not arbitrarily change or remove specific words.
• Do not arbitrarily remove example.com.
• Do not register each document file individually by path.
• Do not forcefully replace linguistic expressions or particular sentences/words.

Operational criteria:

• Review both GitHub Actions and Mac self‑hosted runner.
• When running on a Mac, ensure the flow automatically commits/pushes after completion.
• Provide progress visibility similar to GitHub Actions.
• Log which language/file/chunk is being processed.
• Clearly record branch name, run URL, failure cause, and current progress.

Separate from translation, I recently discovered an interesting document.

• Checked out Pollinations APIDOCS.md

• It appears you can get text responses and even generate images with a curl request without an API key.

• It seems possible to experiment lightly without worrying about creating an API key or incurring charges.

• I’ve already built something fun with it and plan to use it more before releasing it later.

• Refactored the version‑separated JSONL slot structure of the Qwen Validation Debugger

  • docs_chunks serves as code‑explanation evidence, so we keep separate slots for Godot 3 code and Godot 4 code explanations/unrelated explanations.
  • Instead of creating separate JSONL files for api_mapping and label_prototypes for Godot 3 and Godot 4, we now place both Godot 3 and Godot 4 code together to generate a 3 → 4 conversion‑evidence JSONL.
  • The expected validation value for the 3 → 4 conversion‑evidence JSONL is Yes for Godot 3 code and No for Godot 4 code.
  • The expected validation value for unrelated conversion JSONL is No for both Godot 3 and Godot 4 code.

• Retrospective: docs/retrospectives/2026-07-10.md