Merge branch 'microsoft:main' into main

Author: yuriwithowsky

.github/CODEOWNERS

@@ -1,11 +1,11 @@
 # See https://github.com/OSS-Docs-Tools/code-owner-self-merge#readme
 
 # Collaborators for Japanese Translation of the Website
-docs/playground/ja @sasurau4 @Quramy @Naturalclar [translation] [jp]
-docs/tsconfig/ja/**/*.md @sasurau4 @Quramy @Naturalclar [translation] [jp]
-docs/typescriptlang/ja/**/*.ts @sasurau4 @Quramy @Naturalclar [translation] [jp]
-docs/typescriptlang/ja.ts @sasurau4 @Quramy @Naturalclar [translation] [jp]
-docs/documentation/ja/**/*.md @sasurau4 @Quramy @Naturalclar [translation] [jp]
+docs/playground/ja @sasurau4 @Quramy @Naturalclar @uraway [translation] [jp]
+docs/tsconfig/ja/**/*.md @sasurau4 @Quramy @Naturalclar @uraway [translation] [jp]
+docs/typescriptlang/ja/**/*.ts @sasurau4 @Quramy @Naturalclar @uraway [translation] [jp]
+docs/typescriptlang/ja.ts @sasurau4 @Quramy @Naturalclar @uraway [translation] [jp]
+docs/documentation/ja/**/*.md @sasurau4 @Quramy @Naturalclar @uraway [translation] [jp]
 
 # Collaborators for Portuguese Translation of the Website
 docs/playground/pt @khaosdoctor @danilofuchs [translation] [pt]
@@ -29,11 +29,11 @@ docs/typescriptlang/zh.ts @Kingwl [translation] [zh]
 docs/documentation/zh/**/*.md @Kingwl [translation] [zh]
 
 # Collaborators for Korean Translation of the Website
-docs/playground/ko @Bumkeyy @yeonjuan @guyeol @dvlprsh [translation] [ko]
-docs/tsconfig/ko/**/*.md @Bumkeyy @yeonjuan @guyeol @dvlprsh [translation] [ko]
-docs/typescriptlang/ko/**/*.ts @Bumkeyy @yeonjuan @guyeol @dvlprsh [translation] [ko]
-docs/typescriptlang/ko.ts @Bumkeyy @yeonjuan @guyeol @dvlprsh [translation] [ko]
-docs/documentation/ko/**/*.md @Bumkeyy @yeonjuan @guyeol @dvlprsh [translation] [ko]
+docs/playground/ko @bumkeyy @yeonjuan @guyeol @dvlprsh [translation] [ko]
+docs/tsconfig/ko/**/*.md @bumkeyy @yeonjuan @guyeol @dvlprsh [translation] [ko]
+docs/typescriptlang/ko/**/*.ts @bumkeyy @yeonjuan @guyeol @dvlprsh [translation] [ko]
+docs/typescriptlang/ko.ts @bumkeyy @yeonjuan @guyeol @dvlprsh [translation] [ko]
+docs/documentation/ko/**/*.md @bumkeyy @yeonjuan @guyeol @dvlprsh [translation] [ko]
 
 # Collaborators for Indonesian Translation of the Website
 docs/playground/id @jefrydco @nusendra @mazipan @mandaputtra [translation] [id]

attribution.json

@@ -0,0 +1,194 @@
+---
+title: TypeScript pour les Développeurs Java/C#
+short: TS pour les Développeurs Java/C#
+layout: docs
+permalink: /fr/docs/handbook/typescript-in-5-minutes-oop.html
+oneline: Apprenez TypeScript si vous avez de l'expérience avec les langages orientés objet
+---
+
+TypeScript est un choix populaire pour les développeurs habitués aux autres langages à typage statique, comme le C# et le Java.
+
+Le système de types de TypeScript offre la plupart de ces bénéfices : meilleure complétion de code, détection d'erreurs plus précoce, communication plus claire entre les composantes de votre programme.
+TypeScript fournit plusieurs fonctionnalités familières à ces développeurs, mais il est intéressant de faire un pas en arrière et apprendre comment le JavaScript (et par conséquent, TypeScript) diffère des langages orientés objet traditionnels.
+Comprendre ces différences vous permettra d'écrire du code JavaScript de meilleure qualité, et d'éviter les pièges communs dans lesquels les développeurs passant de C#/Java à TypeScript peuvent tomber.
+
+## Apprendre le JavaScript
+
+Si vous êtes déjà familier avec le JavaScript, mais vous êtes principalement un développeur Java ou C#, cette page d'introduction peut expliquer certaines idées fausses et pièges auxquels vous seriez susceptible.
+Certaines façons avec lesquelles TypeScript modélise les types sont très différentes du Java ou du C#. Il est important de s'en souvenir en apprenant TypeScript.
+
+Si vous êtes un développeur Java ou C#, et vous êtes nouveau avec JavaScript en général, nous recommandons d'apprendre un peu de JavaScript _sans les types_ d'abord, afin de comprendre son comportement lors de l'exécution.
+Vu que TypeScript ne change pas comment votre code _s'exécute_, vous devrez quand même apprendre le JavaScript pour écrire du code qui fait réellement quelque chose !
+
+Il est important de se rappeler que TypeScript utilise le même _runtime_ que le JavaScript, donc toute ressource sur comment accomplir un comportement particulier (conversion d'un string à un nombre, affichage d'une alerte, écriture d'un fichier, etc.) s'appliquera également en TypeScript.
+Ne vous limitez pas à ce qui est spécifique à TypeScript !
+
+## Repenser les classes
+
+Le C# et le Java sont ce qu'on pourrait appeler des langages à _POO obligatoire_.
+Dans ces langages, la _classe_ est l'unité basique d'organisation de code, ainsi que le conteneur de base de toutes les données _et_ de la logique à l'exécution.
+Obliger toute la fonctionnalité et toutes les données à être contenues dans des classes peut être un bon modèle de domaine pour certains problèmes, mais tous les modèles _ne doivent pas_ être représentés de cette façon.
+
+### Fonctions et données libres
+
+En JavaScript, les fonctions peuvent être placées n'importe où, et les données peuvent être librement relayées sans être cantonnées à une `class` ou une `struct`.
+Cette flexibilité est extrêmement puissante.
+Ces fonctions "libres" (celles qui ne sont pas associées à une classe), qui travaillent sur des données sans hiérarchie orientée objet, ont tendance à être le modèle préféré pour écrire un programme en JavaScript.
+
+### Classes statiques
+
+De plus, certaines structures du C# et du Java, comme les singletons et les classes statiques, ne sont pas nécessaires en TypeScript.
+
+## POO en TypeScript
+
+Cela dit, vous pouvez quand même utiliser des classes si vous le souhaitez !
+Certains problèmes ont une solution qui correspond à l'approche POO classique, et la capacité de TypeScript à supporter les classes JavaScript rendra ces solutions encore plus puissantes.
+TypeScript supporte plusieurs patterns comme l'implémentation d'interfaces, l'héritage, et les méthodes statiques.
+
+Nous couvrirons les classes plus tard dans ce guide.
+
+## Repenser les types
+
+La façon dont TypeScript comprend la notion de _type_ est très différente du C# et du Java.
+Explorons certaines différences.
+
+### Systèmes de Types Nominaux Réifiés
+
+En C# ou Java, toute valeur a exactement un type - `null`, une primitive, ou un type de classe.
+Nous pouvons appeler des méthodes comme `value.GetType()` ou `value.getClass()` pour obtenir le type exact à l'exécution.
+La définition de ce type réside dans une certaine classe sous un certain nom, et nous n'avons pas le droit d'utiliser deux classes à formes similaires de façon interchangeable, sauf si une relation explicite d'héritage existe ou une interface en commun est implémentée.
+
+Ces aspects décrivent un système _réifié et nominal_ de types.
+Les types qu'on écrit sont présents à l'exécution, et ils sont liés à eux via leurs déclarations, pas leurs structures.
+
+### Types en tant qu'ensembles
+
+En C# ou Java, cela a du sens de faire une correspondance entre un type à l'exécution et sa déclarations à la compilation.
+
+En TypeScript, il vaut mieux de penser aux types comme des _ensembles de valeurs_ qui partagent quelque chose en commun.
+Parce que les types ne sont que des ensembles, une valeur peut appartenir à _plusieurs_ ensembles en même temps.
+
+Une fois que vous pensez aux types en tant qu'ensembles, certaines opérations deviennent naturelles.
+Par exemple, en C#, il est bizarre de transmettre une valeur qui est _soit_ un `string` ou `int`, parce qu'il n'existe aucun type les représentant tous les deux.
+
+En TypeScript, ce procédé devient naturel quand vous pensez aux types en tant qu'ensembles.
+Comment décrire une valeur qui appartient, soit à l'ensemble des `string`, soit à celui des `number` ?
+Elle appartient simplement à l'_union_ de ces ensembles : `string | number`.
+
+TypeScript fournit un certain nombre de mécanismes pour travailler avec les types de façons similaires à la théorie des ensembles, et ces façons seront plus intuitives si on pense aux types en tant qu'ensembles.
+
+### Types Structurels Effacés
+
+En TypeScript, les objets n'ont _pas_ de seul et unique type.
+Par exemple, si nous créons un objet qui correspond à une interface, nous pouvons utiliser cet objet là où l'interface est attendue même si aucune relation de déclaration n'existait entre les deux.
+
+```ts twoslash
+interface Pointlike {
+  x: number;
+  y: number;
+}
+interface Named {
+  name: string;
+}
+
+function logPoint(point: Pointlike) {
+  console.log("x = " + point.x + ", y = " + point.y);
+}
+
+function logName(x: Named) {
+  console.log("Hello, " + x.name);
+}
+
+const obj = {
+  x: 0,
+  y: 0,
+  name: "Origin",
+};
+
+logPoint(obj);
+logName(obj);
+```
+
+Le système de types de TypeScript est _structurel_, et non nominal : nous pouvons utiliser `obj` en tant que `Pointlike` parce qu'`obj` a les propriétés `x` et `y` qui sont toutes les deux des nombres.
+Les relations entre types sont déterminées par les propriétés qu'ils contiennent, et non pas avec une relation de déclaration entre eux.
+
+Le système de types de TypeScript n'est également _pas réifié_: rien ne va pouvoir nous dire qu'`obj` est un `Pointlike`, lors de l'exécution.
+D'ailleurs, le type `Pointlike` n'est _même pas présent_ lors de l'exécution.
+
+Si nous revenons à notre façon de réfléchir aux types _en tant qu'ensemble_, nous pouvons dire qu'`obj` est membre de l'ensemble `Pointlike`, ainsi que de l'ensemble `Named`.
+
+### Conséquences du typage structurel
+
+Deux aspects particuliers de ce système surprennent souvent les développeurs POO.
+
+#### Types vides
+
+Le premier est que le _type vide_ a l'air d'agir de manière impromptue :
+
+```ts twoslash
+class Empty {}
+
+function fn(arg: Empty) {
+  // fais quelque chose ?
+}
+
+// Pas d'erreur, mais ce n'est pas un Empty ?
+fn({ k: 10 });
+```
+
+TypeScript détermine si l'appel à `fn` est valide en déterminant si l'argument fourni est un `Empty` valide.
+Cela est accompli en examinant la _structure_ de `{ k: 10 }` et `class Empty { }`.
+Nous pouvons voir que `{ k: 10 }` a _toutes_ les propriétés d'`Empty` vu qu'`Empty` n'a aucune propriété.
+C'est donc un appel valide !
+
+Cela peut paraître surprenant, mais c'est au final une relation très similaire à celle respectées dans les langages POO nominaux.
+Une sous-classe ne peut pas _retirer_ une propriété de sa classe-mère, parce que faire cela détruirait la relation de sous-type naturelle existant entre la sous-classe et sa classe-mère.
+Les systèmes de type structurels identifient cette relation en décrivant les sous-types de façon à avoir des propriétés à types compatibles.
+
+#### Types identiques
+
+Les types identiques sont une autre source fréquente de surprises :
+
+```ts
+class Car {
+  drive() {
+    // accélérer
+  }
+}
+class Golfer {
+  drive() {
+    // frapper la balle fort
+  }
+}
+
+// Pas d'erreur ?
+let w: Car = new Golfer();
+```
+
+Encore une fois, ceci n'est pas une erreur parce que les _structures_ de ces classes sont les mêmes.
+Cela peut paraître comme une source de confusion, mais en pratique, les classes identiques n'ayant aucun rapport ne sont pas communes.
+
+Nous apprendrons plus sur comment les classes sont liées l'une à l'autre dans leur chapitre.
+
+### Réflexivité
+
+Les développeurs POO ont l'habitude de pouvoir demander le type de n'importe quelle valeur, même générique :
+
+```csharp
+// C#
+static void LogType<T>() {
+    Console.WriteLine(typeof(T).Name);
+}
+```
+
+Mais parce que le système de types de TypeScript est complètement effacé, aucune information sur, par exemple, l'instanciation d'un type générique n'est disponible à l'exécution.
+
+JavaScript possède quelques opérateurs comme `typeof` et `instanceof`, mais souvenez-vous que ces opérateurs agissent sur les valeurs, tel qu'elles existent dans le code sans informations de types.
+Par exemple, `typeof (new Car())` va retourner `"object"`, et non `Car` ni `"Car"`.
+
+## Prochaines étapes
+
+C'était un bref résumé de la syntaxe et des outils régulièrement utilisés en TypeScript. À partir de là, vous pourrez :
+
+- Lire le Manuel [du début à la fin](/docs/handbook/intro.html) (30m)
+- Explorer les [exemples du bac à sable](/play#show-examples)

docs/documentation/fr/get-started/TS for OOPers.md

@@ -0,0 +1,160 @@
+---
+title: Mapped Types
+layout: docs
+permalink: /ko/docs/handbook/2/mapped-types.html
+oneline: "이미 존재하는 타입을 재사용해서 타입을 생성하기"
+---
+
+중복을 피하기 위해서 다른 타입을 바탕으로 새로운 타입을 생성할 수 있습니다.
+
+매핑된 타입은 이전에 선언하지 않았던 프로퍼티의 타입을 선언할 수 있는 인덱스 시그니처 문법로 구성됩니다.
+
+```ts twoslash
+type Horse = {};
+// ---cut---
+type OnlyBoolsAndHorses = {
+  [key: string]: boolean | Horse;
+};
+
+const conforms: OnlyBoolsAndHorses = {
+  del: true,
+  rodney: false,
+};
+```
+
+매핑된 타입은 `PropertyKey`([`keyof`을 통해서](/docs/handbook/2/indexed-access-types.html) 자주 생성되는)의 조합을 사용하여 키를 통해 타입을 반복적으로 생성하는 제너릭 타입입니다.
+
+```ts twoslash
+type OptionsFlags<Type> = {
+  [Property in keyof Type]: boolean;
+};
+```
+
+다음 예제에서, `OptionsFlags`는 `Type` 타입의 모든 프로퍼티를 가져와서 해당 값을 불린으로 변경합니다.
+
+```ts twoslash
+type OptionsFlags<Type> = {
+  [Property in keyof Type]: boolean;
+};
+// ---cut---
+type FeatureFlags = {
+  darkMode: () => void;
+  newUserProfile: () => void;
+};
+
+type FeatureOptions = OptionsFlags<FeatureFlags>;
+//   ^?
+```
+
+### Mapping Modifiers
+
+매핑중에는 추가할 수 있는 수정자로 `readonly`와 `?` 있습니다. 각각 가변성과 선택성에 영향을 미칩니다.
+
+`-` 또는 `+`를 접두사로 붙여서 이런 수정자를 추가하거나 제거할 수 있습니다. 접두사를 추가하지 않으면 `+`로 간주합니다.
+
+```ts twoslash
+// 타입의 프로퍼티에서 'readonly' 속성을 제거합니다
+type CreateMutable<Type> = {
+  -readonly [Property in keyof Type]: Type[Property];
+};
+
+type LockedAccount = {
+  readonly id: string;
+  readonly name: string;
+};
+
+type UnlockedAccount = CreateMutable<LockedAccount>;
+//   ^?
+```
+
+```ts twoslash
+// 타입의 프로퍼티에서 'optional' 속성을 제거합니다
+type Concrete<Type> = {
+  [Property in keyof Type]-?: Type[Property];
+};
+
+type MaybeUser = {
+  id: string;
+  name?: string;
+  age?: number;
+};
+
+type User = Concrete<MaybeUser>;
+//   ^?
+```
+
+## Key Remapping via `as`
+
+TypeScript 4.1 이상에서는 매핑된 타입에 `as` 절을 사용해서 매핑된 타입의 키를 다시 매핑할 수 있습니다.
+
+```ts
+type MappedTypeWithNewProperties<Type> = {
+    [Properties in keyof Type as NewKeyType]: Type[Properties]
+}
+```
+
+[템플릿 리터럴 타입](/docs/handbook/2/template-literal-types.html)과 같은 기능을 활용해서 이전 프로퍼티에서 새로운 프로퍼티 이름을 만들 수 있습니다.
+
+```ts twoslash
+type Getters<Type> = {
+    [Property in keyof Type as `get${Capitalize<string & Property>}`]: () => Type[Property]
+};
+
+interface Person {
+    name: string;
+    age: number;
+    location: string;
+}
+
+type LazyPerson = Getters<Person>;
+//   ^?
+```
+
+조건부 타입을 통해 `never`를 생성해서 키를 필터링할 수 있습니다.
+
+```ts twoslash
+// 'kind' 프로퍼티를 제거합니다
+type RemoveKindField<Type> = {
+    [Property in keyof Type as Exclude<Property, "kind">]: Type[Property]
+};
+
+interface Circle {
+    kind: "circle";
+    radius: number;
+}
+
+type KindlessCircle = RemoveKindField<Circle>;
+//   ^?
+```
+
+`string | number | symbol` 의 조합뿐만 아니라 모든 타입의 조합을 임의로 매핑할 수 있습니다.
+
+```ts twoslash
+type EventConfig<Events extends { kind: string }> = {
+    [E in Events as E["kind"]]: (event: E) => void;
+}
+
+type SquareEvent = { kind: "square", x: number, y: number };
+type CircleEvent = { kind: "circle", radius: number };
+
+type Config = EventConfig<SquareEvent | CircleEvent>
+//   ^?
+```
+
+### Further Exploration
+
+매핑된 타입은 타입 조작 섹션의 다른 기능들과 잘 동작합니다. 예를 들어 객체의 `pii` 프로퍼티가 `true`로 설정되어 있는지에 따라 `true` 혹은 `false`를 반환하는 [조건부 타입을 사용한 매핑된 타입](/docs/handbook/2/conditional-types.html)이 있습니다.
+
+```ts twoslash
+type ExtractPII<Type> = {
+  [Property in keyof Type]: Type[Property] extends { pii: true } ? true : false;
+};
+
+type DBFields = {
+  id: { format: "incrementing" };
+  name: { type: string; pii: true };
+};
+
+type ObjectsNeedingGDPRDeletion = ExtractPII<DBFields>;
+//   ^?
+```