Great! Thanks so much for providing such essential libs to elixir 
Cochonours
kip
ex_cldr Core Team
Finally updated ex_cldr_dates_times to version 2.0. This completes the migration of the Cldr_* family to version 2.0.
Please note that ex_cldr_dates_times requires Elixir 1.8 or later since it leverages capabilities of the Calendar module.
It also depends on ex_cldr_calendars which implements enhanced calendar functionality including week-based calendars, financial year calendars and user defined calendars based upon the Gregorian calendar. In future releases it will support additional calendars with a first focus on Persian and Islamic.
With this release out the door the Cldr_* family has only two packages left on my “todo” list:
- [Updated] ex_cldr
- [Updated] ex_cldr_numbers
- [Updated] ex_money
- [Updated] ex_cldr_lists
- [Updated] ex_cldr_dates_times
- [Updated] ex_cldr_units
- [New] ex_cldr_calendars
- [New] ex_cldr_calendars_format
- [New] ex_cldr_print
- [In Development]
ex_cldr_collations - [Not started yet]
ex_cldr_messages
9
kip
ex_cldr Core Team
A pretty large update to ex_cldr_units today. Primary focus is on converting units from one measurement system (ie :metric) to the system customary for a territory (country). I think this is pretty cool 
The changelog entry is:
Enhancements
- Add
Cldr.Unit.localize/3to support converting a given unit into units that are familiar to a given territory. For example, given a unit of#Unit<1.8, :meter>it would normally be expected to show this as[#Unit<:foot, 5>, #Unit<:inch, 11>] in the US. The data to support these conversions is returned byCldr.Unit.unit_preferences/0. An example:
iex> height = Cldr.Unit.new(1.8, :meter)
iex> Cldr.Unit.localize height, :person, territory: :US, style: :informal
[#Unit<:foot, 5>, #Unit<:inch, 11>]
iex> Cldr.Unit.to_string us_height
"5 feet and 11 inches"
- Note that conversion is dependent on context. The context above is
:personreflecting that we are referring to the height of a person. For units oflengthcategory, the other contexts available are:rainfall,:snowfall,:vehicle,:visibilityand:road. Using the above example with the context of:rainfallwe see
iex> Cldr.Unit.localize height, :rainfall, territory: :US
[#Unit<:inch, 71>]
iex> Cldr.Unit.to_string height
"71 inches"
-
Adds a
:peroption toCldr.Unit.to_string/3. This option leverages theperformatting style to allow compound units to be printed. For example, assume want to emit a string which represents “kilograms per second”. There is no such unit defined in CLDR (or perhaps anywhere!). But if we define the unitunit = Cldr.Unit.new(:kilogram, 20)we can then executeCldr.Unit.to_string(unit, per: :second). Each locale defines a specific way to format such a compount unit. Usually it will return something like20 kilograms/second -
Adds
Cldr.Unit.unit_preferences/0to map units into a territory preference alternative unit(s) -
Adds
Cldr.Unit.measurement_systems/0that identifies the unit system in use for a territory -
Adds
Cldr.Unit.measurement_system_for/1that returns the measurement system in use for a given territory. The result will be one of:metric,:USor:UK.
3
kip
ex_cldr Core Team
ex_cldr_messages version 0.1.0 is now published. This package implements the ICU Message Format. A good explanation of the motivation for the ICU Message format is in this presentation by Mark Davis from Google.
Eventually this package will be an alternative to Gettext however this first release is simply a message formatter.
The ICU message format leverages the localisation data from CLDR. This implementation uses the capabilities of ex_cldr, ex_cldr_numbers, ex_cldr_dates_times, ex_cldr_units and ex_cldr_lists to simplify the localisation of messages.
A couple of examples:
# Simple binding interpolation
iex> Cldr.Message.to_string! "My name is {name}", name: "Kip"
"My name is Kip"
# Pluralization used the CLDR pluralisation rules implemented in ex_cldr
iex> Cldr.Message.to_string! "On {taken_date, date, short} {name} took {num_photos, plural,
=0 {no photos.}
=1 {one photo.}
other {# photos.}}",
taken_date: Date.utc_today(), name: "Kip", num_photos: 10
"On 8/26/19 Kip took 10 photos."
# ICU Messages can manage grammatical gender, nested message formats,
iex> Cldr.Message.to_string! "{gender_of_host, select,
female {
{num_guests, plural, offset: 1
=0 {{host} does not give a party.}
=1 {{host} invites {guest} to her party.}
=2 {{host} invites {guest} and one other person to her party.}
other {{host} invites {guest} and # other people to her party.}}}
male {
{num_guests, plural, offset: 1
=0 {{host} does not give a party.}
=1 {{host} invites {guest} to his party.}
=2 {{host} invites {guest} and one other person to his party.}
other {{host} invites {guest} and # other people to his party.}}}
other {
{num_guests, plural, offset: 1
=0 {{host} does not give a party.}
=1 {{host} invites {guest} to their party.}
=2 {{host} invites {guest} and one other person to their party.}
other {{host} invites {guest} and # other people to their party.}}}}",
gender_of_host: "male", host: "Kip", guest: "Jim", num_guests: 4
"Kip invites Jim and 3 other people to his party."
The package is under active development with expected frequent updates over the next couple of months.
7
tmbb
kip
ex_cldr Core Team
This first version is interpreted each call. It’s clearly not ready for real world use.
Next version I’ll have done in a few days introduces the f/1/2 macro which will compile the format.
What I’m aiming for is to make it as easy as possible to update existing strings to be localised. So something like just converting ”this is a string” to f”this is a string” would be one way to do that. With interpolation it would be f”this is a {number}” and it will assume number is defined in the scope and therefore resolve to var!/1. This way the behaviour is similar to standard elixir string interpolation.
Then after that its all of the translation scaffolding. Rather than take the po file approach I am looking at pluggable backends with a primary intent to build a backend translation service so that translations can be updated without code building and release cycles and allow good support for crowd-sourced translations.
I know you’ve done a lot of work in this area so any feedback, thoughts, suggestions and criticisms are most welcome.
0
LostKobrakai
I‘m not sure I really like that. It means coupling the name in the translatable string to code concerns, a.k.a. a variable name. I‘d guess I‘d rather like it to work like gettext, where you supply a keyword list for substitution.
This is especially relevant if the same string is used in multiple contexts, where variables might be names differently.
2
kip
ex_cldr Core Team
Definitely there iwill be an option to supply a binding in the same way as for gettext. I’m still in experimentation mode. For standard string interpolation the binding is already implicit though. So there is a behaviour difference between normal strings and gettext strings.
0
LostKobrakai
Yeah, but the important difference is that for normal string interpolation the scope of the variable name in the string is the scope of the variable itself. For translations the scope of variable names extends to being useful names for translators as well. E.g. I just read the medium post on slack implementing translation using ICU messages and they have a rule to always suffix _possissive to their variables if the variable should be in possessive form.
Another difference is that string interpolation understands elixir code, e.g. "#{helper.name} helped #{receiver.name}", which I’m not sure if possible in ICU messages, where I guess you need a plain variable without nesting.
I don’t think code like this is preferable to the latter
helper_name = helper.name
reciver_name = receiver.name
…
f("{helper_name} helped {receiver_name}")
f("{helper_name} helped {receiver_name}", helper_name: helper.name, receiver_name: receiver.name)
1
kip
ex_cldr Core Team
Good points as always. Gettext strategy it is.
Do you have the link to the article you mentioned?
0