diff --git a/1-js/13-modules/02-import-export/article.md b/1-js/13-modules/02-import-export/article.md
index 6059491a3..4d152d880 100644
--- a/1-js/13-modules/02-import-export/article.md
+++ b/1-js/13-modules/02-import-export/article.md
@@ -1,23 +1,23 @@
-# Export and Import
+# Exporter et importer
 
-Export and import directives have several syntax variants.
+Les directives d'exportation et d'importation ont plusieurs variantes de syntaxe.
 
-In the previous chapter we saw a simple use, now let's explore more examples.
+Dans le chapitre précédent, nous avons constaté une utilisation simple: explorons maintenant plus d’exemples.
 
-## Export before declarations
+## Exporter avant les déclarations
 
-We can label any declaration as exported by placing `export` before it, be it a variable, function or a class.
+Nous pouvons étiqueter n'importe quelle déclaration comme exportée en plaçant `export` devant elle, que ce soit une variable, une fonction ou une classe.
 
-For instance, here all exports are valid:
+Par exemple, ici toutes les exportations sont valides:
 
 ```js
-// export an array
+// exporter un tableau
 *!*export*/!* let months = ['Jan', 'Feb', 'Mar','Apr', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'];
 
-// export a constant
+// exporter une constante
 *!*export*/!* const MODULES_BECAME_STANDARD_YEAR = 2015;
 
-// export a class
+// exporter une classe
 *!*export*/!* class User {
   constructor(name) {
     this.name = name;
@@ -25,26 +25,26 @@ For instance, here all exports are valid:
 }
 ```
 
-````smart header="No semicolons after export class/function"
-Please note that `export` before a class or a function does not make it a [function expression](info:function-expressions-arrows). It's still a function declaration, albeit exported.
+````smart header="Pas de point-virgule après la classe / fonction d'exportation"
+Veuillez noter que l'`export` avant une classe ou une fonction n'en fait pas une expression de fonction. C’est toujours une déclaration de fonction, bien qu’elle soit exportée.
 
-Most JavaScript style guides don't recommend semicolons after function and class declarations.
+La plupart des guides de bonnes pratiques JavaScript ne recommandent pas les points-virgules après les déclarations de fonctions et de classes.
 
-That's why there's no need for a semicolon at the end of `export class` and `export function`:
+C’est pourquoi il n’est pas nécessaire d’utiliser un point-virgule à la fin de `export class` et de `export function`:
 
 ```js
 export function sayHi(user) {
   alert(`Hello, ${user}!`);
-} *!* // no ; at the end */!*
+} *!* // pas de ; à la fin */!*
 ```
 
 ````
 
-## Export apart from declarations
+## Exporter en dehors des déclarations
 
-Also, we can put `export` separately.
+En outre, nous pouvons mettre l'`export` séparément.
 
-Here we first declare, and then export:
+Ici, nous déclarons d'abord, puis exportons:
 
 ```js  
 // 📁 say.js
@@ -57,15 +57,15 @@ function sayBye(user) {
 }
 
 *!*
-export {sayHi, sayBye}; // a list of exported variables
+export {sayHi, sayBye}; // une liste de variables exportées
 */!*
 ```
 
-...Or, technically we could put `export` above functions as well.
+… Ou, techniquement, nous pourrions également définir les fonctions d'`export` au-dessus des fonctions.
 
 ## Import *
 
-Usually, we put a list of what to import in curly braces `import {...}`, like this:
+Habituellement, nous mettons une liste de ce qu'il faut importer entre accolades `import {...}`, comme ceci:
 
 ```js
 // 📁 main.js
@@ -77,7 +77,7 @@ sayHi('John'); // Hello, John!
 sayBye('John'); // Bye, John!
 ```
 
-But if there's a lot to import, we can import everything as an object using `import * as <obj>`, for instance:
+Mais s’il y a beaucoup à importer, nous pouvons tout importer en tant qu’objet en utilisant `import * as <obj>`, par exemple:
 
 ```js
 // 📁 main.js
@@ -89,13 +89,13 @@ say.sayHi('John');
 say.sayBye('John');
 ```
 
-At first sight, "import everything" seems such a cool thing, short to write, why should we ever explicitly list what we need to import?
+À première vue, "importer tout" semble être une chose tellement cool, simple a écrire, pourquoi devrions-nous explicitement énumérer ce que nous devons importer?
 
-Well, there are few reasons.
+Eh bien, il y a quelques raisons.
 
-1. Modern build tools ([webpack](http://webpack.github.io) and others) bundle modules together and optimize them to speedup loading and remove unused stuff.
+1. Les outils de construction modernes ([webpack](http://webpack.github.io) et autres) regroupent les modules et les optimisent pour accélérer le chargement et supprimer les éléments inutilisés.
 
-    Let's say, we added a 3rd-party library `say.js` to our project with many functions:
+    Disons que nous avons ajouté à notre projet une bibliothèque tierce, say.js, avec de nombreuses fonctions:
     ```js
     // 📁 say.js
     export function sayHi() { ... }
@@ -103,21 +103,21 @@ Well, there are few reasons.
     export function becomeSilent() { ... }
     ```
 
-    Now if we only use one of `say.js` functions in our project:
+    Maintenant, si nous n’utilisons qu’une des fonctions de say.js dans notre projet:
     ```js
     // 📁 main.js
     import {sayHi} from './say.js';
     ```
-    ...Then the optimizer will see that and remove the other functions from the bundled code, thus making the build smaller. That is called "tree-shaking".
+    … Ensuite, l'optimiseur verra cela et supprimera les autres fonctions du code fourni, rendant ainsi la construction plus petite. C'est ce qu'on appelle "tree-shaking".
 
-2. Explicitly listing what to import gives shorter names: `sayHi()` instead of `say.sayHi()`.
-3. Explicit list of imports gives better overview of the code structure: what is used and where. It makes code support and refactoring easier.
+2. Énumérer explicitement ce qu'il faut importer donne des noms plus courts: `sayHi()` au lieu de `say.sayHi()`.
+3. La liste explicite des importations donne une meilleure vue d'ensemble de la structure du code: ce qui est utilisé et où. Cela facilite la prise en charge du code et la refactorisation.
 
 ## Import "as"
 
-We can also use `as` to import under different names.
+Nous pouvons également utiliser `as` pour importer sous différents noms.
 
-For instance, let's import `sayHi` into the local variable `hi` for brevity, and import `sayBye` as `bye`:
+Par exemple, importons `sayHi` dans la variable locale `hi` par souci de concision, et importons `sayBye` en `bye`:
 
 ```js
 // 📁 main.js
@@ -131,9 +131,9 @@ bye('John'); // Bye, John!
 
 ## Export "as"
 
-The similar syntax exists for `export`.
+La syntaxe similaire existe pour l'`export`.
 
-Let's export functions as `hi` and `bye`:
+Exportons les fonctions en tant que `hi` et `bye`:
 
 ```js
 // 📁 say.js
@@ -141,7 +141,7 @@ Let's export functions as `hi` and `bye`:
 export {sayHi as hi, sayBye as bye};
 ```
 
-Now `hi` and `bye` are official names for outsiders, to be used in imports:
+Maintenant, `hi` et `bye` sont les noms à utiliser dans les importations:
 
 ```js
 // 📁 main.js
@@ -153,95 +153,95 @@ say.*!*bye*/!*('John'); // Bye, John!
 
 ## Export default
 
-In practice, there are mainly two kinds of modules.
+En pratique, il existe principalement deux types de modules.
 
-1. Module that contains a library, pack of functions, like `say.js` above.
-2. Module that declares a single entity, e.g. a module `user.js` exports only `class User`.
+1. Module qui contient une bibliothèque, un pack de fonctions, comme `say.js` ci-dessus.
+2. Module qui déclare une seule entité, par exemple le module `user.js` exporte uniquement la `class User`.
 
-Mostly, the second approach is preferred, so that every "thing" resides in its own module.
+La deuxième approche est généralement privilégiée, de sorte que chaque "chose" réside dans son propre module.
 
-Naturally, that requires a lot of files, as everything wants its own module, but that's not a problem at all. Actually, code navigation becomes easier, if files are well-named and structured into folders.
+Naturellement, cela nécessite beaucoup de fichiers, car toute chose veut son propre module, mais ce n’est pas un problème du tout. En fait, la navigation dans le code devient plus facile si les fichiers sont bien nommés et structurés en dossiers.
 
-Modules provide special `export default` ("the default export") syntax to make "one thing per module" way look better.
+Les modules fournissent une syntaxe spéciale pour l'`export default` ("l'exportation par défaut") afin d'améliorer l'aspect "une chose par module".
 
-Put `export default` before the entity to export:
+Placez `export default` avant l'entité à exporter:
 
 ```js
 // 📁 user.js
-export *!*default*/!* class User { // just add "default"
+export *!*default*/!* class User { // ajouter juste "default"
   constructor(name) {
     this.name = name;
   }
 }
 ```
 
-There may be only one `export default` per file.
+Il ne peut y avoir qu'un seul `export default` par fichier.
 
-...And then import it without curly braces:
+… Et ensuite importez-le sans accolades:
 
 ```js
 // 📁 main.js
-import *!*User*/!* from './user.js'; // not {User}, just User
+import *!*User*/!* from './user.js'; // pas {User}, juste User
 
 new User('John');
 ```
 
-Imports without curly braces look nicer. A common mistake when starting to use modules is to forget curly braces at all. So, remember, `import` needs curly braces for named exports and doesn't need them for the default one.
+Les importations sans accolades sont plus agréables. Une erreur courante lorsque vous commencez à utiliser des modules est d’oublier les accolades. Par conséquent, rappelez-vous que l’`import` nécessite des accolades pour les exportations nommées et ne les utilise pas pour celle par défaut.
 
-| Named export | Default export |
-|--------------|----------------|
+| Export nommé | Export par défaut |
+|--------------|-------------------|
 | `export class User {...}` | `export default class User {...}` |
 | `import {User} from ...` | `import User from ...`|
 
-Technically, we may have both default and named exports in a single module, but in practice people usually don't mix them. A module has either named exports or the default one.
+Techniquement, nous pouvons avoir à la fois des exportations par défaut et des exportations nommées dans un seul module, mais dans la pratique, les gens ne les mélangent généralement pas. Un module a soit, des exports nommés, soit celui par défaut.
 
-As there may be at most one default export per file, the exported entity may have no name.
+Comme il peut y avoir au plus une exportation par défaut par fichier, l'entité exportée peut ne pas avoir de nom.
 
-For instance, these are all perfectly valid default exports:
+Par exemple, ce sont toutes des exportations par défaut parfaitement valides:
 
 ```js
-export default class { // no class name
+export default class { // pas de nom de classe
   constructor() { ... }
 }
 ```
 
 ```js
-export default function(user) { // no function name
+export default function(user) { // pas de nom de fonction
   alert(`Hello, ${user}!`);
 }
 ```
 
 ```js
-// export a single value, without making a variable
+// exporter une seule valeur sans créer de variable
 export default ['Jan', 'Feb', 'Mar','Apr', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'];
 ```
 
-Not giving a name is fine, because `export default` is only one per file, so `import` without curly braces knows what to import.
+Ne pas donner de nom, c'est bien, car l'`export default` est unique. Par conséquent, l'importation sans accolades sait ce qu'il faut importer.
 
-Without `default`, such export would give an error:
+Sans `defaut`, une telle exportation donnerait une erreur:
 
 ```js
-export class { // Error! (non-default export needs a name)
+export class { // Erreur! (un export autre que par défaut nécessite un nom)
   constructor() {}
 }
 ```     
 
-### The "default" name
+### Le nom par "default"
 
-In some situations the `default` keyword is used to reference the default export.
+Dans certaines situations, le mot clé `default` est utilisé pour référencer l'exportation par défaut.
 
-For example, to export a function separately from its definition:
+Par exemple, pour exporter une fonction séparément de sa définition:
 
 ```js
 function sayHi(user) {
   alert(`Hello, ${user}!`);
 }
 
-// same as if we added "export default" before the function
+// comme si nous avions ajouté "export default" avant la fonction
 export {sayHi as default};
 ```
 
-Or, another situation, let's say a module `user.js` exports one main "default" thing and a few named ones (rarely the case, but happens):
+Ou, dans un autre cas, supposons qu'un module `user.js` exporte un élément principal par "défaut" et quelques éléments nommés (rarement le cas, mais ça arrive):
 
 ```js
 // 📁 user.js
@@ -256,7 +256,7 @@ export function sayHi(user) {
 }
 ```
 
-Here's how to import the default export along with a named one:
+Voici comment importer l'exportation par défaut avec celle nommée:
 
 ```js
 // 📁 main.js
@@ -265,38 +265,37 @@ import {*!*default as User*/!*, sayHi} from './user.js';
 new User('John');
 ```
 
-And, finally, if importing everything `*` as an object, then the `default` property is exactly the default export:
+Et, enfin, si vous importez tout `*` comme objet, la propriété `default` est exactement l'exportation par défaut:
 
 ```js
 // 📁 main.js
 import * as user from './user.js';
 
-let User = user.default; // the default export
+let User = user.default; // l'exportation par défaut
 new User('John');
 ```
 
-### A word against default exports
+### Un mot contre les exportations par défaut
 
-Named exports are explicit. They exactly name what they import, so we have that information from them, that's a good thing.
+Les exportations nommées sont explicites. Ils nomment exactement ce qu’ils importent, nous avons donc ces informations, c’est une bonne chose.
 
-Named exports enforce us to use exactly the right name to import:
+Les exportations nommées nous obligent à utiliser exactement le bon nom pour importer::
 
 ```js
 import {User} from './user.js';
-// import {MyUser} won't work, the name must be {User}
+// importer {MyUser} ne fonctionnera pas, le nom devrait être {User}
 ```
 
-...While for a default export, we always choose the name when importing:
+...Alors que pour une exportation par défaut, nous choisissons toujours le nom lors de l'importation:
 
 ```js
-import User from './user.js'; // works
-import MyUser from './user.js'; // works too
-// could be import Anything..., and it'll be work
+import User from './user.js'; // fonctionne
+import MyUser from './user.js'; // fonctionne aussi
+// n'importe quoi pourrait être importé ..., et ça fonctionnera
 ```
+Les membres de l'équipe peuvent donc utiliser des noms différents pour importer la même chose, et ce n'est pas bien.
 
-So team members may use different names to import the same thing, and that's not good.
-
-Usually, to avoid that and keep the code consistent, there's a rule that imported variables should correspond to file names, e.g:
+Habituellement, pour éviter cela et garder le code cohérent, il existe une règle voulant que les variables importées correspondent aux noms de fichier, par exemple:
 
 ```js
 import User from './user.js';
@@ -305,25 +304,25 @@ import func from '/path/to/func.js';
 ...
 ```
 
-Still, some teams consider it a serious drawback of default exports. So they prefer to always use named exports. Even if only a single thing is exported, it's still exported under a name, without `default`.
+Néanmoins, certaines équipes considèrent qu'il s'agit d'un grave inconvénient des exportations par défaut. Ils préfèrent donc toujours utiliser des exportations nommées. Même si une seule chose est exportée, elle est toujours exportée sous un nom, sans `default`.
 
-That also makes re-export (see below) a little bit easier.
+Cela facilite également la réexportation (voir ci-dessous).
 
-## Re-export
+## Réexportation
 
-"Re-export" syntax `export ... from ...` allows to import things and immediately export them (possibly under another name), like this:
+La syntaxe "re-export" `export ... from ...` permet d'importer et d'exporter immédiatement des éléments (éventuellement sous un autre nom), comme ceci:
 
 ```js
-export {sayHi} from './say.js'; // re-export sayHi
+export {sayHi} from './say.js'; // réexportez sayHi
 
-export {default as User} from './user.js'; // re-export default
+export {default as User} from './user.js'; // réexportez default
 ```
 
-Why that may be needed? Let's see a practical use case.
+Pourquoi cela peut être nécessaire? Voyons un cas d'utilisation pratique.
 
-Imagine, we're writing a "package": a folder with a lot of modules, with some of the functionality exported outside (tools like NPM allow to publish and distribute such packages), and many modules are just "helpers", for the internal use in other package modules.
+Imaginons, nous écrivons un "package": un dossier contenant de nombreux modules, avec certaines des fonctionnalités exportées à l'extérieur (des outils tels que NPM permettent de publier et de distribuer de tels packages), et de nombreux modules ne sont que des "aides". utilisation interne dans d'autres modules.
 
-The file structure could be like this:
+La structure de fichier pourrait être comme ceci:
 ```
 auth/
     index.js  
@@ -337,48 +336,48 @@ auth/
         ...
 ```
 
-We'd like to expose the package functionality via a single entry point, the "main file" `auth/index.js`, to be used like this:
+Nous aimerions exposer les fonctionnalités du paquet via un seul point d’entrée, le "fichier principal" `auth / index.js`, à utiliser comme ceci:
 
 ```js
 import {login, logout} from 'auth/index.js'
 ```
 
-The idea is that outsiders, developers who use our package, should not meddle with its internal structure, search for files inside our package folder. We export only what's necessary in `auth/index.js` and keep the rest hidden from prying eyes.
+L'idée est que les tiers, les développeurs qui utilisent notre package, ne doivent pas se mêler de sa structure interne, rechercher des fichiers dans notre dossier de packages. Nous n'exportons que ce qui est nécessaire dans `auth / index.js` et gardons le reste caché des regards indiscrets.
 
-As the actual exported functionality is scattered among the package, we can import it into `auth/index.js` and export from it:
+La fonctionnalité exportée étant dispersée dans le package, nous pouvons l'importer dans `auth / index.js` et l'exporter:
 
 ```js
 // 📁 auth/index.js
 
-// import login/logout and immediately export them
+// importer les login / logout et les exporter immédiatement
 import {login, logout} from './helpers.js';
 export {login, logout};
 
-// import default as User and export it
+// importer par défaut en tant qu'utilisateur et l'exporter
 import User from './user.js';
 export {User};
 ...
 ```
 
-Now users of our package can `import {login} from "auth/index.js"`.
+Maintenant, les utilisateurs de notre paquet peuvent `import {login} from "auth/index.js"`.
 
-The syntax `export ... from ...` is just a shorter notation for such import-export:
+La syntaxe `export ... from ...` est juste une notation plus courte pour importer et exporter directement:
 
 ```js
 // 📁 auth/index.js
-// import login/logout and immediately export them
+// importer login / logout et les exporter immédiatement
 export {login, logout} from './helpers.js';
 
-// import default as User and export it
+// importer par défaut en tant qu'User et exporter immédiatement
 export {default as User} from './user.js';
 ...
 ```
 
-### Re-exporting the default export
+### Ré-exportation de l'exportation par défaut
 
-The default export needs separate handling when re-exporting.
+L'exportation par défaut nécessite un traitement séparé lors de la réexportation.
 
-Let's say we have `user.js`, and we'd like to re-export class `User` from it:
+Disons que nous avons `user.js` et que nous aimerions réexporter la classe `User` à partir de celle-ci:
 
 ```js
 // 📁 user.js
@@ -387,69 +386,69 @@ export default class User {
 }
 ```
 
-1. `export User from './user.js'` won't work. What can go wrong?... But that's a syntax error!
+1. `export User from './user.js'` çe ne fonctionnera pas... C'est une erreur de syntaxe!
 
-    To re-export the default export, we should write `export {default as User}`, as in the example above.    
+    Pour réexporter l'exportation par défaut, nous devrions écrire `export {default as User}`, comme dans l'exemple ci-dessus.
 
-2. `export * from './user.js'` re-exports only named exports, ignores the default one.
+2. `export * from '. / user.js'` ne réexporte que les exportations nommées, ignore celle par défaut.
 
-    If we'd like to re-export both named and the default export, then two statements are needed:
+    Si nous souhaitons réexporter l'export nommé et l'export par défaut, deux instructions sont nécessaires:
     ```js
-    export * from './user.js'; // to re-export named exports
-    export {default} from './user.js'; // to re-export the default export
+    export * from './user.js'; // réexporter les exportations nommées
+    export {default} from './user.js'; // réexporter l'exportation par défaut
     ```
 
-Such oddities of re-exporting the default export is one of the reasons, why some developers don't like them.
+Cette bizarrerie de réexporter l'exportation par défaut est l'une des raisons pour lesquelles certains développeurs ne l'aiment pas.
 
-## Summary
+## Sommaire
 
-Here are all types of `export` that we covered in this and previous chapters.
+Voici tous les types d'`export` que nous avons abordés dans ce chapitre et dans les chapitres précédents.
 
-You can check yourself by reading them and recalling what they mean:
+Vous pouvez vérifier vous-même en les lisant et en vous rappelant leur signification:
 
-- Before declaration of a class/function/..:
+- Avant la déclaration d'une classe / fonction / ..:
   - `export [default] class/function/variable ...`
-- Standalone export:
+- Exportation autonome:
   - `export {x [as y], ...}`.
-- Re-export:
+- Réexportation:
   - `export {x [as y], ...} from "module"`
-  - `export * from "module"` (doesn't re-export default).
-  - `export {default [as y]} from "module"` (re-export default).
+  - `export * from "module"` (ne ré-exporte pas par défaut).
+  - `export {default [as y]} from "module"` (ré-export par défaut).
 
 Import:
 
-- Named exports from module:
+- Exportations nommées du module:
   - `import {x [as y], ...} from "module"`
-- Default export:  
+- Export par défaut: 
   - `import x from "module"`
   - `import {default as x} from "module"`
-- Everything:
+- Tout:
   - `import * as obj from "module"`
-- Import the module (its code runs), but do not assign it to a variable:
+- Import le module (son code s'exécute), mais ne l'affecte pas à une variable:
   - `import "module"`
 
-We can put `import/export` statements at the top or at the bottom of a script, that doesn't matter.
+Nous pouvons mettre des déclarations `import/export` en haut ou en bas d'un script, cela n'a pas d'importance.
 
-So, technically this code is fine:
+Donc, techniquement, ce code est correct:
 ```js
 sayHi();
 
 // ...
 
-import {sayHi} from './say.js'; // import at the end of the file
+import {sayHi} from './say.js'; // importer à la fin du fichier
 ```
 
-In practice imports are usually at the start of the file, but that's only for better convenience.
+En pratique, les importations se font généralement au début du fichier, mais ce n'est que pour des raisons de commodité.
 
-**Please note that import/export statements don't work if inside `{...}`.**
+**Veuillez noter que les instructions import/export ne fonctionnent pas si elles sont à l'intérieur `{...}`.**
 
-A conditional import, like this, won't work:
+Une importation conditionnelle, comme celle-ci, ne fonctionnera pas:
 ```js
 if (something) {
-  import {sayHi} from "./say.js"; // Error: import must be at top level
+  import {sayHi} from "./say.js"; // Erreur: l'importation doit être au plus haut niveau
 }
 ```
 
-...But what if we really need to import something conditionally? Or at the right time? Like, load a module upon request, when it's really needed?
+...Mais que se passe-t-il si nous devons vraiment importer quelque chose de manière conditionnelle? Ou au bon moment? Aimez-vous, charger un module sur demande, quand c'est vraiment nécessaire?
 
-We'll see dynamic imports in the next chapter.
+Nous verrons les importations dynamiques dans le chapitre suivant.

<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
<html xmlns='http://www.w3.org/1999/xhtml'>
<head>
<title>pFad - Phonifier reborn</title>
<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />
</head>
<body>
<h1>Pfad - The Proxy pFad of &#169; 2024 Garber Painting. All rights reserved.</h1>


<!-- Disclaimer -->
<p>Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.</p>
<br>
<p>Alternative Proxies:</p><p><a href="http://rainy.clevelandohioweatherforecast.com/php-proxy/index.php?q=https://patch-diff.githubusercontent.com/raw/javascript-tutorial/fr.javascript.info/pull/113.diff" target="_blank">Alternative Proxy</a></p><p><a href="http://rainy.clevelandohioweatherforecast.com/pFad/index.php?u=https://patch-diff.githubusercontent.com/raw/javascript-tutorial/fr.javascript.info/pull/113.diff" target="_blank">pFad Proxy</a></p><p><a href="http://rainy.clevelandohioweatherforecast.com/pFad/v3index.php?u=https://patch-diff.githubusercontent.com/raw/javascript-tutorial/fr.javascript.info/pull/113.diff" target="_blank">pFad v3 Proxy</a></p><p><a href="http://rainy.clevelandohioweatherforecast.com/pFad/v4index.php?u=https://patch-diff.githubusercontent.com/raw/javascript-tutorial/fr.javascript.info/pull/113.diff" target="_blank">pFad v4 Proxy</a></p></body>
</html>