Merge pull request #172 from hyo-choi/main

Co-authored-by: bumkeyy <[email protected]>

Author: github-actions[bot]

docs/documentation/ko/reference/Decorators.md

@@ -155,7 +155,7 @@ first(): called
 클래스 데코레이터가 값을 반환하면 클래스가 선언을 제공하는 생성자 함수로 바꿉니다.
 
 > 참고  새 생성자 함수를 반환하도록 선택한 경우 원래 프로토타입을 유지 관리해야 합니다.
-런타임에 데코레이터를 적용하는 로직은 이 기능을 **대신해주지 않습니다.**
+> 런타임에 데코레이터를 적용하는 로직은 이 기능을 **대신해주지 않습니다.**
 
 다음은 `BugReport` 클래스에 적용된 클래스 데코레이터 (`@sealed`)의 예입니다.
 
@@ -283,8 +283,8 @@ function enumerable(value: boolean) {
 접근자 데코레이터는 선언 파일이나 다른 주변 컨텍스트(예: `선언` 클래스)에서 사용할 수 없습니다.
 
 > 참고  TypeScript는 단일 멤버에 대해 `get` 및 `set` 접근자를 데코레이팅 할 수 없습니다.
-대신 멤버의 모든 데코레이터를 문서 순서대로 지정된 첫 번째 접근자에 적용해야 합니다.
-왜냐하면, 데코레이터는 각각의 선언이 아닌 `get`과 `set` 접근자를 결합한 *프로퍼티 설명자*에 적용되기 때문입니다.
+> 대신 멤버의 모든 데코레이터를 문서 순서대로 지정된 첫 번째 접근자에 적용해야 합니다.
+> 왜냐하면, 데코레이터는 각각의 선언이 아닌 `get`과 `set` 접근자를 결합한 *프로퍼티 설명자*에 적용되기 때문입니다.
 
 접근자 데코레이터의 표현 식은 런타임에 다음 세 가지 인수와 함께 함수로 호출됩니다:
 
@@ -354,8 +354,8 @@ function configurable(value: boolean) {
 2. 멤버의 이름
 
 > 참고  TypeScript에서 `프로퍼티 데코레이터`가 초기화되는 방식으로 인해 *프로퍼티 설명자*가 프로퍼티 데코레이터에 대한 인수로 제공되지 않습니다.
-현재 프로토타입의 멤버를 정의할 때 인스턴스 프로퍼티를 설명하는 메커니즘이 없고 프로퍼티의 이니셜라이저를 관찰하거나 수정할 수 있는 방법이 없기 때문입니다. 반환 값도 무시됩니다.
-따라서 프로퍼티 데코레이터는 특정 이름의 프로퍼티가 클래스에 선언되었음을 관찰하는 데만 사용할 수 있습니다.
+> 현재 프로토타입의 멤버를 정의할 때 인스턴스 프로퍼티를 설명하는 메커니즘이 없고 프로퍼티의 이니셜라이저를 관찰하거나 수정할 수 있는 방법이 없기 때문입니다. 반환 값도 무시됩니다.
+> 따라서 프로퍼티 데코레이터는 특정 이름의 프로퍼티가 클래스에 선언되었음을 관찰하는 데만 사용할 수 있습니다.
 
 이 정보를 사용하여 다음 예와 같이 프로퍼티에 대한 메타데이터를 기록할 수 있습니다:
 
@@ -396,7 +396,7 @@ function getFormat(target: any, propertyKey: string) {
 `getFormat`이 호출되면 형식의 메타데이터 값을 읽습니다.
 
 > 참고  이 예제에는 `reflect-metadata` 라이브러리가 필요합니다.
-`reflect-metadata` 라이브러리에 대한 자세한 내용은 [메타데이터](#메타데이터-metadata)를 참조하십시오.
+> `reflect-metadata` 라이브러리에 대한 자세한 내용은 [메타데이터](#메타데이터-metadata)를 참조하십시오.
 
 ## 매개변수 데코레이터 (Parameter Decorators)
 
@@ -478,7 +478,7 @@ function validate(target: any, propertyName: string, descriptor: TypedPropertyDe
 그런 다음 `@validate` 데코레이터는 원래 메서드를 호출하기 전에 인수 유효성 검증하는 함수로 기존의 `greet` 메서드를 감쌉니다.
 
 > 참고  이 예제에는 `reflect-metadata` 라이브러리가 필요합니다.
-`reflect-metadata` 라이브러리에 대한 자세한 내용은 [메타데이터] (#메타데이터-metadata)를 참조하십시오.
+> `reflect-metadata` 라이브러리에 대한 자세한 내용은 [메타데이터] (#메타데이터-metadata)를 참조하십시오.
 
 ## 메타데이터 (Metadata)
 

docs/documentation/ko/reference/Module Resolution.md

@@ -7,7 +7,7 @@ translatable: true
 ---
 
 > 이번 섹션은 모듈에 대한 기초적인 지식을 전제로 합니다.
-더 많은 정보는 [모듈](./modules.md)을 보도록 하세요.
+> 더 많은 정보는 [모듈](./modules.md)을 보도록 하세요.
 
 *모듈 해석 (module resolution)* 은 컴파일러가 import가 무엇을 참조하는지 알아내기 위해 사용하는 프로세스입니다.
 `import { a } from "moduleA"`같은 import 문을 생각해보세요;

docs/documentation/ko/reference/Namespaces.md

@@ -10,7 +10,7 @@ translatable: true
 > TypeScript 1.5 버전부터 용어가 변경되었습니다.
 > "Internal modules" 은 "네임스페이스" 로 변경되었습니다.
 > "External modules" 은 "모듈" 로 변경되었습니다. 이는 [ECMAScript 2015](http://www.ecma-international.org/ecma-262/6.0/)의 용어와 통일시키기 위함입니다.
-(`module X {` 는 현재 선호되는 `namespace X {` 와 동일합니다.)
+> (`module X {` 는 현재 선호되는 `namespace X {` 와 동일합니다.)
 
 이 게시물에서는 TypeScript에서 네임스페이스(구 "internal modules")를 사용하여 코드를 구성하는 다양한 방법을 간략하게 설명합니다.
 위에서 설명했듯이, "internal modules" 은 "네임스페이스" 로 변경되었습니다.
@@ -283,4 +283,4 @@ declare namespace D3 {
 }
 
 declare var d3: D3.Base;
-```
+```