ko.react.dev
ko.react.dev copied to clipboard
reactjs
translate glossary
ko.reactjs.org/content/docs/reference-glossary.md
https://github.com/reactjs/ko.reactjs.org/blob/master/content/docs/reference-glossary.md
for better translation, translate glossary can help contributors understand how to translate technical terms.
@gnujoow Hi. If you want to translate glossary, I think you can refer to this link. This link was maintained by reactkr. But it does not seem to be maintained based on this issue after React v0.14.0-alpha.
@taehwanno @hg-pyun
We haven't set translation rules, but if you don't mind, I'll translate glossary by next tuesday.
I will do with following rules:
- 문서의 내용이 친근하게 다가올 수 있도록 경어체를 사용하여 번역합니다.
- 고유명사는 원문 그대로 사용합니다. (예, React, Facebook)
- 기술용어 / 합성어는 최대한 번역하되 의미가 와닿지 않는 경우에는 음역으로 표시합니다.
(예, lifecycle method -> 생명주기 함수 / Component -> 컴포넌트 )
ref https://wiki.ubuntu.com/UbuntuKoreanTranslators
We can also look at https://github.com/reactjs/reactjs.org-translation#make-a-glossary-and-style-guide here as a reference.
https://github.com/reactjs/zh-hans.reactjs.org/issues/2 여기처럼 간단한 표로 용어들을 정리하면 좀 더 번역 하시는 분들께 도움이 될 것 같습니다.
@gnujoow 님의 첫번째 코멘트에 표로 작성을하고, 코멘트 수정 권한 있으신 분들은 다른 분들 의견/수정 요청 한 것들 표에 반영 하는 식으로 하면 어떨까요?
reactjs/zh-hans.reactjs.org#2 에서 정리된 용어들에서 중문을 없애고 올립니다. 제안 주시면 추가/수정 해놓도록 하겠습니다.
React
| 용어 | 번역 |
|---|---|
| Tutorial | 자습서 |
| Declarative | 선언적인 |
| Component | 컴포넌트 |
| Stateful Component | 유상태 컴포넌트 |
| Stateless Component | 무상태 컴포넌트 |
| render | 렌더링하다 |
| data | 데이터 |
| Application | 애플리케이션 |
| External Plugins | 외부 플러그인 |
| Third Plugins | 써드파티 플러그인 |
| syntax | 문법 |
| Embedding Expressions | 표현식 포함하기 |
| Attributes | 어트리뷰트 |
| Elements | 엘리먼트 |
| Function / Functional Components | 함수 컴포넌트 |
| Class Components | 클래스 컴포넌트 |
| Composition | 합성 |
| Inheritance | 상속 |
| Lifecycle | 생명주기 |
| Handling Events | 이벤트 처리 |
| Conditional Rendering | 조건부 렌더링 |
| Operator | 연산자 |
| reuse | 재사용 |
| mock | 모의 |
| callback | 콜백 |
| synthetic event | 합성 이벤트 |
| forwarding ref |
일반
| 용어 | 번역 |
|---|---|
| Tip | 팁 |
| Note | |
| example | 예시 |
| chapter | 장 |
| spec, specifiation | 명세 |
| camelCase | 캐멀 케이스 |
번역하면 안되는 용어
번역하면 안되는 용어의 경우, 조사를 정하기 위해 읽는 법 항목이 필요
| 용어 | 읽는 법 |
|---|---|
| props | 프로퍼티즈. 단수형이라면 프로퍼티 |
| state | 스테이트 |
| context | 컨텍스트 |
| DOM | 돔 |
| ref | 레퍼런스 |
| fragments | 프래그먼츠. 단수형은 프래그먼트 |
| portal | 포탈 |
| class | 클래스 |
| Web（대문자로 된 Web의 경우 번역하지 않음） | 웹 |
| UI | 유아이 |
| Tick | 틱 |
| bundle | 번들 |
| package | 패키지 |
| Create React App | 크리에이트 리액트 앱 |
참고: @gnujoow @taehwanno @hg-pyun @taggon
나름대로 아래에 간단하게 정리해보았습니다. "또는"이라고 표기한 부분에 대해서는 의견을 모아 하나로 정하면 될 것 같습니다.
- Tutorial: 자습서
- Declarative: 선언적인
- Component: 컴포넌트
- Stateful Component: 유상태 컴포넌트 또는 상태 보유 컴포넌트.
- Stateless Component: 무상태 컴포넌트. stateless protocol의 번역으로 '무상태 프로토콜'이 널리 사용되길래 비슷하게 맞추어 보았습니다.
- render: 렌더링하다
- data: 데이터
- Application: 애플리케이션 또는 응용프로그램. 원칙적으로는 응용프로그램으로 번역하는 게 맞지만 실무에서는 애플리케이션을 많이 사용해서 번역하다보면 현실과 동떨어진 느낌이 들 때가 있습니다.
- External Plugins: 외부 플러그인
- Third Plugins: 써드파티 플러그인
- syntax: 문법
- Embedding Expressions: 표현식 포함하기.
- Attributes: 속성 또는 어트리뷰트.
- Elements: 엘리먼트
- Function / Functional Components: 함수형 컴포넌트. "함수 ~"와 "함수형 ~" 중 구글 검색 결과에서 월등히 많은 쪽을 택했습니다.
- Class Components: 클래스 컴포넌트
- Composition: 합성. React의 많은 개념이 함수형 프로그래밍 언어에서 왔는데, 그 쪽에서는 "합성"이 널리 통용됩니다.
- Inheritance: 상속
- Lifecycle: 생명주기
- Handling Events: 이벤트 처리
- Conditional Rendering: 조건부 렌더링
- Operator: 연산자
- reuse: 재사용
- mock: 모의~. mock만 사용되기보다 아마 mock component나 mock function 등으로 주로 사용될텐데 이 때 "모의"라고 붙이는 번역이 많습니다. 혹시 동사로 사용되었다면 "흉내내다"가 적당할 것 같습니다.
- callback: 콜백
번역하면 안되는 용어의 경우, 읽는 법 항목이 필요할 수 있습니다. 읽는 법이 정해져야 조사를 정할 수 있으니까요. 아래와 같이 정리해보았습니다.
- props: 프로퍼티즈. 단수형이라면 프로퍼티
- state: 스테이트
- context: 컨텍스트
- DOM: 돔
- ref: 레퍼런스
- fragments: 프래그먼츠. 단수형은 프래그먼트
- portal: 포탈
- class: 클래스
- Web: 웹
- UI: 유아이
- Tick: 틱
- bundle: 번들
- package: 패키지
- Create React App: 크리에이트 리액트 앱
@taggon 님이 제안 주신 것 중에 아래 3가지는 이렇게 적용 해봤습니다.
- Stateful Component: 유상태 컴포넌트
- Application: 애플리케이션
- Function / Functional Components: 함수 컴포넌트
"Function / Functional Components" 이 부분의 경우 예전에는 함수로 된 컴포넌트를 functional component로 많이 쓰다가 현재는 용어상의 혼동으로 function 컴포넌트로 변경 된걸로 알고 있어서 함수 컴포넌트로 했습니다.
혹시 다른 의견있으시면 알려주세요.
감사합니다 👍
Example은 예제 (#9), 예시 (#17) 2가지로 번역되고 있네요.
제 생각으로는 문제의 성격보다는 보여준다는 의미에서 예시가 맞지 않을까 하는데 의견 부탁드릴게요.
fowardicng refs는 어떻게 해야 할까요?
#13 에서는 ref 넘겨주기/전달하기 정도로 번역하여 사용하고 있습니다만, forwarding ref 영문 표기를 그대로 할 지(API에 forwardRef이라는 함수가 있습니다.), 아니면 어떻게 순화할 지, 명확하게 정해야 할 것 같습니다.
- spec, specification 번역도
스펙,명세로 될 수 있을 것 같네요. (#19)명세가 알맞지 않나 생각하고 있어요. - camelCase에 대해 캐멀케이스(#16), 카멜케이스(#19)도 존재해요.
synthetic,synthetic event에 대한 번역도 논의가 필요해보여요. (#19)
spec,specification은명세camelCase는캐멀케이스. 외래어 표기법에 따라 카멜(x), 캐멀(o)이라고 합니다.synthetic event는 기출간된 서적에서도합성 이벤트로 번역되었으므로 이를 따르는 게 어떨까 합니다.
위와 같이 제안합니다.
표 추가/수정 했습니다.
- synthetic event: 합성 이벤트
- camelCase: 캐멀 케이스
- spec, specification: 명세
- example: 예시
어느 정도 논의가 완료 된것들은 "확정" 이라는 표시를 좀 할 필요가 있을 것 같네요.
#22 번에서 다른 분이 언급해주신 문제입니다.
JS 모듈을 가져온다는 의미로
import라고 그대로 적었는데가져와서 사용할 수 있습니다.혹은불러와서 사용할 수 있습니다.등으로 번역하는게 나을지 의견 여쭙고 싶습니다. - @hewonjeong
또한 export에 대한 논의도 필요해 보입니다.
building block에 대한 논의도 필요해보여요.
- 빌딩 블록 (Function - MDN)
- 작은 단위 (https://github.com/reactjs/ko.reactjs.org/pull/16#discussion_r255340163)
- 구성 블록 (#9)
- 구성 단위 (개인적인 제안)
block을 블록으로 번역할 때는 의미 전달이 명확하지 않다는 단점이 있는 것 같아요.
구성 단위 > 작은 단위 순서로 바람직한 방향이 아닐까 생각하고 있습니다. 의견 부탁드릴게요.
다음 용어에 대한 논의도 추가되었으면 합니다. ref https://github.com/reactjs/ja.reactjs.org/wiki/%E8%A8%B3%E8%AA%9E%E3%81%AE%E7%B5%B1%E4%B8%80
| 용어 | 제안 |
|---|---|
| higher order component | 고차컴포넌트와 영문 병기, 혹은 영문으로 사용 |
| Portals | 원문 그대로 사용 |
| Shallow Renderer | 얕은 렌더링 |
| reconciliation | 재조정 |
| reconciler | |
| imperative | |
| uncontrolled component | |
| controlled component |
Controlled/Uncontrolled Component: (State에 의한)제어/비제어 컴포넌트
가 어떨까요?
-ed의 의미를 살려 제어되지 않은, 제어된 컴포넌트로 번역할 수도 있지만, 컴포넌트가 "single source of truth"인 State를 제어(setState)하고, State의 값에 따라 render가 제어되는 의미를 전달하기가 약한것 같습니다
| 용어 | 제안 |
|---|---|
| children | 자식 |
prop처럼 영문 그대로 써야하는지 헤깔렸어요. approved된 PR보고 자식으로 번역했는데 이것도 추가해놓으면 좋을 것 같습니다:)
At this point, it looks good to organize it and manage it by making it into an md file.
이쯤에서 정리한후 md파일로 만들어서 관리하는 것이 좋아 보입니다.
md 파일로 별도 관리하는 것에 다른 분들 이견이 없다면, 이번주 중으로 용어 의견 모두 취합해서 위키에 작성해놓도록 하겠습니다.
@hg-pyun
escape hatch의 번역도 여러가지로 나뉘고 있어요.
해결책https://github.com/reactjs/ko.reactjs.org/pull/13#discussion_r255336377탈출구#28
2개로 나뉘는데 해결책으로 정리되고 있습니다.
polyfill에 대한 번역도 정리가 할 필요가 있어보여요. (#28) 영문 위키피디아에서는 아래처럼 정의되고 있습니다.
A plugin that provides the functionality of newer browsers to older versions.
- polyfill (원문 그대로 미번역 사용)
- 폴리필 (발음 그대로 미번역 사용)
- 구형 브라우저에 신형 브라우저의 기능을 제공하기 위한 플러그인인 polyfill (의미 그대로 풀어서 번역 후 같이 사용)
위 3가지 방향이 가능할 것 같아요. 3번은 좀 길다는 단점이 있어요. 아래는 3번에 대한 예시입니다.
- 원문
React supports all popular browsers, including Internet Explorer 9 and above, although some polyfills are required for older browsers such as IE 9 and IE 10
- 번역
React는 Internet Explorer 9와 상위 버전을 포함한 모든 주요 브라우저를 지원합니다. 그러나 IE 9와 IE 10과 같은 구형 브라우저는 구형 브라우저에 신형 브라우저의 기능을 제공하기 위한 플러그인인 polyfill이 필요합니다.
제 개인적인 의견은 3 > 1 > 2 입니다. 의견 부탁드릴게요 :)
폴리필은 구글 검색 결과 기준으로 "화살표 함수"와 거의 비슷한 수준으로 사용되고 있습니다. 한 문서에서 최초 등장시 폴리필(polyfill)처럼 병기해주고 이후에는 한국어만 써도 괜찮지 않을까요? 혹시 그래도 설명이 부족하다 싶으면 한국어 위키피디아 "폴리필" 항목을 참조하는 것도 괜찮아 보입니다.