Thinking about a better internationalisation system

[popo63301]

Hi guys!

First, I have to say thanks for the work you all have done to build this library. It's always great to have a decent Faker library in any programming language. I was thinking about the way this library handles i18n. I'm a bit afraid that if we continue to contribute on several languages, using a language namespace will make the documentation enormous.

To be honest, I don't have a solution of my own except reproducing the method that works elsewhere like using YAML file as Faker's Ruby did. Also, I searched about gettext because this is the i18n library by default of Phoenix but I'm not sure that's the right solution here. I just wanted to start the conversation about this with you guys. 😄

[igas]

Hi @popo63301,

In the beginning, I had JSON files as data, but it was quite fast dropped as it was magic on top of it (metaprogramming).

I have always envisioned it as much as possible to leverage the strength of the language. This is why modules such a good way to handle it, you can use them directly, without modifying the state (app config, etc).

I also thought about getting l10n and i18n right for a long time, this is where EnUs and EnAu where applicable and En as fallback come from.

Before continuing our discussion I would like to know if you have any other concerns about it apart from the documentation?

I thought about the library getting too big too, one of the ways could be split of it into core + domain/language hex packages.

Thank you for being passioned about the issue and raising it.

[popo63301]

Hi @igas ! 😁

No, I don't have other concerns besides documentation. Maybe we can stick with the current system and create a github documentation with Markdown files similar to the "usage examples" sections so that people can rely on this documentation instead of a thick hex doc. Thus, we can have a lighter documentation and still benefit from this handy i18n system.