Unit Instance

HTTP 200 OK
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_filtering-bridge/en/?format=api",
    "source": [
        "Now it is time to create your own file with custom firewall rules, in order to secure the inside network. There will be some complication in doing this because not all of the firewall functionalities are available on bridged packets. Furthermore, there is a difference between the packets that are in the process of being forwarded and packets that are being received by the local machine. In general, incoming packets are run through the firewall only once, not twice as is normally the case; in fact they are filtered only upon receipt, so rules that use <option>out</option> or <option>xmit</option> will never match. Personally, I use <option>in via</option> which is an older syntax, but one that has a sense when you read it. Another limitation is that you are restricted to use only <option>pass</option> or <option>drop</option> commands for packets filtered by a bridge. Sophisticated things like <option>divert</option>, <option>forward</option> or <option>reject</option> are not available. Such options can still be used, but only on traffic to or from the bridge machine itself (if it has an IP address)."
    ],
    "previous_source": "",
    "target": [
        "Now it is time to create your own file with custom firewall rules, in order to secure the inside network. There will be some complication in doing this because not all of the firewall functionalities are available on bridged packets. Furthermore, there is a difference between the packets that are in the process of being forwarded and packets that are being received by the local machine. In general, incoming packets are run through the firewall only once, not twice as is normally the case; in fact they are filtered only upon receipt, so rules that use <option>out</option> or <option>xmit</option> will never match. Personally, I use <option>in via</option> which is an older syntax, but one that has a sense when you read it. Another limitation is that you are restricted to use only <option>pass</option> or <option>drop</option> commands for packets filtered by a bridge. Sophisticated things like <option>divert</option>, <option>forward</option> or <option>reject</option> are not available. Such options can still be used, but only on traffic to or from the bridge machine itself (if it has an IP address)."
    ],
    "id_hash": -7992917455695405206,
    "content_hash": -7992917455695405206,
    "location": "article.translate.xml:226",
    "context": "",
    "note": "(itstool) path: sect1/para",
    "flags": "",
    "labels": [],
    "state": 100,
    "fuzzy": false,
    "translated": true,
    "approved": false,
    "position": 42,
    "has_suggestion": false,
    "has_comment": false,
    "has_failing_check": false,
    "num_words": 175,
    "source_unit": "https://translate-dev.freebsd.org/api/units/98136/?format=api",
    "priority": 100,
    "id": 98136,
    "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_filtering-bridge/en/?checksum=111373ec1e419f6a",
    "url": "https://translate-dev.freebsd.org/api/units/98136/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2019-10-20T12:03:43.498753Z"
}