지속적 배포로 다국어 사이트 만들기 • 언어 및 무료 소프트웨어

내 경험

소프트웨어는 번역 가능한 경우가 많습니다. 개발자들이 그러한 노력의 유용성을 인식하고 있기 때문입니다.

운이 좋다면 Weblate와 같은 고품질 번역 플랫폼이 사용되어, 소프트웨어의 변경 사항이 자연스럽게 번역자에게 전달되고 번역이 저장소로 돌아옵니다.

소프트웨어는 빙산의 일각으로, 우리가 직접 사용하는 것입니다. 하지만 소프트웨어를 소개하는 주변 자료 없이 모든 커뮤니케이션이 영어로만 이루어진다면 널리 알리기 어렵습니다. 소프트웨어의 기능, 용도, 사용 방법 등에 대한 설명이 필요합니다.

웹사이트는 프로젝트 커뮤니케이션의 기반으로, 번역 가능한 경우가 많습니다. 웹사이트를 만드는 기술 스택은 상대적으로 표준화되어 있지 않으며, 다양한 콘텐츠를 만들기 위한 제작자의 맞춤화 요구에 영향을 받습니다. 이는 몇 가지 HTML 태그를 통해 가능합니다.

문서화는 독자적인 영역으로, 사용되는 도구는 흔히 개발 생태계(기술 문서)나 협업 생태계(위키)에서 비롯됩니다. 이러한 도구가 협업을 가능하게 하는 국제화 전제 조건을 제공하는 경우는 꽤 드뭅니다. 하지만 이 문제는 웹사이트의 경우와 매우 유사합니다.

마지막으로, 새 버전의 변경 사항부터 소셜 미디어를 통한 도구 홍보까지 더 직접적인 커뮤니케이션은 다국어로 이루어지는 경우가 드뭅니다.

왜 적은 수의 사이트만 번역 가능한가?

양호한 수준의 번역을 위해서는 개발 노력과 복잡도를 줄이는 소프트웨어 국제화 기능과, 번역자가 원활하게 참여할 수 있는 프로세스가 필요합니다.

웹사이트 국제화의 필수 조건:

오른쪽에서 왼쪽으로 쓰는 문자 지원
내부 링크를 수정하지 않고 다국어로 콘텐츠를 게시할 수 있어야 함
어떤 페이지에서든 언어를 변경할 수 있어야 함
Accept-Language 헤더를 처리하여 올바른 언어로 안내해야 함
전 세계 모든 언어와 문자 체계를 허용해야 함

듣기엔 범위가 넓고 인상적이지만, UTF-8 같은 표준, 몇 가지 HTML 태그, 그리고 이러한 요구를 고려한 도구를 사용하면 꽤 쉽게 실현할 수 있습니다.

개발자가 사용하는 도구에는 쉽게 국제화를 할 수 있는 기능이 포함되어 있어야 합니다. 이를 국제화라고 합니다. 도구의 문서에 다국어 예제나 국제화 전용 섹션이 없다면, 피하세요. 반드시 더 좋은 대안이 있습니다.

협업의 전제 조건: 개발자들은 번역자의 작업을 간편하게 해주는 도구를 알고 쉽게 사용할 수 있어야 합니다.

번역자는 소스 코드나 소프트웨어 저장소에 접근하지 않고도 번역할 수 있어야 합니다.
번역자는 허가 없이도 자신의 언어를 추가할 수 있어야 합니다.
번역자는 허가 없이도 번역을 수정할 수 있어야 합니다.
번역자는 번역 관련 변경 사항에 대한 알림을 받을 수 있어야 합니다.
번역은 사람의 개입 없이 자동으로 배포되어야 합니다.
개발팀은 문제가 발생했을 때 쉽게 연락할 수 있어야 합니다 (자율성 ≠ 고립)

정적 사이트 생성 도구 올바르게 선택하기

여기서는 파일로부터 사이트를 생성하는 도구만 다루겠습니다. 동적 사이트는 대부분의 자유 소프트웨어 프로젝트에 불필요한 특수한 복잡성입니다. 유지보수 작업, 비용, 보안 위험을 줄이기 위해 과감히 생략할 수 있는 불필요한 복잡성입니다.

개발 전문 지식 없이도, 다음 세 가지 도구를 비교해 봅시다:

Hugo는 다국어 게시에 관한 페이지가 있습니다. 완전하고 예제를 제공하며, 이 프로젝트에 중요합니다 ⇒ 사용해 보세요 <3
Jekyll에는 국제화에 관한 페이지가 없습니다. 플러그인 사용과 그에 따른 호환성/수동 조작 제약을 감수해야 합니다 ⇒ 피하세요!
Eleventy에는 국제화 페이지가 있습니다. 가능해 보이지만 매우 수동적이어서 신뢰가 가지 않습니다 ⇒ 피하세요!
Pelican은 기사 번역만 다룹니다. 국제화 전용 페이지가 없으며, 미미한 기능만으로는 충분하지 않습니다 ⇒ 피하세요!
Publii에는 국제화 페이지가 없습니다 ⇒ 피하세요!

고민은 짧아도 됩니다: 다국어로 바로 사용할 수 있는 정적 사이트를 원하시나요? Hugo를 사용하세요.

이것은 Pelican이나 Jekyll에 대한 개인적인 감정이 아닙니다. Hugo보다 기능이 적을 뿐 아니라, 번역할 파일의 헤더를 수정해야 한다는 전제 조건만으로도 자동화에 있어 번거로운 단계입니다. 그런데 목표는 가능한 한 적은 작업으로 모든 것을 자동화하는 것입니다! 이러한 도구로 올바르게 국제화하는 프로젝트들도 있지만, 더 많은 노력이 필요하면서도 아마 더 적은 기능을 제공할 것입니다 (예를 들어, URL이 번역되지 않고 영어로 유지됩니다).

사례 연구 - 이 블로그

실제 데이터로 이 자동화 작업을 구체적으로 수행하기 위해, 다음은 제가 정한 요구 사항입니다:

원본 언어의 기사에 어떠한 수정도 필요하지 않아야 함
번역 플랫폼으로 Weblate 사용
새 기사를 추가하기 위해 Weblate에서 설정할 필요가 없어야 함
언어를 추가하기 위해 Hugo에서 설정할 필요가 없어야 함
완전 자동화된 게시

수행한 단계는 간단합니다.

만족스러운 콘텐츠 구조 찾기

content/fr에 사이트의 모든 콘텐츠가 포함됩니다
l10n/에 모든 번역 파일이 포함됩니다
l10n/config에 Hugo 설정 번역 관련 번역할 문자열이 포함됩니다
l10n/pot에 번역 모델(POT 파일)이 포함됩니다
l10n/po/%lang%에 각 언어별 번역(PO 파일)이 포함됩니다

po4a 형식 변환기가 콘텐츠를 번역 모델(POT 파일)로 변환합니다.

Python 스크립트가 polib을 호출하여 최소 80% 이상 번역된 기사가 하나 이상 있는 언어를 식별합니다 (원본 단어 대비 번역된 비율).

다른 Python 스크립트가 번역할 설정들(블로그 이름, 블로그 설명 등)을 사용하여 Hugo 설정을 업데이트합니다.

이것은 투박하지만 작동하는 방식이며, 이 도구를 간소화하기 위해 여러 가지를 개선할 수 있습니다. 하위 명령을 호출하는 대신 po4a 설정을 사용하고, polib 사용을 제거하여 Python 파일 하나만으로 구성할 수 있습니다.

Weblate의 Markdown 지원을 왜 사용하지 않을까요? Weblate는 번역 플랫폼이고, 파일 형식 변환은 다른 역할입니다. 전용 도구가 Weblate보다 이 작업을 더 잘 수행하며, 책임을 분리하면 의존성이 줄어들어 자동화 체인을 발전시킬 수 있는 자율성이 높아집니다. 대표적인 예: po4a는 다른 도구로 대체할 수 있습니다.

결과와 교훈

우리 자유 소프트웨어 커뮤니티는 매우 쉽게 다국어 사이트를 만들 수 있습니다.

하지만 기존 도구를 어떻게 조합하여 완전한 프로덕션 체인을 구축하는지 설명하는 문서가 부족합니다.

이 글은 이러한 공백을 메우고, 관심 있는 프로젝트에서 이 방식을 복사하도록 장려하는 것을 목표로 합니다.

이 도구는 개선되고 간소화되어, 재사용을 극대화하기 위해 작동 방식을 설명하는 전용 프로젝트에 저장될 것입니다. 현재는 languages-in-floss 사이트의 git 저장소에서 몇 가지 스크립트를 찾아볼 수 있습니다.