Fix missing images on English pages

Hugo only auto-shares page-bundle resources across translations when
each language has its own content directory; with filename-based
translation (index.fr.md / index.en.md in the same folder) a resource
with no language code is assigned to the default language only. Add
.en.-suffixed copies of every image referenced from English pages and
point the English markdown at them.

content/blog/migration-gitlab-gitea/index.en.md

@@ -28,7 +28,7 @@ But several needs emerged:
 
 ## The Overall Architecture
 
-![Architecture](global_architecture.fr.svg)
+![Architecture](global_architecture.en.svg)
 
 ### Tech Stack
 

content/documentation/VXLAN/beginners/vxlan-for-beginners.en.md

@@ -55,7 +55,7 @@ The goal of **VXLAN** is to **extend layer 2** across a layer 3 (IP) network. Th
 
 > **In plain terms:** Ethernet frames (layer 2) are encapsulated inside a UDP packet (layer 4), which is itself carried over IP (layer 3).  
 
-![OSI Layers](media_layers.fr.png#center)
+![OSI Layers](media_layers.en.png#center)
 
 > [!NOTE]**The "hardware" layers**  
 >
@@ -87,7 +87,7 @@ The train runs on rails (the **IP network**, layer 3). The rail tracks are alrea
 - **Isolation and segmentation:** Just as several trains can run on the same railway line, it's possible to operate different VXLAN tunnels (each with its own VNI) over the same IP infrastructure.  
 - **Elasticity and reliability:** By relying on layer 3, VXLAN benefits from all the optimizations of IP routing (route recalculation, fault tolerance, etc.).  
 
-![Container transport](transports.fr.png#center)
+![Container transport](transports.en.png#center)
 
 ## Real-world use cases 🏭
 

content/documentation/devpod/_index.en.md

@@ -66,11 +66,11 @@ In my day-to-day networking adventures, I deploy ContainerLab-based setups with
 
 DevPod uses **Providers**, which are configuration modules that define where and how DevPod launches your environment. Here's the list of providers:
 
-![Provider_list](provider.fr.png#center)
+![Provider_list](provider.en.png#center)
 
 We're going to focus on the **AWS Provider** — even though there are plenty of configuration options:
 
-![Provider_list](aws_options.fr.png#center)
+![Provider_list](aws_options.en.png#center)
 
 Before you panic at all these settings, don't worry. If you're just doing a bit of experimenting, the default values will usually do the job. 🙌
 
@@ -245,7 +245,7 @@ Go back to **Users** → **devpod-tool-user** → **Permissions** to confirm tha
 
 - If you created a programmatic user, make sure to note down the **Access Key ID** and the **Secret Access Key**.
 
-![devpod_user_sumup](devpod_user.fr.png#center)
+![devpod_user_sumup](devpod_user.en.png#center)
 
 **Bonus**: Note your **VPC ID** (in the VPC section on AWS). You'll need it when configuring DevPod.
 
@@ -277,7 +277,7 @@ When prompted for:
 
 Click **Add Provider**.
 
-![added_new_provider](new_provider.fr.png#center)
+![added_new_provider](new_provider.en.png#center)
 
 ## Testing a deployment 🧪
 
@@ -292,23 +292,23 @@ Let's do a quick test using one of the pre-built Docker images:
 5. On the right, select a quick-start example (e.g., Python). 🐍
 6. Click **Create Workspace**.
 
-![new_worspace](new_worskapce.fr.png#center)
+![new_worspace](new_worskapce.en.png#center)
 
 Wait a few moments, and your cloud-based environment will pop up in VS Code. 🎊
 
-![vscode](vscode.fr.png#center)
+![vscode](vscode.en.png#center)
 
 ### Stop
 
 When you're not using the environment, click **Stop** to shut down the EC2 instance. You'll only pay for storage — no compute time. Great for your wallet. 💰
 
-![Stopped Instance](stopped_instance.fr.png#center)
+![Stopped Instance](stopped_instance.en.png#center)
 
 ### Delete
 
 Deleting the workspace removes all AWS resources associated with that environment, so you won't pay a dime. But you'll need to redeploy if you want to use it again. ♻️
 
-![Delete Instance](delete_instance.fr.png#center)
+![Delete Instance](delete_instance.en.png#center)
 
 ## Conclusion 💡
 

content/documentation/securité/cadenas_vert/ssl.en.md

@@ -10,7 +10,7 @@ cascade:
 
 You've seen it thousands of times, haven't you? That little **green padlock** (or sometimes gray, depending on your browser and the site) that shows up next to a website's address in your navigation bar. You click on it, you look at it, you think "cool, it's secure," and you move on.
 
-![Certificat](certificat.png)
+![Certificat](certificat.en.png)
 
 But... do you really know what it means? 🤔 All the **mechanics that kick in** just so this little symbol appears? It's much more than a simple icon! It's the visible part of an iceberg. \
 **So, what's our mission today? 🚀**

content/documentation/securité/ssl_bumping/ssl_bumping.en.md

@@ -22,7 +22,7 @@ The principle of HTTPS is comparable to sending mail in a safe where only the se
 
 **SSL Bumping** gets around this problem by inserting itself in the middle of the communication:
 
-![SSL Bumping Expliqué](images/ssl_bumping_explique.fr.svg#center)
+![SSL Bumping Expliqué](images/ssl_bumping_explique.en.svg#center)
 
 The proxy will:
 1. **Intercept** the client's HTTPS connection.
@@ -57,7 +57,7 @@ For SSL Bumping to work, the proxy must be able to generate certificates on the
 
 When you try to access `https://www.example.com`:
 
-![Génération des faux certificats](images/generation_des_faux_certificats.fr.svg)
+![Génération des faux certificats](images/generation_des_faux_certificats.en.svg)
 
 1. The proxy intercepts your request.
 2. It connects to the real `example.com` server and retrieves its legitimate certificate.
@@ -77,7 +77,7 @@ To really understand the mechanism, nothing beats hands-on practice. I've prepar
 
 ### Lab Architecture
 
-![Architecture du lab SSL](images/architecture_du_lab_ssl.fr.svg)
+![Architecture du lab SSL](images/architecture_du_lab_ssl.en.svg)
 
 ### Quick Deployment
 

content/netlab/automatisation réseau/vxlan_automation/_index.en.md

@@ -44,7 +44,7 @@ In a standard site, the connection of leaf devices to the spines follows these r
 * **Leaf Eth2 Interface:** Always connected to the Spine 2 Eth2 interface.
 * **Leaf Eth3 Interface:** Always dedicated to connecting to the access switch present in the same building.
 
-![Site Standard](<Site Standard.drawio.svg>)
+![Site Standard](<Site Standard.drawio.en.svg>)
 
 > [!NOTE] Simplification for the POC
 > For the purposes of this **Proof of Concept**, we opted for a simplified architecture without advanced redundancy at the leaf-spine connection level.  
@@ -155,7 +155,7 @@ Choose site number or 'new': 1
 > [!NOTE] Netbox Plugin
 > The configuration can easily be visualized with the help of the plugin: [netbox_topology_views](https://github.com/netbox-community/netbox-topology-views)
 
-![Topologie de Paris](fabric_topology.png)
+![Topology of Paris](fabric_topology.en.png)
 
 > [!TIP]
 > Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-create-fabric)
@@ -262,7 +262,7 @@ Now that we know how Netbox generates the configurations, let's see how we use t
     * Click on the device you're interested in (for example, one of our leafs).
     * And there we have a magic tab: **Render Config**! Clicking on it shows the configuration Netbox generated for this device using the Jinja2 template and its own data.
 
-    ![PA01 Leaf Configuration](<Render Config.png>)
+    ![PA01 Leaf Configuration](<Render Config.en.png>)
 
 2. **The Human Touch in Containerlab 🖐️** For now, we don't have a script that automatically pushes these configurations to our devices in Containerlab. So we're going to do it the old-fashioned way (but that's fine for a demo!):
 
@@ -312,9 +312,9 @@ For more information, I'll point you to the article on [My First Lab](../../netl
 
 And then, via VSCode, it's possible to launch Wireshark directly:
 
-![Extension vscode](leaf1_capture_eth1.png)
+![Extension vscode](leaf1_capture_eth1.en.png)
 
-![Capture Wireshark](wireshark_eth2_leaf1.png)
+![Capture Wireshark](wireshark_eth2_leaf1.en.png)
 
 ## Conclusion ✨
 

content/netlab/first_lab/_index.en.md

@@ -43,7 +43,7 @@ Our lab will simulate a VXLAN topology consisting of:
 
 The following diagram illustrates the VXLAN topology:
 
-![VXLAN Topology](VXLAN.fr.svg#center)
+![VXLAN Topology](VXLAN.en.svg#center)
 
 Here's the Containerlab topology file (`lab_vxlan.yml`) used for this configuration:
 
@@ -126,7 +126,7 @@ We'll deploy the lab with **DevPod** in two ways:
    - Choose your default IDE.
    - Finally, click **Create Workspace**.
 
-   ![DevPod Configuration](devpod_configuration.fr.png#center)
+   ![DevPod Configuration](devpod_configuration.en.png#center)
 
 ### 2. Using a Local Folder 🗂️
 
@@ -135,7 +135,7 @@ If you prefer to use your local repository:
 - The only difference is in the **Workspace source**.
 - Simply point it to your local repository.
 
-   ![DevPod Configuration - Local](devpod_configuration_local.fr.png#center)
+   ![DevPod Configuration - Local](devpod_configuration_local.en.png#center)
 
 ## Starting the Lab 🎬
 
@@ -169,7 +169,7 @@ If you prefer to use your local repository:
 
    Ports (for example, port 50080 mentioned in `devcontainer.json`) are forwarded. Access the graphical view via [localhost](http://localhost:50080).
 
-   ![Graph View](Graph_view.fr.png#center)
+   ![Graph View](Graph_view.en.png#center)
 
 ## Using EdgeShark 🦈
 
@@ -199,12 +199,12 @@ DOCKER_DEFAULT_PLATFORM= docker compose up -d
 Access EdgeShark via [localhost:5001](http://localhost:5001).
 
 - **EdgeShark View**:  
-  ![EdgeShark View](edgeshark.fr.png#center)
+  ![EdgeShark View](edgeshark.en.png#center)
 
 - **Integration with Wireshark**:  
   By clicking the Wireshark icon in EdgeShark, you can launch Wireshark locally.  
-  ![EdgeShark Interface](edgeshark_interface.fr.png#center)  
-  ![EdgeShark and Wireshark](edge_wireshark.fr.png#center)
+  ![EdgeShark Interface](edgeshark_interface.en.png#center)  
+  ![EdgeShark and Wireshark](edge_wireshark.en.png#center)
 
 ## Conclusion 🎉