fix: multiple h1's

causing href issues

Author: wackerow

public/content/translations/el/developers/docs/design-and-ux/dex-design-best-practice/index.md

@@ -178,15 +178,15 @@ lang: el
 
 Τελικά, υπάρχουν πλεονεκτήματα και μειονεκτήματα και για τις δύο επιλογές, αλλά είναι ενδιαφέρον πώς η τάση φαίνεται να είναι προς το token στα δεξιά.
 
-# Συμπεριφορά κουμπιών {#button-behavior}
+## Συμπεριφορά κουμπιών {#button-behavior}
 
 Μην έχετε ξεχωριστό κουμπί για το Approve. Επίσης, μην έχετε ξεχωριστό κλικ για το Approve. Ο χρήστης θέλει να κάνει Swap, οπότε απλώς πείτε "swap" στο κουμπί και ξεκινήστε την έγκριση ως το πρώτο βήμα. Ένα modal μπορεί να δείξει την πρόοδο με ένα stepper, ή μια απλή ειδοποίηση "tx 1 από 2 - έγκριση".
 
 ![A UI with separate buttons for approve and swap](./14.png)
 
 ![Ένα UI με ένα κουμπί που λέει έγκριση](./15.png)
 
-## Κουμπί ως συμφραζόμενη βοήθεια {#button-as-contextual-help}
+### Κουμπί ως συμφραζόμενη βοήθεια {#button-as-contextual-help}
 
 Το κουμπί μπορεί να κάνει διπλή λειτουργία ως ειδοποίηση!
 
@@ -204,7 +204,7 @@ lang: el
 
 ![Μήνυμα σφάλματος που εμφανίζεται στο κύριο CTA](./17.png)
 
-## Δημιουργήστε το δικό σας με αυτό το αρχείο figma {#build-your-own-with-this-figma-file}
+### Δημιουργήστε το δικό σας με αυτό το αρχείο figma {#build-your-own-with-this-figma-file}
 
 Χάρη στη σκληρή δουλειά πολλών πρωτοκόλλων, ο σχεδιασμός DEX έχει βελτιωθεί πολύ. Γνωρίζουμε ποιες πληροφορίες χρειάζεται ο χρήστης, πώς πρέπει να τις εμφανίζουμε και πώς να κάνουμε τη ροή όσο το δυνατόν πιο ομαλή.
 Ας ελπίσουμε ότι αυτό το άρθρο παρέχει μια σταθερή επισκόπηση των αρχών UX.

public/content/translations/es/developers/docs/design-and-ux/dex-design-best-practice/index.md

@@ -180,15 +180,15 @@ La ley de proximidad establece que los elementos que están cerca se perciben co
 
 En última instancia, hay ventajas y desventajas para ambas opciones, pero es interesante cómo la tendencia parece ser colocar el token del lado derecho.
 
-# Comportamiento del botón {#button-behavior}
+## Comportamiento del botón {#button-behavior}
 
 No tenga un botón separado para Aprobar. Tampoco tenga un clic separado para Aprobar. El usuario quiere intercambiar, así que solo tiene que decir "intercambiar" en el botón e iniciar la aprobación como primer paso. Un modal puede mostrar el progreso con un paso a paso, o una simple notificación "tx 1 de 2 - aprobación".
 
 ![Una interfaz de usuario con botones separados para aprobar e intercambiar](./14.png)
 
 ![Una interfaz de usuario con un botón que dice aprobar](./15.png)
 
-## Botón como ayuda contextual {#button-as-contextual-help}
+### Botón como ayuda contextual {#button-as-contextual-help}
 
 El botón puede tener una doble función como una ¡alerta!
 
@@ -206,7 +206,7 @@ El botón también puede ser **mapeado a la acción** a realizar. Por ejemplo, s
 
 ![Mensaje de error mostrado en el CTA principal](./17.png)
 
-## Construya el suyo con este archivo figma {#build-your-own-with-this-figma-file}
+### Construya el suyo con este archivo figma {#build-your-own-with-this-figma-file}
 
 Gracias a la ardua labor de múltiples protocolos, el diseño de DEX ha mejorado mucho. Sabemos qué información necesita el usuario, cómo debemos mostrarla y cómo hacer que el flujo sea lo más fluido posible.
 Esperamos que este artículo ofrezca una sólida visión general de los principios de la UX.

public/content/translations/es/developers/tutorials/erc-721-vyper-annotated-code/index.md

@@ -614,11 +614,11 @@ def burn(_tokenId: uint256):
 
 Cualquiera a quien se le permita transferir un token puede quemarlo. Mientras que una quema parece equivalente a transferira la dirección cero, la dirección cero no recibe el token. Esto nos permite liberar todo el almacenamiento que se utilizó para el token, lo que puede reducir el coste del gas de la transacción.
 
-# Utilizar este contrato {#using-contract}
+## Utilizar este contrato {#using-contract}
 
 En contraste con Solidity, Vyper no tiene herencia. Esta es una elección de diseño deliberada para hacer el código más claro y por lo tanto más fácil de asegurar. Así que para crear su propio contrato Vyper ERC-721, utilice [este contrato](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy) y modifíquelo para implementar la lógica de negocio que desee.
 
-## Conclusión {#conclusion}
+### Conclusión {#conclusion}
 
 A modo de recapitulación, he resumido algunas de las ideas más importantes de este contrato:
 

public/content/translations/es/developers/tutorials/waffle-test-simple-smart-contract/index.md

@@ -25,19 +25,19 @@ published: 2021-02-26
 - Ha utilizado algunos gestores de paquetes como yarn o npm.
 - Posee conocimientos muy básicos de contratos inteligentes y Solidity.
 
-# Introducción {#getting-started}
+## Introducción {#getting-started}
 
 Este tutorial explica una configuración de prueba y se ejecuta utilizando yarn, pero no pasa nada si prefiere hacerlo con npm, ya proporcionaré las indicaciones apropiadas a la documentación oficial de Waffle[](https://ethereum-waffle.readthedocs.io/en/latest/index.html).
 
-## Instalar las dependencias {#install-dependencies}
+### Instalar las dependencias {#install-dependencies}
 
 [Añada](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#installation) las dependencias ethereum-waffle y de typescript a las dependencias de desarrollo de su proyecto.
 
 ```bash
 yarn add --dev ethereum-waffle ts-node typescript @types/jest
 ```
 
-## Ejemplo de contrato inteligente {#example-smart-contract}
+### Ejemplo de contrato inteligente {#example-smart-contract}
 
 Durante el tutorial trabajaremos con un sencillo ejemplo de contrato inteligente: EtherSplitter. Permite casi se manera similar que cualquiera envíe algunos wei y, eventualmente, los divida entre dos receptores por defecto. La función dividida requiere que la cantidad de wei sea un número entero, de lo contario se revertirá. Para ambos receptores realiza una transferencia de wei, seguida a la emisión de un evento de transferencia.
 
@@ -67,7 +67,7 @@ contract EtherSplitter {
 }
 ```
 
-## Compilar el contrato {#compile-the-contract}
+### Compilar el contrato {#compile-the-contract}
 
 Para [compilar](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#compiling-the-contract) el contrato, añada las siguientes líneas al archivo de package.json:
 
@@ -90,7 +90,7 @@ A continuación, cree el archivo de configuración de Waffle en el directorio de
 
 Ejecute `yarn build`. Como resultado, el directorio `build` aparecerá con el contrato compilado de EtherSplitter en formato JSON.
 
-## Configuración de la prueba {#test-setup}
+### Configuración de la prueba {#test-setup}
 
 Para hacer pruebas con Waffle se tienen que utilizar los emparejadores de Chai y Mocha, por lo que necesita [añadirlos](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests) a su proyecto. Actualice su archivo package.json y añada la línea de `test` en la parte de scripts:
 
@@ -103,7 +103,7 @@ Para hacer pruebas con Waffle se tienen que utilizar los emparejadores de Chai y
 
 Si quiere [ejecutar](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#running-tests) sus pruebas, simplemente ejecute `yarn test` .
 
-# Pruebas {#testing}
+## Pruebas {#testing}
 
 Seguidamente cree el directorio `test` y un nuevo archivo `test\EtherSplitter.test.ts`. Copie el fragmento de abajo y péguelo en nuestro archivo de prueba.
 
@@ -134,7 +134,7 @@ Unas breves aclaraciones antes de que empecemos. El `MockProvider` incluye una s
 
 A continuación, declaramos una variable llamada «splitter»: este es nuestro contrato simulado EtherSplitter. Se crea antes de la ejecución de una única prueba a través del método `deployContract`. Este método simula la implementación de un contrato desde la cartera pasado como el primer parámetro (en nuestro caso, la cartera del emisor). El segundo parámetro es el ABI y el código de bytes del contrato de prueba: aquí pasamos el archivo json o el contrato EtherSplitter compilado desde el directorio `build`. El tercer parámetro es una matriz con los argumentos del constructor del contrato, que en nuestro caso, son las dos direcciones de los receptores.
 
-## ChangeBalances {#changebalances}
+### ChangeBalances {#changebalances}
 
 Primero, revisamos si el método dividido realmente cambia el saldo de las carteras de los receptores. Si dividimos 50 wei desde las cuentas de los emisores, esperaríamos que los saldos de ambos receptores aumentaran 25 wei. Usaremos el comparador `changeBalances` de Waffle:
 
@@ -162,7 +162,7 @@ Tenga en cuenta que en ambos casos `changeBalance` y `changeBalances`, enviamos
 
 A continuación, probaremos si el evento de transferencia se emitió después de cada transferencia de wei. Cambiaremos a otra máquina desde Waffle:
 
-## Emit {#emit}
+### Emit {#emit}
 
 ```ts
 it("Emits event on the transfer to the first receiver", async () => {
@@ -180,7 +180,7 @@ it("Emits event on the transfer to the second receiver", async () => {
 
 El emparejador `emit` nos permite revisar si un contrato ha emitido un evento al recurrir a un método. Como parámetros del emparejador `emit`, proporcionamos el simulacro de contrato que predecimos para emitir el evento, junto al nombre de ese evento. En nuestro caso, el simulacro de contrato es `splitter` y el nombre del evento: `Transfer`. También podemos verificar los valores precisos de los argumentos con los que se emitió el evento: enviamos tantos argumentos al emparejador `withArgs` como lo espera nuestra declaración de evento. En el caso del contrato EtherSplitter, enviamos las direcciones del emisor y del receptor, junto a la cantidad de wei transferida.
 
-## revertedWith {#revertedwith}
+### revertedWith {#revertedwith}
 
 Como último ejemplo, comprobaremos si se revirtió la transacción en caso de número impar de wei. Usaremos el emparejador `revertedWith`:
 
@@ -194,7 +194,7 @@ it("Reverts when Vei amount uneven", async () => {
 
 Si la prueba sale bien, nos garantizará que se ha revertido la transacción. Sin embargo, también debe haber una coincidencia exacta entre los mensajes que hemos enviado en la declaración `require` y el mensaje que esperamos en `revertedWith`. Si regresamos al código del contrato EtherSplitter, en la declaración `require` para la cantidad de wei, proporcionamos el mensaje: «no se permite una cantidad impar de wei». Esto coincide con el mensaje que esperamos en nuestra prueba. Si no coinciden, será que la prueba ha salido mal.
 
-# ¡Felicitaciones! {#congratulations}
+## ¡Felicitaciones! {#congratulations}
 
 ¡Acabas de dar tu primer gran paso para probar los contratos inteligentes con Waffle! Puede que también te interesen otros tutoriales de Waffle:
 

public/content/translations/fa/developers/docs/design-and-ux/dex-design-best-practice/index.md

@@ -180,15 +180,15 @@ DEX ها معمولاً جزئیات اضافی را در یک ردیف بالا
 
 در نهایت، نکات مثبت و منفی برای هر دو گزینه وجود دارد، اما جالب است که به نظر می رسد چگونه روند به سمت توکن سمت راست است.
 
-# رفتار دکمه {#button-behavior}
+## رفتار دکمه {#button-behavior}
 
 دکمه جداگانه ای برای تأیید نداشته باشید. همچنین یک کلیک جداگانه برای تأیید نداشته باشید. کاربر می‌خواهد Swap را انجام دهد، بنابراین فقط روی دکمه بگویید «swap» و تأیید را به عنوان اولین مرحله آغاز کنید. یک مودال می‌تواند پیشرفت را با یک استپر یا یک اعلان ساده "tx 1 of 2 - تایید" نشان دهد.
 
 ![یک رابط کاربری با دکمه‌های جداگانه برای تأیید و swap](./14.png)
 
 ![یک رابط کاربری با یک دکمه که تأیید می‌کند](./15.png)
 
-## دکمه به عنوان راهنمای متنی {#button-as-contextual-help}
+### دکمه به عنوان راهنمای متنی {#button-as-contextual-help}
 
 این دکمه می تواند به عنوان یک هشدار، وظیفه ای مضاعف را انجام دهد!
 
@@ -206,7 +206,7 @@ DEX ها معمولاً جزئیات اضافی را در یک ردیف بالا
 
 ![پیام خطا در CTA اصلی نشان داده می‌شود](./17.png)
 
-## مال خودتان را با این فایل فیگما بسازید {#build-your-own-with-this-figma-file}
+### مال خودتان را با این فایل فیگما بسازید {#build-your-own-with-this-figma-file}
 
 به لطف کار سخت پروتکل های متعدد، طراحی DEX بسیار بهبود یافته است. ما می دانیم که کاربر به چه اطلاعاتی نیاز دارد، چگونه باید آن را نشان دهیم و چگونه جریان را تا حد امکان روان کنیم.
 امیدواریم این مقاله یک نمای کلی از اصول UX ارائه دهد.

public/content/translations/fr/developers/docs/design-and-ux/dex-design-best-practice/index.md

@@ -179,15 +179,15 @@ La loi de proximité stipule que les éléments proches sont perçus comme étan
 
 En fin de compte, les deux options présentent des avantages et des inconvénients, mais il est intéressant de noter que la tendance est au jeton placé à droite.
 
-# Comportement du bouton {#button-behavior}
+## Comportement du bouton {#button-behavior}
 
 N'ayez pas de bouton séparé pour l'approbation. Évitez également de demander un clic séparé pour l'approbation. L'utilisateur veut effectuer un échange, il suffit donc d'indiquer "échanger" sur le bouton et de lancer l'approbation comme première étape. Une fenêtre modale peut afficher la progression avec un indicateur d'étapes, ou une simple notification du type "tx 1 sur 2 - approbation en cours".
 
 ![Une interface utilisateur avec des boutons séparés pour approuver et échanger](./14.png)
 
 ![Une interface utilisateur avec un seul bouton d'approbation](./15.png)
 
-## Bouton comme aide contextuelle {#button-as-contextual-help}
+### Bouton comme aide contextuelle {#button-as-contextual-help}
 
 Le bouton peut également servir d'alerte !
 
@@ -205,7 +205,7 @@ Le bouton peut également être **associé à l'action** qui doit être effectu
 
 ![Message d'erreur affiché dans le principal appel à l'action](./17.png)
 
-## Construisez le vôtre avec ce fichier Figma {#build-your-own-with-this-figma-file}
+### Construisez le vôtre avec ce fichier Figma {#build-your-own-with-this-figma-file}
 
 Grâce au travail acharné de plusieurs protocoles, la conception des DEX s'est beaucoup améliorée. Nous savons de quelles informations l'utilisateur a besoin, de quelle manière nous devons les présenter et comment rendre le flux aussi fluide que possible.
 Nous espérons que cet article vous offrira un aperçu solide des principes UX.

public/content/translations/fr/developers/tutorials/erc-721-vyper-annotated-code/index.md

@@ -614,11 +614,11 @@ def burn(_tokenId: uint256):
 
 Toute personne autorisée à transférer un jeton est autorisée à le détruire. Bien que détruire un jeton semble équivalent à le transférer à l'adresse zéro, celle-ci ne reçoit pas réellement le jeton. Cela nous permet de libérer tout l'espace de stockage qui était utilisé pour le jeton, ce qui peut réduire les frais de gaz de la transaction.
 
-# Utiliser ce contrat {#using-contract}
+## Utiliser ce contrat {#using-contract}
 
 Contrairement à Solidity, Vyper n'a pas de système d'héritage. Il s'agit d'un choix de conception délibéré visant à rendre le code plus clair et donc plus facile à sécuriser. Donc pour créer votre propre contrat Vyper ERC-721, vous prenez [ce contrat](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy) puis vous le modifiez en fonction de la stratégie commerciale que vous souhaitez mettre en œuvre.
 
-## Conclusion {#conclusion}
+### Conclusion {#conclusion}
 
 Voici les principaux points à retenir sur ce contrat :