It would be good have some tutorial or book for this case with translations on ecto.
And would be better showing how to use restrictions. I’m curious about this things as well.
And when I was trying to do a Publish in Ruby on Rails I used the date like @OvermindDL1 says.
For published you have the dates for filter and for the unpublished you have the values with NULL.
romenigld
2
dimitarvp
I am joining @OvermindDL1 here: language codes are standard and there’s no need for IDs since it’s actually possible to have N times the same language.
I’d go with that he proposed but it’s also one of the cases I’d heavily utilise ETS caching. It’s not at all fatal if somebody hits the wrong translation in the cache 4-5 times before it gets propagated from the DB after an update.
2
kip
ex_cldr Core Team
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.
3
wolfiton
Thanks for the help everyone.
I decided to build a CMS called WolfCMS, I will anonunce it officially when I have an MVP.
Find more here CMS open projects ideas suggestions - #30 by wolfiton
1
wolfiton
Moved everything regarding WolfCMS here WolfCMS thread suggestions and help and discussions
Thanks for the help everyone and also for the great ideas
0