앱에서 언어를 바꾸고 종료한 뒤 다시 실행하면 첫 로딩 화면과 로그인 화면 일부가 기본 언어로 잠깐 보였다가 저장한 언어로 바뀌었다. 설정 파일에는 마지막 선택이 정상적으로 들어 있었다. 언어를 읽는 시점이 첫 UI 생성보다 늦었다.
최종 상태만 맞으면 되는 설정과 첫 프레임부터 맞아야 하는 설정의 우선순위가 달랐다.
최소 언어 설정의 우선 조회
전체 사용자 설정을 복호화하고 동기화할 때까지 기다리지 않고, 부트 화면에 필요한 언어 코드를 빠르게 확인할 작은 경로를 뒀다.
앱 시작
-> 로컬 언어 힌트 읽기
-> 초기 자산 선택
-> 전체 설정 로드·검증
-> 서버 설정 동기화
로컬 힌트가 깨졌으면 OS 언어나 기준 언어로 안전하게 시작했다.
언어 설정 출처의 우선순위
OS 언어, 마지막 로컬 선택, 로그인 뒤 서버 설정이 서로 다를 수 있었다. 사용자가 직접 선택한 마지막 값은 지원되는 언어라면 우선하고, 로그인 후 서버 값과 충돌할 때 제품 정책에 따라 동기화했다.
Language Resolve(Language? saved, Language system)
=> saved is { } value && supported.Contains(value)
? value
: supported.Contains(system) ? system : defaultLanguage;
지원 목록에서 제거된 언어를 저장하고 있던 경우도 기본 경로로 처리했다.
초기 화면의 중복 생성 방지
기본 언어로 UI를 만들고 나중에 전체를 다시 만드는 방식은 깜빡임과 이벤트 중복을 만들었다. 언어 결정 전에는 언어 중립 로딩 표시를 사용하고, 결정된 뒤 로그인 화면을 한 번 생성했다.
이미 열린 팝업과 네이티브 SDK 화면처럼 앱 번역 시스템 밖에 있는 요소도 언어 전달 시점을 확인했다.
앱을 강제 종료한 직후 재실행, 저장 중 종료, 지원 언어 목록이 바뀐 업데이트도 확인했다. 마지막 값이 존재해도 현재 빌드에서 사용할 수 있는지 다시 검증해야 했다.
시작 단계의 설정 우선순위
언어 값 저장 자체는 오래전부터 됐지만 사용자가 처음 보는 순간까지 이어지는 경로는 따로 봐야 했다. 설정이 존재한다는 것과 제때 소비된다는 것은 다른 문제였다.
이후 부트 과정에서는 테마와 언어처럼 첫 화면을 결정하는 값, 로그인 뒤에 필요한 값, 나중에 불러도 되는 값을 나눈다. 초기화 순서는 기술 편의보다 사용자에게 보이는 의존성에 맞춰야 했다.
공식 문서 기반의 추가 정리
이 문제를 고친 뒤 관련 공식 자료를 찾아 읽으면서, 당시 코드에서 우연히 맞았던 부분과 규칙으로 남겨야 할 부분을 나눠 봤다.
W3C 일본어 조판 요구사항을 보면 번역은 문자열 치환보다 행 구성과 줄바꿈 규칙까지 포함한 레이아웃 입력이다. 같은 의미라도 문자 폭과 금칙 처리 때문에 버튼·티커·팝업의 높이가 달라진다.
WCAG의 reflow 기준처럼 확대와 좁은 폭에서도 조작 순서와 내용이 유지되는지 보면, 특정 번역 하나에 맞춘 고정 높이를 줄일 수 있다.
다음에 시작 화면의 마지막 언어 복구 같은 문제를 보면 아래 순서부터 확인하려고 한다.
- 최장 번역과 줄바꿈 금칙
- 빈 값과 key 누락의 fallback
- 팝업·티커·버튼의 높이 변화
- 언어 변경 중 열린 화면 갱신
문구 key 누락, 빈 문자열, 예상보다 긴 번역을 서로 다른 상태로 다루고 fallback 언어가 레이아웃을 망가뜨리지 않는지 확인해야 한다.
공식 참고 자료
- W3C 일본어 조판 요구사항 — 일본어 줄바꿈·문자 배치·행 구성
- W3C WCAG 2.1 — 확대·reflow·orientation·입력 접근성