Unicode normalization considerations/ko

핵심 주제는?
1.4 버전부터 미디어 위키는 form C (정규화양식 C, NFC)에서 언급하고 있는 원칙들을 유니코드 텍스트 입력에 적용해 왔습니다. 이러한 정규화에는 합당한 이유가 있는데:


 * 형태적으로는 같은 글자들이지만 의미가 다른 구성요소를 갖는 페이지 제목들이 서로 충돌하는 경우를 피하며
 * 사파리를 제외한 웹브라우저들은 글자소가 결합되어 정상적으로 화면을 읽을 수 있지만, 사파리 웹브라우저는 업로드되는 음악, 동영상 등 미디어 파일들은 이름을 구성하는 글자소들이 분해되어 보여지고, 결과적으로 페이지 제목 또한 분해되어 보여지는 문제가 지속되고 있습니다


 * 입력된 검색어의 글자소 구성형태와 상관없이 검색기능이 예측한대로 작동할 수 있도록 하기 위해

양식 C가 선택되었습니다. 그 이유는:

미리 조합된 글자를 사용하여 양식 C의 형태로 이미 막대한 양의 데이터가 입력되었으며,

양식 C는 기본 글자 + 결합되는 글자의 행렬들을 미리 구성된 글자들로 바꾸는 과정을 보이지 않게 처리하면서 상대적으로 손실이 적은 것으로 알려져 있다.이론적으로도, 양식 C에 의해 정규화되었기 때문에 글자들이 보여지는 형태가 바뀌어서는 안된다.

the W3C recommends it 를 참조하라

문제점
그러나, 시간이 지남에 따라 몇 개의 문제점들이 나타났다


 * 어떤 아라비아, 페르시아 및 히브리 언어의 연결모음 표시들은 부정확하게 정렬된다.
 * 이런 사례들 중 일부는 단지 폰트 또는 렌더링상의 오류로 발생하며 제한된 몇몇 플랫폼에서만 발생한다.
 * 그러나 정의된 분류기준이 의미상으로 정확한 분류순서를 생성할만큼 충분한 구분기준을 제공해 주지 못하기 때문에 꽤 많은 사례들에서 부정확한 문장이 발생할 수 있다. 이는 주로 성경히브리어와 같은 오래된 경전들에 영향을 미친다.


 * 벵골어의 놀라운 구성제외 사례.
 * 몇몇 소프트웨어 도구들에서는 정확하게 렌더링이 되지 않는데 이는 위에서 언급한 바와 같이 특정 플렛폼과 연계된 버그 때문으로 추정된다.
 * 몇몇 영세한 개발자에 의한 검색 툴은 어떻게 정규화하는지 알지 못하는 것이 분명하며, 따라서 문장들을 제대로 표현해내지 못한다.

단지 시간만 좀 걸리면, 다른 개발자들이 잘못된 소프트웨어를 고칠 수 있으며, 그 문제들이 무시할만큼 작은 문제라고 거만을 떨고는 있지만, 렌더링 문제와 영세한 개발자에 의해 개발된 잘못된 검색 문제는 여전히 우리들을 괴롭히고 있다.

정식 순서를 부여하는 문제는 어려운 일이다. 단순히 현재 가용한 규준을 따르기만 하면 올바른 결과가 나오는 것은 아니다. 유니코드체계는 호환성 원칙이 깨질 우려가 있기 때문에 정렬순서에 대한 정의를 바꾸지 않았으며, 정확한 정렬순위를 부여한 *새로운* 글자체계를 도입하지 않는 한 이 문제가 해결될 것 같지 않다.

우리는 어떻게 해야할까?
우리는 이 문제를 무시하고 그저 비켜 갈 수 있기만을 바라거나 (가장 손쉬운 방법이긴 하지만, 지속적으로 이의를 제기하는 특정 언어군들을 달래야 함), 또는 포괄적 정규화를 포기하고 문제를 최소화하면서 이윤을 극대화할 수 있도록 우리가 적용하는 원칙들을 바꿀 수 있다.

만약 우리가 정규화 양식 C (NFC)가 유해하다고 생각한다면, (비록 자매격인 NFKC처럼 유해하지는 않지만) 가능한 해결방법은 아래와 같은 방법이 있다


 * 모든 웹 입력에 대해 정규화 확인과정을 제거한다; UTF-8 충족 여부만 확인하도록 축소하면서, 있는 그대로 보다 재미있는 구성양식을 허용함.


 * 가장 필요로 하는 곳에만 NFC를 직접 적용하고:
 * Title::secureAndSplit을 통해 페이지 제목 정규화
 * 검색 엔진 인덱스 생성
 * 검색 엔진 질의들

This is minimally invasive, allowing page text to contain arbitrary composition forms while ensuring that linking and internal search continue to work. It requires no database format changes, and could be switched on without service disruption.

However, it does leave visible page titles in the normalized, potentially ugly or incorrect form.

Longer term
A further possibility would be to allow page titles to be displayed in non-normalized forms. This might be done in concert with allowing arbitrary case forms ('iMonkey' instead of 'IMonkey').

In this case, the page table might be changed to include a display title form:

page_title:        'IMonkey' page_display_title: 'iMonkey' or perhaps even scarier case-folded stuff:

page_title:        'imonkey' page_display_title: 'iMonkey'

The canonical and display titles would always be transformable to one another to maintain purity of wiki essence; you should be able to copy the title with your mouse and paste it into a link and expect it to work.

These kinds of changes could be more disruptive, requiring changes to the database structure and possibly massive swapping of data around in the tables from one form to another, so we might avoid it unless there are big benefits to be gained.

Other normalization forms
NFC was originally chosen because it's supposed to be semantically lossless, but experience has shown that that's not quite as true as we'd hoped.

We may then consider NFKC, the compatibility composition form, for at least some purposes. It's more explicitly lossy; the compatibility forms are recommended for performing searches since they fold additional characters such as plain latin and "full-width" latin letters.

It would likely be appropriate to use NFKC for building the search index and to run on search input to get some additional matches on funny stuff. I'm not sure if it's safe enough for page titles, though; perhaps with a display title, but probably not without.

Normalizaton and unicodification can both be done by bots. While no bot has yet been known to "normalize", the function is possible. The "Curpsbot-unicodify" bot has unicodified various articles on Wikipedia and this should not be undone.