Opened on 09/04/2015 at 01:38:44 PM

Closed on 03/08/2016 at 02:28:11 PM

#2992 closed defect (fixed)

[CMS] Animation XML files not generated for non English languages

Reported by: SMed79 Assignee: kzar
Priority: P3 Milestone:
Module: Sitescripts Keywords: cms
Cc: saroyanm, greiner, matze, kzar, sebastian Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by kzar)

How to reproduce

  1. Go to
  2. Click Me montrer comment faire link to play the animation.

Observed behaviour

No animation is played because the background request to returns 404.

Expected behaviour

The animation should play and the XML file should be returned successfully.

(For an example of what it should look like start the CMS test server locally and then browse to http://localhost:5000/fr/faq_basics and http://localhost:5000/fr/animations/blockbanner.xml )


Attachments (0)

Change History (20)

comment:1 Changed on 09/04/2015 at 02:01:04 PM by mapx

  • Cc saroyanm added

comment:2 Changed on 09/07/2015 at 10:24:19 AM by greiner

  • Cc greiner added
  • Component changed from Unknown to Websites

The issue appears to be that the XML is located under a language-specific URL (e.g. /en/animations/blockbanner.xml) but that there are no versions of those in other languages. Therefore there should be a fallback to english if there is no translated version of a resource, similar to how texts fall back to their base text if they're not translated.

Note that this also applies to other similar XML files.

We should also find out whether there have been translated versions of those before migrating from Anwiki and recover them.

comment:3 Changed on 11/26/2015 at 05:53:20 PM by saroyanm

  • Priority changed from Unknown to P3
  • Ready set

comment:4 Changed on 03/01/2016 at 02:41:10 PM by juliandoucette

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:5 Changed on 03/01/2016 at 02:44:52 PM by juliandoucette

  • Owner set to juliandoucette

comment:6 Changed on 03/07/2016 at 04:37:46 PM by kzar

  • Cc matze added
  • Component changed from Websites to Infrastructure
  • Summary changed from link errors on FAQ - Basic functionality. to Animations not playing for non English languages

I think this might actually be an infrastructure issue. When using the CMS test server everything works properly, but I can also reproduce the problem as described when playing animations on the live site.

What do you think Matze, possible problem with the Nginx config for

I expect it to behave as follows:

But currently both return 404 instead.

comment:7 Changed on 03/07/2016 at 04:39:15 PM by kzar

  • Cc kzar added

comment:8 Changed on 03/07/2016 at 04:51:31 PM by juliandoucette

I agree that it would be better to solve this problem with infrastructure.

comment:9 Changed on 03/07/2016 at 04:52:12 PM by juliandoucette

  • Owner juliandoucette deleted

comment:10 Changed on 03/07/2016 at 04:52:25 PM by juliandoucette

  • Status changed from reviewing to reopened

comment:11 Changed on 03/07/2016 at 07:47:56 PM by matze

  • Component changed from Infrastructure to Unknown

While looking into this issue I found another one that may create some confusion in this context, so I set up a distinct ticket (#3750). However, the issue described in this very ticket here seems to be no defect in infrastructure:

There is no fr version generated from blockbanner.xml.tmpl in the current state, en only. I am not even sure if the currently intended approach (creating localized content from a template) is even properly supported by the CMS software at this point.

Also, the /xx/foo to /en/foo fallback is explicitly not included in the requested feature set for the httpd configuration, only the canonical /foo is language-sensitive and behaves in that manner. Both as well as are consistent in their behavior, just as intended.

As soon as you've clarified this issue, feel free to request updates or the introduction of additional behavior when you believe they are necessary.

comment:12 Changed on 03/08/2016 at 11:13:23 AM by saroyanm

I also don't think this is related to infrastructure, I'm currently investigating the issue, but when I generate content locally I also miss animation in the localization, could be that it's also related to CMS will keep updated.

comment:13 follow-up: Changed on 03/08/2016 at 01:28:43 PM by kzar

  • Cc sebastian added
  • Component changed from Unknown to Sitescripts
  • Description modified (diff)
  • Keywords cms added
  • Priority changed from P3 to Unknown
  • Review URL(s) modified (diff)
  • Summary changed from Animations not playing for non English languages to [CMS] Animation XML files not generated for non English languages

You're both right, those files aren't actually being generated by cms.bin.generate_static_pages at all. Appears to be a CMS issue instead of a problem with the Nginx config.

comment:14 Changed on 03/08/2016 at 01:31:19 PM by kzar

  • Ready unset

comment:15 in reply to: ↑ 13 Changed on 03/08/2016 at 01:42:10 PM by saroyanm

Replying to kzar:

You're both right, those files aren't actually being generated by cms.bin.generate_static_pages at all. Appears to be a CMS issue instead of a problem with the Nginx config.

Yes, because seems like currently we only generate the content when there is a corresponding locale, somehow we need to be sure that test script and CMS behave in similar way, also not sure if it's a good idea to generate pages for locales that are not exist, we need to be sure that linkify function will still return original version for the translations that do not exist yet.

comment:16 Changed on 03/08/2016 at 01:59:43 PM by kzar

  • Owner set to kzar

comment:17 Changed on 03/08/2016 at 02:21:47 PM by kzar

  • Review URL(s) modified (diff)

Yes you're right. While the translation_ratio for a page is considered 1 for pages with no strings we were accidentally omitting them from the page list anyway.

comment:18 Changed on 03/08/2016 at 02:22:06 PM by kzar

  • Status changed from reopened to reviewing

comment:19 Changed on 03/08/2016 at 02:26:08 PM by abpbot

A commit referencing this issue has landed:

comment:20 Changed on 03/08/2016 at 02:28:11 PM by kzar

  • Priority changed from Unknown to P3
  • Ready set
  • Resolution set to fixed
  • Status changed from reviewing to closed

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from kzar.
Note: See TracTickets for help on using tickets.