Relative time in English has different casing from CLDR
sandstrom opened this issue · 8 comments
I've noticed that relative time has different casing (initials upper-cased) from Unicode CLDR.
TwitterCldr::Localized::LocalizedTimespan.new(3600 * 24 * 2, :locale => 'en').to_s
# => "In 2 days" (expected "in 2 days")These values are lower-case:
https://github.com/unicode-cldr/cldr-dates-full/blob/master/main/en/dateFields.json#L184
These values have first-letter capitalized:
https://github.com/twitter/twitter-cldr-rb/blob/master/resources/locales/en/units.yml#L11
Is this an issue with the imports, or something else?
Hey @sandstrom, unfortunately the units schema in the CLDR changed after v23 and we never put in the effort to refactor. This also means we're stuck using the data from v23, which contains those upper-cased "In" bits. I would love to get all parts of TwitterCLDR using the latest CLDR data (v29 I believe), but my time is limited these days. I would however welcome a pull request if you've got the time to dive in.
@camertron I appreciate the update! I'm also short on time the next 2 weeks. Perhaps I can get around to it later, but I cannot promise anything.
Anyhow, thanks for a great library! We're a tiny startup and this is very helpful to us! It's great that you and Twitter will make this OS contribution ⛵
Glad to hear you're getting some mileage out of the library! Can I ask what your startup is and what you're using TwitterCLDR for? I ask for my own curiosity :)
One thing I forgot to mention is that TwitterCLDR does have the ability to downcase text in just about any script. You can either call #downcase on an instance of LocalizedString or use the caser directly:
"ABC".localize.downcase.to_s # => "abc"
TwitterCldr::Shared::Caser.downcase("ABC") # => "abc"For these examples you could of course have used ruby's built-in String#downcase, but the TwitterCLDR caser should work for many other scripts and languages as well.
It's an finance/employee tool, sold to companies. We're only a couple of people. Most localization occur in the JS-layer (SPA), but some things also need localization at the server. Email bodies and some other server-generated content. For this TwitterCLDR is great!
Great suggestion, that's sort of what I did.
You asked about renaming the project previously. How about vernacular? (rosetta would have been great, but there is a gem with that name already; on ricu I think it's bland and difficult to remember)
Also, on CLDR in general, perhaps the method used by Globalize would work here too: they don't include the CLDR-data in the library, it's loaded separately. That way new releases are less coupled to CLDR.
(I understand it wouldn't really solve this issue, since the format had changed and that would still require changes, even if CLDR isn't bundled, but I still thought it may be a good idea)
Cool thanks for sharing!
I kinda like vernacular, although we decided a while ago that renaming the project wouldn't really benefit it in any way. A name is just a name.
I have always wanted to integrate TwitterCLDR into Rails and libraries like Globalize. It's really just time constraints that have prevented it. But, viva la open-source! Hopefully someone with more time/resources can take up that particular mantle.
@camertron that sounds cool. I really wish to implement that. 😃
This should be fixed with the release of v4.0.0.