음… 사람은 한계가 있잖아요. 마지막으로 한 가지만 말씀드릴게요 (약속합니다). 제가 아는 한, Unicode 사양은 ->를 →로 변환하는 것을 권장하지 않습니다(그리고 이 문제가 그 이유 중 하나가 될 수 있겠죠). 따라서 기존 Discourse의 이 기능은 어떤 Unicode 사양도 따르지 않고 있습니다. 텍스트에 대해 잘못된 가정을 하고 있고, 그 과정에서 이 버그를 유발합니다. 제 생각은 이렇습니다. (다만 이 기능 자체는 여전히 괜찮긴 합니다)
우측에서 좌측으로 쓰이는 언어(RTL)로 입력할 때, ‘dash’(하이픈)를 입력한 뒤 ‘less than’(작음 기호)을 입력하면 왼쪽 화살표(←)로 변환되기를 기대할 수 있을 것입니다. 저에게는 꽤 합리적인 기대라고 생각합니다. 하지만 'less than’을 입력하면 편집기에 ‘greater than’(큼 기호)이 삽입됩니다. 이는 매우 예상치 못한 결과였습니다. 이것이 버그인가요?
RTL 텍스트 박스(예: aljazeera.net의 검색창)에서는 RTL 텍스트 내에서 숫자와 수학적 기호가 LTR(좌측에서 우측으로) 순서로 삽입되는 것을 확인할 수 있습니다. 이는 충분히 자연스러운 동작입니다. (라틴 문자도 동일한 방식으로 처리됩니다.)
아래에서는 RTL 컨텍스트에서 "less than is < and greater than is >"를 입력해 보겠습니다. (이것이 RTL 로케일에서 실제로 어떻게 동작하는지 정확히 알 수는 없지만요.)
일상생활에서 우에서 왼쪽(RTL) 문자를 사용하시나요? 아닙니다よね? (아니시죠?) 당신이 설명한 내용에는 버그가 없습니다. 당신의 말에 모호한 부분이 있어서 혼동을 방지하기 위해 먼저 댓글의 두 번째 부분을 다룰 것입니다.
이것은 정확히 그렇게 작동해야 하는 방식입니다. 이렇게 생각해 보세요:
> 문자는 문자 그대로 "크다(greater than)"를 의미합니다. "A > B"라는 문자열은 "A가 B보다 크다"는 뜻입니다.
마찬가지로, "א가 ב보다 크다"라고 하려면 "is greater than(보다 크다)"라는 부분을 같은 큼 기호인 U+003E 코드의 >로 대체합니다. 그러나 이 문자열이 완전히 RTL(우에서 왼쪽)이므로, "א"는 "ב"의 오른쪽에 표시됩니다. 만약 “크다” 기호가 LTR(왼쪽에서 오른쪽)과 동일하게 렌더링된다면, 다음과 같이 보일 것입니다: א<ب. 이는 “א가 ב보다 작다” 또는 "ב가 א보다 크다"로 읽히며, 설명하려는 관계와 정반대가 됩니다.
이것이 크다(greater-than) 기호를 렌더링할 때 RTL 환경에서는 시각적으로 뒤집히는 이유입니다. 하지만 기본 문자와 이를 뒷받침하는 Unicode 데이터는 여전히 “크다” 기호입니다. 이 문자열은 여전히 "א가 ב보다 크다"는 의미를 가집니다.
이제 첫 번째 질문으로 돌아가 보겠습니다:
키보드 레이아웃을 RTL 언어(히브리어나 아랍어 등)로 변경했다면, Shift+, 조합키(<가 인쇄된 키)는 실제로 “크다” 기호인 >를 입력하게 됩니다. 이는 당신이 발견한 검색 상자처럼 RTL 컨텍스트에서 >로 렌더링됩니다.
[편집: 다음 단락은 당신이 테스트했다고 한 것을 제가 약간 오해했을 때 작성되었습니다. 저는 당신이 LTR 키보드로 RTL 상자에 입력하고 있다고 생각했지만, 실제로는 그 반대 상황이었습니다. 그래도 당신의 혼란을 해소했기를 바랍니다.]
하지만 당신은 여전히 라틴 문자 키보드 레이아웃을 사용하므로, 그 조합키를 누르면 “작음” 기호인 <가 삽입됩니다. 하지만 렌더링은 <로 이루어집니다. 왜냐하면 RTL에서는 오른쪽에 있는 것이 왼쪽에 있는 것보다 작다는 의미가 되기 때문입니다.
결론: 문자는 동일하지만, 렌더링이 거울처럼 뒤집힙니다.
지금까지 제가 설명한 내용을 이해하셨다면, -< 또는 RTL에서는 -<가 된다는 것을 이해하실 것이며, 이것이 당신이 의도한 바가 아니라고 생각합니다.
전혀 아닙니다! 만약 RTL 사용자가 RTL 버그에 대해 논의하고 수정할 수만 있다면, 우리는 훨씬 더 불리한 상황에 놓이게 될 것입니다! 저는 이 기회를 빌려 이 주제에 대해 여러분을 소개해 드린 것뿐입니다. 이 주제를 완전히 이해하는 데는 시간이 좀 걸릴 수 있습니다. 이 주제와 관련하여 더 궁금한 점이나 질문이 있으시면 기꺼이 답변해 드리겠습니다.
이런 경우의 해결책이 될 수 있는 Unicode 추가 사항을 제안하기 위해 Unicode 메일링 리스트에 가입했습니다. 제가 받은 답변 중 하나는 다음과 같습니다:
(나:) 문제는 이 치환이 (제가 아는 한) 어떤 렌더링 컨텍스트 밖에서, 텍스트가 단순히 문자 코드 시퀀스인 상태에서 수행된다는 것입니다. 텍스트가 어떤 방향으로 흘러가는지 아는 것은 합리적이지 않습니다. 텍스트 방향이 치환 시점에 사용할 수 없는 컨텍스트에 의존하는 경우, 그것은 완전히 불가능할 수도 있습니다.
위 설명은 엄밀히 말하면 부정확합니다. 오늘날 모든 진지한 텍스트 렌더링은 HarfBuzz와 같은 셰이핑 엔진(shaping engine)을 필요로 하며, "->"를 "→"로 연결하는 리가처(연결 문자) 생성은 리가처를 지원하는 폰트와 협력하여 이러한 셰이퍼에 의해 수행됩니다. 셰이핑 엔진은 자신이 셰이핑하는 텍스트의 바이디(bidi) 컨텍스트와 스크립트를 인식하므로, 원칙적으로 화살표를 미러링할 수 있습니다.
앞서 언급했듯이, 저는 이 문제에 대한 Unicode 해결책을 제안하는 작업을 진행 중입니다. 해당 문서에서 문제를 자세히 설명했으며, 여기서 설명한 것보다 더 명확하게 서술했을 것입니다. 아직 작업 중(WIP)이지만, 아래 링크를 확인해 주시면 감사하겠습니다: Create [<message>] git stash create. (영구 링크)
