fix: english markdown syntax

use backtick inline pre-formatted text instead of individual escapes; escapes causing issues with crowdin transpiling. Includes wrapping curly brackets in backticks to avoid them being interpreted as JS within MDX parser

Author: wackerow

public/content/contributing/translation-program/translators-guide/index.md

@@ -122,7 +122,7 @@ The best way to handle links is to copy them directly from the source, either by
 
 ![Example of link.png](./example-of-link.png)
 
-Links also appear in the source text in the form of tags (i.e. \<0> \</0>). If you hover over the tag, the editor will show its full content - sometimes these tags will represent links.
+Links also appear in the source text in the form of tags (i.e. `<0>` `</0>`). If you hover over the tag, the editor will show its full content - sometimes these tags will represent links.
 
 It is very important to copy the links from the source and not change their order.
 
@@ -160,7 +160,7 @@ nonce - _Non-translatable text_
 
 The source text also contains shortened tags, which only contain numbers, meaning that their function is not immediately obvious. You can hover over these tags to see exactly which function they serve.
 
-In the example below, you can see that hovering over the \<0> tag shows that it represents `<code>` and contains a code snippet, therefore the content inside these tags should not be translated.
+In the example below, you can see that hovering over the `<0>` tag shows that it represents `<code>` and contains a code snippet, therefore the content inside these tags should not be translated.
 
 ![Example of ambiguous tags.png](./example-of-ambiguous-tags.png)
 

public/content/developers/docs/smart-contracts/formal-verification/index.md

@@ -70,7 +70,7 @@ Low-level formal specifications can be given as either Hoare-style properties or
 
 ### Hoare-style properties {#hoare-style-properties}
 
-[Hoare Logic](https://en.wikipedia.org/wiki/Hoare_logic) provides a set of formal rules for reasoning about the correctness of programs, including smart contracts. A Hoare-style property is represented by a Hoare triple \{_P_}_c_\{_Q_}, where _c_ is a program and _P_ and _Q_ are predicates on the state of the _c_ (i.e., the program), formally described as _preconditions_ and _postconditions_, respectively.
+[Hoare Logic](https://en.wikipedia.org/wiki/Hoare_logic) provides a set of formal rules for reasoning about the correctness of programs, including smart contracts. A Hoare-style property is represented by a Hoare triple `{P}c{Q}`, where `c` is a program and `P` and `Q` are predicates on the state of the `c` (i.e., the program), formally described as _preconditions_ and _postconditions_, respectively.
 
 A precondition is a predicate describing the conditions required for the correct execution of a function; users calling into the contract must satisfy this requirement. A postcondition is a predicate describing the condition that a function establishes if correctly executed; users can expect this condition to be true after calling into the function. An _invariant_ in Hoare logic is a predicate that is preserved by execution of a function (i.e., it doesn't change).