Units API.

See the Weblate's Web API documentation for detailed description of the API.

GET /api/units/23551/?format=api
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/es/?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": [
        "Ahora es el momento de crear su propio archivo de configuración con las reglas personalizadas del firewall para proteger la red interna. Se encontrará con algunas complicaciones porque no todas las funcionalidades del firewall están disponibles en los paquetes bridge. Hay además una diferencia entre los paquetes que están en proceso de reenvío y los paquetes que está recibiendo la máquina local. En general, los paquetes de entrada pasan por el firewall solo una vez, no dos veces, como suele ser el caso; en realidad se filtran solo después de la recepción, por lo que las reglas que usan <option>out</option> o <option>xmit</option> nunca coincidirán. Yo utilizo <option>in via</option>, que es una sintaxis más antigua pero tiene sentido cuando la lees. Otra limitación es que usted solo puede usar solo los comandos <option>pass</option> o <option>reject</option> para los paquetes filtrados por un bridge. Opciones más complejas como <option>divert</option>, <option>forward</option> o <option>reject</option> no están disponibles. Estas opciones pueden seguir utilizándose, pero solo en el tráfico hacia o desde la propia máquina bridge (si tiene una dirección IP)."
    ],
    "id_hash": -7992917455695405206,
    "content_hash": -7992917455695405206,
    "location": "article.translate.xml:226",
    "context": "",
    "note": "(itstool) path: sect1/para",
    "flags": "",
    "labels": [],
    "state": 20,
    "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": 23551,
    "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_filtering-bridge/es/?checksum=111373ec1e419f6a",
    "url": "https://translate-dev.freebsd.org/api/units/23551/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2019-10-20T12:03:43.498753Z"
}