대소문자와 문자 표기 차이 때문에 검색을 놓치지 않게

화면에 보이는 글자와 비교하는 값

2024년 11월 8일의 Factorio 개발 기록 #436은 검색에서 유니코드 문자를 다루는 문제를 설명합니다. 예로 나온 체코어 단어는 소문자로 검색할 때 대문자가 들어간 표시 이름을 찾지 못했습니다. 문자열을 바이트 단위로 처리하는 단순한 대소문자 변환이 여러 언어의 문자를 제대로 다루지 못한 것입니다.

개선 내용은 영어 이름으로 번역된 아이템을 찾는 별칭 기능이 아닙니다. 대소문자, 악센트, 서로 대응하는 가나 문자 등 검색 비교 규칙을 개선한 사례입니다. 따라서 이 발표만으로 한글 이름을 영어 키워드로 검색할 수 있다고 설명할 수는 없습니다.

무엇을 같게 볼 것인지 정합니다

개발팀은 지원하는 언어에 필요한 문자 변환을 다루는 방식을 설명했습니다. 악센트 차이를 무시하는 검색, 히라가나와 가타카나의 대응, 그리스어 시그마의 여러 형태를 같은 검색에 연결하는 사례가 포함됩니다. 원문 당시에는 2.0.16 실험 버전에 적용할 계획으로 안내했습니다.

이 변화의 의미는 사용자가 같은 말이라고 생각하는 입력을 검색이 놓치지 않게 한다는 데 있습니다. 다만 대소문자 무시, 악센트 무시, 번역어 대응은 각각 다른 규칙입니다. 하나를 지원한다고 오타 교정이나 초성 검색까지 된다고 확대해서 해석하지 않았습니다.

유니코드 정규화와 검색 정책은 구별합니다

추가로 확인한 Unicode 정규화 표준은 같은 추상 문자가 서로 다른 코드 포인트 배열로 표현될 수 있음을 설명합니다. 정규화는 이런 동등한 표현을 일관된 형태로 다루기 위한 도구입니다. 그러나 모든 언어의 검색 의도를 자동으로 해결하는 만능 번역 과정은 아닙니다.

표시할 원문과 비교에 사용할 키를 구분하는 설계를 생각해 볼 수 있습니다. 원문은 보존하고 검색 키에만 필요한 처리를 적용하면 이름의 원래 표기를 잃지 않습니다. 이것은 일반적인 구현 제안이며 Factorio가 특정 라이브러리나 표준 정규화 형식을 그대로 사용했다고 주장하는 설명은 아닙니다.

눈으로 같은 문자열도 테스트합니다

직접 해볼 테스트는 아직 실행하지 않은 제안입니다. 먼저 대문자·소문자 쌍, 악센트가 붙은 문자와 없는 문자, 조합된 문자와 분해된 표현을 각각 준비합니다. 가나 대응처럼 제품이 의도적으로 같은 것으로 볼 규칙은 별도 항목으로 관리합니다. 각 입력이 어떤 결과를 반환해야 하는지 먼저 적어야 테스트가 기준 역할을 합니다.

검색 키를 만드는 단계와 실제 목록을 찾는 단계를 분리해 확인하면 실패 위치를 좁히기 쉽습니다. 키가 같아졌는데 결과가 없으면 색인이나 필터 조건을, 키부터 다르면 문자 처리 규칙을 살펴볼 수 있습니다. 다른 단어가 지나치게 많이 합쳐져 결과가 늘어나는 경우도 검사해야 합니다.

좋은 다국어 검색은 변환을 많이 적용하는 것보다 사용자가 기대하는 동등성을 정확하게 정하는 데 가깝습니다. 화면의 이름을 그대로 입력했는데도 찾지 못하는 사례부터 수집하고, 언어별 회귀 테스트로 남기는 것이 작은 검색창의 신뢰도를 높이는 출발점입니다.

출처

• 개발 기록 #436 · Lost in translation
• Unicode Standard Annex #15 · Normalization Forms