Runtime based translations definitions for multi tenancy support

[jfayad]

It is currently mandatory to define a default_local when using the trans macro (eventhough it's stated that this is optional in the doc.)

Moreover, the current __build_embedded_schema__ requires us to know the languages we will want to translate the schema before hand.

I understand that this works for most single tenants apps, but in a multi tenant app, this is limiting.

I have a use case which I think is generic enough for any multi tenant app:
-> each article will have a separate default language (creating article 1 in fr while article 2 could be created in en).
-> each tenant will define the translations he wants to support (Tenant A would enable fr and es while Tenant B might only want en and fr). Consequently, article 1 will have fr as a default language and es as a translation

After reviewing the code I think this can be supported by performing the following:

Remove the requirement to define a default_local as an option to the use

Instead request it to be a field name in the schema so the default language can be stored in the DB immediately

Update the __build_embedded_schema__

Now it defines two nested embeds_one and run the loop for the inner embedded_schema inside the macro, instead having the first level embed be an embeds_many to the embedded_schema (with no loops) and let the translations declarations happen at runtime.

The query_builder and translator need to be updated to fetch the translation inside the list of translations (and not a map anymore)

@crbelaus does it make sense ? Is it something you would want Trans to support ?

I'm eager to see if you have any reserve to move forward with that ? If you think it's a good update for Trans I would happily push a PR, otherwise I can fork and publish a separate deps.

[FabienHenon]

I'm also interested in a solution for this use case.

Did you make any progress on that?