Home / Recipes / Follow a topic in a specific language only
Worked queryFollow a topic in a specific language only
/stories in semantic mode. The parameters matter less
than the reasoning behind them, so that is most of what is below.
The request
GET /stories
?q=<topic, in English>
&mode=semantic
&language=deu
&from=<now - 7d>Why these parameters
Query in English and let semantic matching bridge to the target language. This is the pattern behind most cross-lingual monitoring: you do not need to compose the query in a language you do not read, only to constrain the results to it.
The obvious approach, and why it loses
The obvious approach is to translate the query into the target language first, usually with a model, and then run it as keywords. It sounds more rigorous and is generally worse. Machine translation of a short query has no context to disambiguate with, so it picks one sense of each term and commits to it, and the failure is invisible because the result set looks like a result set. Semantic matching skips the intermediate step: the query and the documents are compared directly, so nothing has to be committed to a single word choice. Where the query is a named entity rather than a concept, the reverse holds and the translated or transliterated form is worth adding explicitly.
When it returns too much, or too little
Too much usually means the concept is broad enough that its nearest neighbours in the target language are adjacent subjects rather than the same one. Add a second concept to the query to constrain the neighbourhood rather than adding a keyword, which reintroduces the problem the recipe exists to avoid. Too little is often a language-size problem rather than a query problem: a language with a few dozen indexed outlets simply yields less, and the honest response is to widen the window rather than to loosen the terms until unrelated material appears. Check the language page for the outlet count before deciding whether a thin result set is your query or the corpus.
How you would know it is working
Get twenty results read by someone who reads the language, and ask a single question about each: is this about what I asked for. You are measuring the bridge, not the ranking, so a precision figure is enough and you do not need them to rank anything. Repeat it when you change subjects, because the quality of cross-lingual matching varies more by topic than by language — concrete, technical subjects bridge well and culturally specific ones bridge poorly. If nobody on the team reads the language, a competent translation service reviewing twenty headlines once a quarter is a small cost against the risk of quietly monitoring the wrong thing.
When this is the wrong tool
Semantic bridging across languages is good, not perfect, and its quality varies by language pair and by how technical the subject is. A query composed in English about a concept with no clean equivalent in the target language will return approximately the right neighbourhood rather than exactly the right set, and you will not be able to tell from the results which you got. Where precision matters more than convenience, have the query composed by someone who reads the language. This recipe is a way to reach coverage you otherwise could not read at all; it is not equivalent to querying natively.
Running it for real
Response fields, failure modes, adaptations and scheduling cost: Follow a topic in a specific language only, in the docs.