For the table, I would add a translation table, if You don’t want to embed translation…

create table(:posts) do
      add :title, :string
      add :content, :string
      add :published, :boolean, default: false, null: false
      timestamps()
end

create table(:posts_translations) do
      add :post_id, references(:posts, on_delete: :delete_all)
      add :language_id, references(:languages, on_delete: :nothing)
      # Add fields You want to translate
      add :title, :string
      add :content, :string
      timestamps()
end

This is more or less what globalize does.

I’ve generally seen both a side translation table and an embedded translation thing as crutches for fixing up originally broken designs. Designing the tables with the translation keys from the start is far superior as there is less joining, more efficient indexes, etc…

ex_cldr handles RFC compliant language tags and also manages fallbacks to supported languages. For a somewhat extreme example:

iex> MyApp.Cldr.validate_locale "en-AU-u-nu-latn-cu-AUD-cf-account-tz-ausyd"
{:ok,
 %Cldr.LanguageTag{
   canonical_locale_name: "en-Latn-AU",
   cldr_locale_name: "en",
   extensions: %{},
   gettext_locale_name: nil,
   language: "en",
   language_subtags: [],
   language_variant: nil,
   locale: %{
     currency: :AUD,
     currency_format: :accounting,
     number_system: :latn,
     timezone: "Australia/Sydney"
   },
   private_use: [],
   rbnf_locale_name: "en",
   requested_locale_name: "en-AU",
   script: "Latn",
   territory: "AU",
   transform: %{}
 }}

Which should tell you pretty much everything you need to know. And there are other related libs for format dates, numbers, units (and soon messages) etc as required.