WPML의 페이지 빌더 번역 지원 예정

이틀 전 저희는 페이지 빌더로 디자인된 사이트를 어떻게 번역하고 싶은지에 대한 설문조사를 진행했습니다. 이 글에서는 그 결과를 공유하고, 이것이 향후 WPML 3.6 개발에 어떤 영향을 미칠지 알려드리고자 합니다.

배경 – 현재 페이지 빌더로 제작된 사이트의 번역 권장 방식

Toolset Layouts를 제외한 모든 페이지 빌더의 경우, 현재 번역할 수 있는 유일한 방법은 언어별로 별도의 디자인을 만드는 것입니다.

이 방법도 사용할 수는 있지만 그다지 편리하지는 않습니다. 한 번만 디자인한 다음 WPML로 텍스트만 번역하는 것이 더 쉬울 것이라고 생각합니다. 참고로, 현재 레이아웃을 포함하여 Toolset의 모든 항목을 번역하는 방법에 대한 문서를 작성 중입니다. 준비가 되면 이에 대해 다시 글을 올리겠습니다.

질문: 페이지 빌더로 생성된 콘텐츠를 번역하는 현재 방식에 만족하십니까?

일부 사용자는 언어별로 별도로 디자인하는 것을 선호하기도 합니다. 전체 디자인을 수정해야 할 때는 이 방식이 합리적입니다. 사이트 홈페이지에 매우 정교한 디자인이 적용되어 있다면 언어별로 수정하고 최적화하는 것이 타당할 것입니다.

대부분의 사용자는 현재 방식에 만족하지만, 하나의 디자인을 유지하면서 WPML로 번역하는 것을 더 선호합니다. 반면 이 방식이 유용하지 않다고 답한 분들도 있습니다. 아마도 번역 서비스 업체를 이용하는 분들일 것입니다. 외부 번역가에게 페이지 빌더 디자인을 수정해 달라고 요청하는 것은 거의 불가능하다는 점에 동의합니다. 저희도 여러 번역 서비스 업체와 WPML을 통합할 때 이러한 문제에 직면한 적이 있습니다.

질문: 어떤 페이지 빌더를 자주 사용하십니까?

페이지 빌더를 사용하는 사이트의 약 60%가 Visual Composer를 사용합니다. 그다음으로 인기 있는 빌더는 Divi와 Avada입니다. 다른 빌더들도 꽤 인기가 있습니다.

번역 프로세스는 어떻게 진행됩니까?

저희는 이미 Layouts 플러그인과 이를 완벽하게 통합하여 작동시키고 있으므로(문서는 아직 "작성 중"이지만), Layouts를 예로 들어 설명하겠습니다.

1단계) 페이지 빌더에서 디자인

앞서 설명했듯이 페이지 빌더에서 한 번만 디자인하면 됩니다. 모든 번역에 동일한 디자인이 사용됩니다.

2단계) 번역에 보내기

페이지에서 페이지 빌더를 사용하는 경우 "두 번" 번역해야 합니다. 첫 번째는 페이지 제목과 사용 중인 모든 사용자 정의 필드를 포함하는 페이지 자체입니다. 두 번째는 페이지 빌더 디자인입니다. 다소 번거로울 수 있다는 점을 알고 있습니다. 이를 자동화하기 위해 노력할 것이지만, 아마도 첫 번째 릴리스에는 포함되지 않을 것입니다.

WPML->번역 관리로 이동합니다. 여기서 페이지 빌더 디자인을 위한 새로운 콘텐츠 유형을 볼 수 있습니다. 번역할 디자인을 선택하고 번역에 보냅니다. 사이트의 여러 요소를 살펴보고 번역 바구니에 추가할 수 있습니다. 번역할 항목을 모두 담았다면 WPML->번역 관리->번역 바구니로 이동하여 모든 항목을 한 번에 일괄 전송합니다. 로컬에서(WPML의 번역 에디터 사용) 직접 번역하거나 선호하는 번역 서비스 업체에 외부 번역을 맡길 수 있습니다.

3단계) 번역

디자인에 속한 모든 텍스트가 나란히 표시됩니다. 구조는 번역하지 않고 텍스트만 번역합니다. 번역을 수행하고 각 필드를 "완료"로 표시하세요. 저장하면 번역이 페이지 빌더 디자인에 자동으로 적용됩니다.

4단계) 프런트엔드에서 결과 확인

콘텐츠를 조회하면 번역이 프런트엔드에 표시됩니다. 번역은 페이지 빌더 자체를 변경하지 않으므로 페이지 빌더 내에서는 번역을 볼 수 없습니다.

5단계) 디자인 업데이트 시 번역 업데이트

페이지 빌더에서 디자인을 편집한 경우 번역 대시보드로 이동하여 번역에 다시 보내세요. 수정된 텍스트만 번역 항목으로 표시됩니다.

WPML과 페이지 빌더 번역 통합 로드맵

저희는 Visual Composer와의 통합부터 시작하고 있는데, 안타깝게도 이 빌더는 통합하기에 가장 까다롭습니다. VC는 디자인을 "콘텐츠" 내부의 숏코드로 저장합니다. 숏코드에는 ID가 없으므로 요소와 해당 텍스트를 연결하기가 어렵습니다. 저희는 셀에 ID를 추가하기 위해 VC 개발자와 협력할 예정입니다. 어쨌든 콘텐츠에 따라 문자열을 식별하는 대체 방법을 사용할 것입니다. 즉, 텍스트가 변경되면 셀을 편집하기 전의 텍스트가 무엇인지 알 수 있는 방법이 없으므로 처음부터 다시 번역해야 합니다. VC 셀에 ID를 추가하기 위해 최선을 다하겠지만, 이 부분이 전적으로 저희 권한에 있는 것은 아니라는 점을 이해해 주시기 바랍니다.

다른 페이지 빌더는 다르게 작동합니다. 빌더 디자인을 "콘텐츠"와 별도로 저장하며 셀에는 고유한 식별자가 있습니다. 따라서 셀을 편집할 때 이전 번역을 확인하고 업데이트만 하면 됩니다.

WPML 3.6에는 Visual Composer 지원이 확실히 포함될 것입니다. Divi 지원도 포함하도록 노력하겠습니다. 또한 이번 릴리스 주기의 일환으로 페이지 빌더에서 번역할 문자열을 등록하는 방법에 대한 자세한 문서도 작성할 예정입니다. 과정은 꽤 간단하며, 제대로 문서화하기만 하면 됩니다.

그런 다음 다른 모든 페이지 빌더 개발자와 협력하여 해당 제품에 이러한 지원을 통합할 것입니다.

피드백이 있으신가요?

어떻게 생각하시나요? 다른 페이지 빌더부터 먼저 작업해 주기를 원하는 분들도 계실 것입니다. 하지만 우선순위를 정해야 하므로 가장 많은 사람들이 사용하는 빌더부터 시작하고 있습니다. 궁극적으로는 가능한 한 빨리 모든 페이지 빌더를 지원할 수 있도록 할 것입니다. 번역 프로세스와 전반적인 계획에 대한 여러분의 피드백을 듣고 싶습니다. 아이디어나 질문, 제안 사항이 있다면 댓글을 남겨주세요. 답변해 드리겠습니다.