Do not call inexistent locales about faker HOT 6 CLOSED

@igas will raising an exception will be the right way to proceed here?

from faker.

I don't think so, we should fallback to defaults.

For example if I call Faker.Name.name for locale set to :id. And we don't have an Faker.Name.Id it should call Faker.Name.En.

I see it something like this:

• check if :faker app started.
• If it is grab locale and check that we have module for this locale.
• If any of this false fall back to En

It'll be a little bit more difficult when we will introduce sublocales like EnUk, EnUs, EnAu and so on, in that case I think we will check for EnUk for example if this MFA doesn't exist check for just En.

It'll make usage much simpler from my point of view.

Any suggestions?

/cc @vforvova

from faker.

@igas fallback to defaults is good idea, but what if we have partial implementation of Faker for some language?
For example, we have Faker.Name.En, Faker.Company.En as default and Faker.Name.Ru for Russian language. If we send name to Faker.Name with Russian as current language, we will get any Russian name. But if we send Faker.Company with Russian language, we will get English company name. It feels confusing a bit... but I have no ideas how to resolve this issue.

from faker.

After a while I had some time to take another look to this issue.

I'm proposing a solution similar to the the one described above by @igas, which looks as follows:

Instead of repetitively defining each localized function over and over in each file, we could abstract that piece of code into a reusable construct, like a macro. That way, this:

def name, do: Module.concat(__MODULE__, Faker.mlocale)

can be replaced by this:

defmodule Faker.Color do
  use Faker.Locale

  localize :name
end

Faker.Locale would simple collect all function names that need to be localized, and resolve the right module to call.

@vforvova your point is valid but I strongly feel that, that specific issue is really hard to solve; I see the following approaches here:

• The simple way would be to delegate the responsibility to the consumer, we just fallback if there's no localization for a specific module.
• The best way will be to have an extension mechanism, that way your example above will be solved by the consumer extending Faker.Company to Russian. If we decide to go this way, it might be better to open a dedicated issue for this IMHO.

I have a WIP branch here: https://github.com/saulecabrera/faker/blob/dynamic-calls/lib/faker/locale.ex

I would appreciate your thoughts on this.

from faker.

Hi @saulecabrera,

Great code out there, I got some inspiration from it and created #173. What do you think?

from faker.

@igas Sorry for the delay! I feel that your solution is a nice iteration to mine, specially because the amount of metaprogramming is less. I'm all in with this!

from faker.