deankarn
commented
7 years ago Hey @nikolay-turpitko
I will try and see if the alt date formats are in the CLDR data somewhere. Once the need for context comes in this library is only designed for the l10n stuff really and that's handles by this library's sister project https://github.com/go-playground/universal-translator which provides the i18n stuff to the end user like custom translations...
as for customising the locale, that's why each returns an interface rather than pointer to a struct so you can create your own, copy-paste-modify, or embed in your own object/struct and override a function and because it complies with the interface will still work in it's sister project just fine...just a different way to customized, but by doing it this way could also create your own reusable locale.
I could allow settings to be set etc..but this is all generated code so if I allowed that then I would have to parse the format every time instead of having the pre-parsed and most efficient code..besides just keeping it simple to use and implement is definitely a priority
nikolay-turpitko
It's just an information for your consideration. When I checked tests for Russian language, I noticed, that month names are in one particular form (case). It's, probably, OK for date formatting, but may be not enough for general use. To better understand what I mean, try to open and compare links at this page: http://www.localeplanet.com/compare/ru-RU/index.html.
Basically, there are different forms (cases) of nouns in Russian language, with different endings, depending on usage context. Something similar to English verb forms. While in English you can use "January" as a title in the calendar and to format dates (21st of January; January, 21), in Russian you will need different noun forms for it. You should use "Январь" as a title in calendar, but "21 января" in formatted date. Sometimes I encountered format like "Январь, 21" but it usually feels cumbersome.
Notice, that in your project, you used translations from CLDR (ICU based on it as well), which is more suitable to format dates, but does not contain translations to be used as titles in calendar. Interestingly, Java decided to use nominative case, more suitable for titles in calendar, than for formatting.
Which way is better, depends on the intended library usage. For formatting only current variant is OK. For general use, it preferable to have both variants. Probably, it could be solved with a way to provide custom translations. Setter or builder, or configuration file with custom translations and formats - don't know.
BTW, in Java you not only have a way to programmatically customize formats, you also can supply property files in your package. You even can put this files within your archive at the path were system default files used to be. Due Java class loading mechanics, this custom files will overwrite system ones, so you can replace default translations with your custom property files if put them in right place.