Our Japanese partner reported a bug introduced in JIRA 3.11 in the Japanese version of JIRA to do with the date picker popup not functioning correctly. The bug was caused by some javascript missing, which is something we’d fixed quite a while ago. In particular the following bits of setup for the Calendar were missing:

// the following is to inform that "%s" is to be the first day of week
// %s will be replaced with the day name.
Calendar._TT["DAY_FIRST"] = "Display %s first";
// This may be locale-dependent.  It specifies the week-end days, as an array
// of comma-separated numbers.  The numbers are from 0 to 6: 0 means Sunday, 1
// means Monday, etc.
Calendar._TT["WEEKEND"] = "0,6";

Depending on the language, JIRA will include a different calendar language file. For Japanese this is calendar-ja.js. Both JIRA 3.10 and 3.11 had these properties missing in their Japanese language files. We’ve cleaned up all of this for 3.12 such that the language files now include the properties above.
So how did things work in JIRA 3.10?


Our header.jsp contained the following javascript include:

<webwork:if test="/hasCalendarTranslationForLanguage == true">
<script type="text/javascript" src="<%= webResourceManager.getStaticResourcePrefix() %>/includes/js/calendar/calendar.js"></script>
<script type="text/javascript" src="<%= webResourceManager.getStaticResourcePrefix() %>/includes/js/calendar/lang/<webwork:property value="/calendarTranslationFilenameForLanguage"/>"></script>
<script type="text/javascript" src="<%= webResourceManager.getStaticResourcePrefix() %>/includes/js/calendar/calendar-setup.js"></script>
<script type="text/javascript">
// Hack to avoid bug in jscalendar - JRA-7713
            if (!Calendar._TT["WEEKEND"]) { Calendar._TT["WEEKEND"] = "0,6";}
if (!Calendar._TT["DAY_FIRST"]) { Calendar._TT["DAY_FIRST"] = "Display %s first";}
</script>
</webwork:if>

There was a nice little hack at the end to add the required properties if they hadn’t been set yet.
Now the fact that this was defined in header.jsp meant that this was loaded on every single page in JIRA. We introduced a lot of performance improvements to page load times in JIRA 3.11, which resulted in the calendar being converted to a web-resource that could be included on demand. In order to do so, we created a calendar-language.jsp (mapped from calendar-language.js via web.xml) that would dynamically include the correct calendar-[LOCALE].js file depending on the language set in JIRA:

<%@ page import="com.atlassian.jira.web.action.util.CalendarLanguageUtil,
com.atlassian.jira.ComponentManager,
com.atlassian.jira.web.bean.I18nBean,
com.atlassian.plugin.webresource.WebResourceManager"%><%@ page import="com.atlassian.jira.util.velocity.VelocityRequestContextFactory"%><%@ page contentType="text/javascript" %><%
// @HACK.  In atlassian-plugins 0.9 you can specify non-cached resources.
                 // When we upgrade to plugins 0.9, remove this hack.
                 response.setHeader("Cache-Control", "private");
response.setDateHeader("Expires", -1);
// end @HACK

response.setContentType("text/javascript"); %>
// Hack to avoid bug in jscalendar - JRA-7713
Calendar._TT = {};
Calendar._TT["WEEKEND"] = "0,6";
Calendar._TT["DAY_FIRST"] = "Display %s first";
<%
VelocityRequestContextFactory.cacheVelocityRequestContext(request); //this is needed so that the staticResourcePrefix below uses a relative path instead of absolute

CalendarLanguageUtil calLangUtil = (CalendarLanguageUtil) ComponentManager.getInstance().getContainer() .getComponentInstanceOfType(CalendarLanguageUtil.class);
I18nBean i18nBean = ComponentManager.getInstance().getJiraAuthenticationContext().getI18nBean();
WebResourceManager webResourceManager = ComponentManager.getInstance().getWebResourceManager();
if (calLangUtil.hasTranslationForLanguage(i18nBean.getLocale().getLanguage()))  { // include the specific language javascript
%>document.write('<script type="text/javascript" src="<%= webResourceManager.getStaticResourcePrefix() %>/includes/js/calendar/lang/<%= calLangUtil.getCalendarFilenameForLanguage(i18nBean.getLocale().getLanguage()) %>"></script>');
<% } %>

That’s all fine, except the only problem is that the WEEKEND and DAY_FIRST properties were added before the language specific javascript file was included. The language specific javascript files all reset the _TT={} variable before setting their own properties, which means that the two properties set above were being lost. I guess the lesson to take away from this is that when dealing with javascript order is quite important as a variable can be re-set or edited pretty much anywhere in your scripts.
At least only Japanese seems to be affected by this bug, as it is the only language that doesn’t explicitly set WEEKDAY and DAY_FIRST in its calendar_ja.js file. This bug has now been fixed for JIRA 3.12 and all the little hacks have been cleaned up properly.

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now