I know it can be a sensitive subject for some people, but that CE/BCE naming is not used a lot in American English in general, and almost non existent elsewhere. Its equivalent is never used in French for example, and when French people look up the english translation of “après JC” google won’t even mention this alternative. Thus, even if Americans could understand both alternatives easily, I think introducing such a convention is a bad idea.
Cochonours
kip
ex_cldr Core Team
The full table of supported codes for ICU is in the reference you supplied, more specifically at Unicode Locale Data Markup Language (LDML) Part 4: Dates
E, EE and EEE are week day formats like “Tuesday, Tue, T”
MMM, MMMM are month names like “September, Sept”
There are others that are primarily textual and therefore locale specific like a, b, B that I recognise are outside of the scope of this proposal.
I’m just trying to work out if they remain valid formatting codes for this proposal, but not supported by the default formatter. Or if they are considered invalid codes for this proposal.
On the locales front - yes, your API strategy makes a lot more sense. The core of what i was trying to express, badly, is that even when a package or a language doesn’t support multiple locales, it implicitly is supporting one which for Elixir is en-US. Today, each package that intends to help support multiple locales like Gettext, Cldr, Trans has its own notion of current locale and what constitutes a supported locale, or locale name format. A unifying strategy for current locale and locale name would be helpful. But outside the scope of this proposal of course.
6
josevalim
Creator of Elixir
Thanks everyone for the feedback!
I am bringing the proposal down for now because the discussion has made it clear that, if we want to support this, then we should go ahead and fully support ICU (with all formats, variants and what not) or we don’t support it all.
After all, if we only support part of it, then the community will have to implement everything again, like in @kip’s great projects, or we will have to define many interfaces so libraries are able to continue the work we started. None of those options feel great and then I would rather make sure that the Calendar functionality provides everything @kip needs in his libs.
So here are the next steps: we will look into simpler formatting syntaxes, possibly strftime, and see if we can write a proposal with reduced scope and less pitfalls that provides a minimum set of functionality without overlapping with more complex use cases. In case we can’t find anything that fits those constraints then we will give up on having formatting in core for now.
6