Wiki Name토론
|
CamelCase에 의한 WikiName을 엄격히 적용하는 건 어느 정도 규모가 되기 전까지는 충돌이 많을 수 밖에 없다고 생각합니다. kz도 위키에 폭 빠져서 GnomeKorea의 몇몇 프로젝트에 대해 페이지이름을 막 바꾸려고 시도한 적이 있습니다. KoPoCheck, ImHangul이 그런 경우인데요. 지금은 AliasPageNames 기능을 통해 개발자가 의도한 페이지로 넘겨주는 선에서 타협이 이루어졌습니다. 지금에 와서 생각해보건데 굳이 어느 한쪽이 맞다고 고집하고 그쪽만 하자고 주장하는 건 의미가 없다고 생각합니다. 너무 열내지 말자구요.
비용과 편익면에서 서로 비슷하면 기술적으로 공존하는 게 생산적이라고 생각합니다.
우발적 링크가 걸리는 건 분명 의미 있는 일이고, OriginalWiki의 권위랄까, 그런 것도 무시할 수 없는 편입니다. 아무도 그렇게 하지 않으면 어쩌겠냐고 하는데, OriginalWiki에 있으면 대부분이 그걸 따릅니다. 믿어주세요. 여기저기 위키를 다니다보니 그렇습디다. 우리나라에선 노스모크가 그런 기준이 될 텐데, FOSS에선 KLDPWiki가 그런 위치가 되리라고 생각합니다. 여기 말곤 없으니까요.
페이지 이름을 지을 땐 조금만 더 생각해주세요. 꼭 WikiName일 필요는 없지만 너무 이상한 이름이면 다른 데서 그 페이지를 참조할 때 힘들고, 따라서 그 페이지가 참조될 가능성이 적어지고, 그만큼 가치가 떨어지는 겁니다. 구글에서 쓴다는 pigeon rank 시스템이 뭔지 생각해보시면 이해하실 겁니다. 서산대사가 짓고 김구 선생이 즐기셨다는 말 있잖습니까. 지금 내가 지은 페이지 이름이 다음 사람의 검색어가 되리니.
지금부터 나오는 내용은 토론의 본문입니다. 한 번 읽으시고, 다음으로 페이지이름 토론으로 넘어가보세요.
SubVersion› vs Subversion ¶SubVersion은 틀린 표기법 입니다.
Subversion은 단어 Subversion이지 Sub + Version이 아닙니다.
http://subversion.tigris.org/project_status.html
여기 릴리즈된 파일이름을 참조하십시오. SubVersion으로 오기 하는 일이 없도록 합시다.
궁금해서 그러는데, subversion이 sub + version이 아니라는 얘긴 근거가 있는 것인가요? 물론 특정 프로젝트 표기할 때 대소문자를 어떻게 할 것인지는 이름을 지은 사람들이 결정할 문제고, 그렇다고 해서 페이지 이름을 WikiName으로 표기하는게 오기라고는 생각하지 않습니다만, 단정적으로 적혀 있으니 궁금해 지는군요. --verotas
SubVersion으로 바꾸는데 한표 던집니다. 이전에는 이렇든 저렇든 별 신경을 쓰지 않았는데, http://moniwiki.sf.net 에 와서 이 페이지 이름을 근거로 내용을 수정해야 한다는 분이 계시더군요.
굳이 근거로 삼자면 일단은 Subversion으로 하고, 누군가가 또 이의를 제기한다면 SubVersion› 페이지를 만들어 #redirect시키던지 하겠습니다. --WkPark
subversion은 subvert의 명사형 단어로서, 전복, 파괴란 뜻입니다. WikiName에도 맞고 어근도 살리려면 SubverSion이라고 쓰는 게 더 적절할 것입니다. SubVersion은 서브한 버전이란 뜻인데, 이게 전복, 파괴와 어떤 상관이 있나요? --방준영
프로젝트 공식 웹사이트에는 Subversion이라고 버젓이 나와 있는데 "Sub + Version"이라는 해석의 근거는 도대체 어디지요? 인터넷의 영어 표기를 Internet이 아닌 InterNet이라고 주장하는 꼴입니다. 물론 후자를 공식적으로 쓰는 경우는 최근 몇년 동안 한번도 본 적이 없네요. --방준영 네. OriginalWiki에서 그렇게 하고 있습니다. OriginalWiki는 일반 위키위키의 지침과도 같기 때문에 위키위키식이라고 우겨도 그다지 잘못된 것은 아닙니다. 괄호를 하느냐, 괄호를 쓰지않고 낙타식 이름(CamelCase)을 쓰느냐의 차이정도로 여길 뿐입니다. --WkPark
말씀대로라면 OriginalWiki가 아니라 OriginAlWiki가 맞겠군요. Origin도 어근을 쪼갤 수 있다면 OrigInAlWiki가 맞는 것일지도 모르겠습니다. --방준영
두 가지 오해가 있는 것 같습니다. 첫째, 저는 "Sub + Version"이라는 해석을 주장한게 아니라 단정적으로 저게 아니라고 주장하는 것에 어떤 근거가 있는지 여쭤 본 것입니다. 의미상으로만 놓고 보면 버전 컨트롤 프로그램 이름을 subversion이라는 단어 뜻만 보고 지었다고 생각하는게 더 억지스러워 보이기도 하고요. 둘째, 영어표기와 WikiName과 무슨 상관이 있나요? 특정 단어가 상호나 상표, 제품명으로 쓰일 때 case를 어떻게 쓰는가는 어디까지나 CI/BI의 영역이지 올바른 철자법과는 아무 상관이 없습니다. 예를 드신 internet도 위키 페이지를 만든다면 InterNet이 더 자연스럽습니다. Subversion이라고 앞에 대문자 뒤를 전부 소문자로 적는게 그 프로젝트를 진행하는 분들이 정한 거라면 그건 좋습니다만, 그렇다고 해서 위키 페이지 이름까지 꼭 그렇게 해야한다고 주장하거나 심지어 다른 사람들이 적어 놓은 글에서 대소문자만 골라서 고쳐 놓는 것은 이해하기 어렵습니다. Subversion 프로젝트에서 릴리스한 rpm 바이너리만 봐도 Subversion-*.rpm이 아니라 subversion-*.rpm으로 돼 있지 않습니까? 왜냐하면 소스나 rpm 등을 릴리스할때는 프로젝트 이름 표기법과는 상관없이 전체를 소문자로만 표기하는게 여러 모로 좋더라는 오랜 기간 시행착오를 거쳐 형성된 암묵적인 규칙이 있기 때문입니다. 비슷한 이유로, 특정 프로젝트 이름이 어찌됐건 간에 WikiWiki에서 페이지를 만드는 나름대로 규칙이랄까 convention이랄까가 있으니 거기에 따르는게 더 좋지 않겠느냐는 주장을 하고 싶었던 것입니다. 이런 생각이야 사람마다 제각각 달리 할 수 있는 것이고 제 주장이 절대적으로 옳다고 얘기하고 싶은 생각은 전혀 없습니다만, 제가 하지 않았던 얘기까지 지나치게 확대해석하지는 말아주시면 좋겠습니다. --verotas
Subversion이라는 단어를 SubVersion이라고 쓰면 뜻 자체가 완전히 달라질 뿐더러, sub-는 단어가 아니라 접두사입니다. 접사, 어근까지 두문자 처리를 해야 한다면, project는 ProJect라고 써야 하나요? development는 DevelopMent로요? subversion의 뜻을 사전에서 먼저 찾아보고 이의를 제기하시면 감사하겠습니다. --방준영
제가 앞장 서서 이의를 제기한 것도 아니고, 이의를 제기했다 하더라도 subversion이라는 특정 단어에 대해 시비를 가리려고 한 것도 아닙니다만 제가 드린 다른 질문은 생략하고 이것만 따져물으시니 난감하군요.
그나저나 Subversion과 SubVersion이 뜻 자체가 완전히 달라진다는건 무슨 얘긴가요? 충고해주신 대로 subversion이라는 단어에 혹시라도 제가 미처 모르는 다른 뜻이 있는지 몇 달 전 Subversion 페이지가 생겼을때 이미 찾아보았습니다만, case에 따라 뜻이 달라진다니 잘 이해가 안가는군요. 제가 뭔가를 착각하거나 오해했을 수도 있으니 귀찮으시더라도 설명을 좀 부탁드립니다. --verotas
로고가 이렇게(SUB+VERSION) 생겼는걸요. 저는 처음에 subversion이라는 프로젝트 이름이 중의적으로 해석될 수 있다는 점을 고려해서 지은게 아닐까 추측했습니다. 하나는 submit + version 쯤 될테고 다른 하나는 CVS라는 강력한 경쟁상대를 뒤엎겠다는 야심을 표현한 것이겠죠. KarlFogel을 비롯한 SubVersion› 핵심 개발자들이 CVS에 기능 추가나 개선 등을 꾸준히 건의했지만 받아들여지지 않아 결국 완전히 새로운 프로그램을 만들게 됐다는 점 때문에 더 그렇습니다. 제 이런 추측이 전혀 근거 없고 잘못됐을 수도 있겠습니다만, subversion이 sub + version 으로 해석되면 곤란하고 단지 전복, 파괴라는 뜻만 가져야 한다면 뭔가 대단히 잘못된 naming이라는 생각도 드는군요. 설명해 주신 사실들은 저도 이미 알고 있는 것입니다만, 거기에 대한 해석은 결과적으로 반대네요. 하나만 더 토를 달자면, WikiName을 만들때 나누는 기준은 그냥 음절 단위인 걸로 압니다. 굳이 어근을 따져서 살려야할 이유는 잘 모르겠군요. --verotas
WikiName이 엄격한 것은 OriginalWiki만의 규칙입니다. 하지만 그동네에서도 단어 하나짜리인 것을 억지로 WikiName으로 만들어서
좋은 지적 감사합니다. 그런데 아무리 생각해도 제가 보기엔 UgLy와 SubVersion은 경우가 좀 다른 것 같군요. 그리고 SubversionProject 라고 만들었을 경우에는 글 중간에 언급할 때 부자연스러운 경우가 생기지 않을까요? 예컨대 SubversionProgram 이나 SubversionPackage, SubversionBinary 등을 구분해야할 일도 있을 것 같고요. OriginalWiki에선 이런 경우 어떤 식으로 해결하나요? --verotas
기존 텍스트에 스며들어가면서 WikiName의 규칙에 맞고 우발적 링크를 걸리기 쉽게 한다면 그것이 바로 좋은 WikiName입니다. 따라서 SubVersion은 OriginalWiki의 관점에서 잘 만들어진 페이지이름입니다. 위키위키의 WikiName규칙에 의해서, Subversion으로 하면 링크가 걸리지 않습니다. 제가 보기엔 방준영님이 제기하신 문제는 위키위키에 익숙하지 않기때문으로 보입니다. --WkPark
위키에 익숙하지 않은 것은 사실이지만, 우발적 링크라는 건 이해가 안되네요. 아무도 Subversion을 SubVersion이라고 표기하지 않는데 어떻게 SubVersion›에 대해 우발적 링크가 걸릴 수 있죠? Intel을 우발적 링크가 걸리게 하기 위해 InTel이라고 쓰고, Samsung을 SamSung처럼 쓰는 것은 WikiName으로는 문법이 맞을지 몰라도, 그렇게 표기하는 사람이 실제로 있습니까? --방준영
아무도 Subversion을 SubVersion이라고 표기하지 않는데라고 말씀하신건 "만약 아무도 ...... 않는다면"이라는 뜻이겠죠? 위키에 익숙한 사람이라면 SubVersion이라고 적는게 자연스럽습니다. (제가 위키에 아주 능숙하다는 뜻은 아닙니다.) WikiName으로는 문법이 맞을지 몰라도라는 표현을 보고 문득 든 생각이지만, WikiName 규칙은 프로그래밍 언어로 치자면 문법 보다는 그냥 스타일이나 컨벤션에 가깝습니다. 제가 위에도 언급했지만 정작 Subversion 프로젝트에서 릴리스한 소스코드나 바이너리 패키지들은 이름이 subversion-* 으로 돼 있듯이, 브랜드 네이밍 차원에서 Capitalization 방식을 정한다 하더라도 쓰이는 장소나 용도에 따라 얼마든지 달라질 수 있는 것이고, 위키에 페이지를 만들 때는 WikiName 작명 규칙 또는 관례에 따를 수 있는 것 아닌가요? 지금 문제가 되고 있는 것은 Subversion이라는 프로젝트를 이렇게 쓰느냐 저렇게 쓰느냐 보다는 오히려 위키 방식에 따른다는 이유로 잘못된 표기를 하지 말라는 주장 때문에 문제가 되고 있다고 느낍니다. 저는 그냥 경우에 따라 다른 표기 방식이 존재할 수 있고, 위키에서는 위키 방식대로 하는게 더 자연스러울 수 있지 않느냐는 의견을 제시하고 싶었을 따름입니다. --verotas OriginalWiki에서는 WikiName이 단순히 스타일이 아닙니다. WikiName규칙을 지키지 않으면 페이지를 만들수도 링크를 걸수도 없습니다. 전혀요 ^^;; --WkPark
네, 그렇다 하더라도 지금 주제가 OriginalWiki에 있는
전에
위키에서는 뭐뭐뭐HOWTO 대신 뭐뭐뭐Howto를 쓰는 게 우발적링크를 유도하며, 다른 곳에서 문서를 참조할 때 기호를 쓰지 않아도 되므로 더 좋을 것 같습니다. 앞으로 만들게 되는 HOWTO 문서는 뭐뭐뭐Howto 형식으로 쓰는 게 좋을 거라 생각합니다.
혹시 Subversion을 선호하는 분이라면, 주장에 보탬이 될 내용이 있습니다. MoniWiki에서는 AliasPageNames를 지원합니다. MoniWikiDev 사이트를 살펴보시면 정보를 얻을 수 있습니다. kz가 한동안 써본 바로는 GetText 기반으로 처리되는 현재의 다국어 번역까지도 대체할만한 가능성이 보입니다.
AliasPageNames를 config.php에서 활성화 시켜 놓았습니다. -- WkPark 2006-07-18 11:10:41
|
Preserve the old, but know the new. |











비용과 편익면에서 서로 비슷하면 기술적으로 공존하는 게 생산적이라고 생각합니다.
아래 토론이 있었던 뒤로
굳이 근거로 삼자면 