Content language

Created on 5 December 2023, about 1 year ago
Updated 8 December 2023, about 1 year ago

Problem/Motivation

The local set on the persistent geocoder is either detected from the Interface Language, or (now since https://git.drupalcode.org/project/geocoder/-/commit/85736b5989c2bf66dd5... ) by a fixed language. Populating an address field on content can be done on the Entity Content Language rather than the interface language.

Steps to reproduce

Gecode with the interface language Italian but apply to an entity with the lang code German.

Proposed resolution

I've not looked at the addressfield geocoder yet. But for my use case, where we are triggering the geocoding in an ajax callback that has the entity langcode adding the a method to access geocodeQuery and passing the responsibility to the caller to create the Geocoder\Query\GeocodeQuery to pass into it. This could probably best be done by adding an interface that the base Geocode-PHP provider implements (with geocodeQuery and reverseQuery passing the GeocodeQuery object through).

Remaining tasks

Add interface and add to the base.

Investigate if this can also be useful for the addressfield->geofield submodule.

API changes

Adds two additional methods. The API and the standard existing geocode and reverse methods remain the same.

Feature request
Status

Active

Version

4.0

Component

Code

Created by

🇳🇱Netherlands ekes

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @ekes
  • 🇮🇹Italy itamair

    Thanks, ... but let's mark also this one as Feature request, as I don't really see any Bug yet, around all this.

    Feel free (and really welcome) to provide (or just outline) your Featured solution to improve and accomplish what you describe.

  • 🇳🇱Netherlands ekes

    I'm thinking that Pass additional parameters to geocoders Needs review will probably fix this one for me. By being able to pass a Query it can have ::setLocal() added to it per query where the local used will be the language of the entity (rather than the interface language). So my German entity (or translation) can get 'Florenz' and my English one can get 'Florence' :)

Production build 0.71.5 2024