문서 번역 중 표에는 어떤 변화가 생길까요?
Chrome에 추가 
TABLE OF CONTENTS
모든 행과 열이 그대로 남아 있어도 번역 후 표가 제대로 작동하지 않을 수 있습니다. 길어진 텍스트, 달라진 줄바꿈, 오른쪽에서 왼쪽으로 쓰는 콘텐츠, 현지화된 숫자, 손실된 머리글 메타데이터 때문에 온전해 보이는 표가 잘못된 정보를 전달할 수 있습니다.
표를 번역하면 무엇이 달라질까요?
문서 표에는 세 가지 계층이 있으며 각각 따로 확인해야 합니다.
| 계층 | 예상 결과 | 발생 가능한 문제 |
|---|---|---|
| 콘텐츠 | 제목, 레이블, 주석, 본문이 번역됨 | 텍스트가 누락, 중복, 오역되거나 원문 언어로 남음 |
| 구조 | 행, 열, 병합된 셀, 머리글 관계가 연결된 상태로 유지됨 | 변환 과정에서 셀이 분할되거나 범위가 바뀌거나 구조적 메타데이터가 손실됨 |
| 표시 | 테두리, 채우기, 글꼴, 너비, 정렬이 사용 가능한 상태로 유지됨 | 텍스트가 줄바꿈, 잘림, 축소, 겹침되거나 표가 다음 페이지로 밀림 |
번역 과정에서 표를 처음부터 다시 만들면 안 됩니다. 문서 형식을 인식하는 워크플로는 구조와 스타일을 보존할 수 있지만, 보존된다고 해서 번역 후에도 모든 셀이 같은 공간을 차지하는 것은 아닙니다.
W3C는 번역문 길이가 달라질 가능성이 크므로 폭이 좁게 고정된 컨테이너 대신 유연한 레이아웃을 권장합니다. 짧은 머리글이 가장 좁은 셀에 배치되는 경우가 많은 표에서는 특히 중요합니다. 또한 W3C의 예는 독일어 합성어가 같은 뜻의 영어 구보다 자연스러운 줄바꿈 지점이 적을 수 있고, 일부 비라틴 문자는 더 넓은 문자 폭이나 더 큰 줄 높이가 필요함을 보여 줍니다.
이러한 영향에 관한 자세한 설명은 번역된 문서가 길어지는 이유에서 확인하세요.
번역 후에도 일반적으로 유지되는 표 요소
편집 가능한 원본 파일을 형식 인식 도구로 번역하면 다음 요소가 결과물에 유지될 수 있습니다. 그러나 검증 없이 정확하다고 가정해서는 안 됩니다.
| 요소 | 예상 결과 | 검토 질문 |
|---|---|---|
| 행과 열 | 동일한 논리적 그리드 | 누락되거나 중복된 행, 열, 셀이 있는가? |
| 테두리와 채우기 | 동일한 시각적 그룹 | 색상과 테두리가 의도한 범주를 여전히 전달하는가? |
| 병합된 셀 | 행 또는 열에 걸친 동일한 범위 | 각 머리글이 올바른 데이터를 계속 포함하는가? |
| 머리글 행 | 동일한 레이블 및 반복 동작 | 머리글이 올바른 열에 연결되고 페이지가 바뀌어도 반복되는가? |
| 셀 스타일 | 동일한 글꼴, 강조, 여백, 정렬 | 글꼴 대체나 자동 맞춤으로 읽기 어려워진 셀이 있는가? |
| 숫자와 수식 | 동일한 기본 값과 논리 | 부호, 구분 기호, 단위, 수식, 참조가 변경되었는가? |
| 주석과 링크 | 동일한 대상 및 연결 관계 | 각 주석이나 링크가 여전히 올바른 셀에 속하는가? |
형식 변환은 별도의 위험 요소입니다. W3C의 표 접근성 지침은 콘텐츠를 형식 간에 이동할 때 표의 구조적 마크업이 손실되는 경우가 많다고 경고합니다. 따라서 표가 올바르게 보여도 보조 기술에 머리글과 데이터의 관계를 더 이상 전달하지 못할 수 있습니다.
표에서 흔히 발생하는 다섯 가지 문제와 해결 방법
1. 텍스트가 넘치거나 행이 너무 높아짐
번역된 레이블은 더 길거나 문자가 더 넓을 수 있고 다른 지점에서 줄바꿈될 수 있습니다. 고정 행 높이는 마지막 줄을 자를 수 있고, 자동 행 확장은 표를 다음 페이지로 밀어낼 수 있습니다.
다음 순서로 해결하세요. 수동 줄바꿈을 제거하고, 행 확장을 허용하며, 가장 좁은 열을 넓히고, 불필요한 셀 여백을 줄인 뒤, 적절한 경우 대상 언어의 하이픈 넣기를 사용합니다. 언어 검토자가 의미가 손실되지 않았다고 확인한 후에만 문구를 줄이세요. 글꼴 축소는 마지막 수단입니다.
대상 문자가 네모 상자, 분리된 글자 또는 예상치 못한 서체로 보이면 넘침 문제가 아니라 글꼴 문제로 다루세요. 번역 후 글꼴이 깨지는 이유의 확인 절차를 따르세요.
2. 병합된 셀이 더 이상 올바른 데이터를 설명하지 않음
원본의 병합 머리글이 세 개의 제품 열에 걸쳐 있을 수 있습니다. 변환 중 행이나 열이 삽입, 삭제, 이동되면 단어가 올바르게 번역되었더라도 머리글이 잘못된 그룹 위에 나타날 수 있습니다.
원본과 대조하여 범위를 확인하세요. 여러 열과 행에 걸친 각 머리글이 담당하는 셀을 추적하세요. 번역된 레이블을 맞추기 위해 새 병합 셀을 추가하지 말고 너비나 줄바꿈을 조정하세요.
Microsoft는 분할 셀, 병합 셀, 중첩 표, 빈 행이나 열이 화면 읽기 프로그램의 셀 계산과 식별을 방해할 수 있으므로 접근성을 위해 단순한 직사각형 표를 권장합니다. 복잡한 범위가 꼭 필요하다면 시각적 검사만으로는 충분하지 않습니다.
3. 머리글과 데이터 셀의 관계가 손실됨
첫 행의 굵은 텍스트는 시각 사용자에게 머리글처럼 보이지만 모양이 구조를 정의하지는 않습니다. W3C 지침은 보조 기술이 관련 행과 열의 문맥을 안내할 수 있도록 머리글 셀과 데이터 셀을 식별하고 연결하도록 요구합니다.
편집 가능한 문서에서 의미론적 머리글을 복원하세요. 첫 행을 머리글로 지정하고, 여러 페이지에 걸친 표에서 머리글이 반복되는지 확인하며, 애플리케이션의 접근성 검사기로 복잡한 표를 테스트하세요. 내보낸 HTML 또는 PDF에서도 변환 후 머리글 연결 관계가 유지되는지 확인하세요.
4. 숫자, 수식, 식별자가 눈치채지 못하게 바뀜
문장이 자연스러운지는 쉽게 알아차릴 수 있지만 소수점 구분 기호, 빼기 기호, 백분율, 모델 번호, 스프레드시트 참조의 변화는 그렇지 않습니다. 독자를 위해 현지화해야 하는 값이 있는 반면 식별자와 계산 논리는 정확하게 유지해야 합니다.
데이터만 비교하는 검토 단계를 두세요. 본문은 무시하고 숫자, 통화 코드, 백분율 기호, 단위, 범위, 합계, 수식, 각주 표시, 셀 참조를 비교하세요. 대상 파일에서 스프레드시트 수식과 합계를 다시 계산하세요. 의도적인 로캘 변경을 기록해 검토자가 원본 형식으로 다시 “수정”하지 않도록 하세요.
5. 오른쪽에서 왼쪽으로 쓰는 텍스트에서 문장 부호나 정렬이 뒤섞임
아랍어와 히브리어는 오른쪽에서 왼쪽으로 진행하지만 삽입된 라틴어 용어와 숫자는 여전히 왼쪽에서 오른쪽으로 진행합니다. 따라서 Unicode는 이를 양방향 텍스트로 처리합니다. 또한 개별 표 셀을 별도 문단으로 다룰 수 있어 셀이나 문단 수준에서 방향을 설정할 수 있다고 설명합니다.
셀별로 수정하세요. 올바른 기본 방향을 설정한 다음 제품 코드, 날짜, 백분율, 괄호, 슬래시, 라틴 문자 옆 문장 부호를 확인하세요. 숫자를 수동으로 뒤집지 마세요. 방향과 미러링은 렌더링 동작이므로 편집 가능한 문서와 내보낸 PDF를 모두 확인하세요.
번역 전 체크리스트
- 가능하면 편집 가능한 DOCX, PPTX 또는 XLSX에서 시작합니다.
- 간격 조정에만 사용된 빈 행과 열을 제거합니다.
- 가능한 경우 레이아웃 표를 일반 문서 레이아웃으로 바꿉니다.
- 실제 머리글 행을 지정하고 데이터가 허용하는 범위에서 표 구조를 단순하게 유지합니다.
- 행이 늘어날 수 있게 하고 번역 대상 셀에 고정 높이를 사용하지 않습니다.
- 병합된 셀, 수식, 합계, 보호된 식별자, 번역 금지 용어를 식별합니다.
- 원본 언어를 정확히 설정하고 대상 로캘을 기록합니다.
- 검토자가 승인된 원본의 모양을 알 수 있도록 참조 PDF를 저장합니다.
이 단계는 도구나 번역가가 파일을 다루기 전에 모호함을 줄여 줍니다. 또한 나중에 생긴 문제가 번역, 변환, 원본 표 설계 중 어디에서 발생했는지 판단하기 쉬워집니다.
번역된 표 검토 방법
검토 단계를 분리하세요. 언어, 데이터, 구조, 레이아웃을 한 번에 확인하면 작은 오류를 놓치기 쉽습니다.
- 그리드를 비교하세요. 원본과 대조하여 표, 행, 열, 병합 영역, 머리글 행, 주석의 수를 확인합니다.
- 콘텐츠를 비교하세요. 모든 셀이 한 번씩 번역되었고 올바른 머리글 아래에 있는지 확인합니다.
- 데이터를 비교하세요. 본문을 편집하지 않고 숫자, 부호, 단위, 수식, 합계, 식별자, 링크를 확인합니다.
- 레이아웃을 점검하세요. 잘림, 과도한 행 확장, 어색한 페이지 나누기, 자동 맞춤으로 작아진 글자, 대체 글꼴, 불균형한 정렬을 찾습니다.
- 방향과 접근성을 확인하세요. RTL 셀, 머리글 연결 관계, 읽기 순서, 반복 머리글을 검증합니다.
- 내보낸 후 다시 확인하세요. 전달할 PDF 또는 기타 최종 형식을 열어 보세요. 편집 가능한 원본만 보고 승인하지 마세요.
OpenL Doc Translator는 PDF, DOCX, PPTX, XLSX 등의 문서 형식을 지원합니다. 공식 페이지에 따르면 글꼴, 색상, 표, 페이지 레이아웃을 보존하고 각 작업에 번역본과 이중 언어 버전을 제공합니다. 가능하면 편집 가능한 원본을 사용해 결과를 미리 본 다음 위의 구조화된 검토를 완료하기 전에 이중 언어 버전을 비교하세요.
서식 보존은 재구성 작업을 줄여 주지만 품질 보증을 대체하지는 않습니다. 표 검토를 마친 후에는 이중 언어 문서 검토 체크리스트로 문서 전체를 확인하세요.
수동 검토가 반드시 필요한 경우
표에 다음 내용이 포함되면 항상 사람 검토자를 배정하세요.
- 재무 합계, 비율, 예측 또는 감사 수치
- 법적 의무, 규정 준수 한도, 복용량 또는 안전 데이터
- 수식, 시트 간 참조 또는 계산 필드
- 다단계 머리글, 병합 영역 또는 중첩 표
- OCR에 의존하는 스캔 또는 이미지 기반 셀
- 오른쪽에서 왼쪽 및 왼쪽에서 오른쪽 텍스트의 혼합
- 확장 공간이 없는 고정 인쇄 레이아웃
이러한 표에서는 “파일이 열림”과 “표가 비슷해 보임”이 승인 기준이 될 수 없습니다. 원본 구조 일치, 대상 언어 의미, 모든 중요 값, 최종 전달 형식을 검증해야 승인할 수 있습니다.
성공적인 표 번역은 사각형뿐 아니라 관계를 보존합니다. 콘텐츠, 구조, 데이터, 레이아웃, 방향, 접근성을 따로 검토하면 서식 결함이 데이터 오류로 이어질 가능성을 크게 줄일 수 있습니다.
Sources
- W3C: Text size in translation - Explains text expansion, constrained layouts, compound words, character width, and line-height differences across languages.
- W3C WAI: Tables Tutorial - Explains header-to-data relationships, complex table markup, screen-reader context, and metadata loss during format conversion.
- Microsoft Support: Make your Word documents accessible to people with disabilities - Recommends simple tables, header rows, accessibility checks, and avoiding split, merged, nested, or blank structures where possible.
- Unicode Standard Annex #9: Unicode Bidirectional Algorithm - Defines display ordering for mixed right-to-left and left-to-right text, digits, punctuation, and direction at paragraph or table-cell level.
- OpenL Doc Translator - Lists supported document formats, formatting preservation, free preview, and bilingual review output.
