Forecast IO 5 day layout language BUG? (+ understanding duration)


I’m trying to integrate the forecast IO widget in my layout, mostly successfully, but I’m encountering some problems with the day names language displayed in short and long format.
Tried to fix by myself by looking directly at the code, without success. I found several files in my xibo installation where day name are hardcoded in english, but I don’t know which one is really used by forecast IO widget if even used at all.

Problem is very simple: I want in the 5 days layout (or any layout with day names) have the day names displayed in selected language (I’m actually using french).
The setting in forecast IO widget for selecting language is working properly for the summary, it’s indeed displayed in french, but day names stays definitively in english whatever the selected language (tried several others language, it’s the same behavior).
Example of expected behavior :
Wed > Mer
Wednesday > Mercredi

I guess this is a bug or it haven’t been yet fully implemented by the team for others language ?
What do I have to edit/modify to translate this locally ?

Any help or hint will be greatly appreciated,

By the way, thank you for this so useful open source free software, you guys are wonderful to spend so much time on this despite some bugs here and there and some…well…strange behavior/concepts (referring to another topic where I learned that all regions will ONLY refresh at the end of the longest one, I always thought that regions were totally independent like some kind of multitasking which would be ideal --consider this like a feature request-- :wink:) but please don’t take it bad. I know how much it is difficult to lead a so ambitious project generally speaking.
I’m also encountering another bug with an embedded page displaying a slideshow (memory leak from .Net player or a resource used by the player ?), but, well, it will be another more detailed topic since I’m still investigating.

Thank you very much,
Best Regards.

You clearly didn’t read that properly then! :imp:

All regions are independent of each other and show their content regardless of what any other region is doing. There’s one exception to that which is where there’s a region with only one media item in it.

For example, a layout setup like this:

Layout A
Region 1: Image 1 (10s), Image 2 (10s)
Region 2: Text 1 (5s), Text 2 (2s)

When that runs, region 1 will show Image 1 then Image 2 because it’s the longest running region on the layout. When that finishes, the whole layout will reload and start again. Region 2 will show Text 1, Text 2, Text 1, Text 2 over and over UNTIL Region 1 completes (after 20 seconds) and then it will stop and the whole layout will reload.

The only exception to that is a layout such as

Layout B
Region 1: Image (10s)
Region 2: Text 1 (10s), Text 2 (10s)

In this case, Region 2 is the longest running region but since region 1 only has one media item in it, when the layout plays the image in region 1 will show once and remain on the layout until Region 2 completes (as if it had a duration of 20 seconds). That’s really a powerful feature. You may choose to call it a strange concept because you don’t understand it, but consider this layout:

Layout C
Region 1: Clock (10s)
Region 2: Weather (10s)
Region 3: Video (0s)

When this layout runs, the clock and the weather will come up on the layout and remain there until the video finishes, with no ugly flashing or refreshing. The 0 duration on the video means that the Player will just play the video until it finishes, so we don’t know at this point how long that duration will be. Without this “strange concept”, you would have to manually edit the Clock and Weather items each time you changed that video such that they had the same duration, otherwise they wouldn’t stay on the layout.

The problem gets worse when you consider things like tickers that can have a duration per item - so an RSS feed that gets shorter and longer could have a duration of 3s per item so you could then never design a layout that worked properly.

We have thought about this stuff! It’s not just arbritrary “strange concepts” because we love explaining it over and over to people!


What have you tried so far in your template?

[time|D] should give you the 3 letter day abbreviation, and [time|l] should give you the full name. For date/time language support you’d need to ensure your PHP installation was set up for this: International Date Formatting and that your language locale is available.

You must also have the “international date format” setting switched on:

Hello Dan,

I have tried the supplied default 5 day template with both [time|D] and [time|l] for testing :

<div class="day">
  <div class="currentDay">
    <div class="day-icon"><i class="wi [wicon]"></i></div>
    <hr class="day-icon-seperator">
    <div class="weekday">[time|l]</div>
    <div class="maxTemp"><span class="temp">[temperatureMaxFloor]</span>°<span class="unitTemp">C</span></div>
    <div class="weekday-short">[time|D]</div>

Thanks for your precious information, php-intl was indeed NOT installed, that did partially the trick.
I simply didn’t not know that this extension was a requirement and used for the translation.
Please consider to add it to the installation/report fault requirements check list as well as php-curl which is required for forecast IO. I think It will prevent some people to bother you like I did.

So after install, I did some basic check, ICU libraries seems to be already installed :

php -i | grep ICU
ICU version =>
ICU Data version => 4.8.1

Intl extension is loaded :

php -m


And I can test it with this grabbed code :

$formatter = new NumberFormatter('fr_FR', NumberFormatter::CURRENCY);
echo $formatter->getTextAttribute(NumberFormatter::CURRENCY_CODE);
$formatter = new NumberFormatter('en_US', NumberFormatter::CURRENCY);
echo $formatter->getTextAttribute(NumberFormatter::CURRENCY_CODE);
$formatter = new NumberFormatter('ja_JP', NumberFormatter::CURRENCY);
echo $formatter->getTextAttribute(NumberFormatter::CURRENCY_CODE);

Which display :


Another test code grabbed from the net :

echo IntlDateFormatter::create('fr_FR', IntlDateFormatter::FULL, IntlDateFormatter::FULL)->format(time(time())) . "\n";
echo IntlDateFormatter::create('fr_FR', IntlDateFormatter::MEDIUM,ntlDateFormatter::SHORT)->format(time(time())) . "\n";
echo IntlDateFormatter::create('en_US', IntlDateFormatter::FULL, IntlDateFormatter::FULL)->format(time(time())) . "\n";
echo IntlDateFormatter::create('en_US', IntlDateFormatter::MEDIUM, IntlDateFormatter::SHORT)->format(time(time())) . "\n";

Which outputs :

mercredi 25 mars 2015 23:48:30 heure normale de l’Europe centrale
25 mars 2015 23:48
Wednesday, March 25, 2015 11:48:30 PM Central European Time
Mar 25, 2015 11:48 PM

But despite of these successful basic tests, when I tick “Show international dates” in settings/region and set language to fr or fr_FR in “Default Language” (I tested both since I’m not sure which one I’m supposed to use here), it still not working.

This is what I get :

And when I untick “Show international dates” :

I tried to set language in php.ini just in case language selection was not passed properly but same result :

intl.default_locale = fr_FR

What I am missing ?

About server, it’s a debian 7.8 recently installed. PHP has not been particularly modded.

Thank you for your help.

Hi Alex,

Thank you for your very instructive answer.
I will try to better understand.

So, could you tell me what would be expected in this scenario please ?

Region 1: Forecast IO (3600s), Forecast IO (3600s)
Region 2: Clock (86400s)
Region 3: Webpage - pictures slideshow - (86400s)
Region 4: Ticker 1 (360s), Ticker 2 (360s), Ticker 3 (360s),Ticker 4 (360s)

Thank you

Region 1 will load the weather forecast and it will remain on the screen for 1 hour, then it will refresh with new data and be shown again for another hour and continue to do so for the duration of the rest of the layout. Note you could achieve the same thing by adding one Forecast media type and ticking the region loop box (assuming Xibo for Android clients)

Region 2 will load the clock and it will remain there for 24 hours. Clocks update internally so there’s no need to refresh it

Region 3 will load the slideshow and show it for 24 hours, regardless of any changes to the external webpage on the remote server

Region 4 will show Ticker 1-4 in rotation, refreshing the content each time one is shown and the cache interval on the individual ticker has elapsed (as defined on your media item).

What I’d also expect is a support case from this person saying that they’re making changes to their layout but they aren’t being reflected on the display, or that they’re scheduling a second layout but it’s not being shown.

Say that layout you describe starts running at 8am. If you added a second layout to the schedule and removed that one, then while the client may well receive that information a few minutes after you set it up in the CMS, your new content won’t be shown until 8am the following day. Equally if you don’t have the option to expire modified layouts switched on, if you made a change to the design of that layout, you would have to wait until 8am the following day for your change to be shown.

In general, use reasonably short durations as that offers much more flexibility.

Consider this layout instead:

Region 1: Forecast IO (10s)
Region 2: Clock (10s)
Region 3: Webpage - pictures slideshow - (10s)
Region 4: Ticker 1 (360s), Ticker 2 (360s), Ticker 3 (360s),Ticker 4 (360s)

It does everything your original one does, but lasts 24 minutes (which is still longer than I’d suggest but it’s the shortest duration I can get maintaining the same functionality as your example). Yes every 24 minutes the layout will reload as a whole but that’s a good thing, especially when you want to introduce more layouts.

Keep in mind that people quickly get accustomed to a fixed layout and stop reading it, because they perceive that they’ve seen it already. If you want your digital sign to get regular engagement then it’s crucial that it appears to be different each time the user engages with it.

requirements checks


I think we are going to need some extra logging to find out what the problem is - can you add something to this file.

Above line 54.

Debug::Error(sprintf('Intl Available: %d. Intl on: %d. Default Language: %s. Default Timezone: %s. Format: %s. Timestamp: %d.', Config::CheckIntlDateFormat(), Config::GetSetting('USE_INTL_DATEFORMAT'), Config::GetSetting('DEFAULT_LANGUAGE'), Config::GetSetting('DEFAULT_TIMEZONE'), $format, $timestamp));

Then load up your layout again and see what the error message in the log says.

Sorry for the late reply

Great ! Thank you

Thank for the help, as requested, I added debug code, here the result which always coming by 2 identical entries (don’t know why):

963 2015-34-30 8:: CMS DateManager getLocalDate Intl Available: 1. Intl on: 1. Default Language: fr_FR. Default Timezone: . Format: y-m-d h:i:s. Timestamp: 1427740470.
962 2015-34-30 8:: CMS DateManager getLocalDate Intl Available: 1. Intl on: 1. Default Language: fr_FR. Default Timezone: . Format: y-m-d h:i:s. Timestamp: 1427740470.

Note : could someone authorize/upgrade my forum account status to directly upload pictures please ? It will be more easy to share screen captures with you when needed.

You managed to get “basic status” already :smile: so that should allow you to do the necessary with images.

I think you will want fr not fr_FR - the international code for French - French is fr. See: ICU Demonstration - Locale Explorer

Indeed :smiley:

Unfortunately, this not the problem, this seems to only change the numbers displayed which should be names of days:

Any other suggestion ?
Does it seem for you a bug or a system configuration problem ?
Sorry for the stupid question, is it working on your test setup for french ?

Thank you

Thank again for time taken to explain it to me.
This “strange concept” becomes clearer now :wink:
As a note, I’m using the windows client.

May I suggest you to add some examples/hints/concept explanations directly in the CMS, it will prevent confused people like me to bother you again and again (in particular, the “one item” exception behavior which was really unexpected for me, and the option “Loop?” adds some confusion since it talks about not being implemented with windows client, so we wonder is the one item behavior exception is applicable when unticked? You see the point I think).
By the way, do you plan in a short term to enable the “loop” option when for windows client ?
It would be simply great and so useful. I’m really waiting for this personally.

About the new layout you submitted, I totally agree that in a multiple layout scheme it’s far better to keep short duration for dynamic changes, but for now, I only need 1 layout and need to avoid as much as possible the refresh artifacts. The only solution I found was long duration. Maybe I’m in a wrong way ?

My problem with the 24 minutes layout is the slideshow which is my main area, it will be always interrupted by refresh.
It would like to set the overall layout as static as possible (functionally, not for the content) because It’s quite annoying from the aesthetic side, it does not look professional for a public environment.
Is there any other way to achieve this ?

Thank you again for the time you are sharing here.

Yeah, I have it working here (it was broken in 1.7.1, but fixed in 1.7.2) - perhaps you would be so kind as to export your layout and send it to us - perhaps in a dropbox or similar so we can download it and try it out?

I can’t imagine why there are numbers there instead of day names!

That’s right, but you make a compromise by doing that. It’s totally your decision.

I guess, but unfortunately I don’t have really a choice to achieve this.
Sorry to ask again, but do you think the loop option as well as the layer option will be added soon to the windows client ?

Absolutely, I sent you a PM with a dropbox link.
Please keep in mind that this layout in “beta” stage :smile: , explaining the placement of some regions.
If it’s working on your setup, I suppose I’m encountering a system configuration or compatibility problem with Xibo seems INTL seems to work outside of it.
Really hope we will finally find out what’s wrong.

Edit : I just understood that numbers are…day numbers ! (90th day = march 31, etc…). That’s why It changed.
Previously, I thought numbers changed because of language code modification (fr_FR => fr) but it wasn’t.

Loop might be. Layers definitely not as the current architecture of the Windows client prevents it from working.

So I also have the problem and I know what the answer is…

Sometimes PHP drives me totally mad… usually when dates are involved in some way. Turns out the format pattern required by the International Date formatter is DIFFERENT to the format required by PHP’s other date formatting tools. So if you change to

    <div class="weekday-short">[time|eee]</div>

It will work:

1 Like


Can you please tell me how you figured out to change the following?

I would like to know how to get the full weekday after enabling the international date format.

Thank you.

EDIT: Looks to be correct: CDate Formatter

It uses ISO codes, which are also used by the popular frameworks.

Dan :

Oups, sorry for this. Well, you see what I meant :wink:
Thank you very much to have finally sorted out this php mess.
Can’t believe that the fix is “as simple as that”. lol
I totally trust you about how php can be silly, the few things I have seen give me already some headaches…

I was going to ask you if you consider this as a bug, but I noticed that you already put it in the enhancements category. That’s perfectly fine.

Thank you again for your precious time.

1 Like