Localisation of date and time in the activity tables

[lcharette]

No description provided.

[lcharette]

Looks like Carbon doesn't support defining our own locale strings and only support the setlocale php function. This is clearly not reliable as it depends on the locale installed on the system, which contradict the file based localization provided by UF. French support for dates would required it installed on the system even if it's "available" as a UF locale.

So unless someone as an idea how we could solve this, we'll probably require our own fork of Carbon...

FYI, this could probably be done using Moment.js, but that would mean handling dates at Handlebar level...

[lcharette]

This could be useful : https://github.com/jenssegers/date

[Silic0nS0ldier]

It looks as though they already took a stab at it. Git blame seems to suggest its used for the diffForHumans translations, which it is. Pity they didn't extend it to everything else.
https://github.com/briannesbitt/Carbon/blob/master/src/Carbon/Carbon.php#L1093-L1170

[lcharette]

This could be useful : https://github.com/jenssegers/date

I tested it out. Works great. Every questions regarding Laravel and localized date points to this package. All that would need to be done is to add it to core and set the "date" locale when loading the overall locale. Should be easy do rewrite Laravel ServiceProviders to our own format.

Only problem, it doesn't use the same locale identifier as UF. Would requires some trick for us to make it work with UF, like the locale metadata thing we talked before...

[Silic0nS0ldier]

Only real difference in local identifier is _ vs. -. Easy to switch. Shame it doesn't support fallback logic though (I mean, to the same degree we have).

[lcharette]

Hum? We use fr_FR while they use simply fr..

[Silic0nS0ldier]

That's because they are technically different translations. Ours is more specific. We'll need to look though the other locales the user requested before resorting to lowering specifity.

[lcharette]

That's why I brought up the metadata thing. For example each locale could have a simple YAML/json file containing description and settings about the locale :

• Locale name
• English name
• Base / fallback language
• Translator name
• Plural rule
• Date locale

Actually, I found the original issue (and get now why I couldn't find it earlier) : userfrosting/i18n#4

[alexweissman]

I'd actually prefer if we used the more generic language codes. If we had @lcharette's fallback language metadata, we could make this change in a backwards-compatible way.