위키낱말사전 미래

"위키데이터:위키데이터:위키낱말사전 및 위키데이터/참고 사항/미래도 참조하세요."

이 페이지는 위키낱말사전의 미래를 위한 아이디어를 모으는 것을 목표로합니다. 실제로 위키데이터의 도입으로 많은 가능성이 나타납니다. 더욱이, 오메가위키(OmegaWiki)를 채택하겠다는 제안은 중복되는 목표를 가진 프로젝트에 대한 현재의 흥분을 더하고 있습니다.

목표는 먼저 각 프로젝트의 특성과 겹치는 부분을 공개하는 것입니다. 그런 다음 중복되지 않는 목표를 전달하고 중복된 방식으로 자원을 낭비하지 않는 방법에 대한 제안을 논의 할 수 있습니다. 마지막으로, 이 페이지는 위키낱말사전에 관한 장기 계획을 제시하고 토론하는 데 사용되어야합니다.

이 페이지의 구성

이 페이지가 유용한 방식으로 성장하도록 돕기 위해 권고 구조가 제안되었습니다. 물론 토론 페이지에서 문서를 구성하기 위해 자신의 아이디어를 공유할 수 있습니다.

각 제안 섹션은 다음 형식으로 "제안" 아래에 있어야합니다:

제안 제목

주제에 대한 힌트를 제공하는 레벨2 섹션 (===).

제목 요약

제안에 대한 매우 간단한 설명을 제공하는 레벨3 섹션 (====).

제목 현재 상황

현재 상황의 단점을 설명하는 레벨3 섹션 (====).

권장되는 개선 사항 제목

레벨4 (=====)의 자막을 사용하여이를 설명하는 레벨3 섹션 (====).

제안서에 대한 제목 의견

레벨3 섹션 (====), 처음에는 비어 있고 다른 사람에 의해 채워집니다.

다음은 틀입니다:

=== 제안 제목 ===

<span id="Abstract"></span>
==== 요약 ==== 

<span id="Current_Situation"></span>
==== 현재 상황 ====

<span id="Recommended_improvement"></span>
==== 권장 개선 ====

==== 제안에 대한 의견 ====

제안

위키낱말사전 프로젝트에 대한 정보 수집

요약

위키낱말사전의 미래를 위한 적절한 권장 사항을 작성하려면 먼저 최첨단 작업을 실현해야합니다. 문서는 다음에 대한 요약 및 참조를 제공해야합니다:

• 위키낱말사전: 초기 목표 및 구현 선택.
• 위키낱말사전의 현재 상태: 각 장에서 기사가 구성되는 방식의 유사점 및 차이점.
• 오메가위키 및 시맨틱 미디어위키와 같은 관련 프로젝트 목록: 위키낱말사전에서 나온 이유는 하나의 프로젝트로 통합 할 수있는 목표와 위키낱말사전의 목표입니다.
• 더 구조화 된 위키낱말사전의 장단점은 무엇일까요? 분명히 구조는 지부 간 자동 피드백에 도움이 될 수 있습니다. 그러나 다른 한편으로 미디어위키 프로젝트에서 가장 중요한 부분은 커뮤니티입니다. 지부 간 구조를 사용하면, 특히 일부 지역의 기존 특이성이 해당 구조에서 불가능해지면 통제력 상실로 인해 잠재적인 공동체 불만이 제기될 수 있습니다. 이러한 상황을 방지하는 방법을 조사해야합니다: 광범위한 피드백 캠페인, 유연한 구조 등..

현재 상황

알려져 있는 한, 그러한 보고서는 아직 존재하지 않습니다.

권장 개선

보고서를 작성해야하며 멘토링 프로젝트 아이디어로 제안 할 수 있습니다.

예상 사용량 목록 작성

요약

데이터를 구조화하는 방법에 따라 특정 용도를 완화하거나 강화합니다. 따라서 예상되는 용도 목록이 있으면 쉽게 사용할 수있는 구조를 설계하는 데 도움이 됩니다. 물론, 상상할 수있는 미래의 모든 용도를 추측하는 것은 불가능하지만 적어도 지금 잡을 수 있는 모든 아이디어를 고려하면 도움이 될 것입니다.

현재 상황

문서와 데이터베이스 덤프에서 구조화 된 정보를 추출하는 것은 매우 어려울 수 있습니다. 그 내용은 위키낱말사전 html 페이지 생성에만 초점을 맞추고 때로는 위키미디어 엔진 외부에서는 거의 해석할 수 없는 틀에 크게 의존하기 때문입니다.

권장 개선

위키낱말사전 콘텐츠의 다른 사용 사례를 나열하고 이를 완화하기 위한 요구 사항에 도달합니다.

위키낱말사전 데이터 모델 개선

요약

위키 방식은 대부분 프로를 증명했지만 코인은 여전히 남아 있지만 공동체는 예를 들어 위키데이터 이니셔티브와 같은 일부 요소의 구조화 및 공통 데이터의 중앙 집중화를 통해 기꺼이 극복하려고 합니다.

현재 상황

위키낱말사전의 각 언어 버전에는 데이터를 구조화하는 고유한 방법이 있으므로 번역과 발음 및 동의어와 반문과 같은 단어 관계와 같은 공통 데이터를 공유하기가 더 어렵습니다.

권장 개선

모든 위키낱말사전 기여자를 위키낱말사전 항목의 글로벌 구조화에 참여 시키세요. 구조화된 데이터를 확장하는 정의된 방법을 통해 각 공동체가 필요한 특수성을 계속 개발하면서 글로벌 교차 버전 협업 작업에서 좋은 행위자로 남을 수 있습니다.

• 위키낱말사전이 쉽게 사용할 수있는 용도 정의
• 위키낱말사전 항목 정의:
  • 필수 데이터
  • 데이터가 불안정한 지 알려주는 방법
    • 항목과 관련이 없음
    • 기여가 필요합니다
    • (여기에 다른 아이디어 입력)
• (다른 아이디어 추가)

위키낱말사전에 대한 작업과 토론

위키데이터의 위키낱말사전 지원에 관한 위키마니아 2013 회의

위키마니아 2013에서 위키데이터의 위키낱말사전 지원에 관한 회의가 조직되었습니다. 다음 행사 중 메모가 작성되었으며 온라인에서 교차 목록 토론이 함께 진행되었습니다.

11:30-13:00, Y520 호실 참석자: 미크루(Micru), Aude, Nikerabbit, Duesentrieb, Jaing Bian, 데니(Denny), Chorobek, Linda Lin, Amgine (스카이프 사용), 스트렙로(Stepro), 버티고(Vertigo) (스카이프 사용), Nirakka, 비이크(GWicke), Max Klein

• 미크루는 여러 가지 데이터 모델을 제시합니다.
  • 여러 위키낱말사전
  • 오메가 위키
  • 워드넷(WordNet)
  • 레몬 모델
  • 디비피디아(DBpedia) 위키낱말사전
• 데니의 말: 이 회의의 아이디어는 아무것도 결정하지 않고 토론을 논의하고 이동하는 것입니다. 이것은 분명히 위키낱말사전에 대해 결정하기에 적합한 사람들이 아닙니다. 우리의 주요 목표는 우리 자신의 어휘 자원을 만드는 것이 아니라 위키낱말사전을 지원하는 것입니다.
• Amgine의 말: 위키낱말사전의 인터위키 링크 설정은 다소 복잡합니다. 단어/어휘와 개념의 차이. 감각, 어휘, 정의에 관한 용어 질문...
• 스트렙로의 말:구조화 된 편집을 편집 할 수있는 간단한 양식 기반 사용자 인터페이스를 갖기 위해 모든 언어로 제공되는 구조화 된 데이터, 위키낱말사전 회의일 수도 있지만 어떻게 시작해야할까요?
• 데니: 위키데이터가 회의에 초대하면 날아 가지 않을까 걱정. 독일어 위키낱말사전은 이런 종류의 구조화 된 데이터를 원합니다. 독일어 위키낱말사전의 테슈투베(Teestube), 영어의 맥주 가게(Beer parlor) 및 그리스 핏(Grease Pit), 하루 중 다른 시간에 영어를 위한 IRC 채널. 더욱 영어 위키낱말사전에는 기술적으로 기울이는 위키낱말사전을 위한 "그리스 핏"이라는 공통 대화 영역이 있습니다.
• 버티고의 말: 이거 미리 먹어 보면 좋을 텐데
• (데니) 문제는 우리가 무엇을 개발해야하는지 알아야한다는 것입니다. 나중에 변경하면 비용이 많이 듭니다.
• (미크루) 어쩌면 모의?
  • (버티고) 실물 모형(mock up)은 아주 좋은 아이디어입니다.
• 스트렙로의 말: 첫 번째 위키낱말사전 회의는 올해 였고 다음 회의는 아마도 봄에 있을 것입니다.
• 비이크의 말: 파소이드(Parsoid)는 위키텍스트의 구문 분석을 수행합니다. 자바스크립트를 통해 틀 및 틀 블록 가져 오기. 위키낱말사전이 시각편집기에 대한 특별한 요구 사항이 있는 경우 가브리엘 비이크(Gabriel Wicke)에게 문의하세요. parsoid.wmflabs.org에서 사용 가능한 첫 번째 데모.
• 비이크의 말: en.WT에서 편집기 특수 문자를 보셨나요? 확장 또는 가젯입니까?

구조화되고 제안서에 병합되어야하는 기여

데니의 질문

저에게 있어서 여기 제안은 약간 진보 된 것입니다. 먼저 약간의 배경 지식을 수집하고 싶습니다. 함께 모을 수 있다면 대단히 감사하겠습니다.

아래 페이지에는 데이터 모델 아이디어와 사용 사례 및 요구 사항이 혼합되어 있습니다. 이 페이지를 분류하고 다른 지점으로 나누어 사용 사례와 기타 요구 사항 및 데이터 모델을 논의하는 것이 좋습니다. 데이터 모델의 경우 오메가위키의 기존 데이터 모델, 2~3개의 성공적인 위키낱말사전, 워드넷(WordNet), 버브넷(VerbNet) 및 프레임넷(FrameNet)에 대한 간단한 설명을 보고 싶습니다. 이러한 배경은 데이터 모델을 구축하는 데 매우 유용합니다.

이 사이트를 적절하게 준비하고 토론을 구성하고 싶은 사람이 있나요? --denny (토론) 2013년 4월 3일 10:28 (UTC)

의견

좋은 제안이지만, 우리는 그들에게 도달하기 위한 도구(위키데이터와 오메가위키, 워드넷, 벌브넷 등)에 대해 생각하기 "전에" 대상 설명이 필요하다고 생각합니다. 저는 WT 프로젝트의 WT 비즈니스 모델을 모르고 "여기에 제시된 제안의 대상, 비즈니스 모델?" 이라는 제목을 추가하기 "이전"에 아래에 (스케치) 제안을 했습니다. 하나가 있나요? 어디서 찾을 수 있나요? 먼 미래에 이르는 장기적인 개발을 위해 정말 열려 있나요? 장기 목표를 알면 좋은 제안을 하고 그 (상상) 가치를 더 잘 평가할 수 있습니다. 그러나 이것은 제안을 구성하는 방법에 대한 여러분의 질문에 대답하지 않습니다. 저는 단기, 중기, 장기를 제안합니다. 일부 중장기 제안은 전제 조건으로 많은 단기 제안이 필요할 수 있습니다. NoX (토론) 2013년 4월 3일 17:38 (UTC)

저는 오메가위키와 위키낱말사전, 워드넷 등의 데이터 모델을 도구로 간주하지 않습니다. 저는 그것들을 수십 년의 경험이 흘러 들어 오는 분명히 관련된 작업으로 간주합니다. 이미 몇 가지 좋은 현실 테스트를 거친 기존 데이터 모델을 명시적으로 설명하지 않고 새 데이터 모델을 구성하는 것은 주어진 분야에서 천재가 아니거나 경험이 많지 않다고 가정할 때 잠재적인 시간 낭비처럼 보입니다. 그래서 저는 여전히 제 요청을 고수합니다. 완전히 새로운 모델을 소개하기 전에 최소한 몇 가지 위키낱말사전과 오메가위키 및 워드넷의 기존 데이터 모델을 먼저 설명하겠습니다. --denny (토론) 2013년 4월 4일 11:14 (UTC)

여기에 제시된 제안의 대상, 비즈니스 모델?

여기에 제안을 추가하는 것은 스스로에게 다음과 같은 질문을 제기해야합니다: "제 제안으로 누가 혜택을 받나요?"

• 제 잠재 고객, 제 제안의 최종 사용자는 누구인가요?
• 그 뒤에 있는 비즈니스 모델은 무엇인가요?
• 윈-윈 상황으로 이어질 것인가
  • 나를 위해 (나만을 위해?),
  • 전세계 WT 프로젝트의 경우,
  • 전 세계 (희망적으로 확장되는) 사용자 그룹: 사용자 읽기, 사용자 기여 또는 (매우 필수적인) 사용자 기부?

여기서 윈-윈 상황은 두 당사자, 즉 WT 프로젝트 자체와 사용자간에 존재할 수 있습니다.

WT 사용자

WT 프로젝트는 광범위한 사용자의 진정한 요구를 충족하고 현재 및 미래의 이 사용자 그룹(언어 관련)의 요구를 충족하는 방향으로 정확하게 평가하고 계속 발전할 경우에만 장기적으로 번창 할 것입니다.

이 사용자 그룹은 WT의 품질이 높고 사용 편의성이 증가하는 경우(이해하기 쉽고 기여하기 쉬운 경우)에만 비용을 지불(기부 형태로, WT 인프라에 절대적으로 필요하며, 지속되는 광고를 통해 기부를 하지 않기를 바랍니다)할 의향이 있습니다.

이것은 모든 비즈니스에서 제기되는 질문으로 이어집니다. WT 프로젝트 사용자(전 세계)는 누구입니까?

저는 개인적으로 다음 사용자 그룹을 설정합니다.

1. 단일어 WT 사용자
2. 다국어 WT 사용자.
3. WT 데이터 빨판: WT에서 데이터를 빨아들이는 경쟁자.

처음 두 그룹 내에서 일반 사용자(단순히 단어 검색, 외국어 학습)와 언어 전문가(번역가, 언어를 공부한 사람들)를 구별해야 합니다. 확실히 일반 사용자는 더 큰 사용자 기반입니다. 일반 사용자의 작은 부분이 기여할 수 있습니다. 더 쉽게 WT를 사용할 수 있습니다. 더 많은 (대량) 입력을 생성할 수 있습니다. WT 프로젝트는 언어 전문가의 요구도 충족해야 합니다. 언어 전문가의 관심사가 일반 사용자의 관심사와 일치하나요? 제 생각에는: 아닙니다. 하지만 그들은 좋은 방식으로 공존할 수 있습니다. 언어 전문가는 일반 사용자의 실제 요구 사항을 이해하고 있나요? "가끔 내 감정은 : '아니요' 입니다".

"좋은 제안의 실제적이고 일반적인 이점"을 추정하기 위한 이러한 사용자 기반의 규모는 얼마인가요?

NoX (토론) 2013년 3월 29일 12:22 (UTC)

개선 된 위키낱말사전 데이터 모델 제안

NoX: 제안 철회.

"이유"

1. 이 제안은 병렬로 실행되는 모든 것(예를 들어, 오메가위키와, 위키데이터 등)을 자세히 알지 못하는 일반적인 교차 WT 사용자(위의 "여기에 제시된 ..." 참조)의 사용 요구를 반영하여 위키낱말사전, 특히 위키낱말사전에 대한 "보통의 일반인"의 관점에서 수행되었습니다.
2. "위키낱말사전 데이터 모델의 개선"은 적절한 제목이 아닙니다. 현재 WT의 "번역과 번역 예"에 대한 부족과 결함이 주요 원인이었습니다. 이러한 결점은 오메가위키에 의해 명확하게 식별되고 제가 제안한 방식(구조화된 데이터)으로 처리되지만 "실현 방식"은 저에게 합리적이지 않은 것 같습니다(두 개의 다른 언어 세계).
3. 하나의 제안이 아니라 "하나뿐인 WT 세계"를 대상으로 하는 여러 제안입니다.
4. 하향식 목표(위의 "여기에 제시된 ..." 참조)를 모르는 "상향식 제안"입니다.

그래서 저는 여전히 모든 제안(일부는 조금 다른 관점에서, 일부는 추가로) 뒤에 서서 더 나은 방법을 찾고 있습니다. NoX (토론) 2013년 4월 6일 20:31 (UTC)

요약: "다음 제안은 내부의 위키낱말사전 데이터 구조를 개선하는 것을 목표로 합니다. 현재 대부분의 텍스트 및 마크업 기반 구조는 데이터 콘텐츠의 품질이 다소 우발적이지만 실제 장기 요구 사항을 나타내는 더 적절하고 이해하기 쉽고 사용 가능한 데이터 모델로 단계적으로 이동해야 합니다. 주제. 보기는 위키낱말사전 사용자의 보기입니다. 목표는 로드맵이 아니라 설명되어 있습니다."

현재: 하나의 위키낱말사전 프로젝트에는 m개의 위키낱말사전이 포함되어 있습니다. (m = many, 많은). 각 위키 사전에는 m개의 위키가 포함되어 있습니다. 각 위키는 마크업과 혼합된 텍스트를 포함하는 하나의 텍스트 블록을 포함합니다. 이러한 텍스트 블록 내에는 1이 포함될 수 있습니다 : 동일하거나 다른 언어의 m 단어(실제 위키낱말사전 언어일 필요는 없음). 각 단어는 단어 토큰 자체(1바이트 또는 더블 바이트 문자 문자열), 단어 유형(명사, 동사 등), 성별 및 기타 특성(있는 경우), 1을 포함할 수 있습니다 : m 발음, 1 : m 단어 의미. 0 : m (단어) 표현식, 0 : 파생어에 대한 m 참조(링크). 각 단어의 의미는 1 : m을 1로 번역 : m 언어. 각 번역에는 2개의 링크가 있습니다(프랑스어 관점). 하나는 번역된 언어의 단어를 포함하는 위키에 대한 동일한 위키낱말사전으로, 두 번째 링크는 번역된 단어가 포함된 위키에 대한 참조된 언어의 다른 위키낱말사전 프로젝트에 대한 링크입니다. 지금까지 잘 알려진 직원들에게. 함께 보기 [위키, 인터위키].

권장 사항:

위키낱말사전 프로젝트는 전세계 커뮤니케이션을 개선하는 데 큰 도움이 되는 훌륭한 세계적인 프로젝트입니다. 따라서 제시된 권장 사항은 하나의 위키낱말사전 내에서 하나의 언어에만 초점을 맞추지 않는 교차 언어 경계 사용자 사용자의 권장 사항입니다.

1. 모든 위키낱말사전에서 하나의 태그 표준, 하나의 모델 표준과 하나의 모델-시퀀스 표준 만 사용하세요.

독일어 위키낱말사전과 프랑스어 위키낱말사전 및 영어 위키낱말사전은 다른 태그와 모델 구조를 사용합니다.

예를 들어:

• (독일어) 번역 마크업: *{{fr}}: [1] {{Ü|fr|maison}} {{f}}, ''Normannisch:'' maisoun
  
• (프랑스어) 번역 마크업: * {{T|de}} : {{trad+|de|Haus}} {{n}} or * {{T|de}} : {{trad+|de|Haus|n}}
  
• (영어) 번역 마크업: * French: {{t+|fr|maison|f}}

부분적으로 마크 태그가 병렬로 존재합니다.

예: 정의된 장소의 젠더 마크업 '|f'(여성) 및 {{f}}(어디서나).

언뜻 보기에 이것은 약간 편협한 것처럼 보입니다.

이미지 1: "중복".

하지만. 태그 표준 버전을 업데이트하기 위한 도구의 생성은 용이하고 위키낱말사전의 경계를 넘어 광범위하게 사용될 수 있습니다. 표준화의 부재는 한 번만 생성된 기능의 이전을 방지합니다. 예를 들어 번역을 자동으로 업데이트하기 위해 다른 위키낱말사전으로 자동화된 데이터 전송을 개선합니다. 같은 방식으로 모든 자동화 기능은 모든 위키낱말사전에 대해 하나의 버전에서 사용될 수 있습니다.

"저는 영어 태그-, 모델- 및 모델-시퀀스 표준을 일반 표준으로 사용할 것을 제안합니다."

이 경우 마크업 언어에 대한 실제 영어 도움말 설명이 실제로 선두에 있어야 하고 또 그래야 합니다. 다른 위키낱말사전은 "번역"만 하면 됩니다. 현재(프랑스어 위키낱말사전에서) 부분적으로 열악하고 부분적으로 구식이며 접근할 수 없는 모델 설명은 기여하려는 의사는 있지만 노하우가 부족한 사용자의 광범위한 사용을 방해합니다.

2. 다른 위키낱말사전에서 중복을 피하십시오.

[NoX: 2013년 3월 28일 수정됨.]
제 생각에는 같은 언어 코드를 가진 같은 단어가 각각 위키낱말사전(WT)에 존재하는 것은 엄청난 시간과 노력의 낭비입니다.

"외국어"의 모든 단어(WT의 "호스트 언어" 제외 (예를 들어, 프랑스어 WT에서 비프랑스어 단어))는 "제거"되어야 합니다. 이미지 1에서 모든 단어를 분홍색으로 지정합니다. 제 생각에 그들은 이 언어에서 "가장 좋은 표현"으로 남용되었습니다. 그것들은 중복이며 어떤 면에서 그들의 생산은 기여하는 사용자들에게 불필요한 시간 낭비입니다. 이러한 노력은 더 나은 목적을 위해 사용될 수 있습니다. 즉, 이중 언어 번역 예제를 개선하는 것입니다.

이미지 1의 위키낱말사전 보기에서 이것은 다음을 의미합니다:

영어 [1]와 프랑스어 [2] 위키낱말사전에서 Haus는 제거되어야 합니다.

독일어와 영어 위키낱말사전에서 Maison은 제거되어야 합니다.

독일어와 프랑스어 위키낱말사전에서 house는 제거되어야 합니다

다음 장에 설명된 대로 다른 ENTITY로 대체됨 (TransEx-Entity 참조).

이것을 설명하기 위해 먼저 프랑스어에 강한 관심을 갖고 있는 모국어 영어(교차 WT 보기)인 (읽기(기여의 반대)) 사용자의 관점을 취하겠습니다. 그가 "maison"을 모르고 "house"를 나타내는 프랑스어 단어를 찾는 경우 영어 WT "house"를 사용할 수 있습니다. 번역 참조 유형 2(이미지 3 참조), "교차 해당 링크를 클릭하여 프랑스어 WT"를 검색하고 "maison"에 관한 완전하고 최상의 정보를 얻으십시오. 그가 찾은 "maison"에 관한 언어 정보는 WT 프로젝트의 기타 모든 WT에서 찾을 수 있는 "최고의 언어"라고 확신합니다. "maison"에 대한 지식을 풍부하게 하고 난 후, 그가 영어 WT에 이 단어를 추가해야 하는 이유는 무엇입니까(그가 기여하는 사용자인 경우)? 반대의 경우(프랑스어에 관심이 있는 사용자 모국어 영어)는 동일한 방식으로 작동합니다.

그래서 제 주장은 다음과 같습니다.

• "house"에 관한 최고의 (언어) 정보는 영어 WT에서 찾을 수 있습니다.
• "maison"에 관한 최고의 정보는 프랑스어 WT에서 찾을 수 있습니다.
• 독일어 WT 등에서 찾을 수 있는 "Haus"에 관한 최고의 정보.

일반적으로 특정 언어의 단어에 관한 최상의 정보는 호스트 WT(이미지 1의 파란색 단어)에서 찾을 수 있습니다. 호스트가 아닌 WT(이미지 1에서 분홍색으로 표시된 단어)에서 이러한 단어의 모든 표현은 "일반적으로 품질이 낮음"입니다.

그러나: 이것이 진실의 전부가 아님을 압니다. 실제로 이러한 분홍색 위키 단어에는 이 단어 자체에 관한 "중복" 정보(예를 들어, 발음과 성별, 편차, 활용 등)만 포함되어 있지 않습니다.

또한 다음을 제공합니다.

1. "호스트" 언어의 동의어에 대한 동의어 참조입니다.
   동의어 참조는 현재 파란색 단어보다 분홍색 단어(이미지 1) 내에서 품질이 더 좋습니다. 예를 들어 모국어 영어를 사용하는 기고자는 "메종(maison)"의 영어 동의어를 더 잘 알고 있습니다. 그러나 그가 오늘날처럼 영어 WT의 "메종"에 추가해야 하는 이유는 무엇입니까? 프랑스어 WT의 "메종" 번역을 개선하는 것이 좋지 않을까요? 이렇게 하면 파란색 단어가 동의어 참조로 사용됩니다. (저는 이것이 다른 번역 마크업 태그인 다른 WT 업데이트를 방해하는 WT 마크업의 차이점 문제에 영향을 미친다는 것을 알고 있습니다. 내 권장 사항 1: 모든 WT에서 하나의 태그 표준만 사용을 참조하세요.)
2. 정의된 이중 언어 의미/의미 맥락에서 단어 사용의 이중 언어 표현(번역 예).
   오늘날 그것들은 내 생각에 분홍색으로 된 단어가 존재하는 유일한 강력한 이유입니다(제거할 것을 제안함). 이러한 이중 언어 표현의 진정한 의미는 힌트, 도움의 손길, 단어가 (양쪽) 언어 컨텍스트에서 일반적으로 적절하게 사용되는 방법을 읽는 사용자에게 전달한다는 것입니다: 예의 형태로 다른(!?!) 언어로 번역됩니다. 이 결정적인 정보는 유지되고 살아 남아야 합니다. 저는 그것을 TransEx-Entity(번역 예제)로 옮길 것을 제안합니다. 그 내용은 프랑스어 WT의 "하우스(house)와 영어 WT의 "메종"에서 구성되어야 합니다. 쌍방적으로.

NoX (토론) 2013년 3월 28일 14:36 (UTC) (NoX)

3. 데이터 모델을 개선합니다. ID와 속성을 소개합니다.

Image 2: "데이터 모델".

일반적으로 위키낱말사전에서 사용되는 데이터 모델은 crowfoot 표현에서 ERM 다이어그램으로 표현됩니다. 데이터 "모델링"과 데이터 "표현"(사용자에게 표시되거나 편집됨)은 서로 다른 두 가지입니다.

표시된 기본 엔터티 유형은 Word입니다. 정의된 언어(위키낱말사전 언어 코드)와 단어 유형(동사, 명사 등)에서 하나의 단어를 나타내는 기본 정보만 포함해야 합니다.

데이터 모델의 의도를 이해하기 위해서는 Word(워드)의 식별자가 필요한 것 같습니다. 고유 식별자인 워드의 키는 다음 속성으로 구성되어야 합니다:

1. 단어 토큰. 모든 서체로 작성된 단어를 나타내는 1바이트 또는 2바이트 문자의 문자열입니다.
2. 언어 코드.
3. 단어 유형. 언어 코드와 관련하여 정의된 허용 가능한 단어 유형. 예를 들어 실체, 동사, 형용사 등
4. 동음이의어 토큰. 동음이의어를 식별하기 위해 모든 서체의 문자열 1바이트 또는 2바이트 문자. (동일한 단어 토큰, 동일한 언어 및 동일한 단어 유형의 단어). 일반적으로 비어 있습니다.

각 단어에는 하나 이상의 의미가 있습니다. 의미는 현재 위키에서 다음과 같이 표현됩니다.

(예 DE:) :[1] [[Unterkunft]], [[Gebäude]],

(예 FR:) # {{architecture|fr}} [[bâtiment|Bâtiment]] [[servir|servant]] de [[logis]], d’habitation, de demeure.

(예 EN:) # {{senseid|en|abode}} A structure serving as an [[abode]] of human beings..

각 의미 개체는 이 특정 의미(현재와 같이) 아래의 단어를 사용하여 하나의 의미와 하나 이상의 특징적인 문장(반복은 이미지 2에 표시되지 않음)을 포함해야 합니다. 의미는 관련성에 따라 정렬되어야 합니다.

각 의미에는 0부터 n개의 번역이 있습니다. 각 번역에는 두 개의 참조가 있습니다.

이미지 3: "번역 참조".

TransEx-Entity(이중 언어 번역 예제)를 참조하기 위해 참조 유형 1(이미지 3 참조)을 대체할 것을 제안합니다. 이것은 저에게 결정적인 변화인 것 같습니다. 참조 유형 2를 유지해야 합니다. 번역에서 참조하는 언어로 된 단어를 가리켜야 합니다.

TransEx-Entity(이중 언어 번역 예제)를 설정하면 현재 정의된 하나의 위키낱말사전에서 외국어 단어에서 만나는 모든 중복을 피할 수 있습니다. 데이터는 기술적으로 다른 언어에서 특정 단어 의미 간의 다대다 관계를 해결하는 관계 유형 엔터티입니다. 그 내용은 이중 언어입니다. 하나의 위키낱말사전에 속하지 않습니다. 두 위키낱말사전을 잇는 다리입니다.

그 내용은 어떻게 생겼나요? 예: DE: Haus의 독일어 첫 번째 의미와 FR: maison의 프랑스어 첫 번째 의미 사이의 TransEx. ((DE: maison) 및 (FR : Haus).)

Signification – Bedeutung

DE: Haus im Sinne von: [1] Unterkunft, Gebäude

FR: Maison en sens de: (Architecture) Bâtiment servant de logis, d’habitation, de demeure.

Exemples – Beispiele

FR: [1] Dans quelle maison est-ce que tu habites?

DE: In welchem Haus wohnst du?

FR: Sa maison se trouvait seule sur une colline. De là, on avait une vue sur les toits des autres maisons du village.

DE: Sein Haus stand einsam auf einem Hügel. Von dort blickte man über die Dächer der anderen Häuser der Stadt.

TransEx의 다른 모든 정보는 "피해야" 합니다. 예를 들어, 단어 유형과 성별, 발음, 번역. (DE: maison)의 독일어 예를 참조하세요. 그들은 이 곳에서 불필요하고 잉여적입니다. 이러한 정보는 다른 엔티티의 속성입니다. 대부분 엔터티 Word 자체입니다.

기타 개체: 그들은 스스로 설명하는 것 같습니다. 그들 모두가 상세하지는 않습니다.

현재 데이터 모델과 제안된 모델의 비교.

워드의 아이디.
현재 위키의 ID는 단어를 나타내는 문자열일 뿐입니다. 워드의 제안된 ID는 분리된(데이터베이스) 데이터 필드에 넣어야 하는 여러 속성으로 구성됩니다. 텍스트 마크업이 아닙니다. (이 IT 속성 중 하나가 변경되면 단어의 데이터베이스 이동 프로세스가 됩니다.)
기타 공통 속성.
그들은 잘 알려져 있고 희망적으로 표준화된 마크업을 포함하는 텍스트 컨테이너에 넣을 수 있습니다. 그러한 컨테이너는 (현재와 같이) 반복 그룹을 포함할 수도 있습니다. TransEx에서 번역된 문장 쌍. 보기, 표현, 파생어 등과 같은 개체의 경우도 마찬가지입니다. 또 다른 가능성은 이들을 별도의 데이터베이스 요소에 넣는 것입니다.
TransEx 개체.
설명된 대로 이 개체는 건너야 하는 깊고 넓은 요르단 강을 나타냅니다.

향후 발표 및 편집.

영어 스타일의 프레젠테이션을 보면 (아직 존재하지 않는 TransEx 개체 외에) 큰 차이가 없습니다.

프레젠테이션 영역에서 정말로 개선이 필요한 것 중 하나는 번역의 표시입니다. 현재 사용 가능한 롤인 롤아웃 모드는 단순한 생각인 것 같습니다. 숙련된 교차 언어 사용자는 2~3개 언어에만 관심이 있습니다. 사용자 정의 요청된 언어의 번역만 롤아웃하는 번역 언어 롤아웃 모드를 선택할 수 있어야 합니다.

앞으로의 편집 과정이 큰 도전이 될 것 같습니다. 크게 개선할 필요가 있습니다. 바람직하게는 전문가 모드를 제외하고 마크업에 대한 지식이 필요하지 않은 입력 필드를 포함하는 엔티티 구조를 지향하는 창 기반 팝업 시퀀스입니다.

제안의 장점.

1. 일반적으로 사용 가능한 하나의 데이터 구조.
2. 위키낱말사전 간의 경계가 허물어질 수 있습니다. 모든 위키낱말사전은 하나의 전세계 위키낱말사전-프로젝트 데이터 포트에 넣을 수 있습니다.
3. 하나의 일반적이고 전 세계적으로 사용 가능한 마크업 언어가 설정됩니다.
4. 기능은 한 번만 개발하면 모든 위키낱말사전에서 사용할 수 있습니다. (나는 이것이 많은 위키낱말사전 파워 유저의 사랑하는 아기들을 죽일 것이라는 것을 알고 있습니다.)
5. 자동화 절차(자동화된 콘텐츠 제어, 자동화된 워드 스텁 생성, 자동화된 번역 전송, 마크업 업그레이드 등)가 크게 개선될 수 있습니다.
6. 중복되는 단어가 없고 편집 노력이 적습니다.

제안의 단점.

1. 강한 노력이 필요합니다. TransEx 개체는 건너야 할 넓고 깊은 요르단 강입니다.
2. 단일 언어 사용자, 위키 데이터 구조에 중점을 둔 데이터베이스 전문가, 언어 전문가 및 위키낱말사전 프로젝트 데이터 표현 스타일 지침을 작성해야 하는 사람들 간에 주제 전체가 의사소통하기 어렵습니다.

NoX (토론) 2013년 3월 17일(UTC) 19:22. (NoX)

여러분 의견은?

NoX (토론) 2013년 3월 17일(UTC) 19:22. (NoX)

에이리크르(Eirikr)의 의견(및 그에 대한 답변)

• 와우. 소화할 양이 많습니다.

지금은 더 나은 데이터 이식성이라는 기본 아이디어가 좋은 아이디어라고 말할 수 있습니다.

그러나 여기에서 여러분의 제안은 실제로 통합되는 비즈니스가 없는 많은 많은 것들을 통합할 것을 요구합니다. 이러한 다양한 측면 중 많은 부분은 서로 다른 사용자 커뮤니티의 요구를 충족시키기 때문에 적어도 부분적으로 다릅니다. 예를 들어, 번역표에 사용된 위키텍스트 마크업은 각 위키낱말사전의 호스트 언어 언어를 반영합니다. DE WT는 {{Ü}}를 사용하여 "Übersetzung"을 대신합니다; FR WT는 {{t}}가 "transitionif"를 나타내는 데 사용되기 때문에 {{trad}}를 "traduction"의 약어로 사용합니다; EN WT는 FR WT와 동일한 이름 충돌이 없었기 때문에 번역을 위한 약어로 {{t}}를 사용합니다. 모든 위키낱말사전이 번역 테이블 항목에 대해 {{t}}를 사용하도록 요구하는 것은 영어 사용자를 만족시킬 수 있지만 "번역" 관련 용어가 "t"로 시작하지 않는 언어 편집자에게는 좋지 않은 니모닉(mnemonic)이 될 것입니다. 또한 {{t}}에 이미 있는 다른 기존 틀의 이름을 변경한 다음 이전 이름을 참조한 모든 항목을 살펴보고 새 이름으로 업데이트해야 합니다.

이것은 다른 사용자 커뮤니티가 보유하고 있는 문법 및 언어학에 대한 아이디어가 다르기 때문에 위키낱말사전마다 매우 다른 항목 구조를 사용하는 더 복잡한 문제를 다루기 시작하지도 않습니다. 이 제안에 대해 진지하게 생각하고 있다면 각 위키낱말사전 사용자 커뮤니티에 직접 언급하여 풀뿌리 기반 구축을 강력하게 권장합니다. 저는 여기 메타에 온 적이 거의 없으며, 여러분의 제안을 알게 된 유일한 이유는 wiktionary:Wiktionary:Beer_Parlor에 이에 대해 게시한 다른 편집자 덕분입니다. 이 게시물을 더 일찍 놓친 것은 저 혼자가 아닐 것이라고 생각합니다. -- Eiríkr Útlendi │ Tala við mig 2013년 3월 19일(UTC) 22:05.

번역된 틀에 대한 걱정은 생각만큼 큰 문제가 아니라고 생각합니다. 틀 이름이 영어로 되어 있고 각 지역 지부에서 이를 번역하는 감싸기 틀(문서와 함께)을 제공하는 "code-common"을 갖는 것은 어렵지 않을 것입니다. 그러나 나는 여러분이 커뮤니티와 함께 그러한 구조를 만드는 것이 중요하다고 생각합니다. 우리는 이 프로젝트에 대해 소통하고 전체 커뮤니티와 협력해야 하므로 모든 정기 기여자가 이에 대해 알게 되며 모든 사용 사례에 대해 충분히 유연한 구조를 만들어 현재의 특수성을 보존할 수 있도록 열성적으로 참여하게 될 것입니다. --Psychoslave (토론) 2013년 3월 22일 13:57(UTC).

• 답변: 다양한 기능에 대한 현지화된 레이블, 감싸기에 대한 아이디어는 아마도 좋은 아이디어일 것입니다. 이제 루아(Lua)가 있으므로 문제가 덜할 수 있지만 단일 루아 모듈이 한 번에 여러 번 호출될 때 편집자가 성능 문제에 직면할 수 있다는 것을 읽었습니다. 모든 위키낱말사전에 대한 모든 번역 항목 템플릿을 단일 루아 모듈로 축소하면 병목 현상이 극도로 제한될 수 있습니다. -- Eiríkr Útlendi │ Tala við mig 2013년 3월 22일 21:52(UTC).

글쎄요, 이 특정 로드 밸런싱 문제에 대한 세부 사항을 모르지만 저에게는 해결할 수 있을 것 같습니다. 간단한 솔루션은 코드를 자동으로 복제하여 중앙에서 편집 가능한 버전을 유지하지만 실행된 코드는 배포하는 것입니다. 이제 루아 모듈에 부하 균형이 실제로 있다면 이를 해결하기 위한 진지한 조사가 있어야 합니다. 그런 적절한 답변을 드릴 수 있는 기술 인프라를 제대로 표현하지 못했을 뿐인데, 해결될 수 있을 거라 믿어 의심치 않습니다. --Psychoslave (토론) 2013년 3월 23일 08:55(UTC).

• Lars와 -sche가 말한 내용이 같습니다.

@Lars, 번역 처리의 한 가지 차이점은 예를 들어 영어 위키낱말사전이 번역된 용어 항목 페이지로 바로 연결된다는 것입니다. 전체 처리는 거기에서 사용할 수 있지만 "번역" 테이블에는 없습니다.

@Nox, 여러분의 재작성, 특히 이 단락이 상당히 우려스럽습니다.

이것을 설명하기 위해 먼저 프랑스어에 강한 관심을 갖고 있는 모국어 영어(교차 WT 시각)인 (읽기(문서 작성의 반대)) 사용자의 관점을 취하겠습니다. "메종(maison)"을 모르고 "하우스(house)"를 나타내는 프랑스어 단어를 찾는 경우 영어 WT "house"를 사용하고 번역 참조 유형 2(이미지 3 참조)를 선택하고 해당 링크를 클릭하여 프랑스어 WT로 건너가 전체 및 최상의 정보를 얻을 수 있습니다. 메종에 관하여. 그가 찾은 메종에 관한 언어 정보는 WT 프로젝트의 다른 WT에서 찾을 수 있는 가장 좋은 정보라고 확신합니다. 메종에 관한 그의 지식을 풍부하게 한 후, 그가 영어 WT에 이 단어를 추가해야 하는 이유는 무엇입니까(그가 기여하는 사용자인 경우)? 반대의 경우(프랑스어에 관심이 있는 사용자 모국어 영어)는 동일한 방식으로 작동합니다.

이 가상의 영어 독자도 wiktionary:fr:maison의 프랑스어 위키낱말사전 항목을 완전히 이해할 수 있다고 가정합니다. 이것은 심각한 결함이 있는 가정입니다. Lars가 언급했듯이, 각 위키낱말사전은 호스트 언어로 작성된 호스트 언어 기여자의 수천 시간 작업을 나타냅니다.

저는 또한 적용 가능한 데이터 모델에 대한 운영상의 가정 중 일부에 대해 우려하고 있습니다. 제가 본 모든 위키낱말사전에서 항목 구조와 데이터의 유일한 공통점은 보조 정리 용어 자체와 번역, 파생 용어 및 하위 용어와 같은 목록이 있다는 것입니다. 모든 호스트 언어가 품사를 같은 방식으로 취급하는 것은 아니기 때문에 용어 분류를 위해 일반적인 품사를 가정하는 것조차 안전하지 않습니다. 예를 들어, 영어 문법학자들이 "형용사"로 생각하는 것은 대략 일본어의 적어도 세 가지 품사(形容詞 [keiyōshi], 形容動詞 [keiyōdōshi] 및 連体詞 [rentaishi])에 매핑됩니다. 일본어 문법학자가 語素(어소)로 사용하는 것은 대략 영어의 두 품사("접두사" 또는 "접미사")에 매핑됩니다. 한편, 러시아어 위키낱말사전은 이러한 표기를 완전히 포기하고 대신 각 용어의 형태를 설명하기 위해 실행 텍스트를 사용하는 것으로 보입니다. (주의: 저는 러시아 독자가 아닙니다. 이것은 제게 간접적인 정보로 제공됩니다.)

각 위키낱말사전은 호스트 언어를 사용하여 각 용어를 설명하기 때문에 러시아어 위키낱말사전에 사용된 레이블이 프랑스어 위키낱말사전에 사용된 레이블이 영어 위키낱말사전에 사용 레이블이 일본어 위키낱말사전에 사용 레이블과 일치한다는 보장이 전혀 없습니다. .. 모든 단일 주어진 용어에 대해.

저는 확실히 당신의 연구에 행운을 빕니다. 그러나 저는 이 문제가 위의 설명에서 제안한 것보다 훨씬 더 복잡하고 훨씬 더 다루기 어렵다고 생각합니다. -- Eiríkr Útlendi │ Tala við mig 2013년 3월 28일 23:59(UTC)

@Eirikr et al.: 저는 러시아어 위키낱말사전(Викисловарь)에서 꽤 많은 일을 했기 때문에 당신이 그곳에서도 그런 종류의 레이블을 찾을 수 있다고 확신할 수 있습니다. 그런데 이런 페이지만 보면 안 보이는 이유는 어디를 봐야 할지 모르기 때문입니다. 저는 이것이 모든 위키낱말사전이 하나의 큰 위키낱말사전으로 기능하기를 원한다면(그리고 매번 처음부터 시작하지 않고 많은 위키낱말사전에 기여하고 싶다면), 모든 불필요한 차이점을 잘 보여주는 문제 중 하나라고 생각합니다. 이와 같은 이니셔티브가 차이를 만들 수 있습니다.

Lars Gardenius^(diskurs) 2013년 3월 29일 09:14(UTC)

사이코슬레이브(Psychoslave)의 의견(및 그에 대한 답변)

잘했습니다. 이제 제 생각에 "단어" 개체는 현실을 반영하지 않기 때문에 단일 철자법이 없어야 합니다. 잘 알려져 있고 널리 사용되는 주문으로 자신을 제한하더라도 여러 승인을 받는 단어가 있습니다. 예를 들어 프랑스어로 "열쇠(key)"를 나타내기 위해 "clef" 또는 "clé"를 쓸 수 있습니다. 따라서 "철자"는 "의미"와 마찬가지로 다른 개체여야 하며, 한 단어는 (주어진 언어에 대해) 하나 이상의 철자를 가질 수 있습니다. 하나의 철자는 하나 이상의 단어에 해당할 수 있습니다. 또한 맞춤법은 범주화할 수 있어야 올바른 맞춤법인지, 철자가 잘못된 단어인지 또는 "모든 기반은 우리에게 속합니다"라는 표현 및 "l33t"라는 단어와 같은 특별한 것으로 간주되는지 말할 수 있습니다. 또한 명제는 어원뿐만 아니라 동의어, 상위어 등을 포함하도록 확장되어야 합니다. 어원에는 고유한 ERM 부분이 있어야 한다고 생각합니다. 왜냐하면 단어가 한 형식에서 다른 형식으로 미끄러지는 방식에 대한 잘 구조화된 스키마를 확실히 설정할 수 있기 때문입니다(저는 전문가는 아니지만 "I"가 "r"로 슬라이딩되는 것과 같이 많은 "가정" 변환에 대한 특정 어휘가 있다는 것을 알고 있습니다). --Psychoslave (토론) 2013년 3월 22일 10:41(UTC).

또한 각 철자는 예에 첨부될 수 있으며 예는 잘 정의된 참조뿐만 아니라 0 또는 m개의 번역을 가질 수 있습니다(isbn이 있는 URL/문서…). --Psychoslave (토론) 2013년 3월 22일 13:14(UTC).

• 답변: 철자법, 다른 철자는 종종 다른 의미를 내포하고 때로는 용어가 참조하는 기본 개념이 동일한 경우에도 자체 권리에서 다른 엔티티로 간주되어야 할 정도로 다릅니다. 영어 "thru"와 "through"는 하나의 개념에 대한 두 개의 다른 레이블이지만 레이블 자체는 사전에서 종종 이 두 개의 다른 철자를 별도의 항목으로 취급하는 충분히 다른 의미 정보를 전달합니다.

여러분의 프랑스어 예에서도 "clé"에 "렌치(wrench), 스패너(spanner)"의 이차적 의미가 있음을 알 수 있습니다. 이 의미는 "clef" 항목에서 누락된 것 같습니다. 의미의 이러한 차이가 유효하고 위키낱말사전 편집자의 우발적인 누락이 아니라 이 두 철자가 다른 의미론적 정보를 담고 있으며 적어도 위키낱말사전의 목적을 위해 다른 항목으로 취급될 가치가 있다고 가정합니다.

일본어는 문자 언어의 시각적인 풍부한 특성 때문에 훨씬 더 복잡해집니다. 히라가나 つく(tsuku)는 "도착하다, 켜다, 찌르다"를 의미할 수 있습니다. 한편, 한자 철자법 着く (tsuku)은 "도착하다"로 제한됩니다. 付く (tsuku)는 "켜다"로 제한됩니다. 突く (tsuku)는 "찌르다"로 제한됩니다. (간단한 예, 이 모든 항목에는 추가 의미가 있습니다.) 보다 구체적인 한자 철자를 사용할지 여부는 명료함과 중의성은 말할 것도 없고 스타일과 선호도의 문제입니다. 사용할 한자 철자는 의미 체계에 따라 다릅니다. 많은 짧은 동사의 히라가나 철자는 한자 철자와 유사한 일대다 상관 관계를 가지고 있습니다. 여기서 한자 철자는 일반적으로 히라가나 철자보다 더 구체적이며 종종 히라가나 철자가 한자 철자 바로 옆에서 일반적으로 사용됩니다.

데이터 모델은 이 모든 변동을 표면적으로 설명해야 합니다. 여기서 @Psychoslave가 제안하는 개념과 철자를 분리하는 것이 아마도 이것을 위해 필요할 것입니다. 제가 사용한 일부 상용 용어 관리 도구는 데이터 구조의 최상위 수준으로 개념을 사용합니다. 하나의 개념은 여러 용어를 가질 수 있으며 하나의 용어는 여러 개념을 가리킬 수 있습니다. 이러한 소프트웨어의 심각한 잠재적 결점 중 하나는 명확성입니다. --

• 데이터 모델 내에서 개념은 어떻게 식별됩니까?
• 개념에 동의어(예를 들어, 새 철자법)를 어떻게 추가합니까?
• 단일 용어를 볼 때 사용자에 대해 다른 개념이 어떻게 식별됩니까?
• 데이터 모델에서 "개념"으로 변환될 주어진 용어(지금 위키낱말사전에서 번호가 매겨진 정의 라인으로 구현됨)의 개별적인 의미입니까?
• 잠재적인 중복을 찾는 것과 같은 작업을 수행하기 위해 다른 "개념" 데이터 개체를 어떻게 관리합니까?
• 더 구체적인 의미가 식별될 때 의미를 여러 개의 개별 감각으로 분할하기 위해 "개념" 데이터 개체를 어떻게 관리합니까?
• 등 등.

이것은 단지 하나의 언어로 제한되는 경우에도 "엄청나게" 복잡한 문제입니다. 모든 언어를 포함하도록 문제 범위를 확장하는 것은 미친 듯이 야심차고 맛있는 도전입니다. 모두에게 행운을 빕니다!  :) -- Eiríkr Útlendi │ Tala við mig 2013년 3월 22일 21:52(UTC).

자, 가장 간단한 점(프랑스어 원어민의 관점에서)부터 시작하겠습니다. 클레프(clef)와 클레(clé)는 정확히 같은 "단어"이며 철자법만이 유일한 차이점입니다. 그들은 같은 의미를 가지고 있으며 같은 방식으로 발음합니다. 이유를 이해하려면 "w:Rectifications orthographiques du français"로 시작하면 됩니다(일부 동등한 문서는 다른 장에서 볼 수 있음). 그러나 주제와 프랑스어 특성(또는 적어도 모든 언어에서 발생하지 않을 수 있는 언어적 현상)을 모두 유지하기 위해 같은 방식으로 쓰지만 의미에 따라 다르게 발음하는 단어가 있습니다. "wikt:Catégorie:Homographes non homophones en français" 참조. 저는 각 언어마다 고유한 호기심이 있다는 데 의심의 여지가 없습니다. 따라서 실제로 우리는 여기에서 어려운 작업에 대해 이야기하고 있습니다. 다행히도(그리고 바라건대) 이 작업은 글로벌 커뮤니티(또는 원하는 경우 글로벌 커뮤니티 집합)에 의존할 수 있습니다. 아마 한 사람도 그러한 작업을 수행하는 데 필요한 시간과 경험을 감당할 수 없을 것입니다. 하지만 저는 우리가 함께 할 수 있다고 믿습니다.

"식별을 처리하는 방법"과 그 이상에 대해, 우리 데이터베이스의 고유 항목에 대한 키를 형성해야 하는 요소는 무엇입니까? 저는 개인적으로 위키오메가 기여자들의 의견에 대해 알고 싶습니다. 자신의 경험을 통해 얻은 흥미로운 분석을 공유합니다.

또한 우리는 모든 언어/커뮤니티의 특성을 고려할 수 있을 만큼 충분히 유연한 모델을 구축할 수 있도록 정보를 수집해야 하지만 구조를 동결할 만큼 충분한 정보를 수집했다고 어떻게 결정합니까? 이상적으로는 확장 가능한 기본 견고한 구조가 있어야 한다고 생각합니다. --Psychoslave (토론) 2013년 3월 23일 09:57(UTC).

NoX: 당신(사이코슬레이브, Eirikr)이 절대적으로 옳습니다. 제 ERM은 스케치일 뿐입니다. 관련 개체와 관계가 누락되었습니다. IT 데이터베이스 프로젝트에서는 "단순한" ERM으로 시작하는 것이 좋습니다. 그것의 목적은 "필요하고 관련된 것들"(개체)과 서로 간의 관계에 대해 IT 전문가와 (이 경우) 언어 전문가 간의 토론을 시작하는 것입니다. 나중에 데이터베이스 디자인 프로세스에서 특정(MS SQL-, ORACLE-, DB2-, WIKI-) 데이터베이스 및 테이블에 전혀 1:1로 매핑되지 않습니다. 예를 들어 IT 프로젝트에서 여러분의 기여는 (토론 및) 개체를 추가하여 ERM의 확장으로 이어질 것입니다(나에게 보이지 않거나 시작 프로세스를 유발하는 토론에서 제외됨). "언어 및 언어 번역"에 대한 좋은 ERM은 이 환경에서 모든 것(개체)과 관계의 오래 지속되는 본성과 본질을 반영합니다.
그러나 현재 우리의 문제는 다릅니다. 우리는 언어 영역(WT 프로젝트)의 단점과 다른 영역(예를 들어, 위키백과)의 큰 장점을 가진 다목적 위키 데이터베이스를 보유하고 있습니다. 그래서 제 생각은 현재 프랑스어 WT(영어, 독일어 및 이탈리아어 WT도 알고 있음)를 보고 ERM이 어떻게 생겼는지, 개선할 수 있는 부분이었습니다. 나는 그것을 하는 방법에 대해 아무것도 쓰지 않았습니다. 변경 사항은 진화적일 수 있습니다(저는 위키 데이터베이스 전문가가 아니기 때문에 이것이 작동할 수 있는지 확실하지 않음) 또는 혁신적일 수 있습니다. 간단히 말해서 1. 마크업을 조화시킵니다. 2. 현재 WT 내보내기 콘텐츠(예를 들어, 합의된 XML 구조로). 3. 더 나은 데이터베이스에 다시 로드합니다(다른 사람의 다음 제안 참조).

NoX (토론) 2013년 3월 24일 21:35 (UTC).

라스 가르데니우스의 의견(및 그에 대한 답변)

@NoX?: 저는 모든 위키낱말사전을 하나의 큰 위키낱말사전으로 보고 위키낱말사전 간 질문에 대한 여러분의 관심을 공유하기 때문에 여러분의 접근 방식은 기본적으로 칭찬할 만하다고 생각하지만 위의 일부 또는 여러분의 제안은 질문을 제기합니다. 제안을 너무 가혹하게 비판하기 전에 "다른 위키낱말사전에서 중복을 피하세요" 섹션에 관한 질문을 하고 싶습니다. 정확히 무엇을 의미하나요? 비교하려면: 모든 중국어 사용자가 프랑스어-중국어 사전을 버리도록 하시겠습니까? 모든 스웨덴인이 프랑스어-스웨덴어 사전 등을 버리고 모두 라루스의 프랑스어-프랑스어 사전을 사용하여 프랑스어 단어의 정확한 의미? 그것이 위키낱말사전에 대한 여러분의 생각입니까, 아니면 제가 여러분의 비전을 완전히 오해한 것입니까? Lars Gardenius^(diskurs) 2013년 3월 26일 13:21 (UTC)

NoX: 안녕하세요 라스. 저는 중복에 관한 2장을 부분적으로 다시 씁니다. 여러분의 질문에 답변이 되었기를 바랍니다. 그렇지 않은 경우 알려주세요. TransEx-Entity를 넣을 위치(WT)가 설정되어 있는 곳은 아직 답이 없습니다. NoX (토론) 2013년 3월 28일 14:46 (UTC)

"다른 위키낱말사전에서 중복 방지"의 새롭고 확장된 버전에 감사드립니다. 그러나 저는 여전히 매우 비판적이다. 저는 당신의 주도권과 접근 방식을 칭찬할 만하다고 생각한다는 것을 다시 강조하고 싶습니다. 그리고 당신이 전체로서 당신의 제안에 대한 공격으로 제가 아래에 쓰는 것을 당신이 찾지 않기를 바랍니다. 그러나 저는 당신이 그 특정 섹션에서 언어에 대한 몇 가지 매우 기본적인 사실을 간과했다고 생각합니다.
저는 제 인생의 짧은 기간 동안 전문 번역 (중국어에서)으로 일했습니다. 저는 다른 많은 사람들과 마찬가지로 영어용 옥스포드 사전, 프랑스어용 라루스사전 또는 중국어용 신화자전(新华字典)과 같은 단일 언어 사전을 최대한 빨리 사용하기 시작할 것을 권장합니다. 그 이유는 당신이 위에서 제공한 것입니다. 당신이 찾을 수 있는 가장 좋은 설명은 아마도 이런 종류의 사전에 있을 것입니다. (종이) 사전을 만드는 것은 비용이 많이 들기 때문에 이중 언어 사전에서 설명하는 공간을 제한해야 합니다.
그러나 이 권고는 따르는 것보다 주는 것이 더 쉽습니다. 예를 들어 처리할 수 있습니다. 단일어 중국어 사전, 당신은 적어도 몇 년 동안 중국어를 공부해야합니다. 모든 사람이 할 준비가 되어 있지 않은 노력입니다. 일반 사용자가 중국어로 작성된 설명을 아무리 훌륭하게 이해할 수 있다고 믿는 것은 합리적이지 않다고 생각합니다.
물론 중국어 문서(중국어 단어에 대한)를 다른 모든 언어로 번역할 것을 제안할 수 있지만 피하고 싶었던 상황으로 돌아가서 중국어에서 핀란드어, 루마니아어, 케추아어 등으로 번역할 수 있는 사람은 몇 명입니까? 최신 상태로 유지하시겠습니까?
이것이 좋은 접근 방식이 아닌 또 다른 시장 이유가 있습니다.
모든 단일 언어 사전은 사회적, 언어적 맥락에서 작성됩니다. 중국어 단일 언어 사전은 중국어의 사회적, 언어적 맥락에서 작성되었으며 설명을 제대로 이해하려면 알아야 합니다. 모든 언어는 또한 다른 문법 및 언어 문제를 해결하는 다른 방법을 가지고 있습니다. 따라서 중국어 단일 언어 사전에 전혀 언급되지 않은 것은 중국어를 모국어로 사용하는 모든 사람에게 사소한 것으로 간주되기 때문에 아마도 이해하기 매우 어렵고 사전에서 처리해야 할 필요가 있습니다. 그냥 포르투갈어로 하세요.
이것이 제가 모든 진지한 번역가가 번역할 때 모든 종류의 단일 언어, 이중 언어(양방향) 사전을 사용한다고 생각하는 이유 중 일부입니다. 스웨덴어 번역가라면 예를 들어 중국인의 관점과 스웨덴인의 관점에서 다음과 같은 단어를 설명하는 사전이 필요합니다.
따라서 전문 번역가와 일반인들도 모두 현재와 미래에 단일 언어 사전과 이중 언어 사전이 모두 필요합니다.
그렇다면 위키낱말사전의 가장 큰 문제는 이러한 사전의 이중 언어 부분에 있음이 분명하다는 것 또한 말해야 합니다. 예를 들어 중국어-루마니아어 위키를 만들고 싶다면 최소한 10명의 사람이 몇 년 동안 작업해야 허용 가능한 수준의 품질과 사용성에 도달할 수 있습니다. 이 수의 사람들은 분명히 종종 부족합니다. 그러나 이러한 이중 언어 부분을 버리는 것은 문제를 해결하는 것이 아니라 숨기는 것입니다.
이 문제는 문서의 번역 부분에도 부분적으로 연결되어 있다고 생각합니다. 번역에 할당된 공간은 매우 작습니다(모든 위키낱말사전에서). 저는 한때 일반 (종이) 사전과 비교했습니다. 그들이 독일어 단어를 (특정 언어로) 번역하는 데 40줄을 할애한 반면, 위키낱말사전은 반 줄을 할애했습니다. 이는 일반 싸구려 사전에서 찾을 수 있는 정도입니다!
저는 위키낱말사전이 번역을 제시하고 문서에 연결하는 완전히 새로운 방법을 찾아야 한다고 생각합니다.
Lars Gardenius^(diskurs) 2013년 3월 28일 18:13(UTC)

저는 때때로 시를 쓸 때 위키낱말사전을 사용합니다. 그래서 몇 가지 작은 정의가 문장의 전반적인 의미에 대한 모든 핵심을 알려줄 것이라고 기대할 수 없다는 것을 충분히 알고 있습니다. 의미는 상황에 따라 다릅니다. 적어도 현재는 그렇게 생각합니다. 좋아, 하지만 어떤 사전도 관용적 맥락에서 문장을 이해하는 데 모든 키를 제공할 수는 없지만 힌트를 주는 것이 없는 것보다 낫다고 생각합니다. 위키낱말사전에는 기한이 없으므로 제 생각에는 시간이 문제가 되지 않습니다. 더 많은 기여자를 모으는 것이 제 생각에는 훨씬 더 중요한 문제입니다. 그래서 우리가 다음을 목표로 삼아야 합니다

• 새로운 기여자에게 가능한 한 쉽게 에디션을 제공하고
• 다음을 허용하는 유연한 방식으로 문서를 구조화하는 교차 챕터 방식이 있습니다
  • 모든 챕터에 대한 피드백: 영어 버전의 사용 예제로 셰익스피어 인용문을 추가하면 모든 챕터에 전파되어야 하며 사용자가 원래 언어를 알고 있는 경우 현재 챕터 언어로 번역하도록 요청하는 텍스트와 함께 사용해야 합니다. 관련이 있는 경우, 예를 들어 참조 앵커에 텍스트 설명을 추가할 수 있습니다.
  • 로케일 특성에 맞게 조정하려면 해당 지부 커뮤니티가 워크플로에서 요소를 통합하는 방법을 결정하도록 합니다. --2013년 4월 5일 13:01(UTC)

-슈(-sche)의 의견 (및 그에 대한 답변)

• (-sche here:) 지금은 말씀하신 모든 내용에 답변할 시간이 없지만: 예를 들어 많은 것이 사실입니다. 예를 들어 영어 위키낱말사전 항목 프랑스어 단어는 현재 해당 단어에 대한 프랑스어 사전의 항목보다 작습니다. 왜냐하면 위키낱말사전이 불완전하기 때문입니다. 그러나 위키낱말사전은 종이가 아니기 때문에 모든 언어의 모든 단어를 종이 사전보다 더 자세하게 다룰 수 있는 "능력"이 있습니다. 예를 들어 (내 일의 결과로써의)wikt:de:life와 wikt:de:be는 영어 단어 "life" 및 "be"에 대한 독일어 범위를 제공합니다. 단일 언어 영어 사전으로 자세히 설명되어 있습니다. wikt:en:-ak는 아베나키어(Abenaki) 언어 사전보다 더 자세한 "-ak"의 영어 범위를 제공합니다. 많은(어떤) 아베나키어 사전이 있다는 것은 아닙니다! 그것이 각 위키낱말사전이 최선을 다해 할 수 있는 일이며, 외국어 콘텐츠를 위키데이터나 오메가위키에 집중시키려는 제안으로 인해 손실되거나 더 어려워지는 것입니다 (참조. 오메가위키 채택 제안에 대한 제 의견) -sche (토론) 2013년 3월 28일 23:34(UTC).

• 현재 제 의견으로는 인용된 독일어 WT life(첫 번째 이중 언어 부분)과 같은 (매우) 희귀한 분홍색 "고품질" 사례가 제 제안에 대한 강력한 찬성인 것 같습니다. 저는 당신의 예를 유지하고 영어 WT Leben(두 번째 이중 언어 부분)을 살펴봅니다. 하나의 TransEx로 병합하지 않으시겠습니까? 첫 번째 부분은 "1. 삶, 탄생과 죽음 사이의 상태"를 의미하는 두 번째 부분과 "[2] 인생: 누군가가 살고 있는 시간, 개인의 경력, 출생에서 시작하여 죽음으로 끝나는 것"을 의미합니다. 그리고 다른 의미들도 마찬가지입니다. (제가) 제안한 대로 단어의 의미를 가장 잘 나타내는 두 가지 중 하나를 다른 언어로 번역하고 해당 번역 예제 위에 둘 다 번역하는 것은 어떻습니까? (그런데 이 특별한 경우: 파란색 독일 WT Leben은 분홍색 독일 WT life보다 의미가 적습니다 (색상은 위의 이미지 1 참조) 왜 기여자는 파란색의 의미를 개선하지 않았거나 파란색에서 가져 와서 분홍색으로 넣었습니까?) 그런 면에서 우리는 그리 멀지 않다고 생각합니다. 저는 분홍색 단어의 내용을 버릴 것을 제안하지 않습니다. 아이디어는 "정의된 이중 언어 의미/뜻 컨텍스트(아마도 제가 아직 식별하지 못했지만 해결된 것으로 보이는 "기타 중복되지 않은 언어 관계 정보"일 수도 있습니다)에서 단어 사용의 이중 언어 표현"을 TransEx Entity/database/table/WT로 전송하는 것입니다. 링크 유형 1(위의 "이미지 3: 번역 참조"를 참조)은 이러한 TransEx를 처리합니다. "Leben"의 독일어 대 영어 번역 링크 유형 1은 "life"의 영어 대 독일어 번역 링크 유형 1과 동일한 TransEx "Leben*life"를 참조합니다. WT 프로젝트의 진화적 확장에 대해 생각하고 있습니다: 이 경우 "Leben*life", 일반적으로 참조 개체("brige-") 요소가 속하는 WT는 무엇입니까? 관계 개체 TransEx의 요소를 포함하는 독일어도 아니고 영어도 아닌 공통의 새로운 WT입니다. 사용자가 하나의 WT만으로 작업할 수 있는 방식으로 통합해야 합니다. 현재 영어, 프랑스어 등 WT와 함께, 미래에는 하나의 큰 냄비로. 현재 WT의 일부를 분할하여 다른 곳으로 옮기는 것은 좋은 생각이 아니라고 생각합니다. 그렇게 하는 정당은 일반적으로 느슨합니다. NoX

• 답변 "현재 WT의 일부를 분할하여 다른 곳으로 옮기는 것은 좋은 생각이 아니라고 생각합니다": 그러나 이것이 이 제안이 하는 일입니다. 모든 위키낱말사전에서 외국어 항목을 분리하거나 콘텐츠를 복제합니다.

  답변 "하나의 TransEx로 병합하지 않으시겠습니까?": 제가 오메가위키에 대해 작성한 많은 의견-'통합된' 정의를 여러 언어로 번역하고 포함하는 '올인원' 위키낱말사전으로 이미 존재합니다-은 여기에서 반복할 수 있습니다:

  첫째, 서로를 번역할 만큼 외연적으로 유사한 단어는 내포적으로 동의어가 되는 경우가 거의 없습니다. 다른 언어의 용어가 정확히 동일한 뉘앙스 정의를 갖는다고 가정하는 것은 언어적으로 불건전합니다. 예를 들어 "Freund"와 "друг"는 "friend"보다 가까운 동료를 나타냅니다. ("Freund"는 "남자친구"도 나타냄); wikt:de:friend-대-wikt:de:Freund 및 wikt:en:Freund-대-wikt:en:friend 해야 하고 할 수 있습니다 (불완전성으로 인해) "아직" 기록하지 않더라도 이것을 기록하십시오. 통합된 'TransEx'는 이 문제를 어떻게 해결할까요?

  두 번째로 오메가위키는 이미 여기에 제안된 것과 유사한 작업을 시도했지만 실패했습니다. 새로운 기고자들은 매일 en.Wikt에 수십 개의 번역표 항목과 새로운 항목을 만듭니다. 주어진 주에 en.Wikt에는 40명 이상의 정기적인 활동적인 사용자가 있습니다. 자체 언어로 작성된 다른 위키낱말사전에도 많은 활동적인 사용자가 있습니다. 오메가위키에는 10명의 정기적인 활동적인 사용자가 있습니다. 저는 이것이 정당한 이유가 없다고 의심합니다. 오메가위키의 링구아 프랑카(lingua franca)는 영어이며 번역표는 영어 용어를 기반으로 합니다(번역을 영어 뜻에 할당합니다. 독일어 laufen 번역의 경우 DefinedMeaning:run(6323)으로 이동합니다.). 이것은 영어를 잘하지 못하는 사람들이 번역이나 다른 것을 기고하거나 토론에 참여하는 것을 어렵게 만듭니다: 그러한 사용자는 위키낱말사전이 자신의 언어로 가장 잘 제공됩니다. 영어를 공용어로 사용하는 위키데이터는 오메가위키와 동일한 핸디캡을 가지고 있으며, 첫 번째 통합 위키(OmegaWiki)가 번성하지 못한 것처럼 위키데이터에 두 번째 '통합' 위키낱말사전을 만들려는 시도가 번성하지 못할 가능성이 높다고 생각합니다. 경쟁하는 '표준'으로 인해 해당 항목은 다른 위키낱말사전과 동기화되지 않습니다. :/ -sche (토론) 2013년 4월 1일 07:15 (UTC)

언뜻 보기에 이것은 강력한 주장처럼 보였습니다. 독일인들이 이와 같은 문제를 어떻게 다룰지 느끼기 위해 wikt:de:Freund의 토론 페이지에 질문을 추가했습니다.
(한 가지 의견만) 응답에 대한 저의 해석은 다음과 같습니다: 품질 부족. 1) wikt:de:Freund에 의미가 없습니다. 2) 누락된 단어 wikt:de:Freundchen. 3) wikt:fr:ami(wikt:de:Leute를 참조해야) 및 wikt:en:friend(wikt:de:Freundchen을 참조해야)의 잘못된 번역 참조.
하이젠베르크 이후로 우리는 불확실성의 세계에 살고 있으며 그에 따라 살아야 한다는 것을 알고 있습니다. 그러나 우리는 그것을 줄일 수 있습니다. TransEx에 대해 아직 완전히 제시되지 않은 아이디어는
#* {{RQ:Schuster Hepaticae V|vii}} , 단어 "sound" 참조
와 같은 프레젠테이션 구성이 필요하지만 마크업 뒤에 줄 데이터를 포함하지 않는다는 것입니다. 팝업 창을 사용하는 편집 프로세스(데이터 프레젠테이션은 데이터 편집 및 데이터 저장과 다름)는 데이터를 독자와 편집자가 볼 수 없는 별도의 저장소에 넣습니다. 프레젠테이션 절차는 거기에서 날짜를 가져옵니다.
그리고 이것은 오메가위키와 같은 두 개의 타이어 접근 방식과 완전히 다릅니다. 사용자는 "하나의 단일 환경"에서 행동하는 느낌이 있어야 합니다. 이는 데이터 표시를 데이터 저장소와 분리하여 달성할 수 있습니다. 현재는 그렇지 않습니다. 그 설명은 현재 제 제안에 포함된 것보다 더 많은 단어가 필요합니다.
그건 그렇고, 제 {{sic}} 도발적인 버그를 제거해주셔서 감사합니다. 제 서투른 말 뒤에 숨겨진 아이디어를 느끼기를 바랍니다. NoX (토론) 2013년 4월 1일 19:43(UTC)

다음은 귀하의 흥미로운 의견이 저에게 영감을 주는 것입니다. 우리는 단어/위치 "번역"을 제공하는 척하지 말고 의미론적 근접성을 나열하려고 노력해야 합니다. 예를 들어, 내가 말할 수 있는 한 프랑스어 "je"와 영어 "I"는 의미상 동일합니다. 그러나 일본어 "わたし"(와타시)가 (제 일본어 지식이 0에 가까울지라도 그렇지 않다고 생각합니다.) 물론 일본인의 경우 와타시 의미론에 대한 세부 정보가 모국어가 아닌 사람들에게는 그다지 흥미롭지 않을 수 있습니다. 일관성을 유지합니다.

• fr.wikt에서 fr:わたし 일본어 문법에 대한 위키책에 대한 링크(왜 안 됨), 그러나 fr:I 이러한 링크를 제공하지 않음 (위키책이 없을 수도 있습니다)
• wikt:en:I는 fr:wikt:I보다 훨씬 더 많은 어원 정보를 제공합니다.

가능하면 자동화를 통해 이러한 종류의 정보를 보다 체계적으로 전파할 수 있는 방법을 제공해야 합니다. 팁으로, 단어 어원은 컴퓨터가 조작할 수 있는 형태로 잘 표현할 수 있는 것입니다. --Psychoslave (토론) 2013년 4월 5일 13:48(UTC)

"오메가위키의 번역표는 영어로 되어 있다"라는 -sche의 주장은 잘못된 것임을 유의하시기 바랍니다. 오메가위키에는 영어에 상응하는 용어가 없습니다. (예를 들어, safraner). 독일어 "laufen"이 "DefinedMeaning:run (6323)"으로 연결된다는 사실을 영어 기반으로 해석해서는 안 됩니다. 실제로 "DefinedMeaning:6323"으로 이동해야 하지만 최근 변경 사항 페이지를 더 읽기 쉽게 만들기 위해 DefinedMeaning 이름에 번역을 추가하기로 결정했습니다. 약간의 혼란을 주기 때문에 최근 변경 사항 페이지가 아약스화(ajaxize)되는 향후 숫자 전용으로 변경될 예정입니다. --Kip (토론) 2013년 4월 8일 13:40(UTC)

푸로다스(Purodhas)의 의견 (및 그에 대한 답변)

저는 여기서 프레젠테이션 문제에 대해 전혀 논평하지 않습니다. 저는 엄격하게 구조에만 관심이 있습니다.

오메가위키의 접근 방식은 표현 또는 "단어"별로 "개념"을 정의하는 것입니다. 정의는 모든 언어로 표현되지만 단일 언어에 국한되지 않는 것을 설명하는 것으로 가정합니다.

여기에는 기술적인 단점이 있습니다. 필요한 정의가 없기 때문에 대부분의 이중 언어 단어 목록과 사전을 대량으로 가져올 수 없습니다. 다른 단어나 번역이 연결되기 전에 오메가위키에 "반드시" 정의가 존재한다는 것을 기억하세요.

따라서 (대부분) 언어 독립적 정의를 갖는 아이디어가 막다른 골목입니까? 저는 그렇지 않다고 믿습니다. 정말 방대한 종류의 단어에 대해 그러한 정의가 존재하고 쉽게 찾을 수 있으며 목적에 부합합니다. 그러나 주목할만한 예외가 있습니다.

더 자세하게:

• 일반적인 이름과 고유명사, 지리적 명칭, 기술 용어, 과학 용어 및 기타 이러한 종류는 여러 언어 간에 동일하거나 거의 동일하며 의심의 여지 없이 공유할 수 있는 정의가 있습니다. 사진과 그림, 지도 등으로 추가로 식별할 수 있는 경우가 많습니다. 이는 1만 또는 20만 "단어"가 넘는 사전 사용 사례의 90%와 같은 것을 구성합니다. 그러므로 우리가 이 쉽게 얻을 수 있는 기회를 기꺼이 사용하지 않는다면 그것은 현명하지 못하고 낭비가 될 것입니다.

하지만:

• 일반적으로 언어에서 가장 많이 사용되는 100개의 단어 - 각 언어에는 고유한 과정이 있습니다. - 대부분 공유할 수 있는 좋은 정의가 없고 유용한 정의가 전혀 없는 경우가 많습니다. "어머니"와 "비" 또는 "하나"와 같은 매우 일반적인 설명 단어를 제쳐두고, 의미보다는 용법으로 가장 잘 설명되는 단어를 찾을 수 있습니다. 예를 들어 영어 단어 "many", "much" 및 "often"은 의미의 일부 측면을 공유하고 다른 언어로 공통 번역을 가질 수도 있지만 영어 문장에서 서로 교환할 수는 없습니다. 사용 사례는 겹치지 않습니다. 다소 단순화하면 셀 수 있는 경우 "많은", 셀 수 없는 경우 "many", 반복에 대해 "often"를 사용하며 모두 서로를 제외합니다. 고유명사 유형에 대한 설명은 전적으로 목적어 수준에서 이루어질 수 있습니다. "many", "much", "often"에 대한 선행 "설명"은 메타 언어 수준에 있습니다(언어를 사용하여 개체에 대해서가 아니라 언어 자체에 대해 말함). 대상 언어에 "셀 수 있는", "셀 수 없는" 또는 "반복"과 같은 개념이 없으면 다른 언어로 옮기는 것이 번거로울 수 있습니다. -- Purodha Blissenbach (토론) 2014년 3월 21일 05:49 (UTC)
• 도기 보나(Toki Pona) 단어 "li"는 제가 알고 있는 어떤 언어로도 직접 번역되지 않습니다. 순수한 구조적 단어입니다. 동사와 목적어를 분리합니다. 예를 들어 "Purodha toki toki."는 "Purodha가 말하고 이야기합니다."를 의미하는 반면, "Purodha toki li toki."는 "Purodha가 언어를 구사합니다."를 "li"가 어떻게 소개하는지 알 수 있습니다. 두 번째 문장의 목적어. 그 자체로는 "의미"가 없습니다. 구조적인 이유가 있습니다. 전체 문장의 의미에 간접적으로만 영향을 미칩니다. 많은 언어에 구조적 단어가 있습니다. 그들 중 일부는 다른 언어로 유사하거나 원격으로 유사합니다. 일반적으로 언어에 따라 다르며 글로벌 번역이 없으며 자체적으로 의미가 없거나 거의 없으며 메타 언어를 사용하여 설명해야 합니다. 일반적인 "정의"를 갖는 오메가위키 접근 방식은 순수한 구조적 단어에 관해서는 단점이 있습니다. 좋은 소식은 어떤 언어로든 그 중 많은 수가 없다는 것입니다. 대부분 십여 개 정도일 것입니다. 나쁜 소식은 그것들이 일반적으로 가장 자주 사용되는 것들 중 하나라는 것입니다. 그것들이 없는 어휘는 매우 불완전할 것입니다.

(to be continued) -- Purodha Blissenbach (토론) 2014년 3월 21일 13:22 (UTC)

"고전적인" 온라인 위키낱말사전 형식과 읽기 용법에서 벗어나기

우리의 목표는 가능한 한 완전한 사전을 구축하는 것뿐만 아니라 가능한 한 유용한 결과를 원하는 것입니다. 즉, 사전을 다른 곳에 쉽게 통합하고 일반적으로 혁신적인 방식으로 사용할 수 있어야 합니다.

이 부분에서 기여자들은 나중에 생각하기 보다는 디자인 단계에서 고려한다면 어떤 종류의 사용이 더 쉬워질 수 있는지 공개하도록 권장됩니다.

표준 사전 출력을 생성합니다.

현재 생성된 덤프는 그놈(gnome) 사전과 같은 오프라인 응용 프로그램에서 직접 사용할 수 없습니다. 제가 아는 한 w:DICT 프로토콜을 통해 이를 참조하는 표준 방법을 제공하지 않습니다. 전자잉크 기기용 위키낱말사전을 다운로드할 수 있는 것도 편리할 것입니다. --Psychoslave (토론) 2013년 3월 22일 13:40 (UTC).

관련된:

• 자동 고침을 위한 맞춤법 사전 생성
• 불 맞춤법 검사/용어 존재용 API - Amgine/^{메타 위키낱말사전 위키뉴스 블로그 wmf-블로그 구글 뉴스} 2017년 2월 18일 16:03 (UTC)

음성 인식.

위키낱말사전의 항목에 접근하려는 한 가지 방법은 단어/발언을 "발음"하는 것입니다. 스마트폰이 보편화되면서 사람들은 음성 입력을 받을 수 있는 장치를 갖게 되었습니다. 반면에, 사람들은 때때로 철자할 수 없는 단어를 만날 것입니다. 예를 들어, 먼 토착 문화에서 온 두 사람이 친구가 되었고, 그들은 대화를 통해 각자의 지식을 공유하는 것을 좋아합니다. 그래서 언젠가 누군가 모국어의 특정 단어를 말하지만 다른 사람은 그것을 이해하지 못하고 실제로는 그/그녀가 모르는 소리가 포함되어 있기 때문에 발음조차 할 수 없습니다(또는 그/그녀가 성조 언어를 모르는 동안 성조 언어일 수 있습니다). 그래서 그들은 스마트폰을 가지고 "wikipronounce" 앱을 실행하고 원본 그래픽, IPA 전사(최종적으로 관련이 있는 경우 로마자 전사 표기), 사용자 모국어로 정의를 실행합니다. --2013년 3월 23일 08:45 (UTC).

이것은 기대만큼 쉬운 일이 아닙니다. 우리에게는 세 종류의 장애물이 있습니다.

1. 일반적으로 사운드에서 IPA로 가는 기술적인 방법은 없습니다. 녹음의 일부는 기술적으로 식별할 수 있지만(대부분 공명음이지만 지금까지 전부는 아님) 다른 부분은 일반적으로 식별할 수 없습니다. 가장 주목할만한 파열음은 지속 시간의 상당 부분을 침묵합니다. 주요 부분(주파수 없음, 각각의 진폭 0)을 기준으로 이들을 구별할 방법은 없지만 인접 세그먼트와의 동시 연결을 시도할 수 있습니다. 그것은 언어 의존도가 매우 높기 때문에 현재 우리는 독립적인 방식으로 이를 수행할 수 없으며 특정 연구 부족으로 인해 대부분의 주요 언어에 대해 소위 더 작은 언어를 내버려 둘 수 없습니다.
2. 현재 최첨단 음성 인식 시스템은 다음 중 하나입니다:
   • 매우 제한된 사전 정의된 어휘로 제한됩니다. 좋은 것들은 60%에서 75% 범위의 스피커 독립 적중률을 생성합니다.
   • 덜 제한된 어휘, 예. 특정 언어의 맞춤법 검사기가 인식하는 모든 단어를 수락하지만 사용 가능하게 되기 전에 상당한 기간 동안 특정 화자에게 교육을 받아야 합니다. 사전이 아닌 단어에 대한 인식률은 정치적으로 제한적입니다.
3. IPA 사용은 언어와 전통에 따라 다릅니다. 녹음된 발언 하나를 가지고 지구 여러 지역과 IPA를 사용하는 다양한 전통에서 온 12명의 사람들에게 제공하면 "대부분 호환되지 않거나" "모순되는" 12개의 녹취록을 얻을 수 있습니다. 대부분의 경우 사전의 IPA 성적표는 단일 전통을 따르며 원어민 학자가 작성합니다. 공식 IPA 표준에서 전통과 관습 언어 특정 편차를 모두 알지 못하면 외국어 사전에 있는 IPA 성적표를 올바르게 발음할 수 없습니다.

따라서 유감스럽게도 여러분의 비전은 - 최소한 현재로서는 - 극소수의 사용 사례와 기껏해야 위키낱말사전에 이미 존재하는 단어로 제한됩니다. 더 잘됐으면 좋겠지만 확실히 보이지 않습니다. -- Purodha Blissenbach (토론) 2014년 3월 21일 04:31 (UTC)

음성 합성.

IPA(및 X-SAMPA)와 함께 위키낱말사전은 발음 샘플도 제공합니다. 현재 이 소리는 기여자가 하나씩 녹음하고 업로드해야 합니다. 이 솔루션은 없는 것보다 낫고 심지어 발음이라는 단어의 실제 예를 제공하기 위해 보관해야 합니다. 따라서 많은 단점이 있습니다. 우선, 모든 단어에 이러한 샘플이 있는 것은 아닙니다. 그럼에도 불구하고 일부는 IPA를 가지고 있지만, 내가 아는 한 세계의 어느 초등학교에서도 이를 가르치는 곳이 없다는 점을 감안할 때 사람들이 쉽게 읽을 수 없을 것입니다. 따라서 많은 독자가 IPA 데이터(있을 때)를 사용하여 음성 합성을 갖는 것이 매우 도움이 될 것이므로 사람들은 발음하는 방법에 대한 최소한의 아이디어를 가질 뿐만 아니라 다음을 사용하여 IPA를 배울 수 있습니다. 익숙해. 또 다른 장점은 기록이 변경되고 기여자의 다양성을 나타내는 동안 모든 단어에 걸쳐 통합된 발음 음성을 제공한다는 것입니다(기본 설정에서 사용자 정의 가능). 이 마지막 문장은 다양성에 대한 비판으로 받아들여서는 안 됩니다. 앞서 언급한 기록은 실제 사례를 제공하고 음성 합성에 대한 보완 데이터로 남아 있어야 하기 때문에 큰 가치로 간주되어야 하기 때문입니다. --Psychoslave (토론) 2013년 3월 25일 08:11 (UTC)

음성 인식 섹션에 설명된 이유로 IPA 스크립트에서 정확하거나 사용 가능한 음성 합성을 얻을 수 있는 기회는 매우 제한적입니다. 확률은 대부분의 경우가 단순히 올바르지 않다는 것입니다. 이것을 시도하지 않으려는 주장으로 받아들이지 마십시오. 그러나 전체 아이디어가 작동하려면 각 언어마다 고유한 음성 합성 알고리즘이 필요하다는 점을 알아야 합니다. --Purodha Blissenbach (토론) 2014년 3월 21일 04:46 (UTC)

신조어를 피하거나 생성하는 데 도움이 됩니다.

언어의 주요 목적은 의사 소통, 아이디어 공유입니다. 종종 사람들은 자신이 생각하고 의사 소통하려는 것을 표현할 구체적인 단어를 모릅니다. 일반적으로 생각을 어느 정도 정확하게 표현할 수 있는 일련의 단어를 사용하여 문장을 사용할 수 있습니다. 그러나 새로운 개념이 생각의 중심에 있을 때 그것을 표현하기 위해 새로운 단어를 만들기로 결정할 수 있습니다. 각각 장단점이 있는 다양한 전략을 사용하여 이러한 단어를 만들 수 있습니다.

• 주어진 언어에 대한 어원학적 지식을 사용하여 새로운 어근을 추가하지 않고 짧고 이 언어에 대한 좋은 지식을 가진 사람이 이해할 수 있는 단어를 만듭니다. 여기서의 장점은 언어를 화자에게 다소 친숙한 방식으로, 아마도 이전에 들어 본 적이 없더라도 이해할 수 있는 단어로 확장한다는 것입니다. 이러한 종류의 많은 단어의 경우 많은 (모든?) 언어에 이러한 임시 단어를 만들 수 있는 접미사가 있기 때문에 높은 지식이 실제로 필요하지 않습니다. 그러나 때때로 그러한 구성을 만들려면 높은 언어 수준이 필요할 수 있습니다. 특히 과학 활동과 같은 특정 주제에서는 사람들이 자신의 전문 분야에는 유능하지만 언어학에는 유능하지 않을 수 있습니다.
• 약어를 만드세요. 여기서 분명한 이점은 단어를 만드는 데 언어 능력이 필요하지 않다는 것입니다. 명백한 단점은 생성된 단어가 완전히 불투명하고 원어민이 어휘 지식을 사용하여 의미를 추론할 수 없다는 것입니다. 특정 표현이 존재하지 않기 때문에 약어가 반드시 사용되는 것은 아니며, 종종 약어의 문제입니다. 따라서 "디옥시리보핵산"을 나타내는 DNA는 10음절과 3음절을 교환합니다.
• 차용어를 사용합니다. 장점은 단어가 존재하고 결국에는 약간의 발음 튜닝이 필요하고 아마도 알려진 의미 있는 어원이 있다는 것입니다. 단점은 단어가 대상 언어의 원어민에게 불투명할 수 있으므로 이미 획득한 어휘/의미 마인드 네트워크를 기반으로 의미론적 관계를 설정할 수 없다는 것입니다.

여기서 위키낱말사전은 다음을 통해 도움을 주어야 합니다:

• 첫째, 불필요한 중복 신조어를 피하고, 주어진 개념을 표현하기 위해 기존 표현을 쉽게 찾을 수 있도록 하고,
• 대상 언어의 기존 사전을 감안할 때 가능한 한 관련성이 높은 신조어를 쉽게 만들 수 있습니다.
  
  

새로운 발음을 추가하기 위한 사용자 친화적인 방법 추가

예를 들어 Recorderjs 사용(데모 참조).

사용자가 Forvo에서 위키미디어 공용으로 자신의 발음을 일괄적으로 이동하는 데 도움이 되는 도구를 만듭니다

포르보(Forvo)는 사용자가 다양한 언어로 단어를 발음할 수 있는 웹사이트입니다. 불행히도 녹음된 사운드는 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 라이선스를 사용하여 라이선스가 부여되므로 작성자만 포르보의 기존 발음을 공용으로 가져올 수 있습니다.

같이 보기

특정 위키낱말사전 버그:

• 36881-위키낱말사전에는 사용 가능한 API가 필요합니다 (GSOC 프로젝트 설명)
• 46610-음성 녹음 도구(GSOC 소품 초안)
• 22249-일부 검색 결과 페이지에서 자매 프로젝트 검색 기능이 표시되지 않습니다.
• 11415-__EDITPARENTSECTION__

• 위키데이터:위키낱말사전
• 오메가위키
  • 오메가위키 데이터 디자인
  • 의견 요청/오메가위키 채택
  • 오메가위키 데이터베이스 레이아웃
• 범주를 넘어서
• 위키랭은 여러 유용한 방법으로 확장될 수 있는 어휘 및 문법을 포함한 모든 언어에 대한 문서의 중앙 집중식 소스를 제공함으로써 위키백과와 위키낱말사전, 위키배움터 및 위키책의 개발 프로세스 간의 다국어 인터위키 브리지가 되는 것을 목표로 합니다.
  • https://en.wikipedia.org/wiki/Wikipedia:Signpost/Single#WikiLang:_a_new_WMF_project.3F

외부 링크

• DBpedia 위키낱말사전
  • 위키낱말사전 2 RDF 지원 GUI(다른 모든 미디어 위키(예를 들어, 트래블 위키)도 포함)
  • 미디어 위키에서 트리플의 대규모 추출
• 위코킷(Wikokit)