Replies: 49 comments 21 replies
-
|
I think @fzaninotto is right saying the package is way to heavy, and should be splitted, with an extract of the languages.
With this organisation it could be easier to maintain separatly locale providers. |
Beta Was this translation helpful? Give feedback.
-
|
Do we want to split Faker and its locales into different repositories, or do we want to keep a single repo and split it into different Composer packages (like Monorepo:
Multirepo:
|
Beta Was this translation helpful? Give feedback.
-
|
I think Laravel and Symfony are successful examples of such monorepos, using read-only repos for splitting/releasing (no "issues" there, for example). I think a single repo for just for the issues is already better than having it spread and worst-case having issues in wrong repos. I'm 👍 mono-repo if the split happens, because I figure you want to run the test suite also with all of them and that's why certain things are "just easier" and there's only the one-time complexity of setting everything up and making it work (with scripts). |
Beta Was this translation helpful? Give feedback.
-
|
I also believe that the Monorepo is the best approach for this project, just like Laravel does. |
Beta Was this translation helpful? Give feedback.
-
|
Maintainers, do we want to use a democratic system (using something like https://github.com/apex/gh-polls) to make the decisions here? |
Beta Was this translation helpful? Give feedback.
-
|
In my opinion, shared issues and pull request are here an inconvenient, instead of an advantage. We're not talking about splitting a framework in different packages but having N independent locales which should evolve differently (respecting common interfaces, of course). One of the pain point François raised is maintaining those locales, while not understanding the language. With several repos, we can have different repo maintainers who are responsible for their own locale. It will so be easier to maintain the whole thing. And it'll also be easier to find maintainers: if I have no time and no envy to maintain faker, I'm totally OK with handling the French locale, because smaller project, less and clearer notifications, and less responsibility. Thoughts? PS: I'm generally a monorepo guy, but I think that the Faker context is a enough special to handle it differently. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @mathieutu. It makes more sense to create differents repositories with differents mainteners. It's like in the translation business, you can only translate into your native language. It is not possible to manage languages that you can't understand. A repository locale list on this repository would be consistent. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, some opinions from random onlooker who also recently went through the monorepo versus manyrepo debate. So, I recently restructured Pagerfanta to support installing different optional elements as separate packages (akin to So, if I were a maintainer here, what I would personally do to start off is go with the monorepo approach while keeping all of the locales within this repo and supporting a subsplit, then if I found it to be too busy supporting those in one repo, in theory it should not take too much effort to turn the split locale repo into the point of truth and drop that portion of the code from the main repository. |
Beta Was this translation helpful? Give feedback.
-
Actually, in the faker context, we do have years of experience and feedbacks on it:
|
Beta Was this translation helpful? Give feedback.
-
|
Right, but wasn't the original repo predominantly a single person overseeing things? There's a team here, so presumably one could use the code owners feature of GitHub to request reviews from team members who are "language specialists" (for lack of better terms) instead of expecting an English speaker to review all non-English changes. It wouldn't be much different than having those same team members review and merge pull requests to other repos other than the amount of traffic/noise on a single repository. |
Beta Was this translation helpful? Give feedback.
-
|
Im a fan to keep things seperate as much as possible. Where a mono repo is really cool but that is not the only thing. We always talk about Locale and stuff like that but Faker also holds so called Providers. Technically it is the same thing but the providers hold non language specific things. For example there is an eCommerce provider as a suggestion. This provider will probably never make it to the Faker core but it should be easy to be pluggable. I think if we provider proper interfaces for the locales we can ensure that the quality of those locales are good and that they hold all the required data. |
Beta Was this translation helpful? Give feedback.
-
|
This is an interesting discussion. I am a big fan of mono repos. I would say mono repo 7 days every week. However @mathieutu makes a really good point. Since we have localized providers, we have a really hard time figuring out what is a good PR or not. I dont believe any of you could properly verify this PR to add Swedish municipalities. I vote for doing separated repositories. I also think that if someone contributes we should make them a maintainer to that repository. Let's aim for at least 2-3 maintainers per locale. |
Beta Was this translation helpful? Give feedback.
-
|
I already started splitting up faker into faker-core, and one repository for each locale, also planned to add some more for ORM etc. Like nyholm said, I also strongly believe that separate repositories are necessary to maintain language specific providers. |
Beta Was this translation helpful? Give feedback.
-
I think it is important first to discuss on what to take into the core and define the interfaces on what we think is best. Same goes for the interface on the outside so that we can keep an easy migration plan available. Graham already mentioned it earlier which i believe was totally right, that we need to use 2020 to ensure people migrate to the new repository and continue to support it. If we start breaking all stuff people will probably not move. Where also the old repo is still there and working fine for those |
Beta Was this translation helpful? Give feedback.
-
|
Small Isolated and localized packages would be the best Fit, The core Faker Framework should stand alone as a package Maintained by the core team. Core Team should give visibility to well crafted localized packages. |
Beta Was this translation helpful? Give feedback.
-
|
Please, split this up into a repo for each provider and assign a maintainer to own it. |
Beta Was this translation helpful? Give feedback.
-
|
That's the plan! |
Beta Was this translation helpful? Give feedback.
-
This is an option but also grouping it for certain languages. For instance. Nl_NL etc |
Beta Was this translation helpful? Give feedback.
-
|
Hey. |
Beta Was this translation helpful? Give feedback.
-
|
Everyone working on new features, can you take a look as well? Perhaps it makes sense for you to hold off your work for a bit! /cc @GlennM |
Beta Was this translation helpful? Give feedback.
-
|
I'll start working with these changes the next few weeks. Please share your opinions, good or bad. |
Beta Was this translation helpful? Give feedback.
-
|
Quick heads-up, I have enabled discussions and converted this issue into a discussion. I hope that makes sense for everyone involved! |
Beta Was this translation helpful? Give feedback.
-
|
I have not enough experience in structuring big projects - I am just a user. I am German - so most likely would use de_DE and likely en_US as eg. in WordPress English is the source language even if my site ends up being German only. I see that de_AT and de_DE will share a lot of similarities as both use German. Then Germany is part of the EU. I imagine things like that will exist in a couple of locals -> sharing strong similarities with some, but be different in plenty. Eg. de_AT extends some German generators: If they are in separate packages the AT local would need to require the DE local - but what if the DE local extends another local - maybe an EU local or the EN local. As a user I am pro lightweight but also pro simple. Nice would be to require
And all the rest is not mine to figure out. If I miss the point of the discussion, be welcome to ignore my question. |
Beta Was this translation helpful? Give feedback.
-
|
This is a really good point. There could be a repo for a generic Then the |
Beta Was this translation helpful? Give feedback.
-
|
Not sure if the same ist true for eg. Spanish and Portogues. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe the currency thing should be part of the main package and only the things which differ is in separate packages |
Beta Was this translation helpful? Give feedback.
-
|
Currency stuff could be a trait that's used by the necessary locales. So, for example, there could be a Then, |
Beta Was this translation helpful? Give feedback.
-
|
What about... voting? :D
|
Beta Was this translation helpful? Give feedback.
-
|
Although I voted for multi-repo, the monorepo is obviously the short term valid option until there is enough contributors to avoid premature death. Also I've been thinking about the data generators for over a year, fakers text and image generation needs to be completely rethought. In english, it's fairly easy to generate valid or near valid english words with a small morpheme library. With images it's better to generate dummy placeholders than connect to some external service. |
Beta Was this translation helpful? Give feedback.
-
|
English language support please! |
Beta Was this translation helpful? Give feedback.
-
|
Isnt that a default haha |
Beta Was this translation helpful? Give feedback.
-
|
I'm curious about the current status of this, are there any updates? |
Beta Was this translation helpful? Give feedback.
-
|
THIS need update. The main reasons of creator to stop faker (https://marmelab.com/blog/2020/10/21/sunsetting-faker.html) are still relevant, and more relevant now in 2022. This should be discussed please. |
Beta Was this translation helpful? Give feedback.
-
|
Very nice. There is a doc on "how to contribute" or the best way to regroup locales by languages ? I saw |
Beta Was this translation helpful? Give feedback.
-
|
FakerPHP/Dutch is indeed a reference implementation of the new extension system, for now. Nothing is fully set in stone yet. |
Beta Was this translation helpful? Give feedback.
-
The first step is to migrate all existing providers to Extensions. This is for all stuff that will stay in the Faker Core package. After that we will adapt the en_US implementation in the core and remove all the rest. I guess at that point we will release a first release candidate where others can implement a language extension and such. For example at this point Faker generates images use an external website. This will be removed but i assume it would be good to build an extension that depends on GD and generates it locally |
Beta Was this translation helpful? Give feedback.
-
I know it's still early, but when the time for separating each language into individual package comes, we could make a |
Beta Was this translation helpful? Give feedback.
-
This is indeed the plan. We now at a state where an initial reference implementation is done. At this point we are publishing the interfaces and new generators. The current fakerphp/faker will contain the english language pack so upgrades will be easy |
Beta Was this translation helpful? Give feedback.
-
|
Almost one year after the latest commits to the 2.x branch and the Dutch repo, I'm wondering about the progress for Faker 2.0. |
Beta Was this translation helpful? Give feedback.
-
|
The Poc for the dutch repo is finished but we need to finetune some stuff on the core repo and interfaces |
Beta Was this translation helpful? Give feedback.
-
|
Some info on the status. We had a solid meeting this evening concerning the 2.x progress and points left to do. We identified most of the leftover interfaces and we are now in the progress of implementing those for
After all this we will start working on the language packs so we can have them ready when 2.x will release it first beta. The ones that are planned for now would be:
We will ask if we are ready so that people can implement their own. We will add a boilerplate repo for people to start with to make implementations easy |
Beta Was this translation helpful? Give feedback.
-
|
Hello, |
Beta Was this translation helpful? Give feedback.
-
|
As far as I can see, we are in the uncomfortable situation where
That is, it seems to me like we are in a situation where we are somewhat unable to move forward - some people call this death by committee. |
Beta Was this translation helpful? Give feedback.
-
|
Can you explain the disagreement regarding support of PHP versions ? |
Beta Was this translation helpful? Give feedback.
-
|
PHP 8.3 support is indeed an important issue I see there are PRs for it but not sure to understand what's blocking progress ? If we consider the design topic, IIIC probably the most important aspect of 2.0, is the new implementation with Core (en_US as default) and languages as independant packages functional ? |
Beta Was this translation helpful? Give feedback.
-
Consider better locale supportI've been working on a multilingual app and found several shortcomings when trying to generate multilingual dummy data. In my case, I'd like to seed a customers table with companies in different countries, and I'd also like to make sure that the company names and addresses are native to the customer country. For example, if I create a customer in Finland, it doesn't make sense if the company name is However, this is currently painful with Faker because of several reasons. Cannot change locales on the flyIt's not possible to change the locale of the faker instance on the fly. Sure, I could create a new instance for each customer, but this isn't so easy when working with for example Laravel's model factories. It would be nice if we could just change the locale like this: // load the locale data and set the current locale on the generator instance
$generator->setLocale('fi_FI');Non-compatible provider implementations in different localesDifferent locales have different and often incomplete (and thus, non-compatible) implementations of providers. This means I cannot just assume that the I understand that "state" and "county" are somewhat different concepts, but we all understand that they are basically the same. At the minimum, these methods should be aliased to each other. I think it would be best if Faker enforced contracts/interfaces for the providers to ensure a uniform API. No way to know which locale is loadedThere is no 'current locale' on the Can we perhaps have something like this: $generator->getLocale(); // will return `fi_FI`, for example |
Beta Was this translation helpful? Give feedback.
-
|
Well you should create an instance for each locale. This makes sense as-well considering the unique features which are odd over locales. Concerning the state vs country, there is a base interface and mapping that all providers have. For the v2 implementation this is also available. However there will always be locale adapter specifics which is also fine. |
Beta Was this translation helpful? Give feedback.
-
|
An instance per locale would be fine if there was a way to know which locale the instance uses. At runtime, I may call Even so, if you're seeding data using multiple locales, thing can quickly get out of hand in model factories: class CustomerFactory extends Factory
{
public function definition(): array
{
return [
'name' => $this->faker->company(),
'address' => $this->faker->streetName(),
'city' => $this->faker->city(),
// is it safe to call state here? probably not! how about 'county'? Think twice!
'state' => is_callable($this->faker, 'state')
? $this->faker->state()
: (is_callable($this->faker, 'county')
? $this->faker->county()
: (is_callable($this->faker, 'region')
? $this->faker->region()
: null)
)
];
}
} |
Beta Was this translation helpful? Give feedback.
-
Not even close. There's not a Administrative divisions by level would be interesting to have as a unified API between all implementations, and then each one could keep their own naming.
I would go two different routes here depending of your case but both of them reduces to the same concept: being aware of which specific implementation you are using. It will make your static analyzer happier and prevent you a lot of headaches.
Maybe it is not so easy because the anti-pattern is biting back. It's not a Faker's design problem: you can use faker in another way, register your own factory, or open an issue or a pull request into Laravel's repository. |
Beta Was this translation helpful? Give feedback.
-
Well the I also must point out that my last example of using The only way I to know which implementation we're working with, is to loop over individual providers via Actual real-life working example would be something like this: $faker = Faker\Factory::create($someLocale);
$stateOrCounty = null;
foreach ($faker->getProviders() as $provider) {
// check if the provider is an Address provider, and if it has a county method
if ($provider instanceof \Faker\Provider\Address && method_exists($provider, 'county')) {
$stateOrCounty = $provider->county();
}
// alternatively, check the instance of the provider
if ($provider instanceof \Faker\Provider\en_US\Address) {
$stateOrCounty = $provider->state();
}
} |
Beta Was this translation helpful? Give feedback.
and others
-
Hey all,
In fzaninotto's repo a discussion was started about the design of the next major version (fzaninotto#1807). Shall we reopen that here?
The three questions asked by @pimjansen were:
Beta Was this translation helpful? Give feedback.
All reactions