변경 이력

도구가 실제 레포지토리를 처음 마주칠 때 배우는 것이 많습니다. 우리에게 그 대상은 Tuist 였습니다. 그들의 팀은 하루에 main 에 여러 번 병합했고, Glossia 는 우리가 구축한 대로 정확히 역할을 수행했습니다: 모든 변경 사항을 번역하고 각 파일이 준비되자마자 푸시했습니다. 그 결과 거의 모든 병합마다 새로운 풀 리퀘스트가 생성되었고, 각각 약 150 개의 커밋이 따랐으며, 아무도 요청하지 않은 검토 사항들이 CI 큐에 가득했습니다. 그들의 문서 페이지 중 일부는 컴포넌트와 경고가 평문으로 유출된 채로 돌아왔습니다. 우리가 계속 언급했던, 조용하고 배경 처리와 같은 경험이 아니었습니다.

그건 우리를 아프게 했습니다. 항상 최고의 번역 시스템은 생각할 필요가 없는 시스템이라고 말해왔기 때문입니다. CI 를 물들이거나 문서를 망가뜨리는 풀 리퀘스트는 그 반대입니다. 그래서 우리는 번역이 레포지토리에 도달하는 방식을 다시 한 번 재고했습니다.

Glossia 는 이제 프로젝트 당 하나의 풀 리퀘스트를 유지하며 콘텐츠가 변경됨에 따라 이를 확장합니다. 이미 해당 브랜치에 있는 lock 파일을 읽음이므로, 새로운 부분만 번역하며 파일을 파일별로 푸시하는 대신 배치 단위로 푸시합니다. Tuist 같은 레포지토리의 경우, 예전엔 150 건의 푸시로 이루어져 있던 것이 이제는 단지 몇 차례에 불과합니다.

우리는 또한 님의 문서 중 건드리지 않아야 할 부분을 건드리지 않았습니다. Glossia 는 예전부터 번역한 모든 페이지를 다시 구축했는데, 완벽히 이해하지 못한 부분 (Phoenix 컴포넌트나 GitHub 경고 등) 은 번역 결과에서 평문으로 유출된 채로 나타날 수 있었습니다. 이제 번역된 문장만 교체하고 나머지는 작성하신 대로 정확히 그대로 둡니다. 예상치 못했던 좋은 부수효과도 있었습니다: 모델이 이제 전체 문장과 페이지의 나머지 부분을 보게 되어 번역이 더 잘 읽힙니다. 일본어의 경우 링크는 더 이상 영어 문장에서처럼 어색한 위치를 차지하지 않아도 됩니다.

마지막으로, 풀 리퀘스트는 이제 일어난 일을 말씀해 드립니다. 어떤 언어와 파일이 번역되었는지, 어떤 커밋에서 이루어졌는지, 점수가 어떻게 되었는지, 어떤 사전 용어가 이를 형성했는지, 그리고 그중审阅 요청을 요청 전 에 주의해야 할 사항이 있다면 무엇인지. 우리는 이를 신중한 동료께서 리뷰 요청 전에 당신에게 남겨 놓은 메모로 생각합니다.

나머지 해결하는 과정에서 Tuist 팀의 인내에 감사드립니다. Glossia 가 이처럼 여러분의 일을 방해하는 일이 발생한다면, 그 이야기를 듣는 것이 좋겠습니다.