[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search

CLDR Ticket #11161(closed: fixed)

Opened 10 months ago

Last modified 4 months ago

Add wildcard locale to ST URLs

Reported by: mark Owned by: tbishop
Component: surveytool-other Data Locale:
Phase: dsub Review: mark
Weeks: Data Xpath:


In the documentation, it is often useful to point to a specific part of the Survey Tool, such as the following.


It would be useful to be able to have a link that would go to one of the user's locales. That way the users could see exactly where it is for their language, instead of having to muck with a URL, or navigate to a location with (sometimes cumbersome) instructions.

Maybe something like:


It could be the last locale that the user touched, or the first of their locales, or say French as a fallback.


Change History

comment:1 follow-up: ↓ 5 Changed 10 months ago by srl

if the documentation were inside of the ST page, then there could be (there isn't now) a relative URL for the *current* locale.

comment:2 follow-up: ↓ 4 Changed 9 months ago by mark

  • Owner changed from anybody to tbishop
  • Priority changed from assess to major
  • Status changed from new to accepted
  • Component changed from unknown to survey
  • Milestone changed from UNSCH to 34

comment:3 Changed 6 months ago by tbishop

  • type changed from unknown to surveytool
  • Milestone changed from 34 to 35

comment:4 in reply to: ↑ 2 Changed 6 months ago by tbishop

Replying to mark:


Probably P3...

Hi Mark, what does "P3" mean here?

comment:5 in reply to: ↑ 1 Changed 6 months ago by tbishop

Replying to srl:

if the documentation were inside of the ST page, then there could be (there isn't now) a relative URL for the *current* locale.

Hi Steven, currently the domains are st.unicode.org for ST itself, and cldr.unicode.org for Survey Tool for documentation, as in:


Are you suggesting we might move the documentation to st.unicode.org?

comment:6 Changed 4 months ago by tbishop

I'm experimenting with "USER" as a wildcard locale, keeping in mind "*" as a possible alternative.

With current code, using USER in place of locale in URL leads to ErrorCode.E_BAD_LOCALE.

I added this in SurveyAjax.validateLocale():

        if ("USER".equals(loc)) {
            loc = "fr_CA";

where "fr_CA" is a placeholder for eventual user-dependent locale. It's then necessary also to do something like this with toString in each of the 3 places validateLocale is called:

            l = validateLocale(out, loc);
            if (l == null) {
            loc = l.toString();

Then the server seems happy but the client complains "Cannot read property 'dir' of null" triggered by info = null here:

function setLang(node, loc) {
	var info = locInfo(loc);

		node.dir = overridedir;
	} else if (info.dir) {
		node.dir = info.dir;

locInfo relies on window.surveyCurrentLocale:

function locInfo(loc) {
	if(!loc) {
		loc = window.surveyCurrentLocale;
	return locmap.getLocaleInfo(loc);

At least sometimes the client appears to get surveyCurrentLocale from the URL, rather than from the server. That needs fixing.

comment:7 Changed 4 months ago by tbishop

This works in SurveyAjax.validateLocale(), to get the first of the user's locales, or "fr" as a fallback:

        if ("USER".equals(loc) && sess != null && !sess.isEmpty()) {
            CookieSession mySession = CookieSession.retrieve(sess);
            String locales = mySession.user.locales;
            if (locales == null || "".equals(locales) || UserRegistry.isAllLocales(locales)) {
                loc = "fr";
            } else {
                String localeArray[] = UserRegistry.tokenizeLocale(locales);
                loc = localeArray.length == 0 ? "fr" : localeArray[0];

That requires adding sess as a parameter; fortunately it's already present in all 3 cases where validateLocale is called.

In survey.js, ideally we would fix surveyCurrentLocale right after this line in parseHash():

     surveyCurrentLocale = pieces[1]; // could be null

I'm not sure that's possible; do we even have a server response yet at that point to tell us the user's locale? Neither cachedJson.loc nor _thePages.loc is defined at that point, at least not always. Instead, we can fix surveyCurrentLocale here as follows:

    myLoad(xurl, "initial menus for " + surveyCurrentLocale, function(json) {
      if (surveyCurrentLocale === "USER" && json.loc) {
        surveyCurrentLocale = json.loc;

setLang also needs fixing. Ideally it would never get info = null, but I'm not sure that's preventable. If instead we simply avoid accessing info.dir if info is null, we get good results eventually. Logging in as a user for locale "zh", and pasting this url in the browser,


it magically transforms into


comment:8 Changed 4 months ago by tbishop

Now this works:


You have to be logged in for it to redirect to your locale.

I had to clear the browser cache to use the latest survey.js.

Last edited 4 months ago by tbishop (previous) (diff)

comment:9 Changed 4 months ago by tbishop

  • Status changed from accepted to reviewing
  • Review set to mark

comment:10 Changed 4 months ago by mark

  • Status changed from reviewing to closed
  • Resolution set to fixed

Add a comment

Modify Ticket

as closed
Next status will be 'new'
Next status will be 'closed'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.