@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

from ko.reactjs.org.

아래의 용어들은 확정인 것 같아 확정에 추가 했습니다.
다른 의견 없으시면 위키에 반영하겠습니다. 😄

@taehwanno @gnujoow @beingbook @taggon

from ko.reactjs.org.

@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.

from ko.reactjs.org.

@taehwanno 아 제가 잘못 이해했습니다 ^^; key로 변경 했습니다.

from ko.reactjs.org.

At this point, it looks good to organize it and manage it by making it into an md file.

이쯤에서 정리한후 md파일로 만들어서 관리하는 것이 좋아 보입니다.

from ko.reactjs.org.

md 파일로 별도 관리하는 것에 다른 분들 이견이 없다면,
이번주 중으로 용어 의견 모두 취합해서 위키에 작성해놓도록 하겠습니다.

@hg-pyun

from ko.reactjs.org.

attribute에 관한 번역은 있는데 property 또는 properties에 대한 번역이 없는 것 같습니다. 둘 다 속성으로 번역할 수 있지만 의미가 조금 다른 만큼 attribute처럼 property도 프로퍼티로 번역하는 건 어떨까요?

from ko.reactjs.org.

@beingbook Concurrent UI Patterns (Experimental) 페이지 번역을 하시다가 질문하신 것 같네요 ㅎㅎ

검색을 해봤을 때 stable은 안정, 안정된으로 번역을 많이 하시는 것 같아요. 또한 release는 동사적 의미가 들어간 배포보다는 배포판, 배포 버전이 나아보이구요. 개인적으로는 아래처럼 가는게 어떨까 싶네요 ㅎㅎ

• stable release : 안정된 배포 버전, 안정된 배포판
• prelease : 시험 배포 버전, 시험 배포판

from ko.reactjs.org.

#2 이슈는 디스코드에서 논의된대로 조만간 닫힐 예정입니다. 추후에 표현과 단어에 대한 논의는 issue로 오픈해주세요
#601

from ko.reactjs.org.

We can also look at https://github.com/reactjs/reactjs.org-translation#make-a-glossary-and-style-guide here as a reference.

from ko.reactjs.org.

@gnujoow You got it. Thanks.

from ko.reactjs.org.

reactjs/zh-hans.react.dev#2
여기처럼 간단한 표로 용어들을 정리하면 좀 더 번역 하시는 분들께 도움이 될 것 같습니다.

@gnujoow 님의 첫번째 코멘트에 표로 작성을하고, 코멘트 수정 권한 있으신 분들은 다른 분들 의견/수정 요청 한 것들 표에 반영 하는 식으로 하면 어떨까요?

from ko.reactjs.org.

@hiddenest 가독성을 위한 의도적인 줄바꿈이라면 번역된 한글 문장의 길이에 따라 포맷을 유지하는게 좋을 것 같아요.

from ko.reactjs.org.

@taggon, @taehwanno 저도 동의 합니다. property도 추가 했습니다.

https://github.com/reactjs/ko.reactjs.org/wiki/Translate-Glossary

from ko.reactjs.org.

"effect" 관련 기타 의견 없어서 "effect"로 확정하겠습니다.

from ko.reactjs.org.

@gnujoow @taehwanno
Thank you. I will read it later :)

from ko.reactjs.org.

and... we can also check technical terms in here

from ko.reactjs.org.

#10

from ko.reactjs.org.

reactjs/zh-hans.react.dev#2 에서 정리된 용어들에서 중문을 없애고 올립니다. 제안 주시면 추가/수정 해놓도록 하겠습니다.

React

일반

번역하면 안되는 용어

번역하면 안되는 용어의 경우, 조사를 정하기 위해 읽는 법 항목이 필요

참고: @gnujoow @taehwanno @hg-pyun @taggon

from ko.reactjs.org.

나름대로 아래에 간단하게 정리해보았습니다. "또는"이라고 표기한 부분에 대해서는 의견을 모아 하나로 정하면 될 것 같습니다.

• 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: 크리에이트 리액트 앱

from ko.reactjs.org.

@taggon 님이 제안 주신 것 중에 아래 3가지는 이렇게 적용 해봤습니다.

• Stateful Component: 유상태 컴포넌트
• Application: 애플리케이션
• Function / Functional Components: 함수 컴포넌트

"Function / Functional Components" 이 부분의 경우 예전에는 함수로 된 컴포넌트를 functional component로 많이 쓰다가 현재는 용어상의 혼동으로 function 컴포넌트로 변경 된걸로 알고 있어서 함수 컴포넌트로 했습니다.

혹시 다른 의견있으시면 알려주세요.

감사합니다 👍

from ko.reactjs.org.

Example은 예제 (#9), 예시 (#17) 2가지로 번역되고 있네요.
제 생각으로는 문제의 성격보다는 보여준다는 의미에서 예시가 맞지 않을까 하는데 의견 부탁드릴게요.

• 예시 (네이버 국어사전)
• 예제 (네이버 국어사전)

from ko.reactjs.org.

fowardicng refs는 어떻게 해야 할까요?
#13 에서는 ref 넘겨주기/전달하기 정도로 번역하여 사용하고 있습니다만, forwarding ref 영문 표기를 그대로 할 지(API에 forwardRef이라는 함수가 있습니다.), 아니면 어떻게 순화할 지, 명확하게 정해야 할 것 같습니다.

from ko.reactjs.org.

• spec, specification 번역도 스펙, 명세로 될 수 있을 것 같네요. (#19) 명세가 알맞지 않나 생각하고 있어요.
• camelCase에 대해 캐멀케이스(#16), 카멜케이스(#19)도 존재해요.
• synthetic, synthetic event에 대한 번역도 논의가 필요해보여요. (#19)

from ko.reactjs.org.

spec, specifiation은 확실하게 번역이 되는만큼 명세로 가는게 좋을 것 같습니다.

from ko.reactjs.org.

• spec, specification은 명세
• camelCase는 캐멀케이스. 외래어 표기법에 따라 카멜(x), 캐멀(o)이라고 합니다.
• synthetic event는 기출간된 서적에서도 합성 이벤트로 번역되었으므로 이를 따르는 게 어떨까 합니다.

위와 같이 제안합니다.

from ko.reactjs.org.

표 추가/수정 했습니다.

• synthetic event: 합성 이벤트
• camelCase: 캐멀 케이스
• spec, specification: 명세
• example: 예시

어느 정도 논의가 완료 된것들은 "확정" 이라는 표시를 좀 할 필요가 있을 것 같네요.

from ko.reactjs.org.

#22 번에서 다른 분이 언급해주신 문제입니다.

JS 모듈을 가져온다는 의미로 import라고 그대로 적었는데 가져와서 사용할 수 있습니다. 혹은 불러와서 사용할 수 있습니다. 등으로 번역하는게 나을지 의견 여쭙고 싶습니다. - @hewonjeong

또한 export에 대한 논의도 필요해 보입니다.

from ko.reactjs.org.

building block에 대한 논의도 필요해보여요.

• 빌딩 블록 (Function - MDN)
• 작은 단위 (#16 (comment))
• 구성 블록 (#9)
• 구성 단위 (개인적인 제안)

block을 블록으로 번역할 때는 의미 전달이 명확하지 않다는 단점이 있는 것 같아요.
구성 단위 > 작은 단위 순서로 바람직한 방향이 아닐까 생각하고 있습니다. 의견 부탁드릴게요.

from ko.reactjs.org.

다음 용어에 대한 논의도 추가되었으면 합니다.
ref https://github.com/reactjs/ja.reactjs.org/wiki/%E8%A8%B3%E8%AA%9E%E3%81%AE%E7%B5%B1%E4%B8%80

from ko.reactjs.org.

Controlled/Uncontrolled Component: (State에 의한)제어/비제어 컴포넌트

가 어떨까요?

-ed의 의미를 살려 제어되지 않은, 제어된 컴포넌트로 번역할 수도 있지만, 컴포넌트가 "single source of truth"인 State를 제어(setState)하고, State의 값에 따라 render가 제어되는 의미를 전달하기가 약한것 같습니다

from ko.reactjs.org.

prop처럼 영문 그대로 써야하는지 헤깔렸어요. approved된 PR보고 자식으로 번역했는데 이것도 추가해놓으면 좋을 것 같습니다:)

from ko.reactjs.org.

escape hatch의 번역도 여러가지로 나뉘고 있어요.

• 해결책 #13 (comment)
• 탈출구 #28

2개로 나뉘는데 해결책으로 정리되고 있습니다.

from ko.reactjs.org.

@taehwanno 저도 조금 더 의미가 명확한 해결책을 지지합니다.

from ko.reactjs.org.

polyfill에 대한 번역도 정리가 할 필요가 있어보여요. (#28)
영문 위키피디아에서는 아래처럼 정의되고 있습니다.

A plugin that provides the functionality of newer browsers to older versions.

1. polyfill (원문 그대로 미번역 사용)
2. 폴리필 (발음 그대로 미번역 사용)
3. 구형 브라우저에 신형 브라우저의 기능을 제공하기 위한 플러그인인 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 입니다. 의견 부탁드릴게요 :)

from ko.reactjs.org.

폴리필은 구글 검색 결과 기준으로 "화살표 함수"와 거의 비슷한 수준으로 사용되고 있습니다. 한 문서에서 최초 등장시 폴리필(polyfill)처럼 병기해주고 이후에는 한국어만 써도 괜찮지 않을까요? 혹시 그래도 설명이 부족하다 싶으면 한국어 위키피디아 "폴리필" 항목을 참조하는 것도 괜찮아 보입니다.

from ko.reactjs.org.

좋아요~ 제시해주신 방향에 동의합니다.

from ko.reactjs.org.

hydrate는 구글에 "react + hydrate"로 검색하고 한국어 웹을 살펴보니 수화하다로 가장 많이 번역되고 있어요.

from ko.reactjs.org.

수화하다라는 말 자체도 안 익숙한데 이걸 기술 용어로 쓰기엔 무리가 있는 듯 합니다. hydrate 자체의 사전적 번역이 그렇다 하더라도요. 비슷한 용어로 명사형인 "하이드레이션(hydration)"이 있는데 화장품 업계에서 "수분 보충" 혹은 "수분 공급"이라는 의미로 사용됩니다.

참고로 미리엄 웹스터 영영 사전을 찾아보면 hydrate의 사전적 의미는 "수분을 흡수하도록 하다" 또는 "충분한 수분을 공급하다" 정도입니다. 해당 기능이 서버에서 이벤트 없이 렌더링된 마크업에 이벤트 핸들러를 추가하기 때문에 이런 이름을 붙였다 생각합니다. 아래는 hydrate() 메서드의 설명에서 발췌했습니다.

React will attempt to attach event listeners to the existing markup.

따라서 저는 리액트에서 hydrate는 "수분을 보충하듯 이벤트를 보충하다"를 의미한다고 생각합니다. 그래서 번역어를 수화하다보다는 이벤트를 보충하다로 사용하는 건 어떨까 싶습니다.

from ko.reactjs.org.

@taggon 저도 수화하다 자체가 와닿지 않아서 고민하고 있었어요. 말씀해주신 "이벤트를 보충하다"에 동의합니다 :)
@simsim0709 국립국어원 우리말샘에 따라 써드파티 -> 서드파티로 변경해야할 것 같아요.

from ko.reactjs.org.

• form도 번역하면 안되는 용어로 올려야할 것 같아요. 기존 제출된 Pull Request (#16, #28)에서 번역되지 않고 원문 그대로 사용되고 있습니다.
• mount, unmount를 마운트, 마운트 해제로 제안드려봅니다.

from ko.reactjs.org.

https://github.com/reactjs/ko.reactjs.org/wiki/Translate-Glossary

위키에 확정된 용어들 정리해서 올려 두었습니다.

나머지 아직 다른 분들의 의견이나 논의가 필요한 것들 다시 표로 만들었습니다.

추가적인 의견있으면 알려주세요. 이곳에 논의되는 것들은 최대한 정리 하다록 하겠습니다.

from ko.reactjs.org.

'wrapper'에 대한 번역은 그냥 '래퍼'로 하면 될까요? 좋은 우리말 표현을 잘 모르겠네요.
TTA에서 검색해보니 '랩퍼'라고 표기하는 것도 보이는데 '래퍼'가 맞는 것 같네요.

from ko.reactjs.org.

key도 키보다는 번역하지 않고 유지하는게 나을거 같아요. (#12)

from ko.reactjs.org.

추가 했습니다.
@beingbook @taehwanno

from ko.reactjs.org.

@simsim0709 key를 제안했었는데 키가 더 나을까요? 특정 props를 의미하다보니 원문 그대로 쓰는게 좋지 않을까요?

from ko.reactjs.org.

props로 사용되는 key는 번역을 안하는 것이 맞는 것 같습니다.

from ko.reactjs.org.

note에 대해서는 주의(notice)로 해석하는게 어떨까요?

from ko.reactjs.org.

note에 대해서는 주의(notice)로 해석하는게 어떨까요?

좋아요. #9 (comment)

from ko.reactjs.org.

getDerivedStateFromProps() 메서드와 같은 곳에서 사용되는 derive는 어떻게 번역을 해야 적절할까요?

• 가져온 state
• 끌어온 state
• derived state

가져온이라고 단순히 번역을 하자니 (props로부터 가져온) 이라는 문맥이 살지 않을 듯 하고... 좋은 방법이 아직 안 떠오르네요. 좋은 의견 부탁드립니다.

from ko.reactjs.org.

Memoizing에 대한 번역도 논의할 수 있다면 좋을 것 같아요. #12 (comment)

from ko.reactjs.org.

추가 했습니다.

@cadenzah @taehwanno

from ko.reactjs.org.

#13 에서는 Ref forwarding을 Ref 전달하기 로 번역되었습니다.

from ko.reactjs.org.

#55 Code-Splitting 에 대한 논의도 필요해 보입니다.
제가 보기에는 코드 쪼개기 정도로 번역하여도 문제가 없어 보입니다.

from ko.reactjs.org.

reconciliation 제안 그대로 재조정으로 번역해도 될 것 같습니다.
reconciliation 문서 읽어보면 이전 트리와의 추후 트리의 차이점을 찾아 갱신해주는 과정인데 재조정보다 나은 단어가 안떠오르네요^^;

from ko.reactjs.org.

#55 Code-Splitting 에 대한 논의도 필요해 보입니다.
제가 보기에는 코드 쪼개기 정도로 번역하여도 문제가 없어 보입니다.

@ENvironmentSet 제 생각에는 1. 원문 그대로 표기 2. 코드 스플리팅 3.코드 나누기 4.코드 쪼개기 순서대로 괜찮은 것 같아요. #12 에서는 이미 원문으로 표기해달라고 리뷰를 해드린 상황이에요. 변경된다면 따로 변경하도록 할게요.

from ko.reactjs.org.

split은 ‘분할’로 번역되는 걸 종종 본 기억이 있습니다. ‘코드 분할’은 어떤가요? React와 코드 분할을 함께 검색해보면 이미 여러 문서에서 code splitting을 코드 분할로 번역하고 있음을 알 수 있습니다.

from ko.reactjs.org.

Reconcilliation = 재조정
에 한 표 더합니다.

from ko.reactjs.org.

split은 ‘분할’로 번역되는 걸 종종 본 기억이 있습니다. ‘코드 분할’은 어떤가요? React와 코드 분할을 함께 검색해보면 이미 여러 문서에서 code splitting을 코드 분할로 번역하고 있음을 알 수 있습니다.

그렇네요. 구글 검색으로 확인했습니다. 코드 분할에 동의해요.

from ko.reactjs.org.

Glossary에 적합한지는 모르겠습니다만, 아래와 같은 경우에 원문의 포맷을 그대로 유지하는 것이 좋을까요?

ex)
원문: 아래와 같이 영역별로 엔터로 구분됨

This code will not work if you transform classes with Babel. See this issue for the discussion. (⌨️)
Include the custom-elements-es5-adapter before you load your web components to fix this issue.

번역: 두 개가 합쳐져 있음

Babel로 클래스를 변환하면 이 코드가 작동하지 않을 것입니다. 해당 문제를 참조해주시기 바랍니다. 이 문제를 해결하려면 웹 컴포넌트를 불러오기 전에 custom-elements-es5-adapter를 추가하기 바랍니다.

from ko.reactjs.org.

@taehwanno 제가 보기에도 코드 분할이 적합해 보입니다.

from ko.reactjs.org.

@taggon @ENvironmentSet 알겠습니다. 그럼 코드 분할로 리뷰할게요 :)

from ko.reactjs.org.

4가지 용어 추가했습니다.

그리고 리마인드 차원에서 의견이 나왔지만 아직 확정되지 않은 용어들입니다.

from ko.reactjs.org.

@taggon 저도 이거 고민했었는데 좋은 방향이라 생각해요. 동의합니다.

from ko.reactjs.org.

Hook은 번역하지 않는게 맞는거 같은데, 의견 있으신가요?
그리고 Hook, Hooks 모두 Hook으로 통일하는게 어떨까 싶은데요.
@gnujoow @taehwanno @hg-pyun @taggon

from ko.reactjs.org.

@simsim0709 Hook으로 통일에 동의합니다.

from ko.reactjs.org.

@simsim0709 저도 Hook에 동의합니다 :)

from ko.reactjs.org.

https://github.com/reactjs/ko.reactjs.org/wiki/Translate-Glossary 에 Hook 추가 했습니다.

from ko.reactjs.org.

https://github.com/reactjs/ko.reactjs.org/pull/89/files#diff-c38ef803fe7e7fc860f577c958440873L116에 보면 useEffect를 설명 할 때, effect라는 단어가 고유 단어처럼 사용되고 있습니다. 이렇게 사용되는 부분이 많은데 이 단어는 번역하지 않는게 어떨까 합니다.
@gnujoow @taehwanno @hg-pyun @taggon

from ko.reactjs.org.

@simsim0709 좋습니다. 작용, 부작용의 작용도 가능할 것 같지만 hooks의 use 뒤에 사용되는 단어가 특정 맥락을 지닌 고유 단어처럼 사용되는 경우가 많기에 번역하지 않고 그대로 effect로 가는 방향에 동의합니다.

from ko.reactjs.org.

stable release는 따로 정해진게 없을까요?

from ko.reactjs.org.

todo

• 위에서 진행된 논의중에서 위키에서 빠진것이 없는지 확인하기

from ko.reactjs.org.