faker
faker copied to clipboard
Add faker.location.neighborhood() helper for Brazilian “bairro”
Clear and concise description of the problem
Currently, FakerJS doesn’t include a built-in way to generate Brazilian “bairros” (neighborhoods), so some people have been using faker.location.county() as a workaround. Since “counties” usually refer to larger regions (e.g. in the US or UK), the results don’t always match the smaller, city-level nature of a Brazilian bairro.
As a developer working with the pt_BR locale in FakerJS, I’d love to see a dedicated faker.location.neighborhood() (or bairro()) method so that my generated addresses feel more authentic and align with local conventions.
Suggested solution
Add a new neighborhood() method in the location module that:
- Selects a prefix from a dedicated array
// neighborhood_prefix.ts export default [ 'Bairro', 'Vila', 'Jardim', 'Residencial', 'Chácara', ]; - Proxies the “name” portion to the existing person generator—just like
street()orcity()use other modules—to get a plausible, randomized core name:// neighborhood_pattern.ts export default [ '{{location.neighborhood_prefix}}{{person.firstName}}', '{{location.neighborhood_prefix}}{{person.last_name.generic}}', ];
Alternative
Overload faker.location.county() to return Brazilian bairros in pt_BR only, but this is semantically confusing for users.
Additional context
No response
Thank you for your feature proposal.
We marked it as "waiting for user interest" for now to gather some feedback from our community:
- If you would like to see this feature be implemented, please react to the description with an up-vote (:+1:).
- If you have a suggestion or want to point out some special cases that need to be considered, please leave a comment, so we are aware about them.
We would also like to hear about other community members' use cases for the feature to give us a better understanding of their potential implicit or explicit requirements.
We will start the implementation based on:
- the number of votes ( :+1: ) and comments
- the relevance for the ecosystem
- availability of alternatives and workarounds
- and the complexity of the requested feature
We do this because:
- There are plenty of languages/countries out there and we would like to ensure that every method can cover all or almost all of them.
- Every feature we add to faker has "costs" associated to it:
- initial costs: design, implementation, reviews, documentation
- running costs: awareness of the feature itself, more complex module structure, increased bundle size, more work during refactors
Generally I think this is a good idea.
Obviously the way that different countries divide up their territory, and write addresses, varies significantly across the world.
https://en.wikipedia.org/wiki/List_of_terms_for_administrative_divisions
In general we have state() for a 1st-level subdivision of the country, and county() for the 2nd-level subdivision, and we understand that the actual name of the subdivision type may not actually be "state" or "county".
For some locales this is not enough, especially in big cities where a city is divided into multiple neighbourhoods or districts, e.g. the boroughs of New York or London, districts (Bezirk) of Berlin, wards (ku) of Tokyo, arrondissements of Paris, Bairros of Rio, or barrios of Madrid.
faker.location.neighborhood() is OK as a name, though i have a couple of concerns
- there's ambiguous spelling (would be neighbourhood in British English)
- sometimes 'neighborhoods' can be more informal (e.g. "Upper East Side" or "DUMBO" is a neighborhood of New York, whereas "Manhattan" is a formal borough)
I would probably go for a generic method name that implies clearly it is intended to be the subdivision of a city, like faker.location.cityDistrict()
Faker-Ruby appears to use "community" for something similar https://github.com/faker-ruby/faker/blob/main/doc/default/address.md
In general we have
state()for a 1st-level subdivision of the country, andcounty()for the 2nd-level subdivision, and we understand that the actual name of the subdivision type may not actually be "state" or "county".[...]]
faker.location.neighborhood()is OK as a name, though i have a couple of concerns
- there's ambiguous spelling (would be neighbourhood in British English)
- sometimes 'neighborhoods' can be more informal (e.g. "Upper East Side" or "DUMBO" is a neighborhood of New York, whereas "Manhattan" is a formal borough)
I would probably go for a generic method name that implies clearly it is intended to be the subdivision of a city, like
faker.location.cityDistrict()
That is a good suggestion to keep in mind. I wouldn't mind thinking about a 3rd-level administrative division. We should look into the general coverage of our biggest locales for this feature. If too many locales do not have the concept of a 3rd division, I do not see this bein included in the our core library. Although, I don't think that will be the case.
Also, the features naming must be in line with the current naming scheme, otherwise they might become too disconnected.
Generally I think this is a good idea.
Obviously the way that different countries divide up their territory, and write addresses, varies significantly across the world.
https://en.wikipedia.org/wiki/List_of_terms_for_administrative_divisions
In general we have
state()for a 1st-level subdivision of the country, andcounty()for the 2nd-level subdivision, and we understand that the actual name of the subdivision type may not actually be "state" or "county".For some locales this is not enough, especially in big cities where a city is divided into multiple neighbourhoods or districts, e.g. the boroughs of New York or London, districts (Bezirk) of Berlin, wards (ku) of Tokyo, arrondissements of Paris, Bairros of Rio, or barrios of Madrid.
faker.location.neighborhood()is OK as a name, though i have a couple of concerns
- there's ambiguous spelling (would be neighbourhood in British English)
- sometimes 'neighborhoods' can be more informal (e.g. "Upper East Side" or "DUMBO" is a neighborhood of New York, whereas "Manhattan" is a formal borough)
I would probably go for a generic method name that implies clearly it is intended to be the subdivision of a city, like
faker.location.cityDistrict()
I think this is a good approach for it, here in Australia we have states, cities within those states and suburbs within those cities.
I think the idea of using faker.location.cityDistrict() makes a lot of sense as well and would suggest that locale plays an effect on the naming to make it more sensible language dependent.