Not editable
페미위키 디자인, 사용성, 기능 관련 아이디어 및 개선 제안을 적는 곳입니다.
📁 페미위키 소개
|
Content is available under 크리에이티브 커먼즈 저작자표시-동일조건변경허락 4.0 국제 라이선스 unless otherwise noted.
https://github.com/femiwiki/mediawiki/issues/286
번역 도우미에게 문서 언어 바꾸기 권한이 추가되고 미디어위키:Common.css가 수정됨
현재 틀:lang 틀을 통해 개별 단어에 언어에 최적화된 폰트를 선택 할 수 있는데요,
페미위키 현재 폰트:
구글닥스 폰트: (헤더에 적용된 Oswald 라는 커스텀 폰트는 무시해주세요)
참고로 이전에 공유된 현재 사용중인 폰트 명단입니다
Apple SD Gothic Neo Noto Sans KR 본고딕 Noto Sans CJK KR KoPubDotum Medium 나눔바른고딕 나눔고딕 NanumGothic 맑은고딕 Malgun Gothic Arial Dotum sans-serif
문서에 명시적으로 지정하고 싶은 경우에는 templatestyles을 사용할 수 있을 것 같고, 개인 설정은 사용자문서/common.css에서 설정할 수 있는데, 일괄 적용은 위에 적은 것처럼 확장기능이 아니면 어렵지 않나 합니다
개인설정의 경우 페이지 아래 오른쪽 기어 버튼을 클릭해서도 언어별 폰트를 선택할 수 있는데 이 경우는 아마 미디어위키에서 등록한 웹폰트만 가능하고, 등록하려면 라이센스 문제가 없어야 했던 것 같습니다. 이 경우의 요청 조건과 절차는 다음 문서를 참고해 주세요: https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts
templatestyle 을 적용해서 이렇게 시도해보았는데, 이게 통할까요?
틀:다른 언어 에서 "한국어 문서로 가는 링크"가 있으면 영어 문서로 간주하고 en.css 를 불러들임. En.css 에는 BODY {font-family:Arial;} 를 넣었습니다. (스타일 시트 구조 뭔지 잘 모르겠어서 ㅎ)
위 틀:다른 언어 편집은 현재 영향이 없는 것 같고 https://www.mediawiki.org/wiki/Manual:Language#Page_content_language의 안내에 따라 다른 방식으로 적용할 수 있을 것 같아 그렇게 진행하면 합니다 :)
LocalSettings.php를 고쳐야 할 것 같습니다, pagelang 권한을 번역 도우미 그룹에 부여하여 작업 이후에는 해당 권한으로 접근 가능하게 할 예정입니다.
그런데 그 페이지를 좀 더 자세히 읽어보았을 때 적용시 언어별로 다른 폰트를 지정 할 수 있는지에 대한 언급은 안 보입니다. 사이트 네비게이션이 문서 언어에 맞게 바뀐다고는 하는 것 같습니다
현재도 미디어위키:Common.css에 lang="en"을 조건으로 걸 수 있습니다, 다만 문제는 페미위키:대문/en과 같은 문서는 언어가 "en - English"로 나오는 데 반해/index.php?title=Femiwiki&action=info Femiwiki와 같은 문서는 "ko - 한국어"로 표시되어/index.php?title=Femiwiki&action=info 문서 사이를 이동하다 보면 통일성이 떨어지는 문제가 있습니다.
그러나 전자만 할거면 지금 고쳐도 되겠네요... 한국어일때 폰트 명단과 똑같이 해서 Arial만 제일 앞에 추가하면 될까요?
Arial 을 맨 앞에 지정하면 Arial 은 한국어 표기가 불가능하니까 영어만 Arial 이 되고 한국어는 현재 폰트 그대로 유지되나요? 아이고 간단한 해결책이 있었네요.. 그렇게 하죠
특:차이/146714으로 적용하여 브라우저 캐시를 지우시면, 페미위키:대문/en 등에서 확인 가능합니다. 이 주제는 LocalSettings.php 수정 후에 제가 해결된 것으로 표시할테니 유지해주세요 감사합니다
아.. 플러그인으로 번역 처리를 한 페이지에만 적용이 되군요.. 이걸 영어 문서에만 적용하는게 아니라 모든 문서에 적용되도록 일반 CSS 를 변형하면 어떨까요? 영어 페이지(페미위키:대문/en)를 보니 거기에 남아있는 일부 한국어 단어들이 한국어 페이지 (페미위키:대문)의 한국어 폰트와 동일하게 나옵니다. 그러니까 일반 CSS에 적용해도 브라우저가 알아서 한국어는 맑은고딕, 영어는 Arial 을 적용하지 않을까 싶습니다.
일단 디자인이 제 전공이 아니어서... Arial을 적용하면 한글 사이에 있는 스페이스바 폭이 바뀌는데 이게 가독성에 어떤 영향이 있는지 모르겠고, 현재 "Apple SD Gothic Neo Noto Sans KR 본고딕 Noto Sans CJK KR ..." 하며 길게 늘어선 명단이 어떤 의도로 된 것인지 몰라 제가 바꾸기에 제한됩니다. 혹 Arial을 우선시킬 수 있을 근거 자료 등이 있다면 첨부해 주시면 감사하겠습니다!
추가) 문서 언어 변경 기능 활성화는 다른 패치들과 묶어서 다음번 토요일에 적용할 생각입니다, 그 전까지는 잠시 기다려주세요.
아, 이걸 패치하면 그때부터는 플러그인으로 번역한 문서가 아니라 아무 문서나 임의로 "영어" "일본어", "한국어" 등으로 지정 할 수 있게 되는군요? 알겠습니다.
다음 방법을 사용해주세요:
특수:문서언어에서는 가능한데, 문서에서는 어떻게 하는지 모르겠습니다. 문서 설정 란에 언어라는 탭이 있는데 거기에는 클릭 할 수 있는 요소가 없어요
https://github.com/femiwiki/mediawiki/issues/284
페미위키에 InstantCommons 라는 미디어위키 기능을 활용해 Wikimedia Commons 의 사진을 사용한 경우, 사진의 수에 비례해 시간이 오래 걸리며, 사진이 15개 이상일 경우 거의 3분 정도 걸려 기술적인 해결을 제시했지만 요즘 미디어위키 버전에는 이미지 캐싱이 아예 존재하지 않는 것으로 보이며, 그리고 시간이 지난 오늘에는 시간 걸리던 것이 없어지거나 상당히 해소된 것으로 보입니다.
유독 제가 만든 문서들만 로딩 시간이 엄청나게 느립니다. 문서가 너무 길어서 그런 줄 알고 주제별로 쪼개보았는데, 그래도 느리더라구요. 그리고 어제 뭐가 문제인지 드디어 알게 되었습니다. 저는 문서에 InstantCommons 기능을 이용해서 페미위키에 사진을 올리지 않고 위키백과에서 사진 공용으로 만든 Wikimedia Commons 의 사진을 그대로 불러오는데 (사진 올리고 설명 붙이는 작업 너무 너무 귀찮네요), 이럴 경우 사진이 문서 로딩 때 마다 다시 불러오게 되고 있었던 것 같습니다.
기본 값은 아래와 같은 것 같습니다 ($wgUseInstantCommons, $wgForeignFileRepos)
$wgForeignFileRepos[] = [
'descriptionCacheExpiry' => 0,
'apiThumbCacheExpiry' => 0,
];
상기 두가지 변수 값을 8640000 (100일에 해당하는 수의 초 수입니다) 으로 바꾸어 주실 것을 제안합니다. 그런데 LocalSettings.php 파일을 수정해야 하는데 가능하실런지 모르겠습니다..
LocalSettings.php 파일 수정 가능합니다, 가능한데, 적어주신 링크들의 내용이 많아서 우선 다 읽고 대강이라도 이해해보고 그 다음에 수정하고 싶은데 제 체력에 따라 시간이 좀 걸릴 수도 있습니다. TwT
제가 10년 전 써본 기억으로는 LocaSettings.php 에 어딘가에 (맨 밑에?) 저 4줄만 넣어주면 되는 것으로 알고 있습니다.
$wgForeignFileRepos[] = [ 'descriptionCacheExpiry' => 8640000, 'apiThumbCacheExpiry' => 8640000, ];
모든게 그렇듯이 안 급하니 편하신대로 하시면 됩니다.
로컬 테스트를 해봤는데 써주신 네 줄 코드를 추가했을 경우에 다름 에러가 나고
Notice: Undefined index: class in /var/www/femiwiki.com/includes/Setup.php on line 255 Notice: Undefined index: name in /var/www/femiwiki.com/includes/Setup.php on line 259 Notice: Undefined index: name in /var/www/femiwiki.com/includes/filebackend/FileBackendGroup.php on line 77 Notice: Undefined index: directory in /var/www/femiwiki.com/includes/filebackend/FileBackendGroup.php on line 79 Notice: Undefined index: class in /var/www/femiwiki.com/includes/filerepo/RepoGroup.php on line 416
모르겠어서 Setup.php의 255 및 259 줄을 찾아봤는데 다음과 같습니다,
if ( !isset( $repo['directory'] ) && $repo['class'] === 'ForeignAPIRepo' )
$repo['backend'] = $repo['name'] . '-backend';
하여튼 그래서 대신
$wgForeignFileRepos[] = [
'class' => 'ForeignAPIRepo',
'name' => 'wikimediacommons',
'apibase' => 'https://commons.wikimedia.org/w/api.php',
'url' => 'https://upload.wikimedia.org/wikipedia/commons',
'thumbUrl' => 'https://upload.wikimedia.org/wikipedia/commons/thumb',
'hashLevels' => 2,
'transformVia404' => true,
'fetchDescription' => true,
'descriptionCacheExpiry' => 43200,
'apiThumbCacheExpiry' => 86400,
];
을 적었는데 그러면 다음과 같은 에러가 납니다.
Exception encountered, of type "FileBackendException" [c1cec22c515fa99a337f5e37] /index.php?title=%ED%8A%B8%EB%9F%BC%ED%94%84&action=submit FileBackendException from line 126 of /var/www/femiwiki.com/includes/filebackend/FileBackendGroup.php: Backend with name `wikimediacommons-backend` already registered.
Setup.php을 더 살펴봤을 때, $wgUseInstantCommons을 true로 설정할 경우 Commons를 자동으로 ForeignFileRepo으로 추가하고, 이 때 캐싱 기간은 12시간/24시간으로 정해져있지만, 이를 수정하는 옵션은 없는 것 같고(아마?) 위 에러는 같은 이름의 ForeignFileRepo를 둘 추가했기 때문에 난 것으로 그러면 대신 $wgUseInstantCommons를 false로 설정한 다음 수동으로 Commons를 추가하면 조금 억지로지만 조정은 할 수 있는 것 같습니다. 이 경우 추가해야 하는 코드는 다음과 같습니다.
$wgUseInstantCommons = false;
$wgForeignFileRepos[] = [
'class' => 'ForeignAPIRepo',
'name' => 'wikimediacommons',
'apibase' => 'https://commons.wikimedia.org/w/api.php',
'url' => 'https://upload.wikimedia.org/wikipedia/commons',
'thumbUrl' => 'https://upload.wikimedia.org/wikipedia/commons/thumb',
'hashLevels' => 2,
'transformVia404' => true,
'fetchDescription' => true,
'descriptionCacheExpiry' => 8640000,
'apiThumbCacheExpiry' => 8640000,
];
그러나 뭔가 억지스러워서 하기도 조심스럽고… 12시간/24시간으로 이미 캐싱이 되고 있는 것으로 생각되어 이것을 100일로 늘리는 것이 옳은 일인가를 제가 판단할 수가 없어 보류하려고 합니다.
더 잘 아시는 분이 있다면 살펴봐 주시면 감사하겠습니다ㅠㅠ
정확히 어느 항목의 로딩 시간이 긴 건가요? 기여 목록을 보고 제2차 세계 대전 등의 항목에 접속해 봤는데 제 쪽에서는 페이지가 충분히 빠르게 뜹니다.
문서내에 사용된 커먼즈 사진의 수에 따라 급수적으로 늘어나는 것 같습니다. 지금까지 제일 많이 사용한 문서는 2018년 북미정상회담 입니다. (15초 이상 걸리는 듯) 처음 로딩 후 둘째 로딩은 금방 되는 것을 보니 캐싱이 작동은 하는 듯 합니다. 원래는 도널드 트럼프 문서도 사진이 엄청 많아서 로딩이 오래 걸렸는데, 그 문서를 4개 문서로 쪼갰습니다.
이상한게 제가 이 개선 요청 글을 올렸을 때는 캐싱 시간이 0 이었던 듯한 느낌이어서 북미정상회담 문거 같은 경우 한번 로딩 할 때 15초, 그리고 몇분 있다가 로딩할때도 또 그정도의 시간이 걸리고, 전혀 캐싱의 효과를 못 봤던 것 같은데, 이제는 또 되는 느낌이네요?
아 그리고, 이 캐싱이라는게 개별 사용자에 한한 캐싱이 아니라 페미위키 서버 차원의 캐싱이라, 사용자 1이 문서를 한번 열면 다른 사용자들은 그 문서를 빠르게 열어볼 수 있습니다. 12시간이 지나면 캐싱이 지워지고 다시 다음회에 한해 느려집니다.
그래도 캐싱을 100일로 늘렸으면 하는데, 정확한 설정 파일 문법에 대해 확인해보고 다시 댓글 올리겠습니다..
좀더 살펴본 결과 캐싱이 큰 관련이 없을 거라고 생각됩니다. 해당 도널드 트럼프 문서에서 개발자 도구를 통해 이미지 소스 URL을 보면 페미위키가 아니라 위키미디어 커먼즈에서 직접 사진을 받아 쓰고 있습니다. https://www.mediawiki.org/wiki/Manual:$wgUseInstantCommons 문서에서도 미디어위키 1.27부터는 개별 서버에서 원본 이미지를 따로 받는게 아니라 문서에 위키미디어 커먼즈 링크를 직접 사용 (핫링크) 한다고 하며, 현재 페미위키의 미디어위키 버전은 1.27.1로 확인됩니다.
2018년 북미정상회담 페이지의 로딩이 여전히 매우 느립니다. 이 페이지에는 커먼즈 이미지 11개, 페미위키 이미지 2개가 있는데, 이미지가 모두 로딩 될 때 까지는 페이지 내용을 전혀 보여주지 않아서 더 느리게 느껴집니다. 페이지 글은 일단 보여주는 상태에서 이미지를 하나씩 로딩하면 이런 느낌은 없을텐데, 왜 기능이 이렇게 구현되어있는지 모르겠네요. 아, 물론 한번 로딩을 하면 다음번에는 페이지가 금방 로딩됩니다. 그리고 시간이 좀 지나서 (일주일 정도?) 사용자의 브라우저 캐시가 지워지면 다시 한번 느려집니다.
모종의 이유로 서버에서 응답을 늦게 하는 경우가 있는 듯합니다. 제 경우는 이미지가 문제가 아니라 아예 첫 응답 자체가 수 초단위로 걸립니다. 일단 첫 응답이 오면 나머지는 빠르게 로딩되고, 이 상태에서 캐시를 비활성화하고 새로고침해도 빠르게 로딩되는 걸 보아 서버 쪽에서 뭔가 문제가 있지 않나 싶어요.
이 문제가
오늘 우연히 lazy loading 이라는 기법(이미지들을 사전에 로딩하는게 아니라 사용자가 스크롤을 내림에 따라 거기에 대응해서 로딩) 에 대해 알게 되어 관련 정보 링크 남깁니다.
https://www.mediawiki.org/wiki/Reading/Web/Projects/Performance/Lazy_loading_images
같은 현상이 아직 그대로 유지되고 있습니다. 낙엽님이 깃헙 티켓에도 요약해둔 현상은 다음과 같습니다:
사용자가 누구든지 한번만 열면 나머지 사용자들은 버벅거리는 현상을 관찰 할 수가 없어서. 테스트하기 참 어려운 현상입니다. 새 문서를 만들고 거기에 지금까지 페미위키에서 사용되지 않은 이미지들을 잔뜩 넣으면 저장하는 순간 문서 보기 모드로 전환하기 까지 시간이 많이 걸리기는 할 것 같네요.. (편집 과정에서 이미 로딩되서 아니려나?)
이 현상이 관찰 될 정도로 InstantCommons 이미지가 많이 사용된 예시 페이지들은 아래와 같습니다:
미디어위키 사이트의 InstantCommons 설명을 보면 Scalability 항목에 이런 내용이 있습니다
InstantCommons 의 과거 버전에는 캐싱 기능이 있었던 것으로 보이는데, 그게 현재는 없어진 것으로 생각되지만 (페미위키 상에서 이런 이미지의 속성을 보면 모든 내용이 Wikimedia Commons 의 핫링크로 나타납니다), 캐싱 기능을 언급하는 듯한 상기 문구가 아직도 미디어위키에서 삭제되지 않은 걸 보면 혹시 캐싱 기능이 없어지지 않았는데 우리가 잘못 파악한 것인가? 라는 생각도 듭니다.
저도 2006-2014년 사이에 InstantCommons 를 켜놓고 이따금 사용하던 미디어위키 위키를 운영했는데 그때 이미지 속성이 어떻게 표시되던지 기억이 안 납니다. 당시에는 링크가 로컬 캐시로 나오고, 이제는 위키미디어로 나온다면 그게 캐시가 없어졌다는 나름의 증거일텐데 말이죠.. 그나저나 이 페이지 하나가 InstantCommons 에 대한 문서화의 전부라니 뭔가 매우 부족한 느낌이 듭니다.
지금 이 스레드를 살펴보니 사샤나즈님이 링크해준 매뉴얼 문서에 캐싱이 언급되어있네요. 1.26 버전까지는 캐싱이 있었지만 현재는 없다라는데.. 근데 저거 설명해둔 사람들이 왜 "Enabling this configuration parameter does not avoid any usage of disk space on the server running the local wiki." 이 문구는 삭제하지 않았는지 모르겠네요.
캐싱이 문제가 아니라 상기 Scalability 항목에 이미지를 너무 한꺼번에 불러들이거나 대역폭을 (사용자/IP당 하루에 1GB?) 초과하면 그걸 보호해야 한다는 이야기가 있고 그게 도입되었는지, 제한이 얼마인지는 나와있지 않은데 그거일 가능성도 있을 것 같네요. (하지만 그러면 한 사람이 로딩 한 후 다른 사람들에게는 빠르게 나오는 현상이 설명되지 않을 것 같은데..)
이따금 해당 문서들의 서버측 응답이 너무나 느린 나머지 60초가 지나 HTTP 504 오류가 뜨기도 합니다. 분명히 이미지는 위키미디어 URL을 직접 사용하고 있어 페미위키에서 이미지 캐싱을 해야 할 이유가 없는데 원인을 모르겠네요.
