Replies: 51 comments 24 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.
-
Hey. |
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.
-
What about... voting? :D |
Beta Was this translation helpful? Give feedback.
-
English language support please! |
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.
-
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.
-
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.
-
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.
-
Hi, maybe somebody will find it useful - I needed a Faker 2.0, read a lot what you were planning, thought a lot of what was bothering me in Faker 1.0 and came up with this. Since I'm not limited by any braking change promise I just tried to do that properly "this time". Yep, it comes with some sacrifices, I wanted to remove that one Any feedback welcome! This is MIT license so you can take anything from it at use as your own if needed. |
Beta Was this translation helpful? Give feedback.
-
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