Units API.

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

GET /api/units/31027/?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_vm-design/pt_BR/?format=api",
    "source": [
        "FreeBSD solves the deep layering problem with a special optimization called the <quote>All Shadowed Case</quote>. This case occurs if either C1 or C2 take sufficient COW faults to completely shadow all pages in B. Lets say that C1 achieves this. C1 can now bypass B entirely, so rather then have C1-&gt;B-&gt;A and C2-&gt;B-&gt;A we now have C1-&gt;A and C2-&gt;B-&gt;A. But look what also happened—now B has only one reference (C2), so we can collapse B and C2 together. The end result is that B is deleted entirely and we have C1-&gt;A and C2-&gt;A. It is often the case that B will contain a large number of pages and neither C1 nor C2 will be able to completely overshadow it. If we fork again and create a set of D layers, however, it is much more likely that one of the D layers will eventually be able to completely overshadow the much smaller dataset represented by C1 or C2. The same optimization will work at any point in the graph and the grand result of this is that even on a heavily forked machine VM Object stacks tend to not get much deeper then 4. This is true of both the parent and the children and true whether the parent is doing the forking or whether the children cascade forks."
    ],
    "previous_source": "",
    "target": [
        "O FreeBSD resolve o problema de camadas profundas com uma otimização especial chamada <quote>All Shadowed Case</quote>. Este caso ocorre se C1 ou C2 tiverem falhas de COW suficientes para fazer uma copia de sombra completa de todas as páginas em B. Digamos que C1 consiga isso. C1 agora pode ignorar B completamente, então, em vez de temos C1-&gt;B-&gt;A e C2-&gt;B-&gt;A temos agora C1-&gt;A e C2-&gt;B-&gt;A. Mas veja o que também aconteceu - agora B tem apenas uma referência (C2), então podemos unir B e C2. O resultado final é que B é deletado inteiramente e temos C1-&gt;A e C2-&gt;A. É comum que B contenha um grande número de páginas e nem C1 nem C2 possam ofuscar completamente. Se nós forçarmos novamente e criarmos um conjunto de camadas D, no entanto, é muito mais provável que uma das camadas D eventualmente seja capaz de ofuscar completamente o conjunto de dados muito menor representado por C1 ou C2. A mesma otimização funcionará em qualquer ponto do gráfico e o grande resultado disso é que, mesmo em uma máquina diversos forks, pilhas de objetos da VM tendem a não ficar muito mais profundas do que 4. Isso é verdade tanto para o processo pai quanto para os filhos e verdadeiro quer seja o processo pai fazendo o fork ou os processos filhos fazendo forks em cascata."
    ],
    "id_hash": 3235970144273771436,
    "content_hash": 3235970144273771436,
    "location": "article.translate.xml:295",
    "context": "",
    "note": "(itstool) path: sect1/para",
    "flags": "",
    "labels": [],
    "state": 20,
    "fuzzy": false,
    "translated": true,
    "approved": false,
    "position": 38,
    "has_suggestion": false,
    "has_comment": false,
    "has_failing_check": false,
    "num_words": 219,
    "source_unit": "https://translate-dev.freebsd.org/api/units/102077/?format=api",
    "priority": 100,
    "id": 31027,
    "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/pt_BR/?checksum=ace879b389352bac",
    "url": "https://translate-dev.freebsd.org/api/units/31027/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2019-10-20T12:20:03.390842Z"
}