Mozilla 한국 커뮤니티

현재 어플리케이션은 차니님과 김정균님 정도, 확장 기능은 저를 비롯해서 김고명님, 스시짱님, 블루로봇님, 김정균님, xxl님, DeadAlive님등이 번역을 맡고 계신것으로 알고 있습니다.
번역을 하시는 분이 많으니 비슷한 확장 기능이라도 서로 다른 분이 맡고 계시는 경우도 있고해서 같은 용어라도 번역가분에 따라 서로 다르게 번역되고 있습니다.
제가 이글을 쓴 이유는 이렇게 일관성 없이 서로 다르게 번역되고 있는 용어들을 한 데 모아 각 용어들의 표준 표기법을 정해 보자는 취지에서 입니다.
확장 기능이나 어플리케이션을 번역할 때 이것은 어떻게 번역할까?란 생각을 해보신 용어가 있다면 댓글로 올리고 그 용어의 표기법을 의논해 보는것은 어떨까요?
일단 생각나는 것은 **bar라는 표현입니다.
저는 주로 막대라고 번역하고 있는데 그냥 바로 번역하시는 분도 계시더군요.
toolbar는 도구 막대, 도구 모음, 도구바, 툴바등 표기법이 4개 이상이군요...
그밖에 생각나는 녀석들은
bookmarks(현재 북마크로 번역되고 있는데 순우리말인 책갈피 정도로 바꾸면 어떨까요? 책에다 표시하는 것이 아니라 웹에다 표시하는 것이니 웹갈피 정도의 신조어는요?)
sidebar(그냥 사이드바 말고 더 멋드러진 우리말 표현은 없을까요?)
panel(사이드바와 거의 같은 뜻으로 쓰이고 있는 놈입니다. 위의 녀석이 결정되면 이녀석도 같이 묶어서 한 용어로 쓰는것도...)


ps. 제목 글자수의 압박이로군요... 차니님, 제목 글자수 제한을 30~40자정도로 늘리실 생각은 없으십니까?

프랙탈 wrote:번역을 하시는 분이 많으니 비슷한 확장 기능이라도 서로 다른 분이 맡고 계시는 경우도 있고해서 같은 용어라도 번역가분에 따라 서로 다르게 번역되고 있습니다.
제가 이글을 쓴 이유는 이렇게 일관성 없이 서로 다르게 번역되고 있는 용어들을 한 데 모아 각 용어들의 표준 표기법을 정해 보자는 취지에서 입니다.
확장 기능이나 어플리케이션을 번역할 때 이것은 어떻게 번역할까?란 생각을 해보신 용어가 있다면 댓글로 올리고 그 용어의 표기법을 의논해 보는것은 어떨까요?

반드시 시정되어야할 문제라 봅니다. IE와 FF가 다른 것은 이해될 수 있지만 FF 내에서는 표준통일안이 반드시 있어야 된다고 여깁니다.
Wiki 같은 것을 통해 좀더 많은 사람의 의견을 수렴하는 것이 가능할까요?

프랙탈 wrote:toolbar는 도구 막대, 도구 모음, 도구바, 툴바등 표기법이 4개 이상이군요...
그밖에 생각나는 녀석들은
bookmarks(현재 북마크로 번역되고 있는데 순우리말인 책갈피 정도로 바꾸면 어떨까요? 책에다 표시하는 것이 아니라 웹에다 표시하는 것이니 웹갈피 정도의 신조어는요?)
sidebar(그냥 사이드바 말고 더 멋드러진 우리말 표현은 없을까요?)
panel(사이드바와 거의 같은 뜻으로 쓰이고 있는 놈입니다. 위의 녀석이 결정되면 이녀석도 같이 묶어서 한 용어로 쓰는것도...)

그놈 데스크탑 번역때문에 고민해 봤었는데요. MS윈도우를 따라하는 방향으로 진행하고 있기 때문에 MS에서 쓰는 용어를 조사해 봤었습니다

toolbar: 도구모음이 MS 윈도우에서 사용하는 말입니다.
sidebar: 명확한 용어가는 없고 "보조창", "보조모음" 따위로 "보조"라는 말을 씁니다.
panel: MS윈도우에서는 패널같은 게 없기 때문에 번역 용어가 없고요. 그놈에서는 그냥 패널이라고 합니다 -_-

toolbar 도구 모음
sidebar 탐색 창
상태바 상태 표시줄
panel 패널

로 통일할 예정 입니다.

전부터 계속 신경쓰이던 어휘가 있는데 편집 메뉴의 잘라내기, 복사, 붙여넣기 입니다.
그중에서 잘라내기는 사전상의 의미로 보면

자르다1[자르니·잘라][타동사][르 불규칙 활용]
1.(날붙이 따위로) 물체를 베어 도막을 내다.
¶고등어를 세 도막으로 자르다.
2.온 것에서 한 부분을 떼어 내다.
¶곁가지를 자르다./생선의 꼬리만 자르다.
3.(말이나 일이) 이어지던 것을 끊다.
¶남의 말을 중도에서 자른 다음, 제 주장만 늘어놓다.
4.(상대편의 요구 등을) 받아들이지 않겠다는 뜻을 나타내다. 거절하다.
¶경위 해명의 요구를 한마디로 잘라 버렸다.
5.(직장 등에서) ‘내보내다’를 속되게 이르는 말.

자르다2[자르니·잘라][타동사][르 불규칙 활용] (물체를) 잘록하도록 동이다.
¶지혈을 위해 상처를 붕대로 잘라 매었다.

인데
자르다2는 아닐테고 자르다1의 두번째 의미로 사용한 듯 한데 자르다에는 필요없는 부분을 잘라서 버린다는 부정적 의미가 강합니다.
그에 비해

오리다[타동사] (종이·천 따위를) 칼이나 가위로 필요한 모양으로 베다.
¶색종이를 둥글게 오리다.

는 필요한 부분을 오려서 모아둔다는 긍정적 의미가 강합니다.
잘라내기보단 긍정적이고 원뜻에도 잘 맞는 오려두기로 바꾸는 건 어떨까요?
m$ 윈도우의 UI를 따라 잘라내기로 번역하신 듯 한데 어떤 마소의 ㅄ이 저따위로 번역했는지는 몰라도 그 사람은 우리말 어휘의 느낌에 대해서 잘 모르는 외국계가 아닌가 합니다.
그리고 복사는 한자어 인데 잘라내기 붙여넣기 등의 순우리말 사이에 있어서 어색해 보입니다. 베끼기로 바꾸시던지 글자수를 맞추어 복사하기로 바꾸셨으면 합니다.

현재 파이어폭스를 번역하면서 가장 주안점을 둔 것은 IE와 용어를 따라가는 것입니다. 물론 IE 번역팀이 모두 맞는 것은 아닐것입니다. 그러나, 꽤 오랫동안 사람들에게 길들어진 용어를 그대로 차용함으로서 얻는 점은 이전 시 사용자들에게 편리함을 주기 때문입니다.

그들에게 오려두기나 베끼기 등은 생뚱맞을 수 밖에 없습니다. (저도 어색합니다.) 새로운 소프트웨어에서 어휘를 선택하는 데 단순히 사전적 고찰로 해결 하는 것은 별로 바람직 하지 않다고 생각합니다. 이미 있는 소프트웨어, 사람들이 많이 쓰는 용어 위주로 선택하는 것이 맞습니다. Firefox는 국어 순화를 위한 소프트웨어가 아님을 분명히 합니다. 게다가 사람들이 흔히 말하는 웹 표준을 위한 소프트웨어도 아닙니다.

첨부. 언급하신 것들 중에 보면...
왜 '잘라내기'와 '복사'로 했을까요? 자르다는 대체하는 단독 명사가 없습니다. 대산 복사하다는 복사처럼 해당되는 명사가 있죠. 이런 이유로 Insert도 삽입하기라고 하지 않고 삽입이라고 번역합니다.

앞으로 IE에서 선택한 용어 위주로 계속 가는 것은 기본적인 기조가 될 것입니다. 단, Firefox에서만 쓰는 단어들은 최대한 일반 용어나 영어 원문에 맞출 예정입니다.

말이란 만들고 가꾸는 사람들 것이 아닐까요?

조금 억지스럽지만 대부분의 기능을 지원하는 IE를 두고 왜 우리는 불여시(firefox)를 사용하는 걸까요? 표준은 누구를 위해 지키는 걸까요? 우리가 필요로 하는 기능의 대부분을 가지고 있는 IE를 나두고 구지 왜 불여시를 다시 만들고, 같지 않은 딴지를 걸어대는 사람들을 뒤로두고 사람들에게 웹 표준과 접근성을 말하면서 알리고 이해시키느라 애쓰시는지요.

용어의 우리말화는 언어적 접근성에 해당되지 않나요? 전 글을 쓰신분의 마음이 이해가 갑니다. 우리들이 쓰는 한글화된 불여시를 쓰는 사람들은 일단 컴퓨터를 다루는 사람들이라 어느 정도 숙련된 지식과 기술을 갖춘 지식을 갖춘 사람들이라 한자식 표현과 영어식 표현쯤은 당연히 하다고 무심코 생각하는게 아닌가 싶습니다.

구지 있는 우리말을 두고 그냥 배운대로 한자어나 영어식 단어를 쓰는 입장에선 생뚱맞고 어색하고, 영어나 한자어를 빌어쓰는 단어는 그렇지 않을지 몰라도 배우지 못한 사람들입장이나 문화적인 면에서 본다면 그것도 일종의 고집과 의식에 불과하다고 생각합니다. 찍찍 쥐가 아닌 컴퓨터에 사용하는 “마우스”란 단어를 꼭 우리식으로 “쥐”라고 말하는 수준은 주장하는 것도 별로 억지스럽지 않다고 생갑니다. 꼭 지켜야할 문화라고 생각을 하는 분들은 어쩔 수 없이 방어적이며 공격적입니다. 우리가 불여시를 알릴 때 하는 행동과 같습니다. 불여시에서 충분히 “액티브엑스”를 구현하고 지원해줄 방안이 있는데도 그렇게 하지 않고 지켜나가는 이유랑 비슷합니다. 저야 컴퓨터에만 쓰이고 새로 만들어진 물건이라 영어식 표현을 빌려서 이 물건은 “마우스”라고 가르키고 귀여운 생쥐는 쥐라고 불러주는게 더 편리하다고 생각하지만 “아름다운” 이란 말이 있는데 명사가 없다는 이유로 구지 “뷰티” 나 “뷰티풀”에 해당하는 말을 한자어에서 빌려 “미”라고 표한 한다면 조금 억지스럽지 않습니까? 구지 영어권 사람들이 컴퓨터 용어를 쓸 때 없는 명사가 없는 단어를 위해 라틴어를 꼭 빌어다 새로 만들지는 않듯이 이것도 우리말의 특징이라고 생각했으면 좋겟습니다.

“복사”란 말이 없다고 치고 “Copy”에 해당하는 우리말 명사가 없다고 “베끼기”란 말 대신에 새말을 만들 때 꼭 한자어를 빌어서 복사란 단어를 만드는게 과연 일반인들에게 어떤 도움을 주는지 모르겟습니다. 그 말을 이해 시킬려면 오히려 한자를 두 개 가르쳐 이해시켜야 하는 복잡한 언어적 접근성을 가져 더 힘든데 말입니다.

말만 한글 우리글 하지 아직도 대부분의 배운 분들은 우리말의 조합으로 새로운 단어를 만들지는 않고 무의식적으로 영어를 가져다 쓰거나 한자어 조합을 고집합니다. 차니님이 마지막에 하신 말씀인 “앞으로 IE에서 선택한 용어 위주로 계속 가는 것은 기본적인 기조가 될 것입니다. 단, Firefox에서만 쓰는 단어들은 최대한 일반 용어나 영어 원문에 맞출 예정입니다.”란 글 속에도 그런게 느껴집니다. 그리고 “이미 있는 소프트웨어, 사람들이 많이 쓰는 용어 위주로 선택하는 것이 맞습니다” 이렇게 쓰신 글도 조금 이상합니다. 이건 맞고 틀린 문제가 아니라 선택의 문제가 아닌지요.

글을 아무나 아는 시절 아이이서 종속적일 수밖에 없던 시절도 아니며, 취미나 일상생활 문화가 문학(책, 노래.....)보다 기술이 더 가까운, 책이나 노래마저도 그 기술의 쓰임새가 컴퓨터 위주로 흐르는 지금은 여러분들이 분들이 우리글 문화를 만들고 가꾸는 맨 앞자리에 서있는 분들이라고 생각합니다. 그래서 대단하시다고 생각하며 항상 고마워하고 있습니다.

IE를 놔두고 왜 꼭 우리들이 불여시를 이렇게 알리려 노력하는지를 우리글에 빗대서 생각한번 해주시기 바랍니다. 여기 있는 분들이 만드는 우리말식 조합의 새로운 말이라면 제가 앞장서서 밀어드리겠습니다. ^.^;;

문화가 서로 나누고 배워가면서 커가지만 이런 수준이면 일본말보다 더 빠르게 조사위주의 꾸밈말만 남고 단어가 영어와 한자식 외래어로 바뀌는 날이 올까 걱정돼 기술을 알리는 입장에서 말까지 고민해달라고 하는게 어려운 부탁인줄 알면서 앞뒤없이 몇자 적어 올립니다. 리눅스 진영에서 한창 잘나가는 배포판인 우분투란 말이 의미를 부여하고 뜻을 알리고 좋은 곳에 쓰자 그 말의 가치가 올라간거 아닐까요. 우분투란 말이 뜻을 적은 글을 보면 단어도 문장도 아닌 이상한 관계적인 말이지만 이젠 우분투란 단어를 아는 사람들은 그 뜻을 헤아리고 있을 겁니다. 그렇지 않았다면 흔히들 나쁘게 말하는 미개한 아프리카 어느 종족의 사라져가는 말이었을 겁니다.

글이나 댓글에 대한 딴지는 아니고 좀 더 좋은 온누리를 위해 고민하다보니 불여시 리눅스 GPL... 등을 알아가다 보니 넓은 의미에서 우리말 접근성에 대해 잡생각이나 여러분들께 올립니다. ^^*

맞춤법을 몰라 잘 쓰던 오픈오피스를 잠시 닫고 거의 1년째 쓰지 않던 한글815를 깔아서 이글을 쓰고 있네요. ㅡ.ㅡ;; 못쓰는 글이지만 좀 더 다듬어서 인터넷 글쓰기에서 한글쓰임을 강조하는 몇몇 학자님들께 보내봐야 겟습니다. 컴퓨터가 삶에 차지하는 몫이 점점 커가는 지금은 제가 생각하는 고리타분한 분들이 쓰는 어려운 글보다 실제로 우리 삶에 더 영향을 주고 있는 이런 기술 용어에 대해 이런 글타래로 고민하는 분들도 있으니 관심도 가져주고 참고할 만한 것이 있는지 여쭤야 겠습니다.

혹시나 글을 보내 반응이 있고 관심을 주시면 그 분들을 꼬득여서 위키하나쯤 만들어 봐도 좋을 거라 생각합니다. 이런 글타래로 잠시 토닥거리다 지나가면 개인적인 고민거리로 남지만 위키라도 생기고 서로 의견이 올라가고 우리말에 대한 앎이 넘치는 분이 도와주신다면 좋은 자료로 남을 거라 생각합니다.

그래도 행복하지 않습니까? 온누리를 따지면 쓰임이 아주 작은말이지만 이렇게 작은 문화라도 지켜갈려고 토닥거리는 우리를 보면 저는 행복합니다. 줄루말도 니뽄말도 우리말도....오래오래.....우분투

잘라내기

잘라두기
오려두기

잘라, 오려의 차이 보다는 내기, 두기의 차이가 더 의미에 차이를 주는 것 같네요.

두기로 표현하는 것이 더 직관적인 느낌입니다. 내기는 필요없는 것을 치워 버린다는 느낌이 좀 나는 것 같습니다.


번역... 참 힙듭니다. : ) 어디서든 자꾸 토론해가면서 합의점을 찾아가야겠죠. ^^

프랙탈

그리고 복사는 한자어 인데 잘라내기 붙여넣기 등의 순우리말 사이에 있어서 어색해 보입니다. 베끼기로 바꾸시던지 글자수를 맞추어 복사하기로 바꾸셨으면 합니다.

오해가 있으신가 본데, 복사자체가 동사입니다. 하-를 붙이는 것은 우리말쓰기에 편리하도록 붙여쓰는 것입니다.
그리고 배끼기 보다는 배껴두기로하면 ㅤㄱㅙㄶ찬아 보입니다.

내다의 경우

내ː다3[타동사] 【‘나다1’의 사동】
1.밖(겉)으로 나가게 하다.
¶이삿짐을 밖으로 내다.
2.생기거나 일어나게 하다.
¶소리를 내다./불을 내다.
3.밖으로 드러나게 하다.
¶이름을 내다./소문을 내다.
4.틈(짬)을 만들다.
¶바빠서 시간을 내기가 힘들다.
5.길을 새로 만들다.
¶통로를 내다.
6.어떤 상태로 되게 하다. <-이 것으로 보입니다.
¶결말을 내다./두 동강을 내다.
7.윷놀이에서, 말을 날밭 밖으로 나게 하다.
¶두 동을 내다.
8.(구멍 따위를) 뚫다.
¶구멍을 내다.
9.힘(기운)을 더하다.
¶좀 더 속력을 내라.
10.발표하다.
¶광고를 내다.

그러나 두다의 경우

두다2[보조동사] 동사 어미 ‘-아(어)’의 뒤에 쓰이어, ‘그 동작의 결과를 그대로 지니다’의 뜻을 나타냄.
¶사람을 잡아 두다./양해를 얻어 두다.

잘라내다의 경우, 자른 상태로 되게하다인데, 이는 잘라낸 문서가 기준이 됩니다.
그럼, 위의 상태는 일부 삭제 및 1번의 실행취소와 다 바 없습니다.
차라리 실행 취소가 여러번 되는 문서, 그래픽, 소리 편집프로그램을 사용하는 것이 낫겠지요.

잘라두다의 경우, 자른 것의 결과를 지닌다는 것으로 그 의미와 사용이 동일합니다. 자른 목적(다른 곳에서 이용)이 훨씬 분명하게 드러납니다.

고로, 잘라두기, 오려두기가 옳다고 생각합니다.

차니 wrote:현재 파이어폭스를 번역하면서 가장 주안점을 둔 것은 IE와 용어를 따라가는 것입니다. 물론 IE 번역팀이 모두 맞는 것은 아닐것입니다. 그러나, 꽤 오랫동안 사람들에게 길들어진 용어를 그대로 차용함으로서 얻는 점은 이전 시 사용자들에게 편리함을 주기 때문입니다.

그들에게 오려두기나 베끼기 등은 생뚱맞을 수 밖에 없습니다. (저도 어색합니다.) 새로운 소프트웨어에서 어휘를 선택하는 데 단순히 사전적 고찰로 해결 하는 것은 별로 바람직 하지 않다고 생각합니다. 이미 있는 소프트웨어, 사람들이 많이 쓰는 용어 위주로 선택하는 것이 맞습니다. Firefox는 국어 순화를 위한 소프트웨어가 아님을 분명히 합니다. 게다가 사람들이 흔히 말하는 웹 표준을 위한 소프트웨어도 아닙니다.

첨부. 언급하신 것들 중에 보면...
왜 '잘라내기'와 '복사'로 했을까요? 자르다는 대체하는 단독 명사가 없습니다. 대산 복사하다는 복사처럼 해당되는 명사가 있죠. 이런 이유로 Insert도 삽입하기라고 하지 않고 삽입이라고 번역합니다.

앞으로 IE에서 선택한 용어 위주로 계속 가는 것은 기본적인 기조가 될 것입니다. 단, Firefox에서만 쓰는 단어들은 최대한 일반 용어나 영어 원문에 맞출 예정입니다.

IE가 좋은 용어를 선택하여 사용하고 있는데, 억지로 FF용을 새로 개발하는 무리수를 둘 필요는 절대로 없다고 봅니다.
하지만 IE에서 사용하는 것보다 더 적당한 용어가 있고, 또 바뀐다하여도 직관적으로 이해할 수 있다면, 당연히 바뀌어야 한다고 생각합니다.
또한가지 생각해 볼 것은, IE를 버리고 FF를 받아들이는 것이 어려울까요, FF에 있는 IE와 다른 용어를 받아들이는 것이 어려울까요?
히말리야를 넘은 등반가가 뒷동산 산책로가 바뀐것을 불평할까요?
차니님의 답변에 상당히 당황하고 있습니다.

xx1 wrote:

프랙탈

그리고 복사는 한자어 인데 잘라내기 붙여넣기 등의 순우리말 사이에 있어서 어색해 보입니다. 베끼기로 바꾸시던지 글자수를 맞추어 복사하기로 바꾸셨으면 합니다.

오해가 있으신가 본데, 복사자체가 동사입니다. 하-를 붙이는 것은 우리말쓰기에 편리하도록 붙여쓰는 것입니다.
그리고 배끼기 보다는 배껴두기로하면 ㅤㄱㅙㄶ찬아 보입니다.

복사하기에 관한 내용은 베끼기로 바꾸기 힘들다면 차선책으로 조형성이나 맞추자는 취지에서였습니다.

잘라내기
복사
붙여넣기

는 왠지 불안해 보이거든요.

잘라내기
복사하기
붙여넣기

가 훨씬 안정적으로 보입니다.
베껴두기가 더 좋아보이네요.
그리고 차니님께서 IE의 용어를 따라가는 것의 이점이 IE의 잘못된 번역을 고치는 것보다 더 이점이 크다 하셨는데, 그런 논리대로 라면 IE의 엑티브엑스 기능을 따라가는 것이 더 이점이 크고 사용자에게 편리하므로 엑티브엑스를 지원하자는 주장도 성립됩니다.
하지만 그렇게 하지 않는 이유는 엑티브엑스에 분명히 잘못된 점이 있기 때문이죠.
IE의 오역도 마찬가지 입니다.
현재는 사용자에게 편리할지 몰라도 이는 곧 낱말의 사용을 모호하게 만들고 혼란스럽게 만들어 현실에서의 낱말 사용에도 혼란을 야기시킬 겁니다.
머지않아 '김대리 오려(짤라)버려!!'따위의 말도 안되는 말이 쓰일지도 모르죠(비약이 너무 심한가요?)

프랙탈 wrote: 그리고 차니님께서 IE의 용어를 따라가는 것의 이점이 IE의 잘못된 번역을 고치는 것보다 더 이점이 크다 하셨는데, 그런 논리대로 라면 IE의 엑티브엑스 기능을 따라가는 것이 더 이점이 크고 사용자에게 편리하므로 엑티브엑스를 지원하자는 주장도 성립됩니다.
하지만 그렇게 하지 않는 이유는 엑티브엑스에 분명히 잘못된 점이 있기 때문이죠.
IE의 오역도 마찬가지 입니다.

이런 류의 비약을 제가 제일 싫어합니다.
용어와 액티브엑스와 무슨 차이가 있습니까?
용어는 보편 타당한 일종의 공감대이고 기능입니다.

그리고 파이어폭스가 액티브엑스를 지원안하는 것은 잘못된점이
(그게 뭔지모르지만) 있어서가 아니라 지원할 방법이 없기 때문입니다.
어떻게 크로스플랫폼 소프트웨어에 플랫폼 디펜던트 기술을 적용할 수
있습니까? 그건 할수 있는데 안하는게 아니라 못하는 겁니다.

그러면 ActiveX와 비슷한 자바애플릿도 지원하면 안되겠네요?
Adobe나 WMP 플러그인도 하면 안되겠구요.
왜 이건 지원 하는지 생각해 보세요. 확장 기능은 왜 만드는 겁니까.

모질라 프로젝트는 엔드유저가 보편 타당한 웹 기술을 좀 더 나은
기능 들로 경험할 수 해 주고 싶은 소프트웨어 개발 그 이상도 이하도
아닙니다.

Firefox를 MS니 ActiveX니 웹 표준용이니 하면서 그 가치를 다른
방향으로 해석하는 것이야 말로 이 프로젝트를 훼손시키는 나쁜 방법입니다.

(제가 여기서 웹 표준이나 ActivX 대안을 찾는 이유도 Firefox 사용자가
국내 웹 서핑을 좀 더 원할하게 해주고 싶은 마음 그 이상도 이하도 아니구요.)

makeittrue wrote:

차니 wrote:현재 파이어폭스를 번역하면서 가장 주안점을 둔 것은 IE와 용어를 따라가는 것입니다. 물론 IE 번역팀이 모두 맞는 것은 아닐것입니다. 그러나, 꽤 오랫동안 사람들에게 길들어진 용어를 그대로 차용함으로서 얻는 점은 이전 시 사용자들에게 편리함을 주기 때문입니다.

그들에게 오려두기나 베끼기 등은 생뚱맞을 수 밖에 없습니다. (저도 어색합니다.) 새로운 소프트웨어에서 어휘를 선택하는 데 단순히 사전적 고찰로 해결 하는 것은 별로 바람직 하지 않다고 생각합니다. 이미 있는 소프트웨어, 사람들이 많이 쓰는 용어 위주로 선택하는 것이 맞습니다. Firefox는 국어 순화를 위한 소프트웨어가 아님을 분명히 합니다. 게다가 사람들이 흔히 말하는 웹 표준을 위한 소프트웨어도 아닙니다.

첨부. 언급하신 것들 중에 보면...
왜 '잘라내기'와 '복사'로 했을까요? 자르다는 대체하는 단독 명사가 없습니다. 대산 복사하다는 복사처럼 해당되는 명사가 있죠. 이런 이유로 Insert도 삽입하기라고 하지 않고 삽입이라고 번역합니다.

앞으로 IE에서 선택한 용어 위주로 계속 가는 것은 기본적인 기조가 될 것입니다. 단, Firefox에서만 쓰는 단어들은 최대한 일반 용어나 영어 원문에 맞출 예정입니다.

IE가 좋은 용어를 선택하여 사용하고 있는데, 억지로 FF용을 새로 개발하는 무리수를 둘 필요는 절대로 없다고 봅니다.
하지만 IE에서 사용하는 것보다 더 적당한 용어가 있고, 또 바뀐다하여도 직관적으로 이해할 수 있다면, 당연히 바뀌어야 한다고 생각합니다.
또한가지 생각해 볼 것은, IE를 버리고 FF를 받아들이는 것이 어려울까요, FF에 있는 IE와 다른 용어를 받아들이는 것이 어려울까요?
히말리야를 넘은 등반가가 뒷동산 산책로가 바뀐것을 불평할까요?
차니님의 답변에 상당히 당황하고 있습니다.

차니님과 제가 일단 IE 를 기준으로 하자고 합의를 본 상태 입니다.

이유는, 차니님이 말씀하신 "길들어진 용어를 그대로 차용함으로서 얻는 점은 이전 시 사용자들에게 편리함" 이기는 합니다만, 이는 번역을 할 때의 용어 선택이 쉽지 않기 때문에 일단 IE 를 ㅤㅉㅗㅈ아 가는 것이 좋다고 생각하는 개인적인 판단에 동의를 한 것이기도 합니다.

물론, 어색하거나, 잘못된 것은 수정이 되어야 합니다.

하지만, 현재 FF 의 번역 수준은 좋지 않습니다. 1.0 에 비해서 1.5 에서 많이 다듬어 졌다고는 하지만, 여전히 문법적인 문제가 더 많이 남아있습니다. 그래서, 2.0 에서의 중점은 틀린 문법 찾기 이며, 용어의 선택에 대한 지적 보다는 여러분들의 문법 지적이 더 갈구되는 상황입니다. 그래서 일단 용어는 많은 사람들에게 익숙한 IE 를 일단 따라가자고 합의(?)를 본 상태 입니다.

물론, 차니님과 제가 한국어 버전에 대한 권한을 남용한다고 생각할 수도 있겠지만, 현실적으로 둘이서 하는 작업에, 모든 분들의 의견을 반영하기는 쉽지 않습니다.

작업을 하다 보면, 어디 어디가 이상해요.. 하고 리포팅을 해 주시면, 작업하는 사람은 수많은 메세지에서 어디 있는지 찾아 가면서 수정을 하는 작업이기 때문이기도 하고, freeze 되지 않은 영문 메세지 변경을 좆아가는 것도 쉬운일이 아닙니다.

여러분들의 훌륭한 뜻도 알겠지만, 그래도 아직은 모든 것을 반영하기는 쉽지 않고, 차근 차근 하나씩 밟아 나가도록 하겠습니다.

다시 말씀 드리지만.. 이번 버전에서의 주안점은..

1. 문법 오류 (띄어쓰기 포함)
2. 오타 (항상 있죠 ^^)
3. IE 와의 용어 통일

이 정도에서 리포팅을 해 주시면 감사하겠습니다.

참고로.. 저는 국어 수준이 상당히 좋지 않습니다. 여러분들의 도움이 있어야 합니다.

한국어판 모질라 프로젝트의 로드맵 필요성

한국어판 모질라 프로그램의 로드맵이 필요하다는 생각입니다.

현재 논의가 대립구도를 만들어가는 것으로 비추어지지 않았으면 합니다.

- 우리 말에 대한 존중과 이를 기반으로한 프로그램 단위에서 반영
- 현재의 수준에서 모질라 프로그램 사용자의 확대라는 현실적 욕구

이 부분은 누구나 공감하는 부분입니다. 그러나 문제의 선후/우선 순위에 있어서 강조점의 차이가 있다고 생각합니다.

문제는 현재 한국어판 모질라 프로젝트의 전체적인 일정이 없기에 사용자 단위에서는 아쉬움이 생길 수밖에 없다고 봅니다.

또 현재까지 한국어판 모질라 프로젝트에 있어, 로드맵이 필요한가라는 인식도 없었고, 모질라 재단의 로드맵 일정에 따라 번역작업이 이루어졌으니 이는 자연스러운 과정이였다고 생각합니다.

제안하자면, 차니님이 방어적 입장에서의 이야기를 풀어가기보단, [한국어판 모질라 프로젝트]에 대한 개요적 차원에서라도 [로드맵]을 작성해보심이 좋을듯합니다. 그리고 의견을 수렴하여, 최종적인 [로드맵]을 만들면 되겠죠.

이렇게되면, 현재의 번역문제 역시 자연스럽게 로드맵 안으로 수용될 수 있을 것이라 생각합니다.

소프트원트 wrote:한국어판 모질라 프로젝트의 로드맵 필요성

한국어판 모질라 프로그램의 로드맵이 필요하다는 생각입니다.

현재 논의가 대립구도를 만들어가는 것으로 비추어지지 않았으면 합니다.

- 우리 말에 대한 존중과 이를 기반으로한 프로그램 단위에서 반영
- 현재의 수준에서 모질라 프로그램 사용자의 확대라는 현실적 욕구

이 부분은 누구나 공감하는 부분입니다. 그러나 문제의 선후/우선 순위에 있어서 강조점의 차이가 있다고 생각합니다.

문제는 현재 한국어판 모질라 프로젝트의 전체적인 일정이 없기에 사용자 단위에서는 아쉬움이 생길 수밖에 없다고 봅니다.

또 현재까지 한국어판 모질라 프로젝트에 있어, 로드맵이 필요한가라는 인식도 없었고, 모질라 재단의 로드맵 일정에 따라 번역작업이 이루어졌으니 이는 자연스러운 과정이였다고 생각합니다.

제안하자면, 차니님이 방어적 입장에서의 이야기를 풀어가기보단, [한국어판 모질라 프로젝트]에 대한 개요적 차원에서라도 [로드맵]을 작성해보심이 좋을듯합니다. 그리고 의견을 수렴하여, 최종적인 [로드맵]을 만들면 되겠죠.

이렇게되면, 현재의 번역문제 역시 자연스럽게 로드맵 안으로 수용될 수 있을 것이라 생각합니다.

동의 합니다.
여기서 서로 소모적인 논쟁만 벌일것이 아니라 전체적인 번역 일정은 아니더라도 여기서 요구되었던 사항들은 언제쯤 반영될 수 있을지 정도는 정해 두는 편이 좋다고 생각합니다.

김정균 wrote:다시 말씀 드리지만.. 이번 버전에서의 주안점은..

1. 문법 오류 (띄어쓰기 포함)
2. 오타 (항상 있죠 ^^)
3. IE 와의 용어 통일

이 정도에서 리포팅을 해 주시면 감사하겠습니다.

참고로.. 저는 국어 수준이 상당히 좋지 않습니다. 여러분들의 도움이 있어야 합니다.

베껴두기등의 다른 문제는 제외하더라도 잘라내기의 문제는 1번과 2번 사이에서
서로 모순되는 애매한 문제라고 생각합니다.
우리가 말을 할때 필요한 부분은 오려둔다고 하지 잘라낸다고 하지는 않습니다.
한편, 필요없는 부분은 잘라낸다고 하지 오려둔다고 하지는 않습니다.
예를 들면, 사진등을 오릴 때 얼굴(또는 사람)을 오려두라고는 해도 잘라내라고는 하지 않습니다.
반면, 사진등을 오릴 때 가장자리를 잘라내라고는 해도 오려두라고는 하지 않습니다.
그러므로 문서에서 필요한 부분을 선택해서 오려두는 것을 잘라낸다고 표현하는 것은
명백한 문법적 오류입니다.

항상 생각하는 게 문제를 찾는 것도 중요하지만, 더 중요한 것은 방법을 찾아 해결해 가야 한다는 생각을 합니다.

차니님이 이 문제에 있어, 고정된 입장을 갖기보단 유연한 접근을 하길 바랍니다.

그리고 국소적인 문제의 옳고 그름은 피했으면 합니다. 큰 틀이 만들어지지 않은 속에서 누구의 옳고그름은 자존심 문제로 나갈 수 있지않을까 합니다.

그리고 현재 자바스크립트 콘솔의 경우, 필터(filter)를 거름개로 번역하고 있으므로 우리말 단어로 바꾸는 것이 적절하지 않다고만 할 수 없을 것같습니다. 물론 MS IE에서 필터(filter)라는 용어는 없기에, 이를 거름개로 했는 지는 모르겠습니다.

그리고 모질라 재단의 프로그램도 용어 선택 과정에서 변화가 있었음을 생각해야 합니다. 용어 선택뿐만 아니라 화면 구조 역시 변화하였습니다.

그 극적인 변화가 1.5 버전이죠. 저는 여전히 1.5 이전 버전의 화면 구조가 올바르다는 생각을 합니다. 아래 글은 1.5 정식판이 나오기 전 나이틀리 버전에 대한 생각을 적은 글입니다.

파이어폭스 최근 나이틀리버전 화면구조 올바른 방향인가?

그리고 과거에 XUL을 번역할 때, 김고명님과 세운 번역의 원칙은 가능한 [우리말]을 사용하도록 하자는 것이였습니다.

그래서, menu라는 것도 그냥 메뉴라고 하기보단, 차림표라고, popup window의 경우 팍뜸창 또는 톡뜸창, dropdown->내리펼침, tooltip을 도구찌, Label(라벨)을 띠말로 등등 ...

XUL 번역 당시 고명님과 나누었던, 의견들을 보려면 아래 링크에서 확인할 수 있습니다.

XUL 프로젝트 의견교환

한국어판 모질라 프로젝트가 번역 과정에서 우리글, 우리말 사용에 앞장서고 있다는 것도 다른 측면에서 보면, 홍보 효과가 되지않을까 합니다.

추가로 현재 저의 경우, 썬더버드는 영문 버전을 계속 사용하고 있는 데, 파이어폭스와 썬더버드 간의 용어의 불일치 사항은 없는 지 점검해볼 필요도 있지않나 하는 생각이 들었습니다.

김정균 wrote:물론, 차니님과 제가 한국어 버전에 대한 권한을 남용한다고 생각할 수도 있겠지만, 현실적으로 둘이서 하는 작업에, 모든 분들의 의견을 반영하기는 쉽지 않습니다.

남용한다고 생각하지 않습니다. 모든 사람의 의견 반영은 근본적으로 불가능하고, 결국에는 임의적으로 결정을 내릴 수밖에 없는 부분이 있으리라 여깁니다. 항상 감사하게 생각하고 있습니다.

김정균 wrote:다시 말씀 드리지만.. 이번 버전에서의 주안점은..

1. 문법 오류 (띄어쓰기 포함)
2. 오타 (항상 있죠 ^^)
3. IE 와의 용어 통일

이 정도에서 리포팅을 해 주시면 감사하겠습니다.

IE 와의 용어 통일은 같은 원문(영어)에 대한 통일입니까, 같은 기능에 대한 통일입니까?
FF를 번역하면서 어느 것을 만족시키기가 더 쉽던가요? 아니, 더 옳다고 생각하시는지요?
어느 것도 만족스럽게 만족시킬 수는 없지 않던가요?
(순수한 질문입니다.)

김정균 wrote:이유는, 차니님이 말씀하신 "길들어진 용어를 그대로 차용함으로서 얻는 점은 이전 시 사용자들에게 편리함" 이기는 합니다만, 이는 번역을 할 때의 용어 선택이 쉽지 않기 때문에 일단 IE 를 ㅤㅉㅗㅈ아 가는 것이 좋다고 생각하는 개인적인 판단에 동의를 한 것이기도 합니다.

'페이지 설정' 대신 '인쇄화면 설정', '즐겨찾기' 대신 '북마크' 등을 사용함으로해서 길들어진 용어를 그대로 차용함으로서 얻는 이점을 얼마나 저해 했는지 모르겠군요.

김정균 wrote:여러분들의 훌륭한 뜻도 알겠지만, 그래도 아직은 모든 것을 반영하기는 쉽지 않고, 차근 차근 하나씩 밟아 나가도록 하겠습니다.

결국은, 영원히 바뀌지 않을 수 있다는 뜻으로 확대 해석될 여지가 있군요. 이미 FF에서 사용하기 시작한 용어는 해를 거듭할 수록 길.들.여. 지고, 한 번 길들여 지면 길들여진 이점을 포기할 수 없고, 따라서 영원히 바꿀 수 없게되지 않을까 걱정이 됩니다. 이것이 논리의 비약으로 끝나길 빕니다.

지금까지 별로 참여/기여도 하지 않은 사람이 말도 많지요? 그렇게 생각하신다면, 한 귀로 흘려버리시고 잊어버리세요. 그렇지 않으시다면 새로운 번역 지침을 새우는 것에 대해 긍정적으로 검토해주시길 빕니다.
FF 사용하면서 항상 감사함을 느낍니다.

makeittrue wrote:

김정균 wrote:다시 말씀 드리지만.. 이번 버전에서의 주안점은..

1. 문법 오류 (띄어쓰기 포함)
2. 오타 (항상 있죠 ^^)
3. IE 와의 용어 통일

이 정도에서 리포팅을 해 주시면 감사하겠습니다.

IE 와의 용어 통일은 같은 원문(영어)에 대한 통일입니까, 같은 기능에 대한 통일입니까?
FF를 번역하면서 어느 것을 만족시키기가 더 쉽던가요? 아니, 더 옳다고 생각하시는지요?
어느 것도 만족스럽게 만족시킬 수는 없지 않던가요?
(순수한 질문입니다.)

순서가 애매해서 일지 모르겠지만.. 글에서 밝혔듯이.. 3번 IE 와의 용어 통일을 전제로 해서 1번과 2번에 대한 작업을 한다는 것입니다. 용어에 대해서는 의견이 분분하기 때문에 일일이 결론을 기다리면서 작업을 하기는 너무 힘듭니다. 그래서 일단은 IE 와의 통일을 전제로 한다는 것입니다.

옳다 그르다의 문제가 아니라.. 작업의 진행을 위함입니다.

makeittrue wrote:

김정균 wrote:이유는, 차니님이 말씀하신 "길들어진 용어를 그대로 차용함으로서 얻는 점은 이전 시 사용자들에게 편리함" 이기는 합니다만, 이는 번역을 할 때의 용어 선택이 쉽지 않기 때문에 일단 IE 를 ㅤㅉㅗㅈ아 가는 것이 좋다고 생각하는 개인적인 판단에 동의를 한 것이기도 합니다.

'페이지 설정' 대신 '인쇄화면 설정', '즐겨찾기' 대신 '북마크' 등을 사용함으로해서 길들어진 용어를 그대로 차용함으로서 얻는 이점을 얼마나 저해 했는지 모르겠군요.

위에서도 말했듯이.. IE 가 옳다고 한적은 없습니다. 그저 작업의 흐름을 원할히 함이 가장 중요하겠죠. 물론 차니님의 의견과 같지는 않습니다. 제가 IE 에 맞추자를 동의한 가장 큰 이유는 작업의 흐름 때문입니다.

토론이 나쁘지는 않지만, 막상 언어팩 작업할 때 토론을 하면, 작업자는 언제 끝날지 모르는 토론을 기다려서 반영할 정도의 여유가 없다는 것이 문제입니다. 언어팩 작업도 먹고 살기 위한 행위를 하면서 하는 일이기 때문에 더 그렇죠.

makeittrue wrote:

김정균 wrote:여러분들의 훌륭한 뜻도 알겠지만, 그래도 아직은 모든 것을 반영하기는 쉽지 않고, 차근 차근 하나씩 밟아 나가도록 하겠습니다.

결국은, 영원히 바뀌지 않을 수 있다는 뜻으로 확대 해석될 여지가 있군요. 이미 FF에서 사용하기 시작한 용어는 해를 거듭할 수록 길.들.여. 지고, 한 번 길들여 지면 길들여진 이점을 포기할 수 없고, 따라서 영원히 바꿀 수 없게되지 않을까 걱정이 됩니다. 이것이 논리의 비약으로 끝나길 빕니다.

지금까지 별로 참여/기여도 하지 않은 사람이 말도 많지요? 그렇게 생각하신다면, 한 귀로 흘려버리시고 잊어버리세요. 그렇지 않으시다면 새로운 번역 지침을 새우는 것에 대해 긍정적으로 검토해주시길 빕니다.
FF 사용하면서 항상 감사함을 느낍니다.

뭐 그럴 수도 있을 것입니다. 왜냐면 제가 3.0 때도 작업을 하라는 보장은 없으니까요. 또한, 저도 사람인지라, 그 때 마음이 어떻게 바뀔지는 모르니까요. 다만, 제가 참여한 1.0, 1.5, 2.0 작업을 하면서 분명히 진전은 있었다고 생각이 됩니다. 3.0 에서 그 진전이 멈추어 질 것이라 생각이 되지는 않습니다. 뭐 저도, 더이상 할 것이 없다고 생각이 되면, commit 을 그만 두겠죠. ^^;

그냥 작업을 하면서, 큰 목표를 가지고 할 수도 있겠지만, 큰 목표는 전체의 목표일 뿐이고, 언어팩 작업에서는 작은 목표를 (더 쉽게 말하면, 이룰 수 있는 목표를) 지향하여 큰 목표를 조금씩 조금씩 만족해 나가도록 하고 있습니다.

L10n 메세지에 대하여 좀더 유연한 업데이트 방식을 모질라에서 제공해 주기 전에는 솔직히 답이 없습니다. 이 부분에 대해서는 몇차레나 건의를 해 보았지만 거절 당했으니까요.

http://my.oops.org/39

를 보시면 mozilla 의 L10n 정책에 대한 불만을 보실 수 있을 것이며, (자세하게는 나와있지는 않습니다.) 이런 이유 때문에, 큰 목표를 이루어 내는데 쉽지 않고, 그래서 언어팩에서는 구현 가능한 목표를 세워서 가려고 하는 겁니다.

웁스 방문해 보았습니다.
"주는 거나 잘 받아 먹어" 아주 강한 멘트를 날리셨군요.
그정도 느낌을 받았다면, 뭐 더 이상 할 말이 없군요.

김정균 wrote:

makeittrue wrote:

김정균 wrote:다시 말씀 드리지만.. 이번 버전에서의 주안점은..

1. 문법 오류 (띄어쓰기 포함)
2. 오타 (항상 있죠 ^^)
3. IE 와의 용어 통일

이 정도에서 리포팅을 해 주시면 감사하겠습니다.

IE 와의 용어 통일은 같은 원문(영어)에 대한 통일입니까, 같은 기능에 대한 통일입니까?
FF를 번역하면서 어느 것을 만족시키기가 더 쉽던가요? 아니, 더 옳다고 생각하시는지요?
어느 것도 만족스럽게 만족시킬 수는 없지 않던가요?
(순수한 질문입니다.)

순서가 애매해서 일지 모르겠지만.. 글에서 밝혔듯이.. 3번 IE 와의 용어 통일을 전제로 해서 1번과 2번에 대한 작업을 한다는 것입니다. 용어에 대해서는 의견이 분분하기 때문에 일일이 결론을 기다리면서 작업을 하기는 너무 힘듭니다. 그래서 일단은 IE 와의 통일을 전제로 한다는 것입니다.

옳다 그르다의 문제가 아니라.. 작업의 진행을 위함입니다.

음... 제 질문은 같은 단어에 대해서 동일한 용어를 선택하는 식의 통일인가, 아니면 같은 기능에 대해서 동일한 용어를 선택하는가 하는 것입니다.
예를 들어 [Bookmark] 메뉴는 IE에 동일한 기능의 [즐겨찾기]가 있음에도 불구하고, 여전히(아마 앞으로도 쭉~) [북마크]로 번역하고 있습니다.
반면, [보기] 메뉴에 있는 [Sidebar]는 IE에 [탐색 창]에 해당하는 기능이라 [탐색 창]으로 번역되었습니다.
심지어는 [Navigation Toolbar]가 [도구 모음]로 둔갑을 했더군요. 아무리 IE를 따라 간다고 해도 이건 좀 지나치다고 느껴지더군요.

그래서 제 예기는 통일의 범위를 같은 단어는 같은 용어로 까지만 할 것인지, 같은 기능까지도 원문 단어가 달라도 같은 용어로 번역할 것인지를 묻는 것입니다.
IE를 따라 갈수밖에 없는 상황이라면 (옳고 그름의 문제가 아니라면) 범위를 어떻게 정하는 것이 바람직하다고 생각하시는지를 묻어 본 것입니다.

오늘 en-US에 기초해서 도움말 번역을 좀 해보았는데, 도움말 원문과 현재 선정되어 사용된 용어 사이의 괴리감을 좁히기가 쉽지 않더군요.