[Proposal] Define the default locale and support locale fallbacks

[kipcole9]

I wonder if you would consider PRs for the following two proposals?

I am the author of the ex_cldr libraries. With the recent work by @maennchen, we now have good integration between gettext and ex_cldr. My next step is to make it really easy for ex_cldr users to work with trans. While its definitely not hard to do today, there are a couple of things that would help.

Overall I think this would create a very good partnership between Trans, Gettext and ExCldr which can only make Elixir stronger as a platform for localised applications and lower the barrier to entry for making more applications localised.

;TLDR

• I propose adding a :default_locale option to use Trans to define what the default locale is
• I propose adding support for locale fallback chains to Trans.Translator and Trans.QueryBuilder
• I am fine to do the work and submit PRs if there is support for the proposal

Cldr integration with schema definitions

I have drafted a prototype implementation of how a Trans schema might leverage ex_cldr. This prototype looks like the following, using the example from the README. Basically, by introspecting the ex_cldr backend we can determine the available locales and generate the schema definition required. Overall I think it also looks quite clean and easily understood.

defmodule MyApp.Article do
  use Ecto.Schema
  use Trans, translates: [:title, :body], default_locale: :en
  use MyApp.Cldr.Trans

  schema "articles" do
    field :title, :string
    field :body, :string

    # Configures all locales known to MyApp.Cldr
    # The usual options can also be specified
    translations :translations, MyApp.Article.Translation
  end
end

Allow defining the default locale

While there is the concept of a default locale in trans, there is no identification of what that locale is. Why is that useful? One use case relates to the example above: we would not want to configure embedded schemas for the default locale so we need to know what it is! Another reason is that if specifying the default locale with Trans.QueryBuilder then the translations do not need to be retrieved or accessed. This would would also aid identifying what translations are available for a schema. Lastly, related to the next proposal, is the ability to support locale fallback chains. To do so requires knowing what the locale of the base column is.

What would this look like? I propose:

use Trans, translates: [:title, :body], default_locale: :en 

Allow fallback chains in Trans.Translator and Trans.QueryBuilder

In many localised applications, the translations and localisation may be sparse. For example, if my application is configured to support en-AU, en-GB, en-CA and en-US then many localisations could be common (where terms, spelling and colloquialisms are the same for example). In such a case, if the locale is set to en-AU it would be appropriate to look for translations in en-AU then en. Thats a simple example. A more complex example might be if the locale is set to :nd then the fallback chain (assuming a default locale of :en) would be:

iex> MyApp.Cldr.Locale.fallback_locale_names(:nb)
{:ok, [:nb, :no, :en]}

The "good news" is that this can be implemented as a non-breaking change to the current code. A secondly, since ex_cldr can derive the fallback chains from the CLDR data the integration is greatly simplified.

[crbelaus]

This is an incredible proposal. Thank you for taking the time to think and write it 🙇

I love all the proposed changes and I agree with you that they will make the combination of Gettext, Cldr and Trans very powerful.

Unfortunately I won't be available for the next two weeks, so don't worry if the pull requests don't receive any feedback right now. I will merge them as soon as I'm back.

PS. Thank you so much for building Cldr! I've used it myself in multiple projects and it has always worked like a charm.

[Kurisu3]

Really great proposal! No more news on the subject since then?

[davemccrea]

@kipcole9 did some great work here. Will we see the main branch tagged and released?

[crbelaus]

You are right. A new release of Trans is long overdue.

Unfortunately I've had lots of things going on in my personal life and neglected this library a bit. I plan to fix that and started working on the 3.0 release today on #82