André Bargull 3d58656e00 Bug 1693575 - Part 3: Implement support for "calendar" option. r=tcampbell ... This last part to support "calendar" requires a bit more code. `GetCalendarDisplayName()` performs the following steps: 1. Validate the input matches the `type` nonterminal, per CanonicalCodeForDisplayNames, step 4.a. 2. Then convert it to lower case, because ICU expects lower case names and it needs to be in lower case for `LanguageTag::replaceUnicodeExtensionType()`. 3. Replace calendar name aliases with the preferred name, e.g. use "ethioaa" instead of "ethiopic-amete-alem". 4. Check the input isn't too large, just in case ICU somehow doesn't properly handle large string inputs. 5. Retrieve the old-style value of the calendar name, for example "gregorian" for the calendar name "gregory". 6. And finally call `uldn_keyValueDisplayName` to search for the localised name. Our ICU data file doesn't yet include calendar names. To include calendar names we need to enable them in "data_filter.json", rebuild the ICU data file, and then reapply the update for tzdata 2021a. (Reapplying the tzdata changed "intl/tzdata/GIT-INFO", but otherwise didn't change any time zone files.) Adding the calendar names to the ICU data file results in a slight increase of the overall data file size (79,184 bytes). The existing "calendar.js" test file was renamed to "month-calendar.js", so the test file for the new "calendar" type can be named "calendar.js". Differential Revision: https://phabricator.services.mozilla.com/D116008		2021-06-01 07:45:44 +00:00
..
fdlibm
ffi
freetype2
icu
lgpllibs
nspr
rlbox
rlbox_lucet_sandbox
sqlite
zlib
moz.build