July 10, 2026 | idea_world

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 during the process

Document structure criteria:

Use the Korean document as the reference document
Multilingual documents are placed in the form docs/<lang>/...
Sub‑paths that were previously directly under docs/ are treated as Korean reference documents and 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/
Prevent existing language folders such as docs/en, docs/ja from becoming 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 docs are also changed according to the target language
Keep image paths, subdirectory 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 other languages
When a file is deleted from docs/ko, delete the corresponding files in 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 produced 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 based on file‑count comparison or a simple version file
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
Increase depth only for the queued failed regions, split them finer, then re‑translate/re‑inspect
Avoid a structure that only performs a final check after concatenating all chunks

Inspection criteria:

Verify that no Korean text remains in the translation result
Verify that whitespace has not been lost
Verify that the Markdown structure is preserved
Verify that code fences, links, images, and headings are preserved
Do not judge languages that shrink in length (e.g., Chinese) solely by length comparison
Read the output to ensure there are no oddities compared to the original

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 produced outputs
If failures repeat, analyze the cause first

NVIDIA API usage criteria:

Test the translation pipeline based on the NVIDIA API
gpt-oss-120b supports up to 128k input context, but NVIDIA API policy limits output to roughly 4,096 tokens
Even if large inputs can be provided, output limits may cause truncation, so the practical chunk size is based on the 4,096‑token output limit
Attempt up to 40 calls per minute, and apply wait/retry policies on errors

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 specific sentences/words

Operation criteria:

Review both GitHub Actions and Mac self‑hosted runner
When running on 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 being billed
I tried building something fun with it and plan to share more after further use
Reorganized the version‑separated JSONL slot structure of the Qwen Validation Debugger
- docs_chunks is a code‑explanation basis, so 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 only or Godot 4 only, combine Godot 3 and Godot 4 code into a single 3 → 4 conversion‑basis JSONL
- The validation expected value for the 3 → 4 conversion‑basis JSONL is set to “yes” for Godot 3 code and “no” for Godot 4 code
- The validation expected value for unrelated conversion JSONL is set to “no” for both Godot 3 and Godot 4 code
Retrospective: docs/retrospectives/2026-07-10.md