회사에 있을 때도 하지 못했던 국제화(i18n)을 준비하게 됐다. 시작하려고 생각해보니, 구현 가능한 방법이 한가지가 아니다. 그렇다면 어떤게 베스트 프렉티스일까?

유의점들

• 국제화는 번역이 아니다.

국제화에 번역은 반드시 필요하다. 그렇다고해서 번역이 곧 국제화를 의미하지는 않는다. 같은 서비스라도, 지역에 따라 다른 접근법이 필요하다. 가령 일본, 한국, 중국이 각각 선호하는 웹 페이지 디자인이 다를 수 있다. 번역 그 이상을 염두에 두자. 각 국가별로 UX까지 달라질 수 있다는 전제를 깔고, 국제화를 설계하는 것. 이렇게 설계하는 것이 손은 많이 가도 가장 높은 수준의 추상화를 하는거니까, 범용성도 좋아진다.

추가: 내가 생각하는 국제화는 위키피디아 기준 i18n + l10n인 듯 하다. 둘을 합쳐서 g11n라고 한다고 한다.

• 국제화 적용 순서

어느 국가의 페이지를 보여줄 것인지를 판단할 때의 기준은,
(1) 유저가 선택한 옵션
(2) 유저가 사용하는 브라우저의 언어
(3) 유저 접속지역
으로 한다. 이 때 (1), (2), (3)이 불일치할 경우, 언어 변경 가능에 대한 알림을 준다. google.com의 방식에서 영감을 얻음.

• ISO language code table 참고하기

  • ko-KR: 한국어-한국
  • en-US: 영어-미국
  • en-CA: 영어-캐나다
  • fr-CA: 프랑스어-캐나다

방안들

• URI

  • 언어 변경을 URI에 표시하지 않기(airbridge.io/)
  • 언어 변경을 URI에 파라미터로 표시(airbridge.io/?lo=kr)
  • 언어 변경을 서브디렉토리로 나누기(airbridge.io/kr/)

유의점 1을 생각해보았을 때, 서브디렉토리 안이 유력. 문제는 대시보드 URI와의 연계를 어떻게 할지. 대시보드가 {root}/d/#/... 스타일 이었던걸로 기억. 그러면 airbridge.io/kr/d/#/... 의 식으로 해야하나? URI가 너무 복잡해지지 않나? 그런데 유의점 1을 정말로 적용하려면, 이렇게 하는게 맞음. 가령 google의 경우, google.com으로 일본에서 접속하면 google.co.jp로 리다이렉트 해서 서브디렉토리도 아니라 도메인을 옮겨버림. 페이스북의 경우 https://{locale}.facebook.com/으로 나감.

• Scripts
  • 기본적으로 한국어(혹은 기본언어)로 찍어내고, 각각을 언어 변경에 따라 자바스크립트로 교체하는 방식: 번역에 적합. 문장이 깜박이는 이슈는 없을까?
    • 전체 언어 셋을 처음부터 한번에 다 받아오기
    • 한번이라도 언어를 변경할 시, 전체 언어 셋을 다 한번에 받아오기
    • 변경시마다 선택된 언어에 해당되는 언어 셋만 받아오기
  • 각 언어별로 별도의 페이지를 만들기
    • 템플릿 구조가, 언어별로 다르지 않을 경우 변수만 바꿔치기 해줘서 다른 html로 찍어내게 함
    • 언어 별로 다른 게 있을 경우, 템플릿 엔진의 조건문을 활용하여 분기
  • 스크립트 JSON 구조 짜기
    • ID->language->country
    • language에 기본적으로 입력하고, country 별로 다르게 하고 싶으면 명시하기. 명시되어 있지 않으면 language 기본 적용하기.
    • language별 모아보기 관리페이지 필요?
• Writing direction
  • 아랍어의 ‘우->좌’ 글쓰기 고려

현재까지의 생각

국제화를 어디까지 할 것인지, 즉 번역에 머무를 것인지 아니면 UI/UX의 변경까지도 염두에 둘 것인지에 따라 베스트 프렉티스가 달라져야 할 것 같다. 번역만 한다면, URI는 파라미터로 들어가는게 맞고, 유저의 언어 설정에 따라 다르게 뿌려주면 된다. 번역만 염두에 두는 게 아니라면, 적어도 서브디렉토리 단위부터 달라져야 하는게 맞다.

고민1. ajax에서 request header가 언어별로 달라지게 되는데, 이렇게 되면 이미지를 한 언어에서 불러오고 다른 언어로도 부를 때, 브라우저 캐쉬가 사용될 수 있나?