Merge pull request #15715 from ethereum/fix-build-warnings

fix: "Link component missing href prop" build warnings

Author: corwintines

package.json

@@ -150,5 +150,5 @@
     "unist-util-visit": "^5.0.0",
     "xml2js": "^0.6.2"
   },
-  "packageManager": "pnpm@10.11.1+sha512.e519b9f7639869dc8d5c3c5dfef73b3f091094b0a006d7317353c72b124e80e1afd429732e28705ad6bfa1ee879c1fce46c128ccebd3192101f43dd67c667912"
+  "packageManager": "pnpm@10.12.3+sha512.467df2c586056165580ad6dfb54ceaad94c5a30f80893ebdec5a44c5aa73c205ae4a5bb9d5ed6bb84ea7c249ece786642bbb49d06a307df218d03da41c317417"
 }

public/content/community/events/organizing/index.md

@@ -92,6 +92,6 @@ _Δεν θεωρούμε ότι ανήκουν στο επίπεδο 2 οι άλ
 
 Εάν θέλετε να προσθέσετε ένα επίπεδο 2 στο ethereum.org, δημιουργήστε ένα ζήτημα στο GitHub.
 
-<ButtonLink to="https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml">
+<ButtonLink href="https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml">
   Δημιουργήστε ένα ζήτημα
 </ButtonLink>

public/content/translations/el/contributing/adding-layer-2s/index.md

@@ -27,6 +27,6 @@ description: Τα κριτήριά μας για την καταχώριση τ
 
 Αν θέλετε να προσθέσετε έναν πόρο περιεχομένου στο ethereum.org και πληροί τα κριτήρια, δημιουργήστε ένα ζήτημα στο GitHub.
 
-<ButtonLink to="https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=">
+<ButtonLink href="https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=">
   Δημιουργήστε ένα ζήτημα
 </ButtonLink>

public/content/translations/el/contributing/content-resources/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/el/developers/docs/design-and-ux/dex-design-best-practice/index.md

@@ -92,6 +92,6 @@ _No consideramos que otras soluciones de escalabilidad que no utilicen Ethereum
 
 Si quiere añadir una capa 2 a ethereum.org, cree una incidencia en GitHub.
 
-<ButtonLink to="https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml">
+<ButtonLink href="https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml">
   Crear una incidencia
 </ButtonLink>

public/content/translations/es/contributing/adding-layer-2s/index.md

@@ -27,6 +27,6 @@ Los recursos de aprendizaje se evaluarán a tenor de los siguientes criterios:
 
 Si desea añadir un recurso de contenido a ethereum.org y cumple con los criterios, cree una incidencia en GitHub.
 
-<ButtonLink to="https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=">
+<ButtonLink href="https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=">
   Crear una incidencia
 </ButtonLink>

public/content/translations/es/contributing/content-resources/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/docs/design-and-ux/dex-design-best-practice/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/erc-721-vyper-annotated-code/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: