페이지이름띄어쓰기

FrontPage|FindPage|TitleIndex|RecentChanges| UserPreferences P RSS
띄어쓰기 토론에 관해 WikiX:wikiX띄어쓰기토론에서 진행된 것을 요약했습니다. 좀 더 진행되면 좋겠군요. --거북이

[edit]

1. 띄어쓰기의 필요성

  1. 한글은 띄어쓰기가 필요한 글쓰기 방식이다. 일본어나 중국어와는 달리 한자를 노출시키지 않기 때문이다. 중국어나 일본어에 비해 훨씬 가독성이 높은 방식이라고 생각된다. (세종형님 만쉐이~)
  2. 가독성을 높인다는 것 하나만으로도 다른 수만가지 자잘한 반대사유에도 불구하고 구현해볼 가치가 있다.

[edit]

2. 띄어쓰기를 안 하는 이유

  1. 우리말에서는 띄어쓰기가 엄격하지 않아서 혼선이 생긴다.
  2. 위키에서 페이지이름은 그 특성상 하나의 단어처럼 인식이 된다. 법조문이나 법령명을 보면 3-40음절로 된 것들도 모두 붙여서 처리하는데 그것은 그 법 자체를 고유명사로 인정하기 때문이다.
  3. 예외를 허용하면 그것들에 대한 홍보가 필요한데 그것이 참으로 어렵다.
  4. 페이지 이름을 잘 만드는 것으로도 얼마든지 피해갈 수 있다.

[edit]

3. 띄어쓰기를 안 해서 나타나는 문제점

  1. 직관성의 파괴
    1. '질서도전이효과'를 볼 때 '도전'이라는 글자가 눈에 들어온다.
  2. 인덱싱이 불가능
    1. WordIndex를 못 만든다(MoinMoin 0.11) --산오리
      WordIndex는 활용도가 떨어진다. LikePages로도 충분하다. --김창준
  3. 검색 기능에 문제
    1. 대부분의 검색엔진들은 타이틀 텍스트를 형태소 분석하여 검색하는데 띄어쓰기가 안되어있으면 형태소 분석이 불가능하다.
    2. 검색엔진에 적합하게 만든다는 것은 위키를 통해 정보공유를 한다는 측면에서 결코 가볍게 생각할 문제는 아니다.

검색엔진을 위해서라면 #title 문법을 ProcessingInstruction에 넣는 것도 한가지 방법입니다. See HelpOnProcessingInstructions --고무신

HTML의 HEAD 안에 TITLE 태그와 또 따로 검색 엔진을 위한 항목이 있었던 걸로 기억하는데, 거기에 넣는 정도면 충분하지 않나요? --kz
[edit]

4. 제안

[edit]

4.1. 이용자가 태그를 넣게 한다 

아버지가_방에_들어가신다
노스모크_모인모인~에서는
등.

* 예(WikiPedia, UseModWiki 모두 동일)
텍스트로 쓰는방식 위키페이지상의 노출방식 내부적 처리방식
[한국 환경의 문제점] 한국 환경의 문제점 한국_환경의_문제점
모인모인도 %20을 이용해서 띄어쓰기구분을 주는 것은 가능합니다.(bab2)

  • 구현된 위키 : WikiPedia, UseModWiki
  • 찬성자 : 산오리, 안형진

  • 문제점
    • 룰이 복잡하면 많은 교육이 필요하다.
    • 사람들에게 신경쓰게 해야하기 때문에 큰 비용이 계속 들어간다.

[edit]

4.2. 표현형과 링크형을 다르게 구현한다

  1. 현재 유즈모드위키는 공백을 _로 처리하고 있는데 내부적으로 처리할(저장과 불러오기 등등) 때는 _이 없는 형태로 저장을 하고 텍스트에서 보여주거나 제목에 URL에 노출시킬때는 공백을 보여준다.
  2. '가나다 라마바사'와 '가나다라마바사' '가나 다라마바 사'는 모두 동일한 페이지 이름이다.
    1. 한글 띄어쓰기는 엄격하지 않아 예외가 많으므로 혼란을 최소화시켜야 한다.
  3. 영문은 대소문자가 합쳐져있는 부분을 보여줄 때 공백을 하나 삽입하여 보여준다.

텍스트로 쓰는방식 위키페이지상의 노출방식 내부적 처리방식
[한국 환경의 문제점] 한국 환경의 문제점 '한국환경의문제점' 공백 무시
[한 국환 경의문 제점] 한 국환 경의문제 점 '한국환경의문제점' 의도적이 아닌 경우로 가정하고 모든 공백은 무시
["한국 환경의 문제점"] 한국 환경의 문제점 '한국 환경의 문제점' 의도적으로 띄어쓰기를 할 경우

  • 사용중인 위키: KLE위키,GnomeKorea위키 (WordIndex도 된다) 구현된 위키: MoniWiki
    • 위의 위키의 경우, DB에 '한국환경의문제점'이 저장되고, 휘발성 영역(cache)에 '한국 환경의 문제점'이 저장된다. --고무신
  • 찬성자 : 거북이, 고무신, 지원, kcjun, aDVaNCe, NovaKim, bab2, 김민수
  • 유보자 : 김창준, HuidaeCho
    • DB내부적으로도 띄어서 구분한다 : HuidaeCho

  • 마지막에 누군가 적으신 [" "] 가 필요한 것인지 저는 모르겠습니다. 의도적으로 했다 하더라도 다른 사람이 그 페이지를 본문에서 참조하려고 할 때 띄어쓰기를 잘못할 수도 있거든요. 누군가가 철자를 틀리게 기억하지 않는 한 어떤 식으로 띄어쓰기를 하던지 동일한 페이지를 참조하는 것이 혼란을 줄이는 길이라고 생각합니다. 어차피 페이지 본문에는 필자의 의도대로 띄어쓰기가 되어 나오는 것이니까요. --KRock:거북이
    DeleteMe 고무신이 적었습니다. 이것은 모인모인위키에 원래 있는 문법이죠 (노스모크에서도 물론 되고요) 누군가가 두번째와 세번째의 띄어쓰기가 똑같은 방식으로 저장된다면 DB설계상 문제가 아닐까 하는 의문에 대한 답변이기도 합니다. 저 역시 [" "]를 굳이 쓸 이유가 없다고 생각합니다. 그러나, 필요한 경우가 있다면 이 방식을 사용하여 띄어쓰기 정보가 포함된 페이지를 만들 수 있다는 것이죠. 두 방식이 혼재하려면 LikePages를 잘 만들거나 FindPage를 좀더 손쉽게 만들면 되겠죠.

[edit]

5. 토론

띄어쓰기에 대한 표준이 WikiClone 수준에서 결정될 수 없기 때문에, 띄어쓰기를 쓰지 않는 것이 낫고(경제적이고), 따라서 표준에 대한 논의가 나오지 못하는 것입니다. --kz
띄어쓰기에 대한 표준을 정하자는 것이 아니라 위키에서의 띄어쓰기에 대한 표준을 정하자는 얘기입니다. 따라서 당연히 위키클론 수준에서 결정될 수 있습니다.
띄어쓰기에 대한 표준이 불분명하기 때문에 위키에서 띄어쓰기를 하지 않는다는 것은 중국어는 글자를 조합해서 쓰는 글이 아니므로 전산화를 할 수 없다라는 말과 크게 다르지 않습니다.
그리고 분명 위키에서 띄어쓰기를 구현해서 사용할 수 있는 안이 있는데도 그것을 쓰지 않는다는 것은 문제가 있다고 보기때문에 이런 논의를 진행시키는 것입니다. --거북이
글쎄요 제 생각에 맞춤법에 문제가 있다는 것은 여기서 핑계가 못될거 같아요. 한자사용어권에서 IME를 만들어 로마자로 입력하는 것에 비하면 우리말은 축복이니까요. ^^ --거북이

한글을 쉽게 쓸 수 있는 거랑 띄어쓰기는 무관하다고 봅니다. --kz

중국어는 어떤 식으로 사용하고 있는지 모르겠지만 일본어는 띄어쓰기를 하지 않고있지요. 한자를 노출시키기 때문에 그 한자의 앞뒤 근처에서 형태소가 떨어진다고 얼추 보면서 문장을 읽는 것입니다. 하지만 히라가나만으로 글을 쓴다면 가독성이 엄청나게 떨어집니다. 그래서 한자에 약한 초등학교 저학년생들을 위해 일본 교과서에서는 가나로만 쓰되 띄어쓰기를 한다고 알고 있습니다.
한글은 한글만을 이용해 글을 쓰는 대신 띄어쓰기를 해주어 형태소간의 구분을 쉽게 해주고 있는 것이지요. 따라서 띄어쓰기와 한글 쉽게 쓰기는 무척 관련이 깊습니다. --거북이

DeleteMe 한자사용권에서는 띄어쓰기가 없으니 위키 사용자에겐 편하겠군요 ^^;;
현재의 맞춤법자체가 어중간한 상태이기 때문에, 위키안에서 쓰일 엄격한 맞춤법을 따로 만들지 않는 이상, 이것도 저것도 못될것 같습니다.(예를 들면 이곳에서는 페이지이름을 만들때 띄어쓰기대신 반드시 띄어 쓰기를 쓴다던지 하는식으로 말입니다.) 설사 LikePages를 정교하게 만드는 식의 대안을 만들어낸다고 해도 그것들 역시 잃는게 많을거 같고요.
대부분의 위키들이 페이지이름 띄어쓰기를 나름대로 구현했지만 사용하지 못한다는 것은 가슴아픈 일이네요. --bab2

제 생각에 가장 큰 문제라면 표준의 부재입니다. 초반에는 당연히 이런 저런 것들이 생겨날 수 있습니다만, 지금쯤 되면 표준화에 대한 논의가 시작되어서 텍스트포매팅 룰이나 띄어쓰기 정책이나 매크로 이름에 대한 것들은 공통적인 것을 써야합니다. 그런데 그런 움직임이 아직 없는것이 안타까워요. 위키 개발하시는 분들이 영리를 목적으로 하는 것이 아니라 개인 시간을 쪼개서 하시는 것이기 때문에 그분들께 많은 것을 기대하는 것은 염치없는 것이지만 개발 속도를 조금 늦추더라도 표준화 논의를 진행해주시면 어떨까 하는 소망을 저는 가지고 있답니다. --거북이
위키 표준 이전에 맞춤법의 띄어쓰기 복수 허용의 문제가 있기 때문에 띄어쓰기를 엄격하게 지켜지도록 현재 표준이 고쳐지지 않는다면 엄격한 위키문법을 만들 수 없겠죠. 현재의 맞춤법이 복수 허용을 하므로 위키 문법도 둘 다 허용하게끔 만들어야 하겠죠. 문제는 이것을 어떻게 구현하느냐인데, 표현은 띄어쓰기를 허용하고, DB는 공백 정보를 버리고 캐쉬(모인모인에서) 혹은 minor key 에 남기도록 하는 것이 지금으로서는 최소비용의 구현이 될 것으로 생각되네요. (위의 두번째 구현법)
MetaWiki를 다룰 때, 이러한 unique한 키를 구별하기 위해, 영문의 경우 다음의 방법을 사용합니다.
  1. -_,. 등등의 특수 문자를 페이지 이름에서 제거한다.
  2. 각 단어를 모두 소문자로 만들고 이어 붙인다.
즉, MeatballWiki에서 사용하는 MetaWiki는 그 key를 WikiName으로 하지 않고 모두 소문자로 이어붙여진 값을 사용합니다. 결국 유니크한 키를 만들기 위해 어쩔 수 없이 띄어쓰기 정보를 잃어버린 것이죠. 영문 WikiName에서도 이렇게 하는 이유는 Meatball:CategoryHomePage와 Meatball:CategoryHomepage'''''를 TwinPage로 같게 취급하기 위한 방법입니다. 이렇게 되면, 표현은 WikiName 혹은 wiki name과 같이 하게 되고, 내부적인 처리방식은 공백정보를 없앤 wikiname를 key로 사용하게 되죠. 결국, 마법의 WikiName으로 모든 예외사항을 처리할 수 없기 때문입니다. 이에 비하면 한글은 어절을 읽어버리지 않기 때문에 띄어쓰기를 없앤 unique한 키라 할지라도 한글 형태소 분석기를 갖추게 되면 띄어쓰기 정보를 적당히 되살릴 수 있겠지요.--고무신

아 사실 저는 Meatball:CategoryHomePage'''''와 Meatball:CategoryHomepage정도의 차이를 한글에서는 구분하지 않는 것이 경제적이라고 생각하는 것이지요. 즉 고무신님께서 최소비용의 구현일 거라고 말씀하신 것에 대해 동의합니다 :)
한글 형태소분석기까지 동원해서 하는 것은 너무 무거운 것이 아닐까 하는 생각이 드는군요. 형태소분석기는 앞뒤 문맥까지 고려해서 하기 때문에 잘못 판단하는 일이 종종 있는거 같더군요.
띄어쓰기를 복수로 허용하는 것을 모두 반영해주고 사람들 사이의 혼란을 줄이기 위한 최선의 방법은 역시 위키페이지 상에서 보여줄 때는 사용자의 표기 그대로를 보여주고 그것에 링크가 걸리거나 할 때는 띄어쓰기 정보를 무시하는 것이 가장 단순한 형태인 거 같아요. ^^ --KRock:거북이
참고로, 공개된 한글 형태소 분석기는 작년에 GPL로 공개한 이상호님의 KLE:KTS와 같은 방 연구실의 MoA가 있습니다. 이것을 여기에 써먹으려면 아직 갈길이 멀죠. ;) --고무신
노스모크에서는 영문의 경우 대문자가 들어가면 자연스럽게 한칸을 띄어서 표시해 준다. 하지만 한글은? 전혀 그렇지 못하다 그리하여 아버지가방에들어가신다와 같은 문제가 일어날 소지가 있다.
처음 노스모크를 만들 때(스위키시절부터)에 제가 고심을 했던 부분입니다. 띄어쓰기를 하지 말자는 결단은 대략 두 세 가지 정도에서 근거를 찾아볼 수 있겠습니다:

  1. 현대 한글맞춤법에서 띄어쓰기의 복수 허용 문제
가 있습니다. (성문화된 맞춤법을 떠나서, 사람들이 저마다 쓰는 띄어쓰기에 영어만큼의 엄격함을 기대하기는 힘들죠.) 조사가 붙는 경우라면 띄어쓰기에 여러가지 경우가 나오진 않을 것이지만, 복합명사 같은 경우 여러가지가 가능하죠. 이런 걸 일일이 법칙으로 만들고 지키려면 너무 부담이 클 것 같고, 그렇다고 맘대로 놔두게 되면 같은 제목에 다른 띄어쓰기로 이름 중복 문제가 생길 것 같았습니다. 특히 영어 페이지이름도 비슷한 식으로 띄어쓰기를 하거나 대소문자를 마음대로 섞어쓰는 사람들이 생길 것이고, 이는 곧 위키네임이라는 큰 장점을 사장시키는 결과를 가져올 수도 있다고 봤습니다.

  1. 페이지이름에 대한 인식 문제
이기도 했습니다. 페이지이름을 띄어쓰기를 하게 되면, 사람들이 이걸 위키에서 말하는 어떤 고유한 "단어"로서의 페이지이름(위키의 페이지이름은 "단어"입니다. 그게 하나의 커뮤니케이션 단위이기 때문이죠.)이 아니고 게시판에서의 게시물 제목 수준으로 생각하게 되는 어포던스가 있었습니다. 사실 위키에서의 페이지이름은 프로그래밍의 변수이름처럼 상당히 중요한 역할을 하는데, 붙여쓰기를 하게 되면 사람들에게 기존 의식틀에서 벗어나서 페이지이름이 고유한 것이고, 기존의 게시물 제목과는 다르다는 인식을 심어주는 데에 많은 도움이 되었습니다. 다른 원인도 있겠지만, 주변에서 페이지이름에 띄어쓰기 붙여쓰기 등 별 제한 없이 자유로운 곳일수록 페이지이름을 페이지이름으로 활용하지 못하는 경우를 많이 봤습니다. 만약 띄어쓰기를 허용한다면 오히려 더욱 엄격한 규칙과 이의 전파가 필요할지도 모르겠습니다.

하나의 규칙이 다른 규칙을 파괴하는 방향으로 작동하기도 합니다. 즉, 페이지이름띄어쓰기를 허용하면 기존의 다른 규칙들 다수가 점차적으로 사용자들에 의해 파괴될 수 있고, 또, 이를 막기 위해 더 많은 규칙을 만들어내고 더 많이 규칙 설파를 해야하는 상황이 올 수 있다는 거죠.

하지만, 위키교양이 충분한 사람들이 페이지이름띄어쓰기를 한다고 해서 문제가 있을 것 같지는 않습니다. 사실 페이지이름띄어쓰기를 하는 것이 전달 정보가 더 많지요.

그렇지만 또 띄어쓰기를 하지 않는 것이 크게 불편하지도 않은 것 같습니다. 처음 보는 사람들은 오해할 수 있겠지만, 제 경우, 대부분 해당 페이지의 내용을 한번 보고 페이지이름의 의미를 이해하고 나면, 다음부터는 잘못 읽고 싶어도 그렇게 되지가 않더군요. 특히 그 이름 자체가 음성화(vocalize)된 적이 한번이라도 있다면. 강력한 무의식 덕분이겠죠.

하지만 '질서도전이효과'같은 것은 내용을 아는데도 '도전'이 묶여서 들어오던걸요. --서상현
아예 다른 식으로 생각하면 어떨까요? 영어 WikiName 처럼 자연스럽게 쓸수 있는 규칙을 만드는 겁니다. 괜히 각괄호로 둘러싸지 말고요.

잘 생각해 보면 wiki name을 WikiName 이라고 쓴다고 해서 띄어쓰기의 정보를 잃어버리지는 않습니다. 요번 MoinMoin 0.11 에서는 preferences에 '위키이름 사이에 띄어쓰기 하기'(Add spaces to displayed wiki names)가 추가되어 있습니다. 제 생각에는 이게 훨씬 자연스러워 보입니다.

단어가 분리 안되는 것은 Wiki 자체에도 비효율(?)을 낳을 수 있다고 생각합니다. 노스모크에서는 거의 안 쓰는 것 같지만, 당장 WordIndex를 만들 수 없습니다. 또한 LikePages가 비슷한 page를 골라주지 못하고요.

원래 WikiName 이라는 아이디어는 Wiki:CamelCase에서 가져온 것으로 알고 있습니다. 프로그램 짤 때 변수 이름 쓰듯이 쓰게 하는 거죠. 사실 머리속에서 생각한 것을 옮기는 동안 방해를 덜 받기 위한 가장 좋은 방법이었구요. (HTML로 만들때에는 href name을 생각해야 하죠. 반복되기도 하고...)

그래서, 같은 방식을 대소문자가 없는 한국어, 일본어, 중국어 등에 적용하면 어떨까 생각합니다. 아버지가_방에_들어가신다와 같이 띄어쓰기 대신 특정 문자를 집어넣으면 WikiName으로 인식하게끔 하는 것이 어떨까 합니다. 조사와의 연결을 위해서는 노스모크_모인모인~에서는처럼 붙여야 할 부분을 표시하게 하고요.

우리나라에서 WikiWiki를 가장 많이 쓰는 여러분들께 의견을 듣고 싶습니다.

WordIndex는 별로 쓰지 않게 되더군요(해당 위키가 큰 곳일수록 더욱). 만약 특정 단어 찾기만 생각한다면 현재의 페이지이름 검색에서 string inclusion 검사를 해주고 있습니다. 그리고, LikePages는 꼭 띄어쓰기를 해야만 가능한 건 아니구요. (참고로 노스모크모인모인에서는 아버지라는 페이지에서 LikePages를 하면 아부지도 찾아줍니다.)

밑줄로 띄어쓰기를 대신하는 것은 저를 비롯 몇 몇 사람들이 생각을 했었던 아이디어입니다만, 역시 상기된 문제점들이 있습니다. 예를 들어 한 단어를 표기하는 방법이 필요할텐데, _아버지_ 라고 한다면, 분명히 _아버지가_방에_들어가신다_ 와 아버지가_방에_들어가신다 를 모두 사용하다가 점점 전자 쪽으로 옮겨갈 수 있습니다. 특히, 유럽사회운동연합회 같은 경우, _유럽사회운동연합회_일까요, _유럽_사회운동연합회_ 일까요 _유럽_사회_운동_연합회_ 일까요? 아님 이 모두를 하나로 자동 매핑시킨다면, 결국 띄어쓰기는 거추장스러워지는(redundant information) 건 아닐까요?

조사와의 연결 부분을 또다른 특수문자로 표기하는 방식은 사용자 입장에서 너무 비용이 큰 건 아닐까요? 거기서 얻는 이득이 얼마나 되나요? 제대로 된 지도 한장에서 얻는 이득이 몇 배 크다고 생각합니다만...

그리고 상대적으로 큰 문제는 아니지만, 한국어는 교착어이기 때문에, 영어위키이름과 달리 위키이름 뒤에 바로 조사를 붙이는 실수가 가능합니다. 예를 들어, in the RecentChanges는 문제가 없으나 새로_바뀐글에서는은 문제가 생깁니다. 위키이름 뒤에 조사가 와도 억지로 한칸 띄어줘야 한다는 것인데, 많은 사람들이 여기서 실수를 자주 하게, 이것은 계속 발생할 것이며(새로 들어오는 사람들이 있는 한), 쉽게 해결될 문제는 아닌 듯 합니다.


4천여 페이지중에 띄어쓰기로 된 페이지는 단 하나도 없습니다. 띄어쓰기를 허용하지 않는다면, 다음과 같은 방식으로 띄어쓰기 표현을 적극 권장할 수도 있습니다.
  1. 띄어쓰기 표현으로 링크한다 [노스모크의 위상과 현실]
  2. 보여주는 것은 띄어쓰기로 보여주되, 링크되는 페이지는 띄어쓰기를 무시한다. 즉, 위의 링크가 그대로 표현되고, 대신에 링크되는 페이지 이름은 노스모크의위상과현실
  3. WikiPedia에서는 이와 유사한 방법으로 [[Magic Number]]라고 링크를 걸면 그대로 표현되고, 대신에, Magic_Number라는 페이지로 링크된다.
위의 방식은 GnomeKorea:그놈한국위키제안에 처음 제안하였고, GnomeKorea는 이 방식의 띄어쓰기를 사용하고 있습니다.
-- 고무신
음.. 각 페이지의 unique 한 key는 띄어쓰기가 없게 하고, 실제 보여줄 때에는 띄어서(제일 처음이나 마지막에 띄어 쓴 방식으로..???) 하자는 뜻인가요? 개인적으로는 괜찮은 생각 같은데요? :) 유일하게 문제라고 생각되는 것은, "아버지가 방에 들어가신다"와 "아버지 가방에 들어가신다" 처럼 내용이 다른데 띄어쓰기를 없애면 key가 같아지는 경우일 듯 하네요. 그런데 그 경우라도 어짜피 현재 rule에서도 안되니.. ;) --지원
예. 맞습니다. 그리고 지적하신 부분은 완전히 띄어쓰기를 권장하지 않는 한 피할 수 없는 문제죠. 현재 노스모크에서 지원하는 두가지 링크방식, 하나는 ["나와 너"]와, 노스모크만의 방식인 [나와 너]가 있겠는데, 전자는 그대로 두고, 후자를 고치는 겁니다. 띄어쓰기는 허용하되, 무시하고 페이지 만드는 것으로요. -- 고무신
정확히 말하자면 단어 구분을 기계가 알 수 있어야하지 않겠느냐는 의미에서 LikePages와 조사 앞의 ~를 이야기 한 겁니다. 원래 LikePages는 단어를 기준으로 처리하는 것으로 알고 있고, 제가 보기에는 음절보다는 단어 가지고 맞춰 보는게 자연스러워 보여서요. 좀 더 정확하게는 띄어쓰기 정보를 잃어버리지 않았으면 좋겠다는 생각이고요.

하나짜리 단어에 대해서는 기존의 각괄호(+따옴표) 스타일을 쓰게끔 하는게 좋다는 생각입니다. 영문에서도 대문자 하나짜리는 WikiName이 되지 않쟎아요?

그리고, 띄어쓰기를 어떻게 할 것인가는 기본적으로 맞춤법에 의거한다고 보는 것이 맞지 않나요? (이름 이외의 고유명사는 단어 별로 띄어 씀을 원칙으로 한다) 물론 맞춤법이 여러 변형을 허용하고 있기 때문에 혼란이 있을 수 있고, 실제로는 띄어쓰기가 잘 지켜지지 않기 때문에 의미가 없을 수 있다는데는 동의합니다만... (원래 LikePages가 이런 page들을 찾아주는 것 아니었나요? 비슷한 pattern의 문서 찾기라는 의미에서...)
여러곳을 통해 거듭 말씀드렸지만 맞춤법에 의거하는 것이 제대로 안됩니다. 별도의 법칙을 만들어야 합니다.

원래 의도는 글을 쓰면서 formatting에 신경을 되도록이면 안 쓰게 하면 좋겠다는 겁니다. 기존의 case rule은 쓰면서도 대단히 자연스러운데, 각괄호 규칙에다가 띄어쓰기없애기는 상당히 부자연스럽다는 생각이 듭니다. 그에 비해 띄어쓰기 대신 글자 넣기는, 영문에서 space 대신 shift누르기 만큼 자연스럽지는 않더라도 대충 비슷하지 않을까 하는데요.

(이상하게도 저는 각괄호를 넣기 위해서 항상 화살표 키를 쓰거나 mouse click을 해야 하더군요. 게다가 이미 띄어 쓴 단어를 다시 붙여 쓴다는 것은 매우 부자연스러워 보였습니다. 물론 제가 이상한 것일 수도 있지만...)

뭐, 그렇다고 지금의 규칙을 없애자는 것은 아닙니다. 이런 식의 고려도 해 볼 수 있지 않을까 해서요. 사실 Wiki의 특징중에 하나가 page를 만들때 모양(formatting)을 생각하지 않아도 되게함으로써 원래 적어 넣으려던 아이디어를 까먹지 않게 한다.라고 알고 있는데, 이 특성이 한국어에서는 많이 사라지는 것이 아닌가 해서 질문을 던져 봅니다.

밑줄을 사용하는 것은 과거 스위키에서 옮겨올 때 생각을 하지 못했었습니다. 그 후에 생각을 하게 되었죠. 그도 그럴 것이 스위키에서는 모든 이름에 좌우별표(*)를 사용했기 때문이고, 모인모인 자체에서 확장위키이름은 [" "]를 사용했기 때문입니다. 거기에 길들여졌던 것이죠(TunnelVision). 밑줄 사용의 장점은 충분히 이해합니다. 하지만, 지금 고치기엔 조금 조심스러워야 할 것 같습니다. 고치는 비용이 매우 높기 때문입니다. 다른 곳에서 사용하는 것을 한 달 정도만이라도 좀 두고본 후에 논의를 더 진행하면 좋을 듯 합니다.

그리고 띄어쓰기 정보는 사용자들이 페이지이름 작명에 신경을 쓰고 잘 한다는 전제가 먼저 충족되어야 그 가치가 있습니다. 하지만, 1년 넘게 노스모크를 지켜보면서 느끼는 것은 대부분의 사람들이 그렇게 하도록 유도하는 것은 꽤 힘들다는 점이었습니다.

그리고 다른 영문 위키에서도 띄어쓰기 정보(혹은 단어절단 정보)가 그렇게 유용하게 쓰이고 있지는 않습니다. OriginalWiki의 LikePages 경우는 첫 단어와 끝 단어가 일치하는 페이지이름만 보여줍니다. 노스모크모인모인에서는 영문경우 첫단어/끝단어로, 한글경우 첫N바이트/끝N바이트로, 그리고 fuzzy string match를 통해 유사한 페이지이름까지 보여주고 있습니다.

어찌되었건 다른 위키 사이트에서 밑줄을 위키이름에 사용하는 것에는 반대하지 않습니다. 오히려 그러한 실험들을 적극 격려하고 싶습니다.


'띄어쓰기'는 띄어 써야할 것인가(띄어 쓰기), 붙여써야 할 것인가(띄어쓰기)도 한때 논란이 되었다고 합니다.. :)

어찌보면 이 페이지는 '페이지이름붙여쓰기'가 되어야할 것이지만, 전통적인 '띄어쓰기'의 권위에 의해 '페이지이름띄어쓰기'가 되었죠. 예전에는 글을 다 줄줄이 붙여썼기 때문에 새로운 표기법으로 단어별로 띄어쓴다는 개념이 성립했으니까. B)

근데... 질문 있습니다. 띄어쓰기 라는 말은 명사로 있는데요. 원래 동사는 띄우다 에서 나온거자나요? 띄어쓰다 라는 동사는 없는 걸로 알고 있습니다만 그러면 띄워 쓰다 가 맞는 말 아닌가요? 참고 : [http]http://kordic.britannica.co.kr/sear_content.asp?id=13009&cid=0 --홍차중독
'띄어쓰기'의 '띄어'는 '띄다'에서 온 것입니다. 띄다는 띄우다의 준말이고요. 결국 같은 뜻이지만 어쨌든 틀린 말은 아닙니다 :) http://kordic.britannica.co.kr/sear_content.asp?id=13003&cid=0
PuzzletChung은 굳이 페이지이름띄어쓰기의 구분이 필요하지 않다고 생각합니다. &아버지가방에들어가신다&와 띄어쓰기조심에 링크된 페이지들과 같이 띄어쓰기에 따라 의미가 바뀌는 경우는 아주 적습니다. 정말 예외적인 경우로 Jangnan:20세기소년시리즈가 있습니다만... 그런 경우에는 한 페이지에 두 가지 페이지이름에 따라 두 가지 내용을 적거나 아예 다른 이름의 페이지(예: &장난학위키의20세기소년시리즈&)를 만드는 방법도 생각해 볼 만 합니다. 그리고 자동으로 링크가 걸어질 수 있는 WikiName을 위하여 단어 사이에 특수문자를 삽입하는 것도 거부감이 있을 수 있습니다. 아무튼 제가 생각하는 방법은 이것입니다.
  • 하나의 페이지에는 띄어쓰기가 없는 페이지이름과 띄어쓰기를 포함한 페이지이름이 저장되어 있다.
  • 내부적으로 처리되는 실제 페이지이름은 띄어쓰기가 없는 것을 쓴다.
  • 링크 안의 페이지이름에 띄어쓰기가 포함되어 있을 경우 띄어쓰기를 없애고 해당되는 페이지이름으로 이동한다.

김민수는 띄어쓰기는 반드시 필요하다고 생각합니다. '위키'이기 때문에 더욱 더 한글에서의 띄어쓰기를 지원해야 한다고 생각합니다.
ExtractFrom 한글문화원

AnswerMe 그렇군요. URL 뒤에 한글 문화원이라고 쳐서 새 페이지를 만드는 것이 아니고 URL 뒤에 그냥 한글 문화원이라고 쳐서 새 페이지를 만드는 거군요. 그러면 페이지 이름 띄어쓰기와 페이지_이름_띄어쓰기, 페이지이름띄어쓰기가 어떻게 처리되는지 궁금하군요. 잠깐 해 보니까, 현재는 붙여서 만든 페이지와 띄어서 만든 페이지가 따로 처리되는 것 같은데요? --hopark

헉! 원래 "페이지이름띄어쓰기"로 만든 페이지에는 "페이지 이름 띄어쓰기"와 같이 링크를 넣으면 연결이 안 되는군요. --hopark

또 한 가지 한글 처리 부분에 발견한 문제가, 사실 노스모크 위키에서 처리할 문제는 아닌 것 같고 모질라에서 처리해 줄 문제인지 것 같지만, "http://no-smok.net/nsmk/한글 문화원"이라고 입력하면 "http://no-smok.net/nsmk/한글 문화원"으로 처리하여 MS Windows용 모질라에서는 "한글 문화원"이라는 페이지를 위키에서 잘 만들려고 하는데, 맥 OS X에서는 오직 IE만 이런 처리를 잘 해 주고, 나머지 사파리, 모질라, 까미노에서는 다 한글 인코딩을 유니코드로 만들어 버려 제대로 처리가 되지 않는 문제가 있군요. 모질라 커뮤니티에 가서 또 버그 리포트 해야 되겠네요. --hopark

다른 방법은 URL을 EUC-KR(CP949)로도 유니코드(UTF-8)로도 해석해 보아서 둘 중 제대로 해석 가능한 놈을 택하는 방법이 있습니다. 결국은 UTF-8 쪽으로만 가야겠지만 임시로 이런 방법을 쓰고 있습니다(현재 노스모크에서는 EUC-KR만 취합니다). --김창준

네, 답변 감사합니다. 맨 위에 문단을 답변 요청으로 바꾸었습니다. :) --hopark

"; if (isset($options[timer])) print $menu.$banner."
".$options[timer]->Write()."
"; else print $menu.$banner."
".$timer; ?> # # ?>