Translate-plugin: Dates translation not working anymore

[amdad]

Carbon do not react on language switch. Always show dates in default language of config/app.
Tested on many plugins. Rainlab Blog also.

[munxar]

@amdad afaik there was never a translation of dates out of the box. we had to add the twig extensions plugin to make it work.

[amdad]

So, you know it wrong. It works flawlessly some times ago.

https://github.com/octobercms/october/issues/1968

[amdad]

Thing is, that translation is done correctly in system by carbon extension. If you set global app config on other then English you can see it (translated dates). It just not switch to active lang with languageSwitcher like it was before last updates.

Without latest pending 'edge' fix language switcher doesn't switch even content properly. So latest issues must be related to this issue also.

[vannut]

There is a difference between the app locale (set in the config file) and the locale which is selected by the translate plugin.

I've overcome this 'issue' and the problem of different system locale (like nl_NL.UTF8 vs nl_NL vs nl_NL.UTF-8) by wrapping the translation of dates via carbon in a twig-function which standardises the locale-array to work on every system, takes a format as argument with a sensible (for us) default.

[munxar]

@vannut was about to write the same :-)

[amdad]

@vannut @munxar Guys, I told you, this function was added by my request and works by itself. And still works. It is just broken now.

Originally dates show up only in English. From this octobercms/october#1968 October got function to extend Carbon with localized/translated version. It still there, just somewhere between communication between Translate plugin and October something is missing after last updates. It's need to be fixed, not talking about workarounds.

'locale' => 'fr',

en, ru, fr and so on changing output of dates. In Translate plugin language settings I also from beginning have short versions of lang names. So it was working fine and should be still. Don't overthink it.

[LukeTowers]

@amdad you seem to be the most knowledgeable about the issue and what broke. Please submit a detailed pull request to fix it.

[amdad]

If I could, I would Luke. I just know how it works before is stops, because I just used it.

[LukeTowers]

@amdad don't be afraid to dig into the code and read / play around with it. I can tell you right now that I personally don't have time to work on this particular issue so any fix will have to come from the community.

[munxar]

@amdad @LukeTowers I found the code and your totally right, Argon was added exactly for this purpose.
I'll take care of this, if nobody minds.

[munxar]

I found that this event 'locale.changed'

$this->app['events']->listen('locale.changed', function($locale) {
            $this->setArgonLocale($locale);
 });

is never fired. I'm on it...

[LukeTowers]

@munxar to the rescue! 🎆

[munxar]

@amdad did you use the build in twig date filter like {{ now|date }}?
because i can't find any piece of code that overrides the standard twig date with the Argon implementation (I think Argon is mainly/only used for the backend)

[amdad]

Yes, yes.

{{ post.published_at|date('M d, Y') }} from Rainlab Blog example. Without Argon date always would be in English format, and one only. When you change config in app date is translated with Argon also on frontend. This proves Argon works on frontend. It just not receive properly this function/event to change lang from Translate plugin. Before Argon, frontend date format was always the same.

Before this was considered: https://github.com/octobercms/october/issues/1968#issuecomment-215336920

Anyway after Sam implement this this works flawless without any changes in templates code. Just October (Carbon extended) do whole thing before it goes to twig.

[munxar]

@amdad I can change the locale or fallback_locale and nothing is translated.
my build is 431 latest translate plugin, no other plugins installed.
pls. list the plugins you have installed, I bet one of theme replaces/extends the standard date filter.

[amdad]

You shouldn't change 'fallback_locale' but 'locale' => itself.
Fallback is when original translation is MISSING, then secondary language is displayed.

Change 'locale' => 'ru' or any other well known lang, and you'll see how Argon works flawless on frontend without any changes in code.

[munxar]

@amdad tnx I now how the system works ;-)
but it just doesn't what you say on my system. If you like me to help you, pls give me the required info.
What plugins do you have installed? What versions?

[amdad]

Ok, I will write you steps to recreate. I'll start on clean install to be perfectly sure. Give me a second. It must be the same scenerio with you. It's not about plugins I have installed.

[amdad]

1. Make clean installation of October. I choose SQlite DB
2. Install Rainlab.Blog
3. Add BlogPosts component to demo theme.
4. Open site. You'll see default English month name on date of test Blog post.
5. Change in config/app.php

'locale' => 'en' to 'pl'

1. Refresh website, you see Polish month name on frontend.

BTW. Clean CACHE!

[amdad]

Maybe have cached page. Clean any cache after locale change. Only installed is Rainlab.Blog, not even Translate plugin.

[amdad]

@munxar Did you experience Argon on frontend already? 😄

[vannut]

SOrry @amdad I clearly mis understood your question, as it seems more extensive then on first sight. My suggestion is not a workaround, but an extension to add some functionality to twig.

Besides that I'm not seeing what this 'jenssegers/date` extension adds as localisation functionality is baked into carbon by default.
But I might be missing the picture here (again) ;)

@munxar if that event is not fired on locale change, then shouldn't it be an easy fix, fireing the event in the middleware?

[amdad]

Exactly, I guess it's must be somewhere in middleware as I see middleware was broken and fixed in latest commits. So I thought there is a problem. But for me as a beginner "middleware" is just another concept I still need to learn from scratch. Also, after update to laravel 5.5 many things can fail because of changes. You can check last build of October before update, and last Translate plugin version from those times and there was no problem with switching date language.

[munxar]

So I found something that could explain everything:

<?php

use Illuminate\Support\Carbon;
use October\Rain\Argon\Argon;

function onStart() {
    $this['argon_date'] = Argon::now();
    $this['carbon_date'] = Carbon::now();
}
?>
==
<div class="container">
    <div>{{ argon_date|date }}</div>
    <div>{{ carbon_date|date }}</div>
</div>

The output in ru locale is:

январь 27, 2018 06:53
January 27, 2018 06:53

wich means that the model is relevant how the date is rendered. If you use a Carbon or plain php DateTime it is NOT translated, if it is an instance of the Argon class, it's translated properly.

Long story short: If there is a breaking change, than it's in the way the timestamps are instantiated (they should be of type Argon not Carbon). It could be a change in the core or in the RainLab.Blog plugin.

So sorry, but nothing to do here, everything works if the right date instance is passed.

[LukeTowers]

@munxar were you able to find any changes in how the core uses the dates and if there was a switch during the Laravel 5.5 upgrade?

[munxar]

No, I didn't look into it yet. But the $dates Attribute in the Model class
would be a good starting point. Will habe a look this WE

Am 27.01.2018 8:34 vorm. schrieb "Luke Towers" [e-mail]:

@munxar https://github.com/munxar were you able to find any changes in
how the core uses the dates and if there was a switch during the Laravel
5.5 upgrade?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rainlab/translate-plugin/issues/338#issuecomment-360967091,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALtgtBNEkv992ZmV4fUvTYHdGviE96Qzks5tOtGNgaJpZM4Rt1ec
.

[munxar]

So I have to admit, I made a mistake. I added this call the Translator class

Event::fire('locale.changed', $locale);

and this made everything work. If I remove it, translation doesn't work. Has someone insight if Laravel 5.5 removed this event?
Afaik it should fire on App::setLocale(), no?

So to correct my statement from above, we indeed can fix the behavior inside of the translate plugin by fireing the event.
I'm not sure if this is the right place...

[amdad]

Wow, it works for me :) Thank you. Can you PR this?

[munxar]

@amdad @LukeTowers here you go:
https://github.com/rainlab/translate-plugin/pull/339

[amdad]

PUSH THE BUTTON 👇 Luke :)
https://www.youtube.com/watch?v=Xu3FTEmN-eg

[daftspunk]

Fixed by https://github.com/octobercms/library/commit/16f7a286d8c90fb114d3abc9f7a51218c414c1f7

This will be available in core build 433+

[daftspunk]

"legacy" will stay forever in core?

Yes it will, legacy is in the context of Laravel. For October, it is not mutually exclusive, so it should be considered the "simple" event, referring an event class perhaps is "advanced" event usage.