페이지 이름 띄어쓰기
|
See also
 페이지이름띄어쓰기
아래의 토론을 읽어보신 후에 자신의 의견을 투표하시기 바랍니다. 중복 투표를 막기 위해 Whois를 켜놓았으며 자신이 투표를 했을 경우는
 아이콘을 누르면 히스토리에 나오게 됩니다.
![/!\](/imgs/smile/alert.png "/!\") 투표 종료
참고적으로, MoniWiki에서는 위의 첫번째 방식의 링크는
[페이지 이름]과 같은 식으로 링크를 걸고 두번째 방식으로 하려면 ["페이지 이름"]과 같이 링크를 걸어야 합니다.(모인모인에서 쓰는 방식)
투표는 단지 여러분들의 생각이나 의견을 묻는 것입니다. 특별한 의미는 두지 마시고 자유롭게 투표해 주시기 바랍니다. --WkPark
이 투표는 그 자체로 의미가 있긴 하겠지만, 위, 아래의 논의와 직접적인 연관이 있는 것 같지는 않습니다.
(지울 것 까지는 없고 옮기면 어떨가요)
연관이 있는 투표라면 차라리 "띄어 쓸 수도 있고 붙여 쓸 수도 있는 이름을:" 1) 무조건 붙인다, 2) 무조건 띈다, 3) 사례 별로 다르게 중 하나를 선택하는 게 되겠죠. 그러나 투표로 할 만한 일인지는 또 다른 문제일 것입니다. --류광
역시 KLDP위키토론 에서...
{{|
띄어쓰기 문제는, 띄어쓰기를 공식적으로 금지하는(했던) 곳도 있고, 꼭 그렇지는 않더라도 그냥 별 생각없이 페이지 이름을 붙여쓰는 경우를 많이 봤습니다. 그냥 희망일 뿐입니다만,
띄어쓰기를 지지하는 한 사람으로서, MoniWiki도 따옴표 없이 대괄호만 사용하게 되길 바랍니다. WordIndex 역시 마찬가지로 개별 한글 단어에 대한 처리를 적극적으로 고려해 주시길. 그리고 배포판의 기본 페이지(시드 페이지)들 중 하나에 띄어쓰기 금지 또는 비권장에 대한 내용이 포함되는 일도 없길 바랍니다....
--류광
논외라고 생각되지만, 짚고 넘어가겠습니다. 띄어쓰기 문제는 간단한 문제가 아닙니다.
노스모크에서 논의가 있었지만, 띄어쓰기 복수 허용 문제때문에 띄어 쓰기와 띄어쓰기가
다릅니다. 그러나, 이것은 일종의 낭비라고 보고, 노스모크에서는 모두 띄어쓰기 하지 말것을
권장하는 식이였죠. MoniWiki는 노스모크 식의 Single Bracket을 사용하고 (DbWiki도 이걸
사용하는군요
.png ":)") ) 이와 더불어, 띄어쓰기와 띄어 쓰기가 같은 페이지인 띄어쓰기로
링크가 걸립니다. 띄어 쓰기를 허용하되, 실제로 저장되는 페이지는 띄어쓰기가 무시되는거죠.
굳이 띄어 쓴 페이지 이름을 만들기 위해서는 모인모인의 extended wikiname 방식인 띄어 쓰기를
사용하면 되겠고요. 모니 위키는 띄어 쓰기 복수 허용문제를 허용하며 띄어쓰기 표현을 장려합니다.
--WkPark
|}}
우선, 노스모크에서 띄어쓰기 논의가 된 것은 알고 있습니다. 그러나 띄어쓰기가 본격적으로 시도된 적은 없었고, 비교적 초기부터 붙여쓰기로 고정되어 있었다고 알고 있습니다.
그리고 현재의 단일 대괄호의 작동 방식은 복수 허용 문제를 기계적으로 해결하는 것이라고 봅니다. 페이지 이름 역시 페이지의 내용처럼 시스템을 통해서 결정할 것이 아니라 사용자들이 서로 논의하고 협의할 대상일 뿐입니다. 띄어 쓰기와 띄어쓰기 둘 다 동등한 기회를 줘야 합니다. 예를 들어 현재 초보자 코너 페이지가 만들어져 있는데,
그 페이지를 만든 (그리고 링크를 건) 분의 진짜 의도가 '초보자코너'였을까요? 혹시
띄어쓰기가 된 '초보자 코너'였는데 단일 대괄호의 작동 방식을 잘 몰랐던 것이 아닐까요?
물론 그런 규칙을 잘 알리면 되는 문제이긴 하겠지만, 띄어쓰기를 왜 확장된 위키 이름이라는 특별한 규칙으로 사용해야 하는가는 여전히 납득할 수 없습니다. 그런 방식은 위에 쓰신 대로 "굳이 띄어 쓴 페이지 이름을 만들기 위해서는"이라는 문제의식에서 출발한 것이라고 보구요.
결론적으로 말하면, 단일 대괄호 방식과 대괄호+따옴표 방식을 바꿨으면 좋겠다는 것, 그리고 띄어쓰기에 대해 전향적인 태도를 가질 필요가 있지 않는가 하는 것입니다.
띄어쓰기의 필요성에 대해서는 딱 한 가지만 간단하게 이야기하겠습니다. 일단 띄어쓰기는 어렵다, 혼란스럽다 같은 말은 한국어를 사용하는 사람이 할 말은 아닌 것 같구요. 무엇보다도, 띄어쓰기는 한글 위키 이름을 구성하는 단어들에 대한 정보를 유지하기 위한 가장 유력한 수단이며, 붙여쓰기는 단어에 대한 정보를 손실시키는 행위라는 점입니다. 단어 구성에 대한 정보는 가독성 문제만큼이나 중요합니다. 가독성은 현재의 단일 대괄호 방식으로 어떻게 해결이 되겠지만, 단어 구성에 대한 정보는 (어휘사전과 자연어 처리가 도입되지 않는 한) 붙여쓰기로는 도저히 해결이 되지 않습니다.
위에서 WordIndex를 언급한 것도 그런 이유입니다. 일단, WordIndex는 위키에서 대단히 유용한 기능이라고 생각합니다. WordIndex는 이 위키에서 어떤 것들이 논의되고 있는지를 페이지 이름을 구성하는 단어들을 통해서 알려주며, 그 때문에 페이지 이름 작성 시 어떤 단어를 써야 할지 결정하는데 지침이 됩니다. 한글 위키 이름의 경우 어떤 단어를 띄어 써야 하는지에 대한 지침이 되구요. 예를 들어 http://www.gpgstudy.com/gpgiki/WordIndex 의 'ㅈ'의 항목을 보면, 저 위키에서는 정오표라는 단어가 자주 쓰이며, 또한 그 단어를 지금까지 띄어 써왔다는 점을 알 수 있습니다. 띄어쓰기가 없으면 이런 활용은 불가능합니다.
이런 측면은 LikePages도 마찬가지입니다. LikePages는 원래 페이지 이름의 첫 단어와 마지막 단어를 검색하는 기능입니다. 모인모인 계열은 붙여쓴 이름을 위해 처음 몇 글자, 끝 몇 글자를 검색하는 식으로 알고 있는데, 일종의 편법이라고 생각합니다. 예를 들어 '페이지이름'의 비슷한 페이지가 '페이퍼모델' 또는 '페이지불수준'라고 나올 수도 있으니까요.
어떤 한 위키가 띄어쓰기를 사용하느냐 마느냐는 그 위키의 문제이라는 점에는 동의합니다. 그러나 지금까지 띄어쓰기가 위키 엔진 차원에 은연중에 억제되어 왔다는 생각을 떨칠 수가 없네요. KLDP 위키부터 바로잡아 나갔으면 합니다.
--류광
저의 접근 방법은 실용주의입니다. 그렇게 해야 한다는 것과 구현 비용은 차이가 있는 경우가 있습니다. 띄어쓰기가 바로 그러한 예이죠. 구현 비용이 가장 간결한 것은 유니크한 키를 가지는 띄어쓰기가 없는 key입니다. '초보자 코너'와 '초보자코너'는 같은 페이지를 가리켜야 정상입니다. 예를 더 좋은 예를 들어주세요. 띄어쓰기가 소실되어서 의미 소실을 가지는 예는 거의 없다고 봐도 무방합니다. 구현 비용 측면에서 그렇다는 것입니다.
타이틀 바에 띄어쓰기 표현이 되지 않는것이 문제라면 문제인데, 이것도 해결할 수는 있고 방법도 있습니다. (http://kle.kldp.org/moin.php/옛한글을 참조하세요) 그러나 MoniWiki에 적용하지 않았습니다. 구현 비용이 많다고 판단했기 때문입니다. (코드가 길어집니다)
여러 문제가 있을 때 가장 간결한 해법이 가장 좋은 방법입니다. 띄어 쓰기 복수 표준에 대한 완벽한 해법은 없습니다. 다만 가장 근접한 해결법이 KLE에서 제시되었고, 모니위키에는 적용하지 않았습니다.
이 해결법이 아니라면, 류광님이 구현하신 방법을 제시해 주시길 바랍니다.
단일 대괄호 방식과 대괄호+따옴표 방식을 바꿨으면 좋겠다는 것의 구체적인 의미는 두 방식을 맞바꾸자는 것입니다. 즉 단일 대괄호에서 띄어쓰기를 그대로 유지하도록 하고 붙여쓰기로 변환하는 것은 대괄호+따옴표로 하자는 것입니다. 전향적인 태도의 구체적인 의미는 그 아래 글과 지금 이 글로 대신할 수 있을 것입니다.
제가 제시하는 방법은 이미 위에 나와 있습니다. 페이지 이름 역시 페이지 내용처럼 고민하고 합의할 대상이라는 거죠.
예를 들어 초보자 코너냐 초보자코너냐는 사용자들이 합의를 하면 되는 문제이고,
다만 합의가 일어나는 과정에서, 띄어쓰기에 대한 시스템 차원의 제약이 있어서는 안 된다는 것입니다. 현재의 단일 대괄호는
띄어쓰기의 여지를 아예 없애버리는 것이고, 대괄호+따옴표는 번거롭다는 점에서 역시 띄어쓰기를 비권장하는 것이라고 봅니다.
초보자 코너의 예를 좀 더 확장하겠습니다. 우선 처음에 페이지를 만들 때, 초보자 코너이냐 초보자코너이냐가 고민이 될 것입니다. 선택하는 기준은 초보자나 코너가 다른 페이지 이름들에도 쓰일만한 단어인가를 생각하는 것입니다. 그리고 WordIndex도 참고하구요. 이미 코너, 초보자 같은 단어가 등록되어 있다면 띄어쓰는 게 좋겠죠.
다른 페이지에서 링크를 걸 때 역시 초보자코너였는지 초보자 코너였는지 기억이 나지 않을 수 있습니다. 이 때에는 미리보기를 사용하면 됩니다. 초보자코너라고 괄호를 쳤는데 링크가 제대로 걸리지 않는다면 초보자 코너인 것입니다. 간단하죠?
좀 더 극단적인 예를 들까요? 일반적으로 사람 이름은 성과 이름을 붙여씁니다. 그러나 예를 들어 축구팬 위키 등 일종의 인명 사전 같은 역할도 하는 위키라면 황 선홍 황 승주 서 정원 서 혁수 등으로 띄어쓰기를 하는게 더 도움이 될 수도 있습니다.
이런 고민이나 과정이 번거롭다고 느끼신다면, 한국어에서 띄어쓰기가 어느 정도 중요한 것인지를 다시 생각해 보셨으면 합니다.
구현 비용을 이야기하셨는데, 미리보기나 WordIndex 등의 도움이 있으면 될 문제이고, 또 단어 구성 정보를 유지하는 것은 구현비용을 상쇄하고도 남는다는 생각입니다. 이 문제에서 핵심은 페이지 이름의 단어 구성 정보를 얼마나 중요하게 생각하느냐인 것 같습니다.
타이틀 캐쉬 #1 ¶
제 말을 잘못 이해하신 것 같은데요. 제가 주장하는 단일 대괄호 용법에서는 리눅스 설치하기와 리눅스설치하기는 다른 페이지를 가리켜야 합니다. 그러나 그것이, 하나의 위키에서 띄어쓰기만 다른 두 페이지가 존재해도 좋다는 뜻이 아닙니다. 당연히 둘 중 하나로 고정시켜야 하구요. 그러나 그게 반드시 붙여쓰기 버전일 필요는 없다는 것입니다. 제 주장이 띄어쓰기만 다른 페이지들이 여러 개 존재해도 상관없다는 뜻이라고 받아들이셨다면 제가 표현을 잘 못 한 것입니다. 어쨌든 그런 이유로 위의 투표는 별로 의미가 없습니다.
제 얘기는 기계적으로 붙여쓰기로 고정시키는 규칙을 좀 더 특별한 것으로 취급해서 대괄호+따옴표에 할당하고, 좀 더 편한 단일 대괄호 방식을 띄어쓰기를 허용하는 것에 할당하자는 것일 뿐입니다. 그게 띄어쓰기에게 좀 더 정당한 기회를 주는 것이라고 생각합니다.
그리고, 띄어쓰기가 있다고 해서 고유한 키가 되지 않는 것은 아닙니다. 페이지 이름, 위키 이름이라는 것을 하나의 단어로 보고 계시는지요? 위키 이름은 고유한 키이지만 그렇다고 하나의 단어인 것은 아닙니다. 실제로 영문의 경우 하나의 단어로는 위키 이름이 아예 성립되지 않습니다. 영문 위키 이름은 띄어쓰기가 없지만, 단어의 구분은 여전히 살아있고 LikePages 등도 그런 특징을 활용합니다. 한글 역시 마찬가지여야 하구요. 페이지 이름 안에 단어에 대한 정보가 남아 있어야 한다는 점에 대해 좀 더 이야기를 해 봤으면 좋겠습니다.
저 역시 띄어쓰기만 다른 페이지들이 존재할 필요는 없다고 생각하므로, 제목줄 문제나 띄어쓰기가 된 페이지와 그렇지 않은 페이지를 같은 것으로 취급하는 기술적인 문제는 논외입니다.
모인모인과의 호환성에 대한 제 답변은, 전향적인 태도라는 말로 대신하겠습니다.
--류광
기능적인 문제점을 고쳐서 띄어 쓰기를 사용 방법을 제한하는 것 보다는 (즉, 띄어쓰기와 띄어 쓰기가 같은 쪽을 가리키는 허용을 그렇지 못하게 제한하는 것) 제한을 풀어서 (즉, 둘 다 표현이 되도록 허용하되, 암묵적인 동의를 끌어 내는("띄어쓰기"라고 붙여 쓰지 말고 항상 정확히 "띄어 쓰기"로 띄어쓰기를 유도하도록 동의를 끌어 내는 ..).
물론 이렇게 하려면, 띄어 쓰기로 링크를 걸면 "띄어쓰기"라는 실제 페이지 (실제로는 urlencoding된 페이지이름을 가짐)를 가리키면서, 맨 위의 타이틀 바에는 "띄어 쓰기"로 표현되어야 하겠죠. KLE의 방법처럼. --WkPark
그리고 저도 위키를 사용하는 사용자들에게 제어권을 맡기고 공공의 암묵적인 동의를 끌어내는 것이 더 낫다고 봅니다.
다만 띄어쓰기가 불리한 위치에서 출발하는 게 아닌가 하는 불만이 있습니다.
같은 말이 계속 반복되는 것 같은데 제 주장을 두 가지로 요약할께요.
타이틀 캐쉬 #2 ¶http://chem.skku.ac.kr/~kle/moin/직결식글꼴페이지를 참조하세요. 실제로 저장되는 페이지는 "직결식글꼴 == _c1_f7_b0_e1_bd_c4_b1_db_b2_c3" 이지만 (공백정보 없음) 상단에 표시는 "직결식 글꼴"이라고 표현됩니다. DB에 저장되는 내용을 띄어쓰기로 저장할 필요는 없습니다. (이 방식은 띄어쓰기 정보를 다른 곳에 저장해 둡니다. 이런 식의 "휘발성 캐쉬"로 복수 표기를 허용할 수 있게 합니다. 휘발성 캐쉬이므로, 잘못된 표기를 바로잡을 수 있으며, 저장된 DB를 띄어쓰기를 교정해야 한다는 이유로 모두 갱신해야 하는 불편함도 없습니다.) 둘을 구분해서 생각하세요. 이러한 기술적인 트릭으로 예전 방식과 호환을 유지하고도 띄어쓰기로 DB로 저장된 기존의 이름들을 모두 바꿀 필요도 없는 간결한 방법입니다. 잘못된 띄어 쓰기 표현을 수정하는 비용을 생각하셔야 합니다. --WkPark
그 기능을 KDLP 위키가 사용했으면 좋겠습니다. 그 기능이, 휘발성 캐시가 무엇인지 구체적으로는 모르겠지만, 그러니까 어떤 형태로든 단어에 대한 정보가 어딘가에 저장된다는 거죠? 단어에 대한 정보가 온전히, 그리고 다른 어떤 기능들이 쉽게 사용할 수 있는 형태로 저장되기만 한다면 어디에, 어떻게는 더 이야기하지 않아도 될 것 같습니다.
그러나, 비용과 관련한 제 생각은 이런 것입니다. 그런 혼란이 있을 때에는 그냥 페이지 이름에 대해 문제를 제기하고 논의하고 적절히 바꾸면 된다고 생각합니다. 페이지 이름에 대해 문제를 제기하고 바꾸는 것은 띄어쓰기, 붙여쓰기 상관없이 많이 일어나는 일 아닌가요. 그냥 위키 활동의 하나일 뿐이라고 생각합니다. 예를 들어 얼마전까지만 해도 FrontPage에 월드와이드웹(WWW)이나 개발자(developer)코너 같이 한글, 괄호, 영문이 섞인 이름의 페이지가 만들어지길 기다리고 있었습니다. 그리고 얼마 전에 괄호와 영문자들이 빠진 이름의 페이지를 링크하도록 바뀌었구요. 페이지가 실제로 만들어지고 그걸 링크하는 페이지들이 생겼다면 좀 더 힘들었겠지만, 역시 어쩔 수 없이 겪는 일이겠구요. 페이지 이름의 띄어쓰기를 바로잡는 활동 역시 그런 활동과 기본적으로 동일한 것이라고 생각합니다.
끝으로, 반복되는 말 속에서 조금씩 진전이 있었다고 생각하구요. 이정도까지 이야기하게 되어서 무척 좋았습니다. 사실 편견도 좀 있었습니다. 왜냐하면 다른 곳에서 다른 분들과 띄어쓰기 얘기 할 때 그냥 '호환성 때문에'에서 그친 적도 있었고, 페이지 이름을 구성하는 단어 정보를 유지하는 것의 필요성에 대해 어떤 의견도 듣지 못하고 끝난 적도 있었거든요. 후자는 여기의 논의에서도 아직도 좀 모자란 느낌이지만, 그래도 상당히 만족스럽습니다.
--류광
따라서 페이지 이름 자체는 띄어 쓰기를 채택하지 않는 게 타당합니다.
페이지 이름 자체는 띄어쓰지 않고 표현만 띄어 쓸 수 있다면 좋은데, WkPark님이 된다고 하시니 된 거죠.
류광님이 원하시는 게 띄어 쓰기라고 링크를 걸 수 있게 하자, 혹은 그렇게 표현되게 하자는 건데 (맞죠?), 그게 된다는 겁니다.
링크도 걸 수 있고 표시도 띄어 쓰기가 들어가서 된다면, 실제 페이지 이름이 어떻게 저장되는지는 사실 중요한 문제가 아니잖습니까?
이 외에 (혹시 제가 잘못 이해했다면) 페이지 이름 자체에 띄어 쓰기까지 넣어서 저장해서 얻을 수 있는 이점을 제시해주시기 바랍니다. --kz
예 WkPark님 말씀에 따르면(제가 잘못 이해한게 아니라면) 단지 표현 뿐만 아니라 휘발성 캐시라는 곳에 띄어쓰기 정보가 저장되는게 가능한 가 봅니다. 다행입니다. 위의 글을 참고하시구요.
페이지 이름 자체에 띄어쓰기를 넣는 것은 개인적으로 프로그래밍하기가 좀 더 편한데, 그건 뭐 위키 엔진마다 알아서 할 일이구요.
한가지 걸고 넘어갈께요.... 띄어쓰기가 번거롭고 혼란스럽게 느껴질 수 있겠지만 그렇다고 띄어쓰기 규칙이 명확하지 않은 것은 아닙니다. 띄어쓰기는 "단어는 띄어 씀을 원칙으로 한다"라는 뚜렸한 규칙이 있구요. 나머지는 한국어 문장에서 무엇이 단어이고 무엇이 아닌가에 대한 규칙들인데 그건 사실 한국어 문법의 문제입니다. 위키에서 문제가 되는 것은 붙여쓰기를 허용하는 규정이 존재한다는 것인데, 그에 대한 이야기는 다시 반복할 필요가 없겠죠.
--류광
이 애매한 허용 기준을 아주 나쁘게 얘기 하시는 분이 있더군요. 띄어 쓰기 복수 허용을 하지 말라고, 정확하게 표현하는 습관을 하라고 말이죠. --WkPark
검색 로봇 ¶페이지 이름 붙여 쓰기를 하면 단어 단위로 검색을 쓸 수가 없습니다. 나중에 검색봇 접근을 허용 했을때 붙여쓰기를 한 페이지 이름들은 검색 키워드로 쓸수 없게 될 가능성이 높습니다. 검색엔진이 정확이 어떻게 작동하는지는 모르지만 콘텐츠중 타이틀과 링크에 들어가는 페이지 이름이 그 페이지에 가중치를 줄 것이라고 생각합니다. 그러나 붙여쓴 페이지 이름은 가중치를 획득하는데 실패해서 사용자가 원하는 결과임에도 한참 뒤로 밀려날 가능성이 높다는 것 입니다. -BL
페이지 이름이 붙여쓰게 되는 것과 검색 로봇이 찾지 못하는 것과는 크게 상관이 없습니다. 페이지 이름은 urlencode()되어 링크되기 때문이며, 실제 검색 로봇은 contents를 중심으로 찾지 웹 페이지의 페이지 이름으로 contents를 긁어 모으지는 않습니다. 그 대신에 HEAD의 title태그의 정보를 찾는다고 합니다. title 정보에는 띄어쓰기 정보가 들어가게끔 하는 것이 옳겠지요.
지금 문자 단위로 검색하는 현재 검색 시스템에서 "log"나 "로그"로 페이지 이름과 내용을 검색해 보면 결과가 좋지 않은것을 알수 있습니다. google처럼 단어 단위로 검색하게 된다면 그나마 나은 결과를 얻을수 있을 겁니다. 검색봇의 접근을 계속 거부 하더라도 KLDP 같이 검색이 중요한 싸이트는 검색비용을 줄이는데 초점을 맞추는것이 중요하다고 생각합니다. -- BL
검색 엔진은 페이지 이름 그 자체에 가중치를 두지 않습니다. 위키는 유독 페이지 이름이 페이지 내용의 키워드가 되지만, 이런 부분은 Meta Tag의 keywords와 title에서 위에 언급한 "페이지 이름 캐쉬"를 적용하면 해결 할 수 있을 것입니다. 어떤 위키엔진은 페이지 이름이 게시판의 일련 번호와 같을 수도 있습니다. 대부분의 블로그도 페이지 이름이 번호입니다. 페이지 이름 그 자체는 의미 없는 경우가 많습니다만, 검색 로봇은 대다수의 블로그 컨텐츠를 잘 찾아냅니다. 개발 ¶차후의 토론은 페이지 이름 캐쉬를 구현하고 난 후에 가능할 듯 합니다. 우선 계획하고 있는 것은 KLE에서 쓰는 기존 방법에(고 자동 방법), 저 자동 방법으로 페이지 이름을 제어하는 방법을 추가하는 것입니다.
"페이지 이름 캐쉬"를 넣으려다가, 위의 '저 자동' 방법과 '고 자동' 방법을 다 넣는 대신에 "저 자동"방법만 넣어봤습니다. (페이지 이름 캐쉬를 전혀 사용하지 않습니다. 물론, WordIndex로 사용하려면 페이지 이름 캐쉬에 이것을 저장하도록 해야겠지요.)
이 방법의 장점은, 저장되는 페이지 이름과 완전히 무관하게 각 페이지의 title을 쓸 수 있다는 점입니다.
사용 방법은, 페이지의 상단에
#title 페이지 이름이 주는 느낌과 같은 식으로 쓰면 됩니다.
이 방법이 유용한 이유는, 위키위키에서 페이지 이름이 주는 지나친 함축성에 대한 단점을 극복할 수 있고, WikiName에 크게 얽메이지 않고도 설명적인 페이지를 만들 수 있다는 점입니다. 단, 오용하면 안되겠죠. -- WkPark 2003-07-31 14:20:01
|
Your mode of life will be changed for the better because of good news soon.    
|
|||||||||
