아랍어 여행 예약 사이트는 번역이 아니다

제다의 한 여행사가 아랍어 토글을 켜고 자기 홈페이지를 본 뒤 일이 끝났다고 판단한다. 2주 뒤 한 고객이 항공권 요금 링크를 WhatsApp으로 동생에게 전달하는데, 도착한 것은 퍼센트 기호로 된 벽이다. 다른 고객은 합계 금액이 가격의 엉뚱한 쪽에 찍혔다며 전화를 건다. 세 번째 고객은 ICN–DXB 구간을 하루 어긋난 날짜로 예약한다. 날짜 선택기가 한 주를 월요일부터 시작했기 때문이다. 이 중 어느 것도 번역 버그가 아니다. 아랍어 여행 예약 사이트는 문자열의 묶음이기 이전에 레이아웃이고 숫자 체계이며 URL 정책이다. 그런데 문자열이 늘 먼저 처리된다. 스크린샷에 보이는 부분이 그것이기 때문이다.

실제로 무엇이 달라지는지, 여행사들이 부딪히는 순서대로 적어 본다.

RTL은 글자 방향이 아니라 레이아웃 결정이다

dir="rtl"을 걸면 페이지가 거울처럼 뒤집힌다. 내비게이션이 오른쪽으로, 필터 레일이 왼쪽으로 가고 문단은 오른쪽 정렬된다. 여기까지는 거의 공짜다. 비싼 쪽은 뒤집히면 안 되는 모든 것이다.

운항 시각은 뒤집히지 않는다. 07:45는 어디서나 07:45다. ICN에서 DXB로 읽히는 여정 스트립은 오른쪽에서 왼쪽으로 흐르는 문단 안에서도 그 순서 그대로 노선으로 읽혀야 한다. 문장이 어느 방향으로 흐르든 출발 공항은 출발 공항이기 때문이다. 항공사 코드, PNR, 전자항공권 번호는 아랍어 문장 안에 떨어뜨린 라틴 문자열이고, 이들을 격리하지 않으면 브라우저의 bidirectional 알고리즘이 주변 문장부호를 재배치한다. 예약번호 뒤의 마침표가 반대쪽 끝에 찍힐 수 있고, 고객 눈에는 자기 예약 참조번호의 오타처럼 보인다. 로고는 뒤집히지 않는다. 재생 삼각형도 뒤집히지 않는다. 뒤로 가기 화살표는 뒤집힌다.

그다음은 고객이 먼저 말해 주기 전까지 아무도 목록에 올리지 않는 것들이다. 통화 기호와 숫자의 순서, 예약 퍼널을 가로지르는 진행 단계 표시, 좌석 배치도, 캐러셀이 넘어가는 방향, 검색 결과 행의 어느 쪽 끝에 항공사 로고가 앉는지, 넓은 요금 표가 어느 모서리에서부터 스크롤되는지. 하나하나가 모두 결정이다. 그중 어느 것도 켜기만 하면 되는 플래그가 아니다.

숫자, 날짜, 그리고 고객이 실제로 쥐고 있는 달력

아랍어는 두 가지 숫자 체계로 쓰이고 둘 다 일상적으로 쓰인다. 그런데 여행은 숫자투성이다. 요금, 시각, 소요 시간, 수하물 허용량, 카드 입력란, OTP 코드. 당신의 시장이 어느 쪽을 읽는지는 당신의 고객과 함께 한 번 답해야 할 질문이고, 그다음에는 예외 없이 적용해야 한다. 눈에 띄는 실패는 덜 쓰이는 쪽을 고른 것이 아니다. 실패는 둘을 섞는 것이다. 같은 결과 카드 위에서 가격은 이쪽 숫자로, 출발 시각은 저쪽 숫자로 찍히면, 만들다 만 사이트처럼 읽힌다.

날짜는 숫자보다 더 많은 가정을 끌고 온다. 월요일에 시작하는 한 주는 주가 일요일에 시작하는 고객에게는 틀린 것이고, 잘못된 요일에서 시작하는 달력은 정확히 한 종류의 실수를 만든다. 한 칸 어긋난 예약이다. 움라를 계획하는 고객은 그레고리력이 아니라 히즈리 달을 기준으로 움직인다. 날짜 선택기와 여정에 그레고리력 옆에 히즈리 날짜를 함께 보여 주는 일은 비용이 들지 않고 전화 한 통을 아껴 준다. 반면 프랑크푸르트 출장에까지 그것을 어디에나 띄우는 것은 소음이다.

아랍어 여행 예약 사이트가 반드시 맞혀야 하는 것

번역된 사이트와 현지화된 사이트의 간격은 전체가 아니라 화면 하나하나에 있다. 개발자와 다퉈 볼 만한 목록은 이렇다.

이름 행이 진짜 돈이 드는 행이고, 가장 자주 틀리는 행이기도 하다. 여행자는 양식이 그렇게 초대했기에 이름을 아랍어로 입력하고, 항공권은 그 문자열로 발권되며, 항공사가 확인하는 여권과 맞지 않는다. 그 뒤의 모든 것, 재발행과 언쟁과 환불은 항공사가 아니라 당신에게 떨어진다.

서체 행은 보기보다 싸다. 이 플랫폼에서는 폰트와 색상, 로고를 포함한 테마를 재배포 없이 관리자 패널에서 교체할 수 있다. 그러니 다른 아랍어 서체를 당신의 요금 표에 대 보는 일은 릴리스가 아니라 한나절짜리 작업이다. 통화 행은 그 자체로 별개의 주제이고, 그 이야기는 다통화 가격 책정과 마진이 새는 지점에서 다뤘다.

slug, 그리고 WhatsApp에 붙여 넣었을 때 살아남는 것

아랍어 slug는 주소창에서 아름답게 보이고, 사람들이 검색창에 실제로 치는 단어로 이루어진다. 그런데 일반 텍스트 입력란에 복사되는 순간 percent-encode되어 몇 배로 부풀고, 고객이 전달하는 것은 기계 출력물처럼 보인다. 라틴 음차는 깔끔하게 붙여 넣어지지만 누구도 읽지 못한다. 아랍어 독자가 검색하는 것과도, 영어 독자가 검색하는 것과도 맞지 않는다.

그 URL이 무엇을 위한 것인지로 결정을 나누자. 콘텐츠 페이지는 검색으로 살고 죽으니 그 언어 고유 문자로 된 slug를 준다. 인코딩된 형태는 누군가 복사할 때만 나타나고, 어느 쪽이든 도착하는 페이지는 정확하다. 예약 딥링크는, 검색 결과든 홀드한 요금이든 서브에이전트에게 보내는 견적이든, 어차피 예쁠 수 없다. 이미 쿼리 스트링에 날짜와 인원수를 싣고 있기 때문이다. 그쪽에는 짧은 링크를 주고 짧은 채로 두자.

둘 밑에 깔린 규칙은 하나다. 언어별, 페이지별로 canonical URL은 하나. 같은 글을 아랍어 slug와 음차 slug 양쪽에 발행하면 그 페이지가 벌어들이는 것이 두 주소로 쪼개지고, 관리할 것만 둘로 남는다.

hreflang, 아니면 아랍어 페이지가 당신의 영어 페이지와 싸운다

한 페이지의 두 언어 판본은 두 페이지가 아니다. 크롤러가 그것을 구분하지 못할 때 가장 흔한 결과는 제재가 아니다. 한 판본이 선택되고 다른 판본은 거의 중복으로 취급되어 조용히 빠지는 것이다.

네 가지가 둘을 갈라 준다. 각 언어에 자기 URL이 있어야 하고, 이 조건만으로 JavaScript 토글 하나로 돌리는 단일 주소는 탈락한다. 모든 판본이 자기 자신을 포함해 모든 언어를 나열해야 한다. 자기를 가리키지 않는 집합은 통째로 버려지기 때문이다. 각 페이지의 canonical은 영어 원문이 아니라 자기 자신을 가리켜야 한다. 아랍어 페이지를 영어로 canonical 거는 것은 아랍어 페이지를 하나도 색인되지 않게 만드는 가장 빠른 길이다. 그리고 x-default는 일치하는 언어가 없는 독자를 내려놓고 싶은 곳으로 보낸다.

그 페이지들이 통화, 전화번호, 재고에서 정말 다르지 않은 한 ar-AE와 ar-SA로 쪼개는 일은 참자. 같은 원고의 지역 변종 둘은 같은 검색어를 두고 싸우는 페이지 둘이고, 둘 다 당신의 이름을 달고 있다.

이것이 틀렸을 때 치르는 값

이탈은 홈페이지에서 일어나지 않는다. 탑승객 정보 입력 단계에서 일어난다. 퍼널에서 사람을 잃기에 가장 비싼 자리다. 고객은 이미 검색했고, 골랐고, 가격을 봤고, 동의했으며, 그를 거기까지 데려온 검색 비용은 당신이 이미 냈다.

나머지 비용은 더 조용하다. 헷갈려 전화하는 고객 한 명 한 명이, 온라인으로 옮겨서 아끼려던 바로 그 직원 시간이다. 이름 불일치 하나하나가 재발행 한 건이고, 항공사가 아니라 당신을 탓하는 고객 한 명이다. 그리고 끝내 색인되지 않는 아랍어 페이지는, 돈을 들여 쓰게 했는데 아무도 찾을 수 없는 글이다. 불평이 전혀 나오지 않는 유일한 종류의 실패이고, 그래서 1년 내내 방치될 수 있다.

어디서부터 시작할까

아랍어가 두 번째 시장이라면 이 일은 개보수이고, 위의 표가 당신의 펀치 리스트다. 첫 번째 시장이라면 순서가 뒤집힌다. 색 조합보다 먼저 숫자 체계와 아랍어 서체를 고르고, 진짜 여권을 옆에 두고 탑승객 양식을 만들고, 영어 쪽을 번역으로 취급하라.

어느 쪽이든 가장 싼 시험은 진짜 고객 한 명 앞에 놓인 진짜 스토어프런트다. 여행 웹사이트 만들기의 마법사는 그 양식만으로 플랫폼 서브도메인에 당신 브랜드의 사이트를 띄우고 카드를 묻지 않는다. 스토어프런트는 아랍어, 페르시아어, 히브리어, 우르두어를 포함한 40개 언어로 제공되고, 자체 도메인은 나중에 붙일 수 있다. 엔진을 직접 만들지 아직 고민 중이라면 그 논의는 여기에 정리해 두었다. 다만 결정하기 전에 아랍어로 한 번 해 보라. 사내 견적에서 늘 빠지는 부분이 바로 RTL 작업이다.