spellcheck-ko / hunspell-dict-ko Goto Github PK

(http://code.google.com/p/spellcheck-ko/issues/detail?id=7)

인접한 키를 눌렀을 때 발생하는 오타를 찾는 용도, hunspell(4) 맨페이지 참고:

       KEY characters_separated_by_vertical_line_optionally
              Hunspell searches and suggests words with one different  charac-
              ter  replaced  by a neighbor KEY character. Not neighbor charac-
              ters in KEY string separated by vertical line characters.   Sug-
              gested KEY parameters for QWERTY and Dvorak keyboard layouts:

              KEY qwertyuiop|asdfghjkl|zxcvbnm
              KEY pyfgcrl|aeouidhtns|qjkxbmwvz

       Using  the first QWERTY layout, Hunspell suggests "nude" and "node" for
       "*nide". A character may have more neighbors, too:

              KEY qwertzuop|yxcvbnm|qaw|say|wse|dsx|sy|edr|fdc|dx|rft|gfv|fc|tgz|hgb|gv|zhu|jhn|hb|uji|kjm|jn|iko|lkm

한글 타이핑에서 이러한 오타는 비교적 적으므로 우선순위 낮음.

새로운 단어 항목을 가져왔을 때 (예를 들어 국립국어원 사전에서 새로 추가됐거나) 기본적으로 돌려야 할 스크립트가 흩어져 있고 그때그때 돌려서 처리하는 관계로 실제 추가될 때 누락될 가능성이 높음.

지금까지 ad-hoc으로 만들어서 돌렸던 기능 스크립트를 포함시킨다.

• 불필요한 단어 제외 (a66c49e)
• 표제어, 품사 뽑기 (a66c49e)
• 불규칙 용언 찾기 (a66c49e)
• 보조용언 앞에 붙는 어미 찾기
• 합성용언 여부 찾기

(http://code.google.com/p/spellcheck-ko/issues/detail?id=23)

-어치(1000원어치),

안녕하세요, 먼저 사전 업데이트에 늘 감사드립니다.

이전까지 저는 비교적 예전 버전의 사전을 사용하고 있었습니다. 구체적으로는 chromium 소스 트리에 포함되어 있는 bdic (https://chromium.googlesource.com/chromium/deps/hunspell_dictionaries/+/master/ko-3-0.bdic) 과 같은 버전의 사전을 사용하고 있던 중에, 근래 업데이트된 최근 버전 0.6.4를 시험하고 있는 중입니다.

최신 버전의 사전에서 몇몇 단어의 제시어를 가져올 때 이전 버전보다 확연할 정도로 속도 차이가 발생하는 것을 발견할 수 있었는데, 이를테면 한녕하세요와 같은 단어의 제시어를 가져올 때 0.6.1버전의 경우 약 300-350ms가 걸리는 반면 최근 버전의 경우 평균 950ms정도가 걸리고 있습니다. (실제 수행 시간의 경우 시스템 환경에 따라 상이) 단순한 추측으로는 0.6.1버전 이후 dic / aff 모두 크기가 거의 두 배 가까이 커진 것과 관계가 있지 않을까 싶습니다만 정확한 원인은 찾을 수 없었습니다.

현재 저는 데스크탑 기반의 어플리케이션의 컨텍스트 메뉴에 제시어를 표시하고 있어 (아래와 같은 경우를 생각하시면 됩니다) 실행 시간의 증가는 다소 부담이 되는 상황입니다.

이 문제를 해결할 수 있는 방법이 있을지요?
감사합니다.

F7을 눌러서 맞춤법 검사기 창을 열면 극심한 프리징으로 정상적인 사용이 불가능합니다

(http://code.google.com/p/spellcheck-ko/issues/detail?id=24)

'어수룩하다'의 잘못으로 많이 쓰이나, 대치어 만들지 못함.

부사: 되도록이면

• 단순화, 단어 로데이터와 빌드용 파일 통일
• json과 다르게 주석을 넣을 수 있다

현재 새로 추가한 단어 정보 파일이 많아서 크기도 커지고 처리 속도가 너무 느린 경우가 있다. 적절하게 합치는 것 고려해 볼 수 있다. yaml은 '---' 라인으로 여러 문서를 하나로 합쳐도 가능. 단 파일을 합칠 경우에

• 라이선스가 다른 파일은 다른 파일에 넣어야 해서 추가 복잡도 증가
  • 그 전에 라이선스를 CC-BY-SA로 정리/통일하면 상관없음 #40
• 처리 스크립트 개선 필요
  • 표제어 가나다순으로 맞춰 insert, sort
• 어떤 수준에서 합칠 것인가?
  • 첫 음절
  • 받침 제외 첫 음절 - 최대 크기가 '저'로 시작하는 2.05MB 정도

• 뵙다
• 보조용언 가지다/갖다 (-어 가지고/갖고)

맞춤법 검사에 적합한 인코딩은 두벌식 키보드 스트로크이다. 두벌식 키보드를 사용해서 발생하는 오타 뿐만 아니라 자음이 종성에 붙는지 초성에 붙는지 헷갈리는 오타 패턴이 많이 발견된다. 연음법칙 때문이기도 하다.

문제는 이러한 인코딩은 hunspell의 ICONV/OCONV 테이블에서는 구현이 불가하다는 점이다. 이 기능에서는 테이블에서 일치하는 문자열을 replace하는 기능이 있을 뿐, 가장 긴 걸 매칭한다든가, 뒤의 시퀀스를 고려한다든가 하는 부분이 없다. 예를 들어 다음과 같은 테이블이 있으면 내부적으로 "ㄱㅏㄱㅏ"라는 시퀀스가 있으면 "각ㅏ"로 변환된다. (테이블 순서를 바꾼다면 반대로 "각"이 되야 할 경우에도 "가"로 변환될 것이다.)

OCONV ㄱㅏㄱ 각
OCONV ㄱㅏ 가

이상적인 해결 절차와 방식은 다음과 같다. 아직 애매함

• hunspell 커뮤니케이션 - 문제점 제기
• 인코딩 변환을 hunspell 코드에 하드코딩하지 않고, 변환 방법을 사전 데이터에 정의하는 방법을 고안
• hunspell 커뮤니케이션 - 수정하는 방법 제안

hunspell 커맨드라인을 비롯한 몇몇 부분에서 OCONV 적용이 제대로 안 되는 버그도 문제.

한국어기초사전 정보를 보면 형용사 뒤에 오는 보조 용언과 동사 뒤에 오는 보조 용언이 구분되어 있다. ("일부" 형용사/동사 뒤에 오는 경우도) 이 정보를 활용해 보조 용언 붙은 형태를 줄여서 효율 높이는 방법 고안.

데비안 빌드 중에서

https://buildd.debian.org/status/fetch.php?pkg=hunspell-dict-ko&arch=all&ver=0.7.92-1&stamp=1575459898&raw=0

	make -j4 "INSTALL=install --strip-program=true"
make[1]: Entering directory '/<<PKGBUILDDIR>>'
python3 make-aff-dic.py ko.aff ko.dic dict-ko-builtins.yaml dict-ko-data.yaml 
python3 make-aff-dic.py ko.aff ko.dic dict-ko-builtins.yaml dict-ko-data.yaml 
Progress: 중복 제거...
Status: 중복 제거 후 단어 수: 51149...
Progress: 보조용언 확장...
Progress: 플래그 계산...
Progress: dic 출력...
Progress: aff 출력...
Progress: 중복 제거...
Status: 중복 제거 후 단어 수: 51149...
Progress: 보조용언 확장...
Progress: 플래그 계산...
Progress: dic 출력...
Progress: aff 출력...
make[1]: Leaving directory '/<<PKGBUILDDIR>>'

hunspell을 설치하고 사전을 ko.aff, ko.dic으로 업데이트한 상황입니다.

테스트로 틀린 문장부호 위치를 잡을 수 있나 확인해봤는데 잡을 수 없는 것 같습니다.

예를 들어 ""안녕하세요?" 같은 문장의 경우 앞에 따옴표가 연속적으로 붙어서 틀린문장인데

검출이 안되어 질문드립니다.

(http://code.google.com/p/spellcheck-ko/issues/detail?id=25)

여태껏의 잘못으로 많이 쓰이나 대치어 만들지 못함

안녕하세요.

ubuntu 16.04 기반 elementary os loki에 spacemacs를 사용 중인 유저입니다.

우분투 리파지터리에서 hunspell 1.3.3 버전과 hunspell-dict-ko 0.5.6를 설치하여 사용하다가

오늘 이곳 깃헙 release의 ko-aff-dic-0.6.4.zip을 내려받아

ko.aff와 ko.dic만 기존의 /usr/share/hunspell 내부의 데이터와 교체하여 사용해보았습니다.

이후 hunspell -D를 시도하니

error: line 22471: bad entry number 메시지가 중간에 뜹니다.

동작은 하는 것으로 보이는데 에러 메시지를 보게 되어 알려드립니다.

(http://code.google.com/p/spellcheck-ko/issues/detail?id=36)

문제점이 발생하는 상황을 설명해 주십시오.

1. 부사어 뒤에 보조사 "-나" 또는 "-까지"가 붙을 경우, 옳은 표현도 틀렸다고 표시됩니다.

어떤 동작이 문제입니까? 이 경우에 어떻게 동작하는 게
올바릅니까?
=> "누구에게나", "이렇게나", "너에게까지", "이렇게까지" 등은 모두 허용되어야 합니다.

사용하고 계시는 버전과 애플리케이션 소프트웨어의
버전 등 환경을 써 주십시오.

=> aff/dic data 0.5.5를 애플 OSX 10.8.2의 내장 맞춤법 검사기로 사용 중입니다.

기타 관련 정보가 있다면 써 주십시오.

어떤 부사어인지 좀 더 명확히 알아야 합니다. 모든 부사어는 아닌데요.

안녕하세요. 맞춤법 검사기에 관심을가지고 소스를 받아서 빌드를 했는데 아래와 같은 에러가 납니다.

python3 make-aff-dic.py ko.aff ko.dic dict-ko-builtins.xml dict-ko-galkwi.xml
Traceback (most recent call last):
File "make-aff-dic.py", line 277, in
dic.load_xml(open(filename))
File "make-aff-dic.py", line 109, in load_xml
from lxml import etree
ImportError: No module named 'lxml'
make: *** [ko.aff] Error 1

맥에서 Python3를 설치하고 실행했습니다.

(http://code.google.com/p/spellcheck-ko/issues/detail?id=21)

조사 '-뿐', 다른 조사와 성격이 좀 다름.

'~뿐이다' 처럼 명사 접미어처럼 쓰인다.

보조사로 '~하게뿐 아니라' 식으로도 쓰인다.

(http://code.google.com/p/spellcheck-ko/issues/detail?id=35)

판넬 -> 패널

지금 대치어 규칙은 불규칙 용언 등 문법 규칙에 대해 맞는 말을 찾는 규칙이라서 단어 하나하나의 경우는 열거하는 게 적합치 않습니다.

다른 방법을 찾아봐야 할 것 같습니다.

(http://code.google.com/p/spellcheck-ko/issues/detail?id=2)

공손 선어말어미 '-옵-' 활용 추가.

'-옵-'같은 경우 이 뒤에 자음으로 시작하는 광범위한 어미가 올 수 있어 현재
코드에 추가하기 간단하지 않다. 또 높임 선어말어미 뒤에도 붙는데 (-시옵), 높
임 선어말어미 앞에도 붙을 수 있기 때문에 (-옵시) 까다롭다.

(http://code.google.com/p/spellcheck-ko/issues/detail?id=20)

-지+않다 활용 추가

"않다" 뒤에 다시 활용이 들어가기 때문에 구현 어려움. 지금은 '잖아'만 따로 들어가 있어서 '잖다', '잖게' 따위의 활용은 불완전하다.

1. 많이 쓰는 활용만 더 추가하는 방법, pros: 구현 간단, cons: 불완전
2. 선어말 어미처럼 구현, pros: 모든 경우 커버 가능, cons: 어미 데이터 크기 증가
3. 보조용언처럼 구현, cons: 어미 데이터 크기 증가

(http://code.google.com/p/spellcheck-ko/issues/detail?id=18)

지명을 나타내는 명사 뒤에 붙음

서울행 열차, 광주행 비행기

1만 단위 자릿수별 붙여쓰기를 위해 수사를 내부적으로 관리했는데 그러니까 갈퀴에 명사로 잘못 입력되거나 관형사로만 입력된 경우가 있다.

• 갈퀴에 포함
• 자릿수 정보는 읽으면서 포함하거나 위키에 직접 포함

FOUND: 경 (001) (한국어기초사전 30460) -> 경 (갈퀴 Django 1581)
FOUND: 구 (005) (한국어기초사전 34882) -> 구 (갈퀴 Django 2962)
FOUND: 넷째 (002) (한국어기초사전 26821) -> 넷째 (갈퀴 Django 5355)
FOUND: 다섯째 (002) (한국어기초사전 26826) -> 다섯째 (갈퀴 Django 5914)
FOUND: 대여섯 (001) (한국어기초사전 87906) -> 대여섯 (갈퀴 Django 6489)
FOUND: 둘째 (002) (한국어기초사전 58108) -> 둘째 (갈퀴 Django 7452), 둘째 (갈퀴 Django 7453)
FOUND: 만 (006) (한국어기초사전 64558) -> 만 (갈퀴 Django 8416), 만 (갈퀴 Django 8417)
FOUND: 몇 (001) (한국어기초사전 66235) -> 몇 (갈퀴 Django 9142)
FOUND: 몇몇 (001) (한국어기초사전 62624) -> 몇몇 (갈퀴 Django 9143)
FOUND: 백 (002) (한국어기초사전 36019) -> 백 (갈퀴 Django 11119)
FOUND: 셋째 (002) (한국어기초사전 71132) -> 셋째 (갈퀴 Django 14954)
FOUND: 수만 (001) (한국어기초사전 64977) -> 수만 (갈퀴 Django 15518)
FOUND: 수백 (001) (한국어기초사전 65400) -> 수백 (갈퀴 Django 15536)
FOUND: 수십 (001) (한국어기초사전 65410) -> 수십 (갈퀴 Django 15619)
FOUND: 수억 (001) (한국어기초사전 64594) -> 수억 (갈퀴 Django 15626)
FOUND: 수천 (001) (한국어기초사전 64700) -> 수천 (갈퀴 Django 15716)
FOUND: 열 (001) (한국어기초사전 67805) -> 열 (갈퀴 Django 18860), 열 (갈퀴 Django 18861)
FOUND: 오 (003) (한국어기초사전 31635) -> 오 (갈퀴 Django 19201)
FOUND: 이 (008) (한국어기초사전 71125) -> 이 (갈퀴 Django 21087), 이 (갈퀴 Django 21088), 이 (갈퀴 Django 21089)
FOUND: 일 (005) (한국어기초사전 31523) -> 일 (갈퀴 Django 21614), 일 (갈퀴 Django 32157)
FOUND: 일고여덟 (001) (한국어기초사전 87907) -> 일고여덟 (갈퀴 Django 21632)
FOUND: 조 (006) (한국어기초사전 75237) -> 조 (갈퀴 Django 24009)
FOUND: 천 (002) (한국어기초사전 17167) -> 천 (갈퀴 Django 26111), 천 (갈퀴 Django 26112)
FOUND: 첫째 (002) (한국어기초사전 17310) -> 첫째 (갈퀴 Django 26286)
FOUND: 칠 (002) (한국어기초사전 71470) -> 칠 (갈퀴 Django 27224)
FOUND: 팔 (002) (한국어기초사전 31598) -> 팔 (갈퀴 Django 28658)
FOUND: 한둘 (한국어기초사전 72435) -> 한둘 (갈퀴 Django 29787)
total: 83

갈퀴 Django에서 수사와 겹치면서 명사로 맞춤법 검사 사전에 포함된 항목은 다음 2개.

FOUND: 일고여덟 (001) (한국어기초사전 87907) -> 일고여덟 (갈퀴 Django 21632)
FOUND: 한둘 (한국어기초사전 72435) -> 한둘 (갈퀴 Django 29787)

• CC BY 라이선스로 아직 허가하지 않은 기여자가 추가로 허가할 가능성이 별로 없다는 점에서 남아 있는 MPL/GPL/LGPL 라이선스의 정보를 다른 방법으로 정리할 필요가 있다. (현재 1188개)

$ grep -l -r 'MPL 1.1/GPL 2.0/LGPL 2.1' data/entries|wc
   1188    1189   54683

• 표준국어대사전 버전으로 대체. (CC BY SA 2.0 KR)
  • #39
• 인사이트 인명/지명 사전 버전으로 대체. (CC BY SA 2.0 KR)
• 우리말샘 버전으로 대체. (CC BY SA 2.0 KR)
  • #45
• 100개 내외로 줄어들 것으로 예상. 남아있는 단어 중: 중요성 평가해 삭제

예를 들어 ㅂ불규칙은 학교문법에서는 불규칙이라고 부르기 때문에 일일이 입력하기는 하지만 "-ㅂ다"로 끝나는 경우는 다 해당된다. 이런 속성은 자동 처리하도록 한다.

단어 데이터 관리 방식이 지금까지 변화해 온 방식을 보면 다음과 같습니다.

1. google app engine 기반은 구글의 요금 체계가 바뀌면서 실패
2. 1을 단순화시켜 일반 django 기반으로 운영하다가,
3. semantic mediawiki (SMW) 기반으로 바꿨으나,

현재 SMW 상태의 문제를 개선할 필요가 있습니다. 왜냐하면,

1. 이용하려면 SMW를 배우는 장벽이 있음.
2. 그리 안정적이지 않음.
3. 느리다. SMW에서 단어 사이의 관계를 기술해도 그게 업데이트되는데까지 꽤 시간이 걸림.
4. 크지 않으나 도메인과 서버 비용과 업데이트 등 관리 부담
5. 트렌드로 보면 SMW보다 wikidata가 대세가 되고 있다.

단순히 git에 들어간 자료 형태로 개편하는 안:

1. github의 기능만으로 가능.
2. 기여자들은 PR과 같은 방식으로.

단 git에만 저장된 형태로 가면 한계는 다음과 같습니다.

1. 웹에서 단어 사이의 관계를 기술하기 힘들다.
2. 올바른지 확인을 위해 CI 등을 사용해야 함

github 내장 위키 등 여러가지 github 기능을 고려할 수 있습니다.

간단하게 맞춤법 검사를 위한 파일 test.txt를 만들고 hunspell test.txt를 실행시키면 자모가 분리된 단어들이 뜹니다.
실제로 수정한 파일에도 자모가 분리되어서 들어갑니다.

macOS Sierra에서 Hunspell 1.6.0를 구동하고 있습니다.

(http://code.google.com/p/spellcheck-ko/issues/detail?id=22)

접미사: -경 (쯤, 무렵)

(http://code.google.com/p/spellcheck-ko/issues/detail?id=5)

명사의 종류에 따라 제약이 있는 조사를 구분.

1. 사람/동물에만 붙는 경우
2. 셀 수 있는 대상에만 붙는 경우
3. 몇몇 대명사 (나가(x), 내가(o), 너가(x), 네가(o))

대명사 이거/그거/저거 + 이 => 이게/그게/저게

0.3.0 대명사의 경우 구별할 수 있게 구현.

1의 경우 모든 명사의 유정명사/무정명사 구분이 필요. 작업량 많음.
2의 경우 현재 "가산명사" 속성 활용 가능.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859294

  python3 make-aff-dic.py ko.aff ko.dic dict-ko-builtins.json dict-ko-galkwi.json 
  Traceback (most recent call last):
    File "make-aff-dic.py", line 329, in <module>
      dic.load_json(open(filename))
    File "make-aff-dic.py", line 166, in load_json
      d = json.load(infile)
    File "/usr/lib/python3.5/json/__init__.py", line 265, in load
      return loads(fp.read(),
    File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
      return codecs.ascii_decode(input, self.errors)[0]
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xed in position 38: ordinal not in range(128)
  Makefile:28: recipe for target 'ko.aff' failed
  make[1]: *** [ko.aff] Error 1
  make[1]: Leaving directory '«BUILDDIR»'
  dh_auto_build: make -j1 returned exit code 2
  debian/rules:5: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

(http://code.google.com/p/spellcheck-ko/issues/detail?id=13)

What steps will reproduce the problem?

1. "있따" 입력

What is the expected output? What do you see instead?

"있다"가 우선순위가 더 높아보이는데 "잇다"가 먼저 등장한다.

연속된 글자가 아닌 경우에도 더 많은 글자가 대체된 쪽이 우선 순위가 높다.

예를 들어, "찾앗다"에 대해 "잦았다"가 "찾았다"보다 먼저 등장한다.

보조용언 붙여 쓰기를 위해 (https://www.korean.go.kr/front/page/pageView.do?page_id=P000075&mn_id=30) 확장하는 부분에 대해:

보조용언은 현재 20개, 보조용언이 붙는 어미는 3종류 (-어, -은, -을)

그러므로 모든 동사에 보조용언을 붙여서 확장하는 것보다 위 3 어미만 확장하고 합성어로 처리하는 게 크기나 성능면에서 더 낫다.

예제:

$ cat aux-using-compounds.aff
SET UTF-8

FULLSTRIP

SFX A Y 3
SFX A 오다 와 오다
SFX A 다 아 받다
SFX A 다 고 .

COMPOUNDMIN 1
COMPOUNDRULE 1
COMPOUNDRULE CB
$ cat aux-using-compounds.dic
4
받다/A
받아/C st:받다
오다/AB
와/C st:오다
$ 

아예 "받아"를 확장하지 않고 다음과 같이 특정 suffix에 대해서만 COMPOUNDRULE에 처리되게 만들고 싶지만, hunspell의 COMPOUNDRULE 기능에 한계가 있음. 이렇게 하면 동작하지 않음.

$ cat aux-using-compounds.aff
SET UTF-8

FULLSTRIP

SFX A Y 3
SFX A 오다 와/C 오다
SFX A 다 아/C 받다
SFX A 다 고 .

COMPOUNDMIN 1
COMPOUNDRULE 1
COMPOUNDRULE CB
$ cat aux-using-compounds.dic
2
받다/A
오다/AB
$ 

#40 관련, 남은 단어 1300여 단어의 대부분을 우리말샘 데이터로 대체.

• 단어 목록 작성
• import
• process

(http://code.google.com/p/spellcheck-ko/issues/detail?id=37)

문제점이 발생하는 상황을 설명해 주십시오.
1.'실용주의'라고 붙여 쓸 경우 맞춤법 오류로 나옴 -> 합성어는 붙여 쓰는 것이 맞음
2.다른 모든 합성어의 체크의 문제로 보여짐.

어떤 동작이 문제입니까? 이 경우에 어떻게 동작하는 게
올바릅니까?

실용주의라고 썻을 경우 표준국어대사전[국립국어원]에 따라 합성어로 보고 붙여 써야 하는데
이러한 합성어를 붙여 쓴 것을 맞춤법 오류로 보고 빨간 줄이 쳐지고 있습니다.

사용하고 계시는 버전과 애플리케이션 소프트웨어의
버전 등 환경을 써 주십시오.
ko-aff-dic-0.5.6
MAC OS 10.9.1

기타 관련 정보가 있다면 써 주십시오.

일단은 사전에 있는 단어는 입력하는 게 정책이므로 예제로 드신 실용주의는 입력하면 해결될 것 같고요. 사전에 없는 일반적인 합성어에 대해서라면 이미 알고 있는 문제이고, 해결도 쉽지 않은 문제입니다. 붙여서 썼을 때 하나의 의미를 가져야 하기 때문에 규칙만 가지고는 어렵습니다.

모든 명사+명사를 폭넓게 허용할 수도 있는데 이러면 의미가 안 통하는 모든 단어를 붙여 써도 허용하는 문제가 생깁니다. 명사를 분류해서 어느 정도 규칙을 만들어 입력하면서 어느 정도는 개별 입력하는 정도가 실용적인 방법일 겁니다.

결국 마찬가지이기는 하지만, 파이썬 코드의 데이터를 단어 데이터로 바꿈으로써 장점이 있다.

• 파이썬 코드를 단어 열거로 바꾸어 관리 부담을 코드에서 데이터로 옮긴다.
• 국어 문법의 9품사 중의 하나이므로 형태소분석 기능에서 각 단어별로 품사가 나오게 한다.
• 보조사도 조사+보조사 형식으로 바꾸어 AFF 파일 크기를 줄인다.

• 한국어기초사전의 조사에 들어 있는 문법 정보 뽑아내기

전체 참고: 받침이 없거나 ‘ㄹ’ 받침으로 끝나는 명사 뒤에 붙여 쓴다.

(http://code.google.com/p/spellcheck-ko/issues/detail?id=14)

문제점이 발생하는 상황을 설명해 주십시오.

1. 접미사 ~별

(http://code.google.com/p/spellcheck-ko/issues/detail?id=12)

문제점이 발생하는 상황을 설명해 주십시오.

1. 접사 ~씩

어떤 동작이 문제입니까? 이 경우에 어떻게 동작하는 게
올바릅니까?

수량, 단위를 나타내는 명사에 대해 허용. "한 개씩", "며칠씩", "하나씩", ...

사용하고 계시는 버전과 애플리케이션 소프트웨어의
버전 등 환경을 써 주십시오.

기타 관련 정보가 있다면 써 주십시오.

단위 명사, 수사, 그 외 수량을 나타내는 명사 (며칠 등) 따위를 사전 데이터에
서 구분해야 한다.

~째

KDE Neon 유저입니다. hunspell-ko 0.7.92-1 을 사용하고 있고 hunspell 은 1.7.0 입니다.

Kate 랑 Intellij Idea 를 사용하면서 발견한 문제인데, 한글 dictionary 파일을 사용하도록 하면 모든 영어 검사가 비활성화 되는 것 같습니다.
Kate에서 영어를 기본 맞춤법 검사 언어로 설정할 시:

Kate에서 한글을 기본 맞춤법 검사 언어로 설정할 시:

또한 Intellij 에서는 ko.dict 파일을 추가하는 순간 모든 맞춤법 검사가 비활성화 됩니다.
ko.dict 없이:

ko.dict 추가 이후:

"받은듯하다"는 되고 "받으신듯하다"은 안 되는 상황.

• 네이버 맞춤법 검사에서는 틀린 단어로 취급.
• 다음 맞춤법 검사, 부산대에서는 맞는 단어로 취급.

안 그래도 용량이 커지고 성능이 떨어지는 주범인 보조용언 확장에 선어말 어미 케이스까지 포함하기는 어렵고, COMPOUNDRULE로 제대로 동작할 수 있어야 한다.

「접사」

「1」((수나 양 또는 값을 나타내는 명사구 뒤에 붙어))‘그만한 수나 양을 가진 것’ 또는 ‘그만한 가치를 가진 것’의 뜻을 더하는 접미사.
¶ 한 뼘짜리/열 살짜리/오십 권짜리/방 두 개짜리/백 원짜리/얼마짜리.
「2」((몇몇 명사 뒤에 붙어))‘그런 차림을 한 사람’의 뜻을 더하는 접미사.
¶ 양복짜리/장옷짜리/창의짜리.

(http://code.google.com/p/spellcheck-ko/issues/detail?id=29)

특별한 상황입니다. 명사+서는 정상적임.

예; 둘이서, 셋이서, 여럿이서

제삼자 + 가, 는, 인, 등등.

Third party / person

표준국어대사전 사이트가 기존 우리말샘/한국어기초사전 기반이기는 하지만 몇 가지 차이점 등 때문에 사용하기에는 문제가 있다. 정리 목적

• 표준국어대사전 사이트의 버그: XML 다운로드가 완료되지 않음.
• XML 포맷이 기존의 LMF가 아니라 새로 만들었음.
• 어휘 수는 단어만 36만에 달해 한국어기초사전에 비해 3배 넘게 늘어나지만 빈도 정보가 없는 관계로 어휘를 그대로 쓸 수 없음. 한국어기초사전과 겹치는 단어를 확인하는 등의 과정이 필요하지만 상호 레퍼런스하는 정보가 없어 어렵다. 화이트리스트를 만들어 해당하는 단어만 import한다

• 단어 리스트 작성
• importer 포팅
• process 스크립트 맞추기

한국어에서 가산명사의 구분은 그리 엄격하지 않아서 '-들'을 붙이는데 비교적 자유롭다. 셀 수 없는 것도 시적 허용에 따라 허용하는 경우가 많고, 고유명사의 경우는 잘 그러지 않는다.

고유명사처럼 거의 안 붙이는 경우가 있어서 트레이드오프지만, 모두 '-들' 접미사를 허용하는 게 생산적인 방법으로 보인다.

문제는 현재 '-들'이 붙은 형태를 미리 생성해 놓고 있기 때문에 사전 사이즈가 2배 가까이까지 늘어날 가능성이 있다는 점. 미리 생성해 놓지 않고 suffix rule을 쓰면 그 뒤에 조사가 붙었을 경우 suffix를 2개까지만 허용하는 hunspell 제한에 걸릴 수 있고, compound를 쓰면 대치어 찾기가 제대로 되지 않는다.

Word does not match! Index: 13975 Expected: 김수한무거북이와두루미삼천갑자동방삭치치카포사리사리센타워리워리세브리캉무드셀라구름위허리케인에담벼락서생원에고양이고양이는바둑이바둑이는돌돌이 Actual: 김수한무거북이와두루미삼천갑자동방� ERROR converting, the dictionary does not check out OK.

qtwebengine 사전으로 변환을 시도하였으나, 위와 같은 오류로 인해 변환이 불가능 합니다.

관련 이슈:
wooorm/dictionaries#14

(http://code.google.com/p/spellcheck-ko/issues/detail?id=15)

사동의 의미를 부여하는 접미사 '-시키다', 피동의 의미를 부여하는 접미사 '-당
하다'는 사전에 별도로 나와 있지 않다. 사전에 없어도 별개의 단어로 기재하거
나 서술의 의미가 있는 명사에 대해서 표시를 해야 한다.

'-시키다'의 경우에는 서술을 나타내는 모든 명사에 가능하지만 '-당하다'는 피
동이 가능해야 하므로 타동사의 경우에만 가능하다.

"사과인듯하다" = 사과 + 이다 + 듯하다

모든 명사를 -일, -인이라고 확장하기는 힘들고, COMPOUNDRULE로 처리할 수밖에 없음.

(http://code.google.com/p/spellcheck-ko/issues/detail?id=26)

대치어: 자켓 -> 재킷, 팬더 -> 판다

모음 2개를 바꾸는 것보다 우선순위가 높은 다른 단어가 많기 때문인데, 모음 2개의 변화의 우선순위를 높이는 방법 고안해야 함. 외국어 표기로 많이 발생하는 케이스.

어미 활용 정보를 현재 suffixdata.py 파일에 일일이 기록하고 있는데, 길이도 길어지고 관리가 쉽지 않다. 단어 데이터로 분리해서 사용할 수 있도록 개편.

• 한국어기초사전에 어미도 포함되어 있으므로, 이쪽 데이터를 사용한다.
  • 단, 사전 데이터에 충분한 정보가 담겨져 있지 않은 경우가 많은데 suffixdata.py에 있던 정보를 추가 정보로 입력한다.