Skip to content

Conversation

@cedricr
Copy link
Collaborator

@cedricr cedricr commented Nov 20, 2025

🔧 Problem

Fixes #1532

See also: MTES-MCT/ecobalyse-data#179

Copy link
Member

@n1k0 n1k0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are just preliminary remarks with the geoZone name, which could just be geozone and solves a lot of headaches wrt naming conventions across codebases. worldRegion could also be just region imho, but I won't die on this other hill. More broadly, even if I understand we can't use a same single concept and type for "any scale geographic location", I fear the two names — geo zone and world region — might be quite confusing to end-users and documentation readers… though I don't have much better suggestions to offer. What would prevent us to use a single concept and type? (I'm asking the question because I didn't spend the necessary time to investigate the matter yet am offering others to chime in, and I'm definitely part of the ones who should be involved answering that question)


// Redirects: API
api.get(/^\/countries$/, (_, res) => res.redirect("textile/countries"));
api.get(/^\/geo-zones$/, (_, res) => res.redirect("textile/geo-zones"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same, I could live with just geozones just totally fine.

@cedricr
Copy link
Collaborator Author

cedricr commented Nov 24, 2025

These are just preliminary remarks with the geoZone name, which could just be geozone and solves a lot of headaches wrt naming conventions across codebases. worldRegion could also be just region imho, but I won't die on this other hill. More broadly, even if I understand we can't use a same single concept and type for the concept of "geographic location information", I fear the two names — geo zone and world region — might be quite confusing to end-users and documentation readers… though I don't have much better suggestions to offer. What would prevent us to use a single concept and type? (I'm asking the question because I didn't spend the necessary time to investigate the matter yet am offering others to chime in, and I'm definitely part of the ones who should be involved answering that question)

@n1k0 I’m even wondering if the 'geo' part is necessary after all… Couldn’t we go with just zone? @paulboosz what do you think ?

About worldRegions (previously named zones 😅). I’m afraid just “regions” would be more confusing, as you have administrative regions, of different levels, geopolitical regions, etc. I think “world region” has the advantage of evoking something “big” at least.
We could try something like "SuperZone", or “MetaZone” to be super clear that’s it a division above the Zone, but I’m not a big fan of the hyberbole.

That won’t be the end of the road, in the codebase, we also have “locations”, with their own semantic, coming from Brightway, “geographicOrigin”, with its own classification, “defaultOrigin”, with another classification, and probably others ? Baby steps… 😆

@cedricr cedricr force-pushed the chore/1532-rename-countries branch from c3fbdab to 446627d Compare November 24, 2025 16:00
@cedricr cedricr marked this pull request as ready for review November 25, 2025 13:01
@cedricr cedricr requested a review from n1k0 November 25, 2025 13:02
@cedricr cedricr marked this pull request as draft December 1, 2025 09:33
@cedricr cedricr force-pushed the chore/1532-rename-countries branch from 223e1ac to e4eade1 Compare December 1, 2025 11:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Renommer le fichier countries.json en 'location' ?

3 participants