미디어위키토론:Gadgets-definition

문서 내용이 다른 언어로는 지원되지 않습니다.
새 주제
위키백과, 우리 모두의 백과사전.
마지막 의견: 3년 전 (Ykhwong님) - 주제: 중국어 위키의 소도구 기능 추천

commons:user:i18n#useful links[편집]

Dear friends; please look at the links at commons:user:i18n#useful links. Thanks in advance! Best regards Gangleri
‫·‏לערי ריינהארט‏·‏T‏·‏m‏:‏Th‏·‏T‏·‏email me‏·‏‬ 2008년 2월 8일 (금) 03:13 (KST)답변

GoogleTrans Gadget[편집]

Hi there,

Sorry about the English.

I have had a GoogleTrans gadget on the enwiki for almost a year now. If you position the cursor over a word and hit the SHIFT key it will popup the google translation of that word. It is like the google toolbar translation feature except that it will also handle selected text (< 500 characters). The gadget is currently running on 7 wikis.

The help page for the gadget is at:

http://en.wikipedia.org/wiki/User:Endo999/GoogleTrans

and the code is at:

http://en.wikipedia.org/wiki/User:Endo999/GoogleTrans.js

There are instructions on how to port the gadget onto other wikis on the help page.


Good luck with your wiki. Anybody who is learning Korean by reading zhwiki articles could benefit from this gadget.

Endo999 (토론) 2010년 8월 18일 (수) 08:19 (KST)답변

Romanisation put in GoogleTrans gadget[편집]

Hi there,

A new version of the GoogleTrans gadget is available at:

User:Endo999/GoogleTrans.js

If you wish to use this privately, or to refer to it in a kowiki gadget file use the following javascript command:

importScript("User:Endo999/GoogleTrans.js");

This new version has:

1) new languages
2) support for IE11
3) changing deprecated javascript calls to the new MW object
4) a Romanisation trial, romanised pronounciation will now appear below the translation. (This can be turned off by setting SCdoRomanisation=false; in the gadget code.)

Endo999 (토론) 2015년 1월 1일 (목) 05:53 (KST)답변

2015년 5월 3일의 편집 요청[편집]

위키백과:도구/ref툴바의 개선 버전을 소도구 형태로 추가하고 싶습니다. 좌측 문서의 내용을 우측 이름으로 만들어주세요.

그리고 미디어위키:Gadgets-definition에 도구를 정의해야 하는데, 영어판에는 다음과 같이 되어 있습니다.

refToolbar[ResourceLoader|default|dependencies=user.options,mediawiki.legacy.wikibits]|refToolbar.js
refToolbarBase[ResourceLoader|hidden|rights=hidden]|refToolbarBase.js

이 코드는 전체 사용자에게 모두 적용되는 것이므로 선택할 수 있도록 알맞게 수정해주시면 됩니다.--Namoroka (토론) 2015년 5월 3일 (일) 22:10 (KST)답변

완료 문서 이동 및 "editing-gadgets" 도구 정의란에 추가를 완료했습니다. --L. Lycaon (토론 / 기여) 2015년 5월 8일 (금) 18:59 (KST)답변
@Twotwo2019: 제가 하나 빼먹었네요. 미디어위키:RefToolbar.js에도 사용자: 라고 되어 있는 부분을 바꿔주세요.--Namoroka (토론) 2015년 5월 8일 (금) 23:01 (KST)답변
@Namoroka: 완료 처리했습니다. --L. Lycaon (토론 / 기여) 2015년 5월 8일 (금) 23:04 (KST)답변

2015년 8월 9일의 편집 요청[편집]

미디어위키 1.26부터 모든 소도구 정의는 ResourceLoader를 필수적으로 포함해야 한다고 합니다. mw:ResourceLoader/Migration guide (users)#MediaWiki 1.26 이에 따른 편집을 요청합니다. ReferenceTooltips[ResourceLoader|default] 식으로 하면 됩니다. --Senior9324 (토론) 2015년 8월 9일 (일) 13:20 (KST)답변

완료 기술 사랑방에도 해당 문제의 수정을 언급했습니다. --ted (토론) 2015년 9월 2일 (수) 23:31 (KST)답변

상단으로 스크롤하는 버튼 소도구 추가[편집]

페이지 상단으로 올라갈 때 화살표 버튼만 누르면 상단으로 스크롤하는 화살표 버튼을 추가하는 기능을 위키백과에 활성화했으면 합니다. 현재 위키미디어 공용에서 소도구로 적용되어 있고 약 250명가량이 활성화했습니다. 한국어 위키백과에도 소도구로 적용하면 좋을 것 같습니다. 이 소도구를 기본값으로 적용할 지는 좀더 토론이 필요하겠지만요.

이 기능을 활성화하려면 다음 코드를 추가하면 됩니다.

mw.loader.load( "//commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-scrollUpButton.js&action=raw&ctype=text/javascript" );

– Kwj2772 (msg) 2019년 11월 17일 (일) 01:36 (KST)답변

좋은 기능입니다. 말씀하신 모든 사용자 기본값 적용에도 동의합니다. --ted (토론) 2019년 11월 30일 (토) 08:31 (KST)답변
찬성합니다.--L. Lycaon (토론 / 기여) 2019년 11월 30일 (토) 10:49 (KST)답변
참고로 해당 기능은 모바일에서 베타 기능의 하나로 이미 제공되고 있습니다. commons:MediaWiki:Gadgets-definition에 있는 그대로 적용할 경우 모바일에서는 해당 베타 기능과 충돌이 발생할 수 있으므로, targets=desktop를 추가하여 데스크톱에서만 사용하도록 한정할 필요가 있다고 생각합니다. (베타 기능에서 사라졌음) --ted (토론) 2019년 12월 9일 (월) 00:44 (KST)답변
의견 요청이 한 달 이상 있었고 별다른 이의가 없었기에 소도구의 하나로 추가합니다. --ted (토론) 2019년 12월 21일 (토) 01:22 (KST)답변
예, 아주 좋습니다. 매우 편리하군요. -- 아사달(Asadal) (토론) 2019년 12월 23일 (월) 11:18 (KST)답변

편리 하네용 다니엘킴 (토론) 2019년 12월 24일 (화) 16:18 (KST)답변

중국어 위키의 소도구 기능 추천[편집]

중국어 위키에서는 zh:template:Internal link helper라는 틀이 있어, 어떤 문서가 중국어 위키에는 없고 다른 위키에 있다면 초록색으로 글씨를 표시한 뒤 밑에 알림창을 띄워 그 위키의 문서로 이동할 링크를 띄워집니다. 예시로 zh:Template:朝鲜战争을 보시면 되겠습니다. 해당 틀은 {{타 언어판 문서 호출}}로 임의로 작성해두었고, 해당 모듈도 만들어 두었습니다. 이제 zh:Special:小工具에서 跨语言链接로 시작하는 기능들을 가져오면 한국어 위키에도 동일 기능이 작동할 수 있을 것 같습니다. {{임시링크}}를 효과적으로 대체할 수 있으며, 주목도나 심미성이 뛰어나기 때문에 해당 기능을 한국어 위키에도 도입해주시면 참 좋을 것 같습니다. 이에 대해 의견 들어보고 싶습니다.――사도바울||X 2020년 4월 25일 (토) 03:33 (KST)답변

번역되어야 할 문서와 이미 있는 문서를 효과적으로 식별 가능하게 만드는 소도구이군요. 만약 도입된다면 편리할 것 같습니다.--Kenlee77 (토론) 2020년 4월 25일 (토) 15:34 (KST)답변

저는 접근성 문제를 이유로 이 기능을 사용하지 않는 것을 제안합니다. 링크의 색은 검은색(일반 문장), 붉은색(존재하지 않는 문서), 파란색(존재하는 문서)으로 기본적으로 의미가 정해진 색이며 그 이외의 녹색은 일반 독자에게 혼동을 가져올 수 있고 시각 장애를 지닌 사용자를 배려하지 않습니다. 또 제시해주신 기능을 사용할 경우 알림창 표시를 위해 마우스 커서로 링크를 가리키고 있어야 하는 수고를 들여야 하는 반면 임시링크 틀은 그러한 문제가 없습니다. 그리고 다른 언어 위키로의 링크를 제공한다는 면에서 기존 {{임시링크}} 틀과 기능면에서 동일하다고 생각합니다. --ted (토론) 2020년 4월 26일 (일) 00:17 (KST)답변

일단 저의 경우 마우스를 올리면 색이 빨간색으로 변하며 아래 (lang):(해당위키문서제목)이 표시 되기 때문에 기능에 혼동을 겪지는 않았고, 아마 대부분의 사람들도 마찬가지일 것으로 보입니다. 시각 장애 사용자를 위해 특:환경설정/소도구에서 주황색 등 여러 선택지를 제시할 수도 있습니다. 임시링크 틀과 기능면에서 동일하나 말풍선이 뜨는데 걸리는 시간이 극히 짧아 기능적 손해가 크지 않을 것으로 보며, 만일 있더라도 미미한 수준이라 심미적 관점에서 교환할만하다 봅니다. 더 다양한 인터페이스 선택지를 제공하는 것이지, 사용을 강제하자는 것이 아닙니다.――사도바울||X 2020년 4월 26일 (일) 00:39 (KST)답변
정적인 상태에서 색 구별 문제 외에, 마우스를 올려야 색이 바뀌고, 팝업을 보기 위해 절차가 하나 더 있는 등 이런 것이 접근성 문제라고 저는 생각합니다. 행동이 어렵거나 시각 문제가 있는 분들을 배려하지 못한다고 생각합니다. 접근성에 따르면 "사용자의 신체적 특성이나, 지역, 나이, 지식 수준, 기술, 체험과 같은 제한 사항을 고려하여 가능한 많은 사용자가 불편 없이 이용할 수 있도록 제품, 서비스를 만들어 제공하고 이를 평가 할 때 쓰이는"이라고 되어 있습니다. 혹시나 해서 지금 영어 위키백과 쪽을 확인해봤는데 거기서도 같은 이유(접근성 포함)로 삭제로 결론이 났음을 발견했습니다. 개인마다 호불호가 갈릴 수 있지만 제가 보기에는 심미적 관점에서 별로이고 오히려 지저분해 보입니다. 일단 개인의 한 의견으로 이해해 주시기 바랍니다. 제 주장을 고집하지는 않으며 총의에서 문제 없다고 하면 수용할 자세는 되어 있습니다. --ted (토론) 2020년 4월 26일 (일) 00:50 (KST)답변
약간 생각을 바꿔서, 기술적으로 가능하다면 디폴트 값은 해제하는 것으로 두고 원하는 사용자만 해당 기능을 사용할 수 있도록 하면 어떨까요? 분명 해당 기능을 필요로 하는 사용자는 있으리라 생각합니다. 번역 작업을 주로 하시는 분들이라던가요. --양념파닭 (토론 · 기여) 2020년 4월 26일 (일) 00:54 (KST)답변
네, 기술적으로 가능한지 확인하지는 않았으나, 가능하다면 양념파닭님의 의견에 동의합니다. 소도구를 기본값으로 두지 않고 하나의 옵션으로 두는 것은 가능합니다. 소도구가 꺼진 상태에서는 어떻게 동작할까요? --ted (토론) 2020년 4월 26일 (일) 00:56 (KST)답변
소도구가 꺼져 있을 수가 있나요? --양념파닭 (토론 · 기여) 2020년 4월 26일 (일) 01:03 (KST)답변
소도구를 끈다는 의미는 환경 설정에서 소도구의 체크 상자의 체크를 해제한다는 의미로 이해해 주시면 됩니다. 제가 설명을 적절히 드리지 못한 것 같습니다. --ted (토론) 2020년 4월 26일 (일) 01:06 (KST)답변
어떤 설정을 강제하는건 저도 반대입니다. 제 뜻이 그렇게 전달되었을줄은 몰랐네요;; 인터페이스 다양성을 제공하자는 것이지, 이 인터페이스로 바뀌어야한다는 주장이 아니었으니 혹시 오해하셨다면 풀리면 좋겠습니다. 해당 소도구를 가져온다면 중국어 위키와 동일하게 작동될테니, 중국어 위키의 개인 사용자 소도구창에서 설정을 바꿔가면서 시험해보실 수 있습니다. 跨语言链接로 시작하는 소도구를 다루시면 됩니다.――사도바울||X 2020년 4월 26일 (일) 02:13 (KST)답변
말씀하신대로 소도구를 비활성화하면 붉은색 링크만이 표시되는데 이 부분은 임시링크처럼 동작하도록 수정되는 게 좋을 것 같습니다. 제안을 고려해 주시기 바랍니다. --ted (토론) 2020년 4월 26일 (일) 02:25 (KST)답변
영어위키는 초록링크를 띄울 일이 다른 언어판에 비해 많지 않다는 점에서 기타 언어판 위키들과 상황이 좀 다른 것 같습니다. 해당 토론문서를 한번 읽어보고 싶은데, 링크 부탁드려도 될까요?――사도바울||X 2020년 4월 26일 (일) 02:20 (KST)답변
en:Wikipedia:Templates for discussion/Log/2017 May 27#Template:Internal link helper입니다. --ted (토론) 2020년 4월 26일 (일) 02:31 (KST)답변
임시링크와 비교할 때 뒤에 (lang-code) 부분이 본문에 추가되지 않으면서 다른 언어판 문서로 안내해주기 때문에, 본문 내부에 삽입하는데 부담이 더 적다는 이점도 있겠습니다.――사도바울||X 2020년 4월 26일 (일) 02:20 (KST)답변

도입해야 하는 소도구 수가 너무 많습니다. 소도구 도입에 앞서 사용자:사도바울/common.js사용자:사도바울/common.css에서 소도구들의 내용 전체를 가져오거나 외부로부터 불러와서 일일이 정상 동작 테스트를 부탁드릴 수 있을까요? 중국어 위키백과에서 된다고 하여 한국어 위키백과에서 그대로 된다는 보장이 없으며 소스 수정이 필요할 수 있습니다. 그리고 도입해야 할 소도구의 목록, 그리고 목록의 항목에 일치하는 소도구 정의의 중한 번역이 필수인데 이곳에 정리가 필요합니다. --ted (토론) 2020년 4월 26일 (일) 02:29 (KST)답변

네 그러면 한번 해보겠습니다.――사도바울||X 2020년 4월 26일 (일) 03:15 (KST)답변
일단 사도바울님이 common.css와 common.js에 제안하신 건은 작동되게 만들었습니다만 (콘솔창에서 실행시키면 해당 스크립트 자체는 작동합니다.), 어째 common.js에 넣고 돌리면 jQuery.tipsy is not a function 오류가 나네요. 이건 mw.loader.load로 가져오면 해결되는 문제인가요? 제 추측으로는 script가 너무 빨리 로딩되는 거 같아 $().ready, $(window).load 등 해봤는데 고쳐지지가 않네요. --Raccoon Dog (talk) 2020년 5월 5일 (화) 09:04 (KST)답변
더군다나 위의 함수가 아니더라도 (구문에 보이는) anonymous function은 $( function() { });로 작성하면 나중에 로드하는 것과 동일하다고 알고 있는데 말이죠. 일단 사도바울 님이 테스트를 해보신다면 사용자:Raccoon Dog/Sandbox에 들어가신 후 구문을 Console에 실행하시면 제대로 동작하는 게 보이실 겁니다. 확인해 보세요. --Raccoon Dog (talk) 2020년 5월 5일 (화) 09:08 (KST)답변
이 부분의 오류는 해결되었고 자세한 사항은 사도바울 님의 토론란에 남겼습니다. --Raccoon Dog (talk) 2020년 5월 5일 (화) 11:59 (KST)답변

@Raccoon Dog, Ykhwong: Raccoon Dog 님 덕분에 redtipsy.js의 문제가 해결되었습니다. 추가적으로 모듈:ilh에서 그냥 "-{"와 "}-"를 지워버림으로써 별도의 처리 없이도 깔끔하게 나오게 하였는데, 아직 발견하지 못한 부작용이 있을 수도 있습니다. 일단 다른 코드들을 전부 가져와서 실험해본 결과 제대로 작동해야 하는 경우에는 제대로 작동한다는 것을 확인했습니다. 직접 테스트해보실 분께서는 사용자:사도바울/기타에 정리해두었으니 참고해주시면 감사하겠습니다.――사도바울||X 2020년 5월 6일 (수) 00:57 (KST)답변

중국어 위키백과에서는 "跨语言链接:光标悬浮时显示Tooltip" 기능의 경우 (비로그인 사용자 포함) 모든 사용자에게 기본 활성화하도록 설정되어 있는데 한국어 위키백과에서는 跨语言链接 관련 모든 소도구에 대해 기본 비활성화하는 것으로 이해하고 있습니다. 그리고 사용자:사도바울/기타 내용에 있을 수 있겠지만, 많은 사람들이 이해할 수 있도록 중국어로 된 정의와 일치하는 한국어 번역에 대해 명확히 해주셨으면 합니다. 소도구 정의의 중한 번역이 필수라고 위에서 말씀드렸듯이 아래의 중국어 내용을 번역해서 정리해 주시면 감사하겠습니다.

이 글을 보려면 오른쪽 '펼치기' 버튼 클릭
跨语言链接:只显示红链 : 빨간색 링크만 표시
→ Gadget-internalLinkHelper-redonly.css

跨语言链接:在Tooltip中显示原文链接 : 툴팁에서 원본 링크 표시
→ Gadget-internalLinkHelper-redtipsy.js, Gadget-internalLinkHelper-redonly.css, Gadget-internalLinkHelper-redtipsy.css

跨语言链接:显示红链和未链接原文 : 빨간색 링크와 원본 문자열 표시
→ Gadget-internalLinkHelper-redplain.js, Gadget-internalLinkHelper-redplain.css

跨语言链接:直接指向原文 : 원본에 바로 연결
→ Gadget-internalLinkHelper-external.js, Gadget-internalLinkHelper-redonly.css, Gadget-internalLinkHelper-external.css

跨语言链接:指向原文和语言名后缀 : 원본에 바로 연결(언어 표시)
→ Gadget-internalLinkHelper-external.js, Gadget-internalLinkHelper-suffix.js, Gadget-internalLinkHelper-external.css, Gadget-internalLinkHelper-suffix.css

跨语言链接:鼠标点击时显示Tooltip : 마우스 클릭 시 툴팁 표시
→ Gadget-internalLinkHelper-cravix.js, Gadget-internalLinkHelper-cravix.css

跨语言链接:光标悬浮时显示Tooltip : 커서를 올리면 툴팁 표시
→ Gadget-internalLinkHelper-redtipsy.js, Gadget-internalLinkHelper-redonly.css, Gadget-internalLinkHelper-redtipsy.css, Gadget-internalLinkHelper-altcolor.css

跨语言链接:光标悬浮时显示Tooltip(對於已存在頁面的情況下高亮表示): 커서를 올리면 툴팁 표시 (문서가 이미 존재하는 경우 강조)
→ Gadget-internalLinkHelper-redtipsy.js, Gadget-internalLinkHelper-redonly.css, Gadget-internalLinkHelper-redtipsy.css, Gadget-internalLinkHelper-altcolor.css, Gadget-internalLinkHelper-ilbluehl.css

그리고 사용자:사도바울/기타에서 내용이 없는 소스 파일은 그대로 가져와서 사용하라는 의미로 해석하면 될까요? 가이드를 구체적으로 해주시면 다른 분들이 테스트하기가 쉽고 소도구 도입을 하시는 분께서 정확히 업무를 처리할 수 있습니다. --ted (토론) 2020년 5월 7일 (목) 00:20 (KST)답변

위에 숨기기 하신 것에 번역어를 추가했습니다. /기타 문서에 /*~*/ 처리만 해놓고 내용을 안 써놓은 것은, 다른 소도구들에 한 번 사용된 거라서 내용을 생략한 거라서 ctrl-f로 찾으시면 됩니다. 또한 저는 모든 사용자들에게 "커서를 올리면 툴팁 표시 (문서가 이미 존재하는 경우 강조)"가 활성화된 편이 좋다고 생각하는데, ted님께서는 현재 색맹 사용자들의 접근성 문제로 해당 사안에 반대의견을 내시는 것으로 압니다. 그렇다면 연두색 링크를 노란색 링크로 대체하는 것을 제안드리오니, 이에 대해 의견 주시면 감사하겠습니다. 언제나 좋은 기여에 감사드립니다ㅎㅎ――사도바울||X 2020년 5월 7일 (목) 17:27 (KST)답변
말씀하신대로 색 문제도 있습니다만, 위에 기술한대로 마우스 동작에 관한 접근성 문제가 더 큽니다. 통일성 없는 사용자 경험(UX)도 문제이지만 일반인의 관점에서만 편의를 생각해서는 안 됩니다. 이미 기본값으로 사용하지 않는 것을 동의해 주셨으니 이 부분은 그대로 진행했으면 합니다. --ted (토론) 2020년 5월 7일 (목) 21:17 (KST)답변
아, 그리고 {{타 언어판 문서 호출}}의 설명문서도 번역하여 추가하였으니 도움이 되면 좋겠습니다.――사도바울||X 2020년 5월 7일 (목) 17:28 (KST)답변
생각해보니 채도에 충분히 차이를 둠으로써 색맹 사용자분들의 접근성 문제도 해결할 수 있겠습니다. 실제로 중국어 위키에서는 틀:타 언어판 문서 호출#표시 효과커서를 올리면 툴팁 표시 (문서가 이미 존재하는 경우 강조)에서 볼 수 있듯 연한 하늘색도 사용하고 있습니다. 아니면 이탤릭체나 기타 효과를 통해 접근성 문제를 해결할 수도 있겠습니다. 이에 대해서도 고견 들려주시면 감사히 듣겠습니다.――사도바울||X 2020년 5월 7일 (목) 20:06 (KST)답변
소도구가 기본값으로 활성화되지 않는 한 기본적으로 꺼져있기 때문에 일부 신체 장해가 있는 사용자는 해당 소도구를 기본적으로 이용하지 않게 되므로 문제가 없을 것으로 생각합니다. 기능이 필요한 사람만 소도구 옵션을 활성화하면 되기 때문입니다. 그러므로 소도구 옵션이 강제되지 않는 한 색을 포함한 접근성 문제에 대해서 저는 문제 제기를 하지 않으려고 합니다. (만일 기본값 활성화를 염두에 두고 말씀하신 것이라면 얕은 채도를 구분하지 못하는 사용자들이 있기 때문에 제안해 주신 모호한 연한 하늘색은 사용하지 않아야 합니다.) 한편, 기울임체의 경우 백:편집 지침에 따르면 "기울인 글씨는 한글일 경우 되도록 사용하지 않습니다."가 있으므로 어울리지 않을 것 같습니다. --ted (토론) 2020년 5월 7일 (목) 21:22 (KST)답변
기울임체는 토론에서 그냥 강조를 위해 쓴거니 신경쓰지 않으셔도 괜찮습니다. 소도구의 도입과 함께 "커서를 올리면 툴팁 표시 (문서가 이미 존재하는 경우 강조)"를 기본 효과로 적용시키는 것도 염두에 두고 있습니다. 일부 사용자층이 해당 효과를 누릴 수 없기 때문에 사용되지 않아야 한다고 하셨는데, 연한 하늘색의 경우 위키 사용에 필수적인 어떤 기능을 제공하는 것이 아니라 관리의 편이를 위한 것입니다. 위키백과에 다채로운 그림이 올라올 수 있듯, 색맹 사용자분들의 위키 이용을 저해하는 경우가 아니라면 다수의 비색맹 사용자분들께 도움이 되는 기능의 추가는 바람직하다는 것이 제 생각입니다. 연두색의 경우 더 적절한 색이 있다면 추천 부탁드립니다.――사도바울||X 2020년 5월 7일 (목) 21:38 (KST)답변
실례합니다. 저는 처음부터 기본값 사용에는 동의하지 않는다고 말씀드렸으며 갑자기 입장이 바뀌신 데 대하여(정확히는 강제 설정 또한 추가로 염두에 두는 것) 이해가 되지 않고, 추가적으로 말씀하신 내용을 들어도 납득이 되지 않습니다. "어떤 설정을 강제하는건 저도 반대입니다. 제 뜻이 그렇게 전달되었을줄은 몰랐네요"라고 사도바울님께서 말씀하셨고 이후 기본값으로 사용하지 않는다는 것이 양념파닭님과 저와 이미 합의된 부분입니다. 그래서 그 부분을 바탕으로 지금까지 토론이 이루어졌는데, 어떻게 하여 갑자기 이 의견이 바뀌었는지 의문이 듭니다. 저는 분명히 색상만이 문제가 아니라고도 말씀을 드렸습니다. --ted (토론) 2020년 5월 7일 (목) 21:53 (KST)답변
아, 염두에 둔다는 건 현재 제 생각을 말씀드린 겁니다. 기본설정으로 바꾸는 것이 편이가 클 듯 하여 생각이 바뀌었는데, 발제자의 생각이 이동한 것에 대해 혼란을 느끼실 수 있으나 토론중에 당연히 벌어질 수 있는 현상입니다. ted님께서는 현재 색맹 사용자뿐 아니라 팝업을 위한 절차, 심미성 등을 들어 반대하시는 것으로 파악이 되는데, 팝업 절차나 심미성의 경우에는 4월 26일 00:17에 전달한 제 생각에서 더 설득할 여지가 없는 듯 하여 평행선으로 간주하고 말씀드리지 않았습니다. 혹시 제가 파악하지 못한 부분이 있다면 너른 아량으로 의견을 들려주시면 감사하겠습니다. 양념파닭님께서도 제가 새로이 주장하는 바에 대해 의견 들리주시면 좋겠습니다. 지금까지의 내용을 정리하여 소문단 하나를 더 만들도록 하겠습니다.――사도바울||X 2020년 5월 7일 (목) 22:15 (KST)답변
네, 알겠습니다. '기본값 활성화가 아님'이라는 합의를 전제로 저는 계속 도움을 드리고 있었는데 의견이 바뀌셔서 제게 큰 혼동이 있었던 것이 맞습니다. 그리고 기본값 활성화의 제 반대 의견 또한 말씀하신 부분이 맞습니다. 위키백과에 (색 문제는 색약 포함 많이 있으니 배제하더라도) 신체 문제로 어려움을 겪는 사용자들이 있습니다. 직접 제 눈으로 본 행동 패턴을 하나 공유드리고 싶습니다. 이들은 마우스 커서를 겨우 움직여서 커서를 링크에 대고 가리키고, 해당 링크를 정말로 가리켰는지 수초 동안 가만히 있다가 확인을 한 이후 겨우 다른 문서를 넘겨보는 사용자들입니다. 그러한 동작이 지금 소도구의 기본 활성화에 의해 문제가 발생할 소지가 있을 것 같아요. 중국어 위키백과는 참고로 여러 부분에서(본 소도구를 차치해 두고라도) 웹 접근성을 희생하고 있는 부분이 더 발견됩니다. 거기서는 그러한 접근성 희생이 상관 없다고 판단하여 그렇게 총의를 모아 진행했을 수 있겠지요. 여기서는 그런 일이 없기를 바랐을뿐이었습니다. 그러나 기본값 활성화가 하나의 옵션이 된다면 현 상태에서 저는 기 말씀드린 이유로 계속 토론으로 도와드리기 어려울 듯 하며 다른 분께서 도와주시는 게 좋겠습니다. 이해해 주시기 바랍니다. 고맙습니다. (소문단을 하나 더 만드시는 것에 이의 없습니다.) --ted (토론) 2020년 5월 7일 (목) 22:41 (KST)답변
경험 공유해주셔서 감사합니다. ted님과 같은 수준으로 해당 사안을 이해하지는 못하더라도, 위키백과의 인터페이스가 나아가야 할 방향에 대해 늘 그런 분들의 존재를 염두에 두어야 겠습니다. 다시한번 감사드리며, 개인적으로 존경의 말씀도 드리고 싶습니다.――사도바울||X 2020년 5월 7일 (목) 22:54 (KST)답변
기울임체에 대해서 무슨말씀을 하셨던건지 이제 알았네요;; 이해가 늦어 죄송합니다. 그러면 기울임체가 아닌 다른 방식으로 수정하는 것을 생각해봐야겠습니다.――사도바울||X 2020년 5월 7일 (목) 22:49 (KST)답변

쟁점[편집]

현재 제가 주장하는 바는 (1) 해당 소도구의 도입, (2) 해당 소도구를 기본 설정으로 하는 것 입니다. 여기서 (2)의 경우 과거인 4월 26일에는 주장하지 않았으나 오늘 처음 말씀드린 바, 이전에 의견을 주신 @Kenlee77, 양념파닭:님께서도 새로 방문하셔서 의견 들려주시면 감사하겠습니다.

해당 소도구의 도입을 제안하는 이유는 다음과 같습니다.

(p1) {{임시링크}}에서 괄호를 제거하고 색으로 구분함으로써 가독성을 향상할 수 있으므로, 편집자들도 해당 기능을 더욱 활발히 사용할 수 있습니다. 현재 중국어 위키의 경우가 대표적인데, 한국어 위키에서는 빨간 링크로 남겨둔 부분들을 해당 기능을 통해 적극적으로 교체해왔으며 교체하는 중입니다. 대표적으로 {{한국전쟁}}과 zh:Template:朝鲜战争을 비교하시면 되겠습니다.
(p2) 가독성과 중복되는 내용일 수 있는데, 심미적으로도 더 좋아보입니다.
(p3) 위키백과의 인터페이스 다양성을 제공함으로써, 사용자들의 경험을 더욱 다채롭게 할 수 있습니다.

또한 저는 처음에는 해당 기능을 기본 설정으로 제공하자는데에는 생각이 미치지 못했으나, 굳이 선택사항으로 둠으로써 비로그인 사용자들에게 위의 (1)과 (2)의 접근성을 낮출 이유가 없다는 데 생각이 닿아 오늘 기본설정화를 추가적으로 제안하게 되었습니다.

ted님께서 이에 대해 반대의견을 주셨는데, 그 이유를 제가 이해한 바 다음과 같습니다.

(o1) 색맹 사용자들이 가장 잘 구분할 수 있는 색인 빨강, 파랑, 검정을 제외하고 연두색을 추가하는 것은 접근성을 저해합니다. 실제로 영어위키에서는 같은 이유로 해당 틀이 삭제되었습니다.
(o2) 심미적으로 지저분해보입니다.
(o3) 별도의 팝업이 추가되는것이 번거롭습니다.

@Ykhwong:혹시 주장하신 바를 제가 잘못 이해하고 있다면 윗 줄을 수정해주시면 되겠습니다.――사도바울||X 2020년 5월 7일 (목) 22:49 (KST)답변

ted님께서 주장하신 바에 대한 제 생각은 다음과 같습니다.
(o1)에 대해 색맹(특히 적록색맹 사용자들이) 연두색과 빨간색 링크를 잘 구분하지 못할 수 있다는 것에 동의합니다. 그러나 녹색 링크의 추가가 현재와 비교했을 때 별도의 불편성을 주는 것은 아니라고 생각합니다. 일단 해당 틀은 적록색맹 사용자들의 시각에서 빨간 링크와 동종으로 인식되는데, 해당 문서를 새로 생성하고자 마우스를 올리는 동시에 팝업이 떠오르므로 새로운 문서를 작성하려 하는 경우 동등한 도움을 얻을 수 있습니다. 그러나 가장 좋은 방법은 위에 제가 언급한 (p1~3)을 만족하면서 동시에 더 많은 색맹 사용자분들께서도 편하게 사용할 수 있는 방식을 고안하는 것인데, 연두색을 밝은 노란색으로 교체하는 것도 좋겠습니다. 더 좋은 방법이 있다면 제안해주시면 감사하겠습니다. (o2)에 대해선 (p1~2)가 제가 드릴 수 있는 말의 전부이고, (o3)에 대해서는 팝업이 거의 즉시 나타나므로 저는 불편감을 느끼지 못했으니 사실상 더 들려드릴 의견은 없습니다. 좋은 의견 들려주셔서 감사합니다.――사도바울||X 2020년 5월 7일 (목) 22:49 (KST)답변

@사도바울:중국어 위백에서 확인해보니 '편리는 하지만 눈이 아프다'는 생각이 듭니다. 비색맹 사용자이기는 하나 연한 초록색이 눈에 잘 들어오지 않아 눈이 피로해집니다. 예시로 든 zh:Template:朝鲜战争의 경우 초록색 문서가 적어서 그나마 나았지만 대부분 초록색인 경우를 생각해보니 난감하군요. 적록색맹 사용자들도 쉽게 구분할 수 있는 다른 색이라면 찬성합니다. 다만 로그인 사용자에게도 선택권을 줘야 하므로 소도구형식으로 말입니다. 왜냐하면 팝업이 다른 글자를 가리기 때문에 본문에서 읽을 시 불편할 수 있습니다. 정리 감사합니다. 추신: 팝업은 즉시 나타나므로 속도 관련 불편은 못 느꼈습니다.--Kenlee77 (토론) 2020년 5월 10일 (일) 14:03 (KST)답변

의견 남겨주셔서 감사합니다. 초록색이 눈이 아프시다고 하셨는데, 그렇다면 링크가 빨간 색으로 표시되는 툴팁에서 원본 링크 표시를 기본 설정으로 두는 것에 대해서는 어떻게 생각하시나요? 현재는 쎄쑌(영어:Session (Presbyterianism))처럼 나와 원 문서의 제목이 길어질 수록 가독성이 낮아집니다. {{임시링크}}에서 괄호를 제거해 가독성을 높이고 툴팁으로 주시성을 높이자는 것이 본래의 취지였기 때문에, 괄호 제거 및 툴팁을 기본설정으로 하는 편이 좋겠습니다.――사도바울||X 2020년 5월 11일 (월) 10:47 (KST)답변
이의 없습니다.--Kenlee77 (토론) 2020년 5월 14일 (목) 15:22 (KST)답변

도입에는 찬성하지만 접근성을 이유로 기본 활성화에 반대합니다. 다음의 문제들이 확인됩니다 (중국어 위키백과).

  1. 툴팁을 띄우는 링크와 툴팁을 띄우지 않는 링크가 색상만으로 구분되거나, 색상으로도 구분하지 않습니다.
  2. 툴팁이 키보드 초점에 반응하지 않습니다.
  3. 툴팁이 띄워져도 문법상 전체 페이지 가장 마지막에 오게 되어 사실상 초점을 맞추거나 화면 낭독기가 읽을 수 없습니다 (이 문제는 위키백과 상단의 경보·알림 기능과 문서 미리보기 기능에도 존재하는 것으로 보입니다).

첫 번째 문제는 색맹 사용자 내지는 사용자 전체에게 불편을 줍니다. 두 번째와 세 번째 문제는 지체 장애 또는 시각장애가 있는 사용자가 타언어 링크에 접근할 수 없게 만듭니다. 다수의 편의를 이유로 장애가 있는 사용자의 위키백과 이용에 지장을 주는 것에 동의하지 않습니다. 기본 활성화 여부와 무관하게 소도구는 위키백과의 일부로서 접근성을 중시해야 한다고 생각하지만, 필요한 사용자가 선택할 수 있도록 기본 비활성화로 소도구를 도입하는 것에 굳이 반대하지는 않겠습니다.

추가로, 만약 도입된다면 틀:임시링크의 외관과 비활성화 시 틀:타 언어판 문서 호출의 외관이 일치해야 할 것입니다. 慈居 (토론) 2020년 5월 17일 (일) 01:44 (KST) (수정됨. 慈居 (토론) 2020년 5월 18일 (월) 22:57 (KST))답변

의견 남겨주셔서 감사합니다. 1번 사안에 대해서는, 문장 사이사이에 (영어) 등 내용과 무관한 문자열이 삽입됨으로써 가독성이 저해되는 것이 더 크다는 생각입니다. 또한 색상만으로 구분되지 않는다고 하셨는데, 해당 문서를 새로 생성하고자 마우스를 올리는 동시에 팝업이 떠오르므로 새로운 문서를 작성하려 하는 경우 동등한 도움을 얻을 수 있으므로 별도의 불편을 겪게 하지는 않는 것 같습니다. 이 점에 있어서는 위에 대화한 것처럼 외관을 어떻게 할지 논의하는 편이 좋겠습니다.
2번, 3번 사안에 대해서는 전혀 고려하지 못했던 사안이고, 개선되면 너무나 좋겠습니다. 이를 보완할 방법을 한번 찾아보겠습니다. {{임시링크}}와 외관이 일치해야한다는것도 동의합니다. 좋은 의견 들려주심에 다시 한번 감사드립니다:)――사도바울||X 2020년 5월 17일 (일) 23:43 (KST)답변
가독성이 저해되는 문제를 해결하는 것은 좋지만, 지금의 해법에서 색맹 사용자의 경험이 결코 동등하지 않다는 것이 저의 의견입니다. 색맹 사용자는 링크 위에 커서를 올리기 전에 타언어 링크를 안내하는 툴팁이 띄워질지를 미리 예측할 수 없으므로 비색맹 사용자에 비해 더 많은 불편이 초래됩니다. 예컨대 예상치 못하게 화면이 가려져 클릭하려던 링크를 클릭하지 못하거나, 타언어 링크를 실수로 클릭할 수 있고, 또 비색맹 사용자는 문서 전체를 훑어보고 타언어 링크가 얼마나 많이 사용되었는지 짐작이 가능한 반면 색맹 사용자는 일일이 커서를 올려보거나 문서의 원본을 살펴봐야 합니다. 색맹 사용자와 비색맹 사용자의 경험이 동등해지려면 색상 이외에도 툴팁을 띄우는 링크를 외부 링크에서와 같이 별도의 이미지로 구분하는 등 추가적인 조치가 필요합니다. 慈居 (토론) 2020년 5월 18일 (월) 22:57 (KST)답변
색맹 사용자의 경험이 동등하지 못하다는 것에는 동의하나, 그로써 초래되는 불편이 없거나 다른 사용자와 동등한 수준일 것 같습니다. 빨간 링크에 의도치않게 커서를 올려서->클릭하려던 링크를 클릭하지 못하거나/우연찮게 툴팁의 링크를 클릭하게 되는 경우가 있을지는 개인적으로 의문이 있습니다.
문자색을 도입할 생각만 했었는데, 좋은 의견 감사합니다. 색상만으로 구분하는것이 어렵다면, 가독성을 저해시키지 않는다는 전제로 다른 방식을 고민하는 것도 좋을 것 같습니다. 지금 당장 떠오르는 것으로는 별도의 문자열을 추가하거나 크기, 문자색, 배경색, 밑줄 등이 있는데요, 문자열/크기/밑줄은 가독성이 개선되기는 하나, 색을 이용한 방식이 가장 좋아보입니다. 배경색을 기본설정으로 하는것은 어떨까요? 배경색은 아무리 옅게 해도 주지성이 좋으니, 색맹과 비색맹 사용자를 아울러 가독성을 크게 저해하지 않는 채로 동등한 사용 경험을 제공할 수 있을 것 같습니다. 논의의 범위를 넓혀주심에 감사드립니다.――사도바울||X 2020년 5월 19일 (화) 00:12 (KST)답변
색맹 사용자에게 불편을 초래할 만한 각각의 상황을 검토하기보다는 그 상황을 미연에 방지하는 것이 중요하다고 생각합니다. W3C가 발표한 《웹컨텐츠 접근성 지침 2.1》에서는 "색상은 정보를 전달, 행동을 지시, 반응을 유발, 또는 시각적 요소를 구별하는 유일한 시각적 방법이 될 수 없다 (Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element)"고 권고하고 있습니다. 이에 따라 글자색 또는 배경색만을 통한 구분은 지양하는 것이 좋겠다는 의견이며, 정 필요하다면 기본 비활성화된 옵션들로 제시하는 것이 가장 바람직하다고 생각합니다. 慈居 (토론) 2020년 5월 19일 (화) 03:18 (KST)답변
배경색의 경우 색대비 문제도 있기 때문에 사용자 전체에 영향을 미칠 수 있고, 개인적으로는 심미적인 이유로 선호하지 않습니다. 慈居 (토론) 2020년 5월 19일 (화) 03:27 (KST)답변
지침의 내용에 공감하나, 비색맹사용자의 효용도 따져보아야 한다는게 제 생각입니다. 그렇지 않는다면 위키백과에서 다채로운 그림 등은 사용되지 못할 테니까요. 차라리 그림의 색까지 아우르는 색약/색맹모드를 소도구에 선택지로 추가하는 편이 더욱 나을 수도 있겠습니다. 해당 소도구의 도입으로 인한 효용은 분명합니다. 한국어 위키의 경우 {{임시링크}}는 대략 1,700회 사용되는 반면, 중국어 위키백과에서 {{타 언어판 문서 호출}}은 287,000회 가량 사용되고 있습니다. 도입시기나 전체 문서갯수만으로는 168배의 차이를 설명하기엔 부족하고, 오히려 설명문서에 명시된대로 美观(미관)이나 가독성이 비색맹 사용자들에게 더욱 큰 효용을 제공하기 때문에 널리 사용되는 것 같습니다. 따라서 폰트색을 바꾸는 것도 고려할만 하다는게 제 의견이었습니다.
그럼에도 색맹 사용자들도 구분할 수 있는 배경색이 더욱 좋을 것 같긴 합니다. 색대비야 아무리 미소하게 주어도 효용이 있으니 사용자 전체에게 주는 불편이 크지 않을 것이라는게 제 생각입니다. 나중에 후보 몇 가지를 제안한 뒤 다른 사용자들의 의견을 들어보는것도 좋겠습니다. 고견 감사합니다.――사도바울||X 2020년 5월 19일 (화) 15:20 (KST)답변
접근성은 모든 사용자에게 흑백 화면만을 제공할 것을 요구하는 것이 아니라, 색의 구분 기능에 준하면서도 색맹 사용자에게도 유효한 시각적 장치들을 함께 갖출 것을 요구합니다. 차트 등에서 색과 패턴을 함께 사용하는 것이 대표적인 예입니다. 저는 색을 통한 구분 자체가 아닌 추가적인 시각적 조치의 부재에 반대하며, 이를 비롯한 접근성 문제들이 해결되지 않은 채 기본 활성화하는 것은 장애가 있는 사용자에 대한 고려가 부족한 조치라고 생각합니다. 또 비색맹 사용자의 효용은 기본 비활성화로도 충분히 충족될 수 있다고 생각합니다. 慈居 (토론) 2020년 5월 20일 (수) 01:22 (KST)답변
그러나 배경색을 사용할 경우 비색맹 사용자도 구분이 가능합니다. WCAG2.0에서는 7:1이상의 대비를 줄 경우 색맹 사용자들의 접근성에 문제가 없다고 말하고 있습니다. 심미안과 가독성을 둘 다 잡을 수 있는 배경색을 고민하고 있는데, 선생님께서도 의견 주시면 즐거이 듣겠습니다. 비색맹 사용자의 효용에 대해선, {{임시링크}}만으로 현재 충분히 내용을 인지할 수 있기는 하나, 현재 중국어 위키와 비교할 때 168배나 사용이 저조한 이유는 추가적 문자열로 인한 가독성 저해인 것으로 파악됩니다. 실제로 중국어 위키에서도 이를 언급하고 있고요. 따라서 효용을 극대화시키고 사용에 거리낌을 덜기 위한 방안을 제안한 것이니, 이 점 고려해주시면 감사하겠습니다. 좋은 하루 되세요:)――사도바울||X 2020년 5월 20일 (수) 11:49 (KST)답변
임시링크 틀의 사용이 저조한 건, 편집자들이 잘 사용하지 않아서이지, 가독성 때문은 아닙니다. -- ChongDae (토론) 2020년 5월 20일 (수) 12:03 (KST)답변
배경색을 사용하는 설정은 앞서 말씀드렸다시피 색대비 문제로 인해 접근성 문제를 야기합니다. WCAG 2.1 (또는 2.0)에서는 텍스트 대비 배경에 최소 4.5:1 (AA 등급 기준, AAA 등급은 7:1)을 요구하고 있고, 비텍스트 요소에 대해서는 3:1 (AA)을 요구합니다. 이 둘의 곱(13.5)은 예컨대 검은 텍스트와 틀:정보상자의 연한 회색 배경 사이의 대비(약 9:1)의 약 1.5배이므로 두 가지 요구사항을 모두 만족하는 중간색을 찾는 것은 불가능합니다. 또 모든 작업 환경(고대비 모드, 블루라이트 필터 사용 등)에서 모든 외측 배경색(틀 문서에 끼워넣은 설명문서의 녹색 배경, 틀:정보상자의 연한 회색 배경 등)에 대해서 유효한 조치인지 고려되어야 합니다. 그리고 배경색의 사용은 (그 색의 종류와 무관하게) 이 소도구의 본래의 목적인 가독성과 심미성을 저해시킬 수도 있다고 판단됩니다.
중국어 위키백과는 한국어 위키백과보다 규모가 더 크고, 타언어 링크에 관한 논의가 훨씬 오래 전부터 있어 왔었기 때문에 단순한 수치상의 비교는 의미가 없다고 생각합니다. 중국어 위키백과에서도 각각의 배색 방안에 대한 호불호가 갈리는 것으로 보이며, 이는 오히려 특정 방안 활성화를 기본 설정으로 삼을 이유가 부족하다는 방증이 될 수도 있다고 생각합니다. 무엇보다 틀:임시링크는 적어도 모든 사용자에게 유효한 기능을 제공한다는 점에서는 적어도 틀:타 언어판 문서 호출보다 뛰어나며, 중국어 위키백과에서 이 측면에 대한 논의는 찾아볼 수 없습니다.
제가 접근성 관련해서 계속해서 의견을 내는 이유는, 기본 활성화를 주장하심과 동시에 기본 설정에서 접근성을 고려하는 것은 원하지 않으시는 것으로 보이기 때문입니다. 접근성 문제가 해결된다면 기본 활성화하는 데 아무런 이의가 없습니다. 기본 비활성화에 동의하신다면 접근성 문제를 방치하는 것에 굳이 이의를 제기하고 싶지 않습니다. 하지만 이 두 가지가 모두 포기된다면 장애가 있는 사용자의 위키백과 이용에 치명적일 수 있으며, 누군가의 편익을 위해 누군가의 정상적인 이용이 방해 받을 수 있다는 것을 이해해 주셨으면 좋겠습니다. 慈居 (토론) 2020년 5월 20일 (수) 14:50 (KST)답변
아이고, 제가 접근성을 고려하지 않는다고 생각하시니 섭섭합니다. 접근성에 대한 선생님의 의견을 수용해서 배경색을 제안드린건데요. 말씀하신 사안들이 모두 고려되어야 한다는 점에 저도 동의합니다. 저는 접근성을 결코 포기하고싶지 않고, 최근까지 녹색 글씨색을 옹호하는 듯한 말씀을 드리긴 했으나 이는 그저 해당 틀의 효용을 강조하며 선생님의 주장에 대한 제 생각을 말씀드린 것 뿐입니다. 배경색에 대해서 한번 좋은 안이 제안될 수 있도록 하겠습니다. 그 때 의견 주셔도 감사하겠습니다.――사도바울||X 2020년 5월 20일 (수) 21:50 (KST)답변
다시 한 번 말씀드리지만, 배경색을 사용하는 것은 접근성에 부합하지 않으며, 녹색 글씨색 자체가 문제가 아니라 그 외의 상응 조치의 부재가 문제입니다. 그리고 저는 분명 기본 설정에서 접근성을 고려하지 않고 계시는 것 같다고 말씀드렸습니다. 慈居 (토론) 2020년 5월 21일 (목) 01:23 (KST)답변
접근성을 고려하지 않은게 아니라, 배경색으로 접근성을 해결할 수 없다는 의견에 동의하지 않은 것 뿐입니다. 저는 접근성 문제를 해결할 수 있는 디자인이 존재할 것이라고 생각하며, 그런 디자인을 찾는다면 기본설정으로 할 수 있다고 생각합니다. 배경색이 제안될 경우 선생님께서 직접 평가해주시길 바란 것도 접근성을 고려하기 위한 것이었는데, 기본설정에서 접근성을 고려하지 않는 사람이라고 말씀하신 것은 오해이십니다. 접근성의 필요에 깊이 공감하고 있습니다. 다만 제가 웹 디자인 분야를 잘 알지 못하여 위에 4.5와 3의 곱인 13.5를 만족해야 한다고 말씀하신 것을 제가 이해하지 못했기 때문에 아마 그런 오해를 산 것 같은데, 이 부분에 대해서 조금 더 자세한 설명을 해주시면 감사하겠습니다. 해당 설명에 의하면 대비가 4.5:1을 넘는다면 텍스트/비텍스트 모두에서 AA등급인 것 아닌가요?――사도바울||X 2020년 5월 21일 (목) 03:25 (KST)답변
접근성 관련해서 제가 사도바울님의 의견을 오해했다면 죄송합니다. 그리고 기본 설정에서 접근성의 필요성에 공감해 주셔서 감사합니다.
WCAG 2.1에 따르면 이웃하는 비텍스트 요소들의 색상에도 충분한 대비가 있어야 합니다. 텍스트에 배경색을 사용할 경우 텍스트와 텍스트 배경 사이, 텍스트 배경과 외측 배경 사이에 각각 최소한 4.5:1, 3:1의 대비가 있어야 하며, 이는 텍스트와 외측 배경 사이의 대비가 13.5:1 이상이어야만 만족될 수 있습니다. 하지만 이 비율은 기존에 사용되던 텍스트와 외측 배경 사이의 대비(틀:정보상자에서의 9:1)를 상회하므로 이 요구사항에 맞는 배경색은 존재하지 않습니다. 慈居 (토론) 2020년 5월 21일 (목) 05:16 (KST)답변
저야말로 감사의 말씀을 드리고 싶습니다. 사려깊은 조언 덕분에 접근성에 대한 제 이해가 깊어질 수 있던 것 같습니다. 지금 로 확인해보니 배경색과 글자색의 대비가 정보상자는 #F8F9FA로 19.92배, 정보상자 제목은 #CCCCFF로 13.64배, 틀 설명문서는 #ECFCF4로 19.79배, site notice는 #E8EEFF로 18.1배입니다. 따라서 13.5:1의 대비를 가지는 표현형을 아예 구현할 수 없는 것은 아닙니다. 그리고 13.5배를 채우지 못하더라도 WCAG 기준을 충족시키는 디자인 사례는 존재합니다. 대표적인 예시로, 배경과 전경이 4.5:1의 대비를 가지고 텍스트가 배경과 같은 색을 가지는 경우도 있습니다. 네이버가 이런 인터페이스를 주로 사용하고 있습니다. 지금 이러한 디자인을 제안하는 것은 아니고, 단지 산술적 곱을 기준으로 가불가 여부를 판단하는 것에 대한 반례를 제시하는 것 뿐이니 양해해주시면 감사하겠습니다. 좋은 하루 되세요:)――사도바울||X 2020년 5월 21일 (목) 11:34 (KST)답변
틀을 사용할 때 색대비를 고려해야한다는 문구를 삽입하는게 좋겠습니다.――사도바울||X 2020년 5월 21일 (목) 11:45 (KST)답변
저의 계산에 착오가 있었습니다 (배경색을 #AAAAAA로 잘못 가정했습니다). 실제 틀:정보상자에서의 대비는 9:1가 아닌 말씀하신 19.92가 맞습니다. 하지만 저와 사도바울님 모두 검은색 텍스트를 기준으로 계산한 것 같습니다. 빨간색, 녹색 등 링크에 사용된 텍스트의 경우 대비가 13.5:1보다 낮을 것이라고 생각됩니다. 저의 결과는 방문한 적 있는 빨간색 링크(#A55858)는 4.81, 방문한 적 없는 빨간색 링크(#BA0000)는 6.45, 녹색 링크(#00AF89)는 2.65로 모두 13.5:1에 크게 못미칩니다. 慈居 (토론) 2020년 5월 21일 (목) 14:54 (KST)답변
저도 FFFFFF를 기준으로 계산했습니다만, 말씀하신 것처럼 빨간 계열로 인지되도록 하는 편이 가장 좋습니다. 그러나 빨간 계열이라 함이 꼭 빨간 글씨색을 의미하는 것은 아니고, 붉은 계열의 어두운 색을 사용해도 괜찮을 것 같습니다. 아니면 네이버처럼 글자색을 배경색의 방향으로 조절할 수도 있겠는데, 가독성을 고려할 때 눈이 많이 아플 것 같아 저로서는 이를 생각하고 있지는 않습니다. 글자에 그림자를 주는 방식도 고려해볼 수 있겠습니다. 아무쪼록 좋은 디자인이 제시되면 좋겠네요. 저도 한번 생각해보겠으나, 이번주는 좀 힘들 것 같습니다.――사도바울||X 2020년 5월 22일 (금) 01:59 (KST)답변
기존의 링크 색상을 변경하는 것은 디자인의 일관성을 해치므로 바람직하지 않다고 생각합니다. 밝은 글자색과 배경색 사이에 어두운 배경색을 넣는 것이 가독성을 해친다고 말씀하셨는데, 저는 텍스트에 별도의 배경색을 넣는 것 자체가 가독성을 심하게 저해한다고 생각하며, 대부분의 사용자들이 이를 마음에 들어하지 않을 것이라고 추측합니다. 특정 의미를 전달하는 이미지, 패턴, 기호 등을 사용하는 일반적인 해법 대신 배경색을 사용하는 것이 색에 대한 의존도를 줄이는 적절한 해법이라고 생각하지도 않습니다. 慈居 (토론) 2020년 5월 22일 (금) 05:31 (KST)답변
지금 대화가 평행선을 달리는듯한 느낌이 살짝 있습니다. 심미성이나 가독성의 경우 사실은 추측에 의존하는 부분도 많이 있습니다. 이 부분은 대문 디자인 변경때 했던 것처럼 투표로 의견을 듣는게 가장 좋은 방법일 것 같습니다. 색에 대한 의존도를 줄여야 한다는 W3C의 말에는 공감하나, 빨간 링크와 파란 링크를 전부 (없음), (있음)로 대체하지 않는 것은 일반적 사용자들의 효용도 고려했기 때문으로 보입니다. 물론 접근성을 포기하자는 것은 아닙니다! 다만 색과 접근성에 대한 논의는 WCAG 2.0의 level AA를 만족시키는 것으로 충분하지 않을까 해서 드리는 말씀입니다. 감사합니다:)――사도바울||X 2020년 5월 22일 (금) 11:35 (KST)답변
심미성과 가독성에 대한 저의 개인 의견은 개인 의견으로 참고해 주셨으면 좋겠습니다. 말씀하신 것처럼 사용자들의 의견을 수렴하는 것이 중요하다고 생각합니다. 다만 접근성을 고려함에 있어서 WCAG 2.1 충족 여부만 고려하는 것은 절대 충분하지 않으며, 그에 상응하는 현실적인 고려도 있어야 합니다. 텍스트 배경색을 사용할 경우 기존보다 텍스트 대비가 낮아지므로 (기존의 색대비의 최소 약 1/3로 낮아질 것으로 보입니다) 텍스트 인식이 더 어려워지는 것은 사실입니다. 이에 따라 이후 도입될 새로운 기능과 호환되지 않거나, 또는 새로운 기능의 도입에 일정 정도의 제약이 생길 수 있음도 고려해야 합니다. 배경색이 선택된 요소들의 색상(파란색), 브라우저의 찾기 기능에서 쓰이는 텍스트 배경색(노란색, 녹색 등) 등과의 구분이 수월한지도 고려해야 합니다. 텍스트 배경색은 앞서 말씀드렸다시피 색에 대한 의존도를 줄이는 전형적인 방법이 아니므로 저는 여러 가지 잠재적인 문제들을 우려하여 이에 부정적임을 이해해 주시면 감사하겠습니다. 慈居 (토론) 2020년 5월 22일 (금) 14:04 (KST)답변
기존의 파란색, 빨간색 링크에 추가 구분 방법이 없음을 지적하셨지만, 지금의 문제는 구분이 쉽던 기존의 색상에 제3의 색을 추가하는 것으로부터 시작됩니다. 물론 일부 사용자들에게는 예시 , 예시 와 같은 방법이 도움이 될 수 있습니다. 기존에 (외부 링크에서) 사용되던 방법이므로 잠재적인 문제의 우려가 적고 기존의 디자인과의 일관성이 준수될 수 있기 때문에 저는 이 방법을 가장 선호합니다. 慈居 (토론) 2020년 5월 22일 (금) 14:58 (KST)답변
늦게와서 죄송합니다. 와, 이거 진짜 괜찮아보이는데요? 문자열이 아니라 아이콘인데다 현재 외부링크 아이콘처럼 복잡한 구조도 아니어서 가독성 문제도 해결할 수 있을 것 같습니다. 디자인도 단순해서 심미안도 좋아보이고, 도형의 의미가 본래 취지에 맞기도 하고, 접근성 문제도 바로 해결되네요. 후보를 좀 모아서 어떤걸 기본 설정으로 할지는 별도의 총의로 정해야겠습니다. 배경색은 지금 몇가지 시도해봤는데, 아무리 봐도 level AA를 만족하면서 문서 내에서 사용할 수 있을 정도로 가독성이 좋은 디자인은 정말 찾기가 힘드네요. 해당 디자인을 기본설정으로 하는 것에 찬성합니다. 정말 좋은 디자인 감사합니다!:)――사도바울||X 2020년 5월 23일 (토) 20:29 (KST)답변
도입에 찬성하며, 慈居님의 의견에도 동의합니다. —{{사|친절한사용자}}토론 2020년 5월 19일 (화) 17:11 (KST)답변
도입 자체 반대 제 의견은 일단 임시링크라는 것은 말 그대로 "임시방편"일 뿐, 보편적인 도구라고 볼 수만은 없다는 것입니다. 다른 언어판에서 좋은 정책이 있거나 틀이 있는데 이를 모두에게 참고하게 할 경우나, 공동 번역을 할 때 원어판을 참고하거나, 이런 식으로 문서에서 필요한 때만 사용해야 하는 것입니다. 저는 그렇기 때문에 해당 도구가 들어올 지라도 위키백과에 커다란 향상이 있으리라고 예상하지는 않습니다. 오히려 임시링크 틀이 일반화되어 사용될 경우, revi 님의 말씀대로 긍정적인 기능보다는 부정적인 영향이 더 커질 것입니다. 문서 편집 횟수가 낮아지고, 독자들 입장에서는 해당 링크를 클릭하면 다른 언어판 문서가 나와 이해하기 오히려 어려울 수 있기 때문에 가독성이 저해됩니다. 그렇기에 저는 일단 반대하는 것으로 의견 남깁니다. -- Yelena Belova (토론) 2020년 5월 19일 (화) 23:45 (KST)답변
(1-1) 녹색 링크가 문서가 마치 있는 것 처럼 보이게 할 수 있다고 하시는데, 경험적으로는 공감이 되지 않지만 웬디러비님이나 revi님께서 그런 경험을 하신 적이 있다니 그런 경우도 있다는 것을 인정해야겠습니다. 다만 얼마나 많은 사람이 유의미한 불편을 느낄지는 여전히 의문이고, 혹시 이로 인한 불편을 느끼신 분이 또 있으시다면 밑에 덧글 달아주시면 감사하겠습니다.
(1-2) 그리고 사실은 녹색 링크를 기본설정으로 하자는 것은 현재 ted님이나 慈居님 등으로부터 지적이 많이 되었습니다. 따라서 현재 논의되고 있는 부분도 표현형을 어떻게 해야 좋을지에 대한 것인데, 지금 두 분께서 지적해주신 사안도 고려한다면 고려한다면 폰트를 빨간색으로하고 배경색에 차이를 두는 것도 좋겠습니다. 중요한 것은 여분의 문자열을 제거하는 기능이니까요.
(2-1) 해당 기능이 제공된다면 편집자들이 생성에 필수적인 문서를 생성하기보다는 link-en 등을 다는 데에 그칠 것이라 지적해주셨습니다. 우선 생각나는건 {{타 언어판 문서 호출}}에 "이 틀이 문서의 생성을 대체할 수는 없음"을 눈에 잘 보이게 강조하는 방법이 있겠네요.
(2-2) 그리고 만일 그렇다고 해도 분명한 효용은 있을 것입니다.
(2-2-1) 문서의 생성이 필수적으로 여겨지지만 시간이 없는경우 이 틀을 사용할 수 있습니다. 저 같은 경우 기독교 관련 문서를 편집할 때 그러한데, 문서 생성에 필수적으로 보이는 문서들도 있지만, 문서 생성에 우선 순위가 있으며, 개인의 사생활에서 위키편집에 할당된 우선 순위도 다들 다를 것입니다. 따라서 필수적으로 보이는 경우에도 틀의 추가를 통해 조치할 수 있습니다.
(2-2-2) 문서 생성이나 위키편집에 할당된 순위가 높다 하더라도, 실제로 문서를 작성하는데 시간이 너무 오래걸린다면 임시적으로 조치할 수도 있습니다. 제가 존 칼빈프랑시스 풀랑크 문서를 편집할때 그랬습니다. 거대한 문서를 작업하는데에는 거의 한 달이 넘게 걸립니다. 빨간 링크중 필수적이라고 생각되는 것들도 있었지만, 한 달이 넘게 작업하다보면 아예 까먹거나 편집이 늦어지는 경우가 부지기수입니다.
(2-2-3) 만일 생성이 시급해보이지 않는 문서인 경우, 당연히 효용이 있을 것입니다. 편집자들은 문서를 훑어보며 생성이 필요하고 또 참고할 수 있는 페이지를 쉽게 찾을 수 있고, 표현형이 개선된다면, 편집자가 아닌 다른 독자들 중 외국어 능력이 있는 사람들의 경우 도움을 받을 수 있습니다. 외국어를 잘 못하는 독자의 경우 해당 틀을 보고 자격지심을 느낄 수도 있겠습니다만, 현실적으로 그런 사람이 얼마나 될지는 의문입니다. 만일 로그인한 사용자들에게만 소도구를 켜 놓을 수 있다면, 그렇게 하는 것도 좋겠습니다.
해당 사안에 대해서는 사랑방에서 대화 나누었습니다. 웬디러비님과 revi님의 의견, 이에 대한 제 생각에 대해 더 자세한 정보를 얻고 싶으신 분들은 사랑방의 내용 참고해주시면 감사하겠습니다. 지금 좀 바빠서 이 내용으로 답변하는 것을 양해해주시면 감사하겠습니다.――사도바울||X 2020년 5월 20일 (수) 11:49 (KST)답변
문서의 생성이 필수적이라고 판단될 경우, 사용자 문서 등에 목록을 만들어두어 이를 확인하는 방법도 있고, 실제 많은 사용자들이 이러한 방법을 사용하고 있습니다. 굳이 해당 틀을 사용할 이유는 없습니다.
거대한 편집에 관해 한 명이 모두 책임을 떠맡을 필요가 없습니다. 저 역시 영국 전차의 역사 문서를 편집하면서 수많은 붉은 링크들이 있었지만 해당 붉은 링크를 해결하기 위해 저는 에디터톤, 오프라인 모임, 공동 편집 등을 적극적으로 활용하고자 했습니다. 이는 다른 문서들도 마찬가지입니다. 해당 링크를 붉은 링크로 남겨두어 다른 사용자들과 같이 편집을 하거나, 해당 주제를 공론화시킬 생각을 해야지, 이걸 혼자서 다 해결하지 못한다고 해당 틀을 활용하는 것에 대해서는 상당히 부정적인 입장입니다. 앞서 사랑방에서 오간 이야기처럼 문서가 필수적인 경우 토막글이라도 만든 다음 이것을 다른 사용자들이 꾸준히 기여할 수 있도록 해야 합니다. 특히 한 달 이상의 문서 편집이 예상될 경우, 당연히 우리는 오프라인 모임이나 에디터톤을 통해 이를 해결할 수 있습니다. 현재는 온라인 에디터톤도 활기를 띄기 시작했고요. 이러한 수많은 제도와 시스템이 있는데 이걸 활용하지도 않고 그냥 저 틀 하나로 해결하려는 것에 대해 저는 개인적으로 반대합니다.
무엇보다도 현재 사용자님이 해당 틀을 판단하시는 기준은 "문서를 편집하는 사람들"에 관한 것입니다. 단순히 편집을 하지 않고 위키백과의 문서만 읽으러 오는 독자들의 경우, 해당 틀은 혼란만 부추길 뿐입니다..만약에 해당 틀이 효용성이 있었다면 영어판이나 스페인어판, 프랑스어판과 같이 독자와 사용자 수가 많은 곳에서 일반적으로 널리 쓰였겠지요. 효용성이 있는 지 없는지 섣불리 판단할 수 없는 상황에서 무작정 도입하거나 받아들인 것들이 현재 한국어 위키백과 및 위키미디어에서 버려지는 경우는 수도 없이 많았습니다. 더욱이 해당 틀을 써놓고 독자들에게 읽고 알아서 판단하세요,라는 건 독자들을 전혀 고려하지 않은 행동입니다. 위키백과 문서 자체가 사용자&독자 친화적이어야 합니다. 해당 틀을 기본 도구로 사용하자는 것은, 여태까지 임시링크를 사용해오던 위키백과 사용자 및 독자 모두에게 혼란을 줄 테고요. 효용성이 있다고 확신하셔서 그에 따른 주장을 제시하기보다는, 객관적으로 임시링크와 기능이 중복되는 이 틀이 향후 사용자들이나 독자들에게 어떤 영향을 미칠 지 고려하는 게 우선이라고 생각합니다. -- Yelena Belova (토론) 2020년 5월 20일 (수) 15:50 (KST)답변
의견 감사합니다. 사용자문서에 필요한 문서들을 정리할 수 있다고 하셨는데, 개인적으로 매우 좋은 방식이라고 생각합니다. 그러나 사용자 문서보다는 해당 틀을 사용하여 일반문서에서 바로 접근할 수 있게 하는 편이 접근성이 더 뛰어나다고 생각합니다.
거대한 편집을 위해 에디터톤을 여는 편이 더 좋습니다. 그러나 이 틀은 에디터톤의 대체를 목적으로 하는 것도 아니고, 이 틀의 도입이 사용자들의 에디터톤 개최 의지를 반감시킬 것 같지도 않습니다. 에디터톤은 특정 주제에 흥미가 있는 사람들이 적극적인 참가요청을 함으로써 특정 방향으로의 거대한 기여를 촉진하는 역할이 있는 것으로 이해하고 있습니다. 그러나 이 틀은 특정 주제를 위한 것이 아니고, 특별한 참가요청도 필요하지 않다는 점에서 오히려 에디터톤을 보조하고 긍정적인 방향으로 상승효과를 낼 수 있을 것으로 기대합니다. 물론 웬디러비님처럼 에디터톤에 훌륭한 기여를 해주시고 그 유익에 공감하는 분들의 적극적인 기여로 인한 에디터톤은 계속 열릴 것입니다.
독자들에게 가져올 혼란은 녹색 링크가 빨간 링크와 동종으로 인식되지 않는 점을 말씀하신 것으로 이해했었습니다. "아직 생성되지 않았으며, ~를 참고할 수 있습니다"는 문구가 독자를 고려하지 않은 행동이라는 말씀에는 잘 공감되지 않습니다. 빨간 링크를 채우는 것이 더 좋은 기여라는 점은 100% 인정합니다. 하지만 모든 빨간 링크를 채울 수는 없는 일입니다. 오히려 부득이하게 빨간 링크를 남겨야 할 경우 추가적인 정보를 제공함으로써 독자들에게 더 많은 편의를 제공할 수 있습니다.
향후 사용자나 독자들에게 어떤 영향을 미칠지 고려해야한다는 점에 완전히 동의합니다. 따라서 현재 이에 대해 서로 의견을 교환하는 중이라고 생각합니다. 효용이 커 보인다는 것이 제가 현재 생각하는 바인데, 이 생각이 마치 단단하게 굳어서 바뀌지 않는 것은 아닙니다. 오히려 좋은 말씀 많이 들려주셔서 생각의 범위가 넓어지는 것 같습니다. 감사합니다:)――사도바울||X 2020년 5월 20일 (수) 21:50 (KST)답변
맨 처음 사용자님이 주장을 하신 것으로 되돌아가보죠.
일단 임시링크가 가독성이 떨어진다고 하셨는데, 이는 사용자들이 문서를 편집하면서 발생하는 상황이 아닌, 사용자들이 편집한 결과를 두고 판단해야 합니다. 웬디 (가수)를 예로 들어보자면, 웬디가 다녔던 학교 리치먼드힐 고등학교는 현재 붉은색으로 표시되어 있고, 해당 링크에 임시링크를 걸어준다면 이는 연파랑색으로 바뀔 것입니다. 하지만 색깔은 가독성에 영향을 크게 미치지는 않습니다. "웬디는 캐나다 온타리오의 리치먼드힐 고등학교에서 공부했고"라는 이 문장이 가독성이 떨어진다고 판단하려면 해당 문장에 출처가 5개 이상 달려있거나 웬디, 캐나다 등에 캐나다 (Canada) 식으로 영어를 병기하는 등의 번잡한 문장 서술 등을 예로 들 수 있겠네요. 하지만 임시링크 틀의 경우에는 (물론 되도록 사용하지 않는 것이 좋겠지만) 편집 과정에서 발생하는 문제입니다. 이미 우리는 각주, 분류, 언어 병용 표기 등 수많은 틀을 문서 편집에서 사용하고 있으며, 이렇기 때문에 문서를 처음 편집하려고 시도하는 이들 입장에서는 가독성이 떨어질 수 있겠죠. 하지만 이것은 틀을 교체해서 해결할 문제가 아니라, 해당 사용자들에게 이 틀이 어떤 기능을 하고 왜 붙어 있는지를 설명해주며 해결해야 한다고 생각합니다. 초보 사용자들도 나중에 문서를 제대로 편집하려면 이러한 복잡한 구조에 대해 이해해나가야 하고요. 정리하자면 문서 외부에 나타난 결과던 문서 편집 과정에서던 가독성을 고려해서 임시링크 틀을 다른 틀로 바꿔야 한다는 것에 대해서는 다른 관점에서 접근해야할 문제라고 봅니다.
둘째로 해당 링크가 아예 완전히 문서 생성을 대체하지는 않을 것이라고 보셨습니다. 하지만, 생각해보죠. 우리가 주로 문서를 생성하는 경우는 붉은색 링크가 있을 때, 그것을 채워야한다는 인식이 있기 때문에 가능한 것입니다. 하지만 이러한 붉은색 링크가 겉으로 드러났을 때 사라진다면, 어떻게 될까요. 사용자님과의 토론을 통해 중국어판의 한국 전쟁 틀의 역사를 살펴보면, 2014년 4월 22일판에 "다부동 전투"의 링크가 Gadgets-definition 틀 사용을 통해 영어판으로 넘겨주기 되었습니다. 하지만 이후 해당 문서를 생성하기보다는 원래 붉은색 링크였던 경주, 주문진항, 영덕-강구, 282고지, 사미천, 피의 능선, 원주 (제1-2차 원주) 등이 모두 Gadgets-definition 틀로 변경되었고, 다부동 전투는 그렇게 편집이 바뀐 후 6년 동안 문서 생성이 이루어지지 않았습니다. 이것은 당초 revi 님이 말씀하신 우려가 현실로 드러난 대표적인 사례라고 볼 수 있겠지요. 해당 틀을 사용하면서 문서 생성을 대체하는, 그런 편집 방식이 나타난 것입니다. 그렇다 할 지라도 효용이 있다는 것은 더더욱 아닙니다. 당초 문서가 붉은색이라면 번역을 하던, 자료를 찾던, 아니면 공동 편집을 해서 문서의 생성으로 이어지지만, 해당 틀을 사용하게 되면 말 그대로 그 문서는 타 언어판으로 넘어간채 그대로 잊혀지는 겁니다. 자연스레 관심 밖으로 밀려날 일이지요. 결국 현재 임시링크 틀이나 새로운 틀이나 똑같은 문제가 발생하는 것입니다. 이는 다시 2-2-2, 및 2-2-3으로 연결지어, 해당 문서의 우선순위가 상위이던 하위이던, 그리고 생성이 시급하던 시급하지 않던 결국 모든 문서의 편집은 애당초 붉은색 링크를 적용했을 때보다 더 심각해지는 겁니다. 붉은색 링크들이 초록색 링크로 바뀌는 편집 역사만 보더라도, 이미 해당 문서를 직접 생성하기보다는 넘겨주기로 대체하고 있다는 것이지요.
앞서 말한 2-2-1의 경우에는 자신이 그 편집에 모든 것을 할애할 때 발생하는 상황이라고 보겠습니다. 오히려 토막글이라도 만들고, 다른 사용자들이 기여를 할 수 있도록 돕는 것이 여러모로 유익하다고 생각합니다. -- Yelena Belova (토론) 2020년 5월 21일 (목) 00:53 (KST)답변
(1) 색은 눈이 아픈 경우를 제외하고는 가독성에 큰 영향을 미치지 않는다는 말씀에 동의합니다. 현재 임시링크를 작성할 경우 리치먼드힐 고등학교(영어판)와 같이 나오는데, (영어판)이라는 여분의 문자열이 추가됨에 따라 가독성이 저해됩니다. 연파란색 링크가 나오긴 하지만 이것이 가독성을 저해한다고 생각하지는 않고, 별도의 문자열이 추가됨에 따라 번잡한 문장 서술이 이루어진다는 점을 지적한 것이었습니다.
(2) 붉은색 링크가 겉으로 볼 때 사라지는 것이 문제가 될 수 있다는 말씀은 완전히 수용했습니다. 따라서 초록색 글자를 기본 표현형으로 하자는 주장은 이미 포기했으며, 현재는 붉은색을 베이스로 하고 배경색에 차이를 두어 구분하는 방안을 제안하고 있습니다.
(3) 크로스링크 기능이 널리 사용됨에 따라 새로운 문서의 생성이 늦어진다는 말씀의 사례로 중국어 위키의 틀을 근거로 제시하셨습니다. 그러나 붉은 링크가 생성되는 속도에 비해 크로스링크가 달린 문서가 생성되는 속도가 느린지는 확인하기 어렵습니다. 한국전쟁 틀만 보아도 포항, 경주, 哈里哨가 채워졌고, 당장 {{타 언어판 문서 호출}}의 역링크에서 처음으로 나오는 틀에서도 새로운 문서들이 채워졌습니다. 문서가 생성되었으나 아직 크로스링크 틀이 제거되지 않은 문서의 목록도 zh:Category:有蓝链却未移除内部链接助手模板的页面에서 확인하실 수 있습니다. 문서 관리에 도움이 되라고 만들어 놓은 추적 분류에 이만큼의 문서가 존재한다는 점도 참고해주시면 감사하겠습니다.
(1-첨언)그리고 정말 죄송하지만, "편집과정에서 발생하는 문제"라는게 무엇을 말씀하시는건지 잘 이해하지 못했습니다. 따라서 말씀드리기 매우 조심스럽습니다만 몇 마디 덧붙이자면, 처음 편집하는 초보 편집자가 가독성에 어려움을 겪을 경우 틀에 대한 이해를 먼저 시켜주어야 한다는 말씀을 하시는 것 같습니다. 물론 틀에 대한 이해를 먼저 시켜주는 것이 중요하겠지만, 틀의 초보 편집자의 가독성을 향상시키며 틀의 사용을 편리하게 하는 것의 유익도 분명히 있습니다. 아마 제가 웬디러비님의 말씀을 오해해서 완전히 다른 얘기를 하는 것 같은데, 그렇다 할지라도 별개의 주장으로 읽어주시면 감사하겠습니다.
시간이 늦어서 제 말에 두서가 없을 수도 있습니다. 부디 너른 마음으로 양해 부탁드리고, 이해가 되지 않으시는 부분이 있으시다면 바로잡아주시면 감사하겠습니다. 토론에 적극적으로 참여해주셔서 감사합니다.――사도바울||X 2020년 5월 21일 (목) 03:25 (KST)답변
아무래도 오해가 있으신 듯 한데, 문서 지연뿐만 아니라 revi 님이 말씀하신 문서 생성 대체 기능으로 해당 틀이 사용되고 있다는 것을 보여주기 위해 중국어판의 예시를 보여드렸습니다. -- Yelena Belova (토론) 2020년 5월 21일 (목) 04:58 (KST)답변
문서의 생성하는 대신 link-en을 사용할 수 있으며, 실제로 (2-2)의 하위 문단은 모두 이를 전제로 하였습니다. 문서 생성을 억제하지 않는다는 것이 제 주장이었던 것도 맞습니다. 대체하나 억제하지 않으며, 오히려 촉진할 수도 있다는 것이 제 중심 주장이라고 보셔도 되겠습니다.
붉은색 링크를 없애면 생성이 필요하다는 사실을 숨길 수 있으며, 그에 대한 직접적인 예시로 다부동 전투가 6년간 생성되지 않고, 기타 문서들이 토막글이라도 생성되는 대신 해당 틀이 달렸다는 사실을 제시해 주셨습니다. 붉은색 링크에 대한 예리한 지적은 수용했습니다. 생성 대체에 대한 제 생각은 위의 (2-2)에 기술한 바와 같으며, 중국어 틀의 사례에 대한 제 해석은 제가 바로 위에 작성한 바와 같습니다. 틀이 붙은 뒤로 오랫동안 생성되지 않은 문서도 존재하지만, 이것이 기존의 빨간 링크보다 해당 문서를 관심 밖으로 밀어낸다고 말씀하시려면 빨간 링크의 생성속도와 크로스링크 문서의 생성속도를 비교하셔야 합니다. 그러나 지금 2013년 6월 9일 이 틀이 중국어의 한국전쟁 틀에 사용된 이후 125개의 역사를 추적했을 때 시흥-안양-수원, 한강, 미아리, 제1차서울, 포항, 온정리, 경주, 대전, 안동, 哈里哨, 신천군사건, 고양금정굴 사건, 노근리사건이 크로스링크가 달린 후에 생성되었음을 확인할 수 있었습니다. 표현형만 적절히 고쳐진다면 오히려 어떤 문서의 생성이 더욱 시급한지 강조하는 데에도 사용될 수 있겠습니다.
토론에 적극적으로 참여해주셔서 감사합니다. 좋은 하루 되세요:)――사도바울||X 2020년 5월 21일 (목) 11:34 (KST)답변
개인적인 의견인데 아무리 이를 옹호를 할 수 없는 것이, 중국은 한국 전쟁 참전국입니다. 이에 따라 비록 형평성에는 문제가 제기될 수 있겠지만 중국 역시 많은 한국 전쟁 관련 자료가 있을 것입니다. 그럼에도 불구하고 전투 문서를 바로 생성하지 않고 해당 틀을 사용했다는 것은 앞서 revi 님이 지적한대로 귀찮음으로 인한 넘겨주기라고 볼 수밖에 없습니다. 해당 틀이 걸려 있었거나 현재 걸려있는 와원 전투, 온정리 전투, 설마리 전투, 쌍터널 전투, 원주 전투, 제2차 동두천 (의정부 1951년), 피의 능선 전투 등은 모두 중국군이 직접 참전한 전투이므로 사용자들이 얼마든지 마음만 먹으면 문서를 생성할 수 있었습니다. 중국인민지원군 문서는 출처와 각주가 달려 있고 관련 링크까지 걸려 있는 마당에, 해당 군이 참전한 전투는 임시링크로 걸려 있다는 것도 주목할만 한 점이지요. 오히려 저는 이 사례를 통해 revi 님께서 지적하신 것이 현실화되고 있다는 것으로 판단하여, 현재 틀에 대해 기본 도구로 도입하자는 제안을 반대하겠습니다. -- Yelena Belova (토론) 2020년 5월 21일 (목) 14:06 (KST)답변
(1) 1차자료가 많기 때문에 마음만 먹으면 수월하게 문서를 생성할 수 있음에도 이 틀의 도입이 토막글을 비롯한 신규 문서 생성에 부정적 영향을 끼쳤다고 말씀하시는 것 같습니다. 문서 생성이 얼마나 수월할지는 차치하더라도, 크로스링크가 문서를 새로 만들고자 하는 동기를 낮추었다는 말씀에는 공감이 어렵습니다. 현재 해당 틀의 크로스링크중 다수가 오랫동안 생성되지 않았음을 근거로 제시하시나, 빨간링크의 다수가 오랫동안 생성되지 않았다는 것이 빨간링크가 토막글 생성을 의지를 낮춘다는 근거로 적절하지 않은 것과 마찬가지로 충분한 근거로 읽히지는 않습니다. 빨간 링크와 크로스링크가 문서가 생성되는데 걸리는 시간을 비교해주시면 좋겠습니다. 그러나 이것이 거의 불가능에 가깝다는 것은 이해하고 있습니다. 따라서 완전히 충분한 정량적 근거는 아니더라도, 다른 근거들을 제시해주시면 저를 비롯해 다른 사용자분들이 공감하는데 더욱 도움이 되겠습니다. 만일 정량적 분석 결과 실제로 동기를 낮추었다는 결과가 나온다 하더라도, 이는 처음에 웬디러비님께서 예리하게 지적하신 것처럼 녹색링크가 빨간링크와 동종으로 인식되지 않았기 때문일 가능성이 있습니다. 따라서 빨간 계열의 표현형을 통해 이를 해결할 수도 있다는 말씀을 드리고 싶습니다.
(2) 문서를 만드는데 발생하는 현실적 어려움을 모두 귀찮음으로 치부하는 것은 부적절하다고 사랑방에서 말씀드린 바 있습니다. 마음만 먹으면 문서를 생성할 수 있다고 하신 부분에 대해서는 20일 11:49에 제가 작성한 (2-2) 하위문단에서 제시한 '그럼에도 틀이 사용될 수 있는 경우'를 참고해주시면 감사하겠습니다.――사도바울||X 2020년 5월 22일 (금) 01:59 (KST)답변

@慈居:님께서 제안하신 효과는 모두 구현했습니다. 사용자:사도바울/기타에서 크로스링크: 임시링크크로스링크: 툴팁과 접근성을 확인해주시면 되겠습니다. 현재 언어이름, 콜론, 링크가 모두 표시되는데, 이를 기존의 {{임시링크}}와 표현을 일치시키는 것에는 이의가 없을 듯 합니다. 따라서 별도의 소도구 효과 후보가 나오거나 토론이 열리기 전까지 임시적으로나마 크로스링크: 임시링크를 기본설정으로 해주시면 감사하겠습니다. 고견 들려주시면 위키백과에 큰 도움이 되겠습니다. 언제나 감사드리고, 좋은 하루 되세요:)――사도바울||X 2020년 5월 30일 (토) 01:02 (KST)답변

@사도바울: 어떤 형태든 도입하면 좋겠습니다.--Kenlee77 (토론) 2020년 6월 10일 (수) 21:19 (KST)답변
@-revi, ChongDae, IRTC1015, Ykhwong:판단 및 의견 부탁드립니다.――사도바울||X 2020년 6월 13일 (토) 01:36 (KST)답변
제게 핑을 주셔서 개인 의견만 전달합니다. 바로 위에 의견을 주신 바, 임시적으로라도 임시 링크를 기본 설정으로 두는 것조차 동의하지 않습니다. 소도구를 바라보는 저의 가치관, 그리고 기존 입장과 크게 달라진 것이 없으므로 더는 드릴 말씀이 없습니다. --ted (토론) 2020년 6월 13일 (토) 01:45 (KST)답변
기존 입장과 크게 달라진 부분이 없다고 하셨는데, 위에서 반대 의견을 남겨주신 것은 전부 녹색 툴팁에 대한 것이었으며 4월 26일에는 디폴트값을 해제하는 전제에서 도입에 찬성하신다고도 말씀하셨습니다. 따라서 지금 소도구 도입에 반대하시는 이유는 위에 남겨주신 글들만으로는 유추하기 어려운데, 제 개인적 이해도의 문제일지라도 넓은 아량으로 설명해주시면 감사하겠습니다.
게다가 총의에서 문제 없다고 하면 수용하신다고도 말씀하셨었는데, 현재 기본설정을 배제한 소도구 도입에 대해 총의가 이루어지지 않았다고 보시는 것으로 파악됩니다. 만일 그렇다면 총의 형성을 위해 어떤 과정이 더 필요할지 위키백과 후배로서 조언을 구합니다.
혹시 오해가 있으실까봐 기우에 드리는 말씀이지만, 임시적으로 임시 링크를 기본 설정으로 두자는 것은, 시간이 지난 뒤에 총의 없이 교체하자는 의미가 아니었습니다. 늦은시간 핑 드려 죄송합니다. 안녕히주무세요:)――사도바울||X 2020년 6월 13일 (토) 02:53 (KST)답변
제 의견에 오해가 있으신 것 같으며 너무 기분 나쁘게는 듣지 않으시길 바랍니다. 저는 현 기준으로 제안해 주신 소도구에 대한 큰 애착이 없으며, 색깔만이 문제가 아닌 동작상의 접근성 문제 또한 구체적인 예시까지 들어가며 지적하였음을 상기하여 주십시오. 디폴트값을 해제하는 것에 동의하는 부분 또한 적극적인 찬성을 의미하지 않음을 분명히 합니다. 제 입장을 정확히 말씀드리면 '가능한 도입하지 않는 것', 즉 '최대한의 소극적 도입'입니다. 신체적 장애를 지닌 사용자를 포함하여 가능한 많은 유형의 사용자가 사용하면 사용할수록 문제가 되는 소도구이기 때문에 더욱 그렇습니다. 이 의견 또한 이전과 같아서 계속 같은 말씀을 드리는 것이 실례일 수 있는데 다시 말씀드리게 되었네요. 조금 생각이 변화된 것이 있는데, 편집 시 임시 링크 관련 틀을 두는 것이 허용된다면 오히려 잠재적인 과도한 틀 사용으로 인해 편집에 부정적인 영향을 미치지 않을까 하는 점입니다만, 이 부분 또한 저의 기존 의견에 큰 변화를 주지 않습니다. 저의 의견을 차치해 두고서라도 지금처럼 이의를 제기했던 분들의 의견을 재차 들음으로써 정말로 총의가 확립되었는지 확인하는 과정이 수반되어야 것입니다. 문제 해결과 관계 없이 도입 자체를 완전히 반대하시는 분들이 계셨던 만큼 그분들을 설득하였다고 보기 힘듭니다. 반대가 다수를 차지하는 현 상황에서는 총의가 모였다고 할 수 없습니다. 총의가 다수결은 아니지만 동의 의견보다 비교적 반대 의견이 상당했던 만큼 너무 조속히 처리하려고 하지 말아주실 것을 권고드립니다. 의견은 수락되지 않을 수 있고 공동체 반대에 의해 도입이 거절될 수도 있음을 이해해 주십시오. --ted (토론) 2020년 6월 13일 (토) 03:15 (KST)답변
기분은 나쁘지 않습니다! 오히려 답답하실수 있으심에도 불구하고 새벽에 시간을 내서 친절한 언어로 설명해주신 것에 감사의 말씀을 드립니다. 접근성을 고려하여 동작상의 접근성 문제도 지적하신 것 당연히 기억하고 있었습니다. ted님과 자거님 덕분에 접근성 문제를 해결하는 방안으로 대화가 길게 이루어졌습니다. 그래서 임시링크를 기본설정화 하자는데 이른 것이고요. 과도한 틀 사용이 편집에 부정적인 영향을 미치지 않을까 하시는 말씀에 대해선 잘 이해가 되지 않는데, 어떤 부정적 영향이 있을지 설명해주시면 감사하겠습니다. 총의에 대해선, 솔직히 저는 revi님과 웬디러비님을 제외하고선 ted님까지 포함하여 모두 '도입 자체는 찬성'하시는 줄 알았습니다. 그런데 말씀하신대로 제가 오해하고 있는 부분이 있을 수도 있으니, 한번 다시 의견을 여쭙도록 하겠습니다. 감사합니다!――사도바울||X 2020년 6월 13일 (토) 11:50 (KST)답변
모호한 스탠스로 비추어질 수 있다고 생각되고 최근의 편집상의 문제를 들어 아예 제 입장을 바꾸겠습니다. 기존 저의 입장은 '최대한 도입하지 않는 것. 끝내 도입을 하더라도 소도구의 기본값 적용을 하지 않는다는 기준까지이며, 이는 어디까지나 총의가 확립될 경우에 한정함."이었습니다. 그러나 지금 저의 입장은 본 소도구의 개선 여부, 기본값 설정 여부에 관계 없이 소도구 도입에 원천 반대하는 것으로 선회하겠습니다. 이렇게 입장이 바뀐 이유는 편집상의 문제로, 한 문서에 임시링크 관련 틀이 덕지덕지 부착될 경우 편집 가독성에 상당한 문제가 있을 것이라 생각합니다. 물론 이전에 사도바울님께서 여러 토론을 통해 그렇지 않다는 말씀을 다른 사용자분들께 해 주셨으나 여전히 저에게는 와닿지 않고요. 솔직히 {{임시링크}}를 사용하는 것 자체도 유용성 부분에서 부정적이라 생각되며 나중에 해당 틀의 삭제 토론으로 회부하는 것까지 고려 중입니다. 또, 외부 이야기는 꺼내들지 않으려고 했으나 아래 문장과 위 문장에서 일부 곡해가 있어 다른 사용자분들이 오해하지 않도록 분명하게 말씀드리고 싶습니다만, -revi님도 명시적으로 외부 채널을 통해 사도바울님께 '(개선 여부에 관계 없이) 소도구 자체의 원천 반대'를 강조하셨습니다. 본 소도구의 편집은 인터페이스 관리자 권한을 가진 사용자만이 편집이 가능하며, 4명의 인터페이스 관리자 중 이미 2명의 인터페이스 관리자가 반대 의견을 낸 상황으로 인지하여 주십시오. --ted (토론) 2020년 6월 13일 (토) 12:21 (KST)답변
어디서 제가 곡해했다고 느끼셨는지 확신은 못하겠지만 나름대로 유추해서 문단 일부 수정했습니다. 4분 중 2분께서 반대의견을 내신 상황은 인지하고 있으나, 설득의 여지가 없다고 보지는 않으므로 아마 당분간은 계속 대화를 시도할 것 같습니다. {{임시링크}}의 편집가독성이 효용을 뛰어넘는다고 보시는 것에 대해서는 나중에 생각을 조금 더 정리해서 의견 남기겠습니다. 아마 틀토론:임시링크에 의견 남길 것 같습니다. 감사합니다.――사도바울||X 2020년 6월 13일 (토) 13:20 (KST)답변
저를 바보로 만드셨군요. 이 기여에 -revi님을 추가하시기 전까지의 저의 답변은 유효합니다. (-revi님을 빼셨다는 점이 곡해했다는 점입니다) --ted (토론) 2020년 6월 13일 (토) 15:47 (KST)답변
바보로 만들 의도는 없었습니다;; 그래서 말씀하신 사안 고려해서 수정했음을 명시한 것이고요. 불쾌하셨다면 죄송합니다.――사도바울||X 2020년 6월 13일 (토) 16:18 (KST)답변

총의가 모아졌는지 확인[편집]

@양념파닭, Kenlee77, Raccoon Dog, 慈居, 웬디러비: 다시 핑 드려 죄송합니다. 툴팁과 색으로 임시링크를 구분하는 것에 대해 접근성에 문제가 있음을 근거로 많은 분들이 우려 말씀을 남겨주셨습니다. 지금 의견을 남겨주신 분들이 과거에 남겨주신 의견을 읽어보았을 때 기본설정을 제외한 단순 도입에는 -revi님과 웬디러비님을 제외하고 다들 찬성하시는 것으로 이해됩니다. 그러나 현재 기술적 한계로 쎄쑌(영어:Session (Presbyterianism))처럼 원 문서의 제목이 그대로 표출됨에 따라 가독성이 낮아지는데, 이를 고려하여 현재 여러 문서에서 검증된 방식인 {{임시링크}}와 표현형을 동일하게 하는 방식을 제안합니다. 따라서 표현형 임시링크를 기본설정으로 두는 것은 아무것도 기본설정으로 두지 않는 것과 비교할때 접근성 문제를 유발하지 않으며, 오히려 과한 가독성 해침을 보완합니다. 이에 대한 의견 다들 들려주시면 감사하겠습니다. 도입 자체에 반대하시더라도, 5월 21일까지 위에서 웬디러비님과 나눈 대화와 사랑방을 참고하시고 새로운 의견을 남겨주시면 감사하겠습니다. 좋은 주말 되세요:)――사도바울||X 2020년 6월 13일 (토) 11:50 (KST)답변

@사도바울: 상술했듯 이 소도구에 대해 어떠한 방식으로든 도입에 찬성하며 특히 지금 제안해주신 임시링크 방식으로의 도입을 희망합니다.--Kenlee77 (토론) 2020년 6월 13일 (토) 15:45 (KST)답변

@사도바울: 토론이 너무 길어서 가독성이 떨어집니다. 토론을 문단으로 나누어 주실 것을 부탁드리겠습니다. 그리고 다른 사용자분께서도 본 소도구의 도입 자체에 대해 관심이 없어 토론에 참여하지 않으신다는 답변과 마찬가지로 저 또한 마찬가지입니다. 저의 의견 중 위에서 "기 말씀드린 이유로 계속 토론으로 도와드리기 어려울 듯 하며 다른 분께서 도와주시는 게 좋겠습니다."라는 말씀을 드렸고 이후에 제게 여러 번 핑을 해주셨으나 한동안 답변을 드리지 않았습니다. 그 이유는 다른 사용자분께서 말씀하신 것처럼 제게 해당 소도구에 대해 도입 가치가 없기 때문입니다. 이번에 다시 핑을 하여 답변을 드리긴 하였으나 이후 핑을 하신다고 하여 소도구의 개선이나 도입에 대한 의견은 가능한 드리지 않을 것입니다. 내용을 정리하시고 총의가 나오신 이후에는 다른 인터페이스 관리자분께 의견을 요청하시기 바랍니다. --ted (토론) 2020년 6월 13일 (토) 16:00 (KST)답변

넵 알겠습니다. 말씀하신대로 문단 나누었는데, 혹시 더 나눌 필요가 있다고 생각하시면 임의로 나누어주셔도 되겠습니다. 감사합니다.――사도바울||X 2020년 6월 13일 (토) 16:18 (KST)답변
네, 고맙습니다. 토론 회피가 아니니 오해가 없으시길 바라며, 좋은 결과가 있기를 바랍니다. 이 소도구는 반대 입장이지만 이 소도구의 다른 대안은 저 나름대로 고민하고 말씀드리겠습니다. --ted (토론) 2020년 6월 13일 (토) 16:28 (KST)답변