번역 복구

Glossia 는 게시하기 전에 번역된 콘텐츠를 검증합니다. 복구는 그 요구 사항을 보존합니다: 재시도는 여전히 소스 구조와 필요한 플레이스홀더를 보존해야 하며, 각 조립된 파일은 설정된 검증 명령을 통과해야 합니다.

마크다운 번역

Glossia 는 번역된 마크다운 문서를 다시 렌더링하지 않습니다. 소스만 파싱하여 본문(단락, 제목, 목록 항목, 표 셀, 컴포넌트 및 HTML 의사용자-facing 속성 (title, details, alt, label, description, summary, placeholder, aria-label, caption), 그리고 HTML <summary> 텍스트) 를 찾습니다. 각 번역은 소스가 차지한 바이트와 정확히 일치하는 크기로 다시 작성되므로 코드, 링크 대상, 컴포넌트, GitHub 경고, 명시적 제목 앵커 ({#install}), 목록 마커 및 빈 줄은 바이트 단위로 동일하게 유지됩니다.

각 단락 또는 제목은 전체문장으로 번역됩니다. 인라인 형식은 번호가 매겨진 태그로 변환되며: <gN>...</gN> 는 링크되거나 강조된 단어 주위에 있고, <gN/> 는 변경되지 않아야 하는 콘텐츠(예: 인라인 코드 또는 컴포넌트) 인 경우 사용됩니다. 모델은 목표 언어의 단어 순서를 따르기 위해 태그를 이동할 수 있지만, 각 태그를 정확히 한 번만 유지해야 합니다. 모든 요청은 참고를 위해 주변 소스 문서와 동일한 파일의 가장 최근 번역을 포함합니다.

태그를 떨어뜨리거나 고안하는 단위는最多 삼 번까지 이유와 함께 다시 독자적으로 전송됩니다. 유효로 돌아온 단위는 유지됩니다. 스플라이싱 후 Glossia 는 결과를 파싱하여 소스 구조와 비교합니다. 헤더, 목록, 또는 강조가 될 경우 자체 본문을 이스케이프 처리해야 하며, 이는 추가 모델 호출이 필요 없습니다.

카탈로그 번역

번역 전에 Gettext 카탈로그는 문자열로 파싱됩니다. 요청은 최대 8 개의 문자열과 8,000 바이트 배치 목표 를 포함합니다. 단일 더 긴 문자열은 그대로 유지됩니다. 모델은 동일한 수와 순서의 문자열을 갖는 배열을 반환합니다. Glossia 는 대입 변수를 확인하고 비어있는 번역을 거부합니다.

헤더는 목표 로케일의 복수 규칙을 사용하여 코드로 작성됩니다. 소스 메시지 식별자, 주석 및 카탈로그 구조는 파싱된 소스에서 나옵니다. 배치가 형식 오류 콘텐츠를 반환하는 경우 Glossia 는 한 번 재실행한 후 더 작은 배치로 나눕니다. 성공적인 인접 배치는 다시 번역할 필요가 없습니다.

제공자 속도 제한

Glossia 는 동일한 자격 증명과 모델을 사용하는 번역 요청을 조정합니다. 속도 제한 응답은 공유 쿨다운을 확장하고 새로운 요청 간의 간격을 증가시킵니다. 성공적인 트래픽은 한 분간 속도 제한 없이 간격을 서서히 줄입니다. 이미 실행 중인 요청은 완료할 수 있습니다.

제공자 재시도 힌트는 최소 지연입니다. 반복 실패는 백오프를 늘리고, 최대 30 초의 기본 지연 및 저터 Plus 가능. 더 긴 제공자 힌트는 5 분을 초과하지 않으면 우선권을 맞춥니다. Together 의 x-ratelimit-reset 헤더는 retry-after와 함께 인식됩니다.

8 차례의 실패한 요청 시도 후 레포지토리 실행은 새 파일 시작을 중단합니다. 지연된 이어짐은 번역 분지를 승계하고 미완료된 작업을 재개합니다. 이전 시도는 연결된 이어짐을 통해 세션 역사에서 가시적으로 남아있습니다. 지연은 1 분에서 5 분으로 증가하며, 최대 6 개의 자동 이어짐이 가능합니다. 최신 활성 세션이 우선권을 받으며, 취소된 세션은 다시 부활되지 않습니다. 검증 실패만으로는 제공자 복구를 예약하지 않습니다.

엔진 릴리스 후 복구

에디션: Enterprise. 이 섹션의 Kubernetes 롤아웃 확인과 엔진 릴리스 후 복구에는 격리된 번역 러너가 필요합니다. 이 페이지의 다른 섹션에서 설명하는 마크다운, 카탈로그 및 제공자 복구와 지속적인 진행 상황은 Community에서도 사용할 수 있습니다.

세션은 두 가지 독립 버전이 있습니다: 번역 중인 레포지토리 커밋과 실행하는 번역 엔진 이미지입니다. Kubernetes 에는 각 작업이 담당 웹 복제본의 정확한 이미지 디제스트를 고정합니다. 작업은 웹 롤아웃을 견디고 번역 중간에 코드를 완전히 전환하지 않습니다. 롤아웃 직전에 예약된 작업은 웹 애플리케이션이 업데이트되어도 이전 엔진에서 완료될 수 있습니다. 세션 세부사항은 엔진 디제스트를 보여줍니다; 출처가 없는 이전 세션은 “Not recorded.”을 표시합니다.

5 분마다 Glossia 는 Deploymnet 의 롤아웃 완료를 확인합니다. 오직 그 온전한 릴리스의 워커만 엔진 복구를 예약할 수 있습니다. 프로젝트의 최신 세션이 그 롤아웃이 완료되기 전에 대기 중이었, 기록된 엔진 디제스트에서 실행되고 그 후 6 시간 이내 실패한 경우, Glossia 는 현재 릴리스에서 이어짐을 생성할 수 있습니다. 대기 시간을 사용하여 용량을 기다린 후 롤아웃 후에만 부팅하는 작업을 포함합니다. 다른 이미지 디제스트만은 관련 없는 배포 후 일반 실패를 재시도하지 않습니다. 완료된 파일과 열린 번역 풀 리퀘스트는 유지되며, 미완료된 작업만 다시 번역됩니다. 대기 릴리스 이어짐은 롤아웃 진행 중 최대 15 분 동안 대기합니다. Kubernetes API 또는 권한 실패는 진행 중인 롤아웃과 혼동되지 않도록 명시적 오류로 시작을 중지합니다.

복구는 의도적으로 제한됩니다: 세션은 기록된 항목 검증 실패로 끝났으며, 마지막 시도의 모든 실패 항목은 Markdown 구조, 콘텐츠 보존 또는 Markdown 단위 실패를 보고해야 합니다. 중단되거나 부분적으로 취소된 시도는 자격이 없습니다. 제공자 오류, 고갈된 신용, 거부된 자격 증명, 게시 실패, 소스 읽기 오류, 외부 검증 명령 실패 및 알려지지 않은 원인으로는 배포에서 재시도되지 않습니다. 성공한, 활성, 취소, 대체 및 버전 없는 세션도 방치됩니다. 더 новых 세션은 항상 승리합니다, 사용자가 취소하더라도.

세션은 다른 엔진 릴리스에서 최대 1 개의 이어짐을 얻으며, 계통은 최대 3 개의 릴리스 이어짐을 갖습니다. 만약 새로운 엔진이 여전히 실패하면, 그 동일한 이미지 (롤백 포함) 에서 재시도되지 않습니다. 계통은 이전에 시도된 엔진 디제스트 를 유지하며, 런처는 예약된 작업 생성 전에 다시 확인합니다. 기존 제공자 복구 제한은 릴리스 이어짐을 통해 유지됩니다. 변경 가능한 이미지 태그 및 구성되지 않은 릴리스 식별자 없는 배포는 자동 엔진 복구를 활성화하지 않습니다.

내구성 있는 진행

완료된 파일과 해당 잠금 파일은 배치로 번역 브랜치에 게시됩니다: 25 개 파일마다 또는 15 분마다 하나의 커밋이며, 실행이 끝나면 최종 커밋입니다. 각 푸시는 저장소의 풀 리퀘스트 확인을 실행하므로, 배치는 대규모 실행이 파일당 하나의 확인 실행을 시작하는 것을 방지합니다. 프로젝트는 단일 번역 풀 리퀘스트를 갖습니다. 기본 브랜치에 대한 새로운 커밋은 열린 것을 계속하며, 이후 변경된 내용만 번역합니다. 해당 풀 리퀘스트가 병합되거나 닫히면 다음 실행은 새로운 것을 시작합니다. 미완료 파일 내에서 로컬에서 검증된 세그먼트와 복구 배치도 데이터베이스에 7 일 동안 저장됩니다. 이러한 체크포인트는 워커 프로세스가 중지되더라도 생존합니다. 이 범위는 계정, 프로젝트, 문서 입력, 유효한 자격 증명 및 모델, 컨텍스트, 그리고 세그먼트 또는 복구 시도 중 하나로 한정됩니다.

재개된 실행은 입력이 아직 일치할 때만 세그먼트를 재사용할 수 있습니다. 항상 최종 조립된 문서를 다시 검증합니다. 거부된 모델 응답은 체크포인트가 아닙니다. 문서 수준의 검증 실패는 검증기가 단일 책임 세그먼트를 식별하지 못할 수 있으므로 별도의 복구 시도를 시작합니다.

만료된 체크포인트 및 비활성화된 제공자 속도 조절 기록은 예약된 세션 복구 워커에 의해 제거됩니다. 이들은 운영 기록이므로 사용자가 이를 저장소에 추가하거나 L10N.md 에서 구성할 필요가 없습니다.