The WRONG Images are Showing Up in Preview and Published Versions of Content
Aug 22, 2018
I have a super baffling situation for you that I hope someone can help us with. We're also talking to Tech Support, but so far no light has been shed.
We've never seen this problem before and nothing we've tried as resolved it. We are losing our minds. The entire team of 4 people are having the same issue (all on different computers) and can't figure this out.
The situation: We have a course. We got it translated into 14 languages. We do this a lot, translate our courses. Then we publish them for clients' LMSs and deliver.
Only this time, with this one course, and its 14 language versions, when we publish a language, images that have been localized are now showing up in OTHER LANGUAGES.
When we dig into the Storyline files themselves (thinking our translation company had screwed up and put the wrong images in the wrong language files), we find that the CORRECT image files are in the correct languages. But when we PREVIEW or PUBLISH, that's when sh** hits the fan.
Here's an example:
We are so perplexed, and the client is pissed, and we don't know what to do to rectify it because nothing is working.
- The translation company can't reproduce the issue.
- Articulate tech support can't reproduce the issue.
- We've rebooted.
- We've reinstalled Articulate.
- We've redownloaded the files from the translation company.
- We've moved the files to other locations on the C drive to publish (and yes we're always working from the local C drive).
- We've imported the course into a new STL file.
- We've emptied the temp and cache files.
NOTHING has fixed the problem.
I, normally not involved in the day to day with the team, jumped in to the fray to help, thinking that since my computer has never even seen these files that it might be able to publish everything just fine. I first opened the German file, published just fine. No issues. Then I opened Turkish, and the above issues started happening.
One of the team had started with the Chinese file, and the exact same thing happened. The Chinese one published just fine. But every language she did after that showed Chinese images instead of the respective languages.
Right now, the ONLY thing that I can think to do (and that has worked) is replacing all of the translated image files in the published output folder and rezipping. This is a tedious thing to do to 14 courses that I'm hoping we can avoid, but if we have to do it for this one client, we will to get it out the door. I do NOT, however, want to have to do that forever going forward for this one course. WHY is this happening????????
I have a few questions that may or may not bear any relevance:
- when Storyline publishes a course, is it creating temp files somewhere, that it might then try to reference when publishing another course?
- why and HOW could files from one course end up in another?
- why would the preview function show something different than what's actually on the timeline?
- In the old days of Studio, with the linked files and things not being embedded, I do remember this happening if we weren't careful about about file organization and linking. But everything is supposed to be embedded in a Storyline file, so how would this even happen??
Help us Obi Wan! What is going on?!?!?
14 Replies
Hi Ashley
How frustrating for you and hard to say without seeing the files so just throwing some stuff out here...
times when I've seen this happen with mismatched images, it was a caching issue on the clients side so once we cleared their cache it worked - but seems you have looked at that.
Hi Wendy! Yes, it's super frustrating.
No, none of the images are on master slides.
A few of them do have different states, but they are all showing up as correct within the storyline file.
It's not a browser cacheing issue because we're all seeing it happen on our own computers, in different browsers, even after clearing the browser cache. And when viewing locally. (And when previewing inside of Storyline.)
Hey Matthew. STRANGE INDEED!!!
It happens when viewing locally, when previewing slides within Storyline, and when viewing in the SCORM Cloud (And when the client viewed in their LMS).
It's not a browser issue, because the actual images in the output folder are the wrong language. Somehow the WRONG images are getting pulled into the publishing process, and I do NOT understand HOW that could happen.
Follow up question for Articulate staff or those in the know: all of the files needed to publish a course are embedded in the .stl, yes? So when a course publishes, it's only referencing itself in the process, yes?
Does anyone have any ideas as to how or why it would pull other versions of files into a publish process? Even after the temp files are cleared?
Hi Ashley,
You're exactly right - the additional assets you insert into your Storyline course are connected to the .STORY file in which you added them.
I saw you were working with Vevette on this issue before, and she engaged the help of one of our Senior Support Engineers. Jon will be in touch soon with some additional testing steps, and I'll follow along. I'm really curious to get to the bottom of this one!
It is certainly confounding. We've never ever seen something like this, and it is ONLY happening with one course and its language versions. NONE of our other courses are doing it. We've spent the last two days troubleshooting, experimenting, trying literally every single thing we can think of, and nothing works......
EXCEPT we found another computer in the office that still has an older version of Storyline (3.6.11) and that one published things properly. We do not understand at all. That would lead me to believe the problem is not with the FILES but something with the computers, or the temp/preview/publish files saved somewhere on the other 4 computers where we are experiencing this issue.
Besides the AppData > Roaming etc location where we can delete temp files, does Storyline save temp/preview files anywhere else that might be getting pulled in when publishing other files?
Hi Ashley,
I saw that Jon was able to replicate it! The strangest thing, but he'll keep testing and digging into this.
Did you ever get an answer to this one? We have exactly the same problem with translations - translated text on images aren't being updated.
I think it must be because the image names are the same across translations, and Storyline is using cached versions?! I've deleted /appdata/local/articulate/360/apicache/v1 files, but still getting the issue.
Could you please confirm ASAP if there is another place where files are cached as we are two man days into debugging and have a deadline.
Hi Emma,
Thanks for reaching out, and good call to open a case! I see my teammate, Ronaziel, has replied with a request for copies of the affected files.
Be sure to reply so she can do some further digging and get to the root of the issue. You're in great hands, and I'll follow along to share any relevant insight here!
Hi Ren,
We didn't really get any resolution via the support team as there seems to be a denial regarding the caching issue. Instead we found a workaround which required us to name the images differently across languages (which proves it was caching issue after all).
Kind regards,
Hi Emma!
Thanks for sharing the workaround! I see that Ronaziel offered to look into the files to continue investigating. If you still need assistance, please don't hesitate to reach out.
Hi all,
I just had to struggle with a very similar problem that I could only solve by exporting one Storyline file when having another Storyline file open at the same time.
In my case, there was an image showing up from another file in the exported SCORM. I guess, the cache was stuck with an asset from a previous file (however this might have come together). So, opening both files and saving one of them has done it for me.
Hope this helps in some way!
Best regards
Paul
Please check the below link.
https://community.articulate.com/discussions/articulate-storyline/storyline-360-unusual-caching-issue-when-publishing
Thanks for popping in to help here, Amit. Welcome to E-Learning Heroes! 😊