Demônstrativos em inglês: como não se perder mais
O pessoal que tá começando a estudar inglês sempre trava nos mesmos quatro palavras. This, these, that, those. Parece fácil até você abrir um livro e ver a tabela: singular/plural, perto/longe. Aí chega na hora de usar e começa a bagunça. Eu já vi desenvolvedor com oito anos de experiência errar that/these num email pra cliente americano. Acho que o problema não é dificuldade real. É que a gente aprendeu de um jeito que não reflete como as pessoas realmente falam. Vamos colocar isso em prática de verdade.
this these that those na prática
Em vez de decorar tabelas, tenta entender o padrão: you point at something and say this or that, and it stays singular; you point at more than one thing and it becomes these or those. The physical gesture matters more than you think. When I was writing documentation for a tech product last year, my editor kept changing this to that because the team was referring to something mentioned earlier in the conversation, not something right in front of them. Took me a while to catch on. This is used for singular items close to you. Not necessarily physically close. Close in the conversation, in time, in importance. "I want to talk about this topic." You're bringing it up now. These is the plural version. "These are the files we discussed." Plural, relevant, present.
That is singular but farther away. Could be physical distance. Could be temporal distance. "That project we finished last month." Already done. Those is plural and distant. "Those problems we had with the old server." Past, resolved, out of sight. The nuance nobody explains well is that this/these can refer to something abstract and upcoming, not just physical objects near you. That/those can refer to something abstract but distant, not necessarily far away in space. I learned this the hard way when writing API documentation. My first draft said "configure these endpoints" when the reader had to navigate to a different page to find them. Switched to "those endpoints" and the sentence made more sense contextually.
Another thing most courses skip: demonstratives can point at ideas, not just things. "I don't like this attitude." You're talking about someone's behavior, not a physical object. "Remember those days we stayed up all night debugging?" Both examples use demonstratives correctly without any physical reference. The mental proximity does the work. Counterintuitive but useful: you can use that to introduce a clause that summarizes everything you just said. "She didn't show up, missed the deadline, and blamed the team — and that is exactly why we're restructuring." That isn't pointing at a single noun. It's pointing at the whole situation. Native speakers do this constantly. Learners rarely pick it up from textbooks.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Pitfall number one: mixing up these and those when the items are mentally close but physically scattered. I had this issue organizing a presentation for stakeholders. I said "these issues" about problems spread across three different teams. The audience pictured three separate piles instead of one interconnected problem set. Switched to "those issues" and suddenly the systemic nature came through clearly. Sometimes distance in language actually helps clarity. The limitation nobody warns about: demonstratives become ambiguous in writing when the reference isn't crystal clear. "Send me that report" could mean three different documents depending on context. In spoken English, gesture and tone disambiguate instantly. In emails and documentation, you need to be more specific. I started adding the actual filename after demonstratives in technical writing. "Send me that report (Q3-performance-metrics.xlsx)." Two seconds to add, saves five minutes of back-and-forth.
Advanced usage: this can refer to what's coming next in your own speech. "Here is the plan: this includes budget, timeline, and resources." Pointing forward, not backward. That can refer to what someone else just said, sometimes with a hint of distance or doubt. "You want to ship on Friday? That won't work." The demonstrative carries attitude, not just distance. When writing technical content in English, I recommend using this/these when introducing something you're about to explain, and that/those when referring back to something already covered or external. It creates a natural temporal flow that readers subconsciously follow. The pattern isn't arbitrary. It mirrors how attention actually works in conversation.
One edge case that trips everyone up: relative clauses with that versus which. "The server that crashed is back online." Restrictive clause, essential information, no comma. "The server, which crashed, is back online." Non-restrictive, extra detail, comma required. I still see this wrong in production code comments from senior engineers. The rule is simple but consistently ignored in practice. Bottom line without making a big deal about it: this/these/those point at what's present, immediate, or upcoming in your discourse. That points at what's absent, past, or external. The spatial metaphor does heavy lifting here. Your brain is already tracking proximity. You just need to notice what it's doing and align your language with it.
If you want to practice without sounding robotic, try reading technical documentation aloud and replacing every demonstrative with its opposite. You'll immediately feel which one sounds wrong. That discomfort is your intuition telling you something about proximity that grammar rules never explained to you. Listen to it. I use a simple rule now: before writing any technical document, I underline every this, these, that, and those, then ask whether the reference is near or far in the reader's mental model. If I can't answer quickly, I rephrase. Takes extra minutes upfront, prevents confusion downstream. The method scales from blog posts to API specs without modification.
Search engines don't care about your demonstrative choices. Readers do. Writing clearly about this these that those means understanding that clarity comes from tracking the reader's attention, not from following textbook rules. The rules exist because they describe patterns. Patterns exist because human attention works in predictable ways. Understand the mechanism and the usage follows naturally. One final observation that might save you time: in formal business writing, some style guides recommend minimizing demonstratives because they can be vague. Replace "that feature" with the actual feature name. Replace "these issues" with a numbered list. The tradeoff is specificity versus flow. I tend to keep demonstratives in internal documentation and strip them from external-facing material. The distinction isn't rigid, but having one prevents you from second-guessing every choice.