Fix comments

_posts/2024-08-02-how-to-manage-hundreds-of-templates.md

@@ -29,8 +29,8 @@ At their disposal, they have a design system : a set of visual asset they can us
 
 Sample screens composed of design system components
 
-![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-m6plus.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-videoland.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-rtlhu.png)
-:-:|:-:|:-:
+![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-m6plus.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-videoland.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/home-rtlhu.png)  
+:-:|:-:|:-:  
 
 This results in, approximately, one hundred design elements per client. However, not all components are always specific, and an inheritance system is in place to allow clients to reuse default atoms, molecules, or organisms while applying the tokens corresponding to their brand.  
 The objectives and expectations vary greatly among clients, resulting in numerous graphical element evolutions. Managing the creation and progression of these elements through different processes is a major challenge in tracking designs across each platform. These demands sometimes lead to different integrations. Whether or not the default design is inherited is crucial information to avoid manually comparing the app designs with documentation, which can lead to misunderstandings and wasted time during validation and approval processes.
@@ -45,17 +45,17 @@ Therefore, implementing a versioning system became essential to continue enrichi
 
 <center>
 
-![Release note of the Design system](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/design-release-note.png)
+![Release note of the Design system](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/design-release-note.png)  
 
 </center>
 
-Initially, the design team began by versioning its releases and all available components, which are accessible to technical teams in our online design documentation (hosted on ZeroHeight). This versioning is common to all platforms and all clients if there are no specificities for the component in question. Ultimately, versioning helps product and technical teams track the delivery progress of new designs. The version number follows these rules:
-Code status | Stage | Rule | Example 
-:-:|:-:|:-:|:-:
-First release | New collection | 1.0.0 | 1.0.0
-Documentation update without impact on the anatomy of design element | Documentation update | Increment the third digit | 1.0.1
-New backward-compatible feature | Minor release | Increment the 2nd digit and reset the third | 1.1.0
-Change on element that break backward compatibility | Major release | Increment the first digit and reset the second and the third | 2.0.0
+Initially, the design team began by versioning its releases and all available components, which are accessible to technical teams in our online design documentation (hosted on [ZeroHeight](https://zeroheight.com/)). This versioning is common to all platforms and all clients if there are no specificities for the component in question. Ultimately, versioning helps product and technical teams track the delivery progress of new designs. The version number follows these rules:
+Code status | Stage | Rule | Example   
+:-:|:-:|:-:|:-:  
+First release | New collection | 1.0.0 | 1.0.0  
+Documentation update without impact on the anatomy of design element | Documentation update | Increment the third digit | 1.0.1  
+New backward-compatible feature | Minor release | Increment the 2nd digit and reset the third | 1.1.0  
+Change on element that break backward compatibility | Major release | Increment the first digit and reset the second and the third | 2.0.0  
 
 
 Each frontend team was then responsible for implementing an equivalent versioning system representing the state of their platform. This was done through a feature team including all frontends, design system managers, and the product team. This organization brought numerous benefits:
@@ -73,17 +73,17 @@ Each client has their versioning file containing all the components available on
 
 <center>
 
-Default Versioning file | Customer Versioning file
-:-------------------------:|:-------------------------:
-![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/versioning-file-default.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/versioning-file-customer.png)
+Default Versioning file | Customer Versioning file  
+:-------------------------:|:-------------------------:  
+![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/versioning-file-default.png) | ![](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/versioning-file-customer.png)  
 
 </center>
               
 From these versioning files, we have been able to generate reports for each platform containing only the available graphical elements and their version, whether inherited or not. To track their growing number, we opted for automatic generation of these reports with each build in our continuous integration system using a KGP (Kotlin Gradle Plugin) script integrated on our continuous deployment and integration (CI/CD) : Bitrise.
 
 <center>
 
-![Template versioning report for a customer](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/template-versioning-report.png)
+![Template versioning report for a customer](/images/posts/2024-08-02-how-to-manage-hundreds-of-templates/template-versioning-report.png)  
 
 </center>