페미위키:개선요청

페미위키 디자인, 사용성, 기능 관련 아이디어 및 개선 제안을 적는 곳입니다.

버그는 제보 전 보고된 버그를 검색해 주세요.

📁 페미위키 소개

페미위키 소개

FPOV

• 운영
  • 운영진 · 운영일지
  • 보고서
• 재정
  • 굿즈
  • 해외 후원
  • 후원해주신 분들
• 통계
  • 미디어위키 통계
  • 활동적인 사용자
  • 인기있는 문서
  • 공개된 구글 애널리틱스 데이터
  • 기록
    • WikiApiary
    • 구글 애널리틱스
• 기타
  • 이용약관
  • 면책 조항
  • 개발 블로그
• 외부 채널
  • femiwikidotcom
  • femiwikidotcome
  • femiwikidotcom
  • femiwiki

분류:

• 문서 주제/페미위키 개발

영어 등 알파벳 사용언어 책이나 문서를 보면 문단의 오른쪽 공간 관리를 위해 하이픈(-)을 사용하는 걸 볼 수 있는데요, 몇가지 패턴을 정리해 볼수 있겠습니다:

1. 무조건 단어가 한 덩어리로 붙어있게 하기
2. 줄이 바뀌는 지점에서 단어를 자르기
3. 줄이 바뀌는 지점에서 단어를 자르고 하이픈 추가
4. 줄이 바뀌는 지점에서 단어를 음절 단위로 자르고 하이픈 추가

보통 별다른 신경을 안 쓰면 1번이 기본 설정으로 작동하는데, 가로로 좁은 공간에서 긴 단어가 걸리면 오른쪽 여백이 엄청 크게 나올때가 있어 미관상 안 좋습니다.

그래서 영어 등 언어에서는 보통 4번을 사용합니다.

한국어는 언어 특성상 한 글자 공간에 한 음절이 들어가기 때문에 단어가 어디에서 잘려나가도 읽는데 문제가 없어 2번을 사용합니다.

한국어 위키백과는 2번을 적용중입니다.

영어 위키백과는 1번을 적용중입니다. 아마 가로공간을 최대로 확보했기 때문에 딱히 단어를 자를 필요를 못 느낀 것 같습니다.

근데 페미위키는 한국어 문서는 1번 적용, 영어 문서(문서가 아니라 단어인가? 이점은 확인 못했습니다) 는 3번이 적용되어있습니다. 웹사이트측에서는 3번/4번 구분을 하나의 옵션으로 지정하고 4번 적용을 브라우저가 알아서 하도록 한 것으로 보이는데, 음절 구분을 전혀 못하고 있습니다. 음절을 잘 자르는 경우도 있지만 대충 둘러보니 includ-ing, provid-ing, consec-utive 등 실패하는 경우도 많습니다. (어도비 제품군도 이런 문제가 있던데 도대체 왜 이걸 해결못하는건지..?)

영어 단어를 음절을 무시하고 자르면 보기 안 좋기 때문에 1번으로 바꾸었으면 좋겠습니다.

아마 CSS 를 통해 하이픈 규칙이 적용되어있을 것 같은데 문단에 해당하는 클래스에 (설마 P 는 아닐테고..) 아래를 추가하면 됩니다.

hyphens: none !important;

그리고 한국어 문서는 1번 보다는 2번이 좀 더 문단 오른쪽이 정돈되어보일텐데요? 언어별로 CSS 를 따로 도입할수 있는지 모르겠지만 한국어는 hyphens:auto, 영어는 hyphens:none 으로 하면 좋겠습니다. 언어별로 선별 적용이 안 될 경우, 둘 다 hyphens:none (상기 패턴 중 1번) 로 통일하구요

아 CSS 파트가 좀 더 복잡하군요.. hyphens 속성 외에 word-break, overflow-wrap 속성도 있습니다. 대략 보니까

1. 무조건 단어가 한 덩어리로 붙어있게 하기: 기본 설정
2. 줄이 바뀌는 지점에서 단어를 자르기: word-break: break-all; hyphens: none;
3. 줄이 바뀌는 지점에서 단어를 자르고 하이픈 추가: word-break: break-all; hyphen: auto;
4. 줄이 바뀌는 지점에서 단어를 음절 단위로 자르고 하이픈 추가: 원래대로라면 3번과 마찬가지로 word-break: break-all; hyphes: auto; 를 세팅하면 브라우저가 언어를 인식해서 사전 기반으로 해줘야 하는데 사전 기능이 약한듯

그래서 종합해보면 아래와 같이 했으면 좋겠습니다:

word-break: normal; hyphens: none;

이렇게 하면 영어는 1번, 한국어는 2번으로 표시될 것 같네요

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개가 있는데, 이미지가 모두 로딩 될 때 까지는 페이지 내용을 전혀 보여주지 않아서 더 느리게 느껴집니다. 페이지 글은 일단 보여주는 상태에서 이미지를 하나씩 로딩하면 이런 느낌은 없을텐데, 왜 기능이 이렇게 구현되어있는지 모르겠네요. 아, 물론 한번 로딩을 하면 다음번에는 페이지가 금방 로딩됩니다. 그리고 시간이 좀 지나서 (일주일 정도?) 사용자의 브라우저 캐시가 지워지면 다시 한번 느려집니다.

모종의 이유로 서버에서 응답을 늦게 하는 경우가 있는 듯합니다. 제 경우는 이미지가 문제가 아니라 아예 첫 응답 자체가 수 초단위로 걸립니다. 일단 첫 응답이 오면 나머지는 빠르게 로딩되고, 이 상태에서 캐시를 비활성화하고 새로고침해도 빠르게 로딩되는 걸 보아 서버 쪽에서 뭔가 문제가 있지 않나 싶어요.

이 문제가

1. 저만 겪고 있는 문제인지,
2. 아래의 솔루션으로 해결될 성격의 문제인지는 모르겠지만,

오늘 우연히 lazy loading 이라는 기법(이미지들을 사전에 로딩하는게 아니라 사용자가 스크롤을 내림에 따라 거기에 대응해서 로딩) 에 대해 알게 되어 관련 정보 링크 남깁니다.

https://www.mediawiki.org/wiki/Reading/Web/Projects/Performance/Lazy_loading_images

https://www.mediawiki.org/wiki/Extension:Lazyload

같은 현상이 아직 그대로 유지되고 있습니다. 낙엽님이 깃헙 티켓에도 요약해둔 현상은 다음과 같습니다:

1. InstantCommons 라는 미디어위키 기능을 활용해 문서에 Wikimedia Commons의 사진을 사용한 경우, 사진의 수에 비례해 시간이 오래 걸리며, 사진이 15개 이상일 경우 거의 3분 정도 걸림
2. (마치 서버에서 캐시가 되는 것처럼) 누구든지 일단 시용자가 해당 문서를 한 번 연 이후에는 모든 사람에게 빠르게 열립니다
3. 사용자가 아무도 문서를 열어보지 않은채로 며칠이 지난 후에는 다시 (캐시가 지워진 것 처럼) 문서를 열때 동일한 시간이 걸립니다. 랜덤성으로 한참 버벅거리다가 화면에 "504 Gateway Time-out" 라는 메세지가 뜨기도 합니다. (그냥 흰 화면에 이 메세지만 뜸)

사용자가 누구든지 한번만 열면 나머지 사용자들은 버벅거리는 현상을 관찰 할 수가 없어서. 테스트하기 참 어려운 현상입니다. 새 문서를 만들고 거기에 지금까지 페미위키에서 사용되지 않은 이미지들을 잔뜩 넣으면 저장하는 순간 문서 보기 모드로 전환하기 까지 시간이 많이 걸리기는 할 것 같네요.. (편집 과정에서 이미 로딩되서 아니려나?)

이 현상이 관찰 될 정도로 InstantCommons 이미지가 많이 사용된 예시 페이지들은 아래와 같습니다:

• 미국 2020년 대통령 선거 하위권 후보
• 민족학교 2017년 기금 행사
• 민족학교 2018년 기금 행사
• KRC's 2018 Fundraiser Event

미디어위키 사이트의 InstantCommons 설명을 보면 Scalability 항목에 이런 내용이 있습니다

• "every file only has to be downloaded once, and there are per-user bandwidth limitations"
• "... there could be a limit on the size of files which should be downloaded transparently. This would primarily be because files above a certain size would delay pageviews significantly and might even cause the page request to time out."

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을 직접 사용하고 있어 페미위키에서 이미지 캐싱을 해야 할 이유가 없는데 원인을 모르겠네요.

Memcached를 캐싱을 위해 쓰고 있는데 그 시간이 걸리는 것이 아닐까도 싶습니다 그러나 이 추측이 맞는지 아닌지와 해결법은 잘 모르겠습니다 :-(

느려야만 할 이유는 없는것으로 생각되고, 미디어위키 구현체 버그같습니다. 시간되면 디버깅 해보겠습니다.

https://phabricator.wikimedia.org/T190576 이 버그인듯 하네요. 해결책을 찾아보겠습니다.

위키미디어 사진이 많이 들어간 문서들의 로딩이 많이 빨라진 듯 하네요!

제가 확인하기로는 요즘도 똑같이 느린 거 같습니다😢 설명 업데이트된 걸 보니까 이미지 자체는 핫링크라 캐시고 뭐고 할 게 없는데, 예를 들어 파일:Example.png을 추가하면, 저 링크를 눌렀을 때 나오는 파일 설명 페이지를 받아서 만드는 데 시간이 걸리는 것 같습니다