Translation components API.

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

GET /api/translations/freebsd-doc/articles_vm-design/pt_BR/units/?format=api&page=3
HTTP 200 OK
Allow: GET, POST, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "count": 108,
    "next": null,
    "previous": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/pt_BR/units/?format=api&page=2",
    "results": [
        {
            "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/pt_BR/?format=api",
            "source": [
                "But in the <trademark class=\"registered\">UNIX</trademark> world you are dealing with virtual address spaces, not physical address spaces. Any program you write will see the virtual address space given to it. The actual <emphasis>physical</emphasis> pages underlying that virtual address space are not necessarily physically contiguous! In fact, you might have two pages that are side by side in a processes address space which wind up being at offset 0 and offset 128K in <emphasis>physical</emphasis> memory."
            ],
            "previous_source": "",
            "target": [
                "Mas no mundo <trademark class=\"registered\">UNIX</trademark> você está lidando com espaços de endereço virtual, não com espaços de endereço físico. Qualquer programa que você escreva verá o espaço de endereço virtual dado a ele. As páginas reais <emphasis>físicas</emphasis> subjacentes a este espaço de endereço virtual não são necessariamente contíguas fisicamente! De fato, você pode ter duas páginas que estão lado a lado em um espaço de endereço de processos que termina no offset 0 e desloca 128K na memória <emphasis>física</emphasis>."
            ],
            "id_hash": 7178675671754178708,
            "content_hash": 7178675671754178708,
            "location": "article.translate.xml:869",
            "context": "",
            "note": "(itstool) path: answer/para",
            "flags": "",
            "labels": [],
            "state": 20,
            "fuzzy": false,
            "translated": true,
            "approved": false,
            "position": 105,
            "has_suggestion": false,
            "has_comment": false,
            "has_failing_check": false,
            "num_words": 74,
            "source_unit": "https://translate-dev.freebsd.org/api/units/102144/?format=api",
            "priority": 100,
            "id": 31094,
            "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/pt_BR/?checksum=e39fc77d3ca58094",
            "url": "https://translate-dev.freebsd.org/api/units/31094/?format=api",
            "explanation": "",
            "extra_flags": "",
            "pending": false,
            "timestamp": "2019-10-20T12:20:04.225279Z"
        },
        {
            "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/pt_BR/?format=api",
            "source": [
                "A program normally assumes that two side-by-side pages will be optimally cached. That is, that you can access data objects in both pages without having them blow away each other's cache entry. But this is only true if the physical pages underlying the virtual address space are contiguous (insofar as the cache is concerned)."
            ],
            "previous_source": "",
            "target": [
                "Um programa normalmente pressupõe que duas páginas lado a lado serão armazenadas em cache de maneira ideal. Ou seja, você pode acessar objetos de dados em ambas as páginas sem que elas descartem a entrada de cache uma da outra. Mas isso só é verdadeiro se as páginas físicas subjacentes ao espaço de endereço virtual forem contíguas (no que se refere ao cache)."
            ],
            "id_hash": -1376886729854784282,
            "content_hash": -1376886729854784282,
            "location": "article.translate.xml:878",
            "context": "",
            "note": "(itstool) path: answer/para",
            "flags": "",
            "labels": [],
            "state": 20,
            "fuzzy": false,
            "translated": true,
            "approved": false,
            "position": 106,
            "has_suggestion": false,
            "has_comment": false,
            "has_failing_check": false,
            "num_words": 54,
            "source_unit": "https://translate-dev.freebsd.org/api/units/102145/?format=api",
            "priority": 100,
            "id": 31095,
            "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/pt_BR/?checksum=6ce450d0730e6ce6",
            "url": "https://translate-dev.freebsd.org/api/units/31095/?format=api",
            "explanation": "",
            "extra_flags": "",
            "pending": false,
            "timestamp": "2019-10-20T12:20:04.232868Z"
        },
        {
            "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/pt_BR/?format=api",
            "source": [
                "This is what Page coloring does. Instead of assigning <emphasis>random</emphasis> physical pages to virtual addresses, which may result in non-optimal cache performance, Page coloring assigns <emphasis>reasonably-contiguous</emphasis> physical pages to virtual addresses. Thus programs can be written under the assumption that the characteristics of the underlying hardware cache are the same for their virtual address space as they would be if the program had been run directly in a physical address space."
            ],
            "previous_source": "",
            "target": [
                "É isso que o disfarce de página faz. Em vez de atribuir páginas físicas <emphasis>aleatórias</emphasis> a endereços virtuais, o que pode resultar em desempenho de cache não ideal, o disfarce de página atribui páginas físicas <emphasis>razoavelmente contíguas</emphasis> a endereços virtuais. Assim, os programas podem ser escritos sob a suposição de que as características do cache de hardware subjacente são as mesmas para seu espaço de endereço virtual, como seriam se o programa tivesse sido executado diretamente em um espaço de endereço físico."
            ],
            "id_hash": 4672035647183465942,
            "content_hash": 4672035647183465942,
            "location": "article.translate.xml:885",
            "context": "",
            "note": "(itstool) path: answer/para",
            "flags": "",
            "labels": [],
            "state": 20,
            "fuzzy": false,
            "translated": true,
            "approved": false,
            "position": 107,
            "has_suggestion": false,
            "has_comment": false,
            "has_failing_check": false,
            "num_words": 71,
            "source_unit": "https://translate-dev.freebsd.org/api/units/102146/?format=api",
            "priority": 100,
            "id": 31096,
            "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/pt_BR/?checksum=c0d667aae8552dd6",
            "url": "https://translate-dev.freebsd.org/api/units/31096/?format=api",
            "explanation": "",
            "extra_flags": "",
            "pending": false,
            "timestamp": "2019-10-20T12:20:04.242962Z"
        },
        {
            "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/pt_BR/?format=api",
            "source": [
                "Note that I say <quote>reasonably</quote> contiguous rather than simply <quote>contiguous</quote>. From the point of view of a 128K direct mapped cache, the physical address 0 is the same as the physical address 128K. So two side-by-side pages in your virtual address space may wind up being offset 128K and offset 132K in physical memory, but could also easily be offset 128K and offset 4K in physical memory and still retain the same cache performance characteristics. So page-coloring does <emphasis>not</emphasis> have to assign truly contiguous pages of physical memory to contiguous pages of virtual memory, it just needs to make sure it assigns contiguous pages from the point of view of cache performance and operation."
            ],
            "previous_source": "",
            "target": [
                "Note que eu digo <quote>razoavelmente</quote> contíguo ao invés de simplesmente <quote>contíguo</quote>. Do ponto de vista de um cache mapeado direto de 128K, o endereço físico 0 é o mesmo que o endereço físico 128K. Assim, duas páginas lado a lado em seu espaço de endereço virtual podem acabar sendo compensadas em 128K e compensadas em 132K na memória física, mas também podem ser facilmente compensadas em 128K e compensadas em 4K na memória física e ainda manter as mesmas características de desempenho de cache. Portanto, disfarce de página <emphasis>não </emphasis> tem que atribuir páginas verdadeiramente contíguas de memória física a páginas contíguas de memória virtual, basta certificar-se de atribuir páginas contíguas do ponto de vista do desempenho e da operação do cache."
            ],
            "id_hash": 5337985256232854066,
            "content_hash": 5337985256232854066,
            "location": "article.translate.xml:895",
            "context": "",
            "note": "(itstool) path: answer/para",
            "flags": "",
            "labels": [],
            "state": 20,
            "fuzzy": false,
            "translated": true,
            "approved": false,
            "position": 108,
            "has_suggestion": false,
            "has_comment": false,
            "has_failing_check": false,
            "num_words": 114,
            "source_unit": "https://translate-dev.freebsd.org/api/units/102147/?format=api",
            "priority": 100,
            "id": 31097,
            "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/pt_BR/?checksum=ca14554f06082232",
            "url": "https://translate-dev.freebsd.org/api/units/31097/?format=api",
            "explanation": "",
            "extra_flags": "",
            "pending": false,
            "timestamp": "2019-10-20T12:20:04.252864Z"
        },
        {
            "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/pt_BR/?format=api",
            "source": [
                "Before moving along to the actual design let's spend a little time on the necessity of maintaining and modernizing any long-living codebase. In the programming world, algorithms tend to be more important than code and it is precisely due to BSD's academic roots that a great deal of attention was paid to algorithm design from the beginning. More attention paid to the design generally leads to a clean and flexible codebase that can be fairly easily modified, extended, or replaced over time. While BSD is considered an <quote>old</quote> operating system by some people, those of us who work on it tend to view it more as a <quote>mature</quote> codebase which has various components modified, extended, or replaced with modern code. It has evolved, and FreeBSD is at the bleeding edge no matter how old some of the code might be. This is an important distinction to make and one that is unfortunately lost to many people. The biggest error a programmer can make is to not learn from history, and this is precisely the error that many other modern operating systems have made. <trademark class=\"registered\">Windows NT</trademark> is the best example of this, and the consequences have been dire. Linux also makes this mistake to some degree—enough that we BSD folk can make small jokes about it every once in a while, anyway. Linux's problem is simply one of a lack of experience and history to compare ideas against, a problem that is easily and rapidly being addressed by the Linux community in the same way it has been addressed in the BSD community—by continuous code development. The <trademark class=\"registered\">Windows NT</trademark> folk, on the other hand, repeatedly make the same mistakes solved by <trademark class=\"registered\">UNIX</trademark> decades ago and then spend years fixing them. Over and over again. They have a severe case of <quote>not designed here</quote> and <quote>we are always right because our marketing department says so</quote>. I have little tolerance for anyone who cannot learn from history."
            ],
            "previous_source": "",
            "target": [
                "Antes de avançarmos para o design atual, vamos dedicar um pouco de tempo a necessidade de manter e modernizar qualquer base de código duradoura. No mundo da programação, os algoritmos tendem a ser mais importantes do que o código, e é precisamente devido as raízes acadêmicas do BSD que uma grande atenção foi dada ao design do algoritmo desde o início. Mais atenção ao design geralmente leva a uma base de código limpa e flexível que pode ser facilmente modificada, estendida ou substituída ao longo do tempo. Embora o BSD seja considerado um sistema operacional <quote>antigo</quote> por algumas pessoas, aqueles de nós que trabalham nele tendem a vê-lo mais como uma base de código <quote>madura</quote> que possui vários componentes modificados, estendidos, ou substituído por código moderno. Ele evoluiu e o FreeBSD está no topo, não importa quantos anos tenha o código. Esta é uma distinção importante a ser feita e infelizmente perdida para muitas pessoas. O maior erro que um programador pode cometer é não aprender com a história, e esse é precisamente o erro que muitos outros sistemas operacionais modernos cometeram. <trademark class=\"registered\">Windows NT</trademark> é o melhor exemplo disso, e as conseqüências foram terríveis. O Linux também cometeu esse erro até certo ponto - o suficiente para que nós, do BSD, possamos fazer pequenas piadas sobre isso de vez em quando, entretanto. O problema do Linux é simplesmente a falta de experiência e histórico para comparar idéias, um problema que está sendo resolvido de forma fácil e rápida pela comunidade Linux, da mesma forma como foi abordado na comunidade BSD - pelo desenvolvimento contínuo de código. Por outro lado, o povo do <trademark class=\"registered\">Windows NT</trademark>, repetidamente comete os mesmos erros resolvidos no <trademark class=\"registered\">UNIX</trademark> décadas atrás e depois gasta anos corrigindo-os. De novo e de novo. Eles têm um caso grave de <quote>não foi projetado aqui</quote> e <quote>estamos sempre certos porque nosso departamento de marketing diz que sim</quote>. Tenho pouca tolerância para quem não pode aprender com a história."
            ],
            "id_hash": 3076698109664586470,
            "content_hash": 3076698109664586470,
            "location": "article.translate.xml:70",
            "context": "",
            "note": "(itstool) path: sect1/para",
            "flags": "",
            "labels": [],
            "state": 20,
            "fuzzy": false,
            "translated": true,
            "approved": false,
            "position": 14,
            "has_suggestion": false,
            "has_comment": false,
            "has_failing_check": false,
            "num_words": 327,
            "source_unit": "https://translate-dev.freebsd.org/api/units/157217/?format=api",
            "priority": 100,
            "id": 157218,
            "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/pt_BR/?checksum=aab2a0a133ac6ae6",
            "url": "https://translate-dev.freebsd.org/api/units/157218/?format=api",
            "explanation": "",
            "extra_flags": "",
            "pending": false,
            "timestamp": "2020-04-18T18:14:53.728594Z"
        },
        {
            "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/pt_BR/?format=api",
            "source": [
                "Any codebase that will survive and be maintainable for years must therefore be designed properly from the beginning even if it costs some performance. Twenty years ago people were still arguing that programming in assembly was better than programming in a high-level language because it produced code that was ten times as fast. Today, the fallibility of that argument is obvious — as are the parallels to algorithmic design and code generalization."
            ],
            "previous_source": "",
            "target": [
                "Qualquer base de código que sobreviva e seja sustentável por anos deve, portanto, ser projetada adequadamente desde o início, mesmo que isso custe algum desempenho. Vinte anos atrás, as pessoas ainda argumentavam que programar em assembly era melhor do que programar em uma linguagem de alto nível porque produzia um código que era dez vezes mais rápido. Hoje, a queda desse argumento é óbvia - assim como os paralelos com o design de algorítimo e a generalização de código."
            ],
            "id_hash": -3502117949162657057,
            "content_hash": -3502117949162657057,
            "location": "article.translate.xml:126",
            "context": "",
            "note": "(itstool) path: sect1/para",
            "flags": "",
            "labels": [],
            "state": 20,
            "fuzzy": false,
            "translated": true,
            "approved": false,
            "position": 18,
            "has_suggestion": false,
            "has_comment": false,
            "has_failing_check": false,
            "num_words": 72,
            "source_unit": "https://translate-dev.freebsd.org/api/units/157219/?format=api",
            "priority": 100,
            "id": 157220,
            "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/pt_BR/?checksum=4f65fa47bea3eadf",
            "url": "https://translate-dev.freebsd.org/api/units/157220/?format=api",
            "explanation": "",
            "extra_flags": "",
            "pending": false,
            "timestamp": "2020-04-18T18:14:53.761700Z"
        },
        {
            "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/pt_BR/?format=api",
            "source": [
                "$FreeBSD$"
            ],
            "previous_source": "",
            "target": [
                ""
            ],
            "id_hash": -6157127918850188850,
            "content_hash": -6157127918850188850,
            "location": "article.translate.xml:38, article.translate.xml:40",
            "context": "",
            "note": "(itstool) path: info/pubdate\n(itstool) path: info/releaseinfo",
            "flags": "",
            "labels": [],
            "state": 0,
            "fuzzy": false,
            "translated": false,
            "approved": false,
            "position": 10,
            "has_suggestion": false,
            "has_comment": false,
            "has_failing_check": false,
            "num_words": 1,
            "source_unit": "https://translate-dev.freebsd.org/api/units/229220/?format=api",
            "priority": 100,
            "id": 229224,
            "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/pt_BR/?checksum=2a8d7cc7984b59ce",
            "url": "https://translate-dev.freebsd.org/api/units/229224/?format=api",
            "explanation": "",
            "extra_flags": "",
            "pending": false,
            "timestamp": "2021-01-09T14:33:03.051493Z"
        },
        {
            "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/pt_BR/?format=api",
            "source": [
                "Why do we interleave our swap space instead of just tack swap areas onto the end and do something fancier? It is a whole lot easier to allocate linear swaths of an address space and have the result automatically be interleaved across multiple disks than it is to try to put that sophistication elsewhere."
            ],
            "previous_source": "Why do we interleave our swap space instead of just tack swap areas onto the end and do something fancier? Because it is a whole lot easier to allocate linear swaths of an address space and have the result automatically be interleaved across multiple disks than it is to try to put that sophistication elsewhere.",
            "target": [
                "Por que nós intercalamos nosso espaço de swap em vez de apenas colocar as áreas de swap no final e fazer algo mais sofisticado? Porque é muito mais fácil alocar trechos lineares de um espaço de endereçamento e ter o resultado automaticamente intercalado em vários discos do que tentar colocar esta sofisticação em outro lugar."
            ],
            "id_hash": -5189863536442483307,
            "content_hash": -5189863536442483307,
            "location": "article.translate.xml:662",
            "context": "",
            "note": "(itstool) path: answer/para",
            "flags": "",
            "labels": [],
            "state": 10,
            "fuzzy": true,
            "translated": false,
            "approved": false,
            "position": 81,
            "has_suggestion": false,
            "has_comment": false,
            "has_failing_check": false,
            "num_words": 54,
            "source_unit": "https://translate-dev.freebsd.org/api/units/229221/?format=api",
            "priority": 100,
            "id": 229225,
            "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/pt_BR/?checksum=37f9e69c5597dd95",
            "url": "https://translate-dev.freebsd.org/api/units/229225/?format=api",
            "explanation": "",
            "extra_flags": "",
            "pending": false,
            "timestamp": "2021-01-09T14:33:03.178503Z"
        }
    ]
}