Leitura de textos técnicos em inglês

Do zero

Ler documentação técnica em inglês não exige entender cada palavra. É como entrar num supermercado estrangeiro: você não lê todos os rótulos, procura a seção certa e reconhece os produtos pela embalagem. Três hábitos resolvem a maior parte:

• Saber o que se procura antes de ler. A ideia geral do texto? Uma informação específica (um valor, uma data, um código de erro)?
• Apoiar-se no que já se conhece. Muitas palavras técnicas são parecidas com o português (cognatos: server, database, configuration) ou já são usadas no dia a dia da TI (deploy, bug, log).
• Desconfiar dos “falsos amigos”. Algumas palavras parecem portuguesas e significam outra coisa: eventually é “por fim”, não “eventualmente”; actually é “na verdade”, não “atualmente”.

As duas estratégias que o edital cita têm nome:

• Skimming (passar os olhos): ler o título, os subtítulos, a primeira frase de cada parágrafo e a conclusão para pegar a ideia principal.
• Scanning (varrer): correr os olhos atrás de uma informação específica, como quem procura um nome numa lista, sem ler o resto.

Frase para guardar: skimming para a ideia geral, scanning para o detalhe; cognatos ajudam, falsos cognatos enganam; conectivos mostram a lógica do texto.

Em 1 minuto

• Estrutura da documentação: overview (visão geral), getting started ou quickstart (primeiros passos), reference (referência detalhada), examples, FAQ, changelog ou release notes (o que mudou em cada versão).
• Documentação de API: endpoint, method (GET, POST), path parameter e query parameter, request body, response, status code, required e optional, default (valor padrão), rate limit (limite de chamadas), authentication e scope (permissão).
• Palavras que mudam tudo: deprecated (obsoleto, ainda funciona mas será removido), breaking change (mudança que quebra quem usa), backward compatible (compatível com o antigo), legacy (legado), beta e experimental.
• Palavras de obrigação nas especificações: MUST (obrigatório), MUST NOT (proibido), SHOULD (recomendado; pode haver motivo válido para não seguir), MAY (opcional). A especificação do MCP, por exemplo, declara que usa essas palavras no sentido do BCP 14 (RFC 2119 e RFC 8174) quando aparecem em maiúsculas (fontes/mcp-spec-2026-07-28/mcp-spec-2026-07-28.md) [CONFERIR: o texto das RFCs ainda não está em fontes/].
• Referência pronominal: it, its, they, this, which retomam algo já dito. Volte à frase anterior e teste a troca: em The server rejects the token because it has expired, it = the token.
• Vocabulário de operação: release (versão publicada), rollback (voltar à versão anterior), throughput (vazão: operações por segundo), uptime (tempo no ar).
• Conectivos: however, although, whereas (contraste); therefore, thus, hence (conclusão); because, since, due to (causa); moreover, furthermore, in addition (adição); unless (a menos que); otherwise (caso contrário).
• Grupos nominais: em inglês, quem qualifica vem antes. Leia de trás para frente: database connection timeout = tempo limite da conexão com o banco de dados.

Exemplo concreto: lendo uma página de API

Um sistema do Tribunal vai consumir a API de contratos de outro órgão. A documentação diz:

GET /v2/contracts/{id}

Returns a single contract by its ID. Requires an API key with the contracts:read scope.

Path parameters
  id (string, required)       The contract identifier.

Query parameters
  include (string, optional)  Comma-separated list of related resources to embed.
                              Default: none.

Responses
  200 OK                 The contract was found.
  404 Not Found          No contract matches the given ID.
  429 Too Many Requests  Rate limit exceeded. Retry after the number of seconds
                         given in the Retry-After header.

Note: The v1 endpoint is deprecated and will be removed on March 31, 2027.
Clients SHOULD migrate to v2 as soon as possible.

Skimming (o que é isto?): uma rota que devolve um contrato pelo identificador, com versão nova (v2) e aviso sobre a antiga.

Scanning (perguntas específicas):

• Que permissão é preciso ter? A chave de API com o escopo contracts:read.
• O parâmetro include é obrigatório? Não: optional, e o padrão (default) é nenhum.
• O que fazer ao receber 429? Esperar o número de segundos do cabeçalho Retry-After e tentar de novo.
• E a v1? Está deprecated: ainda funciona, mas será removida em 31 de março de 2027, e os clientes SHOULD (devem, como recomendação forte) migrar para a v2.

Repare que, para responder, não foi preciso traduzir o texto inteiro: bastou saber o que se procurava e reconhecer as palavras-chave.

Comparação: estratégias, falsos cognatos e conectivos

Como a FCC cobra

• Trechos de documentação de software e de APIs.
• Vocabulário técnico de TI (deprecated, release, deploy, rollback, throughput).
• Palavras de obrigação (must, should, may).
• Grupos nominais e a ordem das palavras.

Pegadinhas

Explique com suas palavras

Explique a um colega como ler a página de documentação da API de contratos sem traduzir tudo, usando skimming e scanning, e o que significam “deprecated” e “SHOULD” naquele aviso.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

Primeiro eu passo os olhos pelo título e pelas seções para entender do que se trata: é uma rota que devolve um contrato pelo número. Isso é o skimming. Depois, para cada dúvida, procuro só a palavra que interessa: para saber se o parâmetro é obrigatório, procuro “required” ou “optional”; para saber o que fazer quando passar do limite, procuro o código 429. Isso é o scanning.

“Deprecated” quer dizer que a versão antiga ainda funciona, mas está com os dias contados: tem data para ser removida. “SHOULD” é uma recomendação forte: o certo é migrar, e só um bom motivo justificaria não fazer isso. Se estivesse escrito “MUST”, seria obrigatório.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

O estudo de caso pode trazer um trecho de documentação em inglês, de uma API, de uma ferramenta ou de uma norma técnica. Leia com objetivo: localize o que a pergunta pede (escopo de acesso, limites, prazos de descontinuação, requisitos MUST e SHOULD) e use isso na resposta, em português, dizendo o que o trecho exige e o que recomenda.

Fontes da lição

• Edital nº 01/2026, Anexo II, Língua Inglesa (Leitura Técnica) (fontes/edital-01-2026.txt).
• Especificação do Model Context Protocol, 28/07/2026, seção de convenções (uso de MUST, SHOULD e MAY conforme o BCP 14) (fontes/mcp-spec-2026-07-28/mcp-spec-2026-07-28.md).
• RFC 2119 e RFC 8174 (sentido de MUST, SHOULD e MAY) [CONFERIR: os textos ainda não estão em fontes/].
• MDN Web Docs: códigos de status HTTP.