From 78e6c98321406a48936cb8288a55265df9ce27e4 Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Wed, 19 Mar 2025 01:40:39 +0000 Subject: [PATCH 1/3] chore: import translations for it --- .../translation-program/translators-guide/index.md | 4 ++-- .../consensus-mechanisms/pos/rewards-and-penalties/index.md | 2 +- .../developers/docs/networking-layer/portal-network/index.md | 2 +- .../docs/smart-contracts/formal-verification/index.md | 2 +- .../it/developers/docs/smart-contracts/security/index.md | 2 +- public/content/translations/it/roadmap/merge/index.md | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git a/public/content/translations/it/contributing/translation-program/translators-guide/index.md b/public/content/translations/it/contributing/translation-program/translators-guide/index.md index ac641181cb3..86ab65ec7d8 100644 --- a/public/content/translations/it/contributing/translation-program/translators-guide/index.md +++ b/public/content/translations/it/contributing/translation-program/translators-guide/index.md @@ -116,7 +116,7 @@ Il modo migliore per gestire i collegamenti è copiarli direttamente dal testo d ![Esempio di link.png](./example-of-link.png) -I link appaiono nel testo di partenza anche sotto forma di tag (cioè \<0> \). Se passi sul tag, l'editor ne mostrerà il contenuto completo; talvolta questi tag rappresentano dei link. +I link appaiono nel testo di partenza anche sotto forma di tag (cioè <0> ). Se passi sul tag, l'editor ne mostrerà il contenuto completo; talvolta questi tag rappresentano dei link. È molto importante copiare i link dal testo di partenza senza modificarne l'ordine. @@ -154,7 +154,7 @@ nonce - _Testo non traducibile_ Il testo di partenza contiene anche tag abbreviati, contenenti solo numeri, il che significa che la loro funzione non è immediatamente ovvia. Puoi passare su questi tag per vedere esattamente quale scopo assolvono. -Nell'esempio seguente, passando con il mouse sul \<0> tag puoi vedere che rappresenta `` e contiene un frammento di codice, quindi il contenuto non va tradotto. +Nell'esempio seguente, passando con il mouse sul <0> tag puoi vedere che rappresenta `` e contiene un frammento di codice, quindi il contenuto non va tradotto. ![Esempio di tag ambigui.png](./example-of-ambiguous-tags.png) diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index f4bac577534..97d49cb69a2 100644 --- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -74,7 +74,7 @@ Se queste azioni sono rilevate, il validatore viene tagliato. Ciò significa che ## Perdita per inattività {#inactivity-leak} -Se il livello del consenso ha superato più di quattro epoche senza finalizzare, un protocollo di emergenza detto "perdita di inattività" viene attivato. Lo scopo ultimo della perdita per inattività è creare le condizioni necessarie perché la catena recuperi la finalità. Come spiegato sopra, la finalità richiede una maggioranza dei 2/3 dell'ether in staking totale per accordarsi sui punti di controllo di origine e di destinazione. Se validatori che rappresentano oltre 1/3 dei validatori totali vanno offline o non riescono a inviare le attestazioni corrette, non è possibile che una supermaggioranza dei 2/3 finalizzi i punti di controllo. La perdita per inattività consente allo stake appartenente ai validatori inattivi di disperdersi gradualmente finché non controllano meno di 1/3 dello stake totale, consentendo ai validatori attivi rimanenti di finalizzare la catena. Indipendentemente da quanto sia grande il gruppo di validatori inattivi, i rimanenti validatori attivi alla fine controlleranno più di 2/3 dello stake. La perdita di stake è un forte incentivo per i validatori inattivi a riattivarsi appena possibile! Uno scenario di perdita per inattività è stato riscontrato sulla rete di prova Medalla quando \<66% di validatori attivi è riuscito ad arrivare al consenso sulla testa corrente della blockchain. La perdita per inattività è stata attivata e la finalità è stata infine recuperata! +Se il livello del consenso ha superato più di quattro epoche senza finalizzare, un protocollo di emergenza detto "perdita di inattività" viene attivato. Lo scopo ultimo della perdita per inattività è creare le condizioni necessarie perché la catena recuperi la finalità. Come spiegato sopra, la finalità richiede una maggioranza dei 2/3 dell'ether in staking totale per accordarsi sui punti di controllo di origine e di destinazione. Se validatori che rappresentano oltre 1/3 dei validatori totali vanno offline o non riescono a inviare le attestazioni corrette, non è possibile che una supermaggioranza dei 2/3 finalizzi i punti di controllo. La perdita per inattività consente allo stake appartenente ai validatori inattivi di disperdersi gradualmente finché non controllano meno di 1/3 dello stake totale, consentendo ai validatori attivi rimanenti di finalizzare la catena. Indipendentemente da quanto sia grande il gruppo di validatori inattivi, i rimanenti validatori attivi alla fine controlleranno più di 2/3 dello stake. La perdita di stake è un forte incentivo per i validatori inattivi a riattivarsi appena possibile! Uno scenario di perdita per inattività è stato riscontrato sulla rete di prova Medalla quando <66% di validatori attivi è riuscito ad arrivare al consenso sulla testa corrente della blockchain. La perdita per inattività è stata attivata e la finalità è stata infine recuperata! Il design di ricompense, sanzioni e frazionamenti del meccanismo di consenso incoraggia i singoli validatori a comportarsi correttamente. Tuttavia, da tali scelte di progettazione emerge un sistema che incentiva fortemente la distribuzione equa dei validatori tra i vari client e dovrebbe disincentivare fortemente il dominio di un singolo client. diff --git a/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md index 114400531ff..3597ad0b455 100644 --- a/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md +++ b/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md @@ -55,7 +55,7 @@ I vantaggi di questa progettazione della rete sono: - Ridurre la dipendenza da fornitori centralizzati - Ridurre l'utilizzo della larghezza di banda di Internet - Sincronizzazione ridotta o nulla -- Accessibile a dispositivi con risorse limitate (\<1 GB di RAM, \<100 MB di spazio su disco, 1 CPU) +- Accessibile a dispositivi con risorse limitate (<1 GB di RAM, <100 MB di spazio su disco, 1 CPU) Il diagramma seguente mostra le funzioni dei client esistenti che possono essere fornite dalla Rete Portal, consentendo agli utenti di accedere a tali funzioni su dispositivi con risorse molto limitate. diff --git a/public/content/translations/it/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/it/developers/docs/smart-contracts/formal-verification/index.md index ff79bfacf8a..2329ead4cd1 100644 --- a/public/content/translations/it/developers/docs/smart-contracts/formal-verification/index.md +++ b/public/content/translations/it/developers/docs/smart-contracts/formal-verification/index.md @@ -70,7 +70,7 @@ Le specifiche formali di basso livello possono essere date come proprietà in st ### Proprietà in stile Hoare {#hoare-style-properties} -La [logica di Hoare](https://en.wikipedia.org/wiki/Hoare_logic) fornisce una serie di regole formali per ragionare sulla correttezza dei programmi, contratti intelligenti inclusi. Una proprietà in stile Hoare è rappresentata da una tripletta di Hoare \{_P_}_c_\{_Q_}, dove _c_ è un programma e _P_ e _Q_ sono predicati sullo stato della _c_ (cioè, il programma), formalmente descritte rispettivamente come _precondizioni_ e _postcondizioni_. +La [logica di Hoare](https://en.wikipedia.org/wiki/Hoare_logic) fornisce una serie di regole formali per ragionare sulla correttezza dei programmi, contratti intelligenti inclusi. Una proprietà in stile Hoare è rappresentata da una tripletta di Hoare {_P_}_c_{_Q_}, dove _c_ è un programma e _P_ e _Q_ sono predicati sullo stato della _c_ (cioè, il programma), formalmente descritte rispettivamente come _precondizioni_ e _postcondizioni_. Una precondizione è un predicato che descrive le condizioni richieste per l'esecuzione corretta di una funzione; gli utenti che chiamano il contratto devono soddisfare tale requisito. Una postcondizione è un predicato che descrive la condizione che una funzione stabilisce se eseguita correttamente; gli utenti possono prevedere che questa condizione sia vera dopo aver chiamato la funzione. Un'_invariante_ nella logica di Hoare è un predicato che è preservato dall'esecuzione di una funzione (cioè, non cambia). diff --git a/public/content/translations/it/developers/docs/smart-contracts/security/index.md b/public/content/translations/it/developers/docs/smart-contracts/security/index.md index efba6ee7d12..8c4330fc243 100644 --- a/public/content/translations/it/developers/docs/smart-contracts/security/index.md +++ b/public/content/translations/it/developers/docs/smart-contracts/security/index.md @@ -115,7 +115,7 @@ L'esistenza di controlli e ricompense per la caccia ai bug non è una scusa per - Usa un [ambiente di sviluppo](/developers/docs/frameworks/) per testare, compilare e distribuire i contratti intelligenti -- Esegui il tuo codice tramite strumenti di analisi del codice di base, come [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn), Mythril e Slither. Idealmente, dovresti farlo prima della fusione di ogni richiesta pull e confrontare le differenze nell'output +- Esegui il tuo codice tramite strumenti di analisi del codice di base, come [Cyfrin Aaderyn](https://github.com/Cyfrin/aderyn), Mythril e Slither. Idealmente, dovresti farlo prima della fusione di ogni richiesta pull e confrontare le differenze nell'output - Assicurati che il tuo codice si compili senza errori e che il compilatore di Solidity non emetta alcun avviso diff --git a/public/content/translations/it/roadmap/merge/index.md b/public/content/translations/it/roadmap/merge/index.md index 66700f86eb6..a4e944b8fdb 100644 --- a/public/content/translations/it/roadmap/merge/index.md +++ b/public/content/translations/it/roadmap/merge/index.md @@ -92,7 +92,7 @@ title="Sviluppatori di dapp e contratti intelligenti" contentPreview="The Merge was designed to have minimal impact on smart contract and dapp developers." id="developers"> -La Fusione è stata accompagnata da modifiche al consenso, incluse anche modifiche relative a: +La Fusione è stata accompagnata da modifiche al consenso, incluse anche modifiche relative a:<
  • struttura del blocco
    • From f2f7ea5ab7c553c68124dd2a01cbd2e7b3a396d4 Mon Sep 17 00:00:00 2001 From: Pablo Date: Fri, 21 Mar 2025 17:08:34 +0100 Subject: [PATCH 2/3] fix md --- .../translation-program/translators-guide/index.md | 4 ++-- .../consensus-mechanisms/pos/rewards-and-penalties/index.md | 2 +- .../developers/docs/networking-layer/portal-network/index.md | 2 +- public/content/translations/it/roadmap/merge/index.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/public/content/translations/it/contributing/translation-program/translators-guide/index.md b/public/content/translations/it/contributing/translation-program/translators-guide/index.md index 86ab65ec7d8..b9a7c3d0bf5 100644 --- a/public/content/translations/it/contributing/translation-program/translators-guide/index.md +++ b/public/content/translations/it/contributing/translation-program/translators-guide/index.md @@ -116,7 +116,7 @@ Il modo migliore per gestire i collegamenti è copiarli direttamente dal testo d ![Esempio di link.png](./example-of-link.png) -I link appaiono nel testo di partenza anche sotto forma di tag (cioè <0> ). Se passi sul tag, l'editor ne mostrerà il contenuto completo; talvolta questi tag rappresentano dei link. +I link appaiono nel testo di partenza anche sotto forma di tag (cioè `<0> `). Se passi sul tag, l'editor ne mostrerà il contenuto completo; talvolta questi tag rappresentano dei link. È molto importante copiare i link dal testo di partenza senza modificarne l'ordine. @@ -154,7 +154,7 @@ nonce - _Testo non traducibile_ Il testo di partenza contiene anche tag abbreviati, contenenti solo numeri, il che significa che la loro funzione non è immediatamente ovvia. Puoi passare su questi tag per vedere esattamente quale scopo assolvono. -Nell'esempio seguente, passando con il mouse sul <0> tag puoi vedere che rappresenta `` e contiene un frammento di codice, quindi il contenuto non va tradotto. +Nell'esempio seguente, passando con il mouse sul `<0>` tag puoi vedere che rappresenta `` e contiene un frammento di codice, quindi il contenuto non va tradotto. ![Esempio di tag ambigui.png](./example-of-ambiguous-tags.png) diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index 97d49cb69a2..f4bac577534 100644 --- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -74,7 +74,7 @@ Se queste azioni sono rilevate, il validatore viene tagliato. Ciò significa che ## Perdita per inattività {#inactivity-leak} -Se il livello del consenso ha superato più di quattro epoche senza finalizzare, un protocollo di emergenza detto "perdita di inattività" viene attivato. Lo scopo ultimo della perdita per inattività è creare le condizioni necessarie perché la catena recuperi la finalità. Come spiegato sopra, la finalità richiede una maggioranza dei 2/3 dell'ether in staking totale per accordarsi sui punti di controllo di origine e di destinazione. Se validatori che rappresentano oltre 1/3 dei validatori totali vanno offline o non riescono a inviare le attestazioni corrette, non è possibile che una supermaggioranza dei 2/3 finalizzi i punti di controllo. La perdita per inattività consente allo stake appartenente ai validatori inattivi di disperdersi gradualmente finché non controllano meno di 1/3 dello stake totale, consentendo ai validatori attivi rimanenti di finalizzare la catena. Indipendentemente da quanto sia grande il gruppo di validatori inattivi, i rimanenti validatori attivi alla fine controlleranno più di 2/3 dello stake. La perdita di stake è un forte incentivo per i validatori inattivi a riattivarsi appena possibile! Uno scenario di perdita per inattività è stato riscontrato sulla rete di prova Medalla quando <66% di validatori attivi è riuscito ad arrivare al consenso sulla testa corrente della blockchain. La perdita per inattività è stata attivata e la finalità è stata infine recuperata! +Se il livello del consenso ha superato più di quattro epoche senza finalizzare, un protocollo di emergenza detto "perdita di inattività" viene attivato. Lo scopo ultimo della perdita per inattività è creare le condizioni necessarie perché la catena recuperi la finalità. Come spiegato sopra, la finalità richiede una maggioranza dei 2/3 dell'ether in staking totale per accordarsi sui punti di controllo di origine e di destinazione. Se validatori che rappresentano oltre 1/3 dei validatori totali vanno offline o non riescono a inviare le attestazioni corrette, non è possibile che una supermaggioranza dei 2/3 finalizzi i punti di controllo. La perdita per inattività consente allo stake appartenente ai validatori inattivi di disperdersi gradualmente finché non controllano meno di 1/3 dello stake totale, consentendo ai validatori attivi rimanenti di finalizzare la catena. Indipendentemente da quanto sia grande il gruppo di validatori inattivi, i rimanenti validatori attivi alla fine controlleranno più di 2/3 dello stake. La perdita di stake è un forte incentivo per i validatori inattivi a riattivarsi appena possibile! Uno scenario di perdita per inattività è stato riscontrato sulla rete di prova Medalla quando \<66% di validatori attivi è riuscito ad arrivare al consenso sulla testa corrente della blockchain. La perdita per inattività è stata attivata e la finalità è stata infine recuperata! Il design di ricompense, sanzioni e frazionamenti del meccanismo di consenso incoraggia i singoli validatori a comportarsi correttamente. Tuttavia, da tali scelte di progettazione emerge un sistema che incentiva fortemente la distribuzione equa dei validatori tra i vari client e dovrebbe disincentivare fortemente il dominio di un singolo client. diff --git a/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md index 3597ad0b455..114400531ff 100644 --- a/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md +++ b/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md @@ -55,7 +55,7 @@ I vantaggi di questa progettazione della rete sono: - Ridurre la dipendenza da fornitori centralizzati - Ridurre l'utilizzo della larghezza di banda di Internet - Sincronizzazione ridotta o nulla -- Accessibile a dispositivi con risorse limitate (<1 GB di RAM, <100 MB di spazio su disco, 1 CPU) +- Accessibile a dispositivi con risorse limitate (\<1 GB di RAM, \<100 MB di spazio su disco, 1 CPU) Il diagramma seguente mostra le funzioni dei client esistenti che possono essere fornite dalla Rete Portal, consentendo agli utenti di accedere a tali funzioni su dispositivi con risorse molto limitate. diff --git a/public/content/translations/it/roadmap/merge/index.md b/public/content/translations/it/roadmap/merge/index.md index a4e944b8fdb..66700f86eb6 100644 --- a/public/content/translations/it/roadmap/merge/index.md +++ b/public/content/translations/it/roadmap/merge/index.md @@ -92,7 +92,7 @@ title="Sviluppatori di dapp e contratti intelligenti" contentPreview="The Merge was designed to have minimal impact on smart contract and dapp developers." id="developers"> -La Fusione è stata accompagnata da modifiche al consenso, incluse anche modifiche relative a:< +La Fusione è stata accompagnata da modifiche al consenso, incluse anche modifiche relative a:
    • struttura del blocco
      • From 6de03c36922a52165980c9c6653bbf8d983650b4 Mon Sep 17 00:00:00 2001 From: Paul Wackerow <54227730+wackerow@users.noreply.github.com> Date: Fri, 21 Mar 2025 15:10:32 -0700 Subject: [PATCH 3/3] revert: inappropriate crowdin change --- .../it/developers/docs/smart-contracts/security/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/it/developers/docs/smart-contracts/security/index.md b/public/content/translations/it/developers/docs/smart-contracts/security/index.md index 8c4330fc243..efba6ee7d12 100644 --- a/public/content/translations/it/developers/docs/smart-contracts/security/index.md +++ b/public/content/translations/it/developers/docs/smart-contracts/security/index.md @@ -115,7 +115,7 @@ L'esistenza di controlli e ricompense per la caccia ai bug non è una scusa per - Usa un [ambiente di sviluppo](/developers/docs/frameworks/) per testare, compilare e distribuire i contratti intelligenti -- Esegui il tuo codice tramite strumenti di analisi del codice di base, come [Cyfrin Aaderyn](https://github.com/Cyfrin/aderyn), Mythril e Slither. Idealmente, dovresti farlo prima della fusione di ogni richiesta pull e confrontare le differenze nell'output +- Esegui il tuo codice tramite strumenti di analisi del codice di base, come [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn), Mythril e Slither. Idealmente, dovresti farlo prima della fusione di ogni richiesta pull e confrontare le differenze nell'output - Assicurati che il tuo codice si compili senza errori e che il compilatore di Solidity non emetta alcun avviso