@ohcibi - I find it's generally better to focus on the data and API instead of trying to assume what the intent of every single user is. We aren't really here to make arguments or make assumptions for the users. If you aren't interested in helping improve de locality that's fine.
@Moosh-be ive used faker a lot in projects. It’s suitable for both tests and development/prototyping given that your fake api is as easy accessible in both situations. There is a need for specific languages and phrases as the average length of strings differs depending on it, so to test your layout properly you need edge cases. Many of them however are so special that you end up using fixed data anyways. Text usually is Loren ipsum but having real sounding company names is nice in show cases besides the layout testing aspect. I created them from randomly combining 2-3 bsNouns and appending „Inc.“
@Marak you misunderstood me here. All I’m saying is the de locale is fine as it is. The only bad thing about it is that some modules use the fake api which suggests one can do this everywhere. But one can’t. I’ve replaced the occurrences in DE with lists of real city/street names and will push it this week. Just need to generate a bunch of numbers for the „street address“ fake data. There is public lists online and I think we can quickly fix up the top languages even if we don’t speak the Language with These. At least for most parts. Is it only about missing data and fake syntax or are there other issues? A very loud request is to make this library es6compatible. The locales are the only thing that prevent a fast (fast as in run 2-3 sed commands and it’s done) transition to that so I’m all in on getting these ready ASAP.
If you can provide any proof of example code for ES6 imports working with locales that would be great as a reference
We also could use a script or toolchain or process to test treeshaking
I hear you about de locale. It's pretty close actually, maybe just one or two methods are slightly off.
Hi all, I've recently opened a PR regarding the new datatypes module ( #1114 ) . Although the lib files are successfully merged, it has not been added to the faker.js itself nor is it in the Readme. I thought a contributor should only push the lib files and not touch the ones built by gulp. Was I wrong? :sweat_smile:
@lbuerste - Greetings!
The code should be merged into master now. It will take a few cycles to see it get into the ReadMe and published version
okay, i just merged a few pending PRs. The next one will probably be #841, which is Linting. that might invalidate all the current PRs that are open
if anyone sees any PRs we can merge make a comment / approval on the thread or try to see whats missing
I could rework the image generation into a unit test for arrayElements. I think one could do the same thing for other methods like floats between 0 and 1 to check for an average 0.45 < x < 0.55 or similar