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

CLDR Ticket #7557(accepted tools)

Opened 4 years ago

Last modified 2 years ago

Optimize sublocale menu [only branch]

Reported by: mark Owned by: srl
Component: survey Data Locale:
Phase: dsub Review:
Weeks: Data Xpath:



  1. In the vast majority of cases, the sublocales will all have the same value as the main locale. We could optimize that case, so that we don't have to do lots of computation.
  1. I want to make sure that the computation for the sublocales is using the unresolved locales, since that will be much faster.
  1. Because the sublocales don't change much, we could even cache those paths that are different, and only look at them.
  1. I think it might be cleaner and easier for users to have a table of values, and a pulldown of the locales that have those values. But that's clearly not in the cards for v25.


select_current.PNG (10.6 KB) - added by tomzhang 4 years ago.
select_other.PNG (24.9 KB) - added by tomzhang 4 years ago.

Change History

comment:1 Changed 4 years ago by srl

  • Xref set to 7459

merge into #7459

comment:2 Changed 4 years ago by emmons

  • Owner changed from anybody to tomzhang
  • Priority changed from assess to minor
  • Type changed from unknown to defect
  • Status changed from new to assigned
  • Milestone changed from UNSCH to 26rc

comment:3 Changed 4 years ago by tomzhang

  • Milestone changed from 26rc to 27dvet

comment:4 Changed 4 years ago by tomzhang

  • Status changed from assigned to reviewing
  • Review set to srl

This is done on the branch, and someone may check it for V27. The overall change set is http://unicode.org/cldr/trac/changeset?old_path=%2Fbranches%2Ftomzhang%2Fsideway_optimize&old=10698&new_path=%2Fbranches%2Ftomzhang%2Fsideway_optimize&new=10870. I have tested, and debugged all problems(client-server) I have seen. But chances are new problems may be detected with many users. So I propose the code is checked.

The summary starts by answering all questions:

  1. JSON is stored as key(value)-value(locale) pairs, so there is no comparisons between locales with the same value. For those locales whose values inherited from root locale, they are all stored in noValue array in JSON. And further with new JSON object, it is now directly merged into main locale.
  2. Yes, locale values are using unresolved XMLSource
  3. Now I implemented both client & server cache. Client side: users will store its sideway table contents and resume if possible. Server side: the right JSON object is cached in STFactory class. And except the 1st time, all main/sub locales will get the cached JSON object and manipulate the changed value.
  4. I did have a table showing different values now, and the current value/locale will have sepcial marks on it. The display is fairly basic, but someone can tweak it if another one is preferred.

There are 2 potential problems I want to point out:

1st problem: This may be a BUG: the sideway table may have incorrect highlight for current value/locales for a short time. Here is the reproduction:

  1. transfer to another locale.
  2. change its value before sideway table loaded (~ 2 seconds)
  3. table may not have the correct highlight at the 1st time

The reason for this is client-cache is not update-to-date and so is class attribute. Three key factors I should mentions for this bug:

  1. It requires users to update quickly (~ 2 seconds) before the sideway table is updated.
  2. Even though the user sees the wrong one, the table is updated after ~ 2 seconds. It is the time when another AJAX call is invoked and the table is updated.
  3. If the above 2 investigations are still not sufficient, there is a function “clearCurrentClasses” defined in survey.js. It definition/usage has been commented out for efficiency purpose(need to remove usefull classes through the table). Enabling that will solve the problem

2nd problem: The client cache may not be optimal when users change the current value.
In short, there is preprocess json and create a brand new table if server cache is used. With client cache, all these works can be eliminated. But the efficiency problems occur for manipulating the table(find the right class/id, especially sometimes it has not been attached). And “different” client cache may be error-prone if used carelessly. I mentioned the problem here in case anyone has a good preference/idea on improvement.(or maybe switch back to use server cache entirely)

Changed 4 years ago by tomzhang

Changed 4 years ago by tomzhang

comment:5 Changed 4 years ago by srl

  • Status changed from reviewing to accepted

comment:6 Changed 4 years ago by srl

  • Milestone changed from 27dvet to 27dsub

TODO: review branch, merge in as appropriate.

comment:7 Changed 4 years ago by markus

  • Phase set to dsub
  • Milestone changed from 27dsub to 27

comment:8 Changed 4 years ago by srl

  • Owner changed from tomzhang to srl
  • Status changed from accepted to assigned

Steven to review code on branch, merge in as needed

comment:9 Changed 3 years ago by srl

  • Milestone changed from 27 to 28


comment:10 Changed 3 years ago by srl

  • Status changed from assigned to accepted

comment:11 Changed 3 years ago by emmons

  • Type changed from defect to tools
  • Component changed from unknown to survey

comment:12 Changed 3 years ago by emmons

  • Milestone changed from 28 to 29

Moving all survey related to 29dsub

comment:13 Changed 3 years ago by emmons

  • Milestone changed from 29 to upcoming

Auto move of all 29 -> upcoming

comment:14 Changed 2 years ago by mark

  • Review srl deleted
  • Summary changed from Optimize sublocale menu to Optimize sublocale menu [only branch]

Add a comment

Modify Ticket

as accepted

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

Note: See TracTickets for help on using tickets.