Elementor 및 Divi 템플릿 레이아웃 손상 없이 번역하기

모든 것을 올바르게 수행했습니다. 프리미엄 테마를 구매하고, .po 파일을 찾아 신중하게 번역한 다음, .mo 파일을 언어 폴더에 업로드했습니다. 테마 헤더의 문자열은 올바르게 업데이트됩니다. 푸터는 스페인어로 표시됩니다. WooCommerce 결제 페이지는 현지화되었습니다. 하지만 홈페이지를 열어보면 Elementor로 제작된 모든 제목, 버튼, 텍스트 블록이 여전히 영어로 되어 있습니다.

.po 파일을 확인합니다. 코드에서 영어 문자열을 볼 수 있습니다. 다시 번역합니다. 아무것도 변하지 않습니다. 캐시를 지웁니다. 아무것도 변하지 않습니다. 뭔가 잘못되었다고 확신하던 중, 포럼의 누군가가 부드럽게 지적합니다: Elementor (및 Divi, Beaver Builder, Bricks)는 .po 파일에 콘텐츠를 저장하지 않습니다. 한 번도 저장한 적이 없습니다. 당신이 사용하고 있는 접근 방식으로는 해결할 수 없는 문제와 씨름하고 있었던 것입니다.

이 가이드는 페이지 빌더 콘텐츠가 테마 및 플러그인 콘텐츠와 아키텍처적으로 다른 이유, 번역을 위한 두 가지 경로, 그리고 번역 중 위젯 마크업을 손상시키지 않고 신중하게 디자인된 레이아웃이 무너지지 않도록 하는 방법을 설명합니다.

Elementor와 Divi가 .po 파일을 사용하지 않는 이유

.po 파일은 코드에 있는 문자열을 저장합니다. 예를 들어 PHP 템플릿 곳곳에 흩어져 있는 __( 'Shop', 'mytheme' )와 같은 호출입니다. 빌드 도구 WP-CLI는 이러한 문자열을 .pot 템플릿으로 추출할 수 있으며, 번역가는 .po 파일로 작업하고 컴파일된 .mo 파일은 런타임에 로드됩니다.

페이지 빌더 콘텐츠는 다릅니다. Elementor 제목 위젯에 "Welcome to our store"를 입력하면 해당 텍스트는 어떤 PHP 파일에도 없습니다. Elementor는 JSON으로, Divi는 숏코드 블롭으로 wp_postmeta 테이블에 저장되며, 해당 게시물과 연결됩니다.

페이지 빌더 콘텐츠는 실제로 어디에 저장될까요?

Elementor는 각 페이지의 위젯 트리를 포스트메타의 _elementor_data 키 아래에 저장합니다. 데이터베이스에서 아무 게시물이나 열어보면 모든 섹션, 열, 위젯을 설명하는 JSON 배열과 함께 설정 및 콘텐츠가 인라인으로 포함된 것을 찾을 수 있습니다.

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Divi는 페이지 콘텐츠를 post_content에 삽입된 숏코드로 저장합니다.

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks, Beaver Builder, Oxygen도 고유한 형식으로 동일한 패턴을 따릅니다. 이 콘텐츠는 .po / .mo 파일의 영향을 받지 않습니다.

.po 파일에는 무엇이 저장될까요?

페이지 빌더 플러그인 자체에는 UI 문자열(에디터의 버튼 레이블, 오류 메시지, 관리자 알림)이 있습니다. 이러한 문자열은 .po 파일에 있으며 wp-content/languages/plugins/의 .mo 파일에 의해 번역됩니다. 사람들이 혼란스러워하는 이유가 여기에 있습니다. 그들은 "Elementor" 문자열을 번역하고 에디터 UI를 스페인어로 보지만, 해당 위젯으로 만든 실제 콘텐츠는 영어로 남아 있습니다.

이러한 구분은 또한 번역이 WordPress에 표시되지 않는 문제 해결 가이드에서 발생하는 문의의 절반을 차지하는 근본 원인이기도 합니다. 독자는 .mo 파일이 프론트엔드에 표시되는 콘텐츠에 영향을 미칠 것이라고 예상하지만, 콘텐츠는 코드에 있는 것이 아니라 데이터베이스에 있습니다.

페이지 빌더 사이트에서 .po 파일이 실제로 다루는 것

각 파일 유형이 무엇을 처리하는지 정확히 알 수 있도록 두 가지를 명확히 구분해 드리겠습니다.

.po / .mo 파일 번역 대상

• 테마의 템플릿 문자열: get_template_part, header.php, footer.php, functions.php에 하드코딩된 텍스트.
• 플러그인 UI 문자열: WooCommerce 결제, Yoast 관리자 레이블, Contact Form 7 필드 레이블.
• 페이지 빌더 플러그인 UI: Elementor 에디터 버튼, Divi 저장 확인 메시지.
• 플러그인이 프론트엔드에 에코하는 동적 문자열: WooCommerce "장바구니에 추가", "재고 없음", 장바구니 총액.

.po / .mo 파일 번역 비대상

• Elementor 위젯에 입력된 제목, 단락, 버튼 텍스트.
• Divi 모듈 내부의 이미지 캡션, 호버 효과, 아코디언 제목.
• 재사용 가능한 템플릿, 글로벌 섹션, 저장된 블록의 콘텐츠.
• 빌더 위젯 내부의 사용자 정의 CSS 레이블 또는 인라인 스크립트.

이것이 테마 제작자의 번역 관련 문서가 기술적으로는 정확하지만 최종 사용자에게는 종종 쓸모없는 이유입니다. 개발자가 아니더라도 모든 WordPress 테마를 현지화하는 방법에 대한 저희 가이드에서 테마 측면을 철저히 다루고 있으며, 이 게시물은 그 가이드가 끝나는 지점에서 시작됩니다.

페이지 빌더 현지화를 위한 두 가지 경로

페이지 빌더 콘텐츠를 번역하는 방법은 정확히 두 가지가 있으며, 둘 다 실제적인 장단점을 가지고 있습니다.

첫 번째 경로: 언어별 페이지 복제

WPML, Polylang, TranslatePress와 같은 다국어 플러그인을 사용하십시오. 이 플러그인은 언어별로 모든 페이지의 사본을 생성합니다. Elementor에서는 전체 레이아웃을 복제하고 각 사본의 텍스트를 교체합니다. Divi에서는 숏코드 블롭을 복사하고 태그 사이의 텍스트를 번역합니다.

장점: 각 언어는 독립적으로 디자인된 레이아웃을 가질 수 있습니다 (번역된 텍스트가 길어져 원본 디자인을 손상시킬 때 유용). 페이지 빌더의 시각적 편집기와 완벽하게 호환됩니다.

단점: 선형 확장 - 5개 언어는 5배의 레이아웃 작업이 필요합니다. 어떤 디자인 변경이든 5번 적용해야 합니다. 데이터베이스가 빠르게 증가합니다. 캐싱이 더 어려워집니다.

두 번째 경로: 문자열 번역 레이어

일부 플러그인(Polylang Pro, WPML의 String Translation 모듈, TranslatePress)은 페이지 빌더 위젯 내부의 개별 문자열을 번역을 위해 노출한 다음, 렌더링 시점에 교체할 수 있습니다. 하나의 레이아웃을 유지하고 플러그인이 문자열을 제자리에 번역합니다.

장점: 레이아웃에 대한 단일 진실 공급원. 디자인 변경 사항이 모든 곳에 적용됩니다.

단점: 번역된 텍스트 길이가 극적으로 변할 때 유연성이 떨어집니다. 일부 위젯(중첩된 콘텐츠, 동적 목록, 양식이 있는 복잡한 위젯)은 문자열을 깔끔하게 노출하지 않습니다. 렌더링당 성능 비용이 발생합니다.

Polylang vs WPML vs TranslatePress 비교 가이드에서 각 플러그인의 장단점을 더 자세히 다룹니다.

번역 중 위젯 마크업을 안전하게 유지하기

어떤 경로를 선택하든, 번역된 콘텐츠는 빌더의 구조적 마크업을 보존해야 합니다. 번역가가 Elementor 숏코드를 제거하거나, 데이터 속성을 교체하거나, 중첩된 태그의 순서를 변경하면 위젯이 손상되어 렌더링됩니다.

Elementor 위험 구역

Elementor 위젯은 텍스트 설정 내부에 숏코드와 동적 태그를 포함합니다. 제목 위젯의 제목 필드에는 다음이 포함될 수 있습니다.

Welcome to <strong>our</strong> [user_name] store

[user_name]은 동적 태그입니다. Elementor는 렌더링 시점에 이를 로그인한 사용자의 이름으로 대체합니다. 번역 과정에서 이것이 손상되면 사용자에게 문자 그대로 "[user_name]"이 표시됩니다.

버튼 내부의 아이콘은 번역되어서는 안 되는 클래스 속성을 사용합니다. 이미지 alt 텍스트는 이미지 URL과 별도로 저장됩니다. 열 레이아웃은 개별적으로 처리해야 하는 중단점별 설정(title_mobile, title_tablet)을 사용합니다.

Divi 숏코드 중첩

Divi 숏코드는 [et_pb_section][et_pb_row][et_pb_column][et_pb_text]와 같이 깊게 중첩됩니다. 블롭을 일반 텍스트로 취급하는 번역가는 대괄호를 인코딩하거나, 속성 값을 번역하거나, 닫는 태그를 잃어버릴 수 있습니다. 이 중 어느 하나라도 모듈을 손상시키고 Divi는 이를 렌더링하지 않습니다.

안전한 패턴

어느 빌더를 사용하든 번역은 다음을 수행해야 합니다.

1. 위젯 형식 파싱 (Elementor의 경우 JSON, Divi의 경우 숏코드 AST).
2. 사용자에게 보이는 텍스트 필드만 식별하여 트리를 순회합니다.
3. 숏코드, 동적 태그, HTML 속성 및 인라인 CSS를 잠급니다.
4. 번역가에게 맥락과 함께 텍스트 표면만 보냅니다.
5. 번역된 텍스트를 원래 구조에 다시 삽입합니다.

이는 저희 엔진이 .po 파일에 적용하는 것과 동일한 원칙입니다. 코드 변수를 손상시키지 않고 .po 파일을 번역하는 방법 가이드에서 %s 및 플레이스홀더 패턴을 자세히 설명합니다. 페이지 빌더의 동등한 개념은 숏코드와 동적 태그입니다.

실제로 작동하는 하이브리드 워크플로우

대부분의 팀에게 실질적인 해답은 두 가지 접근 방식을 결합하는 것입니다.

1단계: .po 파일을 통해 테마 및 플러그인 UI 번역

테마와 주요 플러그인(WooCommerce, Yoast, 페이지 빌더 UI)에서 .pot 파일을 내보냅니다. .po 형식을 준수하는 클라우드 번역기를 통해 한 번 번역합니다. 컴파일된 .mo 파일을 wp-content/languages/에 넣으십시오. 이 방법으로 거의 제로에 가까운 지속적인 유지 관리로 사이트 인터페이스 문자열의 80%를 처리할 수 있습니다.

2단계: 동적 콘텐츠를 위한 다국어 플러그인 선택

게시물, 페이지, 제품 콘텐츠를 위해 Polylang 또는 WPML을 설치하십시오. URL 구조(/es/, /fr/) 및 hreflang 태그를 구성합니다. 이는 언어별 데이터베이스 콘텐츠를 위한 인프라를 제공합니다.

3단계: 페이지 빌더 템플릿을 선택적으로 복제

트래픽이 많은 랜딩 페이지, 홈페이지, 핵심 마케팅 콘텐츠의 경우, 각 언어로 페이지를 복제하고 위젯을 수동으로 번역합니다. 중요한 부분에서 완전한 디자인 제어를 얻을 수 있습니다.

4단계: 반복되는 블록에 문자열 번역 사용

모든 페이지에 나타나는 글로벌 섹션, 재사용 가능한 템플릿, 푸터 CTA의 경우 다국어 플러그인의 문자열 번역 기능을 사용하십시오. 한 곳에서 업데이트하고 렌더링 시점에 교체합니다.

5단계: 품질 검사 실행

번역된 페이지 빌더 콘텐츠는 레이아웃 변경 없이 렌더링되어야 합니다. 긴 언어(독일어, 러시아어)는 버튼 너비를 깨뜨릴 수 있습니다. 짧은 언어(중국어, 일본어)는 어색한 공백을 남깁니다. 출시 전에 각 언어별 템플릿을 테스트하십시오.

일반적인 함정과 피하는 방법

모든 페이지 빌더 현지화 프로젝트에서 나타나는 몇 가지 함정입니다.

이미지 Alt 텍스트 번역 안 됨

Elementor와 Divi는 미디어 라이브러리가 아닌 위젯 인스턴스별로 alt 텍스트를 저장합니다. 원본 이미지를 번역해도 해당 이미지를 사용하는 모든 위젯의 alt 텍스트가 번역되지는 않습니다. 복제된 각 페이지에서 alt 텍스트를 업데이트하십시오.

양식 및 사용자 정의 필드

페이지 빌더 위젯에 삽입된 연락처 양식에는 자체 문자열(레이블, 플레이스홀더, 유효성 검사 메시지)이 있습니다. 양식 측면에 대해서는 Gravity Forms 및 Contact Form 7 번역 가이드를 참조하십시오.

글로벌 위젯 및 템플릿

글로벌 템플릿에 대한 변경 사항은 번역된 사본을 포함하여 이를 사용하는 모든 페이지에 전파됩니다. 이는 공유 콘텐츠를 원하는지 또는 개별 콘텐츠를 원하는지에 따라 유용할 수도 있고 재앙적일 수도 있습니다. 템플릿별로 명확하게 결정하십시오.

번역 캐시 만료

페이지 빌더는 렌더링된 HTML을 적극적으로 캐시합니다. 번역 후에는 Elementor CSS 캐시(Elementor > Tools > Regenerate CSS) 및 Divi 정적 CSS 캐시를 포함한 모든 캐시를 삭제하십시오.

모두 종합하기

Elementor 또는 Divi로 구축된 사이트를 번역하는 것은 정적 테마를 번역하는 것보다 어렵지 않습니다. 단지 올바른 사고방식이 필요할 뿐입니다. 테마 및 플러그인 문자열은 .po 파일에 저장되고 .mo 파일을 통해 전달됩니다. 페이지 빌더 콘텐츠는 데이터베이스에 저장되고 다국어 플러그인 또는 수동 복제를 통해 전달됩니다. 이 두 경로를 혼동하는 것이 "내 번역이 왜 작동하지 않나요?"라는 좌절감의 가장 흔한 원인입니다.

성공적인 워크플로우는 지루합니다. 코드에 있는 모든 것을 위한 정적 .mo 파일, 페이지 콘텐츠를 위한 다국어 플러그인, 그리고 고가치 랜딩 페이지를 위한 수동 큐레이션입니다. 단일 도구로 이 세 가지를 모두 처리할 수 없으며, 그렇지 않다고 약속하는 사람은 무언가를 판매하려는 것입니다.

위젯 마크업을 손상시키지 않고 테마 및 플러그인 .po 파일을 번역할 준비가 되셨습니까? SimplePoTranslate를 무료로 사용해 보세요 - 신용 카드 필요 없습니다. .po 파일을 업로드하고, 안전한 번역을 다운로드하여, wp-content/languages/에 넣으십시오.