MenuIcon

Owl-Networks Archive

LoginIcon

Where is it? Version 3.92 (Build 405) 와 한글 윈도우 XP와의 상성 문제

| 분류: 컴퓨터 사용 경험 | 최초 작성: 2008-04-12 08:17:37 |

저번에 한번 관련해서 글을 쓴 적이 있었는데, 4월 5일자로 버전 번호는 같고 빌드 넘버만 다른 새 버전이 나왔다.

whereisit_2.jpg




저번의 당혹함을 거울삼아, 이번에는 가상머신의 XP에 우선 설치하여 실행해봤다.

1) 풍선 도움말의 한글 깨짐 현상 : 툴팁의 한글 깨짐 현상은 3.92 초기 버전과 동일하게 발생했다. 하지만 이것은 일단 사용상 치명적 문제는 아니기 때문에 일단은 패스.

whereisit_1.jpg


(** 원래는 "새 카탈로그 만들기" 가 나와야 하는데, 이상하게 깨진 문자들이 출력된다. 혹시 base64가 아닌가 싶었지만 그것도 아니다. 제작사의 홈페이지의 관련 문서 "Some Far Eastern system locales, most notably Korean, are extremely unfriendly to all data that is not pure UTF-16 Unicode. In many controls, system registry etc. 8-bit string data is modified/translated by the operating system, heavily interfering with using UTF-8 encoding. Several workarounds were implemented in different parts of the program. Additionally, all string data saved to registry is now UTF-7 encoded, instead of UTF-8 (existing UTF-8 entries are still detected and read for compatibility)." )


2) 기본 데이터 경로 등 설정에서 Apply 버튼 클릭시 폴더 경로에 \가 하나씩 더 붙는 현상 : 완벽히 해결된 듯 하다. (애초에 제작자의 단순실수가 아니었나 싶다.)

[정정 2008-05-21] 완벽히 수정되지 않았다. 이는 2008년 5월 출시된 3.92.505 버전에서도 여전한데, 예를 들자면,

- D:\My Documents\WhereIsIt Catalogs\ 처럼 영문자로만 구성된 폴더에서는 문제가 없다.
- D:\My Documents\프로그램 데이터\WhereIsIt Catalogs\ 처럼 한글 이름으로 된 폴더가 중간에 존재하는 경우 이 문제는 여전히 발생한다. 추가 버그 리포팅이 필요하다.


3) 한글로 된 디렉토리 경로를 제대로 읽지 못하는 현상 : 한글로 된 폴더명이 깨지던 문제는 완벽 해결. 카탈로그 자동 읽기에서 한글 및 띄어쓰기의 문제로 파일을 제대로 읽어오지 못하던 현상도 해결 되었다.



결론적으로, 한글 언어팩 사용자들은 이제 3.8x 버전에서 업그레이드할 때가 되었다고 생각된다. 3.90 버전에서의 유니코드로의 전환 과정에서, 동아시아 계 언어와의 궁합에 상당한 문제점을 보여주었던 Where is it? 이지만, 3.92.405 버전에 이르러, 어느 정도는 그 안정성을 확보했다고 생각된다(물론 사용시 좀 걸리적거리는 버그들이 여전히 해결되지 않고 있기는 하지만, 3.9 초기버전에서처럼 아예 사용이 불가능할 정도의 치명적인 문제는 더이상 발생하지 않는다).



첨언.

3.92.405 버전에서 수정되지 않았던 문제점들이 3.92.505 버전에서도 전혀 수정되지 않고 있었다. 버그 리포팅을 하지 않았기 때문일지도 모르겠다. 대한민국에 이 프로그램의 정식 사용자가 나 한명 뿐은 아닐 텐데... 리포팅이 들어가지 않아 고쳐진 것으로 생각하고 있는 것인지, 아니면 버그가 여전히 존재함을 인지는 하고 있지만 치명적인 문제가 아니어서 패치의 우선순위가 밀린 것인지는 알 수 없다.

사실 치명적인 문제가 아니라 조금 걸리적거리는 정도의 문제이기 때문에 필자도 그냥 사용하고 있는 상태이다. 물론 좀더 솔직한 이유는, 필자의 영어 실력이 영어를 자유자재로 구사할 정도가 되지 못하기 때문에, 한번 버그 리포팅 영문 메일을 쓰려면 영어사전을 붙들고 되지도 않는 문장을 만들어야 하기 때문이지만 말이다.

아. 물론 이 문제가 전적으로 Where is it? 개발자의 문제라고 생각하지는 않는다. 개발자도 밝힌 바 있지만, (배경지식의 부족으로 정확히는 번역할 수 없으나) 동아시아 계열의 윈도우 XP 시스템에서 내부 유니코드 인코딩 구현에 (유럽어 버전과 다른) 무언가 편법적인 요소가 있고, 그런 부분이 프로그램의 구동에 영향을 미친 듯 하기 때문이다. (유니코드 시대가 된 요즘은 그렇게까지 문제가 발생하진 않지만, 윈도우 3.x 시절에는 영문 윈도우와 한글 윈도우는 번역판 정도가 아니라 아예 "다른" 프로그램이었다. 영문 윈도우용 응용프로그램을 한글 윈도우에서 설치하면 아예 실행조차 되지 않는 경우가 발생할 정도였으니, 더 말할 나위도 없다. 예를 들자면 Microsoft Publisher (for Windows 3.1) 영문판의 경우 한글 윈도우 3.1에서 실행되지 않았다.)

사실 영미권의 프로그래머들(유럽도 다르지 않을 것이라 본다.)의 경우, 영미-유럽 언어 이외의 언어에 대해서 별 신경을 쓰지 않는 듯도 하다. 영어권 프로그램들을 한글 윈도우에서 실행해보면 문자 그대로 "난리가 나는" 경우가 자주 있는 것이 그 한 예이다. 사실 그들이 접하지도 않는 언어들인데 그들이 뭘 알겠는가? 자기네 시스템에서 돌려보고 문제 없으면 내놓는 거지. (아마도 윈도우 XP가 총 22개 언어로 번역되어 판매되고 있을 것이다. 하지만 웬만한 프로그램이 아닌 이상, 이 22개 언어를 모두 완벽하게 지원한다는 것은 거의 불가능에 가깝다고 본다. 더구나 이 프로그램처럼 개인 제작자에 의해 제작되고 배포되는 프로그램이라면.)

그래서 필자도 가능하면 공개 소프트웨어 내지 셰어웨어의 경우 국내 제작자가 제작한 프로그램을 사용한다. 기능이 좀 떨어질 수도 있고, 유명 프로그램과 호환성을 지원받을 수 없을 가능성이 높지만, 한글 지원이 확실하다는 장점이 있기 때문이다. 다만, 국내 개발자들이 이 프로그램과 유사한 기능을 제공하는 프로그램을 (상용이건 공개이건) 만들지 않았고, 현재로서 내가 아는 범위 안에서는 이 프로그램보다 우수한 기능을 제공하는 프로그램이 없기 때문에, 어쩔 수 없이 이 프로그램을 쓰고 있을 뿐이다.

그러나, 합당한 금액을 지불하고 라이센스를 받아 사용하고 있는 정식 사용자로써, 이런 자잘한 버그들이 발견될 때마다 기분이 좋지 않은 것은 사실이다. 더구나 개발자가 처해 있는 상황을 감안할 때 이러한 버그들이 단시간 내에 사라지기 힘들 것이 자명하기 때문에 더욱 그러하다. 답답하지만, 뭐 어쩌랴. 컴퓨터라는 물건 자체가 동아시아 문화권의 발명품이 아닌 탓인걸.






* 내부 링크

[[LINK::255]]

☞ 태그:

☞ 트랙백 접수 모듈이 설치되지 않았습니다.

☞ 덧글이 없고, 트랙백이 없습니다.

덧글을 남기시려면 여기를 클릭하십시오.
[489] < [298] [295] [294] [270] [265] ... [261] ... [260] [254] [249] [247] [246] > [19]

(C) 2000-2023, Owl-Networks. Powered by Perl. 이 페이지는 HTML 5 표준에 따라 작성되었습니다.