위키백과 대화:WikiProject Spoken Wikipedia/Archive 1위키프로젝트 구어 위키백과/아카이브 1

이것은 과거 토론의 기록이다. 이 페이지의 내용을 편집하지 마십시오. 새로운 토론을 시작하거나 오래된 토론을 다시 시작하려면 현재 토크 페이지에서 다시 시작하십시오.

이름

우리는 일관된 명명 규칙을 가져야 한다. .ogg 파일 이름에 기사의 정확한 이름을 사용하지 않을 이유가 있는가? Fuzheado Talk 23:41, 2005년 4월 13일 (UTC)

나는 OGG 파일의 이름을 짓는데 기사 이름을 사용해야 한다는 것에 동의한다. 파일 이름을 바꾸는 "이동" 기능이 있다면 더 쉬울 것이다. :-) — Timwi 14:59, 2005년 4월 14일 (UTC)

• 파일 이름은 표준화된 기사 제목과 같도록 권고해야 할까? 데미^T/_C07:25, 2005년 4월 14일 (UTC)
  • 응, 그래야 할 것 같아. :-) 기존 녹음 파일의 이름을 바꾸면 반대하시는 분? — Timwi 10:45, 2005년 4월 14일 (UTC)

파일 이름은 변경하지 않았지만 "프로덕션 노트" 섹션 Demi _C/ 2005년 4월 14일(UTC) 17:16에 이 권장 사항을 추가했다.

여러분들은 2005년 4월 14일(UTC) 4월 21일 01:01(UTC)에 "당신의 모든 기지는 우리 것이다" => "에이바부.오그"보다 더 나은 이름을 지어 주시겠습니까?

• 네 코멘트를 여기로 옮겼어. 이미 논의되고 있던 곳에서 말이야. 괜찮기를 바래! 보시다시피, 우리는 이미 그 권고안을 가이드라인에 넣었었습니다. 파일 이름을 바꿀 수 있는 방법이 있다면 그렇게 했을 텐데, 내가 보기엔 녹음기가 다시 업로드하는 게 훨씬 더 나을 것 같아서 말이야. 라이센스는 파일과 더 잘 어울리고 그들은 이전 파일을 빨리 지울 수 있게 해달라고 요청할 수 있어. 데미 _C/ 2005년 4월 14일(UTC) 21:32

업데이트

이것은 훌륭한 프로젝트고, 나는 매우 좋아하지만, 내 질문은, 기사가 바뀌거나 확대되었을 때 어떻게 되는가? 새로운 사운드 녹음이 만들어질까?—Erinaceus eurous) 2005년 4월 14일 15:50 (UTC)

• 난 그렇게 생각하겠지, 어느 정도는. 녹음 중인 버전의 안정성에 대해서는 좋은 판단을 내려야 할 것이다. 편집 전쟁 중에 버전을 선택하는 것은 좋지 않은 생각이다. 다시 쓰거나 크게 확장될 가능성이 적기 때문에 먼저 특집기사를 시작하는 것도 좋은 이유라고 생각한다. 데미 _C/ 2005년 4월 14일 (UTC)

• 심피가 (실질적으로) 갱신/추가된 단락을 다시 기록해서 필요한 곳에 삽입하는 것은 어떨까? 서로 다른 목소리 사이를 넘기는 소리가 작은 부분에서는 이상하게 들릴 수 있지만 전체 단락에서는 괜찮게 들릴 수 있다...? --프랭키 로베르토 15:06, 2005년 4월 29일(UTC)

파일 형식

• ogg뿐만 아니라 FLAC와 같은 무손실 포맷을 저장하는데 가치가 있는가? 그래서 앞으로 더 쉽게 재처리될 수 있도록?
  • 아니, 그 때쯤이면 어쨌든 그 기사는 다시 기록될 필요가 있을 것이다. 2005년 4월 13일, 20:35 (UTC)

• 우리는 새로운 비트레이트를 좋아하는가? 48kbps는 내게는 약간 "기분"하게 들렸지만, 아마도 내 귀나 헤드폰일 것이다. 데미^T/_C 2005년 4월 14일(UTC)
  • 사실 당신의 인코더가 "고품질"으로 설정되지 않았을 가능성이 높다. 48kbps는 시험 목적의 표준 음성 비트 전송률이다. 그것 이상의 것은 무의미한 공간 낭비일 뿐이다. 나는 전문 오디오 엔지니어인데, 당신이 장기 음성 녹음 프로그램인 48kbps, 44.1khz 모노에 대한 계획을 세우는 것이 최선이라면 장담할 수 있다. ALKIVAR™ 18:11, 2005년 4월 14일(UTC)
    • 내가 이해한 바와 같이, vorbis 인코딩의 경우, 인코딩할 때 의미 있게 "품질" 또는 공칭 비트레이트(평균)를 설정할 수 있지만 둘 다 설정할 수는 없다. 그 파일들이 당신에게 제대로 들리는가? 데미^T/_C 2005년 4월 14일(UTC)
      • 그들은 좀 조잡하게 들리지만, 나는 그것의 대부분이 빈약한 마이크 때문이라고 생각한다. 묽은 소리는 매우 경미하고 대부분 가변 비트레이트 IMO 때문이다. 나는 항상 고정 비트 레이트를 선호한다. ALKIVAR™ 15:17, 2005년 4월 15일(UTC)
    • 일부 인코딩 파라미터(및 다른 코덱도)로 실험하고 있다. 나는 44100 Hz 샘플링 속도가 너무 높을 수 있다고 생각한다. 오그는 더 낮은 샘플링 속도로 더 낮은 비트 전송률에서 더 나은 작업을 할 수 있을 것이다. 16000이나 32000 Hz를 시도해서 결과가 어떤지 볼 수도 있다. 그러나 거의 모든 플레이어가 CD 리핑을 염두에 두고 코딩될 것이기 때문에(예를 들어 96000Hz 샘플링 속도를 가진 Buzkashi.ogg가 나와 Raul654에 문제를 일으켰다는 것을 알아차렸다) "비 CDDA" 샘플링 속도는 일부 플레이어를 떨어뜨릴 수 있다고 생각한다. 데미 _C/ 2005년 4월 16일(UTC) 22:14

나는 녹음과 듣기 테스트를 좀 했다. 내가 시도했던 것 중 하나는 낮은 샘플링 속도였다: 누군가가 나에게 이것은 음성 녹음에 "적절하다"고 말했기 때문에, 44100 Hz 대신 16,000 Hz이다. 그렇긴 하지만 "밝음"이 부족했다. 나는 분명히 차이를 알 수 있었다. 다양한 인코딩 품질도 실험해봤더니 '품질 8'(약 128kb/s)과 '품질 3'(약 48kb/s-현재 우리의 추천)의 차이를 들을 수 있었다. "저품질" 인코딩은 가청 압축 아티팩트를 낳았다. 하지만 "품질 5"(약 64kb/s)가 더 좋았기 때문에 결론은 44100Hz 모노로 녹음을 계속한다는 것이지만 평균 비트 전송률을 64kb/s("품질 5")로 끌어올리겠다는 것이다. Ogg Export 선호도에 따라 오디오시티에 입력할 수 있을 것 같아 품질 번호를 알려드리는 겁니다. 데미 _C/ 2005년 4월 17일(UTC) 07:05

• 흥미롭게도, 나는 오디오시티를 사용해 본 적이 없어서 어떻게 설정했는지 모르겠어. 내가 사용하는 소프트웨어에서 특정 비트 전송률을 설정할 수 있으며, 그렇게 하면 절약할 수 있다. 이 애매모호함을 못 박아낼 수 있도록 대담성을 싣고 비교 가능한 것이 무엇인지 살펴봐야 할 것 같다. ALKIVAR™ 10:36, 2005년 4월 19일(UTC)
  • 대박(아래에도 인코딩에 대한 몇 가지 추가 논의가 있다). 당신이 하는 동안, 나는 프로젝트 페이지의 오디오 수준 조언, 특히 압축에 대한 조언을 이해하려고 노력하고 있다. 오디오에 "복합" 필터를 적용하여 볼륨을 압축 및 확장하고 수평을 맞출 수 있다. 그것이 입력으로서 원하는 것은 "공격"과 "지연" (볼륨을 증가시키고 감소시키기 위해, 초 단위 - "입력 신호의 절대값이 그것의 볼륨을 결정하기 위해 통합되는 시간"이다. 시험 삼아 나는 이것을 -0.3,1.0으로 규정했다. It also wants a curve of decibel points telling it what levels to boost: for example, I've used -30,-15,-20,-12,-4,-8,-2,-7 (which boosts -30 to -15, -20 to -12, and decreases -4 to -8 and -2 to -7); here I'm just taking a guess at what curve will converge at -12 dB. 어쨌든, 이것의 더 나은 사용에 대한 우리의 단서들을 제공해 줄 수 있는 어떤 정보라도 감사할 것이다. 데미 _C/ 2005년 4월 19일(UTC) 23:15
  • 몇 번의 시행착오와 청취 후에, 나는 Evolution.ogg에 대한 다음과 같은 컴파운더 설정에 대해 결론을 내렸다.

코덱

나는 단지 이것이 Xiph의 무료 코덱의 관점에서 흥미롭다고 생각했다.

   27483537 4월 15일 00:10 Caesar_cipher.flac 4172650 4월 15일 00:17 Caiser_cipher.ogg 2402619 4월 15일 00:25 Caiser_cipher.spx 122213836 4월 15일 00:10 Caiser_cipher.와브 

기타 노트

• 참고로 프리마트릭스 라디오(freematrix.us)는 몇 가지 검토 후 이러한 것들을 방송할 용의가 있을 것이며, 라디오 쇼에 도움이 될 수 있는 어떤 방법으로 그들을 투입할 수 있는 방법에 대해 이야기 할 것이고, 어쩌면 다른 어떤 것을 할 수 있다면, #프리마트릭스, #리마니아, irc.freenode.net에 있는 애플에 연락할 것이다(곧 가입할 수도 있을 것이다). 뭔가 해결할 수 있을 거야
• GFDL 준수 - 가장 중요한 저자를 인용해야 하는 것과 같은 GFDL 가이드라인에 대해 걱정할 필요가 있는가? 마지막에 구어 목록을 제공해야 하는가, 아니면 위키백과 URL을 사용해야 하는가, 아니면 GFDL 라이센스를 추가해야 하는가?
  • 나는 독자가 마지막에 라이선스 공지문을 낭독하거나, GFDL에 따라 배포되었다고만 명시해야 한다고 생각한다. 고스트 프리먼 10:17, 2005년 4월 13일(UTC)
  • 독일어 녹음은 자료들이 위키피디아에서 온 것이라고 적고, URL http://www.wikipedia.de/을 언급하고, 거기서 기사를 조회하도록 청취자를 초대하며, 실제 기사 텍스트로 진행하기 전에 URL http://www.gnu.org/copyleft/fdl.html,을 언급하면서 GFDL에 따라 허가를 받은 것으로 보인다. 아마 우리도 똑같이 해야 할 것 같아. — Timwi 13:22, 2005년 4월 13일 (UTC)
    • 나는 "<기사 이름>, 무료 백과사전, www.wikipedia.org"으로 녹음을 시작하고, 각각 "이 사운드 파일과 기사의 모든 텍스트는 NPR 방식의 GNU 무료 문서 사용권 하에서 사용권이다."로 녹음을 끝낸다. 사용자:Luigi30 (υσηη ταλκ υγγ)))))) 02:24, 2005년 4월 14일 (UTC)
      • 나는 루이지30의 개찰구와 꼬리 관례를 따르고 있다. 또한, Oggg 컨테이너가 우리에게 몇 개의 추가 태그의 옵션을 주기 때문에, 나는 파일 자체에 다음을 추가했다(아티스트, 날짜, 타이틀 태그 외에, 이것은 위의 리디아 파크 녹음에서 나온 예시다).

        출처

        위키피디아에서 무료 백과사전 www.wikipedia.org

        복사

        GNU Free Documentation License, http://www.fsf.org/licensing/licenses/fdl.txt에 따라 라이센스 부여

        기사

        http://en.wikipedia.org/wiki/Lithia_Park

        버전

        2005년 4월 11일 UTC 08:43

다이어그램(인라인); 인용구

제대로 된 독서가 분명치 않은 상황에 부딪쳤다. 내가 그것을 어떻게 처리했는지 말하고 나서 우리는 그것을 토론할 수 있어, 만약 누군가가 원한다면, 그들은 일관된 관행을 따를 수 있어.

대부분의 다이어그램과 이미지는 기사에 추가되지만 읽을 필요는 없는 "편집"이기 때문에 내가 언급하지 않는다. 그러나 간혹 다이어그램이나 표를 포함하지 않으면 텍스트가 의미를 갖지 못하는 인라인 테이블이나 다이어그램이 있는데, 이는 다이어그램이 말하거나 소개한 내용을 텍스트가 참조하기 때문일 것이다. 그 경우, 본문을 계속하기 전에 "도표 보기:"라고 말하고 나서 간단한 설명을 함으로써 도표를 소개했다.

둘째로, 나는 인용문이나 비슷한 것을 말함으로써 인용문을 도입하는 것을 고려했다; 결국 나는 다른 것을 읽고 있다는 것을 분명히 하기 위해 내 읽을거리를 바꾸었을 뿐이다. 더 많은 대화, 그리고 인용문 출처와 함께 끝냈다.

데미 _C/ 2005년 4월 15일(UTC) 22:34

나는 "공개 인용"과 "접근 인용"이라는 단어를 사용했다. — Timwi 23:11, 2005년 4월 15일 (UTC)

템플릿

• 이 논의는 2005-06-28 아카이브에서 진행되었으며, 나중에 이 아카이브, 다른 아카이브 또는 현재 버전의 토크 페이지에 나타날 수 있다.

날짜

템플릿의 템플릿 토크에서 이 토론을 복사했다.구어 위키백과:

사용자들이 실제로 얼마나 최신인지 알 수 있도록 녹음된 날짜를 기록하면 좋지 않을까?

• 날짜뿐만 아니라 정확한 수정사항을 기록하십시오. 또한 해당 개정판과 현재 개정판 사이의 비교 링크(즉, 역사 페이지의 해당 개정판에 인접한 (커) 링크를 클릭하는 것과 동등한)가 유용할 수 있다. 2005년 4월 17일(UTC) 09:11(Tryduulf 09:11)

안타깝게도 이전 수정본 또는 현재 수정본에만 연결할 수 있으며, 현재 표시되는 수정본에 대한 영구적인 주소는 없다. null 편집은 해결책 역할을 한다. --Andrew 09:17, 2005년 4월 17일(UTC)

음, 현재 사실이야, 개발자들이 이 작업을 하고 있는 것으로 알고 있지만. 또 다른 작업은 최신 비전류 수정본을 보고 링크를 클릭하여 최신 편집을 보는 것이다. 내 생각에 이것은 기본적으로 주어진 아이디를 가진 버전보다 새로운 버전에 대한 링크라고 말하는 영구적인 URL을 생성한다. 2005년 4월 17일(UTC) 12시 34분

나는 그렇게 생각하지 않는다: 이 페이지에서 그렇게 하면 URL http:///...Template_talk:Ampressed_Wikipedia&redirect=no, 반면 영구 개정 URL은 htttp:///...Template_talk:Wikipedia&oldid=12429402 형식이다. 아마도 임시방편으로, 코드에 수정 사항이 있을 때까지 템플릿에는 언제 생성되었는지의 타임스탬프가 포함되어야 하는가? 또는 포스터에 템플릿을 먼저 추가한 다음 이전 버전의 수정 URL을 찾도록 하십시오. — 2005년 4월 18일 석면토크 10:02 (UTC)

몇 군데에 버전을 넣을까? 아래에는 오디오 파일에 포함하자는 제안이 있는데, 기사들이 바뀌면서 내 버전을 다시 녹음하는 것이 어떤 의미일까를 생각해보면, 나는 그것이 그렇게 유용하다고 확신할 수 없다. 나는 프로젝트 페이지 외에 파일 설명 페이지에 버전을 추가한다. 이 사람들이 제안하는 대로 템플릿에 넣어야 할까? 데미 _C/ 2005년 4월 18일(UTC) 21:11

말하기 요청?

구어 기사를 위한 섹션이 있어야 하지 않을까? 그렇지 않다면 이 정도면 될 것 같다. 고스트 프리먼 토크 21:32, 2005년 4월 16일 (UTC)

• Demi _C/ 2005년 4월 16일 (UTC) 22:27, 22:27, 프로젝트 페이지에 "읽을 예술" 섹션을 추가했다.

텍스트 음성 변환

나는 이 프로젝트가 문자 음성 변환 프로그램을 교육하고 운영하는 것 대신에 시작한다는 것이 조금 놀랍다. 그렇게 하면 훨씬 더 빨리 더 많은 커버리지를 제공할 수 있을 것 같고, 최신 정보를 유지하는 것이 훨씬 쉬워질 것이며, 특별한 오디오 장비가 필요하지 않을 것 같다. 비록 실제 사람들이 기사를 읽게 하는 것은 좋은 감동이다. 반면에, 사람들이 자신의 텍스트 음성 변환 프로그램을 그들의 웹 브라우저와 결합하여 사용할 수 없는 것은 아니다. 이것은 일종의 전체 노력을 의심하게 한다. 비록 소유자가 없거나 그러한 소프트웨어를 설치할 수 없는 사람들에게 오디오를 제공하는 것은 가치 있는 일일지 모른다. 컴퓨터가 망칠 단어들에 발음 힌트를 줄 수 있는 협력적인 방법이 있다면 좋을 것이다. -- Beland 11:27, 2005년 4월 17일 (UTC)

• 음, 만약 백과사전을 읽으며 11분 동안 합성된 연설을 들을 수 있다면, 당신은 나보다 더 힘든 사람이야! 어쨌든, 나는 시각장애인을 위한 말하기 책뿐만 아니라 (사람들이 녹음한) 오디오북의 인기를 주목하며, 유용한 노력이라고 생각한다. 시각장애인을 위한 구어 기사의 유용성 외에도, 영어를 배우는 사람들뿐만 아니라 그것을 좋아하는 사람들에게도 유용할 수 있다. 나는 이 프로젝트가 누군가 사용할 수 있는 유용한 텍스트 음성 변환 도구를 할인하는 것으로 보지는 않지만, 또한 내가 보기에 우리가 할 수 있는 곳에 구어 미디어를 추가하는 것도 가치 있는 일인 것 같다. 데미 _C/ 2005년 4월 17일(UTC) 18:56

• • 데미랑 같이 할께 문자->음성 기술이 아직도 얼마나 나쁜지 놀랍다. 독일 게스프로체네 위키피디아에서 몇 개 들으려고 했는데, 그냥 안 되네. 15초 후에 뇌경련을 일으킨다. 그렇긴 하지만, 나는 더 나은 기술이 존재한다면 그 아이디어를 받아들일 수 있다. Fuzheado Talk 07:39, 2005년 4월 19일 (UTC)

• • • 하지만, 연설하기 좋은 텍스트는 같은 목소리를 듣는 것이 여전히 지루함을 얻는다. 그리고 사람들이 말하듯이, 그것은 현재 질적으로 매우 가변적이다. 이것은 대단한 프로젝트다. :ChrisG 23:44, 2005년 4월 20일 (UTC)

• • • • 나는 여름 직장에서 맹인 학생과 함께 일했는데, 그의 스크린 리더가 정말 싫어졌어! 나는 어떻게 사람들이 그것을 몇 시간 동안 들을 수 있었는지 상상할 수 없다. 비록 그 프로젝트가 시간이 많이 걸리지만, 나는 실제 사람들과 함께 하는 것을 지지한다. 게다가 음역도 괜찮고. 들을 때 온갖 억양과 목소리를 들으면 깔끔하다. 위키백과의 "누구나 기여할 수 있다"는 느낌을 요약한 거겠죠? Ckamaeleon 20:07, 2006년 1월 19일 (UTC)[]

버전 지정

기사의 버전 날짜를 구두소개에서 발표하는 것이 좋을 것 같다, 아닌가? -- Beland 11:31, 2005년 4월 17일 (UTC)

• 나쁘지 않은 생각이야. 다른 댓글은? 데미 _C/ 2005년 4월 17일(UTC) 18:03
• 비록 이것이 시작보다는 마지막에 하는 것이 좋을 것이라고 생각하지만. 앞면이 많으면 흥미가 떨어진다고 생각한다. 데미 _C/ 2005년 4월 17일(UTC) 18:34

완료된 녹화표

• 이 논의는 2005-06-28 아카이브에서 진행되었으며, 나중에 이 아카이브, 다른 아카이브 또는 현재 버전의 토크 페이지에 나타날 수 있다.

더 좋은 생각?

• 이 논의는 2005-06-28 아카이브에서 진행되었으며, 나중에 이 아카이브, 다른 아카이브 또는 현재 버전의 토크 페이지에 나타날 수 있다.

배치 및 이름 지정

• 이 논의는 2005-06-28 아카이브에서 진행되었으며, 나중에 이 아카이브, 다른 아카이브 또는 현재 버전의 토크 페이지에 나타날 수 있다.

음성 합성

축제는 음성 합성을 위한 예술의 상태에 가까운 것처럼 보이지만, 그것은 OpenBSD를 기반으로 하지 않는다. 누군가 설치해서 16비트 디폰 목소리 중 하나를 이용해서 우리가 녹음한 합리적인 긴 기사를 실행할 수 있을까? '왜 목소리만 합성하는 게 아니냐'는 질문을 많이 받고 있는데, 이에 비교할 구어적 기사와 문자 대 구어적 기사를 쓰는 것이 토론에 보람이 있을 것 같다. 데미 _C/ 2005년 4월 18일(UTC) 00:24

• 비교를 위해 음성 합성 파일을 갖는 것은 아마도 이치에 맞을 것이다. 독일어 위키백과에도 하나 있다. 그들은 결코 이것을 언급하지 않았지만, 마치 그들이 말하는 것처럼 보였다. "이것봐, 이것이 언어 합성이야. 쓸모없는 것이 아닌가? 그래서 우리가 직접 녹음하는 겁니다." — Timwi 11:56, 2005년 4월 18일 (UTC)

• • Gesprochene에 있는 것은 정말 끔찍했다.위키백과. Fuzheado Talk 07:41, 2005년 4월 19일 (UTC)

최근 Aramaic 관련 기사

나는 최근 특집 기사에서 이것을 시험해 보았는데, 그것은 꽤 길고 실제 발음을 흥얼거리는 사람들을 포함한다. 지금까지 나는 15분에 이르렀고 아직도 그 기사를 절반도 못 읽고 있다. 나는 너무 천천히 읽지는 않았지만 멈추지도 않았어. 나는 거기서 멈춰서 결과적인 ogg 파일을 저장했다. -- 지금까지 8MB. 스트레이트 투 스루 읽기를 포함하는 하나의 파일은 실현 가능하지 않을 것 같다. 기사의 개별 부분을 녹음해봐야 할 것 같다. -- 데릭 로스 토크 04:14, 2005년 4월 18일 (UTC)

• 아마도. 방금 Evolution을 녹음했는데, 꽤 길다. 나는 결국 34분 이상 15MB의 파일로 끝났지만, 어쨌든 끝까지 해냈다. 그것은 실현 가능하지만, 아마도 구간별로 관리하기가 더 쉬울 것이다. 긴 기사에 대해 이 작업을 수행하려면 다음과 같은 사항을 고려해야 한다.
  • 도입부는 매우 짧을 것이다. 자신의 섹션 파일에 있어야 하는가, 아니면 다음 섹션과 함께 있어야 하는가?
  • 여러 파일을 다운로드하는 데 불편한 점이 있으십니까?
  • 어떻게 하면 모든 것을 사람들에게 알릴 수 있을까? 목록을 수락하는 템플릿을 만드시겠습니까?
• 반면에, 변경 제어를 조금 더 쉽게 할 수 있고 각각의 파일은 조금 더 관리 가능하다. 데미^T/_C 2005년 4월 18일 (UTC)
  • 나는 각 기사에 두 개의 파일이 있는 것을 합리적으로 상상할 수 있었다. 한 명은 리드 섹션만 있고, 한 명은 기사 전체를. 일단 당신이 완전한 기사를 얻으면, 당신은 그것으로부터 하찮은 짧은 파일을 얻을 수 있다. — Timwi 11:56, 2005년 4월 18일 (UTC)

나는 이 프로젝트가 좋은 생각이라고 생각하는데, 아라미어 언어의 주요 공헌자 중 한 명으로서 한번 해봐야겠다고 생각했다. 대부분의 (!)를 썼기 때문인지 '허밍거'라는 발음은 그다지 나쁘지 않지만, 파일은 크다. 파일을 분할하는 것이 가장 좋겠지만, 그렇게 되면 청취자들에게 기사의 흐름을 방해하게 될 것이다. 각 파일에는 프로젝트 페이지에서 제안된 상단 및 후미가 필요하며, 스피커는 이전 파일 끝에 다음 파일을 소개하고자 할 수 있다. 생각은? --Gareth Hughes, 2005년 4월 18일 (UTC)

너의 파일은 얼마나 크니? 벌써 올렸니? 누군가 당신을 위해 더 낮은 비트 전송률로 변환할 수 있을지도 모르지만, 당신은 그것을 먼저 업로드 해야 할 것이다:-. — Timwi 12:30, 2005년 4월 18일 (UTC)

나는 그 파일을 압축하는 작업을 하고 있다. 리드 섹션은 꽤 쉽게 올렸는데 이미지에서 찾을 수 있을 겁니다.아람어(lead section.ogg. --Gareth Hughes 12:52, 2005년 4월 18일(UTC)

웨일스 신부는 아마도 아히카르와 아차메니드의 발음에 대한 정의를 행할 수 있는 완벽한 위치에 있을 것이다. 나머지 사람들은 아마도 그들 중 한 명 또는 두 명에게 심호흡을 할 필요가 있을 것이다. ;) -- 데릭 로스톡 14:22, 2005년 4월 18일 (UTC)

자신감을 가져줘서 고마워, 내 생각엔! 나는 그 기사를 녹음하기 위해 오디오시티를 사용하고 있다. 기사 부분을 녹음하고 오디오를 업로드할 준비를 하는 최선의 방법을 제안할 수 있는 사람이 있는가? --Gareth Hughes 14:32, 2005년 4월 18일 (UTC)

엔드 소재

기사의 끝에는 참고, 참고, 외부 링크, 각주 등과 같은 공통 섹션이 있을 수 있다. 나는 "외부 링크"를 제외한 대부분의 것들은 읽혀져야 한다고 생각한다. 대부분의 경우 URL이 아닌 페이지의 링크 제목. 이 자료의 취급방법에 대한 동의서가 있는가? 건배, -Wilmcw 00:25, 2005년 4월 19일 (UTC)

• 아직 기준이 없는 것 같다. 내가 해온 것은 링크 URL을 포함한 모든 See also, Reference, External links 정보를 읽는 것이다. 듣는 것은 귀찮지만, 나는 그 기사가 본질적으로 끝나기 때문에 듣는 사람은 언제나 "stop"을 누를 수 있다는 논리로 한다. 데미 _C/ 2005년 4월 19일(UTC) 01:11
• URL이 짧으면 말하고 싶을 때 말할 수 있지만, 이상하면(예: ?, = 등) 페이지 제목과 페이지 호스트 도메인 또는 다른 정보를 주면 페이지를 다시 찾을 수 있다. 출처, 참고 자료, 참고 자료에도 분명히 이런 일을 하겠지만, 외부 링크는 선택 사항인 것 같다. 예를 들어, 기사가 회사에 있고 회사의 웹페이지에 링크가 있지 않다면 말이다. --brian091818 01:27, 2005년 4월 19일(UTC)
  • 감사윌맥크
• 나는 See 또한 말하고 싶고 중요한 참고문헌은 말하고 싶지만 외부 링크는 말하고 싶지 않다. 왜냐하면 후자는 구어체 형태로 많이 사용하지 않기 때문이다. Fuzheado Talk 16:51, 2005년 4월 21일 (UTC)

너무 큼/스플릿함

로버트 오펜하이머를 녹음했어 이 글은 42분 길이의 것으로 26메가 이상이다. 위키피디아는 업로드된 파일에 대해 8메가 제한을 두고 있다. 각 섹션에 대해 별도의 트랙이 있으므로 분할하는 것은 문제가 되지 않지만, 템플릿으로 여러 파일을 처리하는 방법은 무엇인가? 2005년 4월 19일 02:11(UTC)

• 파일 크기를 줄이지 못하셨나요? 파일 크기가 작은 파일을 더 긴 사람과 대화하십시오. --brian0918™ 02:21, 2005년 4월 19일(UTC)
• 또한, 당신은 그것을 Commons에 올릴 수 있다. 그들은 더 높은 한도를 가지고 있다.

나는 그것을 하원에 올리려고 했지만, 8메가 한도에 대한 동일한 오류 메시지를 받았다. 파일 크기 제한을 찾을 수 없음. -Willmcw 05:30, 2005년 4월 19일(UTC)

• 음, Evolution.ogg는 15MB +이고 위키피디아에 업로드했어. 시간이 좀 걸리고, 오늘 그렇게 하는 데 세 번이 걸렸다. 어쨌든 에볼루션의 길이는 34분이고, 그것은 현재 완성된 기사 목록에서 가장 긴 파일이다. 오펜하이머 파일은 평균 비트 전송률 86kb/s로 인코딩되며, 이는 우리가 권장하는 비트 전송률(48kb/s)이나 내가 사용하는 비트 전송률(64kb/s)보다 높은 수치 입니다. 대상 비트 전송률을 직접 제어할 수 없는 경우 Ogg 인코딩 품질을 더 낮은 수준으로 설정하고 원하는 값을 확인하십시오. 어쨌든, 나는 우리가 언젠가 분할된 파일들의 문제를 다뤄야 한다고 생각한다. 데미 _C/ 2005년 4월 19일(UTC) 05:38

피드백 고마워. 나는 44.1킬로헤르츠 모노로 설정된 오디오시티를 사용했는데, 어떻게 그렇게 크게 자랐는지 모르겠다. 파일의 비트 전송률을 낮출 수 있는 프로그램을 아는 사람? 또한, 8 메가그램 한도가 확실하지 않다면 왜 내가 큰 파일을 업로드할 수 없는지 아는 사람 있어? 마지막으로, 거의 모든 특집 기사가 길기 때문에, 그 기사들에 초점을 맞추면 많은 빅 파일들이 있을 것이다. (이전의) 가장 많이 액세스한 파일 목록이 또 다른 기사 출처가 될 것인가? 건배, -Wilmcw 05:46, 2005년 4월 19일 (UTC)

• 나는 직접 오디오를 사용하지 않지만, 파일 » 기본 설정 » 파일 형식 » Ogg Export Setup은 인코딩 품질을 변경하는 데 사용할 수 있는 옵션이 있다고 생각한다. 디폴트는 5인 것 같아. 나는 2개 또는 3개 시도해볼 수 있다. 데미 _C/ 2005년 4월 19일(UTC) 08:21

아, OGG 품질 설정을 찾았고 로버트 오펜하이머의 크기를 약간 줄일 수 있었다. 그 결과 16Meg의 파일(Audacity/OGGG 품질 수준 0)에 불과했다. 나는 그것을 성공적으로 올렸지만, 어떤 이유에서인지 위키피디아는 그것이 이미지라고 결정했다. 다음에는 좀 더 짧은 기사를 써봐야겠어. 도와줘서 고마워, 모두들. 훌륭한 프로젝트. -Willmcw 08:51, 2005년 4월 19일 (UTC) ("시각장애인을 위한 독서"의 장)

위키피디아는 어떤 것이 이미지라고 "결정"하지는 않지만, 모든 파일이 네임스페이스에 업로드되는데, 이는 역사적 이유로 인해 "이미지"라는 이름이 붙여졌다. [[Media:]를 사용하여 파일에 직접 연결할 수 있다.Robert Oppenheimer.ogg] 또는 [[:Image:]를 사용하여 설명 페이지에 연결하십시오.로버트 오펜하이머.ogg](소프트웨어가 인라인으로 이미지화하려고 하지 않도록 지시하는 선도 콜론(leading colon)을 메모한다. — Timwi 09:19, 2005년 4월 19일 (UTC)

분할 또는 축약

이 기사 듣기(2부)

1부 · 2부

참고: 기사를 변경하면 오디오 파일이 오래된 것일 수 있다. (도움말 필요)

위키프로젝트 구어 위키백과

범주:구어 기사

이 기사 듣기(3부)

제1부 · 제2부 · 제3부

참고: 기사를 변경하면 오디오 파일이 오래된 것일 수 있다. (도움말 필요)

위키프로젝트 구어 위키백과

범주:구어 기사

파일을 분할하는 문제에 대해 나는 많은 FA들이 30분에서 1시간 정도의 상당히 큰 오디오 파일을 만들 것이라는 데 동의한다. 오디오 파일의 길이가 10MB 미만이어야 하고 단면 경계에서 분할되어야 한다는 지침과 함께 새로운 {{Ancedic 위키백과-n} 템플릿(n 1 - 5: 나는 우리가 5부 이상으로 분할할 필요가 별로 없다고 생각한다)을 만들 것을 제안한다. 다들 어떻게 생각해? 나보다 더 훌륭한 템플릿 기술을 가진 사람이 이걸 어떻게 해서든 하나의 템플릿에 넣을 수 있을까? 데미 _C/ 2005년 4월 19일(UTC) 08:30

이것은 우리가 결정해야 할 것을 제기한다 - 우리는 항상 전체 기사를 말하고 싶은가? 보다 '조기 친화적인' 기사를 요약해서 만드는 것이 합리적인가, 바람직한가? 아니면 특정 섹션만 말할까? 독서를 위한 글쓰기는 귀를 위한 글쓰기와는 사뭇 다르다. 나 자신도 정말 긴 문장을 두 개의 짧은 문장으로 나누기 위해, 그것을 기록하기 전에 한 기사(펄리처상)를 편집하는 일에 착수했다. Fuzheado Talk 08:47, 2005년 4월 19일 (UTC)

이런, 로버트 오펜하이머 기사를 읽기 전에 편집했으면 좋았을 텐데. 일부 문장은 몇 절씩 계속되어, 내가 생각했을 때 갑자기 되살아났다. 특집 기사도 좋지만 길다. 프로젝트를 진행하기 위해서는 또한 유용한 도서관을 짓기 위해 좋은 단편 소설의 출처가 필요하다. 위키백과 1.0 프로젝트는 기사의 소개 단락만을 사용하는 것을 고려하고 있지만, 그들의 목록은 아직 준비되지 않았을 수도 있다. 논리적인 대상에 대한 다른 제안은? 사용자:데미, 템플릿이 멋져 보인다. 많은 기사의 경우 섹션에 대한 개별 파일이 더 타당할 것이다. 제1부"를 "섹션 헤더"로 교체하거나 파이프라인으로 연결하는 것이 가능할 것 같다. 그렇지 않다면 그것도 괜찮아. 건배, -Willmcw 11:07, 2005년 4월 19일 (UTC)

하, 그래 나는 기사를 소리내어 읽기 전에 정교하게 편집하는 버릇이 생겼다. 그래서 7분짜리 녹음을 하는데 약 1시간이 걸린다. 왜냐하면 나는 실수를 고치고, 긴 문장을 나누고, 듣는 것을 위해 일을 시키기 때문이다. 구어 발음의 혜택을 받는 몇 가지 기사를 시도하고 있으니 시험 케이스는 중국식 딤섬이다. 또한, 나는 소개서를 쓰고 마지막에 GFDL을 쓰는 라디오 대본과 비슷한 것(딤섬/말씀 참조)을 만드는 것이 조금 더 쉽다는 것을 알게 되었다. Fuzheado Talk 12:02, 2005년 4월 19일 (UTC)

내가 좀 해봤어 아주 조금 나는 우리가 "기사의 주제를 오디오로 발표하는 것"이 아니라 "기사를 말하는 것"으로서 무엇을 하고 있는지 안다. 그만큼 (적어도 나에게는) 충실함이 중요하다. 나쁜 글의 경우, 나는 그 중 일부를 수정했다. 결국, 우리는 편집자이기도 하다. 그리고 큰 소리로 말할 때 나쁜 글이 있다면 그것은 아마도 나쁜 것일 것이다. 하지만 만약 내가 아주 사소한 변경을 한다면, 나는 그것을 만들고 그것을 기록하기 전에 하루 정도 기다릴 것이다. 만약 있다면, 다른 편집자들이 그들의 의견을 말할 수 있는 기회를 주기 위해서일 것이다. 데미 _C/ 2005년 4월 19일(UTC) 18:22

템플릿에 Wilmcw--잘 모르겠어, 난 템플릿 코드를 가진 신참이라서. 그러나, 나는 또한 이러한 녹음들이 결국 본문 밖의 어떤 시스템(전화로 위키피디아?)을 통해 이용 가능한 것으로 보고 있다. CD로?) 그러니까 기사 자체의 구조에 너무 의존하지 말아야 할까? 데미 _C/ 2005년 4월 19일(UTC) 18:22

좋은 지적이야. Re: 잠재 기사 목록, 이른바 "핵심 주제" 목록을 우연히 발견했었습니다. 그들 중 상당수는 상당히 짧고 안정적이며, 추정가치가 있다. 공식적인 것도 아니고, 심지어 조사된 것도 아니어서 우리가 채택하고 싶은지 모르겠다. 그러나 그것은 좋은 출발점이다. 건배, -Willmcw 20:56, 2005년 4월 19일 (UTC)

• 모든 언어가 갖춰야 할 기사 목록도 있다. 데미 _C/ 2005년 4월 19일(UTC) 22:38

아 좋다. 나는 그 리스트가 우연히 "단순한 영어" 기사를 가리키고 있다는 것을 알았다. 그것들은 간단하지 않은 영어 기사들보다 더 짧다. 우리가 "단순한 영어" 기사를 읽는다면, 그것을 단순하지 않은 영어 기사로 다시 연결하는 것이 여전히 적절한가? 그 반대는? 음. -Wilmcw 23:35, 2005년 4월 19일 (UTC)

단순하다는 것은 그 자체 위키백과니까, 나는 그런 것과 같은 맥락에서 언어간 연결과 같은 것을 분류하고 싶다. 우리가 가질 수는 있지만, 같은 것이 아니라는 것은 분명해야 한다. 나는 en에 있는 우리의 템플릿을 사용하지 않을 것이다: 간단한 기사를 위한 기사 페이지: 나 자신. 데미 _C/ 2005년 4월 21일(UTC) 18:40

만약 우리가 기사를 부분이나 부분으로 나누면, 우리는 어떻게 연계를 다루는가? 각 파트의 끝에 면허증을 콕 찌르는가? 위키피디아에서..'각각의 시작'? "2부에 계속..." 및/또는 "1부에서 계속..."?" 데미 _C/ 2005년 4월 19일 (UTC)

나의 의도는 "벌레, 제1부 면허 정보"라는 기사 제목을 읽는 것이다. 어쩌면 "3부 1부"로 만들 수도 있다. 그런 다음 "Worms에서 계속, 파트 2, 엔드 라이선스 정보"를 참조하십시오. 어떤 경우에도 전체 라이센스 정보는 각 기록에 있어야 한다. -Willmcw 23:59, 2005년 4월 19일(UTC)

OGG 규격

현재 문서에는 OGG를 48kbps로 사용한다고 되어 있지만, Oggg를 사용하는 경우 VBR 이후 어떤 것도 정확히 평가할 수 없으며, 슬라이더도 1~10에 불과하다고 Audacity 등은 말한다. 우리는 그 대신에 어떤 품질을 사용해야 하는지 명시하지 말아야 하는가? Fuzheado Talk 07:43, 2005년 4월 19일 (UTC)

• 아마도. 위의 샘플링 및 인코딩 품질과 비트레이트에 대한 내 노트를 봐. 명령줄 인코더를 사용하여 0-10의 품질 또는 대상 비트 전송률을 지정할 수 있다. 내 오디오 파일에 있는 인코더는 3은 48kb/s, 5는 64kb/s, 8은 120kb/s 입니다. 하지만 Timwi는 나에게 그가 5로 설정된 퀄리티로 인코딩을 하고 그의 결과 파일은 110kb/s 정도라고 말한다. "권장 도구" 섹션에 권장 설정을 제공하는 것이 좋다고 생각하지만, 어떤 설정이 되어야 하는지 모르겠다. 데미^T/_C08:14, 2005년 4월 19일(UTC)
  • 난 딤섬을 레벨 3에 암호화했는데, 그건 내가 할 수 있는 한 가장 낮은 수준이야. 꽤 "끔찍한" 소리처럼 들리지만 말이야. Fuzheado Talk 11:58, 2005년 4월 19일 (UTC)

대담성 HowTO

많은 사람들이 오디오시티를 사용하고 있기 때문에, 그것을 사용하는 방법, 어떤 메뉴 옵션을 사용할지, 어떤 버튼을 누를지 등에 대해 "어떻게" 또는 커닝 시트를 하는 것이 좋을지도 모른다. 내가 사용하고 있는 도구에 대해서는 그렇게 했지만, 대담성 버전은 여기 오는 사람들이 첫 번째 녹음을 하는 데 도움이 될 수도 있다. 데미 _C/ 2005년 4월 19일(UTC) 18:26

참고 항목

• 이 논의는 2005-06-28 아카이브에서 진행되었으며, 나중에 이 아카이브, 다른 아카이브 또는 현재 버전의 토크 페이지에 나타날 수 있다.

대화 페이지의 템플릿

나는 우리가 Talk: page에 템플릿이 있어야 한다고 생각하지 않는다. -- 그것은 그것을 위한 장소가 아니다. User talk에 다음과 같이 적었다.Brian0918:

나 또한 기사 페이지에서만 링크가 더 낫다고 생각한다. 나에게 있어 유용한 경험 법칙은 위키피디아의 독자들/사용자/청중을 주로 대상으로 하는 것들이 실제 기사에 속하고, 편집자를 대상으로 하는 것들은 토크 페이지에 속한다는 것이다. 이 경우 기사의 녹음으로 연결되는 링크는 편집자가 아닌 독자층(er, "듣기!")을 대상으로 하며, Talk: 페이지가 아닌 기사 페이지에서만 (IMO)하는 것이 나을 것이다. — Matt Crypto 02:13, 2005년 4월 20일 (UTC)

• 그러나 구어 위키백과 템플릿은 위키프로젝트에 연결되는데, 다른 토크 페이지에도 위키백과 제목 템플릿이 맨 위에 있다. 이것은 페이지 편집에 관한 것이 아니라 기여하는 방법에 대한 링크를 가지고 있는 추천 기사 템플릿과 유사하다. 라울654와 다른 위키프로젝트 회원들과 이야기했는데, 그들은 괜찮다. 앞으로 더 많은 사람이 생기면 바꿀 수 있을 겁니다. 우리는 단지 다른 구어 위키백과 템플릿을 만들 수 있을 뿐이다 (그러나 그것은 여전히 기사의 오디오 파일에 대한 링크를 가지고 있어야 한다). --brian091818 02:18, 2005년 4월 20일 (UTC)

자, 페이지의 "Featured" 상태는 편집자에게 기사에 대한 유용한 메타데이터로서, 그것은 기사의 동료 검토와 안정성을 반영하는 최종 결과물이기 때문이다. (정보가 독자들에게도 유용하기 때문에, 우연히도, 추천 템플릿은 메인 기사 페이지 자체에 있는 것이 좋다고 주장할 것이다.) 그러나 적어도 내가 보기에 스피치 템플릿은 많은 유용한 편집 정보를 제공하지 않는다. 그것은 스피치 위키프로젝트와 연결될 수 있지만, 그것은 주제 영역을 조정하기 위해 존재하는 다른 위키프로젝트들과는 다르다. 이것은 분명히 아주 중요한 문제는 아니지만, 나는 우리가 얼마나 많은 잡동사니를 추가하는지 주의할 필요가 있다고 생각한다. 예를 들어, 토크에서:카이사르 암호, 목차를 보기가 어려워진다. 토크 페이지 템플리트를 추가하는 것은 (적용할 정도로) 비용이 많이 들지만, 편집자들에게는 실질적인 이익을 제공하지 못하거나 적어도 내가 볼 수 있는 한에서는 그렇지 않다. 위키프로젝트의 프로필을 약간 올릴 수도 있겠지만, 나는 Talk 페이지에 투박한 템플릿을 추가하는 것보다 (가장 우수한) 스피치 WP 프로젝트를 알리는 더 좋은 방법이 있을 것이라고 확신한다. — Matt Crypto 02:32, 2005년 4월 20일 (UTC)

네, 토크 페이지용으로 특별히 디자인한 템플릿을 만들었답니다. 위키프로젝트 페이지를 참조하십시오. 검토해서 적절한 기사에 추가하겠다. --brian0918™ 02:42, 2005년 4월 20일 (UTC)

고마워, 비록 이 토크 페이지 템플릿이 스피어드 광고 이외의 다른 효용인지는 아직 확신할 수 없지만. 물론 그것은 꼭 나쁜 것만은 아니지만, 아마도 주제에서 벗어난 이야기일 것이다: 임의의 주제에 관한 기사들을 위한 페이지들 - 적어도, 그것은 내가 할 일이다. 하지만, 다시 말하지만, 그건 별일 아니야. 그리고 나는 사람들이 원하는 어떤 것이든 함께 할 수 있어서 행복해. — Matt Crypto 02:50, 2005년 4월 20일 (UTC)

지금까지 라울654, 데미, 루이지30, 그리고 실소르와 함께 이야기했는데, 모두 괜찮다. 체크아웃 대화:카이사르 암호. 위키프로젝트 템플릿은 모두 이것과 같다(광고?). --brian0918™ 02:56, 2005년 4월 20일(UTC)

좋아, 만약 Talk: 페이지에 있는 템플릿이 유익하다는 의견이 일치한다면 기꺼이 받아들이겠어. 그러나 나는 "주제" 위키프로젝트 템플릿은 두 가지 면에서 다르다고 주장할 것이다. 1) 구어 템플릿과 달리 프로젝트 템플릿을 기사 페이지에 넣는 것은 부적절할 것이다. 2) 특정 분야의 기사를 편집하는 데 관심이 있는 편집자는 특히 그 주제를 다루는 관련 위키프로젝트에 관심을 가질 가능성이 높다. 임의의 주제에 관한 편집자가 스피치 위키프로젝트에 관심을 가질 특별한 이유는 없다. 우리는 Talk 페이지에 있는 Wiktionary, WikiQuote 등에 대한 링크에 만족할까? — Matt Crypto 03:15, 2005년 4월 20일 (UTC)

물론, 위키의 어떤 면이라도 홍보하는 것은 난 괜찮아. 무작위로 우연히 마주치기 전까지는 다른 프로젝트 몇 건에 대해 알아내지 못했다. --brian0918™ 03:19, 2005년 4월 20일 (UTC)

글쎄, 아마도. 초인적인 극단적 주장을 펴기 위해, 당신은 모든 토크 페이지에 모든 위키백과 프로젝트에 대한 링크를 포함시킬 수 있지만, 그것은 사람들이 무언가를 찾는데 도움이 되지 않을 것이다. 그것은 단지 프로젝트의 소음을 증가시킬 뿐이다. 우리는 사물을 따져보고, 링크의 이점이 가치가 있는지 살펴봐야 한다. 내가 생각하기에, 잡동사니를 줄이는 좋은 방법은 주제에서 벗어나지 않도록 노력하는 것이다. 위키피디아에는 가치 있는 프로젝트를 홍보하기 위한 많은 다른 장소들이 있지만, 기사의 토크 페이지는 주로 그 특정 기사를 개선하는 방법에 대한 토론을 위한 것이다. 물론 같은 분야의 위키프로젝트 링크를 포함하거나 피처링 기사 상태를 언급하는 것이 적절하다. 하지만, 나에게 있어서 스피치, 위키트리노, 위키쿼트(또는 그 무엇이든)와 같은 프로젝트들에 대한 링크는 너무 일반적인 것처럼 보인다. (물론 기사 페이지 자체에서는 괜찮다. — Matt Crypto 03:28, 2005년 4월 20일 (UTC)

위키트리노와 위키쿼트는 자매 프로젝트인데 메인 페이지 광고를 낸다. 스피드는 위키프로젝트에 불과하며, 다른 위키프로젝트가 하는 것과 같은 종류의 광고를 얻을 수 없다(특정 주제에 관한 것이 아니기 때문이다). 그래서 우리는 가능하면 광고를 해야 해. 프로젝트가 훨씬 더 커지면, 우리는 토크 페이지 템플릿을 없애는 것을 고려할지도 모른다. --brian0918: 03:33, 2005년 4월 20일 (UTC)

좋아, 이게 내가 가지고 있는 문제의 핵심인 것 같아. 그 혜택은 모두 스피치 프로젝트에 대한 것이지 기사 자체에 대한 것이 아니야. 만약 당신이 기사 Talk 페이지에 광고를 포함시키려면, 그것은 그 특정 기사의 이익을 위한 것이어야 한다고 말하고 싶다. 만약 이 토크 페이지 템플릿이 스피어드에 대한 광고라면, 나는 그들이 잘못 알고 있다고 생각한다. 물론 사람들에게 알리는 것의 중요성은 이해하지만, 우리는 마을 펌프, 커뮤니티 포털 등과 같은 많은 장소들을 가지고 있는데, 이런 것들을 가리키기에 적합하다. — Matt Crypto 03:41, 2005년 4월 20일 (UTC)

현재의 위키프로젝트 토크 페이지 템플릿은 기사를 편집하거나 프로젝트에 참여하기 위해 프로젝트 페이지를 방문하는 것을 제안한다. 오디오 파일을 편집할 수 있는 옵션이 없어서 할 수 있는 작업으로 프로젝트 페이지를 방문해야 한다. --brian091809 03:48, 2005년 4월 20일 (UTC)

CSS가 없는 유혹의 주머니쥐

이 생각만 하면. 기초학적으로, 만약 내가 눈이 멀었다면, 나는 그 녹음된 버전에 대해 알고 싶지 않을 것이다. 왜냐하면 M 텍스트 리더가 완전한 노르막 버전을 직접 말했기 때문이다. 내가 말한 것을 강등시키고, 잠시 동안 파이어폭스에서 css를 비활성화하면, 당신은 언어 버전이 아트칼 텍스트 아래에 있다는 것을 보게 될 것이다. 이것은 아마도 내가 단지 전체 (텍스트) 예술적 비젼을 읽거나 읽었을 것이기 때문에 나에게 감각적이지 않은 것처럼 보인다. 오, 그냥 그 녹음을 듣고 싶었을 수도 있어.

페이지의 맨 위에 템플릿을 배치하는 데 문제가 있는 사람? 토오토 19:15, 2005년 4월 20일 (UTC)

분명히 그것은 정책에 위배된다. 나는 결국 일어날 일이 스피어 위키피디아가 자매 프로젝트가 되어 그 문제를 없앨 것이라고 생각한다. --brian0918™ 19:21, 2005년 4월 20일 (UTC)

이 프로젝트 이름

나는 이 프로젝트를 독일어 동급의 문자 그대로 번역된 이름으로 시작한 것을 후회한다. 나는 "말하는 위키백과"가 정말 엉터리처럼 들린다고 생각하기 시작했다. 중요한 이름을 바꾸는 것에 반대할 사람이 있는가? (이런 변화를 빨리 할수록 일은 줄어들 것이다.) — 새로운 명칭에 대한 나의 제안은 "오디오 기사"일 것이다. 개인적으로 나는 훨씬 더 좋아하지만, 물론 다른 제안들도 기꺼이 받아들인다. — Timwi 21:51, 2005년 4월 20일 (UTC)

• 나는 개인적으로 구어 위키백과라는 이름을 좋아한다; 그러나 나는 주제넘는 것에 충분히 신경을 쓴다. BLACKFAZE (ччч??) 22:04, 2005년 4월 20일 22:04 (UTC)
• 나는 사실 구어 위키피디아를 좋아한다. 내 추측으로는 결국 이 의지는 자매 프로젝트가 될 것이고, 그래서 그것은 (오디오 기사와는 반대로) 그런 포괄적인 이름을 가져야 한다. 아마도 오디오피디아? --brian0918™ 22:05, 2005년 4월 20일 (UTC)
• 구어 위키백과는 전혀 문제가 없다. Fuzheado Talk 00:00, 2005년 4월 21일 (UTC)
• 위와 같은 대안보다 "말하는 위키백과"가 더 명확하다고 생각한다. 119 03:33, 2005년 4월 21일 (UTC)
• "말하는 위키백과"는 좋은 것 같아. 어색한 것은 '위키프로젝트'로 이름을 미리 대면하는 것이다. 만약 우리가 그것을 우리의 "상호"에서 "말하는 위키백과"라고 부르면 덜 어색해 보일지도 모른다. 데미 _C/ 2005년 4월 21일 (UTC)
• 구어 위키백과 silsor 05:37, 2005년 4월 21일 (UTC)
• 나는 "말하는 위키백과"는 괜찮다고 생각한다. — Matt Crypto 14:30, 2005년 4월 21일 (UTC)

짧은 특집 기사

나는 메인 페이지에 올라오지 않은 짧은 특집 기사들의 목록을 만들었다. 그들이 메인페이지에 올라오도록 요청한 다음, 그것들을 구어 오디오로 전환함으로써, 우리는 더 빠르고 쉽게 프로젝트의 홍보를 증가시킬 수 있다. --brian0918™ 12:59, 2005년 4월 21일 (UTC)

아이디어?

사람들은 위키피디아의 팬인 누군가에게 그 기사를 스스로 기록하게 하는 것에 대해 어떻게 생각하는가? 아니, 내 말은 짐보를 말하는 게 아니라 윌 휘튼 같은 사람의 대사를 따라 좀더 생각하고 있었다. 생각? Seth Ilys 20:23, 2005년 4월 21일 (UTC)

• 좋은 생각이에요. 만약 당신이 실제로 그것을 할 수 있는 누군가를 구할 수 있다면, 그것은 깔끔할 것이다;-) BLACKFAZE (PRICK о??) 20:33, 2005년 4월 21일 (UTC)

• FSF에 가입할 생각을 하고 있는 사람이 있다면 내가 보냈다고 말해줘. 만약 내가 세 번의 추천을 받으면, 그 상은 RMS (또는 Eben Moglen)가 "안스워링 머신" 인사말을 녹음할 것이다. 기사 녹음을 부탁하는 대신 생각하고 있었다. 데미 _C/ 2005년 4월 22일 02:19 (UTC)

미래를 위한 아이디어

일단 기사가 더 나오면, 아마 레이아웃을 바꿔야 할 것 같아. 프로젝트와 연결되는 기사 템플릿 대신 위키백과:자매 프로젝트 메인 페이지 또는 위키백과의 레이아웃이 있는 구어 기사:특집 기사, 그리고 우리가 가지고 있는 기사들을 적절한 제목에 나열하시오. 이 목록은 파일이나 파일 페이지로 직접 이동하지 않는 링크로 만들어질 것이다. 그러나 하위 페이지인 위키백과:구어 기사/XXXXX, 파일 정보와 파일에 대한 직접 연결(추하고 혼란스러운 이미지: 페이지 통과). --brian091809 21:19, 2005년 4월 21일(UTC)

아마도 우리는 기사에 있는 템플릿이 아니라 언어 링크 위의 오디오 파일에 대한 링크도 가질 수 있을 것이다. Joe D (t) 21:26, 2005년 4월 21일 (UTC)

그걸 어떻게 할 건데? 대부분의 사람들이 눈치채지 못하게 될 것 같아. --brian0918™ 21:28, 2005년 4월 21일 (UTC)

언어간 링크보다 덜 비호감적인가? Joe D (t) 21:42, 2005년 4월 21일 (UTC)

또 다른 맥락에서, 미디어 파일에 레이블을 붙이는 특별한 태그가 있으면 좋을지도 모른다. 나는 내 {GFDL}에 라벨을 붙였지만 아마도 그것들을 구어 기사 파일로 표시하기 위해 {Andressed-GFDL} 또는 유사한 태그가 만들어질 수 있을 것이다. 그렇게 하면 기사에서 떨어지거나 사슬에 다른 파손이 생길 경우를 대비해서 파일을 쉽게 찾을 수 있을 것이다. 이미지에는 이와 같은 특수 태그가 많이 있으므로 전례가 없을 것이다. -Willmcw 22:04, 2005년 4월 21일 (UTC)

링크 위치

위키백과에서 복사한 내용:구어 기사: 프로젝트 페이지에 내가 없다는 것을 깨닫지 못했는데...

이 구어 기사 프로젝트는 훌륭한 아이디어인 것 같은데, 나는 거기에 투입된 일의 양에 놀랐다. 나는 단지 한가지 질문이 있다: 구어판 기사에 대한 모든 링크는 그 기사의 하단에 있다. 이것은 일반적으로 기사를 읽고 나서야 비로소 그것이 존재한다는 것을 깨닫는다는 것을 의미하는데, 이것은 오히려 목적을 저버리는 것 같다.

이 프로젝트가 위키백과 기사의 상당 부분을 다루기 시작하고, 보기/읽기가 어려운 사람들이 구어판을 주시하기 시작한다면, 나는 꼭대기 근처 어딘가에서 눈에 띄는 고지가 필요할 것이라고 생각한다. 만약 위쪽에 작은 스피커 기호나 무언가가 있다면, 사람들은 즉시 구어 버전이 있다는 것을 알 것이다.

사소한 점이지, 확실해. 기사 전체를 읽고 난 후 구어 버전으로 연결되는 링크를 볼 때마다 항상 이상하게 느껴져. — 2005년 4월 21일 석면토크 23:08 (UTC)

• 알아, 이렇게 하는 방법이 있긴 하지만(생각해) 기사를 기록하고 나열하는 단계에 아직 더 많은 지시사항을 덧붙이는 것은 혐오스러워. 데미 _C/ 2005년 4월 22일 02:00 (UTC)

• 아마도 혼란스러운 것 같다.

  구어 버전 사용 가능.

  119 02:14, 2005년 4월 22일 (UTC)

  • 그 생각이 마음에 들어. --brian091818 02:17, 2005년 4월 22일 (UTC)
  • 나는 오디오 파일에 대한 링크가 있는 페이지 맨 위에 있는 섹션의 줄을 따라 좀더 생각하고 있었다. 그렇게 하면 아무도 어수선하다고 불평할 수 없고 스크린 리더는 그것을 볼 수 있을 것이다(생각한다. 데미 _C/ 2005년 4월 22일 02:23 (UTC)
  • FYI, {{사용자:데미/말씀 머리글 파일 이름.ogg}}: 무슨 뜻인지. 데미 _C/ 2005년 4월 22일 04:22 (UTC)

링크 수정 도움말

기사 링크는 [[:Image:FileName.ogg 아티클 이름](Webedia:구어 기사. 링크를 클릭하고 파일 페이지에서 내용(일반적으로 {{gfdl}인 저작권 공지 제외)을 다음 텍스트로 교체하십시오.

{{음성기사 항목 file_name=타이틀=time=file_size=user_name=date=액센트=}}}} 

• file_name은 name_of_file.ogg 형식이어야 함
• 제목이란 실제 기사의 제목을 말한다.
• 시간은 기사의 분 및 초 단위의 시간(예: 12:34).
• File_size는 파일 크기(예: 12.6MB)
• User_name은 파일을 읽거나 업로드한 사용자의 이름이며, 예: Willmcw
• 날짜는 읽은 개정판에 대한 링크여야 한다(예: 2005-04-18).
• 사투리는 독자의 지역 사투리다. 가능성은 영어 사용자들의 지역 억양을 참조하십시오.

FWIW, 나는 [[:Image:foo.ogg] 대신 [[Media:foo.ogg]]를 사용해 왔다, 다른 것 보다는 하나를 사용해야 하는 이유가 있는가? 나는 "미디어" 태그가 더 정확하다고 생각한다. FuzheadoTalk 02:40, 2005년 4월 22일 (UTC)

• [[Media:] 링크는 사운드 파일에 직접 링크를 만들므로 편리하지만 설명 페이지(현재 brian0918에서 만든 템플릿으로 장식되어 있음)로 연결되는 [:Image:] 링크의 편리성은 어느 정도 제공하지 않는다. 나는 이것을 가지고 brian0918의 의도는 두 가지라고 생각한다: 1) 완성된 녹음목록이 한 페이지에 대해 비실용적일 때 그날을 준비하는 것 (아직 도착하지 않았다면) 그리고 2) 녹화에 대해 좀 더 접근하기 쉬운 "공공의 얼굴"을 만드는 것 (프로젝트 페이지는 리스트렌에 대한 정보보다는 참가자에 대한 지시에 관한 것이기 때문에)rs). 그의 입에 말을 넣지 않고 그저 말하기만 했다. 데미 _C/ 2005년 4월 22일 04:16 (UTC)
• 더 이상 프로젝트 페이지에 있는 테이블이 필요 없을 것 같아. 그것은 작업 부하를 줄일 것이다. --brian091818 04:20, 2005년 4월 22일 (UTC)

템플릿 토론

우리의 {{Anyword Wikipedia} 템플릿에 표시되어야 하는 링크에 대해 약간의 의견 차이가 있다. 관심 있는 사람들이 토크 페이지를 방문해서 참고할 수 있을까? 고마워! 데미 _C/ 2005년 4월 22일(UTC) 18:25

제안

프로젝트의 목표와 이유를 프로젝트 페이지 상단에 요약해 볼 가치가 있을 것 같다. 나는 스크린 리더가 필요한 모든 사람이라고 생각했다. 왜냐하면 나는 스크린 리더를 사용하는 몇몇 맹인들을 알고 있고 그들이 충분하지 않다고 말하는 것을 들어본 적이 없기 때문이다. 어떤 경우든 프로젝트의 이유를 맨 위에 바로 세우는 것이 도움이 될 것이다. - 2005년 4월 23일, Taxman 14:51 (UTC)

그들은 Internet Explorer가 웹을 탐색하는 것만큼 "충분하다". 사람들은 그것에 "사용"되고 단지 그들이 무엇을 놓쳤는지 모르기 때문에 불평하지 않는다. — 물론 네 제안에 동의해. :) — Timwi 21:08, 2005년 4월 23일 (UTC)

내 컴퓨터 문제

컴퓨터에서 .ogg 파일을 재생할 수 없는 경우(Real Player, Windows Media Player 등) - 토니 진(토크) 00:21, 2005년 4월 25일(UTC)

Winamp. --brian0918™ 00:22, 2005년 4월 25일 (UTC)

기본적으로 ogg를 지원하는 모든 항목을 설치해 보십시오. http://www.vorbis.com/download.psp ALKIVAR™ 07:03, 2005년 4월 25일 (UTC)

Winamp는 OGG(또는 유니코드 또는 많은 다른 것)를 지원하지 않는다. 나는 foobar2000 또는 XMPlay를 추천한다. — Timwi 14:21, 2005년 4월 25일 (UTC)

최근에 다시 포맷했는데, 윈램프는 내가 제일 먼저 설치했던 것 중 하나야... 오그플레이는 괜찮다. --brian091818 14:31, 2005년 4월 25일 (UTC)

OGG 태그 추가

이 파일 ID 태그를 쉽게 추가할 수 있는 방법을 아는 사람? 나는 그 일을 위해 위넘프를 이용하지만, 위넘프는 그렇게 하기 위한 인터페이스가 매우 서툴다. 고마워, -Wilmcw 23:34, 2005년 4월 28일 (UTC)

• 난 오겐크를 이용해서 인코딩 시간에 하고 있어. Xiph의 vorbis-tools 패키지에는 이 작업을 위해 설계된 명령줄 도구인 명령이 포함되어 있다. 하지만 나는 그것이 윈도우 사용자들에게 많은 도움이 된다고 생각하지 않는다. 데미 _C/ 2005년 5월 4일(UTC) 18:44

고마워. 리눅스로 전환해야 하는 또 다른 좋은 이유. 그동안 OGG 파일의 태깅을 허용한다고 주장하는 Windows 프로그램을 많이 찾았지만, 지금까지 사용자 지정 필드를 허용하는 것은 Winamp뿐이다. 그리고 다른 프로그램들과 함께 Winamp 태그가 붙은 파일들을 보면, Winamp에서 내가 추가한 태그들은 보이지 않는다. 데미, 미디어를 다운로드해 주시겠습니까?en-1755 리스본 지진조항.oga. 태그가 제대로 나타나는지 확인? 만약 내가 Winamp를 사용하는 것이 막혔다면 나는 적어도 그것이 제대로 작동하고 있는지 확인하고 싶다. 건배, -Willmcw 19:22, 2005년 5월 4일 (UTC)

자체 참조

위키피디아를 초래한 큰 실패를 기억하라.범주로 이동하는 구어 기사:기사 페이지의 템플릿이 위키피디아와 연결되었기 때문에 구어 기사: 외부 링크 대신? 자, 링크 이름에는 위키백과 대신 {{SITENAME}}을 사용하기만 하면 되었다. 위키백과를 만드는 [{{{SITENAME}}:음성 기사]가 되었을 것이다.구어 기사, 그리고 이것은 제3자 사이트에 그들의 시타임이 무엇이든 보존될 것이다. 카테고리를 이전하는 것을 고려한다면: 위키백과로 다시 페이지 이동: (문제가 해결되었으므로, 다시 이동하면 기사 페이지의 문구의 혼란과 잡음이 줄어들 것이다.) --brian0918™ 08:22, 2005년 4월 30일 (UTC)

나도 동의해, 하지만 난 자기소개를 회피하고 있지 않아. 그래서 별로 중요하지 않아. --SPUI (토크) 08:23, 2005년 4월 30일 (UTC)

요약제안

열 개 정도의 기사를 읽으면서, 나는 그것을 준비하고 끝내는 데 드는 시간이 덜 걸리는 기사를 완성하는 법을 배웠다. 그럼에도 불구하고, 그것은 매우 시간 소모적이다. 가장 짧은 특집기사는 약 2,000단어, 약 15분의 방송시간, 최소 1시간의 제작시간이며, 모든 것을 고려해 볼 때 더 많다. 긴 물건은 우리 대부분에게 엄청나게 많은 시간을 소비한다. 반면에, 무작위 기사가 아닌 유용한 참고 자료로 만들기 위해 가능한 한 많은 주제에 관한 기사들 중 최소한 일부를 읽는 것은 멋질 것이다.

우리에게 필요한 것은 하위 프로젝트, 즉 기사의 소개를 읽는 것이다. 대부분의 기사는 초기 단락을 요약으로 사용하므로, TOC 위의 모든 것을 단순히 읽는 것은 단순하지만 포괄적인 재료 선택 방법을 제공할 것이며, 다른 기사들에게도 명백할 것이다. 그것은 다른 템플릿들의 하위분할이 될 것이다. "전체/개요/요약" 또는 그와 비슷한 것. 내부 링크에 "참조/참조"를 넣을 수도 있지만 모든 긴 링크와 참조, 공식, 다이어그램 등은 사용하지 마십시오. 게다가, 소개는 그들의 전체 기사보다 더 자주 바뀌지 않기 때문에 소개만 해도 최신 기사일 가능성이 더 높다.

예를 들어, The Treativations를 보십시오. 약 5500단어 정도의 훌륭한 글인데, 하나도 어렵지 않다. 하지만 그것을 읽는 것은 많은 목록과 참고문헌을 읽는 것을 포함한 큰 프로젝트일 것이고, 아마도 20mb의 큰 파일일 것이다. OTOH, 그것의 도입부는 4개의 잘 쓰여진 단락으로 총 340단어 밖에 되지 않는다. 우리는 그 크기의 한 기사를 전부 싣는 데 걸리는 시간에 10개의 소개를 할 수 있다. 1000엔트리의 전체 요약을 기록하는 것을 볼 수 있었지만, 전체 목록의 전체 기사를 기록하는 것은 위압적이고 지루해 보인다. 그리고 모든 특집 기사들. 또는 연사와 관련된 어떤 주제에 관한 모든 기사들. 그리고 파일들은 상대적으로 작기 때문에 다운로드와 듣기가 빠를 것이다.

이것을 실행하기 위해서 우리는 프로토콜을 약간 변경해야 할 것이다. 아마도 파일 이름은 "제목_제목_(intro.ogg)" ("제목_제목_(abr.ogg)" ("제목_제목_(abr.ogg")과 같은 것일 것이다. 템플릿에는 "요약/요약/완전(pt1, pt2 등)"이라는 레이블이 붙은 추가 파일 이름이 있어야 한다. 기사 목록에 사용된 {{ternal} 태그, 요약만 있는 기사에는 회색 {{sumspoken}}을(를) 구별할 수 있는 방법을 찾고자 할 것이다. 당연히, 제안자로서 나는 그 모든 셋업 작업을 자발적으로 하고 있다. 다른 편집자들은 어떻게 생각하는가? -mcw 08:00, 2005년 5월 1일 (UTC)

이의 없는 말을 듣고 나는 이 일을 추진하겠다. 건배, -Wilmcw 21:16, 2005년 5월 3일 (UTC)

나는 이것에 대해 아무런 문제가 없다고 본다. 기사 전체를 하고 싶은 사람들을 낙담시키고 싶지는 않으니까, 어떻게 해서든 (인테로) 녹음이 존재한다고 해서 기사 전체를 다루지 말라는 뜻은 아니라는 것을 분명히 해두자, 그렇게 마음이 기울어진다면 말이다. 멀티파트 템플릿({음성 위키백과-2} 및 친구)을 검토하여 다양한 부분을 처리하는 방법에 대한 몇 가지 아이디어를 얻을 수 있다.

아, 또 하나 보고 싶지 않은 것은 기사에 나오지 않는 단어를 사용해서 패러프레이징하거나 요약하는 겁니다. 우리가 읽고 있는 기사 텍스트는 위키베트여서 발췌해도 괜찮다고 생각하지만, 예를 들어 서론만 읽음으로써, 나는 우리가 읽을 때 텍스트에 집착하는 것을 선호한다. 왜냐하면 우리의 구어 버전은 위키 텍스트보다 플라스틱이 덜하기 때문이다. 데미 _C/ 2005년 5월 4일(UTC) 18:41

글을 쓴 이후로 더 자세히 조사해 봤어. 나는 나의 무작위적인 예인 The Treativations가 유난히 좋은 소개를 가지고 있고 그렇지 않으면 완벽한 후보가 될 많은 기사들은 인트로가 매우 짧다는 것을 발견했다. 또한 2계층 시스템을 갖추는 데 따르는 복잡성은 거의 병렬 프로젝트가 필요할 것이다. 그래서 나는 덜 급하다. 그래도 계속 조사해 볼게. 나는 기사를 기록하는 것의 어려움은 그 크기에 따라 거의 기하급수적으로 증가하는 것 같다고 생각한다. 그리고 나는 우리가 기사를 단축시킬 어떤 방법을 찾을 수 있기를 바란다. '간편한 영어 위키백과'는 짧고 읽기 쉬운 기사를 가지고 있지만, 나는 누가 이것들의 구어 버전을 전체 영어 기사와 연결하는 것이 옳다고 생각할지 의심스럽다. 나는 자유형 축소를 피해야 한다는 것에 동의한다. 목록과 웹 링크를 삭제하여 줄이는 것이 더 적합할 수 있다. 로이 오비슨 기사의 절반은 그의 노래의 몇 가지 리스트를 가지고 있다. 심지어 짧은 외부 링크 목록도 읽는데 오랜 시간이 걸릴 수 있다: 때때로 그것들을 편지로 철자하는 것이 필요하다. 휴.

다른 한 가지 문제에서, 나는 특집 기사에서도 글의 질이 떨어지는 것에 대해 경외심을 느껴져 왔다. 사실들은 조사되었을지 모르지만, 문법은 때때로 고문을 당하기도 하고 심지어 기사 구조도 난잡하거나 반복될 수 있다. 산문을 소리내어 말하는 것은 정확성을 위해 단순히 대충 훑어보는 것보다 글쓰기에 대한 더 엄격한 시험이다. 그것에 대해 우리가 할 수 있는 것은 아무것도 없지만, 때로는 일정한 재필의 수단이 필요하다. 보통 이것은 런온 문장을 해체하고 유익한 사진 캡션을 통합하는 문제일 뿐이다. 어쨌든 좋은 프로젝트야, 시작해줘서 고마워. 건배, -Wilmcw 07:58, 2005년 5월 6일 (UTC)

직접 링크

오디오 파일로 직접 연결되는 링크가 있으면 좋을 것 같아. 별도의 이미지로 클릭:기사.ogg [sic] 페이지는 특히 위키백과에서 시작할 때 어색하다.추천 기사 또는 카테고리:구어 기사. 나는 또한 어떤 사람들은 구어체 아이콘을 클릭하는 것이 녹화가 아닌 그 아이콘의 이미지 페이지로 이어진다는 것을 발견하고 놀랄지도 모른다고 생각한다. 불행하게도 현재 이 두 가지 문제 중 어느 것도 해결할 방법이 없는 것 같다. - 그것은 버그로 여겨져야 하는가? 심지어 [이미지:모든 베이스는 us.ogg]에 속하며, "Image" 페이지에 대한 링크만 생성되며, 더 나쁜 것은 파일이 이미지로 처리된다는 것이다.

사운드: 또는 오디오: 네임스페이스도 있을 수 있음... 하지만 이 단계에서 정리하기가 쉽다는 것을 상상할 수 없다. ‣ᓛᑐ 06:25, 2005년 5월 4일 (UTC)[]

아, 나는 [[미디어:...] 구문을 알아차렸다. 헤, 나는 미디어: 링크가 이미지: 네임스페이스로 리디렉션된다는 것을 잊었다. 이것들의 조합이 템플릿에 사용될 수 있는가? ‣ᓛᑐᑐ 06:35, 2005년 5월 4일 (UTC)[]

미디어: 네임스페이스 링크 직접 링크, 리디렉션되지 않음 블랭크페이즈(чо blank??) 11:52, 2005년 5월 4일(UTC)[]

템플릿에서 클릭할 수 있는 직접 링크를 갖는 것이 가장 편리할 것이라는 데 동의한다. 사용자에게 파일(예: 크기 및 길이)과 "이미지" 페이지에 나타나는 다른 메타데이터를 스트리밍/다운로드하기 전에 몇 가지 추가 정보를 제공하고자 하는 것이 트레이드오프다. 이런 링크(info)가 있으면 더 좋을까? (info) 이 기사를 들어라. 그러나 (이것들이 실제로 사용되고 있는 것은 아니다), 나는 이것이 멀티파트 템플릿에 무엇을 의미하는지 잘 모르겠다. 카테고리 링크:구어 기사, 파일이 아니라 설명 페이지에 링크한 이유가 기억이 안 나. brian0918이 의견을 말할 수 있을까? 데미 _C/ 2005년 5월 4일(UTC) 18:32

데미야 동의해, 네가 제안한 이미지/인포 링크가 훨씬 나아 보여. 크레이지 18:44, 2005년 5월 4일 (UTC)

그 아이디어는 좋은 것 같다. 멀티파트의 경우, 정보 링크는 첫 번째 Image: 파일로 이동할 수 있으며, 다른 모든 부분에 대한 링크가 있을 것이다. --brian091818 18:50, 2005년 5월 4일(UTC)[]

나는 데미의 제안을 실행에 옮기고 '이 기사를 들어라'를 그 옆에 있는 '(info)'와 직접적인 연결고리로 삼았다. 만약 이의나 제안이 있다면 내가 편집한 내용을 표로 수정해줘. 크레이지 01:35, 2005년 5월 5일 (UTC)

GNU의 발음?

아마도 프로젝트 페이지는 GNU의 발음에 대한 기준이 있어야 할 것이다. 나는 그것이 'g'nu'(동물에서처럼)라고 말하도록 되어 있다고 들었으나, 나는 대부분의 사람들이 본능적으로 "gee en you"라고 한 글자씩 읽게 될 것이라고 의심한다. 사실 내가 "더 잘" 몰랐다면 아마 그럴 것이다.

어떤 발음이 가장 적합한지에 대한 어느 정도의 공감대가 있어야 하기 때문에 시작 페이지에 아무것도 추가하지 않았다.--Ejrh 05:54, 2005년 5월 6일 (UTC)[]

• GNU 프로젝트에 의하면, 「구호노」라고 한다. 하지만, 약어인 만큼 철자도 틀리지 않았다고 생각해. 나는 사람들이 그들의 기호에 따라 둘 중 하나를 선택하는 것은 괜찮다; 하지만 그들은 아마도 그것을 gnu라는 단어로 발음해서는 안 될 것이다. 데미 _C/ 2005년 5월 6일(UTC) 07:12

내 생각에 Ejrh가 맞는 것 같아, 우리는 그것을 프로젝트 페이지에 추가해야 해. 그것은 전혀 명백하지 않다. 도움이 되는 편집자가 나를 바로잡지 않았더라면 몰랐을 것이다. -윌mcw 07:34, 2005년 5월 6일 (UTC)

• 두 가지 옵션 중 하나를 가지는 것이 좋다. (그리고 "g'nu"보다 "guh-noo"가 더 강조된 것 같다;-) Willmcw.--Ejrh 13:15, 2005년 5월 6일 (UTC)[]

좀 더 과학적으로 말하면, 동물 gnu는 IPA: [njuju]라고 발음되지만, 프로젝트 GNU는 IPA: [g^ə'nuː]라고 발음된다.

템플릿

이 기사 듣기

녹음된 이후 기사가 편집되었을 수 있으므로 오디오 파일이 오래되었을 수 있다는 점에 유의하십시오. (도움말 필요)

위키프로젝트 구어 위키백과

나는 전체 너비의 템플릿을 보고 있었는데, 그것은 약간 크고, 때로는 다른 사람들과 함께 쌓을 때 잘 재생되지 않는다(예를 들어 이 버전의 카이사르 암호의 하단 참조). 위키키호테가 사용하는 것과 같은 인터위키 링크와 좀 더 비슷한 것은 어떠세요? 또한, 템플릿에 있는 프로젝트 링크 하나면 충분하다고 생각했다(그래서 /Info를 선택했다). 여기 내가 그런 시도를 한 것이 있다. 데미 _C/ 2005년 4월 16일(UTC) 00:40

나도 동의해. — Matt Crypto 00:59, 2005년 4월 16일 (UTC)

이것을 여기에 두었기 때문에, 템플릿에서 가장 중요한 아이템으로 상단에 "듣기" 링크를 두었다. 그러나, 토론하는 동안 [[사용자:]를 얼마든지 편집하십시오.데미/말씀]]을(를) 개선한다. 데미 _C/ 2005년 4월 16일(UTC) 01:27

나는 이 템플릿에 대해 몇 가지 제안된 변경을 했다. 어느 쪽이든 (이러한 변경사항이 있든 없든) 나는 이 템플릿이 현재 우리가 가지고 있는 수평 막대보다 더 좋다. 교체할까? 빨리 할수록 기존 기사의 태그를 옮기는 작업이 줄어들 것이다. — Timwi 12:27, 2005년 4월 18일 (UTC)

이의가 없는 것 같으니 그대로 진행해서 할 생각이다. 데미 _C/ 2005년 4월 18일(UTC) 19:36

템플릿 및 mediwiki 업그레이드 관련 문제: Robert_Oppenheimer 기사를 보면 구어 wiki 템플릿이 새로운 장의 제목 역할을 하며 다음 장을 모두 하위 장으로 나열하는 것을 볼 수 있다. 이거 고칠 줄 아는 사람 있어? (사용자의 서명되지 않은 주석:CGP) 맙소사, 우리가 그 물건을 구현하자마자 개발자들이 가서 망쳐버린다! 버질라한테 보고하러 갈 거야. — 카멜레온 2005년 6월 28일 11:39 (UTC)

그게 꼭 필요한 건지 모르겠네, h1 대신 div, span 또는 p를 사용할 수도 있을 것 같아. 내가 내 감시 목록을 뒤져봤을 때 한번 해 볼게. 조 D(t) 2005년 6월 28일 12:09 (UTC)

a로 바꿨다. div내가 생각하기에 고칠 수 있을 것 같아 그러나 스타일시트를 변경해야 한다. — 카멜레온 2005년 6월 28일 13:17 (UTC)

OK, 스타일시트가 다음 태그가 가능하도록 변경되었다. H1그러나, 우리는 유지 보수 안내문 또한 위에 있을 때 안내문이 잘못된 장소에 있다는 문제를 여전히 가지고 있다. 나는 Bugzilla에서 물어봤고, 그들은 나를 cs 위키피디아에 소개했는데, 그들은 그들의 템플릿 중 하나에 다음과 같은 코드(이 코드 때문에 약간 엇갈리게 된다)를 사용한다.

<div id="geocoord"><p class="geocord">>마피: [http://kvaleberg.com/extensions/mapsources/index.php?params={{1}} {{{2}}]</p></div> 

#geocord { position: 절대, z-index: 1; 경계: none, 배경: none, 오른쪽: 12㎛, 위쪽: -3.7em, 너비: 45em, float: 오른쪽, 여백: 0, 패딩: 0, 줄 바꿈: 1.5em, 오른쪽, 텍스트-index: 85%; 공백: non, } 

#geocord a[href ^="noss://"] {배경: url(http://upload.wikimedia.org/wikipedia/de/d/d4/Gnome-globe.png) center right no-message; pading-right: 18:; !중요; } 

나는 이제 이것을 실행했다. 효과가 있는 것 같다. 카발 멤버가 모노북 스타일시트를 바꿔주길 기다리는 중이야. — 카멜레온 2005년 6월 30일 12:14 (UTC)

완료된 녹화표

여기 녹음할 때마다 메타데이터가 많기 때문에 테이블이 읽기 쉽고 보기 좋다는 Matt Crypto의 말에 동의한다. 나도 그것이 부피가 크다는 Timwi의 말에 동의해. 식탁을 불룩하게 하기 위해 몇 가지 일을 했다.

• 나는 이 노트에 대한 두 번째 줄이 있는 대신에 복사기 통지가 없는 녹음들을 위해 "질문 GNU" 아이콘을 추가했다.
• {{}}}{{{{}}}에서처럼 모든 아이콘을 16px로 줄였다.FA} 템플릿. 내 생각에 그들은 여전히 알아볼 수 있을 것 같지만 이 정도 크기의 테이블 행은 늘리지 않는다.
• 나는 테이블 헤딩을 수정해서 테이블 헤딩이 일반적으로 한 줄에 맞도록 했다.

데미 _C/ 2005년 4월 17일 (UTC)

물론, 축소된 버전은 여전히 나에게 좋다 — Timwi, 이것은 이제 충분히 분해된 것인가? — Matt Crypto 01:34, 2005년 4월 18일 (UTC)

네, 수고하셨습니다. — Timwi 11:56, 2005년 4월 18일 (UTC)

더 좋은 생각?

IRC의 한 관계자는 "최고의" 텍스트 음성 변환 소프트웨어 또한 무료였고, 서버 역할을 할 수 있는 능력을 가지고 있다고 주장했다. 그것은 축제라고 불린다. 소프트웨어는 어떤 목적으로든 무료일 뿐만 아니라, 목소리도 무료다. 사용자 자신의 텍스트를 입력할 수 있는 데모 페이지 예를 참조하십시오. 이제, 우리가 그들의 서버에 기사의 현재 내용만 제출하면 분명히 좋은 평가를 받지 못할 것이기 때문에, 가장 좋은 방법은 Festival 서버를 주최하고 문제의 기사의 수정된 텍스트 버전을 만들 수 있는 별도의 자매 프로젝트를 만드는 것일 수도 있다. 사람들은 수동으로 기사를 듣고 본문을 미세 조정해야 할 것이다(예: 상승하는 것을 호밀 징으로 대체하는 것) 하지만, 이것은 구어 위키피디아를 확장하는 훨씬 빠른 방법이 될 것이다. 우리는 여전히 개인에게 그들 자신의 녹음 파일을 제출할 수 있는 선택권을 제공할 수 있지만, 만약 이것이 이륙할 예정이라면, 특히 그것이 무료일 때 음성인식이 더 나은 방법인 것 같다. --brian0918™ 22:30, 2005년 4월 17일 (UTC)

또한, 데모 페이지에서 가장 명확한 음성은 bdl_arctic_hts인 것 같다.

이것은 또한 원본 기사가 변경될 때 구어 기사 내용을 업데이트하는 것을 훨씬 더 쉽게 만들 것이다.

meta를 참조하십시오.Talk:Wikishound 내가 같은 제안을 하고 있는 곳. --brian0918™ 22:38, 2005년 4월 17일 (UTC)

• 나는 축제를 이용해 본 적이 있다. 짧은 흐릿함치고는 꽤 괜찮은 것 같다. 텍스트의 긴 부분에 대해서는, 덜 그렇다. 어떤 경우라도(위에서 다룬 점을 반복하기 위해), 서버 측에서 이 작업을 하는 효용성은 보이지 않는데, 이는 이미 사용자가, 당신이 지적하는 바와 같이, 무료 소프트웨어를 사용할 수 있기 때문이다(하지만, Festival은 내 운영 체제를 위해 구축되지 않기 때문에, 나는 할 수 없다는 것도 알고 있다). 하지만 그건 내 생각일 뿐이야. 내가 널 막지 못하게 해. 한 프로젝트가 어떻게 다른 프로젝트를 방해하는지 모르겠으니, 축제의 문자 음성 변환 시스템으로 기사를 처리하고 그 결과를 게시하는 것은 어떨까? 데미^T/_C00:19, 2005년 4월 18일(UTC)
  • 나는 실제로 그것을 편찬해 본 적이 없다. 나는 그들의 데모 페이지를 사용하고, 오디오 프로그램에 함께 붙여넣을 시간에 청크를 인코딩하고 있다. 너도 똑같이 해볼 수 있어. --brian0918™ 00:32, 2005년 4월 18일 (UTC)
• 방금 녹음된 음성으로 데모를 확인했는데..AT&T에 비하면 상당히 안 좋은 것 같다. 〇 Reisio 04:04, 2005년 6월 23일 (UTC)
• 페스티발은 정말로 놀라운 스피치 신디사이저다. 음브롤라 같은 것보다 훨씬 더 많은 메모리를 사용하고 시작하는데 더 오랜 시간이 걸리지만 여전히 끔찍하게 들린다. 스피치 신디사이저의 또 다른 문제는 누군가가 스피치 신디사이저가 읽어야 할 내용만을 나타내기 위해 기사의 본문을 편집해야 한다는 것이다. 이 과정은 아마 내가 직접 기사를 읽는 것보다 더 오래 걸릴 것이다. 다니엘홀트 2005년 7월 2일 18:59(UTC)

배치 및 이름 지정

이 녹음들은 하원에 있어서는 안 되는 것인가? 또한 다른 가능한 파일과 충돌하지 않도록 더 모호한 파일 이름이 있을 수 없었다. 아마도 "Wordered - [Canonical name.ogg"? --Oldak Quill 23:46, 2005년 4월 17일 (UTC)

• 그들은 영어에 특화된 것들이라서, 나는 그들이 그렇게 해야 할 지 잘 모르겠어. 당신이 제안하는 것과 같은 어떤 이름을 생각해 보았으나, 단지 기사_name.ogg가 "전부, 들을 수 있게"를 의미한다고 생각하지 않는 경우가 많지 않다고 생각했다. 또 댓글 있는 사람? 데미^T/_C00:21, 2005년 4월 18일(UTC)
  • 물론 이것에 대해 생각해 보았지만, 파일들이 영어에 특화된 것일 뿐만 아니라 위키백과에도 특화된 것이다. 사실 영어 위키백과 기사에 이보다 더 구체적인 것은 얻을 수 없다! :-) 그래서 나는 영어 위키백과에 그 기사들이 있어야 한다고 생각한다. — Timwi 11:56, 2005년 4월 18일 (UTC)
• 인정해야겠는데, 처음 특정인의 링크를 봤을 때 '이 사람에 의한 무엇인가'라는 뜻인 줄 알았고, 기사만 읽고 있는 것을 발견하고는 다소 실망했다. --Fastfission 03:39, 2005년 4월 20일(UTC)
  • 템플릿의 화신 중 하나는 "누군가가 이 기사를 읽는 것을 들어라."라고 되어 있었지만, 나는 그때 구어 템플릿이 전체 너비였을 때라고 생각한다. 그것은 추했다. 컴팩트함을 위해 우리는 템플릿을 다듬어 왔다. 나는 오디오 파일이 구성되었을 때 어떻게 더 명확하게 해야 할지 모르겠다. 데미 _C/ 2005년 4월 21일(UTC) 18:48

나는 그것들이 영어 위키피디아에 특정되어 있지만 다른 특정한 사운드 파일들이 있기 때문에 공용화되어야 한다고 생각한다. 그러나, 일본 사용자가 볼리비아의 라 페즈 커먼즈 페이지를 검색하다가 파일을 보게 되면, 2개 국어를 할 줄 알고 그 파일을 우연히 보게 되면, 그렌 07:06, 2005년 5월 18일 (UTC)[]

나는 너에게 공통점을 지적하고 싶다.범주:구어 위키백과 - 아직 많이 없지만, 그래서 내가 여기 있는 것이다;) 구어 기사는 언어를 배우는 데 좋은 자료이기 때문에 공용어여야 한다고 믿는다. 또한, 일부 위키피디아에서는 이미 모든 업로드를 공유에 강제하고 있으며, 기술적 도움, 공통 템플릿 등을 위해 오디오 노력에 대한 중앙 조정 지점을 갖는 것이 좋은 생각일 수 있다. G. Gearloose (??) (일명 공용:User:duesentrieb) 12:31, 2005년 5월 29일 (UTC)[]

그것은 모두 하원에 맡겨져야 한다. 또한, 하원에 업로드된 영어로 된 모든 녹음은 _(영어)로 접미하여 공유 간에 충돌이 없도록 해야 한다.이미지:트리케트라_(영어).ogg 및 공용과 같은 미래 버전:이미지:트리케트라_(프란차이).ogg, 커먼즈:이미지:트리케트라_(이탈리아노).오그 등 — 카멜레온 12:44, 2005년 5월 29일(UTC)[]

트라이케트라의 독서는 "en:하원에서 트라이켓라.ogg. 즉, 결국, 영어 위키백과 기사를 하원에서 연결하기 위한 정식 명칭이다. dbenn talk 15:25, 2005년 6월 10일 (UTC)

만약 여러분이 오디오를 공유지에 올리고 싶다면 -- 네, 제 생각엔 -- 하지만 내가 위키피디아에 갔을 때, 사용하기 쉬운 "업로드 파일" 링크가 보인다. 일반인들은 업로드가 그렇게 명백하게 되지 않는다. 2005년 6월 26일 대니얼홀 20장 11절

"참조" vs "컨설팅"

시각장애인들에게 절대 PC가 되려면 "또한 보라"가 아닌 "컨설팅"이라고 말해야 할지도 모르겠다. --brian0918™ 23:14, 2005년 4월 19일 (UTC)

좋은 생각이야, 나도 동의해. 그때마다 이상하게 보였다고 말했다. -Willmcw 23:21, 2005년 4월 19일 (UTC)

내 생각에 그건 좀 너무 PC같다. "보기"의 한 가지 통용되는 의미는 "이해하기 위해" 또는 "자문을 위해" 입니다. -- 타퀸 21:37, 2005년 6월 25일 (UTC)

PCness를 통한 동의를 얻으십시오. 참조(Verb)를 참조하십시오. 대안을 제시하려면 길이가 같거나 짧아야 한다. --CGP 28 2005년 6월 19:15 (UTC)

나는 "Wipedia 내의 추가 읽기는 ...을 보고 카테고리는 ..."을 사용하고, 외부 링크 부분은 "Wipedia 외부의 추가 읽기는 ..."로 사용하고 있다. Joe D (t) 2005년 6월 28일 19:19 (UTC)

위키백과 스타일 매뉴얼에는 "관련 주제"를 "참고" 대신 사용할 수 있다고 명시되어 있다. Epolk 16:39, 2005년 8월 16일 (UTC)

기사 맨 위에 링크?

이것은 장황하게 들릴지 모르지만, 페이지 상단에 있는 사운드 파일에 대한 링크를 가질 수 있을까? 단지 사용자들은 그들이 바닥에 도달할 때까지 구어 버전이 이용 가능하다는 것을 깨닫지 못할 수도 있다(어느 때, 그들은 어쨌든 그 기사를 읽었을 것이다). # 크레이지 ♫ 2005년 5월 7일 00:45 (UTC)

그래, 꼭대기에 어떤 종류의 링크가 있을 거야. — 카멜레온 17:55, 2005년 5월 27일 (UTC)[]

응, 나도 동의해. 쉽게 접근할 수 있도록 링크를 상단에 배치하는 것이 이치에 맞는다. — Peter McGinley 11:07, 2005년 6월 11일 (UTC)

스페인 프로젝트가 이런 일을 한다는 것을 방금 알았다(ES: 참조).시가로라). 기사 제목 오른쪽에 바로 연결되려면 소프트웨어 변경이 필요하겠지만, 스페인 위키백과에서처럼 바로 아래, 오른쪽으로 연결하면 된다. 아무도 반대하지 않는다면, 나는 이 변화를 시행할 것이다. — 카멜레온 11시 15분, 2005년 6월 12일 (UTC)

스페인어 표식을 템플릿에 복사해 두었다.구어 위키백과 테스트는 단지 테스트하기 위해 영국의 앤에 배치했다. 다른 사용자가 만족한다면 템플릿에 복사하십시오.구어 위키백과에서 그렇게 보관한다. 다만 파일이 언제 만들어졌는지에 대한 정보가 없고 이후 편집 내용이 담겨 있지 않다는 점이다. 이것이 문제가 될까? 크레이지 (토크) 2005년 6월 23일 00:26 (UTC)

나는 http://bugzilla.wikimedia.org/show_bug.cgi?id=2528에서 개선 요청을 제출했어. — 카멜레온 13:09, 2005년 6월 26일 (UTC)

CSS로 이미 할 수 있기 때문에 무효로 닫았다. 예를 들어 베트남어 위키백과가 한 일을 보십시오. —ævar Arnfjörð Bjarmason 13:20, 2005년 6월 26일 (UTC)

고마워, 나는 약간의 css를 추가해 달라고 요청했고, 곧 템플릿이 준비될 거야. 조 D(t) 13:56, 2005년 6월 26일 (UTC)

{{MedicedTop 파일 이름}}}. 그들이 바로 작업을 시작하지 않으면, 이 페이지를 새로 고쳐야 할 것이다. 고마워, 제바와 스모디 조 D(t) 14:05, 2005년 6월 26일 (UTC)

나는 아직 코딩을 시행하지 않을 것이다. 클래식(mediawiki:standard.css), 쾰른 블루(mediawiki:cologneblue.css), 향수(mediawiki:nostalgia.css)에 대한 디자인이 필요하여 모든 피부에 올바르게 보일 수 있다. 네가 필요한 코딩이 뭔지 말해주면 내가 구현할게. 하지만 이것은 모노북을 사용하지 않는 소수자들에게는 그 순간 이상해 보일 것이다. smoddy 14:21, 2005년 6월 26일 (UTC)

아니, 문제 없어. 베트남어 위키백과에서 그들이 어떻게 하는지 살펴봤는데 그들이 하는 일은 '스타일='디스플레이:없음''을 덧붙이는 것이다. 이것으로 디스플레이를 다시 켜는 피부를 사용하지 않는 사람은 눈에 보이지 않는다. 이것은 우리가 이 템플릿을 모든 기사에 안전하게 추가할 수 있다는 것을 의미한다. 아무것도 표시되지 않을 것이다. 링크를 보려면 개인 스킨을 편집하십시오(예: 사용자:카멜레온/모노북.css)을 볼 수 있도록 한다. 그런 다음 표준 스킨에 추가할 수 있다. 그렇게 되면 숨겨진 텍스트가 마술처럼 모든 사람의 화면에 아름답고 정확하게 나타날 것이다. 그 동안 우리는 다른 템플릿은 각 기사의 맨 아래에 보관할 수 있다. 녹화가 오래되었을 수 있음을 선언하는 통지가 여전히 중요하기 때문에 이것은 완전히 중복되는 것은 아니다. — 카멜레온 14:40, 2005년 6월 26일 (UTC)

음, 알았어. 그러나 다른 스킨으로 원하는 곳을 정리하면 어떤 관리자라도 정확하게 보이게 할 수 있다. smoddy 14:43, 2005년 6월 26일(UTC)

카멜레온에 따르면, 그러나 나는 클래식 스킨에 대한 코드를 분류했다. (미디어위키:Standard.css:

h1#worded { display: block!중요, bound-bott-style: none, float: right, font-size: 150%; position: 절대, 2%; top: 7.5em; } 

MediaWiki:쾰른블루.css:

h1#worded { display: block!중요, bound-bott-style: none, float: right, font-size: 150%; position: 절대, 2%; top: 10.5em; } 

MediaWiki:향수.css:

h1#worded { display: block!중요, bound-bott-style: none, float: right, font-size: 150%; position: 절대, 36em, top: 1.5em; } 

조 D (t) 14:42, 2005년 6월 26일 (UTC)

지금 이 순간, 나는 다음과 같이 말하고 있다.

파일:CojonesAndmedScreensshot.png

여기서 말했어야 했는데: {{MedicedTop}}}은(는) 두 개의 템플릿을 사용할 필요가 없고, 기존 기사를 갱신할 필요가 없도록 하기 위해 {{Mediced Wikipedia}}에 추가했기 때문에 지금은 실제로 필요한 것이 아니다. 링크를 잘못된 위치에 배치하고 있는 것으로 보인다(Position은 [2] 참조, 위치는 Opera가 표시한다). 당신의 브라우저는 베트남어 위키백과에서도 같은 일을 하는가? 조 D (t) 15:03, 2005년 6월 26일 (UTC)

나는 XP Pro에서 Firefox 1.0.4를 사용하고 있는데, 스크린샷과 같이 나온다. 방금 IE에서 해봤는데, 파이어폭스처럼 생겼어. 오페라에서는 아무것도 전시되지 않는다. 베트남어 위키피디아는 모든 브라우저에 완벽하게 표시된다. — 카멜레온 15:16, 2005년 6월 26일 (UTC)

내가 바뀌면 display: block !important; 로 display: inline !important;좀 나아진 것 같다.

파일:CojonesAndmedScreenshot2.png

— 카멜레온 15:25, 2005년 6월 26일 (UTC)

뭔지 알겠다. 클래식한 피부를 위해 고안된 코드를 사용자:Camelleon/monobook.css, 클래식한 피부를 위한 최적의 위치에 배치하고 있지만 모노북은 해당 코드를 User:카멜레온/모노북.css를 새로 고치고 다음 두 가지를 새로 고치십시오. [3] [4], 잘 보이기를 바라며(같은 브라우저를 사용하는 다른 사람들도 기본적으로 볼 수 있을 것이다.) 조 D (t) 15:27, 2005년 6월 26일 (UTC)

아, 그걸 덧붙여야 한다고 생각했어, 그렇지 않으면 보이지 않을 거야. 그러나 지금 나는 스모디가 스타일시트를 편집했다는 것을 알았다. 카발 멤버가 우리 편이라서 좋다! — 카멜레온 15:41, 2005년 6월 26일 (UTC)

추가해야 할까? noprint 템플릿에 클래스를 맞추시겠습니까? — 카멜레온 16:01, 2005년 6월 26일 (UTC)

좋아, 내가 추가했어. {{Andled__에 상단도 추가했다.위키백과-2, {{Anyword_위키백과-3}, {{음성_위키백과-4} 및 {{Ampressed_위키백과-5}. — 카멜레온 17:06, 2005년 6월 26일(UTC)

모든 것이 정말 깔끔해 보여, 나는 먼저 모든 구어 위키백과 템플릿에 class=plainlink를 추가했다. 이게 네 목적에 부합하고 버그 2528이 필요 없을 거라고 생각해? —ævar Arnfjörð Bjarmason 17:57, 2005년 6월 26일 (UTC)

무슨 상관인지 모르겠다. class=plainlinks하지만 이제 알겠다:

파일:NotherScreensshot.png — 카멜레온 18:18, 2005년 6월 26일(UTC)

왜 그런지 이 차이를 보라. 사이트 공지가 올라갔기 때문에 페이지 윗부분이 약간 아래로 내려간다. 사이트 공지 사항 올라오는 동안 코드에 코멘트를 하겠다. smoddy 18:31, 2005년 6월 26일(UTC)

나만 그런 거야, 아니면 새 버전이 파이어폭스에 안 뜨는 거야? 오페라와 IE에서는 잘 작동하고, 로그인하거나 로그아웃을 했지만, 파이어폭스에서는 전혀 작동하지 않는다. 조 D (t) 2005년 6월 28일 13:08 (UTC)

오늘 보니 누군가 구어체 상자를 구어체 기사 밑바닥으로 옮기고 있다. 그러나 나의 mozilla firefox 브라우저에서 o) 이 기사를 듣는 것은 기사의 상자 밖에 있다! 읽을 수 있는 기사 제목 옆에 있는 대신, 그것은 탭 옆에 있는 페이지의 파란색 배경과 '나의 기여물 로그아웃' 아래에 있다. 이것은 기사가 아닌 페이지의 일부분에 놓여있기 때문에 매우 성가시다. 항상 '내 감시 목록'을 클릭하지 않는 보통 사람들은 기사 제목 오른쪽 아래까지 모든 것을 읽고 나머지 페이지를 무시할 것이다. 다니엘홀트 2005년 7월 2일 18:57 (UTC)

그래 나도 파이어폭스를 사용하고 있는데 다니엘도 마찬가지야. 예전처럼 기사 제목 옆에 붙이는 게 적절할 것 같은데 벌레가 든 것 같아. 나는 우리가 버그를 고치는 사람들에게 많은 것을 요구했다는 것을 알지만, 구어 링크가 기사의 제목 옆에 놓일 수 있는 것이 가능할까? - 누구라도? 크레이지 (대화) 2005년 7월 2일 19:01 (UTC)

어제 저녁부터 오페라에서 템플릿, css, 템플릿 위치가 바뀌지 않았지만, 이 템플릿에서 벗어나야 해서 하루 동안 무시했다. 그러다가 오늘 제대로 나타나기 시작했는데 글자 크기가 150%인데 다 포기했어. 조 D (t) 2005년 7월 2일 19:10 (UTC)

방금 프로젝트에 합류했어!

오늘 프로젝트에서 우연히 만나 합류할 줄 알았어. 나는 모든 사람들이 듣고 의견을 제시할 수 있도록 내 목소리의 샘플을 녹음할 것이다. 하지만 마이크를 구매해야 할 것 같아.

오, 그리고 내가 어디에 있는지 궁금해하는 사람들에게, 나는 호주 멜버른에서 왔어. - 피터 맥긴리 11:06, 2005년 6월 11일 (UTC)

나도 이 일을 하고 싶다.

이봐, 난 16살이고 캘리포니아 출신이야. 필요하다면 이 프로젝트에 관한 기사를 녹음해두면 좋겠어. 나는 마이크가 있어서 음성 샘플을 제공할 수 있어. 기회가 되면 내 토크 페이지에 글을 남겨줘 - 고마워! -그릭()^{talk to me!} 04:54, 2005년 6월 16일 (UTC)

RSS 피드

URL로 가입할 수 있는 /rss에서 RSS 피드를 가지고 놀고 있다.

http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_Spoken_Wikipedia/rss&action=raw

녹음 연령별로 주문된 구어 기사 목록이 있으면 일이 쉬워지겠지만, 나는 그것을 최신 상태로 유지하려고 노력할 것이다. 프로젝트 1면에 어디에 링크를 달아야 할지 모르겠어. 조 D (t) 21:53, 2005년 6월 17일 (UTC)

다른 RSS 피드

http://dingoskidneys.com/~dholth/medwikipedia.xml은 업로드 날짜별로 자동으로 생성된 음성 미디어 오더 목록이다. 팟캐스트 클라이언트가 구독할 수 있도록 인클로저 포함(정보). Wikimedia Commons 미디어는 그 메타데이터를 위해 위키피디아를 탐색하는 것이 약간 더 복잡하기 때문에 현재 정확한 날짜가 정해지지 않았다; 모든 파일들은 RSS의 하단에 나열되어 있다.

이 프로그램 http://dingoskidneys.com/~dholth/spokenwikipedia.py은 카테고리:에서 시작하는 위키백과를 크롤링한다.구어 기사, 그 페이지 하단의 갤러리를 기반으로 한 미디어 목록 작성. 이 RSS는 구어 매체의 포괄적인 목록이 아니며, 단지 (분명히) 가장 최근의 75개 목록일 뿐이다. 대략 매일 피드를 업데이트하고 있어

그 목록의 총 인클로저 크기는 약 450MB이다.

참고: HTML의 날짜 형식은 내 스크립트를 깨는 방식으로 변경되어 피드가 더 이상 업데이트되지 않는다. 대안은 실제 위키 역사와 위키 마크업 다니엘을 구문 분석하는 것일 수도 있다.홀 06:40, 2005년 7월 17일 (UTC)[]

템플릿 배치

구어 기사에 대한 빠른 조사는 템플릿이 아래쪽에 있는 반랜덤 장소에 놓여 있다는 것을 보여준다. 나는 그것을 See 또한 섹션, Fore reading, External links, 그리고 "바로 맨 아래에"에서 발견했다. 어떤 식으로든 일관된 선호 배치가 있어야 한다. -- Cyrius ✎ 00:46, 2005년 6월 18일 (UTC)

내 표는 "목차 오른쪽"으로 간다. 밑바닥은 바보같아, 그때는 이미 늦었어! Joe D (t) 00:59, 2005년 6월 18일 (UTC)

지푸라기라도 걸읍시다. 만약 과반수가 그것을 상위에 원하면, 나는 그것을 실행하겠다. — 카멜레온 21:11, 2005년 6월 22일 (UTC)

톱

1. — 카멜레온 21:11, 2005년 6월 22일 (UTC)
2. 페니스 06:16, 2005년 6월 23일 (UTC)
3. --Dubaduba 08:15, 2005년 6월 23일 (UTC)
4. Joe D (t) 새로운 템플릿으로 나는 더 이상 이것이 중요하다고 생각하지 않는다.
5. Timwi 16:08, 2005년 6월 23일 (UTC)

밑단

구현

좋아, 상단으로 템플릿을 옮기기 전에, 우리는 그것이 어떻게 보일지에 대해 동의해야 해. 꼭대기에는 공간이 별로 없고, 특히 택스옥스, 이미지 등이 있다. 어떡하지 — 카멜레온 19:28, 2005년 6월 23일 (UTC)

맥 문제

내 Mac(OS 10.3.9)에서는 이러한 기사를 들을 수 없고, 페이지에 나열된 Mac용 애플리케이션을 다운로드하면 시스템이 이를 처리하는 방법을 모른다. 이 오디오 페이지를 맥 사용자들이 그렇게 많이 만지작거릴 필요가 없도록 .ogg 말고 들을 수 있는 방법은 없을까? 아니면 나만 그런가? SlimVirgin 06:43, 2005년 6월 19일(UTC)

• iTunes에 .ogg 지원을 추가하는 방법에 대한 튜토리얼은 이 문서를 참조하십시오. BLACKFAZE (чоо??) 12:01, 2005년 6월 19일 (UTC)

안녕 블랭크페이즈, 고마워. 나는 다른 앱들과 같은 반응을 얻고 있다: 기사는 그것을 Quicktime 라이브러리에 넣으라고 하지만, 내가 그것을 할 때, 나는 Quicktime 라이브러리는 수정할 수 없다는 메시지를 받는다. 페이지에 있는 다른 모든 앱들도 마찬가지야: 내 시스템은 그것을 어떻게 다루어야 할지 모른다고 말하고 있어. 그냥 궁금해서 나 자신은 상관없지만 오디오 페이지가 필요하고 맥을 사용하는 사람들은 많이 만지작거려야 한다고 생각하고 있다. SlimVirgin^(talk) 12:11, 2005년 6월 19일(UTC)

WinAmp, Windows Media Player 등에서 OGG Vorbis 파일을 재생하는 데 문제가 없지만 iTunes도 이러한 파일을 재생할 수 없다. MP3를 재생할 수 있지만 내가 그런 파일을 열면 OGG Vorbis만 무시한다. 또한 패치를 설치하려고 할 때 해당 패치를 무시한다(설치 방법에 대한 정보가 있는 것은 아님). — 카멜레온 12:46, 2005년 6월 19일 (UTC)

iTunes, Quicktime Player, Mac용 Windows Media Player를 사용해 보았다. 처음 두 사람은 og 파일이 인식되지 않는다고 했고, 미디어 플레이어는 og 파일이 잘못된 형식이라고 말했다. 패치는 시스템에서 인식하지 못하는 동일한 응답을 얻는다. SlimVirgin^(talk) 12:52, 2005년 6월 19일(UTC)

아하. Windows Media Player(PC에서 XP를 사용하고 있다)는 포맷을 인식하지 못한다고 불평하지만, 어쨌든 재생한다(아마도 K-lite 코덱 팩이 설치되어 있기 때문일 것이다). iTunes에서 패치를 열려고 하거나, 패치의 OGG Vorbis 파일을 열려고 하면 전혀 아무 일도 일어나지 않는다. Mac을 가지고 있는 사람 또 있니? — 카멜레온 13:03, 2005년 6월 19일 (UTC)

GNU 라이선스

나는 말하기 위키 프로젝트에 기여하는 것에 흥미가 있지만 시작하기 전에 한 가지 질문이 있다. GNU 문서 라이센스에 따라 파일에 라이센스를 부여할 필요가 있는가? 또는 cc-by와 같은 크리에이티브 커먼스 프리 라이센스(예: cc-by)가 허용될 것인가? --CGP 17:54, 2005년 6월 23일(UTC)

• 그것들도 괜찮을 거야. --brian091818 19:14, 2005년 6월 23일 (UTC)

확실합니까? 만약 본문이 GFDL이라면, 확실히 이와 같은 파생상품도 마찬가지일 것이다. Joe D (t) 19:22, 2005년 6월 23일 (UTC)

그렇다, 나는 구어 기사는 오직 당신이 텍스트 기사의 유일한 기여자가 아니라면 GFDL에만 있을 수 있다고 99% 확신한다. 이것은 유감스러운 일이다. 왜냐하면 GFDL은 오디오에 끔찍하기 때문이다. 신경 쓰지 마. — 카멜레온 19:27, 2005년 6월 23일 (UTC)

나는 GFDL이 오디오에 이상적인 솔루션이라고 생각하지 않기 때문에 물어본 것이다. 마지막에는 이렇게 말하면서 "이 글의 오디오 녹음은 GFDL에 따라 면허가 있는 동안 창조적 공유 귀속 2.0 면허에 따라 면허가 있다"고 말할 수 있을까, 아니면 이런 종류의 상호작용이 문제를 일으킬까? --CGP 20:06, 2005년 6월 23일 (UTC)

어느 쪽이든, 이중 라이선스가 있든 없든 저작권 상황은 끔찍하다: (Joe D (t) 20:16, 2005년 6월 23일 (UTC)

한편, GFDL에 대한 사람이 읽을 수 있는 요약본은 어디에도 있는가? 실제 본문을 통해 읽으면 어떤 것이 있고 어떤 것이 그것에 의해 요구되는지 명확하게 이해할 수 없다는 것을 인정해야겠다. --CGP 06:26, 2005년 6월 24일 (UTC)

인간이 읽을 수 있는 버전에 가장 가까운 것은 GFDL. — 카멜레온 15:48, 2005년 6월 26일 (UTC)

측정 및 수치

자전거 녹음할까 생각 중이야. 숫자 데이터 읽기에 대한 규약이 아직 있니? 평균 시속 30km의 사이클 선수가 시속 약 1890kJ(450칼로리), 즉 킬로미터당 약 63kJ(15칼로리)를 태운다 같은 문장은 끔찍하게 들릴 것이다. 둘 중 하나를 생각하고 있다.

• 비응축 측정값 삭제
• 평균 시속 30km의 사이클 선수(좋은 주행 속도)는 시속 1890kJ(즉, 450칼로리) 정도 탄다.

그 단락의 문장들은 훨씬 더 재미있어진다!

비금속 단위를 떨어뜨린다는 개념에는 찬성하지만, 이와 같은 기사를 읽는 방법에 대한 아이디어도 찾고 있다...모든 표 :\ --CGP 17:47, 2005년 6월 26일 (UTC)

요소의 경우 첫 번째 문장이나 단락을 읽은 후 요소 상자를 통과하여 각 항목을 읽어 보십시오. 수소를 사용하는 방법 예:

"수소(라틴어:수소, 그리스어: 수력: 물, 유전자: 형성)는 주기율표에 H와 원자 번호 1을 가진 화학원소다.

"화학계열 <일시정지> 비금속"

"그룹 <일시정지> 1"

"주기 <일시정지> 1"

"블록 <일시정지> s"

(등)

또는 텍스트 전체를 스캔하여 텍스트에서 이미 다루어진 항목을 표에 표시한 다음 요소 상자에서 다루지 않은 항목을 읽을 수 있다.

Epolk 18:10, 2005년 8월 15일 (UTC)

제목 및 확장 섹션 링크

이 정책은 링크를 텍스트로 읽는 것이지만 "기본 문서: 자전거 브레이크 시스템"? 예를 들어 "이 섹션의 확장 버전이 자전거 브레이크 시스템이라는 제목의 기사에 수록되어 있다"와 같은 내용을 읽어야 하는가? 그리고 그나저나 독서 제목에 대한 규약이 있는가? 제목만 잠깐 멈칫하면서 말하는 겁니까? -- 타퀸 21:44, 2005년 6월 25일 (UTC)

나는 개인적으로 그것이 괜찮아 보인다고 말할 것이다. (확장된 글과 일시 중지된 제목에 대해 이야기하면서) 아마도 "이 섹션에 대한 자세한 정보는 bla bla를 참조하십시오"와 같은 것? - Jacen Aratan 21:55, 2005년 6월 25일(UTC)

나는 줄곧 그것을 "제목"이라고 읽고 있다. 이 절은 기사 <하위조항>의 요약본이다. 다른 제안들도 똑같이 좋은 것 같지만. 조 D (t) 08:55, 2005년 6월 26일 (UTC)

대담성

이 프로젝트는 (기고자가) 좀 부진해서, 일을 성사시키기 위해 대담하게 프로젝트 페이지를 몇 번 수정해 보았다. 아무도 신경 쓰지 않았으면 좋겠다. — 카멜레온 11:35, 2005년 6월 26일 (UTC)

치어리더

우리를 동기부여를 시키는 대로 해

나는 이 리스트를 프로젝트 페이지에서 옮겨 놓았다. 그것은 그 프로젝트에 대한 진지한 실질적인 정보의 목록이라기보다는 오히려 "대화"에 가깝다, 그렇게 생각하지 않는가? — 카멜레온 11:40, 2005년 6월 26일 (UTC)

• Matt Crypto — 이 프로젝트의 열렬한 팬이지만, 내 목소리는 녹음하기에 너무 약해!
• 스파키 제7차 혼돈 – 아이디어를 사랑하지만, 아아, 나는 녹음 장비가 없다. 언젠가는 그럴지도 모르지.
• 대니 — 내가 만화 더빙을 감독했었기 때문에, 나는 이것이 놀라운 프로젝트라고 생각한다. 불행히도 내 목소리는 별로지만 참여해주시는 모든 분들께 감사드린다.
• 스머디 - 정말 멋진 생각이지만, 내가 녹음하는 것은 아무것도 없는 것만큼 나쁠 것이다. (아마도 상당히 더 나쁠 것이다.)
• Merovingian — 이것은 좋은 생각이지만, 나는 10대 목소리를 가지고 있다.
  • 하지만 더 좋아! 그렇게 하면 우리 녹음의 생동감이 더 높아질 거야! :-) 한번 해봐야 할 것 같은데 :-) — Timwi 11:49, 2005년 5월 2일 (UTC)[]
• 혀짤배기 냄새가 난다. 중립성^talk 23:53, 2005년 5월 1일 (UTC)
  • 당신은 리스를 위해 샘플을 기록하기를 원할지도 모른다. 그것은 텍스트보다 개념을 훨씬 더 잘 보여줄 것이다. 그레그 롭슨 13:32, 2005년 5월 3일 (UTC)[]
• 쉽게 중독됨 — 이 참을 수 없는 축농증을 빨리 제거하고 싶어...
• 에르지키 (에리나케우스 아무렌시스)—프로젝트를 좋아하지만 온화하지만 짜증나는 말투 때문에 참여할 수 없다. 그래도 계속 열심히 해라!
• 에쿠르 - 희, 좋은 생각이야!
• Golbez - 세상에, 위키피디아는 계속해서 나를 놀라게 한다. 잘했어!
• Gkhan - 세상에, 너희들이 통치한다! 나도 돕고 싶지만, 악센트가 있고 녹음이 안 되는 것 같아.
• 헤르미온느1980 — 자, 여러분! 나도 돕고 싶지만 내 마이크에서 냄새가 나고 네가 들어본 미국 남부 억양 중 최악이야.
  • 더 좋은 마이크는 그리 많지 않고, 나는 많은 다른 억양들을 표현하고 싶다. 나는 네가 다시 생각해 보기를 바란다. 데미^T/_C20:09, 2005년 5월 21일(UTC)
    • 아마도 내가 대학을 졸업하고 학자금 융자를 다 갚은 후에… 헤르미온느1980 15:48, 2005년 5월 22일 (UTC)[]
• 헤들리. 지오르디 억양.
• 디벤벤의 나도 참여하고 싶다. 아마도 마이크를...
• 땅, 와우, 대박. 언젠가 기사를 녹음해 볼 수도 있을 것 같아 (30달러짜리 마이크를 가지고 있고, 오디오시티로 약간의 실험을 해 본 적이 있어...)
• Jacen Aratan – 멋진 아이디어, 그리고 내가 그것을 위한 장비를 가지고 있는 동안... 영어를 모국어로 쓰는 사람은 아니다. 아마도 덴마크의 일반적인 문구들을 위해서일 것이다.

소개 전용 기록

우리가 기사에 대한 소개만을 녹음하는 것을 막아야 한다고 생각하는 사람이 또 있을까? 도입부만 녹음하면 훨씬 더 적은 사람들에게 유용하게 쓰이고, 이상적인 누군가가 언젠가는 모든 것을 기록하게 될 것이기 때문에 결국 헛수고를 하게 된다. 조 D (t) 2005년 6월 28일 19:13 (UTC)

인트로 녹음은 내게 나쁜 생각처럼 들린다. — 카멜레온 2005년 6월 28일 19:27 (UTC)

동의함, 비록 나는 여전히 제한적인 축소를 지지하겠지만 --CGP 2005년 6월 28일 19:32 (UTC)

동의하지 않습니다. 50만개의 기사가 있다. 짧은 기사보다 긴 기사를 녹음하는 것이 실질적으로 어렵기 때문에 나는 녹음을 줄였다. 짤막한 기사 목록이나 요약된 기사 목록이 있다면 더 할 것이다. 요약된 많은 녹음에 문제가 있었는가? 건배, -Willmcw 2005년 6월 28일 20:26 (UTC)

더 긴 기사에 대한 소개를 녹음한 누군가가 "녹음 없이 짧은 녹음을 해주시길 바란다"고 말한다. 인쇄된 백과사전의 마법의 일부는 지하실에서 읽고 새로운 주제를 발견하는 것이다. 왜냐하면 그것들은 또한 "Ca-Co" 책 등에 실려 있기 때문이다. 팟캐스트 백과사전을 오디오로 소개하면 사람들이 새로운 주제에 관심을 가질 수 있고, 만약 그들이 그것을 충분히 흥미롭게 발견한다면 그들은 와서 읽었을 것이다. 긴 물건을 생산하는 것은 실제로 더 어렵다. 나는 구어 위키피디아에서 그것들을 들음으로써 내가 찾지 못했을 것들에 대해 확실히 배웠고, 그리고 나서 다시 돌아와서 갤버스턴 허리케인, 영국 기대치에 대해 더 많이 읽게 되었다. (그 기사들은 이야기를 들려주기 때문에, 이야기를 들려주는 기사들의 목록들이 잠재 독자들에게 좋을 것이기 때문에 구어에는 아주 좋다.) 또한 나는 많은 하위 섹션이 있는 분야별 기사를 보고 싶다. 각 섹션이 다른 목소리로 읽히기를 원한다. 다니엘홀스 2005년 6월 30일 05:47 (UTC)g

나는 인트로만 가지는 것을 단념하는 경향이 있다. -- Arwel 28 2005년 6월 20:30 (UTC)

실험

방금 이미지 업로드:Firewall Music.ogg를 실험으로 사용했지만, 어떤 반응에 따라 제거해야 할지도 모르기 때문에 기사와 연결되지는 않는다! 짧은 고전음악을 기사의 배경으로 사용하는 것이 공정하다고 주장할 수 있을 텐데(서곡의 시작이다) 이것을 음악 주제에 관한 기사에 대한 가능한 취급으로 어떻게 생각하십니까? -- 2005년 6월 28일 20:30 (UTC)

빌어먹을, 그 글에서 빨리 읽나, 나는 이 경우에 음악을 배경으로 하는 것이 마음에 든다고 말해야겠어. --CGP 6월 28일, 2005년 6월 20:51 (UTC)

원본 파일은 아직 가지고 있니? 스피치 트랙에서 "속도 변경" 옵션을 사용해서 속도를 늦춰야 한다고 생각해. — 카멜레온 2005년 6월 28일 21:29 (UTC)

파일들을 가지고 좀 놀아볼게 - 이 파일에서는 좀 빨리 말하긴 하지만, 물론 내가 천천히 말하면 더 많은 음악을 들을 수 있어! :) -- Arwel 28 2005년 6월 21일:44 (UTC)

확인 - 이미지 시도:Firewall Music 3.ogg - 이것이 오늘밤 내가 시도할 마지막 편집이다! -- Arwel 28 2005년 6월 22일:17 (UTC)

독자를 위한 건설적 피드백

나는 단지 이 프로젝트의 기여자들을 위해 건설적인 피드백 시스템/페이지를 구현하는 것이 실현 가능한지 궁금했을 뿐이다. RSS 피드를 통해 올라오면서 기사들을 듣고 있었고 녹음과 판독의 질이 고르지 못하다. 어떤 사람들은 그 프로젝트에 부적절한 목소리를 내는 반면 다른 사람들은 기술적인 어려움을 겪는 것 같다. 질 나쁜 녹음을 많이 하는 것은 프로젝트에 좋지 않은 영향을 미칠 것이고, 텍스트로 할 수 있는 것처럼 녹음을 점진적으로 개선할 수 없기 때문에, 나는 피드백이 절대적으로 중요하다고 생각한다. 개인별 토크페이지에서 가능하겠지만 좀 더 체계적인 것을 바라고 있었다. --CGP 2005년 6월 28일 20:30 (UTC)

혹시 파일의 대화 페이지를 사용하시겠습니까? 조 D (t) 2005년 6월 28일 20:58 (UTC)

프로젝트의 외부 소프트웨어

나는 현재 이 생각 페이지에서 시각장애인을 위한 복합 팟캐스트와 구어 위키백과 소프트웨어를 만들 가능성에 대해 고민하고 있다. 소프트웨어 개발자와 RNIB 기술 담당자들에게 살펴보기 전에 먼저 상담을 시작하겠다. 조 D (t) 2005년 6월 28일 22:07 (UTC)

구어 템플릿 배치

이제 기사 상단에 구어 버전으로 자동 링크가 있다. 이제 시각적으로 방해하는 템플릿을 기사 하단으로 옮길 수 있을까? – 플라무라이 (t) 2005년 6월 29일 17:51 (UTC)

예. Joe D(t) 2005년 6월 29일 18:07 (UTC)

나는 그것을 천천히 해오고 있다. — 카멜레온 2005년 6월 29일 18:25 (UTC)

자바 애플릿?

오그/보비스 게임을 할 수 있는 자바 애플릿이 있다. 애플릿 포함이 가능하다면 자바를 가지고 있지만 오그/보비스 플레이어가 없는 사람들은 들을 수 있었다. (사용자의 서명되지 않은 주석:다니엘 홀스 — 카멜레온 2005년 6월 29일 18:53 (UTC)

그건 개발자들과 상의해 봐야 할 겁니다. — 카멜레온 2005년 6월 29일 18:53 (UTC)

템플릿에 revid를 추가하시겠습니까?

현재 버전의 아티클에 revid(oldid)가 있는 경우 템플릿에 revid/oldid를 추가하는 것에 대해 어떻게 생각하십니까? – ABCD 2005년 6월 29일 19:11(UTC)

구어체는 구어판과 현재판 사이의 차이점에 대한 링크와 함께 토크 페이지 템플릿에 있어야 기사를 다시 읽을 만한 가치가 있는지 알 수 있을 것 같다. 그러나 주 네임스페이스 템플릿은 가능한 한 단순하게 유지해야 한다. IMO. Joe D (t) 2005년 6월 29일 19:20 (UTC)

사람들은 자신의 업로드를 설명하는 현재의 템플릿에 어려움을 겪고 있는 것 같다. 더 복잡하게 만들려고? 나는 의심이 든다. 나는 대부분의 오디오가 Oggvorbis에 태그가 없다는 것을 알았다. 사용자가 제공하는 '녹음된 날짜'는 형식에 따라 다르며, 사용자는 '재생 시간'과 '바이트'와 같은 것들을 지정해야 한다. 메타 데이터를 양방향으로 채울 봇이 있어야 한다. 사용자 개입 없이 실제 미디어의 바이트와 재생 시간을 무해하게 가져갈 수 있으며, 감독으로 파일에 Ogg/vorbis 태그를 추가할 수 있다. 다니엘홀스 2005년 6월 30일 05:34 (UTC)