Sarah Hoffmann

Looks good as a first version. We can fine-tune in follow-up PRs, if necessary.

Oh dear, now I forgot about documentation. Do you mind adding a little bit of documentation for the new call in a separate PR? I would suggest to do this...

I'm seeing the same issue [here](https://github.com/osm-search/Nominatim/blob/master/src/nominatim_api/server/starlette/server.py#L82) in the Nominatim project after updating to starlette 0.47. Example of failing CI: [here](https://github.com/osm-search/Nominatim/actions/runs/15328721671/job/43130915460). The problem appears when creating a custom middleware with initialisation...

Another data point here: this only shows up after updating to mypy 1.16.0. So, either downgrading to mypy 1.15.0 or to starlette 0.46.2 makes the issue go away.

Reported error: ``` Jun 11 12:54:22 nom3 nominatim-updates.sh[160393]: org.opensearch.transport.RemoteTransportException: [Node 1][127.0.0.1:9300][internal:cluster/coordination/join] Jun 11 12:54:22 nom3 nominatim-updates.sh[160393]: Caused by: org.opensearch.cluster.coordination.CoordinationStateRejectedException: incoming term 1 does not match current term 2 Jun 11...

I have now cleaned out the directories, so that the *latest* dumps should once again point to valid dumps. Still investigating the root cause. Might be an issue with the...

It looks like the latest export went through without issues. Suspiciously smells like I race condition we have hit because of the heavy load on the server. I'll leave this...

Writing this off as a one-time glitch.

I fear we are running into the limitations of using a one-size-fits all tokenizer here. There is #563 for Japanese.

If only the tag name was `lock:name`, then it could be easily handled in the same way as `bridge:name` but it looks like the tag vastly predates the introduction of...