From c55d0f9bb4ac8e230f1861d520a6956a50fed597 Mon Sep 17 00:00:00 2001 From: Chris Pyle Date: Thu, 4 Jul 2024 12:45:37 -0400 Subject: [PATCH 1/3] CLDR-17566 initial text and md files --- docs/site/TEMP-TEXT-FILES/change-to-sites.txt | 38 +++ ...support-intercalary-months-year-cycles.txt | 179 +++++++++++ .../TEMP-TEXT-FILES/consistent-casing.txt | 79 +++++ .../TEMP-TEXT-FILES/coverage-revision.txt | 34 ++ .../currency-code-fallback.txt | 17 + .../design-proposals/change-to-sites.md | 82 +++++ ...-support-intercalary-months-year-cycles.md | 299 ++++++++++++++++++ .../design-proposals/consistent-casing.md | 157 +++++++++ .../design-proposals/coverage-revision.md | 64 ++++ .../currency-code-fallback.md | 34 ++ .../site/images/design-proposals/site_bug.png | Bin 0 -> 143324 bytes 11 files changed, 983 insertions(+) create mode 100644 docs/site/TEMP-TEXT-FILES/change-to-sites.txt create mode 100644 docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt create mode 100644 docs/site/TEMP-TEXT-FILES/consistent-casing.txt create mode 100644 docs/site/TEMP-TEXT-FILES/coverage-revision.txt create mode 100644 docs/site/TEMP-TEXT-FILES/currency-code-fallback.txt create mode 100644 docs/site/development/development-process/design-proposals/change-to-sites.md create mode 100644 docs/site/development/development-process/design-proposals/chinese-and-other-calendar-support-intercalary-months-year-cycles.md create mode 100644 docs/site/development/development-process/design-proposals/consistent-casing.md create mode 100644 docs/site/development/development-process/design-proposals/coverage-revision.md create mode 100644 docs/site/development/development-process/design-proposals/currency-code-fallback.md create mode 100644 docs/site/images/design-proposals/site_bug.png diff --git a/docs/site/TEMP-TEXT-FILES/change-to-sites.txt b/docs/site/TEMP-TEXT-FILES/change-to-sites.txt new file mode 100644 index 00000000000..a44dffd5759 --- /dev/null +++ b/docs/site/TEMP-TEXT-FILES/change-to-sites.txt @@ -0,0 +1,38 @@ +Change to Sites? +We are using Sites (http://cldr.unicode.org/) to host all of the CLDR development web pages. I took a look at the cldr pages, and the following are not in Sites. The question is, should we move them (or some of them) to Sites? +Advantages +Removing a bottleneck. Even though we have them in CVS (so the project people can edit the repository copies of them), we have a bottleneck in that only a small number of people (Rick, Steven, and me) can actually post them up publicly. +Editing doesn't require an HTML editor. +Disadvantages +The look and feel is somewhat different than the regular Unicode site (although we should be able to make it closer over time). +Files +http://www.unicode.org/cldr/beta.html +http://www.unicode.org/cldr/comparison_charts.html +http://www.unicode.org/cldr/corrigenda.html +http://www.unicode.org/cldr/index.html +http://www.unicode.org/cldr/filing_bug_reports.html +http://www.unicode.org/cldr/locale_faq.html +http://www.unicode.org/cldr/process.html +http://www.unicode.org/cldr/transliteration_guidelines.html +http://www.unicode.org/cldr/terms.html +http://www.unicode.org/cldr/survey_tool.html +http://www.unicode.org/cldr/repository_access.html +http://www.unicode.org/cldr/version/ (version pages) +Here are the other files: +Special purpose, for redirecting. +http://www.unicode.org/cldr/header.html +Old or temporary page: +http://www.unicode.org/cldr/readme.txt +http://www.unicode.org/cldr/press.html +Already redirect, some to Docs pages +http://www.unicode.org/cldr/big_red_switch.html +http://www.unicode.org/cldr/charts.html +http://www.unicode.org/cldr/data_formats.html +http://www.unicode.org/cldr/errata.html +http://www.unicode.org/cldr/procedures.html +http://www.unicode.org/cldr/tr35.html +http://www.unicode.org/cldr/timezone_ids.html +http://www.unicode.org/cldr/survey_tool_known_bugs.html +http://www.unicode.org/cldr/vetting.html +http://www.unicode.org/cldr/xmlGuide.html +Possible Bug - needs investigation. \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt b/docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt new file mode 100644 index 00000000000..fae7c96487a --- /dev/null +++ b/docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt @@ -0,0 +1,179 @@ +Chinese (and other) calendar support, intercalary months, year cycles +Currently the ICU Calendar object has basic support for the Chinese calendar (can determine era, year number, month, etc.). However, real date formatting using this calendar is blocked until CLDR adds necessary support for formatting Chinese calendar dates. In doing this, we need to take into account other calendars that may have similar issues, which we should support in a unified way. The intent here is to provide the minimum change necessary to support the Chinese calendar (and other luni-solar calendars) at the same level as other calendars are currently supported; support for additional special calendar features requiring significant enhancements to the ICU Calendar object (see below) is for future enhancements. +A. Relevant calendar features +Salient features of the Chinese calendar, and related features of other calendars: +1. Chinese luni-solar calendar +Months begin at a new moon and are 29 or 30 days long. +A year consists of 12 or 13 months (determined by the number of new moons between winter solstices). Months are numbered 1-12. When an extra intercalary month is needed, it might be inserted after any of the standard months 2-11 (after 11 is unusual); it repeats the numbering of the preceding month, with an extra marker to indicate that it is a leap month (in Chinese this marker ‘闰’ precedes the month number). An astronomical rule determines whether and where it gets inserted in a given year. The winter solstice always occurs during month 11, so the new year (and month 1) usually begins on the second new moon after that (Unless month 11 has a leap month added). +Astronomical calculations are based on a meridian of 120° (near Beijing). +Years are named using a 60-year cycle. The year name is formed by combining a celestial stem from a 10-year cycle and an earthly branch from a 12-year cycle. The 12 earthly branches correspond to, but do not have the same names as, the 12 zodiac animals associated with them. For example: +Celestial stems: 甲 jiǎ, 乙 yǐ, 丙 bǐng, 丁 dīng, … +Earthly branches: 子 zǐ, 丑 chǒu, 寅 yín, 卯 mǎo, … +Zodiac animals: 鼠 Rat, 牛 Ox, 虎 Tiger, 兔 Rabbit, … +First years of 60-year cycle: 甲子 jiǎ-zǐ, 乙丑 yǐ-chǒu, 丙寅 bǐng-yín, 丁卯 dīng-mǎo, … +In principle each cycle can be treated as a separate era. However, such eras are not normally ever used in formatted dates, leading to potential ambiguity about which date is being represented. Traditionally this ambiguity could be resolved by also displaying a regnal period or regnal year along with the Chinese calendar date. In modern times this ambiguity is normally resolved by always displaying a Chinese calendar date in conjunction with a date (or at least a year) in at least one other calendar. In Taiwan this other calendar is typically the Minguo/ROC calendar; in Japan it is typically the Japanese calendar; in mainland China and elsewhere it is typically the Gregorian calendar (for a format like “y年U年MMMd日” where y is the Gregorian year and U is the stem-branch name). Note that the year transitions of the associated calendar do not occur at the same time as the year transitions of the Chinese calendar. +There are at least two standard conventions for the epoch of the Chinese calendar — i.e. when was year 1 of era 1. Both are associated with the legendary emperor Huangdi 黃帝, hence the "Huangdi era" 黃帝紀元. The most common convention is to use the beginning of Huangdi's reign, commonly specified as 2697 BCE; a somewhat less common convention (and the one used by ICU) is to use the year when he supposedly invented the Chinese calendar, 2637 BCE. Since the latter is 60 years later, the stem-branch names associated with years do not change, but the cycle number is different. For some usages among calendar specialists Chinese calendar years may be numbered continuously from the beginning of the epoch, in which case Gregorian 2012 Jan. 23 is the beginning of Chinese calendar year 4650 or 4710 depending on which convention is used. However this kind of year numbering is not widely known. +In Chinese the days of the month have special numbering. Days 1-10 use 初一, 初二, … 初十. For days 21-29 the number is formed using 廿 instead of 二十 to indicate 20. The first month is designated 正月 instead of 一月. +2. Other calendars related to the Chinese calendar (Japanese, Korean, Vietnamese) +Similar luni-solar calendars are used in Japanese, Korean, and Vietnamese, with the computations based respectively on meridians near Tokyo, Seoul, and Hanoi. For the Japanese version, the date typically used for disambiguation would be a Japanese calendar date, not a Gregorian date. The Vietnamese calendar uses a different set of animals for the branch names in years, and the marker for intercalary month is inserted *after* the month name, not before. +3. Hebrew calendar +The Hebrew calendar is another luni-solar calendar, with months of 29 or 30 days beginning at a new moon. Intercalary months are inserted during specific years of a 19-year cycle, always by doubling the month of Adar: A leap year has months Adar I and Adar II (Adar I is considered to be the extra inserted month). +Month numbering is interesting. Traditionally, the month of Nisan was numbered 1, and Adar was 12 (thus Adar I and II were 12 and 13). However, this puts the month of Tishri, which begins with the new year (Rosh HaShanah), as month 7. A more modern numbering has Tishri as month 1 (to coincide with the new year) which leads to different schemes for numbering Adar and the subsequent months (see discussion below on what ICU does). +4. Coptic and Ethiopic solar calendars +These always have 13 months; 12 months of 30 days each and a 13th month of 5 days (6 in a leap year). There is no leap month per se. +5. Hindu luni-solar calendar (old or new, with several variants): +Months are 29 or 30 days, beginning at new moon (south India) or full moon (north India). Months are named based on which zodiac sign the sun transits into during the course of the lunar month. An intercalary month occurs when the sun does not transit into a zodiac sign during the lunar month, and it takes the name for the zodiac transit of the following month with a marker to indicate “extra”/“added”; the following month *also* takes a marker to indicate “original”/”regular”/”clean” (a bit like Adar I and Adar II, except that it can apply to any month). If the sun transits into two zodiac signs during a lunar month, then two months are collapsed into one; the resulting month takes the name associated with both zodiac signs, with a marker indicating “lost”. A year when this occurs must also have at least one added month, since the year must have 12 or 13 lunar months. Occasionally an added month with no transits is immediately followed by a collapsed month with two; in this case the first month takes the name of the first transit in the second month plus the marker “extra”/“added”, while the second month takes the names of both transits plus the marker “lost”. +This calendar also uses a 60-year cycle of year names, but they are not derived as combinations of sub-cycle names (as with the Chinese calendar). +6. The Tibetan luni-solar calendar +The Tibetan luni-solar calendar handles months like the Hindu calendar. Two different 60-year naming cycles are in use, one derived from the Chinese calendar and one derived from the Hindu calendar. In addition, three different cardinal year numbering schemes are used, with three different epochs (like the distinction between ethiopic and ethiopic-amete-alem calendars). +B. Other features of the Chinese calendar, not for this proposal +The Chinese calendar divides the solar year into 24 solar terms— 12 major terms and 12 minor terms—each associated with divisions along the sun’s course through the zodiac. These are usually shown on printed calendars, and are used for agriculture and astrological purposes. The data could be derived from existing calendar fields, or a new field could be added. +Months and days are also named in cycles of 60 using the stem-branch names, and days are subdivided into 12 two-hour periods named according to the earthly branches. The combination of year name, month, day name and day period name (年月日時) is important for many purposes, including picking children’s names and arranging weddings, moves, travel, and funerals. This data could also be derived from existing calendar fields, or a new field added. +Festivals and holidays are shown on printed Chinese calendars, as well as on many other calendars. ICU4J has a preliminary framework for holiday support. ICU4C does not, and there is currently no commitment in ICU to move this along. Support for marking festivals and holidays is thus beyond the scope of this proposal. +Nothing in this proposal prevents or makes more difficult adding any of these other features later on; this proposal just focuses on features that can be implemented in the near term. +C. ICU behavior +Here is how ICU currently handles the calendar behaviors above: +1. Chinese calendar +Months are numbered 0-11 (the zero-based value of UCAL_MONTH). When an intercalary month is added, it has the same number as the preceding month, but the value of UCAL_IS_LEAP_MONTH is 1 instead of 0 (this seems to be the only supported calendar that ever sets UCAL_IS_LEAP_MONTH to anything other than 0). +For purposes of add and set operations, month is treated as a tuple represented by UCAL_MONTH and UCAL_IS_LEAP_MONTH. If UCAL_IS_LEAP_MONTH is 0 for a month that has a leap month following, then adding 1 month, or setting UCAL_IS_LEAP_MONTH to 1, sets the calendar to the leap month (which has the same value for UCAL_MONTH). If a month does not have a leap month following, then a set of UCAL_IS_LEAP_MONTH to 1 is ignored. +Years are numbered 1-60 (the value of UCAL_YEAR) for each 60-year cycle. The era is incremented for each 60-year cycle, so we are currently in era 78. +Current ICU4C formatting for the Chinese calendar is completely broken. For example, the short date format in root and zh is currently “y'x'G-Ml-d”; the result this produces for Chinese era 78, year 29, month 4 (non-leap or leap), day 2 is “29x-4-”: There is no era value or leap month indicator, and non-literal fields after the ‘l’ pattern character are skipped. +In ICU4J the existing situation is bit better. Via data in data/xml/main/root.xml, ICU inserts its own "isLeapMonth" resource into the calendar bundle for "chinese"; this provides a leapMonthMarker of "*". There is a public ChineseDateFormatSymbols subclass of DateFormatSymbols which uses the "isLeapMonth" resource, and a public ChineseDateFormat of SimpleDateFormat; using ChineseDateFormat, Chinese calendar date formats using 'G' and 'l' can be formatted and parsed successfully. +2. Hebrew calendar +In a non-leap year, months run 0-4 (for months Tishri-Shevat), skip 5 (“Adar I”), then continue 6-12 (Adar-Elul). In a leap year, 5 is not skipped (“Adar I”), and CLDR data provides an alternate “leap” name for month 6 as “Adar II”. +3. Coptic and Ethiopic calendars +Months are numbered 0-12. +4. Other calendars listed above +ICU does not currently support the Hindu, Vietnamese, or Tibetan calendars (it does support the quite different Indian Civil calendar). +D. Problems with the current ICU behavior: +For the Chinese and Hebrew calendars, there is no a priori way to know for a given year whether it is a leap year. You have to run through the dates in the year to check the behavior (and the way you have to do this depends on the calendar). +The current model for UCAL_IS_LEAP_MONTH (ICU4J) IS_LEAP_MONTH) as a boolean cannot directly indicate the "normal-month-after-leap-month" and "compressed-month" used in Hindu and Tibetan calendars. However, those special months can be inferred from looking at month data before and after the month of interest. Another alternative might be to re-interpret the IS_LEAP_MONTH field to take more than two values. +It is a bit too bad that completely different models are used for leap months in the Hebrew and Chinese calendars. It would have been nice to have a more unified model that could also support the usage in Hindu and Tibetan calendars. +Calendar::add (ucal_add) for UCAL_MONTH gives different strange results for the Hebrew and Chinese calendars. For the Hebrew calendar, in a non-leap year, adding 1 month to month 4 produces month 6. For the Chinese calendar, in a leap year, adding 1 month to month n (before a leap month) produces month n (but with IS_LEAP_MONTH set). This is similar to what happens to hours around daylight savings time transitions, except in that case there is no IS_EXTRA_HOUR field to provide disambuguation (we should add one, see below). +E. Current CLDR support +CLDR currently provides the following: +1. yeartype attribute +The yeartype attribute for month name elements allows an alternate month name to be selected for leap years (current legal values are just “standard”—the default—and “leap”). It is only used for the Hebrew calendar, as follows: +Shevat Adar I Adar Adar II +This works with the normal MMM+/LLL+ pattern characters for months; the choice of which name to use is managed by ICU date formatting code. +Note that this yeartype month is currently mapped into ICU month name data as the 14th element in the array of Hebrew month names, which seems a bit hacky. +2. special pattern character ‘l’ +The special pattern character ‘l’ (small L) is described as: “Special symbol for Chinese leap month, used in combination with M. Only used with the Chinese calendar.” It is intended to indicate where the leap month marker (when needed) should go in a date format. This is a bit odd: +It is not clear how (or whether) this is supposed to work with availableFormats items and DateTImePatternGenerator. +There is currently no structure in CLDR to provide the value for ‘l’. But assuming we added it… +It is not clear how a client who wants month symbol names can get the name for a leap month - do they need to assemble it from two pieces? How would they know what order to use? +It is not clear why this mechanism needs to be different than the mechanism used for the Hebrew calendar. +It seems unnecessary; the month naming could just be handled via the MMM+/LLL+ pattern, and CLDR data could provide complete month names both with and without the marker (distinguished using the something like the yeartype attribute). This would fit more smoothly into existing mechanisms. +F. Proposal +Items 1-2 and 5-8 below are probably do-able for CLDR 21 and ICU 49. The others may come later. +1. ICU behavior for months +The Hebrew model of explicitly numbering all month names and skipping leap months in non-leap years does not work well for calendars like Chinese and Hindu that may insert leap months anywhere (and may combine months, etc.). The use of the UCAL_IS_LEAP_MONTH field is better suited to this. +For choosing the correct month name variant, I had proposed the idea of enhancing the UCAL_IS_LEAP_MONTH field to have 4 values, and adding an enum for these values: +normal month, this is currently value 0 for UCAL_IS_LEAP_MONTH +leap month (for Chinese, this has the same month number as the month before; for Hindu & TIbetan, it has the same number as the month after), this is currently value 1 for UCAL_IS_LEAP_MONTH +normal month after leap month (needed for Hindu & Tibetan); this could be value -1 for UCAL_IS_LEAP_MONTH (it is not a leap month, but does need a special name) +compressed month (needed for Hindu & Tibetan); this could be value 2 for UCAL_IS_LEAP_MONTH +While this was agreed in ICU PMC on 2011-11-09, I now think this idea should be withdrawn (agreed in PMC). For purposes of determining the variant month names, there are other approaches, e.g. for relevant calendars we can see whether subtracting a month gives the same month number (in which case we have a normal month after leap), or adding a month skips a month number (in which case we have a combined month). For calendrical calculations, however, the current UCAL_IS_LEAP_MONTH values of 0 and 1 are adequate (since that is all that is needed to disambiguate month numbering); and in fact the extra values would complicate the calendrical calculations: if we set a month to be compressed, what does that mean? +For a unified model we could also change the Hebrew calendar to use this approach (since in a leap year it inserts Adar I before Adar, whose name then changes to Adar II - the form for normal after leap), but that might be a compatibility issue. We can at least set UCAL_IS_LEAP_MONTH appropriately, even if we do not change the month numbering. +2. CLDR data for leap months +The yeartype attribute for month names cannot support different month name types for each month in a year, or for different months in a year. +Old ideas +The first version of this proposal suggested defining for the month name element a new attribute “monthtype” which could have the values “standard”, “leap”, “standardAfterLeap”, or “combined”, and then supplying explicit names for each needed type for each month (rather than a mechanism to combing markers). The thought was that this would permit handling of special forms for e.g. the first month of the year. However, it is only the first month of the lunar year that may have a special form in the Chinese calendar, and that can never have a leap month anyway. +The second idea was to permit inside each element (i.e at the same level as the elements) zero or more elements, which could have a type attribute of "leap", "standardAfterLeap", or "combined", and whose value would be a a pattern showing how to combine a marker with a month name {0} (and possibly {1} for combined months) - e.g. "闰{0}" or "kshay {0}-{1}". This was approved in CLDR 2011-11-16. However, it does not address the problem of specifying a month type marker with numeric months as well. For this we need a separate structure that parallels monthContext… +Current idea +(approved in CLDR meeting 2011-11-30) +Alongside the element, permit an optional parallel element (only present for calendars that need it). The structure under this is similar to that for , except that: +The element's type attribute that takes one of three values: "format", "stand-alone", or the added "numeric" (pattern to use with numeric months). +The element's type attribute can take an additional value "all" for use with the "numeric" context (since there is no width distinction for numeric months). +The elements can have type "leap", "standardAfterLeap", or "combined"; the value is the pattern used for modifying the month name(s) to indicate that month type. +A Chinese calendar example (marker before the month name) in root: + (default alias to format/wide) (default alias to stand-alone/narrow) {0}bis (default alias to format/abbreviated) {0}bis (default alias to format/wide) {0}bis +And in the Chinese locale: + 闰{0} 闰{0} 闰{0} +For other calendars, the elements above could be replaced by others such as the following: +For the Hebrew calendar, in the Hebrew locale, one could have (for Adar I and II): +{0} א׳ {0} ב׳ +For the Hindu calendar, in root (for a combined month, the name will be an affix plus a combination of two month names): +adhik {0} nija {0} kshay {0}-{1} +For the time being, at least, I don't think that we need to present this in the Survey Tool, and that may prove too complex and confusing anyway. +3. Month name styles +(mostly about data, some ideas for future structure requirements): +Japanese locale month name styles, all for either Gregorian or lunar calendar (except as noted). The distinction among them is not just format vs standalone. +The style 1月, 2月, 3月... is almost always used for horizontal text and for yMd formats. This is by far the most common. +The style 一月, 二月, 三月... can be used for vertical text, as a special style e.g. on New Year cards, and rarely for government documents. +The traditional naming, which is still used sometimes for titles on calendar pages: 睦月, 如月, 弥生, 卯月, 皐月, 水無月, 文月, 葉月, 長月, ... +The name 正月 is formally an alternate name for Gregorian January, but in common usage means just the New Year holidays (first few days of Jan.). +Chinese locale month names and alternates (applies to both traditional/simplified, mainland/Taiwan unless noted): +Gregorian calendar: The style 1月, 2月, 3月 is preferred for complete yMd dates (all of whose components should use 0-9 digits), especially when Gregorian dates are shown together with Chinese calendar dates. The style 一月, 二月, 三月 can also be used for month names by themselves, either in running text or as an isolated element on a calendar page. +Lunar calendar: The first month is always designated 正月. For the remaining months, the style 二月, 三月, 四月 is preferred (especially when Chinese calendar dates are shown together with Gregorian dates), except that 冬月 and 腊月 are sometimes used for months 11 and 12. Chinese numerals should be used for the other portions of complete dates as well. +The “monthType” attribute in the first version of this proposal might have also provided a means to address variants such as some of the above, as well as the following: +For parsing, it would be useful to have multiple forms for month names—e.g. “Sep.” and “Sept.” +4. Day names +Will need some way to specify the special day numbering forms used in Chinese for the Chinese calendar - TBD, can be a future enhancement. +5. Deprecate the pattern character ‘l’ (small L). +If it occurs in a pattern it should be ignored. +6. CLDR data for year names +Option 1, element +(The following was originally agreed in CLDR 2011-11-16; however, it has been superseded by option 2, which was approved on 2011-11-30). +Add a element and sub-elements parallel to the current structure for , , and , as follows (with similar structure in ICU): + Jia-Zi Yi-Chou … Gui-Hai (defaults to abbreviated) (defaults to abbreviated) +Only the “format” context would be supported initially; other contexts could be added if needed. +Option 2, element +(approved in CLDR meeting 2011-11-30) +As noted above, the cycle of 60 stem-branch names is used for months and days as well as years. Years as are also known according to the cycle of 12 zodiac animals associated with the branch portion of the stem-branch name. A cycle of 12 branch names is also used for subdivisions of a day. Thus, it would be beneficial to have a more general representation of such name cycles, even though cyclic names for months, days, and day subdivisions are not part of the current proposal. +In one of his comments on #1507, Philippe Verdy mentions that the cycle of 60 names is also used for some non-calendrical enumerations in Chinese such as measurement of angles, and suggests that data for this should be independent of the calendar structure. These notions are specific to the Chinese locale, and are not notions that CLDR would support across multiple locales (unlike the Chinese calendar, which is supported across multiple locales), so it probably does not make sense to add CLDR structure for them. +The following proposes a ways to support cyclic names for years, zodiac mappings, months, days, and dayParts (not really the same as dayPeriods), with the currently-known cycles of length 60 or 12 (for the Chinese, Hindu, and related calendars); this structure would be just below the element: + jia-zi yi-chou … gui-hai < cyclicNameWidth type=”narrow”> (defaults to abbreviated) < cyclicNameWidth type=”wide”> (defaults to abbreviated) (root aliases to years) (root aliases to dayParts) …data for branch names... (root aliases to dayParts, some locales will supply separate data) +As with the leap month data, this may not be appropriate for the Survey Tool. +7. New pattern character(s) +We would need to add a pattern character to indicate year name. A natural choice is ‘U’ since it is currently unused and ‘u’ is already used for a different year type. +8. ICU implementation changes +Formatting... (to be supplied) +Parsing (month names, year names)... (to be supplied) +ICU4J ChineseDateFormat class, move relevant behaviors into SimpleDateFormat, leaving this as mostly a shell. Remove ChineseDateFormatSymbols use of "isLeapMonth" resource; instead derive the necessary data (needed only for backwards compatibility) from the monthPatterns data. +9. ICU API enhancements +Add a calendar field IS_EXTRA_HOUR or IS_REPEATED_HOUR to disambiguate the hour added/repeated during DST transitions that set the clock back. +Work out how and whether to map the modified month names (for leap month types) onto APIs that get date format symbols — use additional options to specify month symbol types? What about symbols for year names? +Add Calendar API to answer the following questions for a given year and era: +Is it a leap year? And if so… +Of what type - does it adjust days or months? +When are the beginnings and ends (perhaps expressed as UDates) of the portions of the year that are affected by the adjustments? Note that calendars like Hindu could have in a single year up to two nonadjacent added months plus one combined month. +10. Supporting the Vietnamese / Korean / Japanese variants of the Chinese lunar calendar +These variants behave in a similar way, using different ways of designating leap months and different names for the stem-branch cycle, the branch cycle, and the zodiac cycle, and using a different meridian as the basis for astronomical calculations. We could support these in several ways: +Treat them as separate calendars with different names, and potentially support all of them in each locale. +Treat them each as the locale-specific variant of the Chinese lunar calendar. In that case the meridian for calculation needs to be supplied as part of the locale data. Need to clarify that the "Chinese" calendar means the locale-adapted version, not the historic imported one. +An in-between approach in which there is just one locale-specific set of data for the Chinese-style lunar calendar, but the meridian for computation is specified independently—perhaps as another locale tag value. +A combination of the above two approaches: Have locale data specify the default median, but also allow specification of meridian in the locale name to override this. This is the recommended approach. +11. Chinese calendar ambiguous dates, and handling of 'y' pattern character +For the Chinese calendar, the value within a Calendar object's YEAR file is the year number within a 60-year cycle. However, this year is never displayed numerically in a Chinese calendar date format; it is always displayed using the cyclic name, i.e. using pattern character 'U'. The Calendar object's ERA field is the cycle number, but this also is never used is a formatted date. Hence formatted dates that use only elements from the Chinese calendar itself are ambiguous as to which era/cycle they are associated with. For real-world usage, that is not a problem; the Chinese calendar is not intended to unambiguously represent a date, and is normally displayed in association with a date (at least a year) in one or more additional calendars that do provide that disambiguation. +As noted above, in Taiwan this other calendar is typically the Minguo/ROC calendar; in Japan it is typically the Japanese calendar; in mainland China and elsewhere it is typically the Gregorian calendar, often with additional calendars such as Islamic. +In the long run, CLDR calendar data for the Chinese calendar should specify which other calendar should be used as the associated calendar. Then it may be that for formatting and parsing Chinese calendar dates, the 'y' and 'G' pattern characters would be interpreted according to this associated calendar, rather than the Chinese calendar. +In the short term, ICU should specify that parse methods that do not take an associated Calendar object may not produce the expected results for the Chinese calendar. Such methods create a work Calendar object and then clear() it, which for the Chinese calendar will set it to era 1; since there is no era in the format, the parsed result will have era 1, producing a date in the range of Gregorian 2600 BCE (probably not what is expected). +Note that the convention of using a secondary calendar associated with a traditional calendar is not unique to the Chinese calendar. Real-world Japanese conventions for formatting dates often use both a Gregorian and Japanese Emperor year, e.g. "2012(平成24)年1月". +G. Tickets +The old CLDR and ICU tickets related to this are: +CLDR #1507: intercalary marker missing from chinese calendar (refile) [includes detailed comments from Philippe Verdy, some anticipating ideas above] +CLDR #2430: Illegal date-time field "l". +CLDR #2558: Chinese calendar formatting does not look right +CLDR #3672: Value inherited from "root" is in error +ICU #6049: Intercalary markers +New tickets related to this, which supersede the above, are: +CLDR #4230: Add element for Chinese calendar support +CLDR #4231: Add cyclic year name support for Chinese calendar +CLDR #4232: Deprecate pattern character 'l', add pattern character 'U' +CLDR #4237: Change Chinese calendar formats to use 'U' pattern char [must wait for ICU format/parse support] +CLDR #4259: Chinese calendar data updates +CLDR #4277: Remove processing from LDML2ICUConverter +CLDR #4282: Chinese calendar formats need era, Gregorian year, or ? +CLDR #4302: Fix spurious errors with chinese calendar (monthPatterns narrow, prettyPaths) +CLDR #4321: Skip some date pattern tests for Chinese calendar ('U' and other differences from std) +CLDR #4322: Fix test errors for monthPatterns +CLDR #4325: Fix test errors for date patterns using U (availableFormats...) +ICU #8958: Use CLDR data to format/parse Chinese cal dates +ICU #8977: Use CLDR data to format/parse Chinese cal dates (J) +ICU #8959: Support new 'U' pattern char for formatting/parsing Chinese cal dates +ICU #9034: Delete obsolete in data/xml/main/root.xml +ICU #9035: More ICU4C chinese calendar format/parse fixes +ICU #9043: Chinese cal dates can't always be parsed - design 2-cal solution +ICU #9044: Chinese cal dates can't always be parsed - document & fix tests +ICU #9055: Integrate Chinese cal pattern updates (cldrbug 4237), update tests \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/consistent-casing.txt b/docs/site/TEMP-TEXT-FILES/consistent-casing.txt new file mode 100644 index 00000000000..eae1e17a52c --- /dev/null +++ b/docs/site/TEMP-TEXT-FILES/consistent-casing.txt @@ -0,0 +1,79 @@ +Consistent Casing +Rough Draft +We know that we need to improve the way we do casing in CLDR. We want the casing to be consistent, so that we don't see, for example, some language names with titlecase and some with lowercase. +Current Status +We have the inText and inList items, but they are not consistently applied - and we haven't had tests for problems. Here is some text from http://unicode.org/reports/tr35 (I added notes in italic): + +The following element controls whether display names (language, territory, etc) are title cased in GUI menu lists and the like. It is only used in languages where the normal display is lower case, but title case is used in lists. There are two options: + + +In both cases, the title case operation is the default title case function defined by Chapter 3 of [Unicode]. In the second case, only the first word (using the word boundaries for that locale) will be title cased. The results can be fine-tuned by using alt="list" on any element where titlecasing as defined by the Unicode Standard will produce the wrong value. For example, suppose that "turc de Crimée" is a value, and the title case should be "Turc de Crimée". Then that can be expressed using the alt="list" value. +Note: we have inList items currently for: +cs.xml +da.xml +es.xml +hr.xml +hu.xml +nl.xml +ro.xml +root.xml +ru.xml +sk.xml +uk.xml + +This element indicates the casing of the data in the category identified by the inText type attribute, when that data is written in text or how it would appear in a dictionary. For example : +lowercase-words +indicates that language names embedded in text are normally written in lower case. The possible values and their meanings are : +titlecase-words : all words in the phrase should be title case +titlecase-firstword : the first word should be title case +lowercase-words : all words in the phrase should be lower case +mixed : a mixture of upper and lower case is permitted. generally used when the correct value is unknown. +Note: we have inText items currently in: +cs.xml +da.xml (20 matches) +es.xml (9 matches) +hr.xml (11 matches) +hu.xml (7 matches) +nl.xml (8 matches) +ro.xml (4 matches) +root.xml (13 matches) +uk.xml (6 matches) +For example, for Dutch we have (excluding draft items): +1,043: lowercase-words +1,045: titlecase-firstword +1,047: titlecase-firstword +1,049: titlecase-firstword +... +In certain circumstances, one or more elements do not follow the rule of the majority. as indicated by the inText element. In this case, the allow attribute is used: +The example below indicates that variant names are normally lower case with one exception. +lowercase-words + +ortografia tradizionale tedesca +ortografia tedesca del 1996 +dialetto del Natisone + +Improved Testing +As a part of bug http://www.unicode.org/cldr/bugs-private/locale-bugs-private/data?id=2227, I added a consistency test for casing. It just generates warnings for now, and the test is very simple: given a bucket of translations (eg language names), verify that everything have the same first-letter casing as the first item. Although simple (and not bulletproof!), it is revealing... +cs [Czech] warning names|language|lb 〈Luxembourgish〉 【】 〈Lucemburština〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). +cs [Czech] warning names|language|om 〈Oromo〉 【】 〈Oromo (Afan)〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). +cs [Czech] warning names|language|ps 〈Pashto〉 【】 〈Pashto (Pushto)〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). +I didn't use the inText or inList data, because I don't think we have enough data, nor that it has been vetted enough, to be reliable. Moreover, I don't think the buckes it uses are fine-grained enough.. I put the test output in 3 different files in http://www.unicode.org/cldr/data/dropbox/casing/ +The code is at http://www.unicode.org/cldr/data/tools/java/org/unicode/cldr/test/CheckConsistentCasing.java. Note that the buckets I used are defined in the code in typesICareAbout in the code. +Feedback and Open Issues +It would be useful to get people's feedback on how the tests can be improved. +In particular, whether the "buckets" should be done differently. For example, it would reduce the warnings if we put the abbreviated format months in a different bucket than the wide format months. But I don't know whether it is right to suppress this warning, or whether it indicates a true problem. +az [Azerbaijani] warning calendar-gregorian|day|sunday:format-wide 〈Sunday〉 【】 〈bazar〉 «=» 【】 Warning: First letter case of =lower doesn't match that of =upper (calendar-buddhist|day|sunday:format-abbreviated). +A second issue is how to pick the "paradigm" casing for each bucket. The algorithm I use now is to just use the first item in each bucket. +A third issue is how to "turn off" the warning; some way for the user to add data that says "it is ok for this item to have different case" (This is a more general issue regarding errors/warnings.) +A broader issue is what we should do with inText and inList in order to deal with casing, and how to deal with the fact that sometimes items in a bucket should undergo a case transformation in a particular environment (eg should be titlecased in menus but otherwise lowercased). +Determining whether current structure is sufficient +(from Peter E, 2009 Nov 18) +The attached "CasingContexts.pdf" is a first draft of a doc providing examples of various contexts for usage of date formats and date elements, language names, region names, and names of various other CLDR keys. This document is somewhat oriented to Mac OS X (since those were the examples at hand), so I would like to solicit other type of examples that may cover situations not depicted here. Suggestions welcome! +What I hope to do with this (and very soon) is to send it out to localizers to solicit either sample translations for each item in context (so I can infer the various grammatical cases and capitalization cases that CLDR may need to support), or better yet, have the localizers let me know about all of the cases that are necessary. +With that information I hope to: +1. Determine what additional types (beyond form,at and standalone) may be necessary for date formatting, and +2. See whether inText/inList are adequate to cover the capitalization cases, and if not, try to come up with something better. +(from Peter E., 2009 Nov 22) +I have attached "CasingContextsV2.pdf" which fixes the calendar menu example (thanks Kent!) and adds examples of currencies in text and various examples of units in text. I still need to add an example of currency in a dialog, along with overall instructions. +(from Peter E., 2009 Nov 25) +Updated to "CasingContextsV3.pdf" which adds an overall explanation of the purpose of this document as well as instructions for localizers to provide feedback. \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/coverage-revision.txt b/docs/site/TEMP-TEXT-FILES/coverage-revision.txt new file mode 100644 index 00000000000..65503167567 --- /dev/null +++ b/docs/site/TEMP-TEXT-FILES/coverage-revision.txt @@ -0,0 +1,34 @@ +Coverage Revision +1. Propose changing CoverageLevel to be data driven. Rough thoughts. +Have a list of paths +- ​/​/ldml​/identity​/version => NONE +- ... ++ /​/ldml​/localeDisplayNames​/languages​/language[@type="*"] language:​type=​[en, und] => Minimal ++ ... +- ... +Have special variables for +this language +this language's countries +this language's territories +... +2. Current coverage: needs review +I put the tentative results in http://spreadsheets.google.com/pub?key=t5UzIpaSqcYBksSMtZp-f7Q&output=html +The more detailed files are in http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/. In particular: +http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/summary.txt +http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/samples.txt +http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/fullpaths.txt +There is more to do, but I wanted to give a snapshot +- tune the weighting +- weight by draft level +- add collations, rbnf, plural rules, transforms (if non-Latin), etc. +From John +I've been doing some more thinking about how to deal with coverage in CLDR. It seems to me that we already have the notion that every XPath in CLDR should have some predefined number associated with it between 0 and 100 that denotes it's relative importance in terms ofcoverage, with 0 being absolutely critical, and 100 being not critical at all. See Appendix M of TR35 for a brief description of the levels. I think that if we could accurately quantify this using metadata, then it would be relatively easy for us to accomplish two things: +1). Filter out fields from the ST that we don't really need, since everything we do would be filtered based on a desired coverage level. +2). Allow individual users to set the filtering in the survey tool based on one of the predefinedcoverage levels as we already have in the spec, or actually any other numeric coverage level that they desire. +So with this in mind, I would like to propose the following structure to be added to the supplemental metadata: + + + +.... + +Finding the appropriate coverage level value would then be a matter of searching the coverageLevel entries in numeric order by value looking for a match of the path vs. "//ldml/" + "regular expression". In other words, we would not specifically include "//ldml" in the expressions, since they would all start with that. Once a given xpath's coverage level value was determined, it shouldn't be too hard for us to simply filter out fields whose coverage level was higher then the requested. I suppose that we will need some wildcards similar to what Mark has started working on in his path filtering proposal. \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/currency-code-fallback.txt b/docs/site/TEMP-TEXT-FILES/currency-code-fallback.txt new file mode 100644 index 00000000000..fab2b6c6485 --- /dev/null +++ b/docs/site/TEMP-TEXT-FILES/currency-code-fallback.txt @@ -0,0 +1,17 @@ +Currency Code Fallback +The basic problem is that we can't use currency codes that our users won't have fonts for. It was fine to have, say, the shekel sign in Hebrew, as in CLDR 1.6, because we could presume that anyone using the Hebrew locale would have a Hebrew font, and that Hebrew fonts would have a shekel sign. But by putting it into root, we are presuming that *everybody* would have that character, which is not true. Our users/customers think there is something wrong when they scan a list of currencies, and some of them are black boxes. +Here are some examples of behavior I think we'd like to support. +We show ￡ if the font is available, otherwise £, otherwise currency code. +We show ₧ if the font is available, otherwise Pts, otherwise currency code. +For reference, here are the currency signs in Unicode: http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%3Asc%3A]. Also see http://en.wikipedia.org/wiki/Currency_sign and http://www.unicode.org/cldr/data/charts/by_type/names.currency.html. +For more details on the problem, see the email thread titled "Problems with currency codes". +Here are some recommendations. +We don't have the character fallback element for any currency symbol that is used for different currency codes. That is, it is ok to have EUR for €, but not ok to use KRW for ₩, since ₩ is also used for KPW, and not to have JAY for ¥, since ¥ is also used for CNY. +Even with this, we don't really want to use character fallback elements for currency substitution in general, since it is too coarse. +We should try to remove all the currency symbols that use Unicode symbol characters from the locales, except where they have special plurals, or where we have symbol reversals (eg in the US, $ for USD and C$ for CAD, while in CA, $ for CAD and US$ for USD). +Options +We then just make sure that all currency symbols in root are widely understood and in common fonts (eg in Windows Arial), or +We enhance the currency symbols so that we have a fallback list. We put the symbols that are in typical fonts in each locale in the currencySymbols exemplar list for that locale. When formatting, we walk through the fallback list until we hit one that works. If we don't get any, we use the currency code. If a smart client has font information, then he could also walk the fallback list using the font information instead of the currencySymbol exemplars. +We have something like "commonly used" that lets the application provider choose to force the symbol; otherwise only the commonly used symbols appear. So in root, commonly used would be on EUR, etc. Could be turned on in locales, or by application. +I'm leaning towards #1, just for simplicity. +However, see also: http://www.unicode.org/cldr/bugs/locale-bugs?findid=2244 \ No newline at end of file diff --git a/docs/site/development/development-process/design-proposals/change-to-sites.md b/docs/site/development/development-process/design-proposals/change-to-sites.md new file mode 100644 index 00000000000..364b5fb31ee --- /dev/null +++ b/docs/site/development/development-process/design-proposals/change-to-sites.md @@ -0,0 +1,82 @@ +--- +title: Change to Sites? +--- + +# Change to Sites? + +We are using Sites ([http://cldr.unicode.org/](http://cldr.unicode.org/)) to host all of the CLDR development web pages. I took a look at the cldr pages, and the following are not in Sites. The question is, should we move them (or some of them) to Sites? + +Advantages + +1. Removing a bottleneck. Even though we have them in CVS (so the project people can edit the repository copies of them), we have a bottleneck in that only a small number of people (Rick, Steven, and me) can actually post them up publicly. +2. Editing doesn't require an HTML editor. + +Disadvantages + +1. The look and feel is somewhat different than the regular Unicode site (although we should be able to make it closer over time). + +Files + +http://www.unicode.org/cldr/beta.html + +http://www.unicode.org/cldr/comparison\_charts.html + +http://www.unicode.org/cldr/corrigenda.html + +http://www.unicode.org/cldr/index.html + +http://www.unicode.org/cldr/filing\_bug\_reports.html + +http://www.unicode.org/cldr/locale\_faq.html + +http://www.unicode.org/cldr/process.html + +http://www.unicode.org/cldr/transliteration\_guidelines.html + +http://www.unicode.org/cldr/terms.html + +http://www.unicode.org/cldr/survey\_tool.html + +http://www.unicode.org/cldr/repository\_access.html + +http://www.unicode.org/cldr/version/ (version pages) + +*Here are the other files:* + +Special purpose, for redirecting. + +http://www.unicode.org/cldr/header.html + +Old or temporary page: + +http://www.unicode.org/cldr/readme.txt + +http://www.unicode.org/cldr/press.html + +Already redirect, some to Docs pages + +http://www.unicode.org/cldr/big\_red\_switch.html + +http://www.unicode.org/cldr/charts.html + +http://www.unicode.org/cldr/data\_formats.html + +http://www.unicode.org/cldr/errata.html + +http://www.unicode.org/cldr/procedures.html + +http://www.unicode.org/cldr/tr35.html + +http://www.unicode.org/cldr/timezone\_ids.html + +http://www.unicode.org/cldr/survey\_tool\_known\_bugs.html + +http://www.unicode.org/cldr/vetting.html + +http://www.unicode.org/cldr/xmlGuide.html + +Possible Bug - needs investigation. + +![image](../../../images/design-proposals/site_bug.png) + +![Unicode copyright](https://www.unicode.org/img/hb_notice.gif) \ No newline at end of file diff --git a/docs/site/development/development-process/design-proposals/chinese-and-other-calendar-support-intercalary-months-year-cycles.md b/docs/site/development/development-process/design-proposals/chinese-and-other-calendar-support-intercalary-months-year-cycles.md new file mode 100644 index 00000000000..e1872269992 --- /dev/null +++ b/docs/site/development/development-process/design-proposals/chinese-and-other-calendar-support-intercalary-months-year-cycles.md @@ -0,0 +1,299 @@ +--- +title: Chinese (and other) calendar support, intercalary months, year cycles +--- + +# Chinese (and other) calendar support, intercalary months, year cycles + +| | | +|---|---| +| Author | Peter Edberg, with info and ideas from many others | +| Date | 2011-11-20 through 2011-11-30, **more 2012-01-10** | +| Status | Proposal | +| Feedback to | pedberg (at) apple (dot) com | +| Bugs | See list of tickets at the end of this document | + +Currently the ICU Calendar object has basic support for the Chinese calendar (can determine era, year number, month, etc.). However, real date formatting using this calendar is blocked until CLDR adds necessary support for formatting Chinese calendar dates. In doing this, we need to take into account other calendars that may have similar issues, which we should support in a unified way. The intent here is to provide the minimum change necessary to support the Chinese calendar (and other luni-solar calendars) at the same level as other calendars are currently supported; support for additional special calendar features requiring significant enhancements to the ICU Calendar object (see below) is for future enhancements. + +## A. Relevant calendar features + +Salient features of the Chinese calendar, and related features of other calendars: + +### 1. Chinese luni-solar calendar + +- Months begin at a new moon and are 29 or 30 days long. +- A year consists of 12 or 13 months (determined by the number of new moons between winter solstices). Months are numbered 1-12. When an extra intercalary month is needed, it might be inserted after any of the standard months 2-11 (after 11 is unusual); it repeats the numbering of the preceding month, with an extra marker to indicate that it is a leap month (in Chinese this marker ‘闰’ precedes the month number). An astronomical rule determines whether and where it gets inserted in a given year. The winter solstice always occurs during month 11, so the new year (and month 1) usually begins on the second new moon after that (Unless month 11 has a leap month added). +- Astronomical calculations are based on a meridian of 120° (near Beijing). +- Years are named using a 60-year cycle. The year name is formed by combining a celestial stem from a 10-year cycle and an earthly branch from a 12-year cycle. The 12 earthly branches correspond to, but do not have the same names as, the 12 zodiac animals associated with them. For example: + - Celestial stems: 甲 jiǎ, 乙 yǐ, 丙 bǐng, 丁 dīng, … + - Earthly branches: 子 zǐ, 丑 chǒu, 寅 yín, 卯 mǎo, … + - Zodiac animals: 鼠 Rat, 牛 Ox, 虎 Tiger, 兔 Rabbit, … + - First years of 60-year cycle: 甲子 jiǎ-zǐ, 乙丑 yǐ-chǒu, 丙寅 bǐng-yín, 丁卯 dīng-mǎo, … + - In principle each cycle can be treated as a separate era. However, such eras are not normally ever used in formatted dates, leading to potential ambiguity about which date is being represented. Traditionally this ambiguity could be resolved by also displaying a regnal period or regnal year along with the Chinese calendar date. In modern times this ambiguity is normally resolved by always displaying a Chinese calendar date in conjunction with a date (or at least a year) in at least one other calendar. In Taiwan this other calendar is typically the Minguo/ROC calendar; in Japan it is typically the Japanese calendar; in mainland China and elsewhere it is typically the Gregorian calendar (for a format like “y年U年MMMd日” where y is the Gregorian year and U is the stem-branch name). Note that the year transitions of the associated calendar do not occur at the same time as the year transitions of the Chinese calendar. +- There are at least two standard conventions for the epoch of the Chinese calendar — i.e. when was year 1 of era 1. Both are associated with the legendary emperor Huangdi **黃帝**, hence the "Huangdi era" **黃帝紀元**. The most common convention is to use the beginning of Huangdi's reign, commonly specified as 2697 BCE; a somewhat less common convention (and the one used by ICU) is to use the year when he supposedly invented the Chinese calendar, 2637 BCE. Since the latter is 60 years later, the stem-branch names associated with years do not change, but the cycle number is different. For some usages among calendar specialists Chinese calendar years may be numbered continuously from the beginning of the epoch, in which case Gregorian 2012 Jan. 23 is the beginning of Chinese calendar year 4650 or 4710 depending on which convention is used. However this kind of year numbering is not widely known. +- In Chinese the days of the month have special numbering. Days 1-10 use 初一, 初二, … 初十. For days 21-29 the number is formed using 廿 instead of 二十 to indicate 20. The first month is designated 正月 instead of 一月. + +### 2. Other calendars related to the Chinese calendar (Japanese, Korean, Vietnamese) + +- Similar luni-solar calendars are used in Japanese, Korean, and Vietnamese, with the computations based respectively on meridians near Tokyo, Seoul, and Hanoi. For the Japanese version, the date typically used for disambiguation would be a Japanese calendar date, not a Gregorian date. The Vietnamese calendar uses a different set of animals for the branch names in years, and the marker for intercalary month is inserted \*after\* the month name, not before. + +### 3. Hebrew calendar + +- The Hebrew calendar is another luni-solar calendar, with months of 29 or 30 days beginning at a new moon. Intercalary months are inserted during specific years of a 19-year cycle, always by doubling the month of Adar: A leap year has months Adar I and Adar II (Adar I is considered to be the extra inserted month). +- Month numbering is interesting. Traditionally, the month of Nisan was numbered 1, and Adar was 12 (thus Adar I and II were 12 and 13). However, this puts the month of Tishri, which begins with the new year (Rosh HaShanah), as month 7. A more modern numbering has Tishri as month 1 (to coincide with the new year) which leads to different schemes for numbering Adar and the subsequent months (see discussion below on what ICU does). + +### 4. Coptic and Ethiopic solar calendars + +- These *always* have 13 months; 12 months of 30 days each and a 13th month of 5 days (6 in a leap year). There is no leap month per se. + +### 5. Hindu luni-solar calendar (old or new, with several variants): + +- Months are 29 or 30 days, beginning at new moon (south India) or full moon (north India). Months are named based on which zodiac sign the sun transits into during the course of the lunar month. An intercalary month occurs when the sun does not transit into a zodiac sign during the lunar month, and it takes the name for the zodiac transit of the following month with a marker to indicate “extra”/“added”; the following month \*also\* takes a marker to indicate “original”/”regular”/”clean” (a bit like Adar I and Adar II, except that it can apply to any month). If the sun transits into two zodiac signs during a lunar month, then two months are collapsed into one; the resulting month takes the name associated with both zodiac signs, with a marker indicating “lost”. A year when this occurs must also have at least one added month, since the year must have 12 or 13 lunar months. Occasionally an added month with no transits is immediately followed by a collapsed month with two; in this case the first month takes the name of the first transit in the second month plus the marker “extra”/“added”, while the second month takes the names of both transits plus the marker “lost”. +- This calendar also uses a 60-year cycle of year names, but they are not derived as combinations of sub-cycle names (as with the Chinese calendar). + +### 6. The Tibetan luni-solar calendar + +- The Tibetan luni-solar calendar handles months like the Hindu calendar. Two different 60-year naming cycles are in use, one derived from the Chinese calendar and one derived from the Hindu calendar. In addition, three different cardinal year numbering schemes are used, with three different epochs (like the distinction between ethiopic and ethiopic-amete-alem calendars). + +## B. Other features of the Chinese calendar, not for this proposal + +The Chinese calendar divides the solar year into 24 solar terms— 12 major terms and 12 minor terms—each associated with divisions along the sun’s course through the zodiac. These are usually shown on printed calendars, and are used for agriculture and astrological purposes. The data could be derived from existing calendar fields, or a new field could be added. + +Months and days are also named in cycles of 60 using the stem-branch names, and days are subdivided into 12 two-hour periods named according to the earthly branches. The combination of year name, month, day name and day period name (年月日時) is important for many purposes, including picking children’s names and arranging weddings, moves, travel, and funerals. This data could also be derived from existing calendar fields, or a new field added. + +Festivals and holidays are shown on printed Chinese calendars, as well as on many other calendars. ICU4J has a preliminary framework for holiday support. ICU4C does not, and there is currently no commitment in ICU to move this along. Support for marking festivals and holidays is thus beyond the scope of this proposal. + +Nothing in this proposal prevents or makes more difficult adding any of these other features later on; this proposal just focuses on features that can be implemented in the near term. + +## C. ICU behavior + +Here is how ICU currently handles the calendar behaviors above: + +### 1. Chinese calendar + +Months are numbered 0-11 (the zero-based value of UCAL\_MONTH). When an intercalary month is added, it has the same number as the preceding month, but the value of UCAL\_IS\_LEAP\_MONTH is 1 instead of 0 (this seems to be the only supported calendar that ever sets UCAL\_IS\_LEAP\_MONTH to anything other than 0). + +For purposes of add and set operations, month is treated as a tuple represented by UCAL\_MONTH and UCAL\_IS\_LEAP\_MONTH. If UCAL\_IS\_LEAP\_MONTH is 0 for a month that has a leap month following, then adding 1 month, or setting UCAL\_IS\_LEAP\_MONTH to 1, sets the calendar to the leap month (which has the same value for UCAL\_MONTH). If a month does not have a leap month following, then a set of UCAL\_IS\_LEAP\_MONTH to 1 is ignored. + +Years are numbered 1-60 (the value of UCAL\_YEAR) for each 60-year cycle. The era is incremented for each 60-year cycle, so we are currently in era 78. Current ICU4C formatting for the Chinese calendar is completely broken. For example, the short date format in root and zh is currently “y'x'G-Ml-d”; the result this produces for Chinese era 78, year 29, month 4 (non-leap or leap), day 2 is “29x-4-”: There is no era value or leap month indicator, and non-literal fields after the ‘l’ pattern character are skipped. + +In ICU4J the existing situation is bit better. Via data in data/xml/main/root.xml, ICU inserts its own "isLeapMonth" resource into the calendar bundle for "chinese"; this provides a leapMonthMarker of "\*". There is a public ChineseDateFormatSymbols subclass of DateFormatSymbols which uses the "isLeapMonth" resource, and a public ChineseDateFormat of SimpleDateFormat; using ChineseDateFormat, Chinese calendar date formats using 'G' and 'l' can be formatted and parsed successfully. + +### 2. Hebrew calendar + +In a non-leap year, months run 0-4 (for months Tishri-Shevat), skip 5 (“Adar I”), then continue 6-12 (Adar-Elul). In a leap year, 5 is not skipped (“Adar I”), and CLDR data provides an alternate “leap” name for month 6 as “Adar II”. + +### 3. Coptic and Ethiopic calendars + +Months are numbered 0-12. ### 4. Other calendars listed above + +ICU does not currently support the Hindu, Vietnamese, or Tibetan calendars (it does support the quite different Indian Civil calendar). + +## D. Problems with the current ICU behavior: + +- For the Chinese and Hebrew calendars, there is no a priori way to know for a given year whether it is a leap year. You have to run through the dates in the year to check the behavior (and the way you have to do this depends on the calendar). +- The current model for UCAL\_IS\_LEAP\_MONTH (ICU4J) IS\_LEAP\_MONTH) as a boolean cannot directly indicate the "normal-month-after-leap-month" and "compressed-month" used in Hindu and Tibetan calendars. However, those special months can be inferred from looking at month data before and after the month of interest. Another alternative might be to re-interpret the IS\_LEAP\_MONTH field to take more than two values. +- It is a bit too bad that completely different models are used for leap months in the Hebrew and Chinese calendars. It would have been nice to have a more unified model that could also support the usage in Hindu and Tibetan calendars. +- Calendar::add (ucal\_add) for UCAL\_MONTH gives different strange results for the Hebrew and Chinese calendars. For the Hebrew calendar, in a non-leap year, adding 1 month to month 4 produces month 6. For the Chinese calendar, in a leap year, adding 1 month to month n (before a leap month) produces month n (but with IS\_LEAP\_MONTH set). This is similar to what happens to hours around daylight savings time transitions, except in that case there is no IS\_EXTRA\_HOUR field to provide disambuguation (we should add one, see below). + +## E. Current CLDR support + +CLDR currently provides the following: + +### 1. yeartype attribute + +The yeartype attribute for month name elements allows an alternate month name to be selected for leap years (current legal values are just “standard”—the default—and “leap”). It is only used for the Hebrew calendar, as follows: + +\Shevat\ \Adar I\ \Adar\ \Adar II\ + +This works with the normal MMM+/LLL+ pattern characters for months; the choice of which name to use is managed by ICU date formatting code. + +Note that this yeartype month is currently mapped into ICU month name data as the 14th element in the array of Hebrew month names, which seems a bit hacky. + +### 2. special pattern character ‘l’ + +The special pattern character ‘l’ (small L) is described as: “Special symbol for Chinese leap month, used in combination with M. Only used with the Chinese calendar.” It is intended to indicate where the leap month marker (when needed) should go in a date format. This is a bit odd: + +- It is not clear how (or whether) this is supposed to work with availableFormats items and DateTImePatternGenerator. +- There is currently no structure in CLDR to provide the value for ‘l’. But assuming we added it… +- It is not clear how a client who wants month symbol names can get the name for a leap month - do they need to assemble it from two pieces? How would they know what order to use? +- It is not clear why this mechanism needs to be different than the mechanism used for the Hebrew calendar. +It seems unnecessary; the month naming could just be handled via the MMM+/LLL+ pattern, and CLDR data could provide complete month names both with and without the marker (distinguished using the something like the yeartype attribute). This would fit more smoothly into existing mechanisms. + +## F. Proposal + +Items 1-2 and 5-8 below are probably do-able for CLDR 21 and ICU 49. The others may come later. + +### 1. ICU behavior for months + +The Hebrew model of explicitly numbering all month names and skipping leap months in non-leap years does not work well for calendars like Chinese and Hindu that may insert leap months anywhere (and may combine months, etc.). The use of the UCAL\_IS\_LEAP\_MONTH field is better suited to this. + +For choosing the correct month name variant, I had proposed the idea of enhancing the UCAL\_IS\_LEAP\_MONTH field to have 4 values, and adding an enum for these values: + +- normal month, this is currently value 0 for UCAL\_IS\_LEAP\_MONTH +- leap month (for Chinese, this has the same month number as the month before; for Hindu & TIbetan, it has the same number as the month after), this is currently value 1 for UCAL\_IS\_LEAP\_MONTH +- normal month after leap month (needed for Hindu & Tibetan); this could be value -1 for UCAL\_IS\_LEAP\_MONTH (it is not a leap month, but does need a special name) +- compressed month (needed for Hindu & Tibetan); this could be value 2 for UCAL\_IS\_LEAP\_MONTH + +While this was agreed in ICU PMC on 2011-11-09, I now think this idea should be withdrawn (agreed in PMC). For purposes of determining the variant month names, there are other approaches, e.g. for relevant calendars we can see whether subtracting a month gives the same month number (in which case we have a normal month after leap), or adding a month skips a month number (in which case we have a combined month). For calendrical calculations, however, the current UCAL\_IS\_LEAP\_MONTH values of 0 and 1 are adequate (since that is all that is needed to disambiguate month numbering); and in fact the extra values would complicate the calendrical calculations: if we set a month to be compressed, what does that mean? + +For a unified model we could also change the Hebrew calendar to use this approach (since in a leap year it inserts Adar I before Adar, whose name then changes to Adar II - the form for normal after leap), but that might be a compatibility issue. We can at least set UCAL\_IS\_LEAP\_MONTH appropriately, even if we do not change the month numbering. + +### 2. CLDR data for leap months + +The yeartype attribute for month names cannot support different month name types for each month in a year, or for different months in a year. + +Old ideas + +*The first version of this proposal suggested defining for the month name element a new attribute “monthtype” which could have the values “standard”, “leap”, “standardAfterLeap”, or “combined”, and then supplying explicit names for each needed type for each month (rather than a mechanism to combing markers). The thought was that this would permit handling of special forms for e.g. the first month of the year. However, it is only the first month of the lunar year that may have a special form in the Chinese calendar, and that can never have a leap month anyway.* + +*The second idea was to permit inside each \ element (i.e at the same level as the \ elements) zero or more \ elements, which could have a type attribute of "leap", "standardAfterLeap", or "combined", and whose value would be a a pattern showing how to combine a marker with a month name {0} (and possibly {1} for combined months) - e.g. "闰{0}" or "kshay {0}-{1}". This was approved in CLDR 2011-11-16. However, it does not address the problem of specifying a month type marker with* ***numeric*** *months as well. For this we need a separate structure that parallels monthContext…* + +Current idea + +(approved in CLDR meeting 2011-11-30) + +Alongside the \ element, permit an optional parallel element \ (only present for calendars that need it). The structure under this is similar to that for \, except that: + +- The \ element's type attribute that takes one of *three* values: "format", "stand-alone", or the added "numeric" (pattern to use with numeric months). +- The \ element's type attribute can take an additional value "all" for use with the "numeric" context (since there is no width distinction for numeric months). +- The \ elements can have type "leap", "standardAfterLeap", or "combined"; the value is the pattern used for modifying the month name(s) to indicate that month type. +A Chinese calendar example (marker before the month name) in root: + +\ \ \ (default alias to format/wide) \ \ (default alias to stand-alone/narrow) \ \ \{0}bis\ \ \ \ \ (default alias to format/abbreviated) \ \ \{0}bis\ \ \ (default alias to format/wide) \ \ \ \ \{0}bis\ \ \ \ + +And in the Chinese locale: + + \ \ \ \闰{0}\ \ \ \ \ \闰{0}\ \ \ \ \ \闰{0}\ \ \ \ + +For other calendars, the \ elements above could be replaced by others such as the following: + +- For the Hebrew calendar, in the Hebrew locale, one could have (for Adar I and II): + \{0} א׳\ \{0} ב׳\ + +- For the Hindu calendar, in root (for a combined month, the name will be an affix plus a combination of two month names): + \adhik {0}\ \nija {0}\ \kshay {0}-{1}\ + +For the time being, at least, I don't think that we need to present this in the Survey Tool, and that may prove too complex and confusing anyway. + +**3. Month name styles** + +(mostly about data, some ideas for future structure requirements): + +- Japanese locale month name styles, all for either Gregorian or lunar calendar (except as noted). The distinction among them is not just format vs standalone. + - The style 1月, 2月, 3月... is almost always used for horizontal text and for yMd formats. This is by far the most common. + - The style 一月, 二月, 三月... can be used for vertical text, as a special style e.g. on New Year cards, and rarely for government documents. + - The traditional naming, which is still used sometimes for titles on calendar pages: 睦月, 如月, 弥生, 卯月, 皐月, 水無月, 文月, 葉月, 長月, ... + - The name 正月 is formally an alternate name for Gregorian January, but in common usage means just the New Year holidays (first few days of Jan.). +- Chinese locale month names and alternates (applies to both traditional/simplified, mainland/Taiwan unless noted): + - Gregorian calendar: The style 1月, 2月, 3月 is preferred for complete yMd dates (all of whose components should use 0-9 digits), especially when Gregorian dates are shown together with Chinese calendar dates. The style 一月, 二月, 三月 can also be used for month names by themselves, either in running text or as an isolated element on a calendar page. + - Lunar calendar: The first month is always designated 正月. For the remaining months, the style 二月, 三月, 四月 is preferred (especially when Chinese calendar dates are shown together with Gregorian dates), except that 冬月 and 腊月 are sometimes used for months 11 and 12. Chinese numerals should be used for the other portions of complete dates as well. +- The “monthType” attribute in the first version of this proposal might have also provided a means to address variants such as some of the above, as well as the following: + - For parsing, it would be useful to have multiple forms for month names—e.g. “Sep.” and “Sept.” + +### 4. Day names + +Will need some way to specify the special day numbering forms used in Chinese for the Chinese calendar - TBD, can be a future enhancement. + +### 5. Deprecate the pattern character ‘l’ (small L). + +If it occurs in a pattern it should be ignored. + +### 6. CLDR data for year names + +Option 1, \ element + +(The following was originally agreed in CLDR 2011-11-16; however, it has been superseded by option 2, which was approved on 2011-11-30). + +Add a \ element and sub-elements parallel to the current structure for \, \, and \, as follows (with similar structure in ICU): + + \ \ \ \Jia-Zi\ \Yi-Chou\ … \Gui-Hai\ \ \ (defaults to abbreviated) \ \ (defaults to abbreviated) \ \ \ + +Only the “format” context would be supported initially; other contexts could be added if needed. + +Option 2, \ element + +(approved in CLDR meeting 2011-11-30) + +As noted above, the cycle of 60 stem-branch names is used for months and days as well as years. Years as are also known according to the cycle of 12 zodiac animals associated with the branch portion of the stem-branch name. A cycle of 12 branch names is also used for subdivisions of a day. Thus, it would be beneficial to have a more general representation of such name cycles, even though cyclic names for months, days, and day subdivisions are not part of the current proposal. + +In one of his comments on [#1507](http://unicode.org/cldr/trac/ticket/1507), Philippe Verdy mentions that the cycle of 60 names is also used for some non-calendrical enumerations in Chinese such as measurement of angles, and suggests that data for this should be independent of the calendar structure. These notions are specific to the Chinese locale, and are not notions that CLDR would support across multiple locales (unlike the Chinese calendar, which is supported across multiple locales), so it probably does not make sense to add CLDR structure for them. + +The following proposes a ways to support cyclic names for years, zodiac mappings, months, days, and dayParts (not really the same as dayPeriods), with the currently-known cycles of length 60 or 12 (for the Chinese, Hindu, and related calendars); this structure would be just below the \ element: + + \ \ \ \ \jia-zi\ \yi-chou\ … \gui-hai\ \ \< cyclicNameWidth type=”narrow”> (defaults to abbreviated) \ \< cyclicNameWidth type=”wide”> (defaults to abbreviated) \ \ \ \ (root aliases to years) \ \ (root aliases to dayParts) \ \ …data for branch names... \ \ (root aliases to dayParts, some locales will supply separate data) \ \ + +As with the leap month data, this may not be appropriate for the Survey Tool. + +**7. New pattern character(s)** + +We would need to add a pattern character to indicate year name. A natural choice is ‘U’ since it is currently unused and ‘u’ is already used for a different year type. + +### 8. ICU implementation changes + +- Formatting... (to be supplied) +- Parsing (month names, year names)... (to be supplied) +- ICU4J ChineseDateFormat class, move relevant behaviors into SimpleDateFormat, leaving this as mostly a shell. Remove ChineseDateFormatSymbols use of "isLeapMonth" resource; instead derive the necessary data (needed only for backwards compatibility) from the monthPatterns data. + +### 9. ICU API enhancements + +- Add a calendar field IS\_EXTRA\_HOUR or IS\_REPEATED\_HOUR to disambiguate the hour added/repeated during DST transitions that set the clock back. +- Work out how and whether to map the modified month names (for leap month types) onto APIs that get date format symbols — use additional options to specify month symbol types? What about symbols for year names? +- Add Calendar API to answer the following questions for a given year and era: + - Is it a leap year? And if so… + - Of what type - does it adjust days or months? + - When are the beginnings and ends (perhaps expressed as UDates) of the portions of the year that are affected by the adjustments? Note that calendars like Hindu could have in a single year up to two nonadjacent added months plus one combined month. + +**10. Supporting the Vietnamese / Korean / Japanese variants of the Chinese lunar calendar** + +These variants behave in a similar way, using different ways of designating leap months and different names for the stem-branch cycle, the branch cycle, and the zodiac cycle, and using a different meridian as the basis for astronomical calculations. We could support these in several ways: + +- Treat them as separate calendars with different names, and potentially support all of them in each locale. +- Treat them each as the locale-specific variant of the Chinese lunar calendar. In that case the meridian for calculation needs to be supplied as part of the locale data. Need to clarify that the "Chinese" calendar means the locale-adapted version, not the historic imported one. +- An in-between approach in which there is just one locale-specific set of data for the Chinese-style lunar calendar, but the meridian for computation is specified independently—perhaps as another locale tag value. +- A combination of the above two approaches: Have locale data specify the default median, but also allow specification of meridian in the locale name to override this. This is the recommended approach. + +**11. Chinese calendar ambiguous dates, and handling of 'y' pattern character** + +For the Chinese calendar, the value within a Calendar object's YEAR file is the year number within a 60-year cycle. However, this year is never displayed numerically in a Chinese calendar date format; it is always displayed using the cyclic name, i.e. using pattern character 'U'. The Calendar object's ERA field is the cycle number, but this also is never used is a formatted date. Hence formatted dates that use only elements from the Chinese calendar itself are ambiguous as to which era/cycle they are associated with. For real-world usage, that is not a problem; the Chinese calendar is not intended to unambiguously represent a date, and is normally displayed in association with a date (at least a year) in one or more additional calendars that do provide that disambiguation. + +As noted above, in Taiwan this other calendar is typically the Minguo/ROC calendar; in Japan it is typically the Japanese calendar; in mainland China and elsewhere it is typically the Gregorian calendar, often with additional calendars such as Islamic. + +In the long run, CLDR calendar data for the Chinese calendar should specify which other calendar should be used as the associated calendar. Then it may be that for formatting and parsing Chinese calendar dates, the 'y' and 'G' pattern characters would be interpreted according to this associated calendar, rather than the Chinese calendar. + +In the short term, ICU should specify that parse methods that do not take an associated Calendar object may not produce the expected results for the Chinese calendar. Such methods create a work Calendar object and then clear() it, which for the Chinese calendar will set it to era 1; since there is no era in the format, the parsed result will have era 1, producing a date in the range of Gregorian 2600 BCE (probably not what is expected). + +Note that the convention of using a secondary calendar associated with a traditional calendar is not unique to the Chinese calendar. Real-world Japanese conventions for formatting dates often use both a Gregorian and Japanese Emperor year, e.g. "2012(平成24)年1月". + +**G. Tickets** + +The old CLDR and ICU tickets related to this are: + +- CLDR[#1507](http://unicode.org/cldr/trac/ticket/1507): intercalary marker missing from chinese calendar (refile) [includes detailed comments from Philippe Verdy, some anticipating ideas above] +- CLDR[#2430](http://unicode.org/cldr/trac/ticket/2430): Illegal date-time field "l". +- CLDR[#2558](http://unicode.org/cldr/trac/ticket/2558): Chinese calendar formatting does not look right +- CLDR[#3672](http://unicode.org/cldr/trac/ticket/3672): Value inherited from "root" is in error +- ICU[#6049](http://bugs.icu-project.org/trac/ticket/6049): Intercalary markers + +New tickets related to this, which supersede the above, are: + +- CLDR[#4230](http://unicode.org/cldr/trac/ticket/4230): Add \ element for Chinese calendar support +- CLDR [#4231](http://unicode.org/cldr/trac/ticket/4231): Add cyclic year name support for Chinese calendar +- CLDR[#4232](http://unicode.org/cldr/trac/ticket/4232): Deprecate pattern character 'l', add pattern character 'U' +- CLDR[#](http://goog_1707162891)[4237](http://unicode.org/cldr/trac/ticket/4237): Change Chinese calendar formats to use 'U' pattern char [must wait for ICU format/parse support] +- CLDR[#4259](http://unicode.org/cldr/trac/ticket/4259): Chinese calendar data updates +- CLDR [#4277](http://unicode.org/cldr/trac/ticket/4277): Remove \ processing from LDML2ICUConverter +- CLDR[#4282](http://unicode.org/cldr/trac/ticket/4282): Chinese calendar formats need era, Gregorian year, or ? +- CLDR[#4302](http://unicode.org/cldr/trac/ticket/4302): Fix spurious errors with chinese calendar (monthPatterns narrow, prettyPaths) +- CLDR[#4321](http://unicode.org/cldr/trac/ticket/4321): Skip some date pattern tests for Chinese calendar ('U' and other differences from std) +- CLDR[#4322](http://unicode.org/cldr/trac/ticket/4322): Fix test errors for monthPatterns +- CLDR[#4325](http://unicode.org/cldr/trac/ticket/4325): Fix test errors for date patterns using U (availableFormats...) +- ICU[#8958](http://bugs.icu-project.org/trac/ticket/8958): Use CLDR \ data to format/parse Chinese cal dates +- ICU[#8977](http://bugs.icu-project.org/trac/ticket/8977): Use CLDR \ data to format/parse Chinese cal dates (J) +- ICU[#8959](http://bugs.icu-project.org/trac/ticket/8959): Support new 'U' pattern char for formatting/parsing Chinese cal dates +- ICU[#9034](http://bugs.icu-project.org/trac/ticket/9034): Delete obsolete \ in data/xml/main/root.xml +- ICU[#9035](http://bugs.icu-project.org/trac/ticket/9035): More ICU4C chinese calendar format/parse fixes +- ICU[#9043](http://bugs.icu-project.org/trac/ticket/9043): Chinese cal dates can't always be parsed - design 2-cal solution +- ICU[#9044](http://bugs.icu-project.org/trac/ticket/9044): Chinese cal dates can't always be parsed - document & fix tests +- ICU[#9055](http://bugs.icu-project.org/trac/ticket/9055): Integrate Chinese cal pattern updates (cldrbug 4237), update tests + +![Unicode copyright](https://www.unicode.org/img/hb_notice.gif) \ No newline at end of file diff --git a/docs/site/development/development-process/design-proposals/consistent-casing.md b/docs/site/development/development-process/design-proposals/consistent-casing.md new file mode 100644 index 00000000000..f75f3c7e097 --- /dev/null +++ b/docs/site/development/development-process/design-proposals/consistent-casing.md @@ -0,0 +1,157 @@ +--- +title: Consistent Casing +--- + +# Consistent Casing + +***Rough Draft*** + +We know that we need to improve the way we do casing in CLDR. We want the casing to be consistent, so that we don't see, for example, some language names with titlecase and some with lowercase. + +## Current Status + +We have the inText and inList items, but they are not consistently applied - and we haven't had tests for problems. Here is some text from [http://unicode.org/reports/tr35](http://unicode.org/reports/tr35) (I added notes in italic): + +\ + +The following element controls whether display names (language, territory, etc) are title cased in GUI menu lists and the like. It is only used in languages where the normal display is lower case, but title case is used in lists. There are two options: + +\ + +\ + +In both cases, the title case operation is the default title case function defined by Chapter 3 of *[*[*Unicode*](http://unicode.org/reports/tr35/#Unicode)*]*. In the second case, only the first word (using the word boundaries for that locale) will be title cased. The results can be fine-tuned by using alt="list" on any element where titlecasing as defined by the Unicode Standard will produce the wrong value. For example, suppose that "turc de Crimée" is a value, and the title case should be "Turc de Crimée". Then that can be expressed using the alt="list" value. + +*Note: we have inList items currently for:* + +*cs.xml* + +*da.xml* + +*es.xml* + +*hr.xml* + +*hu.xml* + +*nl.xml* + +*ro.xml* + +*root.xml* + +*ru.xml* + +*sk.xml* + +*uk.xml* + +\ + +This element indicates the casing of the data in the category identified by the inText type attribute, when that data is written in text or how it would appear in a dictionary. For example : + +\lowercase-words\ + +indicates that language names embedded in text are normally written in lower case. The possible values and their meanings are : + +- titlecase-words : all words in the phrase should be title case +- titlecase-firstword : the first word should be title case +- lowercase-words : all words in the phrase should be lower case +- mixed : a mixture of upper and lower case is permitted. generally used when the correct value is unknown. + +*Note: we have inText items currently in:* + +*cs.xml* + +*da.xml (20 matches)* + +*es.xml (9 matches)* + +*hr.xml (11 matches)* + +*hu.xml (7 matches)* + +*nl.xml (8 matches)* + +*ro.xml (4 matches)* + +*root.xml (13 matches)* + +*uk.xml (6 matches)* + +*For example, for Dutch we have (excluding draft items):* + +*1,043: \lowercase-words\* + +*1,045: \titlecase-firstword\* + +*1,047: \titlecase-firstword\* + +*1,049: \titlecase-firstword\* + +... + +In certain circumstances, one or more elements do not follow the rule of the majority. as indicated by the inText element. In this case, the allow attribute is used: + +The example below indicates that variant names are normally lower case with one exception. + +\lowercase-words\ + +\ + + \ortografia tradizionale tedesca\ + + \ortografia tedesca del 1996\ + + \dialetto del Natisone\ + +\ + +## Improved Testing + +As a part of bug http://www.unicode.org/cldr/bugs-private/locale-bugs-private/data?id=2227, I added a consistency test for casing. It just generates warnings for now, and the test is very simple: given a bucket of translations (eg language names), verify that everything have the same first-letter casing as the **first** item. Although simple (and not bulletproof!), it is revealing... + +cs [Czech] warning names|language|lb 〈Luxembourgish〉 【】 〈Lucemburština〉 «=» 【】 Warning: First letter case of \=upper doesn't match that of \=lower (names|language|aa). + +cs [Czech] warning names|language|om 〈Oromo〉 【】 〈Oromo (Afan)〉 «=» 【】 Warning: First letter case of \=upper doesn't match that of \=lower (names|language|aa). + +cs [Czech] warning names|language|ps 〈Pashto〉 【】 〈Pashto (Pushto)〉 «=» 【】 Warning: First letter case of \=upper doesn't match that of \=lower (names|language|aa). + +I didn't use the inText or inList data, because I don't think we have enough data, nor that it has been vetted enough, to be reliable. Moreover, I don't think the buckes it uses are fine-grained enough.. I put the test output in 3 different files in http://www.unicode.org/cldr/data/dropbox/casing/ + +The code is at http://www.unicode.org/cldr/data/tools/java/org/unicode/cldr/test/CheckConsistentCasing.java. Note that the buckets I used are defined in the code in typesICareAbout in the code. + +## Feedback and Open Issues + +It would be useful to get people's feedback on how the tests can be improved. + +1. In particular, whether the "buckets" should be done differently. For example, it would reduce the warnings if we put the abbreviated format months in a different bucket than the wide format months. But I don't know whether it is right to suppress this warning, or whether it indicates a true problem. + - az [Azerbaijani] warning calendar-gregorian|day|sunday:format-wide 〈Sunday〉 【】 〈bazar〉 «=» 【】 Warning: First letter case of \=lower doesn't match that of \=upper (calendar-buddhist|day|sunday:format-abbreviated). +2. A second issue is how to pick the "paradigm" casing for each bucket. The algorithm I use now is to just use the first item in each bucket. +3. A third issue is how to "turn off" the warning; some way for the user to add data that says "it is ok for this item to have different case" (This is a more general issue regarding errors/warnings.) + +A broader issue is what we should do with inText and inList in order to deal with casing, and how to deal with the fact that sometimes items in a bucket should undergo a case transformation in a particular environment (eg should be titlecased in menus but otherwise lowercased). + +## Determining whether current structure is sufficient + +(from Peter E, 2009 Nov 18) + +The attached "CasingContexts.pdf" is a first draft of a doc providing examples of various contexts for usage of date formats and date elements, language names, region names, and names of various other CLDR keys. This document is somewhat oriented to Mac OS X (since those were the examples at hand), so I would like to solicit other type of examples that may cover situations not depicted here. Suggestions welcome! + +What I hope to do with this (and very soon) is to send it out to localizers to solicit either sample translations for each item in context (so I can infer the various grammatical cases and capitalization cases that CLDR may need to support), or better yet, have the localizers let me know about all of the cases that are necessary. + +With that information I hope to: + +1. Determine what additional types (beyond form,at and standalone) may be necessary for date formatting, and +2. See whether inText/inList are adequate to cover the capitalization cases, and if not, try to come up with something better. + +(from Peter E., 2009 Nov 22) + +I have attached "CasingContextsV2.pdf" which fixes the calendar menu example (thanks Kent!) and adds examples of currencies in text and various examples of units in text. I still need to add an example of currency in a dialog, along with overall instructions. + +(from Peter E., 2009 Nov 25) + +Updated to "[CasingContextsV3.pdf](https://drive.google.com/file/d/1mvXlCSPhU87nl9owW_ZeCYHy_pJ-RqHL/view?usp=sharing)" which adds an overall explanation of the purpose of this document as well as instructions for localizers to provide feedback. + + +![Unicode copyright](https://www.unicode.org/img/hb_notice.gif) \ No newline at end of file diff --git a/docs/site/development/development-process/design-proposals/coverage-revision.md b/docs/site/development/development-process/design-proposals/coverage-revision.md new file mode 100644 index 00000000000..2c1efcbb132 --- /dev/null +++ b/docs/site/development/development-process/design-proposals/coverage-revision.md @@ -0,0 +1,64 @@ +--- +title: Coverage Revision +--- + +# Coverage Revision + +1. Propose changing CoverageLevel to be data driven. Rough thoughts. + +Have a list of paths + +\- ​/​/ldml​/identity​/version => NONE + +\- ... + +\+ /​/ldml​/localeDisplayNames​/languages​/language[@type="\*"] language:​type=​[en, und] => Minimal + +\+ ... + +\- ... + +Have special variables for + +- this language +- this language's countries +- this language's territories +- ... + +2. Current coverage: needs review + 1. I put the tentative results in http://spreadsheets.google.com/pub?key=t5UzIpaSqcYBksSMtZp-f7Q&output=html + 2. The more detailed files are in http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/. In particular: + 1. http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/summary.txt + 2. http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/samples.txt + 3. http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/fullpaths.txt + +There is more to do, but I wanted to give a snapshot + +\- tune the weighting + +\- weight by draft level + +\- add collations, rbnf, plural rules, transforms (if non-Latin), etc. + +From John + +I've been doing some more thinking about how to deal with coverage in CLDR. It seems to me that we already have the notion that every XPath in CLDR should have some predefined number associated with it between 0 and 100 that denotes it's relative importance in terms ofcoverage, with 0 being absolutely critical, and 100 being not critical at all. See Appendix M of TR35 for a brief description of the levels. I think that if we could accurately quantify this using metadata, then it would be relatively easy for us to accomplish two things: + +1). Filter out fields from the ST that we don't really need, since everything we do would be filtered based on a desired coverage level. + +2). Allow individual users to set the filtering in the survey tool based on one of the predefinedcoverage levels as we already have in the spec, or actually any other numeric coverage level that they desire. +So with this in mind, I would like to propose the following structure to be added to the supplemental metadata: + +\ + + \ + + \ + +.... + +\ + +Finding the appropriate coverage level value would then be a matter of searching the coverageLevel entries in numeric order by value looking for a match of the path vs. "//ldml/" + "regular expression". In other words, we would not specifically include "//ldml" in the expressions, since they would all start with that. Once a given xpath's coverage level value was determined, it shouldn't be too hard for us to simply filter out fields whose coverage level was higher then the requested. I suppose that we will need some wildcards similar to what Mark has started working on in his path filtering proposal. + +![Unicode copyright](https://www.unicode.org/img/hb_notice.gif) \ No newline at end of file diff --git a/docs/site/development/development-process/design-proposals/currency-code-fallback.md b/docs/site/development/development-process/design-proposals/currency-code-fallback.md new file mode 100644 index 00000000000..77e7bb3c7c8 --- /dev/null +++ b/docs/site/development/development-process/design-proposals/currency-code-fallback.md @@ -0,0 +1,34 @@ +--- +title: Currency Code Fallback +--- + +# Currency Code Fallback + +The basic problem is that we can't use currency codes that our users won't have fonts for. It was fine to have, say, the shekel sign in Hebrew, as in CLDR 1.6, because we could presume that anyone using the Hebrew locale would have a Hebrew font, and that Hebrew fonts would have a shekel sign. But by putting it into root, we are presuming that \*everybody\* would have that character, which is not true. Our users/customers think there is something wrong when they scan a list of currencies, and some of them are black boxes. + +Here are some examples of behavior I think we'd like to support. + +- We show ￡ if the font is available, otherwise £, otherwise currency code. +- We show ₧ if the font is available, otherwise Pts, otherwise currency code. + +For reference, here are the currency signs in Unicode: http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%3Asc%3A]. Also see http://en.wikipedia.org/wiki/Currency\_sign and http://www.unicode.org/cldr/data/charts/by\_type/names.currency.html. + +For more details on the problem, see the email thread titled "Problems with currency codes". + +Here are some recommendations. + +1. We don't have the character fallback element for any currency symbol that is used for different currency codes. That is, it is ok to have EUR for €, but not ok to use KRW for ₩, since ₩ is also used for KPW, and not to have JAY for ¥, since ¥ is also used for CNY. +2. Even with this, we don't really want to use character fallback elements for currency substitution in general, since it is too coarse. +3. We should try to remove all the currency symbols that use Unicode symbol characters from the locales, except where they have special plurals, or where we have symbol reversals (eg in the US, $ for USD and C$ for CAD, while in CA, $ for CAD and US$ for USD). + +Options + +1. We then just make sure that all currency symbols in root are widely understood and in common fonts (eg in Windows Arial), or +2. We enhance the currency symbols so that we have a fallback list. We put the symbols that are in typical fonts in each locale in the currencySymbols exemplar list for that locale. When formatting, we walk through the fallback list until we hit one that works. If we don't get any, we use the currency code. If a smart client has font information, then he could also walk the fallback list using the font information instead of the currencySymbol exemplars. +3. We have something like "commonly used" that lets the application provider choose to force the symbol; otherwise only the commonly used symbols appear. So in root, commonly used would be on EUR, etc. Could be turned on in locales, or by application. + +I'm leaning towards #1, just for simplicity. + +However, see also: http://www.unicode.org/cldr/bugs/locale-bugs?findid=2244 + +![Unicode copyright](https://www.unicode.org/img/hb_notice.gif) \ No newline at end of file diff --git a/docs/site/images/design-proposals/site_bug.png b/docs/site/images/design-proposals/site_bug.png new file mode 100644 index 0000000000000000000000000000000000000000..eaed221587db43ab4137b8c5200a9fd21e7139d7 GIT binary patch literal 143324 zcmV)8K*qm`P)4Tx0C)j~lubw!VHn5%vyB9?2GN%Y#n8bdR3-~j0@L*?Q?_N*ObKG0eRrK4 zXQ!FnEkz=P=$LhkE>=W`h)&_5L#H}K1etY-prb_)1zsYy|2vbrV^qE{GrxJB|NDHs z!vIx}QjTLqG+@fkyUE^|c6xM7+x!|;s74fADZ_I*5{Utysg=+5YxOM@X<2HNvDW)G ze5-bu5KuHKcVq)TEO|WO3B0oEDw|RJBu+ zGaQ$3B0I<}MI$R?J|OFM+O)~CZ>m^~%c}YWBk^(HLv`P%3?|12*3PeqJw?e%vmVe%@gY*74Lb z3U1NYvM}W(5Y!v&X8hzD{fmR1d{qmuz&Va=0s5~1H$MXV9|GGS1Bq&2s1=dRY&W>_ z;v(k)bmp9C*UV1jwPsyEqIK|Sh1O>qO$}PgvNYf2X|C{uTNLRgOj!la*l4~Q(c@Tn%LH-wCL(4H<0gV%$`1SJ+Jo}w`VwD<$#&*8wxmb%C_P> z7paNV*yHh&WX4xiCm)mZkUZxV2W3p(elB$)L9V4eIhpI1nqA!6J~J`IGm@-WGZUTh z-~7fcBxT-x)ZBF}|C?uRk!Ki%1pyN_?>00f(Tf-w;lM=>8G1}AOj@O1&}zcNd~MmI$sFQpd^Oai2xV%-IOEB# zW%ot0#W&&STg&#Z=~4T9_DM}8*Rr~JW-0o7He3yB|Ff%L(z2`Y@RVv~cmzAP@5AY~F1TW1 zfKUiCZbkw#5}1*|j09#R@CPFSiv{Bo6G(}%p&-ozyUhwqPw!CZnP*Ea`7fZmxnNc7R;Ot0rN2HUu7?%_B6gM_D zj^H#FKBvPDhuw~#(3f6%YR%JiVpvrxH; zLY4pLbcD4KhZ2ZnO~M7A{E9%M=}Z@PRvL;naZSQC!&t1G){?Tw@;}3=g8VqNnNKCG z>DZxAr5q(MB9rrVS{}9X_{egYjv&)h9DR)RBFO033Cmf^QZG}1i{MS(Sq}t7tE==# zHgy{GP47fz!k-~K1L6Ed6iJulgby_cG}AEXo5Lb8|6OlN7Ah+&-*eR&;f?=3PWk`4 zn3_TUA0+|lGe<^!7#SNzX-S^eWK22qjgF)4_$g$kW}>~P6U8ODNJ&mm%}c>Wa4N;<4e(C&;; z3dY3u$MRaNHZln^t1Czowlw_7v3~Rpjw3lG4M9JZYfJ)SIG3FCpRMtgL;{oO>t%+M z(-7m3#tBfb&^+qLBsIIN^T|lS;fhh|8p(}~d6}0u*hO1T+cOI-znZ1GV%*Z~4OI2C zQtA7KIw(6k(o&MaBc89-%ik63o@ln{E?udLUL{^H)(Gm0y z4k0!v9m%mSll(bV=V&NE`9`Lq@i08l2cJKP^z=+vKF-XXX$Jk{7~=pdJ~kfKP=NLA z{Ac#sD2^Oi>=+d}Pdbs77>CKpfGSfd58u!LhJ0g4$;g4r;zwU!5BzYj?xr9x5oErk z9x#8ZUPR_jx^j_mkZ{%*4&WwOA8BXzPx=tFx>%PO_OTT&2MMIv-`9tP)GRp2Q-I1u z@-oS?fz73C`G#f{xd#J&D%@z^ephi@Ip}0tVI4Q};T`P92xZ}n^B|d>hH3~AWGJ!V zBnP{}nYHf-xy-zruLNxDSO-Q2aLpB~FsHoWtbx1q-><*38K=+mpmJ^zlH;w|yKfI1 z4u?u&a&i(?Rh78?rYrE$JKHepcnvPhiN&6>awPiOF}ENG`%bpPTCfZkG@pd!&|b7u zR8nWLU$awzu^qwXw!>nJfs>7AXN?7a{X{nodhPh)1^HN2l7z1A4s=oj-gwj9@Q?Lk z{p&Ac+?|UGMMH!w zL0W9^^&Q8N0Si`?l&MTf;|>P>gbl$uF@P7}eghs)0X$1%P=8`ODyuHRp|(?4RK65W zD?1y}PHgZp7Ppc1!0AJ%-@g@I2^J365dImJd->bt4K>+zbn-!Z3IZuv4+xU6|;u#hY($#jW?<54S}WZipSIpCf-e zhECVu!_B*qk~JHtS*wxaiB%n*Os{1$tY$mpQ}QQa25sr9lx*0s$-<;Kk&}`oBPDGP zL|~cd!j@Ox!bNx8iv+R%GEEzmt#qmZDgrz69#nj@U$i@5hZk=@^*qY1xDT^4T;!Bx z!19nz&hE5f$5W4^*^v$>yZFl0*PtRRnTe3z_#k#S>_KJug@~~UPtvJQ!q0LH4macV z*PlmHZU&BLEy1;G7P1ozk}hYR%!O5yKmEeLl!c7$g(n%LNM-JB-i||^PAti@qdl08 zs+>&L0f7>kP{vG4WGXW9PfqaNfso{1WE2>|kpriYkr~3~?R$}$TLO2`jhchKxcb)X zVfFW7!;??JRaAn*#~ZL>eik;pyA__)IHb*8gE(&!a_3f~@$g>ES#cQ>n72svN%@R* z;Ki5U$2Fh-4EDVA5OP+27M9*!7>HYp3(NAUa0BF%bx!z{89uo+%2g&gQXVo;vPnGi zKoQ{R))!IN9fQK+Hl*b(My|)f_GZEE*Pcae^q zq-SHj5T&NVm`;eWA`>NJ%5{9O6?;#2VR_ji!m&P%cHr%opF-xsrO3=HLSbqi+odQs zC0)fQnZQ8vZtU9KhIO~x!um29Sq`f0veu}!3suLY9S2$7Qhz1y=i{Vq&$$1Y5|H}m z?supOL2FwNn|@@A60@MV*f=K#Ne(o(bl}*r9>mCIL3R~BuMcO=bYpg5Ibvd+9E35j z&x`9XyAGSETV8zfSrmNXt5}zngWm1C5#(Ss!4rcR(OCrLWW$13w*)xYIW%!V*oO9@ z`S4A+@Z9k}T)iL(U;N_Tc;n5@aL2{rbmKPkTg&mlr*1~Tdj^Nzcmc0H`w%KGxC+&| zA-wkPM$B5i4$hNXQPb9oyvmDEnKq8?JN9GHnTB;2EJe-s4d{!_B$HPlkr_L_V>yWg1FD+V3utd zTXye)yLcgHS-WwhIe@FKy&O4N^{~6L5HErXdU3pwrqVf!Ib#gK9ph3R>R8utJpcL@ zgi>;_YUOeadL8h%LfH1PCzn{Se#t?MCl7NBvzb*t%^4 zMp9^xj9 z7vkMOQ~eHX+IbLZC5y0XZXQQ4?;s_2IhIv8@!kiUQM}?xxY(h_#5mD+;xM)xIDpvV zC0Mtjnllg?Y&fy}l3S3}wE^2|4kNKJgbl}hxOh<}-hAOH1n$g3W#S;-*-?unYi~wn zb`tH}c2>kVWMvnkJ7B|DM0&cxv9(HV8 zj}BJ~E}1_Y`*zpBnvf3L&}npe$5672?Je7ZjUT+vx|4?mX}x&)rESQ#zW|lRxd?F9 z>9EHjzpNVbiqcr8UqNzCIoi&g;b1d_14mDCpp}mm6uWWa6@;pwNJ$1wXu7wO2LeYm9)!N2`3 z%D?I!Z{S)daa zuDKQsTi?SDj_mw44;x=MK6v#>jM!5!*0K++OIKqSNByFGt3nHrMf2sWO)>c5wJY%a z8y{jx<^70>E5`r(#{KyD&;JRbHJ_o4v>A@%YcOZYN-Qf$#?OEFFcNa}ai)gaIp2e^ zU<_jI6BtR$!Zph;M4X$W>hXRIpBYB-ia42rAc+fsF%*`sw-s?|WvECWMdPV%xSf5d zt67i3Eq46*SFgd2*Pp_ery5tyZYJNq!N6oZ?!N5~y!!0R`0aB~!cNoM@R>d6T)rBG z87z>H12G<&YtoX?wEsfaP9JZ9Nql^dYezMgH6I5R~&5P9r*1_FCi%}53L9GPY{0%x!LQIlSY3+7yovB_99E8e+t zKd$}k-FWT!hcKCx4e!yt@Ok{mtGXHmgM0DV(@!HicM)#8#ERF}Gyl$UWM*5Do9@8A z70SbqP4pd zu3!%QR5Wf+0_&g$K5B9&^N^IB4Ey+qQrJ!^Y!{WY&FaA9U>kOy?#1W7c_-|LYp|cD zyyDmpTKoHvm{g2`Gxd0pri*2lUXS^+QqXj&154%Q8W)Lyh6 zI*z-)@~3e09>I>5Zru8X>+t+zPhj2WK8GVOJc7EBJb3+M80&3d9)U03d@+9e+IAF` zS0Q_THJXAA$Xa?aGCeNPmPjS$!pLw3EbeTqD)XT3Xe&ypmY{0&D(rpZr>N_vtS4J> z)ZxSMgd3l_bSYkX_z*6=?t1Lr@IGGm_oFWmkIA;Z7+Spq^H;3G;yERpF^e^VxHRvN z3=P2*Ux5{s`FQZJzKz@d?B8H*d=a?|)*`=mC*IvRi~+hEz2zV{2Y6(8U1yBqWXkE*}0S>n>4(m zG*vsDEM~ETX;vYz7&z>-%+W#>A5Tjc2bvQTezdVYdOQ>AJu%Ux6q%Q6Wlm9GPMYay z!Ki6Eh18CAtmI(o{k^*pI&&H&Nl8ixCd9{bz{^pl*P z&Jj09%<;L{xxW@`uHnp#v!^Cs3g%sO6-R$LTzhjPJ1ZN#8+M|*YAurN-Pn6%5Q&^J zCM1y2KsRq4r1}j{1g>TQUdsleO4)s0M=*A!HO}QS;~H!qt_iE>4Fl&V`HD%)xW-y#&W_ zB~mz|#_&lTY~;Cx>|9K?v>+oR8OO%`$gn4%hYdPCJ^?AITma?FR;JX6lvi`zZn#JN z$jnLv~krD?-U^4{G-AfG;))m3g^nZa#>HOh1k^ z97Sd^XGmOQ8KaHa8?-4o#b;OIqOt`j%ub*@I5VRO^w6$%;pB{@bnYx1*tHjBrP&ze z8c}>;6bFtU#L45$C@d*p1s&$XYCN1{P9$d(7o!TUm{vldofI z!$AaMyjW0CfsXcO?63DDc~%9g3V>(d*?{~j=fTCb)l9CZzP;-Z7E|F)9&5l+zmN4O zpQE@zWMpTf`sUm5rF;Jv)%X1!DhiTlD`45AQ(^g>xN=nmo?rhW&|880beh3hk74Vk z^_b6@ie+>V+unTvonwhuvpA2VHo}+3;6u(-7N=X`q|8SKIEzi-AdF=eTR0aF+*?9B zpq=&2iET}TT&tQ7%kXAY&YOcBJGa3VvLP-h3kB(oIKUZrX|5Y-ak0oPn2ot5i8#1- zJA51{EUR9H(E2B^>tqsATtnD%=rBAvxrps*r1ipsY);b;)*Zzq3$I2}tc?Q*3%oS{ zCB()elLMeroE65g5g%x%M^Qm8JX~8|TzL(O;@k1zUe-a@IS&V$sTpZVv`!$Hoy9tm zgn6Y4u(aHc-TQunx}JWlsbIcYznyI04*NK|x=wLMco54MaE9A-6y**VT8>hMc2RNw69{R;27#J9)InjqJueu6zxK<@5McLV&laq|Te)dOP!|!b8 z8oGCq3XID%ezr%>z6J+;%2MQJ{XabHMZtIf8daV|)IIQJT=bo9W1Bk`$NudhSmKh9 z#C2~c`%4)=S^oUb|336*fA&STUn>`y9eC!+7jWTaMN}YJDCPRl#N;R!!UwQn!vWm+ zsn5_39>PfHN$lKv0-3Wb*igq2lbnh1{%&r81kSW~QE{Xo!NpFHi`Le$KJ3}?0bYJ< zJI35e_|~_+h2CQa;7lpPytxH%aLLCKn&d2FF9J!0$Y;YpP}hce)yt8Y8c*}a1P*i2 zuY1&q#f#>%^J#-Skt5yCV`v<5VNqcs_U^64tcnFxcAcm@If8i$$}l|C$%XtvBquny zwr9gz&;ASgQZKBl;?7mbO4Do%giZfCvK7Hu$3d(U8ryIW6_F*5EJF` z)?qAMvIygSU9iW;aZ!DO9TT^cQVEKJiizXlyZ~nl6JErpWT3HjA4Y8{m|u~PzOF&e z=Hj^_#fO~P`Ec6&I8{@FV{P43u0@z%nu*;zcOyBkf@Y&E9HufG3ZU2 zayDLz+QvRqEn0{!cAUeLX_z}F8QuM3D9BF6zPa^q#2a;A;f4=FCGp zXWMlg@RTiFhP)IT59jwGYgQ)C96yG4Uw;QBmtKp;jc=mr#xLN4a&GLP>CkXulIW(1 zZ47ZpPL!1!nqGU(Fq#$HnT!cOI6x~x*U1{z zbw3s^o)2#q%OQvTfO8C6H}67xMkz}2-RS8VB_DZgw=&i~Pd8&eJWoM=^1x))v~kOR zc;XY$(%8&h?Bi5OG`q*da+6n%nk9A9+Ht|kQq(teAdc3ALx=0sGKf?QStI5y45Ve2 zB0WC=8Qb2+P|X1>x&K}?Q6UC=qj09BBJbXNaPXgh&Q@nd^&<~)dB}l(`o~9L`Nm)T zF!VQn{U>TsT6P_7q$%)NLjz5QPA)7<;|@`4jbQRLEep@G?O)ks$y;FLH0qj1F}Jdm z<|XpSj!RHv{X_aNp)Va(h<1IoE0Xz8>8W(+=i;FXmu!+}+1@D%OIy$;0m%pPZOjKr zYPhnIMW>_W!-Qnot3U;sa9Z1D2zeKtgr-4X<4s$mk1HQzQ)wXEiE0RTkVRAaWLX@(~hQ@`X{FY{;l8FUcciBC?gT zm9%XH6gdyDoI6MCDCHK{APdGqIH94o!m?rrZLMrrUc_@SaVa-#gNr6JtsVu@)7Heb zo*0xCXDAwy4@u|ru^RXj=b|WEc7bvWF7ai91Er>Dg(z@lQ>7`q8#1)pC(*FC3CRU1 z=xORhc6lKZ;>f>N0L0du8=TRQ2jN}(vRhEfP4Xf3d{MGejg_2O zPer!kmyJqXs3R5fMtrGPQn!V+R_{dSq{xaR=}H>X_Egz2Ky7A{ddj@Y#vh}-8TCbQ zMGmT+kTcnqOvY4wV9KftB@a?pWs}fg*J+lMgIkd^SWZGy%0b(7W7J(KhsgYy+Kc3g z^v>6bNomIY&y;}ZjLq8*(yFx|1-YD=(@7sUFyO@~XItVXgFbxqf$Q+_<8LFC)-$Q6 zhLid}L5p9@=?+|f({jYp0(k5nehL~WV5Ny&8i?wT2qU_|zn}`Y{_3aFH1VD9{Dg{( zc1zj)B}$5W6)&Y$4W*r0yD&#o|E=&HebXJxVt)R4K{2uN3f2G9!@G~u4nz@|_$L9(& za$~^%d%8m&1VQQSOjOOwM1TK~8iYy8$y`B6=32E3uF6X0(oF8crK{)S(9u(jW{Ns< z;&sJ@uxLRx$_u!uDt|3{Y4Nl6bjj$`U{z%qn(UYKmOs|j}no@ot=(W4AX^2a}@m^oz}VNN8`!6fosG``bL=H zH+Y(kZgiOW-Jlaq+n^`m(eUOt1J9si#F^g>zX2=H>EI+hIxPu{bkWodN|8`g5{eH0 z&wV$ziRSVnQZ+ygR3#e*8sUN}apw1rAU6{gDS;WWMam=mW)@7i?uBE|u5X{vIw&(P zCpTZn^Q<<+AhEK@Q6ndh?l>G=Kba1QxN;0jL}25(no@FS!O@DqyAXZeQRL@m;_%^G zS`=uK=;2PU3oa-_QBj^UGl+RZ2$`Kx7Ao9$(E(^VnQ{_myvx*09GMf-mfw9I=>%cK>$K(7NJh~$(vndASEeDMBhJ9p-ZaFBFzrQtuA9MaBG%Qf!h2u2- zg_2Q%MruM+Ie`t!Mbe_v5W;>Fxp1@=ssHL|dhta>MP<#*kb=`uBXG{*(TI%#mNiyI zpAYe>Y!F7k{H3l+&RjDx?OWwKW0N5}#@p zrhEzw6-^wYZG`FSiRkG`zam~)FBOluu4$q&QY4T78cc@UtAvRYe1X;JONhXj@}R|P z@fy`BSe>{=hreM;lBPF`M%wddHPU0e~kse{Bp%c+VwTHw_g&RJVwaBOlEP;~? z43a$|q-V{Fh|^x!$By(PG{}7vRwwM4+#A7N#D1Pz)VPrrG9~F#r&_UX`ysWIp-!2} z8iK5O#d4ZAG&smJVX-RGoKl!s3DjSV^#zm6wYabhbU+rix%@PEuAQ*K$*fMj8wm(; zy>gh-H_|l9TfmKE6rAde#K%zn|Kunzc7e>VO7Fb1 z!H3{$(h;A~Rzi`7N<@oOej`c)(q$)sQ%;AT3eaIA%H4>SI5UFrZr~Vjrsr8a8gV*~ z@%ryoU?E+B$=w(#?@FdzLljx^&l05HNKEsi7oV;l;+M6Lbk)8OZOtpBvNdW)!cilUqz*J2O zOGiAaD+&u#MMeAwMvyz3V`F(Lb8}Gw>LyMQ(6+P(b6GIw9I)hgkUf&V8)*jrqN=0?7U==U2QBe(NkVY+Z3iU zsV6NFGKIEMW}>WR#%nYx0g*w#$lw6a$;GNe-3H%ga*C9mKW&;$3e3JpK;T6I4i5|< zV}Q)G1LsmDh|X+UOxbNQ#p zDW4fED(Y;ShEOArw3o=*AN@vBW*jAZb84nY-D|Wh^~xU;gkCzPG|Z6^ka`*s^-aPe z37RM|CW4p-tCP_%^>}$0UIWD(X5dU0X2hwdfgBOYm#Ofu&+r(}C=>}+ayv(Skh_&_ zz4ZXkf(5w#b)x$?e)hzTSh096Vp9CLDD8__l6z&Cs@9IR*RTSUR~g06<~2NOFdqij zJPz*l-~HYWe0Xp#GSW)0cwr8X*7o9>TQ1^O`3YV}B`2+?=TJ^+AKG#NZ*Sj%#Kdge z{OOyJ%-aq&ZP<(Q>V>d)+kr&6L4bE1%KbP|PIlKFKimR)DldWTIDr-)&)h64=L)}e zpP}M6APP>5edl(Phn??k!xkPQPED=AO}AbI2dAlW5KmK3G72X?hZGaM2Tx|DvcaXZ zy@OYnOyF44FfLkKg&+^@$^DN`o+2Ohkq748JWe)qVCR)iufF&!w_n$yZ1GZj>ZWVR z_ZY8DiRI2l-ptG~MC-9S498KX<%ztmiFZ&^sZEy;+3i+yq?g;6(-A+}f}`9vCyuV8J z2_JgtO}ulU28*w}3pcDSAi=}5}w zd8Z@qqIRMX#b5a}PXutRF_p9;6W~GIq?jITI^KmmODl%QW~26<5Ap7{t;k!v3dOuW zD8|x(QC@N5p)#F&;T%|an%i&&IqC)SK^b|HxzjQQ18s-!>nC1A!A0v(I5~o{6_q%+ z;}p@k*<}6JkZvJtvlDl?eBv-ry6Y^yo@7bZtmhK#mMokIPl&H^zppa z=N|YR(qhR16|$@~8ZwX>T;xDQ&EpJFDL4rUJ3ZRKSK%fA6|JU&I)n}%hSOmq@WaG4 zk73q{3RY80-B=bGMVdlS>WO*aAfr?@Ql%+SO;06l5-`%Xa0VYZ|s8MVZ#>8!{| zMlT9SsESAaOpfuAre>~XxcC(T14idYje@jzEk;sgF6F_|mOM0M@kI@~1Xlyll2?BD zF#>tiM9_sd=7GZ$^(H^!mlZE7tp%DSWah77YEZ(T(3!#!uN0q=Rn_*Qvd!3YIO^@BU-U0@kW3SYUEu~A+F+!AO^1n zxFoCjjSz#5_Ac?7(|yteR52S^krcIRMp*TqsfJ}SML!aQ)P+|gp(!vGCa=24H8uoP zhgA>xF>o~q^(%wy^_G=5UbzCJiA`8t(SqKD8s4bGBPP5%G1t9_{TT1@JcrX;oE9q$ zGb1C5e9AeJNGHn88WWEq9^x$J`H^9sxDN2r*R9)YkjXm>$NTv{9fu?%9j1l274zn+ zi%aWHjpOs*_&Qecj87L2>*mk71b1A20}oq9HD;X!xiLE_tB|*%)?p-+1sAW-`EcV7 zxbt&4`xA3!3tC6~=xI61I~I9c1chgouaOhUgDso~9;iJ&i0t$fG@LpEM-FG0`|1(H zdmBenm*IgssLSFqW~A`uiab>1=V9>lC>B)m8lmQ` zc;b}DerhA;UAqiJJKw?!+fMQVVD7q!;Q`ahQ)uHIbZVVz8gfzwF}w${dhudZ zFW@(EDoQbDRw@$G(|F@J?*g3Y$8(QAioF3h3JQ~ck7EzhBsvo`BY_zS%t+urNdhN& zg5ZZyFvgplZ2W9d9`6fv)V_clEL(A%>o5uvw8PQoN^J)2l@RI+^-)IMSR|> z5NgMh551twHfz?b!s-PJxie!0=5+Na#c-~3Vxmu+{6JZ2V;!0sPvFKIuEL#b@8ESJ z{Pq@=gPj*XW>)%0-#_h4MtC`Rs1|#8fvTnLSu9(z3|D;m(>T+18oc8ODY3IKi@Z-l zuF$cm8^)*0@C419ORBSI#o=uQAt%N;n>otsb`lf&(7*V0UX^tv>{KLIeBoX!8wv6o zQt|2n1&c*KGh*l6gLfccjmN}DFUGm)BEeRI;zi5Vx2EKFh3TB!eDLzCn|U*OBWjOs z!5z2o^BI;nZYNE~C@+m2;kUz5d5zHI=qLuN=fjhhrp$-at6-j^;EnrFKl(h)13}&i znT*@-x)p=IN!}Bf3J+(hUUw!I(M%i5J0s=Bh>udN)A2hKHY0%<3Cu{~ze)n$@d>O* z8^aL4^BBsFN9M#4Uck;9JmN<%VWH_Te(p!IV)@?p{xy`HlZB;Aicv^Y;Hi_1Y9j|V zQy5V!TC&qkZtL*+xQN7nc;4$LpY>2?QDy8DJE~^;(jQ@)rzpm89zYw_apmILSbqLO zQ+R?W_EOq^!-(Oel}F)^kLzjko^5V`h~dX5wX1iubR}hFvsJ`|Md`e??mL341TjFa zFY0N~qP_DL8P6EW1C`igL z`QptK-VykD6^i69F)>M9r6Sk*NWKI>T_eP&k^yO{kA_Cr_BFan4&1onB|S+;c2OoK zCTe(0PtoMM4ymf^gZL1R6|Ar$PLhn2v+y7=TD-6yk+cw-iq?QkzbZN!DV*38U_=>A z1^-UpS&Cd}OQPcFH;Gyckic`TfvL40V+~A`g<1nr#P}l%143KyBb+2EfBfY`TLYsf zDpOi*(P=1Pg);RcB+P4II!)tY&X+<`!i~(KgljU9NNo*F$jYBUYHMIp>e|0Z?8rBQ zD`HZ75oxP*8D zU`2~zDiiXnwTmfe`V@UFL}QIeMw#lohS$JUIOWRp1VeTe3srOd6#J2Ysd$M~e5)Ug zt~vjLZEAPIw?SIFKlY-*_6y%DdqVj!kKX@eCMwM&oE<8rBr9<};^f;2AKH?`OkD zRvR-1(OjrFovcAMf=vN1l2yRd|AcY%X!E<-KRxz&gigo9bYVKFkBB-eG2t&iNP~C;> z{KTpw8NK|pPuOB*L`FR|3kN?nGs6 zz(9>w7)5y^03xG)$D4r}Nmb|9tR)p42{$kd!aAnj8z|PJK@8C7r@#^209TaMi%Eg$ z!g`mM|a%R*N5ry%QKSGD_@{m6@s8qBylg-%~n1-5>0f{o15S0yu1T}K}mAps_ zQepTvWkM7J!UX>eyPA6EQ4)SisK0+eeS9xQ4)3!gQ1lcVf@gGXDnNf1h$$#@Pom{Y z1Y}lV8m!1!4%lnB5+;5+WkO`S;eycU%UDWQ6wJGD&Da|9)USyn6=-BN+&qLWvop)p z9B%R(G)1IJWPFC%6gUIGgk$zbM+*z#F!4n5B+N!65J@eJtAfqQ2C*p!m6kEMP@o!& z{3@9U4V5vL1Ov6wo}w8k9t~F|Yy3p;%6Re}rmJ!(!zsZNr}>O`si{*bNxZp*%RAkF zw*n*UQ{2<9GaRl9!lNGe`zkQm5kAHbWEw84z!Yt+0qx(tQ(YzH;O)XjVo{RQMJ@7| z@rTBxG@7tTbtc1wBOpf3jFgFYR*)$!?A1}jg(pY`J-yT+#v;3{ohhDFoJLV> z!LmssI`JTBDO|<0R*~d;PV%iJwI(333cwHx*BW?xvSu7-M7Z|S&)RJxJ+-K-CClVU zQzs$mPwiS{pphqmC6Id6g`;f@Ahz(rHNYTmbq?`Lt|_PSt-eI(->X zNQ@+)>^7>B6Mcx3)3+0)N=~MAS1!j!OFX$phw6N4GVX42KYr^6|V5j z+-e94+>ilZM1FFZ-o%PR3X5H#snt-nW9hbar{pP!{9{X!@>kI+TuO-bR?=aldkLnL}R`oEIo)NDzq1q}nugaUO5vdgAS8AvxAp=Ei z+ESaJBt*)H91vH;p~*(Vr&2NFODL-zH=Y@p+B-zv;V zkAW&{`n!md3>)+mKa4WyXk;~5`Bm)6lYg31p~^euGvdyEDoQ3ml`ox`%7;POs31%* z+)Squ4c8x2kYe3HSN)G6G_nz)z=UG?-1)rrUhcy%cao6|+t~q0Ry)VLF&Y@-)kjXG zyHeq{#bAuPP5wKagWsMB@L$JRC%w$LyL5Rd$Kc#&fW>t=Lxdl3#8m7=?soz>HKs>Poo=&AAaL$ zbnf_IDN(LN18CaxCUO_dM?(H=rW;v4rZNqqn?15)(K|ARF`ij-u!D??cf!gmx~99j z%Z&FQ>9=t9(%ZZb!=1IrUv!81;H56u|Hx#1Z(8yZR6jdN*_mo%ZzrFA5czy$8BLR# zY=#;f3h>Lc0qzpDbH^_CS?L>&rU8!#l1(}FbzKW(`iL*?ErrJLc6p=hFEaxtvUR_ zZ8FPS2H!L8lPG}*1tzno`r5--SiMa9Lh>{@5@mJNTZb1qUP7C%38SMu7~)?7vT*0@ z&*QpT>-cq8xd!RKu1dJ9F6~_VoGi^Oui-O^BbR=Pk)mS(OIUJsd)HMHbvnHfb3(a%>@A z)*Toc#ZR6+j3IuMe(gNsPV0!n&k4Beo`<7nCjv#wFxut9>A(3J^8V~kfzN&&7?)4U zou8A&f8ux#YTJepO!5%P3EMyiE|`~u6kZE9m8axBdT$7Qajdhj%=JA%)y7h<7FhJ^K1?Wh39lU%h`Ei58^8SFWbf0 zWh;E~vrvk+Vec3Yzp)cF>vv$1O<~dPt1-W7A{Xar|y z4(c1L!4LNS5!(8{i7zkw5*OOePhrTYS4N$`uM_3B3%SwFBWYId($-{cQv4fWY`zf2(-aL+UYX8QVv zgT--mjO8Qo$(EE$Pfri86Fa45lX8A@lz-zqODTV{&VAKY>yVO~dj4&XiP{`7NGVw< zDV&}8a7YlnZHFTikP#(yVPe9Mhqv`&u&W7Ir~3J&UJe59z7(;{^XqTC!NEcTs;U-{ zN3Bm_Rrl3QGw%Cb0>1V2Yz|h|;qU+MEv&j|fM25buw9xlXZ)W82}IOHnSmW|sHN3P zS18i==>3n}tJgKrjfa~b!hD+M+Ix5K;$15qtokX+l9%v%Eq2VwOu)1C|AZYayEw|y zMrj=UtI?~>0wNtdH+J$pJp){Yh>kNLjh1da4Sv|!5yi$eh(_NjJktCNEOFYNc04>`D1{i)S$lJ zG|tLBOtB18e@t>M>W0;eP?lDKVa}+uKAMEYBSgqtfDKhP#)$iQ4f%U~0oFWSjXU4E z3M-f9VL|Q!3=fV`f*PJAt#~7i*rUIO`^2xoyR+0yBNR5MmEpMaXXpqx(Z2J2b|xZU zJw1(a?VVx5z5L2wkR3sD08Bu$zt05X%JXrchdX$fhvWoylCyZ2ygV02>blf{XffxI z8Zq>2=uagQ`llSJGEivu_4F%xf~T@B9+Q*Vm2ZTjUSB`sZ5Zxuh9|aXuk)8~vs$xv!F|D=wHGi0HZ zDZ|u3aXr$(*~H%3J^0#|uj1#Ye#jeTT)6M@+c9Tx2~H=*p>@=TjT_d(N0XHd@RXE@ ztN2j-XdFrYPaSJV{J=h3P;iFRCM(8UL+Cm)2^Y<7-lhiZ*xsqr(0Ee02CjDLk{&(AVFO?(S|iGt>q>%m+zO-|`k4n!PO^ zy!UcDtiv_P&vm1#;YC<_*CR8@PZ*JaV$>uHNi)O?53G3W%{D5pVuExa$>YSI+&2gR z@Y8N2BzG~rO1$_=6F+Oufu@iNQ_%7+WHm8OYQ&&KwDSN;$l zXA+^ieN_MeAOJ~3K~xT(-iIuH@}zh^*9lBTtgxwI-6vm0O!IGm>@3y*7EkLLa6*a6 z%YTHS;&q6<^h>BebPCN!j;jqOdaBbtq^$(}G<(w1H0DG%l~-OSczZve6h%&c9ItC3 z7o0haQAxi1FAw7vPrU%|Bxji9UsY%-p>f_KA_Evvax%D)dJ>oz!H#V;=+zZ?wEV1G zw`6luSYV6c;gq7P^{&D*c(d0RTn`hmL$M1Rx*Isl#3R0J&Vf`LtExQ!m>>y7Z zKf&+bNxe1aR9cpN?FQJ)t*5_fFcNeTnZi1z(4CA~xMwFxUHB$fG zJU}lW=94ngoZ*ohR(SWOlQSimF%9;>GSrTY#0h>WqJuji`xLlz@@IE4N>YkN)n*8@ zYu9e<-n|=VIE#OSGaT{9$McFbVMLsfto{kG7(0?l3;s+KQMsFFtpV@X9uv zz{a49V|ogaxe-xByXnHBVgAG3r%TMtzxWLpBiwj5n23Hi!arfp2os{rz*<|HxbU2O zRyM?Te{!&%qv=zq$h#h2uKEdL?H*ph+mG8yzeYvlK;!UnJl60t)SfvA-?)!AP{gql zvLl(-9d&Z(e`Lp-_|2QgaQzqW#Q2ssQSapyPM$JseqjT$msexq>?BU(weCi)se1Cs z-{QwV{weOg?{oOdS7?^xy;%{CjiR<|KfGh7usrWZRHdy}w-89jB<>6I{vM-j48J<| zZ>Z}!%zFpD>h47u4+#C={N_3Q=tn=s-FJTmfBeT^?4f9%{bcEUQJpL4iY%f=s(qlE^frR{+4SoT7L+S zzxWE=bJk+r$^?FL<`v{$a0TL855Zl$6saS%*w;7!D|c`;H}8PG;6mJc(^^Thei`r4v{BL2zloEFdf`m@no>qXtP`%dWMpM$ zV7%`*e)+_2k-X?~%(0B1XypRb?ref>@F;ei@?-g>3((HHERzc7BP%I@cVB;v8z%; z@+GB+l>r(5wX`&2+qSK$4qkorHQJ^r6Kh>G|GChIqQFspA)PbU_&CI;d0^pX(7ip~ z=;-J`3BL+4JugxlwKXmW2PRorSxjpiHf`FZ%!>Eia}O0^n>JvK%8Qehg-0KL3{O4z zYy8nyAH?l<-o-XYrKKG69b%;q^icDgd&p>MNF9*BNI6l*VEz7Pd@xyrddj+Ns1Avi zQGUaam6H{GYLZjAz9%;|i7X3eW_Y;LJd*gFEWj7zWva4fD^>5miX--r_Ct zso9u2CkKrOPqTyM=UQm@e*fJMv8wt~{GYWI`1?QlHu{%ejdi8zG$$F2g(GY#lbdh8 zQH{WFy7>m$@~1k-DaP1P$H&+h{Yaw;u{d#|Qefj$GO}qS)}DaEgVtK?Gj_Kl#axf|o0J-E_&<9>>VCRDjMF`@{~Sx{vnqtnz_KlUGL#+)NoeB8_sNK>Ct0T$5|Z+b_HddwVBFQ!)@g+K;BAeq^O2^D^cAsLr2< zOBZC|gH1#D#$Vl!=O2C^)tBFiEgLytVP3hs6YdH^tOpsTt1z1R92)li49N}8pfG;~ z_7GD~EC#1r=smg##}8y9vGS+9J%5>KS*{VfkvEIqhAT`*?};{K@%wX!PBdY`#j`kj zIKmOS13lg{eDw>t_~pO8i;BxH#+>wVoazqX(slR1GhBy#h((TNoI3%Xs7xt@i`%8; zh>Y2ZMPbwN5AnSZ{t~%mP81X*VSUH1uu|6l zTj!&k%o5@fohYGMx&CAiPP}`NeLQa-h)dzjg66JC4~i->Fj7O)BFk9ruYBpHm#}>K za;|B`s9CMlIB_i;K)Uz=SWzY+nxKoRsN&+{IP>bKa^@x+*5v@}axVu|>FJqjkfIRH zKO`kH*HQAD%xlL^oH(JBrI;2wJGo1jN=Y^)MTtb=+-c#i*^L?DWPrkT zJ(@BY9F1*262@49(1Tg0uj|O!a(lo8k6&Wl{`*dLUrYyYq zUK_sj88?3M7}vAMatP_07J4S|lOchK-cKrZZ(lFcGqTCOHWM) zT|*pcH~$)MHa&r1ZYWuudlUX_!H@BJ>vQ<#p0BdQo51{u6vT2S<(Edt)*L1UCW7jxVF5DmIwa|iF@9M=Ywa_RJepY5~;x0*v@ham$rF++w1gr z55D=%{jkM3@TG9Z^{sg9 zpI^b^ORKTq@+DNBeq}m|z%{+73yDc9{^XOe*LA=;egT?3;AWdF-lESAa-yRj6|<7K zIYCCC7Iby=aINP6;_aCzUF<>ai4I<*?9 zT0ZY)w8FzqIC8k7F%slg4cz<;P03~7NBsvG$eMVSH|RG3spS;z2xneH$h`0=cv3Sd zYbrLLqq6gJHFIa>psF|#@78XI-xGsb_EePf=s@GXT`0NWQj8va8ozwz7;;wdvp$^V zTe)$^%}?xf)NR0UY7&YP-H0#FLSo2=W7~IAsg;pGb>b^5AwO^KU(AtwS#~LgQiqUJ zkcv~o0nE+68D(o%QTfR}HQvvb6GD5=0u*xVoZ7S!rZDA^BAnz*e>A~~j1>hq@`?}h z7v&&p7A+Kv8{X24+D%$N+7E->Exx>==rRi}{(P0h;LgSdZ$J z$$XmTq}qU7l>M2{-mUN>+k~prfS2pK>Pr>T?UC`y#7dK|5SJ|JAY#37#l+&zuSmyl zIU7ulFU7<_A5OAu)J$aJ-D4qq|N4tnzQr_bc0#J{bSLvYhOW*tNOq5)u5$q0oRPJS zOtRkgab`;;G|j*wOoxL$n`0RF|4ApVSQ`uPgazOIp#y*S?M56s%DygYCK|?@@%+I{ zAVPsj1Ck4FWtW_6crZIZJHu5uYw&#C&$)BRk4NkOkzfAx;=y^}!;bDfca)=O zZ9&{xaT`Z*T!@|=$4z&x!5}Mrc5W8WGL>U^+{#Wf6_dmB(Z_R1$=ux)V_C=<4M&zy zBR6S4vV$t3HSkT=W~6<{mAhBuuEWNr-;nQ7?m8SrZbCW!&%%GkE6va1>pLI706Q^X zGjP-Lo7v&ZIUlwNwFW}lHf{3~3T|0yibxE;P$t_8?Q zQza{DGCw4h7(?71A130tD=Ib>KJGjlp&4+5Q@#l%D*O*oR^wEj;v^47M}o+`ry0P!x%`|Ag);2(W98M?p}2RLojK1K z^6RYE-FYpXTt8d=+0UY~Z;TyyGCOeA21^FgsG=&1xs{r;ub^*$A3n8nz0HQa@=By- zWb&*Kg{x#G1;v`f*EsG7{p+<%Wg9 z3FOV2O+4mHXlOnymt31ub%k}RhsQ1k_n$@zzr_}y@~Y=v22O5aDVl|mElqF+hGChL zsn#WJG`R=#GSp@dtV_&GLBTA}nv%Htu~8`+nMpM_H>;VK%*x~|3_%yqL&fo_)&;fM ziY9Spie)bx$=46O-eIg;w~k+$Sb_o0B;{Lwa>nzQzkE#5qsB3^qvuJJizrG>Rw`Kg zQDT!B7?lN&ctpDZ2P-{oC%E~BXAOta*g~`hp~S`V46<$e8lT4{<4@tQKD>g1-Ap84 z7_GV2pgd+A3l=PjX#avId6H+_>1HagE*@VQKxW!;Y<}xa#Lr%Y!M1+N`xPv@DH$C! zZ>MBbP$rrJ3?CjRzU+K-x=+H(bD975J1zLmU(RJ(qgc6Qj0%iaoFOSBJwbXTO=(G* zrBsuw#0Oc%(q2`FUfD&~0#C_DIwJ!bGzl_5YwQY6>WtSRfYLf_I zbtKtq62>!lXMkb$mcHGfZvqTcRk+jA3WF$5gqG6E#LAJOY^$cJz~tm?*P_e?xMkLt z@Yt~*AR)(re{J|N4su=W=wKbZOw8Bp$6DVi+_~y@cJA6alXx!5CL}Y1>@i|JG)qyS zVg|8$l8~Foa7vPMA$D-guwuZJ=H9L^KzS*Sp>vlCQflysb23z1t$ z?EH>gb`EEbtVeQ8K)P^gjG}y9lBGD#zW6TLisdI9)GZbYCXz!x%O~BFhA+?gOFaJS zV@OQlSFJOeP$*`^iaplUDIL$$XtY1lc@v}XN8Br8k zRwf679Q?@!6}w&Ppk9tTA?bX@?6_m+4%9a^P?&OMD8;(^S31EO>PPW`4cB3GSS~z@Of;h=Yw@UhBK&P_Ar3o=ZWr!My&gaK z;@={k2R|p-Ifzp?Rj39gHCh|tspcjPINb20$^Cv#I@bSp$+r-@(Ss-J9>GcOa@*DL zv|2}w?}@{GnYZD4pZ#0a$;u8Z$>aGr87cVqp~#w@t-K|mmx@C=DR%lyPo7fUJI-{Y zaNgM!U&(RIkD6UAG@&K4L2*P(oS0xNx&tSa;^^+~NBXR(hGy_2I;CV*JdYs^IorGLhUF-r*)NG3H!_yaQ3qZ{gyt;C%>=!t4&cl?uVQzHD6g+z;W9RA zc3{#O2>kT2);fA4QgtSh5hAG0R%cMsQtv`YcT?qPgqWT*?F_Z;pu*kFGi+Z+(VB0- z$yr2u{fDUKw#fg_-gN+2Rb1_Fd+)t>7T9I!9RwASA}XR{FEPdvWB&BSKYwBpHHp1f z?1G|#C!ujPSw@b+!LxM^A4f1Mgn&3Jb>N1_hIPJSd1An7U7&|h=*_m zg=Gc?*}F>Pie~7r;iQRmACoD$tXRo|WUom&^;Zon)ZJk~Q~7C1>s;M8yZWF z!hP_s;hp>dd7XJx!<=%QBqU}iF23^~oY4;>zkpEL;zuek&1%b$anri$ zhX-hlqZ8BS9mTG7gIK{4Tzjn%)2HhU?CkI5YbK=USR6a?=y^ z0auF ztQrv!!AiBfva$ku)^0%3@M%aH9ivt)I&aYFuhl2GSOJkp0jLL+S&Pu4%_a04+Eo$8 zoI_>M+Ndz)3d~S>677vu2uZ$_`AI1vW6wU+Sdoo3Ln(q2CUcg3rgDU(5;JI7w5q^o zx$S!thQ&ycmq=c#g(=^>Ij6RgR@uyNOUj$%MU#-CXdra0udk)@2G8d)K7gWbSDHAI z$%oV?`DF!GTgzEL4f(oLOfG#%tY;iPRE_fLE-IPuUHLhvNrorS965_kQ5ID1ihty) z$#r;92n+uEh znDmvlXvTi~_e?VaEF%S_&3)+#9j&PrkOEx=PDHvIk5NIZN{>17%6IA>GLb~$id-$7 z`m)HlAheTyuY%MgK^kB+JJ6#gN#P?`87%mu#81RS9pzw**eR7&p^0%SaDuIu*S>M> zo0FqBB6?r_SqYY`6i>h4wuK!Q&3DHYS41mGhU`shHR??l5h61R66PRi$|oUFnnXfV zb(1=^dgZUVfV$-$^^yeu@1?MHkUSQQwL41=-so-6ib#qopgo@Pm+4jrT11GFPpa07 z3K)US=E|)ENs@a#i^NH=PFE3nM)hFzhi$Zo5Y5q2UmrXTx`Jn>flSuUfNup--I_C4 z!xFuPqM{NM&^UlNwCu;g;^QN5?C>FF4^hNI{el@A?VWOfWha$coE~JR*F{l<3anUt zs1^**Y`G-$HINUMyc&qF@>kU%Ma{rOR3Qx%!15hSNADI9QE>9M(P#QQoURqu{zaP)d5A0v}(UdjV^jCH3ZZ^EBG+T z9*8hjZD`c;$zM5)DwxQJCldx~rxJsyEGmae=O0T@3@lPsF^rP-@DR7yOH@C-h&i|3 zna$Nm0sa(lt++Yg*)CeH0V(D>RjeSZHB}=BA&Lz|VNkuagkoJ@EW68#QnU4Q)od=H zE`%$%_YJum#8|1MnX~mFW{y(EG-)a3@fb`*QhN@l6Na$r$KGh;~wTcdm72I@$6;hJZDlk#E(69QqzKtQ2junuKCZ6&&SfZ_QvWiuu1i00^5Zt7H^eZC$R|R6oK~9Y=5+wtk898}Wq>}MU9^^N$E{T$$ z(s;E(U3U#j`__h7X~O280|ev_t0K|np_gTbQT#t z`o9*fE-9-?X!_Gd>!x1~AIku$vY(%>`hX@`H3at67k;#z$`pr?QGiz~@Q)SSYhYmu0i28$qrl4EOn~SNGevw+MrW?@%$b(f8UZO2oG)cyTyd$15bMxaV0}324bt1MKlkO(Xl)g5 zo_Sm6=zAZMPheT)=aU;197GdLqE(8yjhe{RT!a@1YIe$NUp0O3bm%JMS^o5|)to^U zGPh4&ilwRAjST6QC@Yu}r@_;q>ba~knUmCo$%4Ci;;1r7y#BK)Wr_T{D=-a))F8O< zC%_fKCSeK5E zj;|H!7jgwg*%l=ceTyp#1M8;cj7}ch)MUFlw%`6$tOHnR^eutcX=)AbY;lr)ws`%0 z>sQHlwtGEJ#xr%#Kk8}*s>hwR5&`-h27e!l45=C{LE)j-rQ>>*hU<(>&-yQ2t>IhW z|4Tso3hN-HZTh{W4t%zhkOZ9&mU}752aOL{vYvTk&et!YFV5df1~%Et5qeu=BL(zI z<^If|LFt1fIW!2?aazoorOyU?K)JqIiMhCSnRCHCv!?GOWJKP#Ef z1>hWwk-=VxYAxygX{8tf(?rZKZg#X(R>Fyf;9;HH0;1oIAfyEiwf-e!!XYAQtxdx4 zgcWFI|gB5 zo@C3~!-dB@%)!FI+`Xvo?jOoQP$cMP@>$h2u;WOlvNV|YI^nJF`Xeq{e7)F{Sf}7zy~IhdT-AJ-^_P!MDPA{(K(VqwAHE_69k2)TG z$P0E1Qc$~-8y&PIN>Acd;0W{8z9%h*qdMR&8mXPCtOW-Rvbp(ZLOmON$z`FPWKa>L z1OIi2H6PURXXVgR&QA1l52>Z8ndfa>Nie;&%*7WyuoCqibX*iDJqPphR{s_yNzdEL zL%DJoaQet3r8Zkdn{N7wPnef4Ej{@8%HdSArjmmDpY^97$;?gDDJPHS_hf1G+45Tw zZ8tUw*eLLgDNsy9*=6(;5FQ?KCJcUfqRF@S&~X&-JYZrN52uTZ7mBasSU@`ui7U5L zRF=|$_7%(bDnG?ybcSNip$&}Y2M&t*woMlgm5Q>J1CJ9}GcXYq7<*cApn!(6Gh2}w z)_`fLgULYM)T&Uc$pT!fR0du%?s|$`1t)SGqCh;Y2OK@og0w_vL6za{!0alO=NoF8 z8_`f#MJ-txrRJXdjxAegz`_fQZn&8?bK6vNRbB!T9w6kPWmdM43l&i$Fo(0jm%7i! zzyyEY%ZC)Vtia?!m{``y;}}kdmb#clt(JILR5!9KoJlo|fOKLjq6mPm5M0Qm-Cdke zTvdTnSx1pPC_(ws>gGYuFSc#QWtYuHWK`5wfMm;JqkxS9HVS-m3Ut%T&#;sv9%b=A zClCWC^qIxca#T^8gP6EM9As&;(mWQbt7!6B?K`Q7yfBS(1beQ;4E3dOaWugv zD4qwZsqmx*SjBI!!}JJtw2wu*UpTh8T!&pBO~GGoU80zPfOT->)`4hRtJP3{X}~$E z>>tf?qPQ(9&953vWL_@$d5C}fVP$d2mCM7rDO2Gzdj_6+{Bd=_{)QWFQ80VyWX+EB z63L$Mi;m_x8fI`tpr41DAXwKa8ivAy&OR#v~*rvqFu6Qejt{0p%53 zt})G?CS;7QbvRv6qgH8#>QaH!v7!+_u=@ zkIkk2SbHh}Ny&qit+U_!_P0C(BX-}6s5kVmNKN%7zwjp z*%UEx!(BYvewA>3Cyn9LGbYn?COS4!id z+R7^JLu?@aV!CT!kPqckP;7P0IYc{Oy^=40`JI>|dK-vfu z6JveMOO7d>YRJHe#saw6dm_Xs6eHX2!bp0TKd^5reY(}Len%ASS%s%xcm^-N`aVs} zu|Jamh?^mipee%*yvleiW4hoVnm8f~m9jFvw^e82)79J1!!rFb)36k;9pd^&aJK}3 zPp=4$YgVK2lTT2x>?53}n;vn?^wXc-hwMzA7i3%Zq_4n>uhAy$_AI#aJY+9dU**}` zvH3tQ53f@pis-6UEOEB$ZA1EJ%TdzEGnfNtWU2QoHx8FvGVdWTFHb~-`%{GHiJa_A zS_23Zex=SbmGWTlo{T)i4M|2@RRNA2JArnZc5$Y2%cIA#(QWUBPI6UI&8jHKquDqz zFH1y8yAVbhXjmP6M6dMuG2yok*Nx9^ADV zUcr&bI7B~Akum6LufoR7nMh2DLu*AY*6%Jw>W~Pv;mbl5$WfQ^tHPXmK0ADLmdi+$Q*>`ay8M_N;|E9)bU{U@lv{$3K9F1+S#&B zT6mCyo6+IRq0GwVb%RAT@a7Zr9jr?Ib~9x*&Py>;Vu zctpg)l@`9`9oe&ND{Vg3Ql#7MNDt7oXD5y?#bQDSEwjj(vcA}+G?ss|Oc_0njZ1>KwrL<^OW+wx?WjZ>oL#+9Tu66DG|DW8w%f_* zifHs8G{_CLw4l=7)`ar1d}ZvriFOv9?1dRNqqMjHaPg!BN^D6|oJXZAcba9ZuCC&J z2kl#msW@4w$Z%?pjAIS>{K$Uzd6eRpe|i|~u9b0g!ghrDKiV)z@jV-(O;NXt6NZ+yt<)zt3Uw?p1 ztq#kUtwzl7$%yh3Gjn~DI$4UGTH!A=rM=jo3V4 z5svzf#GYzbOdCq$-SM%so)U!5Kl%cR)8}AHk}uLfeiNUr*#HB_365Miv~3mAcVy54 zj|r=mE<;g+fyNg;MU`VX#te=leFjV%v=3V?iVU>0-N^hc&Gc?z-5+IBPR!H@mlpek zLg0FO0uJ$aMN!@<7)mN=Ff#;IbYF0~)e}Lq4_8{0O&25awD*>Yqq#+Nhv5y5&*=4_ z?Y*u{*%uYvVVE|_6;*~{q#3z7>U6>W zk6%W1V-I{nN8rG+x3M`ZA9j8Tc=MUvNSd|)7mbQX*{Nfw?g>GlLpAp9qG4GB+vpsI z5kqONr|Kjb)iDejI}FtakD}CX2(F$SiY+VFBA3?D1D&_y_08!B9eWjibmL^=+lFoL zzJ)D$MvR_07S)Go`e(valuSDUP2gQh}yUr>0371su3JH z7CjB8F?8${6z|x8e3v+k8xnxrqkBOMb+~L?0=A{^g7=hJh^x)Pma-Pyc++fb`QTkt zx+h`ckSHAf_+#v%lg4ZAxD~#1X6VF~*T*kCi&h#kZmw>?(^;!=(ZYLCwPPuEm$+fZ z#CQ~++=E)z7|b6@_-i+zIw%=eL_j@4}EtBj~g;7`rxpfc&~9IOQHgj-5X)pD-9-Y~F@Z^R8sy9L|r; z7XDKyAe$lL`C7bfJG**eUHV!wt}Hq)&BZF}k=Svv*EHZ(R`#^gZSkNU4$?-NOh#2AO=jd-y6} zfMQ)ojnk}97Jh-W*j2QVmiOtcDwblmVWUFf7vYUK+L0}h2{9*a-7aAW=EB3@$UdJ@ zhTHDF3oD-aKU4&a!7p!_jpeHj($y4gtM06aw~GN8*|iv+8i%stLJXevV@!;$Mb>m* zj2}#MTC}fe9b}beXfojS*IvR4FTG(&5^nr1 z6;YrZw!h&gH{tmHO?YF|X%v+;Vf5$}PKXUCF33caF%YS7e%P{ZJ;q=DGh98^7f;gZ z>culB@|)uk6{$@KFF}Z+->ZneKWD7KiV6!6%o(XH2ixl_k&#Kyzb1<1D9-bA_eW5G z6Dq5lXrMO)9!~A3HuNHCXbS9FIeT{vQC*I9CvUE{TxjycfT+Z1E=Iax z=&(a^&Q`p-tQn0hL*ZplkH2l5m^fiv>wm5UuH4(F> z4u-S)U}d^#!R@!9X3ahXO`U+GxBwUm528IR3Lf>jWJ+9}1&+ZD*It35;|EaQ9*hTm zejSQWJAQE=yqYWE zG~`kYbE?D2^wYTEmk%J$y$xGdZzbc1rTY;d+Ng^{Pg5lh<~iW5JEr2Zmp34B<~$_& z(gJw!WLz~Vng&!&Tp=AJ9o;eemfH|yYNS239dJ*I;VL1Rt1)L}W>p|46xg03s;?~F|cp%WgAE0 z`gvnGd1ym))CkPEWF+$FYNVFFsis_UBZda`V)wdjFhxYLQ@hcAyDLIn{kSr1#*y4A zTygKukVN+rStUKV?XFwVP*}xxS4Lk-o8cCD3GVyROss$QGsMhYNGGB+;2JsslS8_( zc1sBs{m;)4QAe&+ZO)i;<*lTDE7t5T#O=TS9|X{} z(U$aW@E#lw9~auB?>vRghw>>3pNtWS{^;;Y!QA0K$T(PwQ#o5uSl)q1clHy9PIS;i zc3jLTq=fWf)4n_&;tzovt?m2T(ansPFJcn;9rS%Gw!8l@3e<7SK|I7a8rqd@$zj7r zVf)q%xb^n?*nd(eO`s%#9yJ>286hE(#+*5D+jFAo6D|{>*&n z5U-}9l6I--!OIq*8s%}!uY7`p4}i_PAP7WL`RkMXiVaHG9Vabe}eRgE(z zqqG(A;7TE{OvDPUT*Z=t!7(4!AIPK0rEByi5(GrY9`F?!9`v|g5oQAho zCwA|k)7j8qGPN+IBnRPiSvM|9@x}(O<`&MMgyOt%M8pl|BEt?o5lM&-bR`q{0`5_1 zG`LOW5JAiwWVJPvWAVakt|w2RM+b@pB{*s9a*6AYLI5`?U6d&3Ldf`xm4}vx> zL1$D5g2JM)X4Pg+4%oK9C8fN>?N%I!WXV#?>FC`#(jC zZ#2sGt;F%{eC*k`7Y@V5Bc{6y`Q`Mu+Eaz7h#|-?%%dUGu{gEqBWyW%1g`#x@NF;0 zr__+?b`L^yL>v-h{jlw=?eK{S!nRe*aDuaapTKA&Cq<*%P(z<$Zb%O8#3vuF0lYj= zuz3Rxw0dFA)FgcV$x;+_I$=Ue1ZvA05HMm0+zZQ4+Uy4B>OENU#R(+L7)3{nfryXr z$M(-xV%>hadWfLSL#HT=3UNF)yC%*&r0nD*x!IOssMm?sS-pdq+)1NFs;bfVa&9PFlkg0*1o+M+d0#Vxp)*OCn1QZRrp;WzK7klP8bqT zUvVo}q0%h|v&PYB;~Sr#dq@gmJexQ{I6;f!t|%jY1A@ZgPe+w*cC9#;lY!vqAQ*c6 zF=bc?)^HVjw16x9@KnSG*-;czg_7D+bc`C#enwwqi80)VZH6z!$LrR7irp0*m`Qt& zRkS-9NDZy&<0oQd$`G{V?8LsJDj0J!kbbfeQy0#_B@-qf#I*(64s1o2i#I}}lHpdp z7sner5iS!c4oGoyg>vE;Ex-rHa5BaTfqX!=@E=J5v1v(3KV3G7p=){zpb_$klcpnp zmhr{Xzl?!m?75NR{DBOtoe~b&=dz;+QEa0cstY+G??yl?gwO^ z%%qEP+5d1vN*cv0^+>``2tk%FHP^zF{}UFPIAx#R7)bcD}Sg4)B~sahBynCxNn;BOTL7 z(SalPs+ybXXuQB3o^ISvV?Cn4AtFrKGpVOla2LL8dy1sG$+EpUlWL%`R~L65xYIvX z1I3`dbnW3wqpl)Curqbi7;FazXfi8l5B(jz_2T0=(Ugd5rX|4LHxk1stFGsaOT-4Q z^jB41Q^Oe>MF3tj-^INe2WQfh`(m~1@a}xUo-`)g(QKg9*p=e5188;&$MEDB%F$&L zRO@bXVne($*VJ&f?tbjP~)65RmKMq>q!vL*lk_S$ggh2%<&wcDdKZ5*23K@9AzbWG_W1T zNxtNyZCFmI)Yc2jN_kmHi86)6$p|cCrF6GmPU6*f%avOX_xAn#0#Ht8vR?Gf=fLe3 zF%Ygn)U><>mXsCa&RafT0auP&4)IZ_%`R^nNZNo_zXA+=-01R_`AwXhn(zq_Kuw0{JV^XREBA#GKia-rzlfhm|*T7 zU#l|ORT(f?*dgRB|)2T7Avhr#U++FlX7s2-TWW?8j zsk9!^Pav}pjY4ORl`8aQ>3i-QQnfff%Q!5PT?w*}HL#fWAz8&rR;x!<(EKc=HI;YX zNgRKIt}t#HyJi1O$6b;KG(~~Z|EOv-w9c$g&t$$1WMHgC3sQkF5)W!5I&dkeD%2C@ zN-V^go*u92v#wOXXIA}Izp4m6xNybO(A1n3AUoF|@oqZ$@ftI+(*4 zRwyk$Tae5H)ATs~dbV<3GfuDKUjZo_#e%F3>no$67m(uCL65hN`?7l-##b$?Ub2>1 zFQS8xs;uMmdx_WcSjS2HHxB|yhk6z$R(STM4lL96tj+$kHzN5}3cqTLcLJ$OeT{mZ zl0$<2tUZ}anjiE$XUivXef66QnB(*dVe8;6psdPBnu^yGEfETw{^dxfJ}`ZEDpS8d zUp4J~`K$pB$Y+hFbvFH8PnYKbMb)!)x?biRUadh%Ro2e}QlunBrS)bsm_x@$5}8@P zTCsdFD4rYB3~C~-?zj)+>_#Ti$N2i->tDP%V?Uq*M32|6vQiW6S+n@goUY(0gtZ9y zD=O!zM*dMrdV|bmEG^WZnXVQGylM+Uy?};?C7Y}`1fuz(W2RMNdD3pog`}0DVSLs+ z3Yr-n?-fPlyOQr!4}8|2RQ2+tzCArd-&OKiVcwU(I|~C7bx#BL0=&G!&_oyN-&L42 zC`^eH&kuiq!@RR)wr-J5iGlg_Jl5$FcRq@kVdzEW@hfCEm--ejIs(?X3wS;LTdc|& zlujN!POnZ!Lw}a^?}aWpV&CAZe;?Lu>Bj^A-5Nw1s5Y4!q)R$1@5plV4T$xv6%izK ziVIL3DV^BXX#*=APm7vp7q)+iNr$&))CwnJ~OQ^m%8KV-%Zi8 z1nLY@Pk?(ofgz+lS3?v%>p^dce%0g8b#-vyK0j6Ty+n$@V4}i^^~sHaaI6`qN*hQI zy}^1xdDi1p1@ec%I$ev={#xg?jz8DERerhE!Af?kBrTqa)_HU(opoOIElR|IAaHef z4%GCNqe*(OFtB1e3G1X-M%RMTGkh1<9yxC%XLGoLDWXsl&9fLOOt#}eX(#S2_3(_B zvOA_QC+a+t<0#GpJKO0VovNnNQvRd^$=;K|5fd*)nyOM<-jc={3-^P1ItY()S#36= zS$cG&_KzLUTNx>avgd5dj+&M|luxT}%_XoS&ua8=Gg9QredV}UB0iv`E{Z@^UN%6) zyE2;-Je2c1c5oAMmb$G&ui($a%K}5JnRmDGkTPdqPV_BxX5d~T^UEf)li(`iQ8ay1 zbY@+!ZO1k{wr$(CZQJbF>e#mJ)S354W>yX`QNut@kGt zp*~)i*NQ^^2g1Vpj<3<`dGYdv{`F5swB`QjsV6Oi@ikG!eGd|mqai>YWrZ}s8q!5! zQNg&YSs9WgrG%(JQ(Aq*^&eW~WW3olCke69gNw7M+32P5<2Aas zaWeQmKMGtjYka52TM^$07_)#ruq0PZVx~XRmFL~Si-Z_gEEfaa>6s5{>pW z$8vSRgHk@D)u3lw#|TMHfsLk-CYrR`&R^DdDA|W07f*sh5!CP@j-7blxjIbsTPR3n z5SZ>$n@}VVp{p@Ml}=&bpx=s!YZCg6(8AmJ<2p^C_)XTbWRh)+q) z$o!K?VYX?-m1$KE#MDwbtOQ%BW775Z_wxk7huQTKo_iXH_Om!zy_aheAh-~A=p9Dr zi8st<_fl?Jb+H6g}&q?WCcvPSfPqmW3ea+oL zj9JeKfY^iSqN=ac4I>3$Sh+I>7K{Q-Q!Act2ndkp6W$K*hD8K$pP2f2T;E~8&sSr! zb3$KBAV~m+Xqn$MY;Xj6pm}$Aqp9ly!;R6vfFSCv{8xSin(uo!cs*~Bcv|^E*4GZh z^Uf4K`8-ghnAc*H1v+*CK%~?7JRyuH1v9=c#g?_5(EQ`x;Gtpjb6-FlU+DSDEAe*z z=MOnFhtUL0zOcoSF8~%&e{e}Yf0%5*_iUC;Huy~WWT&SpP360hW-aII11G5-cu%_k zFv?F$p5?xc@VDy6;@1&h;0>cetK6TC#K95nnsxU7!vd%^=5rN7F^a=WmcNN?>OR4& zuk=M~o^01=826`-WLVb|4y6!wn@GEmM7wr+u~?pxWao94BNwBd11092loFKB>ZbL4 zK}{_sjWe<4#6CVvr$2XMjBV`2u#hxpaCqH~cO0(`6AgqMq$;`$Jg+x9}qnv2G*fJ0Civlki&M z$?rVhl2zA>te1WbF$zjo<83+Je9zkb+77ZOw2QbqWy=#K9TX;YKHEP*`3Xm$a!h@T zEqIg+rC-YRo`6v?J2S9dny(U$8Ceji9Er^d(yJcP`1X;Yr0E6Qy&aIPL&^*-3oZVL z)v}Mm2A$s5inkQ#K{{eHV^v9VP+~z87SE(2u%e?Ws{Yr&+^(su2(r+W!CZ#&vG0ba zDmvQ9=*D$d+e|DrV*sL{j5_6RfJQAnrO;*$$BfYN5cU+4j6vszVz~yMeqXq4r+^OV z9uOW{oYFpH0iNvdpsrPW($5MJ##m_!A`wqx;B9e1(&Z6;E5G-4`xo!tabwaftvsL5 z+WGKP*{!PlW>AroPW{!cGdN00@G@t7&n-BtE6*;f(O{n77q)JgH*@LOcBDl}&|yp% zG}FT?yB63#RiM2y$NK8)uUaHOPk*6!YA>&jtdUR?l^8I>F$?a|;&}3f=w#Y<-a`YV z4-bv|@$2_04!10)+rN^)33krHmRTrOLSIan#?R9_8#N2DD$br@&+vrdrcOBE+2FYo zO>u?}qu9yJ+|~9EZ3zc#|AEH#ekrhB>Ba~9lc!-MYlLWNFGDlxdg0T*DJN|}?<6Io zkRX`9CmeQ|M8T|)j*kOd|2pXcV zSzo8nVfZ&3{*c|^zrnEW35=}FwKYe_i3PVK1IRWr_s1HpBr6Ex6r!vFj=Z6 z7?LOC3thYZW>B;E#2MqbYq-co+UqKi-TlUt#Jl6(jF#9|UJRrn$u~|vTd_hCGKl=C zS!2S}QrL*}b_)2im+Sg;*XwkEld!}jKECCy*t&;wVVz|D_~^yvAHgl}(^6C}t%>28 zSJM`U2p5(?STaD=Wu29Zc@Ut6bAH%&unVyJ869&ykfNDJ`BYAc86RK{-T@H2abTW6PAI_i}$)Eql2=yuT*LiC|4mO%C5M$q#&) z^6%X4KYCu}hI6XTAys5<9s&qPkKJJ`O70gTvoW%1pEuX}KZP$N3qNj``h^&gAU76t zMtc6{yCTIxiY|_l($(Pee!XJrRG94x(Jtz3CynaWnqQBVeR-pE(g&ia_uhe5mG4BS z8E`Uu>MgkO=rSvwD;S5hT`vFcy~2dPOGE}Q)APg33~zWzQ9z{lr^55h^=E9yvv5l) z&4%tr`Nlf5pYgnEYb0PQu@y=@o3l7q!XYdqE%2Soqo)JCc55M0;b9;x``Bbo_k0ii zA|hP=+W08gw{l(4UYJ{I%OJW}(I3%L$A(J#6*kTA&9sZ$;XSBr?p^6M46l ze!mm)wV3kyhsJD1n7^#&06i77d-l#?)6{VxUp*RsYboqkc$3bQUBSb>0=nfPngzQ; z?WS2&JB7XXE5Rz%*bR8U6*1`Fjl7XX>t^R1%sYPV2z^Q7wvT(6n)jDt8w@M1#^i?! zGD`ShsHLsH3790~**2bz5(~@zPSDUQ=Dv4UXqS`Ps}KJWwPlN_eHo`5L~v_g;o@jD z1VZrV`eeZhf+FzcezKVu~{wV``ZHlqB!Cptr$xAVHiQ{W1JE; zBFJ4TAeX^Xc4-L$N}3S+-s6nxUjtb_yZ`=`FKo=GH^eqB^KZG%HIb(vpxxYmcrK%2 zfTui2QcUUldw|%^!;jQiA8Lu3!pvHsE2oUp;#$P*7QnRxZsL~ygPZU{Xl(HaSSnYa zE&AK;6o3(|_Tk6(gMjkJrT&XdJ~%2($fu&i=w#nU8coY*-uU$Bz9k4qrjMi|F;{+2 zx>7E94*XA~61ZX@HXoE`&nI4wHH`n8;g|58*2htckG}qhWaHD3d1Og7B4_jM2!N-A z;s47sms<9Xw5%BV?UgIw(YQQsLr}>|*o`aNx=suo+$Tb<&zkRpD z_l53j#%_bG1uHCt+1@l`l%50Qtx8waax?vQq+m&z@x1V3Ow)_oYe8o2$@~~LOAtDd zw!&@`f2^~go2p@TA;jOewtY#a7sV*t%!ZwZjZSFf|A+2+_f!?iNO>RLE-Z6j<>aA$ zi;lfku{3x)y>}b}n2|4N>sF#8hFZTTia1)b!i&$qmNE{_h|!XTqjvrL62KL@97+3) z8W!{bd-*0dq0#=op9BmIg&2rtEzCkhTZP87wLP%y2<5_Xa{4|mRJRhmvNA2)zJWkl z&mp-3K6v2I&JRE8491XB<9F13?VarZJE#!~AXp`3rG-=T6&l8~3XeTD7RAFX5lpQN z4#eu}X*xKIV}Q`DuyCazJq4V#;Q#jh--{kA8Wf#yF*uC$XIgRhYD#H4s*iZ1g^`J6 zTSN@q`A35QB!y-CRZlXFJDY|qcgg?RhyT_)2~!Ehh+?xs>X}eOmR?6Z^yg7?{xdaN z)|#}DLle>&Tfh3!rxs#dLLEl4dIH*q!^$;qy;jg8DX+3(06djVQzO~$7G878beP;zq&;N8tJcfG(!Y<ed%KA_!i_tcGo@FHK)*QH329?B*yhn~vfNJ0S*Wp;+wmxYqD!^=ktJGnO* zcZNC)z{@A+O^*R4T?Y~bjF0`5&56&IhfqNuU!MLptD@x?urBpKqJ4u0chH#@$I@M} z-w{x_c{!QESV`cQ3_q}mqlBURZUdR$2>aDzMefl@?j2ky$8+l)jv1{ht&%F|hLs^HIPU2l3krH8%4SQd?j8 z(f4wioQ!ZqlH^Xhlj}=TRl+4no6;KT;f@kzcwMX(-a&RtSyqKWIGo z(-9RN9leIPK{*8-r(mZih9c6Io{XOau@1VnHlQ8(yKJIQ>(9BLr~46^RZWx=^*;zd zyXI)H00(-7mHP+2?OjS(bbJ{_hg*|D^B0}4#?|F%cqk>v{IW@Kwc-!G;&9{bm}`=b z_8+#IX6w@=XO0iH`o4*+zF3Q%S7EZZUYktjO!>CV&H=F2TQPAlJAj~9$c{zuPXxg( zwAu(yqq9d+CwEt&`-Zg+9}S$G3!aAC&XvTaHDSvVfsW7R4P+@z`V*vHuIDq5;c4s; zqIv=5lb5L+%GPoSUxB%i3W(y}#ib}TTTNqm3xXoa>4A&ALMCh;rA*ZXlsm}^^$%~N z!uD1iM}bD{2Zwm*C@FyZ3Vp%lWHTJ?x^0z`fn`GIfba>3wb(0djB`ol&#Qomj+eHn zJw?l^9SN=$7s4XOk2I@idm^(C<6;0r2_T)R!Q-B%n}lecQ2uk<%uHR6{-LP1C50I zscMBM(h!%3Z=`nh>)ke`njT2%A$UIwf^vFY#mwPy1{EI*f{6}t zFKC+wZpVJ=IVktko4IfDHjkQDNz&iZ7J;JLHGRJ!LZ`)L!fOx z+F7T8lhNFUJI`K^k?rkFJ{5J7ff&&;^64f^=<<(X8SfX z0+fJZc(S>EhWEit!_-!S|C%<_VtXc7X7pEut<#ZIpx@&^s8hL&_!m{s28)+5s!ONg znwZgp+>>;GtqE*+SE}jVEb8Xto3FFkfdKl+Mqwcn5@Am#h9~(>%wVhSJUTPVias|Y z!99{E+X1-GmLCch8ib)Ir4DF;sFErUftL~FRA98cBrWs6Il6$BGyD*yUV`x>hS$lG zJ5V|&w9{I+qRuJ2{X@E^{gx;gRno|-gx2FyI{|S=ZPS0L)ydON(m#sR!54^WR^~X6 zB$`>l-39|PWHC@3{s~m*+8ceV6Z$MubUszXkeKbp$0Bdr>!sX|_=ucpG*SWAVEFj) z5O3V^dE9BW*@tnKNy+5C>|QZVQ_Os(RI~QX{qI85X@*{tWPJ)kyqraO0ai?MiMBIv z$KZD59KUVz+Y&cW?>bGC-VxlEjn@_R2z9!8l$3g!Eo!DUrLKgJHn|Khxpd}xVj=be zVPhSH-Mrnw<>}oX^imTn46->HB%R|?Lh7@?kkTRXbbBBh;p)S5hpaEY-e|3;+(i~I ztQ$DnNUo2tl=RPFb{dG-%r7NhqCi_+Y{vItiH=mr6tcuvUmq*@enagT-vDLhM67H; zb!ZTPgm`g@d#1{7Bi-X`Dlqv>qzXN+pvVI7p9=C+{Fz@L>)7waeYP~SM*CuSFdn=6 zXG^cf+Igu6#lCF6lY^0Ql0uo%33B+BLtChwbKu=beJw#y%Swp3rm-;2MwmJ^j4s>g zpWl;HBeT58%UpnNOs%B0irnFPS;5GTj4Ads!qg+ZsSW}alXK<2s<3Fld zkeU7BFrf$4FBQ9*Txk%@dx7{c5f0SMc7*m2^e)9ymO>T`y6y%2J5 zrbRVDHQLDuDR%EYtzrD-xycmz(vf7nW;{2mPgP7sL_!0K$Tped+JsSDh7_DWfs#5_ z<>d8-xjGh3B-kDa+?@Y2k2ohq2(HSK7+94j)9s$&x^zUf;SoFC^V1pac(Azz2NC54 z`ViK2t~}pJcbOSm?z6+n4ZF#sW&gLf^EjVF0=KJ)lba?-m7>RPwD0i&oAn-^)BuWki+k!$N@LO)~ zjsK8!lXkM8w{NyW6Uh7COf-u0#jy3EH+98pc+^m+;R%M8?JYzyItRNZz>y3UGkaKZ z85~rdP3k&IG@hWm-rb1DDuQOwjECmrcC0%HtKwefQ8O-H=HRssZl@Cz>w@kc9mNZ+ zC?Wp&BVzx}z#Geo@8dzb&WIySux(Y8RuiF5o71^|eR?K>#4Bm33K5Tma|4*W8YoQI zku>(ClmFwjD5HaQp_LC8s2rdSjlo=AiQD<2F7=ZagIReGSRz-H>=GW&u|NEXH#hl9 ze_hNAV+k&}no@jxK~fb(jD1igoMuzFC%2yS3idNNOq@!A!;5B3JHbfzm*vLd`m$R+S} zC~zo^&r(bxyl}YzBjNqh(d(-CfeAuw|7h$pd_^;FxP*AG;mLDv*8nVk6D53kFaRA?OB8B&ZoD{HGz$yi>T^X%QxlSpN2r+VJ7;BcDN z&Q8EgJ1+gjJi)+~6KqWp?JXZ$8!u4<1sW3nz2+e=f`nTvVXxhiSe7TZkI2F9Qcglo z7c5tCE-RB|NgQ5K3V5B$^qWdAgWf{R1z=}2?||I_8}&3iMK+w&afhHKv63@2XSj@h zW8tS9L~JDJv{NM&K7)Kf75CeZs-@gu7_;KRr4yNJ5QUPHyhPka}E~=MijhqIp6~HX0FHzMftV%#ajRe&~dHLeh=L zA2au30}IZniOJgb?(}M=D@T{g#Szh!%R_2`fUD^#H_7PAZeJtC;ynK86De_6(%di} zGzO63Y=ysv<3(DNBvh-;{Vkd~c}*KUJlxG(drvsVW`dZTWLsqB85VPAtH2hN3_f!i zL7#C^%#kWxDvHue`dMh-RfjzFJ({UZ-(LPvhQY%ZNo{Ua4^B-z9K=7X2ejVjUA$XW%lkwBB;lb7Q>0}wheLD}k)D0H)Jj=DR<@hg3 zWR#Rd%+A=qf1}PXFC&t^`AbTsKb~LgpBzSpzq)uSCx|?a*T}EbWUUPiPz21P$0{JG z62`0lzI@z?1vTmIZ0kedu2ygY2)>z_E!Su#=F{IR8;vIpe82opjwP)4SKl>xM7H^& z)uCClY8&LUZ8_P*f^v@jq*@DO&H#W+Itp2L!ydjSLE$USa}dxc7y9hD#)P~0{{t?0 zkhPP4Uufd-tl69Sxw)Bjh|IiBL~15TYjUJee?ZnMXV`;mB(J1|(a_uwsk0qa6oONd z2GkbC?{6N!_Ed7rz9s(OXrBZ26rJlFR!$LpbV*A)>TmVqcS8jV)?6NV`7{l9yo{Jy z1MOry!5FXFi~9q}@9?FFAs4@~~#mgd0N+FjOpM6rQq~49LyIf*AF-baJ zoVE@(M?dzDG;d$IyL>f7P=_?QdG=CBL4}5y>HEbl%AmnvHDy-cTG=pU;v0jMvx8 zjxqek?=%inr1vxS6n0hWP}ti9`kaLPcZbekcc&f5i^;0je@-*p-C43X?;%e{@1Zam zY?mfIy=Rg3Di5udRz8snS-EdO*VegLiQlUQJ*o zPOtL|m4_Fq3K*lI93i8+9$b`XiI^LEy$ts+sb}(Mc^U_S@Um^FqDBfik=$_{cB`%_b84Q3SK+p8V=0*mzMX)qq%B zKVn;B;BF?9HEC*g%Y2OI=M5`gTOC0{|2<29?X2C5x#qZ3@6FL_X zSn&{Q7bgs`YBWBU1wBU~I-&id@LwHFt2;tP4SPW{&0rh?q}pNnzL_R}k2i(6)TA2U zeZQwstRv-ZRaT`AUDdQfhs8kZ^8sVs=qi;?IMdB^d@&rK6>3#YNfuZ+tzM<tAn8RSyygwfqMyYkTJ(V%tY^2sB=`JilLt6!Wr0o}$7sof~xYnQ(G>FRi zAUr6tPG++B!?gL3jykk5;n>8!bB9T1*-YDpjmiy}$Br({jmh!s;)NzFGrIpZ{9$Ca=h z;=ILa5xoAWTh^hTSevFF3tFl{(THfjBcAt^BoLu`9YXJbCs zBkDr4<5;*nE)bAoMd0_zf2-rIQPY{`0gYs`uaC5UDS17-xI!@4we^pJZ+)5(Wp-TvTsMWf&V){3_|6kK#sV8 zZC5Cr50*(DsTipYB`m9O42Xv^l`J6xYN3n>+vj4l@g-Sh&FdM4f3)%m$t3O1=BmpG zi^6+3?s$v++!I&jhmB!Zjw@~ki_6SY8uf=N6)&!=_>tQ;t*0N!L7;-4g&MNhgW?1b z{y!`L9{L71QBsJKrY-)36*||vJl!9|A64&I>crP;@ez@}F9LIza(p%CIOyTD7KXu* zLR}MuXbZ;@U_HfUgG2Y!pYLyOc$+@h6emL1ST9X$g1srm1wh=%crjX~%DtR;F17tmfcJMz`jc+erz1U0eJC>J!Y@CE+{N7WQ~Pyu;`?XxagUT{otrE$(c2 zfeQA$2|QfsSH%6Z7{hc9jJb$!`^;(hEQNBObA`G&wq@K6mnCsp3#lf4G%-(~Okl+d zHuj*|0@_IOc>iYDqGxL!nBUk6*I<#zYX8N%lVEGaMxl@;mn;i{lX@7LgsiY_m zjc!2dwc)lH&?h~&O`$WiJ8TCWhr#}N75oek0xwaJ@Up?d?0-U(H)l6lqgC8b^KPl@ zX9Qzai86HL)zKFLp6=uiT4lxluQq`HX=6#LQB++TrtjI0bMgX@+4Rb+YC&@_P%K#G zqJqmut#X0a7erJdc4VY7$m{N?_4MA8y!d7)SX?y`dpG)`*0<5llEGhmZ7J9f7E_-& zHUu&b(OIsAvrS3758m_`DTo#dBL*)9y28!AM_EppS#~eQ4B2Hi_9A6kR4WX=+GIE~ zuv^EuqXCCK!qxfDJUrHIW2ffqKmiluh!!2N)M0iw3?ylaI($Qv9HepEm53j0pg0*> zxD;jNR~Qyc0u#IM-mscgLpk+*adiTT84Z1dFH4+gYh^La+o`LKnGPL&OTNFj>z?7w zi*3tOT_u^^?bSWI-cY^Bq)oGw{~t`KnUM+(8~La6u(>%D<)TCLL^UiDLqwVfP0dSbR+oT zGuNc;tUnVB_*)ryHycl92@hs)0}~bw5=e3+g6xMz>Cz zeh*G&7Xl#H<3u?n8v8brc%sFbUC&%)SNpMIw)v^S5sj0?Xz zImL%ksjS(IKQZq1&h5kq*d<6uX8qBCqGDg%>3Llg1Cq>!|FwFObXkHR&>5{`=?Rr%0K*)JGE>*om zkboym9yI*Dq>vD_pP!!)q(e z;z4E>Zt&4Io|@-pw&NX+JX#9CNF`jg!B$L1rzvx2Uz9?fVCa4x(R4o#rtdays7IX` zM?fDGVv+|HN7#WQ(zGy_WzC!5_OFD5l)_}7iN*BT%#B3P`zLYei0>dHACAI^2k^df zv=9e}rj&E*=N)5EL}3QaLpgFD8>+zrIhFId@Z$KM)iJ;`Sb?=$hlknLg~sLSxQKHZ zN|ho(G`1ZkzjhYTFd^!6*h`A-d?z;i;<4Af!is_{9#ZahWl1v=5%gx)D=*|=%uyS> zq|@n$bQ|Ahy6g_K+S4cUGJG3-FIGGNGU41iUga`cp#^opmlD?1^aCe{ZU1Y{7YW!= zcdp}wP&QWp&lHj=Tn`R{Oa{{6se)d~ux9f;`$D1djxzA~)2)HQ%gz(I_k?WDaT*^M zdA#|WM*T%^FcCDU*!TEPBUmQD{cXLgaMf>g40heDgM?e7<89Zut*6cAxozLe)@IIH z;kg?evStZw!JqR(+>jS*od`)$wpLEMKp|s~8y~nxMII@NI=-T`7Q(@Bj{`@eBZU z2tgQC$4hGe-1v0-;D+^&7*j#I`wjMBhw!oQmar%59t^fWUd)GlahHA8L)bd-pLg0o zfrc9omQlW8ik>tB$)95h$_0fK;~H+nu#t_MldpqnE&TJLiW&MKp20#czSj}P{Xi7) zV_d?pg!v1vWvV9Z+HuR;;vY~|<`~+!8etee*CO3FoNFCo)zeZph2IKw(;_#Ha7fdz+g3A zx3qF5ZcpjnwyP`<=P-w9qO@2cnRw2J9#vSgY;=-}bfSJ#k3#l(h^fR;#a>FZqm5f4 zRQ*dc(9%MZNk#`#6^1;NKbapvMH45-T;*4j38izKF~vAZ6JT?HYj~@}E6HS4z9UK2 zxsyq}&Jg{3gp+nKF8mY4#$S|}Mws%SuGSIvM3kYx9gB(k#Pr`akuDk}o;+SC$5)%0 zeXp7_J#2cqj*KMnUqOU8@s`Vd!#WD!IZ8AxY4^Znm_w-q5W~+~$b0!v=UQKQ@fT~k zaQTtFp>nNx8eDI<>10y%G?Da(863(gT8qR^X4%Oop9CerF~eaT7GU`o@MEqKyr`WZ zRY(n#uoc|lOhix9Y+yJAfs#?r6hb#F)E~Ju(v0mO%~oAiA-(EKe{L$>7p)%uSC$hl^Z-hK{-GqB&?1p=sNK$+Am~fNg0Xz z>;xH=318H4$)GHB%z~V8Ze>@QM97$V_0awisu65b)YAT({8YCIm;#YsUt;`J&ia)a zXn|gB$lhwMr9Z=a^OoMAi|w^dl3{(322rK zvO^U6S!@NWL`11)K-KQaSqKmV5ii_zSl<5Z&Jl+oCn_j0uaK)7x*qWc?P9E`4K?|l zvNprhJ#>xU6CXQyFYyK1NcD;d0UNS1MtvKprsgLiyxo!4G4}(b1zJQxR}J*PUB3_J z7-f(y4U@BU5GV@rKcubUqP|@r|4TlOt?U?V9X=IvLmFZTQ{Ampe;{R+vYt@^Drrsb zx)5MFjJiZ^a^AHQX*<-chCxB-Vc?GIFY823G4^4a{UDfbrrC@$?8sj042#F{;PTrY z^xO$M7ZCZaD`|{^=t(62$GxIq<{578z>`lwE15G(YP7DtCWPN^^a`K41v}G}-wy$5 zF22C*Nx^Q4Q>wv*aVvsSA=dZ{%{;a@>a&QRCa40u2sKh>H~BZf9%EIK6Z%-%Tl#*( zd`O~D&&oND-ECJ(9?C^lhRHKX?(WPSdLzxLZ8q-1a6L-O6IY=P!SpEnL5oW}sPK@b zhMsHKx{BST+QEGk2$_yZhfghBOtSE?3c1LP+#!bTiixf@ z4?Vpx#=0{Qp!|N5-~TJtzPe#`J!)Bdblncj3g3++P3d!T1$UQoq`15eMb!X8Bdv^x z>sZ8a2hWUyTSb*kX)wmsu|>!_N_^=E(yB=%(MDrw>34hNqy;UE7Vk~gu>bNyYt;y<0e>YkpC)7zhkwumDBaNKPH9hM_rgjgid9 zE!o(CY17*Qhr0PgR@Hn7qGNLd$CO##X3^v+X%M&toClkGqJCFU3#>G+FuUuWs*8MF z9!;26p1mfY+PF!8tM;zG5lZI3(O0|n=ZBEM%SP7_yY5+V*Y2fEQQp5(PyY^V4h!+m zGn2MqjPa&pnHWzoFBQy?we$esJ4w3iXHR?CGa*N;c*SjsVRj!JQPVyXVP4g^uR=Sj z)?r(4Rt^oszO~XtH`aS4Zpe=g`L_cmi^OtHbYUA1)PSrFTW@MOI*UDv!Lh>Uv3gG zYG9a~l$axOlT)MWr;1<-u|}D>a+r&ZB|Fvx5=wCp9t@Z?0|TO_QRdiY)t-p-PllT7 z^CS$6VRUR62BuG(j^YlStmzskthpzlEvzsI1wB!mskMP?kjlD(ktM^}If7o8dnIxi z`)Yqe7-Hv#|Na}yz;Pu##T`jHI6+y^CC<-Ienu@H(^1maj~kvA8HTiQdSB&k>Yp-J z;1FqJ3)1{NazAvS7PS}W-`__wBD@$`3Vh>Re5@H-J!(G9Q77Wv`t@4H+M&l8o03Ck z)wu>-^KokRM{cX$;@a{0>5z&T(~5NyQjW9_8q-8kGd&h%Q*Q~jp2 z<0#6hDoodfJd0Obzye)#3}ljN!*RYkRnGCQBq$q1cVquUOu>KwBf}Wpg+KMg)%6Qv z8LGO53#@$gWG_{`CmI z%!;xl40;$C*azc!C}W>{UKm@`Kt|n*XQB`qv33&et z11?7`25!qNzn0g}7b8-XUjMs;C~d^PI%BHSW6p*y&aJ>$C5ZiH;({_X4XzycI(1SY zHyt*+5u=Lr+Hn(ST8F%3NaFAvC7)LHP|ct$k!9&?)=6am`2}l`v`dPv40`7l@Ll$PC?Ck*A6$-N|(s)R&Zrs+6 zPdRJwD}L@Dz%T&Gb%M6>7N5-t@AR!jmx2Xu7hhB~*aKKAW&wJ+ojU#=Mb%(#6oT|u zli|Ql9!>|kd5+CmX^jWewJi-PHrZ%4Vo(pG%H}OmH7DUEN<*&(S6JglrbPGM>cnAF zE*$w}6Ey0ZEyF{0m)&G6;7u=FjRuC497b8V`=8X2#@ZRw$L=G;;Cm*hxwghp99fZDGsb2dv8&_g z0WUhZGS}J&zGKjO@AP=U!7C@$pS*}LJb&v;L1UE9jq9&M_zj>~S+{x*sgjcR2Kl{U zKJJKHp5POWOESD&gyA{whmJgrc4=I{eCmHtLtxi(MRQa1b9y2amb5@Kx1r$q7Gi08 z15#Z{Gi)ybs6SQoZ0ODW52mYK3trvuRa}$j1+a%zDBqYV4km+aYBu|#7=7R^#`hNo z@VBC;O)^9j?jISD5vokQbFJAt6^%zZ$h8^q%ex9>3Ki3F^Zs}t_}FF@wxJ7itU+>` zmJQ)2&o^u6a}}8j6obfIV{407{3)j>keUq*t3+M;&?H(Ja}{m+b<@Q#tol=dbq)ot zWdTcf;@|JcwJ2_?5RZGr7imRx__cTJ_8Wf`j9V&Y(u^V@aOQwKMy= zh$R1+#Br|<(@2LqL)X0(&7rFyIr{L2IJmEz4PYbM`Q(}ZH5>YVDBh-CJM#~i+Ewm$SbCo_?wuEgN z-rk=zPh%sq=gLJDbQtk@5`Wy~0oNV_Z9+T@im;FTdXU%m;1>EgTv9 zlKeYsH&Mo9N9cnUcg0y(ufBbKgfH4JTB!;i*~h|GuFaJIsRF*y0Cw+=^Sp<7g>Gif zgHb0!P=Zj=@1~sGe zDQK)7KC&q_h}TB+ypm{quVQYkh(oM@qVlYZVk|owA3BtrJ5Z=61oSG}Nwx8Z4~tN9 zE#m>jOGT!!M>$pXGR&_EznRJYaVI=f(h;Y`hiBRRR!rF4Q8W||=aFl=6>eE}t%d1m zKrS9|JNY3euEEBsP;BQ;!O4>D9F1$h|I^4W0RND+Ipb-SN$EVywk1U-r+&%U z77X>K(YPPj^d~RQ)3~O}Dcz_%>e!?v{NFU@f#w7}x$xHJwuug9tv4X+5$Z&X$f^O~t7iN@d(Zjg3EWv`x&Tc%#b}$V<$1=NFY?u9A>hRA({>t^r|b z&Vx6Wz+2jr1&QUiN!j$wYz=vlRctkVn_r@~La6kOG3@f#IoBgMaEJP4O-(!OQKT61 zk%}_El#9iEaS5HsV9uy%{%E+e=;MYZjd4>zDX%R=(Y9*dOcus?UCu+~7)z(;EpUt; zt}9R7=4jW_u+&;?}1oyGr*-MF0h&Jbdl zXKHy(ArTKI!VMIQ|Lr^V>=HX9Z;ra}h$7Iewj^O^(Q5XAy`>5#z1m^RIk{+^xfF`f zbd~LViRfqir2rmYJ}pf9)&!NUp>>83NeU**je0Luek+lFo%9mNOic5Xy4qq6$6{wZf$-Dq zyTR$&<7zXQWY)j653if!kcf*J(U&NBM9;HuzG_r#rG?D&NG0;NgyfqIwNmY(&lm2u zRviWU#7NaX-Six;7PJQ^hXq-YuLVj}l(rJ3)#-6*U}83utPRB)(*))?_Hwm}B`KDKy4EQXMC=1J?R3oNg>`aYH?x>HmDj2JtkUexa zsFL(`xRi9}FrM{YjH8^%kWJ=a>kPa#WW=WgIYB#(Vgc&R)V)2L{2ZID zP~3asb?iPh3>zVF)Dp{ncce2q@ekxjRCAlr?muG}Tn!N2rUyA3L-I6oRno!`bUjEs zg@t9OhT|Mr$Vo*BIOSW_6ns_WxU>(%I8>!ItH`QiVnQUVuUmmwshvlC^Q!T#c@y7b4>SoYudTF7S^znfS zbg(ErYa}g7p=|6me-bk%X;4I`XSTYbURbb3ea}*LI^l4eP4?PUQBc+Mu+!%}g~oYr zmtFJp@@R{Sp=(#xKE3Svd^wwj6k?yeGN5{(&Q;GQoRm-`(EUbV)b?$hSuaA)2cTC% zxRHLJr8Yt*U!pl&!|fx(HUDNz5B)>Rr`He+N5yR}NmiJ{NbrTpsR+`WN=Pp64i81FG$90Yi(9mYOM@moVVZTg{X;ojc&-kyF zJu{?bx~#>yhmvuoKsVlxLLygQHvx;ZvtnYdVKD zFPd_8$P=}X>GLIzd8Ss3$D$}(*8cL`SpOcvIEG1>Cuz$fhn5>3G2W5hW<-h`O1Fze zFgx#fn>4;FJ9@OThWYob5MPu>kqB)+z(zJC!Io(Gw^xB0Yro%u+*+-_q;0?A`{jn$ zy{0Q^G^D1fFFdnKfmdqBjsMq;ly-)JXb~ggS&QfOt=g7(_Ha}uml<(b=N6fZv54sNCt>3k0Kv|^*~PJD7Ce9%+xVq_;#4;I`Op2sN#eD3q`;I#o? z#Fg(A&2dVJ$L+Yg@lJ`F%P$L&6XGOz`0kq3?ue_e$$4u3dzN(GSMB}9fa<@l9;vLj zc(Z$q9ZPp?F6sO>Vz^j(^~W~5rS-zgrHwb9@5MA&KVCLet!S-x+q4}ERGeo2tTllz zGV#aAP10SLFkOj0lr&a3(zBmC>MpL=;WK4 z5Ix&&ll(_0bYOFRijyxZXimHZ3<8RZ6r^VkW$(mA=*%a5vshlE2Vq7=$YjXSlfdyF z)AoM&UlXuy)*;MqzQw0*4>byX5W+%QZ<}=dR|^18(M=EUfR}1>Sje}T6`jo5b*Lp9~ZS96_9k09VMh@#I3A~xbW`Qe|~CU z7X#dEOszI%gG$}aE^3(l9<}_T=O3B!*SEscazCJ*OfHA*FPVntJcp%De3fl@0y8j+ zY_RQD2Vp#?AkUWi&ZS*6upac?CG0LqhN09dWGSgx~e`KmQ5@TX*829b9!x=6Z zupg+)(HYWjaz<}T3GOnW8n=7nq7~3 zSNWBCkwPy&kOw*05WIo82;wC8MYi9GcYLuC$Z?k)85W!cqZSqF&{pw-seSr_ z@;$W#yK|v9JJ%@uk)Sz!WMa6x$>M};jk*Xoopv;7Efce z8&^a9Kcf8u%-@QhccCy0eNW%&vRbz54OZ#>lOyE?4F0SmV3bwPj6C#7z;jVdi;;#i z^IGm4X~VDlrCPSj7}alK&1g~y2)~ybK{g<5Er5Fx5?41oB1foNP8k51lvd(R6YUKY z#uzc!P+n+T^)clMMnZM~P4>q;&c~{yV>J4DjRrHmryRS`)PK!xte*_AxYLrebV{YC z(`z4wf+weMz33zh?{Fm|C%-CLi_)x0cHYbt@N!#X6jvFB)^2vjnhT0grE#ZyI4m=v zr>$x5 zjD|{BlVH)-ayn_PE4cYw?s}R4BVrQd6c8o_+2zKiMYLR4HxgX_eGNVJ;1H60vFngB z5|SYo=d5sYg>*-n+*9eyaT){prfoVg(a-M2tFtF*Ec1vX(6x_BweV=L|MmN~>~(Z< zN~(nBJPgoxR%`^|nG@PE@rN#bwQNFsuThqmye|@^L89bSbBWWk(6b^@V3E^-qGn>52tQlBc7#8EVjSz! zk31@_;gj9QMaNvE?Aqbv0cm$;Q%l{=Mh`ntMH9n@V3=hhK?Pm6y9hb?{eel?=TdyD z>4Y?;Y78ZyLV#I$&JaF^GyTvheDu0L)pd8|^-DXy;M^g@^z=z7<%~^K^;`5aa6y&d z!f%$TTWL=N>w2Q%P9D(<{fDnDnL$DHwFCN%7Xgcz3*@WzOCX*??>2m)>b&mk_ip2%atqSM3rH70p>d;xec#WGO?Y4KB3ZR&7H_kgK`p3IfiXTd7#-Na6iY^rbm#W)P z?2Gy)d}MsN?{HylxKidu&cuIxQHx#(_kTa2{zICg>B%Ej)MpU7M~n8LlG=E&<9Sv&r?U z@4YtQ1Rrk6tk90_q3Pw9`JJ(ULOLghhFa;v-1Dw7oQd;eCEoQ)GPZn2rEXho)?|_m zg4FZu>{h}cmRO4jy)8^tCV3Azc+qKAy1h9LrEnUHWiZA1z?lNp!aAhu0x6)-J|G47UL zxZd{h^CaYhz;4JPp~18o*?^116r1NWagTgnEOrxOu7wGg=TBFLigFJfJ3z?cdo$f4 z2urUoHlcG=)ce+DQL$*jP)7A-lXzkRUV1j1qpn~|P}I?Ppg-vD7zSUyJwi^2JZ6g^ z`yCbENe{hnr5?$h!^F@gaEWWU;W`Iqa%O#+c}`$R8?;US6PtKSktCq7n@E%Lb-hqJ*1#L1}B|ZAygF|=Cn>+BXzIOunlN3bi#{kfdEot?I3KJJt7)D1=U-#Hi=X#vc z+WN~e+(RD{UnBgkO4K2MX-lV=x=U#|4EGuytldq56CC1r)|kl5))FAzK`Z9M0)dIu zE~nYIr&*{h{1{4f|8L_!ND}F%54(TP#~D#E7xon3BE7ykv&}L8oezN55R?9q&`;cg zVib>ZI&Yb0@;Met83OwoCWdpnPejx|{5X7hHDb=0B!-1?vM3=3H6rba%EL$>AiQF={&EXoM%aL3<7QP{QQs!O>DuP+z@Td6;B1%dUAEQ>h zv}c3{1S`whU*PXbt^DSFRIe^+j~AJ2&jQR900Px%GwWP|2m=+NbM_u5kO-dbdk%4?MzM^fZ=}|S-l$qq9MpAf4v)5U z^mH(U^@spm|AZ?k*2KuJE=HZrzvzsDT3{NNaK}fKj<=(pq9C02>8as4ZD{iuxPRFs z7u4=c_^jUxKQA}t=6GT4Hp4XP<%asoFAs7fF~IIZ!=Q8=4-{4y}Zx2#^fvh(+Yh3dzPPN zx)Ez+Lp`At;xGFd1jl5sqKFAej7zFjB0jo=CMOL@?Np98P6Tszw=$s-yi2PudnU*n_U4icBN})FzS)vZ)DR}7X`{>E^Ul)?g1K(6~HAPQw?)cmQ zdp#b-N?8Ki{d%zM(iLm- z7Ba30)$U)%g=S!s%f-Pw;K$XmWL^AYU^Wy-NB`=Pjb_F$tEUAm&1C7tci^6ov zmjosBU*V7j$#U+a%_*Awm}b{Z-6tFHVshQXkas z!88YX>GL}v?cqXg!S7ndj>m(@O~*o=ZC-p!{oBzXF^z32F8-hZPgvV<*wXWIOE3zB z7kALE|A=9mEgop-==Bnx!C zK1fAXK>ii}ATt}lPv{ZmO&)0?o}DiBMAn?_r8{D9H3e+PSpYU+_}Zng%^rkLJt}Li zL*UUkeP-NoS>Tkh{3FufSz+hPu_tBbJjTXJux(pdv?RSGbeYUeGtSM#i;ZcGv1$V} z$uP0kU#g7FZ4iiUG2{(k$jC(;_b>W(5LHydwO?}(i#PtX{4)s3!+_nD5uRKbb{IDg z!SS{v*3sC&2)B? z1qt!UOLT{}D!=mclx|rY%PIt;qD;Fe&Qa(WWkaIt`&48qj_zOsgspx~%n}_PEZTQn*8+$-0D%H-3oHns; z&A||A8*I8YC7AHbAA||F<@^p~{Ma7MQl4^{96~9tKzuC2vxDq*V1eh-B-(UBR`?R7 z=&lSkijw^pzDleymK-Ss)XdZiY5B>|BP@plSHY19j|KL(I!6UwmD(J7ztaIrS2U}= zWI#Xx^FtU0ia4m3Ffb`|VXQ$4wnjz%)!f0MhL*Y(iMEN^T?d?p$03n8yg^+5)to>? z)Ot8Nq-6CQ1%s+LG1%FXisFMtdREhp#e|xiOmS5h)C&^xkJzgL58**o1<59SAA(<; zIBIl^rZiI%#TP6vWJM`7Jchcd8wTAljx{S8MVkH^ zg08i09W zIdFMu(RgMx*dk9L3jUX~!z8f5>Bh0kt2BeJK)g5}tf=P_ju9Z3J+R+eat%@Q@KjLH z48@dd8xjsbGtQJJxlD@1a_FP3p^h@O8C<#~$^Z7ps_S~q3cqV%2x16{|LvV6yBx=& z#{fXdSF^MFeHlfzGz%mEMAN9oc77z;e|sP99Rj#gDNNzo;$*Zlvy2qGeE21glsG&I zgkPpw(KFP0;P1>8u9m@a88%`epKl_;8;CISJ*AXBc$jUuk)M%9%%>V_6bKWumJ+a- zo^3*_$fng=I7Y(M${da|Lj$8v5^X6id#@PLaZ<2tvxi`)Jc0Ay&(<`WQq3mnO&w=i zX9L7V2^(^+-*;FJnO@poRwE47A#lPkuyaXlpKIRge9eEO8)<@Y;&W1BireIE*QU(e zH7|0BGDMJn2s5>FbAYjIWH9F_CKFdjMc6Z3ZncJan$9v(t})uK`X{Be zqx#NsMc+ceK$kfBXGP$|&e3_%79E~+Zq<6o1jZkGNN8>sozQs4fhZ(Ql2@M7jo1W4 zgDct5H3f^>dWo?lw8uJWXuLu3A?kw=`TOQq1F^dt$_Prvb`w#)$mgMp2LYSe0C z0gYm)X?G*6zjo|w8_Y;1_-Sssw~`~FA2(u1Z4jJmtx=3se-(1z>4-xfi7LSZO6lof;ZXtW%xm_sA#w zsUA@$Pt4Q%vYT)^r5}D`_xy`@zrtY6bvpAR$JGX}lQ^UzoZ3+zr@dh&lXOC8xcciN zzX84L7?*&a;Lhr&u5DMBi$1Yz;;6s1J<`6RS(%e5TWo?BqEz`C{IOK3$HxtN#(-g` zina>VpjG(qEmoxP* zRcEQ>HbMSfawd#n81L`r4eJTvrp=Jpuj$76o6*6h)DT`Z!62*gyzbJa`FMfb0;QFR9VWx6Vd)R;%)e9}WS z5RpD|qCs~98FhVq?*Kc%SBn5sVXAJm^cI4(Y`aD@HKNC{feDG688I520vS9V=9|+8 zG@;i>+VYfScXPCDn2z%AhVGuTyo@w9p$bRaMsIbZ7a0e9>MeS{w4@o^ ziFyl=_pqx;4N`M2Nii{9U3ZCkeIuEsXnitJ-pRsY0J`;v26k3s_jWGg()=+ ziPfIsc0p$tsII;iM6H`*RJ{ARo8kY$3FXb9N*f^D!^s6C zl@9sQH5QnzLkXYcbzVdDr=0|^q(L!hlWONwvqEelj?8P^NaQif(dUS%Cp^fTNUA3$ zqWMq|{UCWpqpYAcke({U7@oT$Y7ad~bMk(7^yFuVi{xSUuRaK?yxolWzr!JC2FPjo zHCgSc=2pkp6+`$c37F>ewh$(vi~H~LKc-ey8tqAV!HP8NzF;QVawuZ1zf9C!S$nNr zd21ofjxh7@Uh?*+a=>hT@451`xdVwlx>7Ng-Ho5pIQtb{9GpIN+fF*H_kN1tDTZf; ze0P)LTaLp|t{In_q!SuM)^)l*PD?Ko;cBFgtu$s#v1GX)IEF#9H(LV%+ShE*s8e@s z_qOXFeQ*m8Y$K`VwzG5TNgfAOLj9n00RQK;wTt|$!c-|)gO6qW2}%dPl|bBVdHri{ z40fpq04*l`B#kYQP6hapK9Ncw+j{~J*v*HZABB)-Neda* z_?BeSCOzS(^$P$OhZf#S8Na`tcH=(0ACil?C9}89yXL>c>^H_OJoZ?-GZrojVlR8v zPvjFwVEm0eXEx^PZ}K@cIYlyMmZ*x9swTC942gdTxvzh2+c=;~Qi6%vXQwOVMT^a1 zh@|*R)!zjYtv`nzdS6E%Ij}wiP%xJchicMTPHV5EEN2zzagN!BW!v>z;T610*sD5x z$Jym8+Px}_>@gM3gt(Gh2~8yUvt?>2F*Wx+Y4q-;a>1wA(wa{%*hm)k&!4@zz5st! z{GBEJCIX+>-+0rGngJ*PBcsoZw0QSI*=PRb>m+;oNEhu$c`6vEDyLkkP5&GGl66&* z_HFQ_9A9RgM3#+tsbO@wiDcuDCuZjl!i8j0=_=^uqu=S_Qzdox_+sluD^{~qAiPuz zlq-gTBU|^k5>MLgkHXOJ>WW={0R>RT(qSv%zGHNtv!QG>XQ>It8z96j`v78nHhfDS zt2P{qYcP*CYOH}U6eyEJi0?a()wIdta=~YIct5jqWx2S-50-3ul0O3?+8zxF6&Q0L z(dn_}BGmhR)sey{Gavc}8Zqm)0ue>g+~QcC_(?~QIXUXy38wHY_9~;J(m0V8WGkE| z(&CJ&Vr>hK(%FsKWF|e1h0NVSc6uY=K#0E#TLLjOb^u>i6VzwLsCw$+m%jEvl$dNh z5sYs7Lczjkzl1C8_yr%R(i)gOF-CrHlbUM^7}k?_Cs(GH^L6?X7l;f|w0$V8L$VyA zYKg%IM7VIz`A1`wh*lLNaLKEYRW55IY6g+8;XoTPw0PHe{eK$v*T+!qb^lh>S^^tU z8C3U+Ba55oJUDD$3@Fov>rUjO{9UXRhs;Km#KVDvaYkEWMD;^nI;dKClmbi1hXOdL zDpSX=OGNFI3Xt5Fa^U+2C$Z2}Xqn-~$koTAu6mCX*xi_fhfx*|h6R)H3Qn|C2F&ja zTM)d|YyHVix3pVQV^u=`gPLjE*I8V=XeqQBf?!nCgcYwKO8u=*>{5dKQ2f_#tUGF&X>f`ZhKFPK%6HvBE7P^Ki!bip*`usJqJn`184EH|HvN8T~H% zIPD{2XKD8>!;d1|!&F&4(YR-N;o+;`(HLVTW^z%1ampYtt;? zy(lh@?3{ZtYH`i1?I@L*e+5YNE=N_G&huH;YYJ&_-W1Qz?R|;=4;znQD6I^>XDS7d zQF>vUEifB%xFaqpAsV?1OcI;oI~)9T*p4Zxa~^4aqWjSYp<>f52Uq@Gz|!&-#AKF2rMjEt*mLEcJ+MH6Bgv(M`Nz=ZYee1!sIJ+sT{R_($F6!{*13?^#2673K?H3XQv; zrWosl%MY2wgcCRvoC8rR*uF6*<3HSm7^Wv*2k!UFKdUTI>fOUas?URedNpmxg9~PV z-ZVPQg|3LVy)`eX0NoIFS9{+H8QJ26X5A2vm|A3h`u(768RDRo#pk#3lD%M^bM6Bo>5o$5KftX9hNyBFq;_PiS)?~GAB4w#rJ ze{j0JPu5_6F#azn^GpnAOL=h|FOkybU`uNB`0!!NfE_&pJ@oGQq@b_JbKsFXh;Pl1 zkEzB0HYSaf_{Inzxp0#vY6>(_tMTKNmIKVpT&wZ#_T-Jl`!;gGR&FjBO7Y)_Xste>LZpf*Gr8oA$0Z&0XO z-&ZC_d@~Tiv@*8qZM?(6kQ19k>PwL5hW$^^MD=*nH|9> z9yC!#{n`pni-YG3hCzF5F;=s~_j@T~t7F?NRxaDFAK@ApLU2G`u&*(pFZmUJJgBfT z8FF}|!z0V3J4&sX>PX8;@f8W634+yCFzgv_oCsa%!&MBjzv=*g{lznKg!S zI?W6UD|*SF;6tz#SIMJj*{O1qw2RLhh&cNgA>@HbXqE zr-XbjTazwG8camAdcOGT%4L3~GmFXVv)>qDy^OgyPFLHhRJs&1F#XPpwX5RU19`NT zcymnlG@w)(v&ZnU(qV&T!>mr67Ykt*Et<@hUYihC<>0v5k&8`B!}IdxO(yeiFfn%qZ#r3DS+Qc}BHDt8zYIMI8p zs0Nt@w(QPcP%ao=h@W0+)S+XFZTiE0T~8}W)6x(5u0lbSuaiRfkds?&XQrxDv?u80 zljM|9KlPn9XZQhZACpj;(||`f(wvdBZN0Iiv9Ub=5B}SW?_CF?@7YXOL8*gCO-E+utiCp^-3<3;;84qu_nZ4R-1uF=|8ET-;WHE$%6Bde1{7Ef+S=wA>rIuMR zh&OE*mb8>C`fJ#?O3&1+AVUSyicjUQT&6#P+h#XTs0#<2>5DFj`Mx=HAz2!*d=}vu$QF3o|+w8^^K6(EN$MbgOai_wsLig-A{o?Zl9Wz65QMEbooB4PcwqG z=^vnsQ^)tI;8pBj8G#(t5Fjf;{c`L8uC2k-YL*pE%y6>szyI7)x>vGM2k^f92;rAR z`Mbsf$Z8G6)>1LBH+^J$@lyJ})S38?hl4=Bi2nfX z|6-96pbZf&0Y)?~nxlYSyOkG%hd%PNq?1#G<~`Uxcot8`ibp^QuY{KkvkZ%ccP+Ne z{}nejUbwX@gaahKS)lBt;&=iu6#5&9-!SuJfIk?Oh;XkCH2N!Gj@`M`e>!f!jG1P_ zrV?&pSR*=`91E1F)D2Aikwq9|S%BAN~Uig*pK z4pUorfzK-s(^)BeQ& zNFq!<%*~h3pjve5n9a&}29UQKx8i+(L8C)>?^kPw*9!FnA5=yfC;!f1Y@EI7wBh>P zvgZ%*txSZuWM-uTf@Ztm$m>z^IPn8UMpW^j4uk8v+-EQXvMvYNeM#jZ$zd6R;nki% zim8LqUOM<5N7f1VI`w9wqPP}hhQRANa-=RVlp?o&3>;Cc@%i4{A}oh$M}4mayRxKE zsthATN7%;bZ20J^e@X<{4b!A!ZZ{Mm&)-2-m}+xZ^YDdEwkQ|P98C=)IIxhV9lGg# zg48k2KdbOCFq$12j!l~Wb7ubs0ha`CbtF;c8CzIs>xP)_y5|K~$MnA1iWw^Y2`gEv zBrB}b0*R&y}TvKL;j;k(C0JDR05?NAR>^6mnxrkA0ygojmZ$t<)EJ#%zPjaZxJ zGTdKP{-{xHCJpfqW_Kb1t;9Z~t#7-k8pk*nfj$oSlLl(odQHX^H2^CeZ|$irFh@T` z$_=t~@^W^OjTjM4o17;llj`AV1t4_rgFt#V!H{Jc@L&&XcIiy`Dsa5*>Biu=O&zvX zFmy3n0GrnVwjk)=t#{txhfJ~*3oqn<*21S2hr z_p^|rbB91v#6^Q)r85tpUjpX4)`>rWgA}7P_PI zh?xfv9z%ZJ{T4`Y?0revRH2znQP$A)0+IS^!6KL+&LR^>5a$OeaVwUNhb^fWj+i0A zO4(;G@)8TKZ(A+3hR?%X^naZ9GYX)s1iTZh=&Moa6%gdt;SJFcA4L@=DXVA1=%|bIxQz1y;C%L!hB_fJ3!duD>^2s}2 zq)oj|`@)f)uQb-4|2}?P=0{}Dho9ly1u-(zBsw`R(wvuvMUqIhrgSK;gePY1R8Y>9 zt79Z9Q{iTMzdkVa^=X3hYm(0gCDN6gPUcGUn~1W~bC)X5 zvPb5;wUR2>jYM1Mp%gXje!eXc$EIY2(q^1zic1s4sbdx+u$7kP0{~X0f*p8d>S3he z^1>Hn>Ws9X1aMxnI&83VDsX^3?ShQ%h(9xhr?*C8XpF8((j1`2&1M3cNL(7^7#oH? zkGo@nYtmYF99r64W_Zijiiv%fz#PHl;KeLClDrG405p#qpt4jPj{IF-eOs8uBoe|dTA?gupHdS$b&%w9FeDD`iCL2oK%9szCWqF+#MFj1Sm(TT7z+cqmr7vPmH}W zE8y6JN?9uxK(7zps6WBmeXS9|T)|Z*BcJz#zUazv{_4L-{Q%8`5Tv4$t*T0cm1>ZD zWO)}XfQY>p0ZrP7?2W`@guK}^OwZ8POM{Yz0hbaFi!B! zf)jN`N0R>=-|j~?8c@LoLc2fTztNkYD7R;qce6)A_o{?&itaD_m0*i>KxRpruXIwu zr_psL-0ee6G@ie^e_mh*vGArh$X?G3^V`zGZl53ct>M%RLr8`OIOSK-jT;gCX?s;96rs6i%}j zAL(~KMl9W)4c8jXhbgLc!^JrOjcQKsC`-`wOkwMTcB0egDNKSL};Q=*N$nND@(wI!ZE@xpBq3=CrdHV8EfPyGVqWgGzV+CB6I zJGLlJZRSmWc;62E2Upi?Yt8NYH!Tq&H1Y9J!Q_&xgz}W60)JE~!ybq%Mp)zvok7~A z=HpC<-CQZcAag5}>1^YwIuFPO4c?(r%6>N9@aJr^dxHvz=#6M5elO&Gv}%uLFKh`4 z(2BJ3_}R36Sb-1PC1a~}H*y4*boxcBe$GXKQ@K*u)Hdu#>h*esWKIZ(h>=5<3Jl zkz~XlybyUSi53cZ2_LZ1CV6?zSd&1M+nz8-1oj8A;y*#Nzoek)aN#TE+fXRdh0Kr2 z9*idyMC!I8kscQ}PDjF0G9da8wog-xZP!(SH#Xmot#bN+gVD1~Eb`NyM)^QA%Y$b1 z$HG!asJ~o?Y9h$_uj&M;ySpQa%ax9A(_P~H%Q9m6G$ zBaYTNO)Glza7l+IXGHO14&z@Eg_!mu@=aqnQVYQ|@M3k%s9I5=-IHWn4M5UF{PscO z8%A_dVdNb>;YQ@U%k*(s2Awt6#l;vc?F>x}kfy5T47fz%Y!jXJTgv0#H=vY;g)<)+ zZDx#vxOM4q9wza%V8&!t#WRx##H%KgL$k8uSusQ9IWvq)Bmg%IBU3}%z10EJBMxcJ&t#72qNe0$vTfy+Z)Gi70 zxOlcMz5|tHUsfaO*b`sa%VPm++qw*#}ZC3_`EbO zrL10u`Ii*T#f|S+l$~@5y}!PZN?C8Z_{7_-&cU20*UunW%HM{oN$kPnHN4hH!HNeH z=gQHcd1?|yR46Z?ij_^ajFMTLB2`)oOKl`y>2^Cs3z=B6pugs=rSYGCUg^5B`R@cv z6%$8m{6;z6dxe*Tp0FGCASKeK)T-4;b#X!LL>X@RI!WzA$*U$JD+=853jKR8+O%Tz zbEDI~L|@D?3AnENVXIYR{vLs@<(IW9Ops!JgPnaSlXv=RX^vv!5D^cE2f~{`(osA?kHL5I%jkSs0FdKMyS1Ha*1e@XPo4ujZ)L51k>Gz3SmUr_NERF-GUVshJxg+3+uWG-`#2NcG z%1^M>s)bGsrj0u&Af z7vxUw`o*3|mUycp=@?a$4#7Bum2;B`R?0}&v{_x|Yq|Nfbxj|kBL~I^+q*|HcfOUOg9WxOmq)mKAMj(hHuF22q z#P`-i+NIwi2FBv0i__~e*^)fp&ctVTi5Lm2sFj@RUse0d(P{?^{f6C=&?8n4Ny!JP)bMfea zZ0l{y{pn$oY;*N%(hqB^`=f)4FRT|HvRVH%G%7mtY`COk(EiIB$hdGdnY>)hi18u#zZH$=s()R77{%*r0H@te0W5z>N#WtlssYz` zFl&`H1;!Il6lif*tDT6KH-xG(AQKB?fOVy=QK;Okr*<&+pm8`62cOge{bEk z##8ON#=Mfa9ith>Q_bWWysir2XjIX?uet-tVZe#MfnN!w6*B0763^QpM=-(Gy)M_i zr?WF&j`G+zm}3!lj+dO+wOR_=>cY!K?3ALbT5AX&%sf$2(~Ee>x8noEz>#3N$*;|& zw=v;>H$}6?>`i=Rxf*Ha1MVQo^)Om2WN|47)6;dU>tD=?RI`YIxy2#BafFQ^X1&%m zg~ucs6O>p;)-V)&4c=X&=VkQxKDqz@$2xfbOGqT^lPXMBB4<215HE_GuteBPB77sY zk-_jw1N~gyU@C#qJPk_vb{CX8HFTy%E-o^}aEI};DC+SXK^hwPlO$l_5cmKG={}M` zCI#@;h`@wDqY}X$8Z1zf!7Qx$ky?Js5VgnB&z=Z78|7PHr~r~_q+5}B(3M$0I)&HwCQdYdX8@kjsrg6&#Ka4rp_pqQSN3G@+K zTxQ7{Q6(a(bXcqNir<68rg~1g7L>XMQjY{=-;D8fiL0t9QEhFC8)vj2i;U49j;4yF zxqv_fHm84Pb&8-~+#NqH#($T%-R;AVYo)yKiW9D*z=k;Mo24&r4ByKtL!+CaOe&(` zeH3Jx15t9^_B*}y*Z6R^CdN-KD+ z<<@<}peZu^ij%$fSQEa>DF{b`sdMUZzC6?RO13cG5oUX_SBuxjF%?j&%`^qeFf-QG z!lU(spCzu2h2Y7&(WLqNPVKvIVd62;uT_*$stt^ukQb>Ye1Ol5uE zp`hxb2vcJ%|33=Ws^PWW!#AMaEAhNP$cG|1iNH4LNh&(~dxfqnw1(DGhu2_Pc~1x0 zld0i1;yJz$u7k#3yZk0E!oM(R@iGFHB!iPVR~9DKCL3xPM1V)g0tu##7?&`gV!$4E)YO zZFR(*h)d<^IfPA-DSh(t{L+B1Ga;2S^UT}NLys#HnKzT?TiR)&^!X+}g?3h=6it{S z;VV5A+41_#*Q+y3?S&a)$mo`QYDuE=kur|y<@u_)0lk6+9AC@-^`9<-MLK8y?MC3k z1KP2zk`?_)N>;0*<95wmM3=pOXYpYzla`&GB`<|WMKbIcy77&)%D?DxHa2$L9LU^*yEM6%4FdU z49dzp+L6MDlUDxf$#RPp2{=P9PoCG`jJwA#yb$K6^}lSu3e&2^8X6F#rZGh1Qc-_^ z2e>d=c{uLzXZt-VQL_yh9RjICB!@&wDhETIH>6EjU#8~0XGO%%!pi)q;Nym_c)R>^aLSqaYN;;+Ax!8$8EelIyhlQl;!#$7?inhi)Rpw=k_3rbbGEe zF(8AfIpq`MxO~3+nyFx`=jRhi46m`lc1+SVS^TI_PbO>gD235cD^k{11{0H_h*}e< zyS$+&=dC07=V}s>{eVK4%?3*VI=bF`tCogO+HnBcg_v&zUrk02J#KZ!3V!Ld`8%?o zO7n5jBpChHv=H}5+4~qgxQ0nAuS z$XX6RkHKT++9Y~tm#TlLf{g5u#IN3rY0E&~-gMzQ_xS}~1$$R-oe7O}#TOG>V2D}n zDsmN%M(Fz}A>M}8w>T4Od|bbG?spjs<+Tws$c|{e+X_@(U^DD%8%;rZ`spC|76EgttvTYMh7A_Hvlt z6A$V}cghYP(253(q3(YKs&t70(XM);f0mK+-(T~)?Aw7Z_0cXpcSH~lFQ^U-&58A5+RI>vBE#!Et1zr>y2e7885bwizx9cJ-?97SHqB! z@Sg-9$%-M{2bh(^bL@Q}Oo!-g^;3d&<2X(I9jWF3Sj5&2*q|~u6SFxe+Bz5f&3i`n zc?*%hUXW5X5W9h8h9On^D36Da#(x&ye8$t>@H$lM9cF+3ux7_~abr*X6@-9lCJ+a^ zNK8LtaN6+AECQ!C{bKz>$jaXlVWhWK9g5V@inLin$G0~*i;B|b{{z23K)(y-&%5JC z(U${UIO(;FPCkf=_PqK2V~- z!X!s#bReuF7POb=p~u||eU0@{8)eXh%to3QkPjU!g_fd zo?nmhJ+(-i9S^lsEs#c;001BWNkl}rnSR}jnAw@*V!^w4RA)zy$?V}1h88|JSoo9C_Pz=fwp=S_E{0aiFFa*upXuC!=!1^%#zolXg>$)WEHgiI_OwHHh=eJcqMyF z=ggU!%>F6h>JbE`Re|---iOAc^%!m`L4`pHv$mO(ar_*O#KOt`&>;=e{M6_g@jz4< z`8tnZ7W_OIwIyL`RyeBb#*mcYi>mx`o--8zEOZ+dk%TZ`SCm)QVrZxzVUy<~HPZ*% zw`|9N-W3^HWV=yQdFE>|H76Ebxizr*IUzVQ5(9h|COvRJ3Bd`*m`oMW~NJgt|hw*G5yiUU_ZxVyR;I|m-ce< zFaVQXjloJa?tftxijQ4}w%UT#FFy?JLCVBgNY#Xsd(Xo!*&WTaET>G4Mr+|E3~I9Q z;Km%1sk4fOiwtQtjfl0S-f?82o%5+UeXX-g{U5sSmdB}wFe z9fGcF3=twRI3pFIAzrX(WeATY^_*We7NmrtzN!zG4xNPuE!2kUK1}0%zG_$B{Qdq5 ztf{T5Lw!BHE$;5{^YbB@Lm)go1)GsovP=c>#l$~3Jq2S{Bdd8R(A71jnNeoKTV0tnO*b;1Ac^JVvsYm!Emvg1GCcZ^ z3$W>xKhW*e1{~26RaRP6t{j-igu>cz zUj8odatlOoXe@^H=h5EW4CfwN2!S(@;OC0k<~~IFX;?-^#lc&F?AiBV#l}fgs7h8X z7{G6~p2JH|P}vq$!%q{2$e<8Zld8;#C4aOFuO@FrPDCUu)P#id`+;D z^xDuN)qOI>r?qdK1Duqv7Z34xP%4+nV9&%uhYtWF$2ZZM=To z#C;rq;wo2YRGbs`o;wR4*HoN2vkN&Zo<+nMtx9b$rnwK}qrLTb`0>Y4f9NALbq&CW zlWdPM)*KZ5ofeJ&-j8}J(zIAPdYT*1W0fP0Zbs2eh9SzunXXPXpI5=SL)tbfN`KD? zL^t3m?NqCz0Y$&uYd=`~3>RZsAHbPG# za*dtklVs!1nJ1sKfWRo}P%4&fGPbv|#FPrH1$k&!**STzvXVVN)gF8oNEU7ym#s4` zNe#L6!o8x&t?G_K%B0anjbQ`tk4-%1d~S5&z3^jA#}R&K-9r+hE3N%J4rSu+D&6PE zkMFb8g>TFsQFcmrzy+g`VB)w@yH0@#E2*w^2sNDjIoh{h0wOddEU|H4|M;+ZH&+!n zDIT7*RYnyz>!U=B6UXB@koY zKjEu4r2qEN$7a>eJD7?j|}z2FcqsyP%QjeVLHZNhh21=rq5l0thi~|^!8rF z&sdD<%V#1k+Z#1yt!VBaMN(EMd|8QM`223X^G*SLsPHzDgLCy~gonTj8o3lHTXT>3TZUFjT--Ho21;P?zp=7BdZ%JVLBGlo6cKR?Wi)?mv!@6c+Pi+f`N zxQ7fWaYod&aRAphqNd%5#cMK=6mGzlSGK}?*1ZV#7IN@H>@-?T<{*TU5Zss*5BHQ9 zc$hnIl2%7f#CS|hW}}sL@dOg)u1EURAh>%``9=i7kEM>vdZMv>vzxwW4ywfRNY-xEO1& z<9Ib5_`wF8xp*0;kDtc;wT~grObg8`81bPahwiC7UhyQ4gS^d;Y5KAYZlK& z&B254na&ANLKx}eym`;Pkl;D~?xn0)j^?*EV}L)SQYOLJR*e%4IxNbjcVJXb?pGa3 z>IS4fCd>^+Wiuazq(FG9-4GYyh3s@Yw(U75-Df@>->9Y}&0n8ZOG+sNsie$&UsOcF zUtirq_E|1OHD{rsh~&qC-*41qIXZL45)ghv76TQOUxHuq+slP$M+pg^D|*eCv1A#o zpYd8`cPx)@@eY-zj-r^rswwl9BQAK{#s4k7oICEil$YAWcq0}67j4~DO;83#z}Nf6 zjhqfsIW6XTx7RK9`mV3K85iQ{s09tQ zCIRds?{l~ind^m1mw?*Z@4D>%IYRRuWf1q3JY(xk7N0_Ndi7}nFs~;O>czi*A{ibtm}s= zDgp6yA${>?=d8C5ff;lo38cjBG{(?&y!I->mp+CxR})Gq8Q>o_A#r&YywtbhXtC&! zPp0gQtW->(&2Q(lT_xq{H2ENN+IWoScJ{g9He-6^?<~ROjWh9C8@1zd8M=*fScc3{ zJCDJGbZ{}@dG_)R#F#jlw<}i?N-F627YR5%TPBio#~*<(S`uZ zBG^~`sr9zu9-KYgi8=SB-x54fy8j}4axxK0V91x&EQ7dkpdM~~#N1;O5fgEz)~pei zJ}knd`)0!RHXezIe&_9c3vFJLv0>rViA8ttIfjcL7sp zIbi0)*VaT85i?`zMw3~p3L6zKs62+PyUGxd9D(8k+wkG;gV3s@5arDz z`2TnX7u%f>8|;b?-h30sE)g0Z6^ibH2Atcw4YgK(xbz>#8=DFdI4Kq-``^Q{)A_Kn zjEt$L8zXW87Kl(h|G}Gh`=dhmC9)jQmOoyI*bN;Er5@X|4?YpzI9=5QQ^hH4-gXHdaq$FXsL)q_1@CR$go_RJh)qsH?cROZ zy6*tXM<^K2VF2GYgmS)@m-c>y{R@b@=1IzK$ljF9y%<#anw0Bky7@oZ$+;xL~wh*p4lGtB42;$K`z=V8_1g zXhSffJx8$Zzu!PnuZr;!H=KL_HEcUkjnSbo=7SEPq%jYkp(#-7dQe|8h{oDe*zwU; z)ac!j78i=XlGFJ0uMe_H#Sl(h*n@JS;F1EpDd)E-%L+K_wRrV+2a&UOAv}~OoOtgK z*m9_egyCU0w{sJA9^3_;CIU9b8v86Y1mSq1wz>&^L4h#$v|{^fZ{r**p~odBvkJT% zWk(O=?VY>PW%Ff0-3IL7_hV;IqPqMHPL_5fh0oW?cL*~-lZU{-P*gJ=!_1hX%r^uf zfqXu8e~2A>x1dVz0?*z7bPUTeSXzmW!9kokyr1`YKdS1Aaro$21Sh59(w{eDS8*Ba zJ~0SD6W;mlyJ)ca!N<<;Z)}H0crrmFN|YRZ7q4&1gL{}ew*PW7!k4T;a+nHxHot+7 z4xEP7KLP&sM!fsqn@~OKg}4wE4!tq{EXF2y;~<~qJ$#luV`I>Igees1ez>sZO&l!X zvz#2s+JOqRUOIt6l^?Wu{h0sM_poAmDE96zg0HA+=t3mzr5$*4%UKw#EUrt$WmDfd zSlptScQ`&N$p3IVMkg=BJ<|eFTUd_mf7l71tQZvU+>EpJCRka*MCtC0_R?aOFsZ=K zxA&mmJrv5`a=iE6>o`@~ib<0v!}%__Zf}M{6d?~cvN~y4wAbCueS93IPWUVe@x}_Q zqC!$&VgUA9a35y=^if1C-3SlsAiNg-kb(o+O6xf=`(fs<|BTq#Nr-#s5m;L4;JfJO znDOFL_-C)>a$mHZDVAPhyPSdJ|NTo$CM3G)LXkA6d(T{oROTQ|`QQHpmG%NU>a^0f zelwoN?7w{u@hewgr#|NIRhy!XJ~mxsP)GWHV$koFJ1M)p$=z*1WV&y6o) z<_pil!(|j*N=C8f`}d)3-(?JU zYY{eg83G3DF=SzKY8~tQgfYh{JQ%gP%#oUugoscNbk!=c?t5vta6Z#KHhVs z0s~C?jY*1yrLz`A&F*;OndRueQi@TR$;gQVDob0SZFI+jPt8Wz!AcDGjSz{}hBF1U z23!VVQhP(m{2o~dQHbGj2qO@p=Sng9kcgQHa&muK5$T(Z8H?hev@>+9BFvr1r)!?v zh}IMJ80oISm0m)7^=*9EoG{$)i)9=z+6Q7VH`*J`eS8KIP29$Y#83e~AX-v8L|{n^ zDqE^BtaFCH!hn;z@(I&-CqmMMDXGzfy4OJ&Iun_M!*}S(H5$qss@^{4QIWdMkLd)1 zeP}GHM`gQ#2(m5?ys?NP!qaNCz^WKT(Y`LEt;nWYGNA7AFgCul9CgR@nS?xqsmv2I z78F3v!8R>*3gQ|2@%LA8;y8?B`|{u)qeN$)3HlNvRzJHQ^~dTYn0%$t38wxg=C;`| zB8$ZX56y+XsT>E+9>M(ePa}?ijNy(pRFw5&u%RDIAHN@shpG|B@jycanN{xv)^o+I z4fkV+Ie`JZP7l`+)aSLqEhvG|`3U69kHK(#HR?J8uxx$+O7d#ZR}HLxYBkCZ)zN|j zJR(B*JTyQ?qeas9)ZJi!Yl+C*5SEA`eKANvwLASdn(=lqHqJ``1m5SLjqhO^K zdg1UO?t6A7^Y3aA;+KS+)l;E?7Uyt{2->r1WC`P_~RWHf!dN&IC;7eQ|IRp&B{W#vR35P z6OC@}C0a^BB(90*#y(uxlMh);Alm90n1NwN@Z=>38XCr^cPN6r@7zkhnF13z!yxW5N`zTd>FHydK$4avY_^hN9_F%BJ;8P;o-@L#XkcX zk3WI9Ss9Wd^Pxa9o_-X;S(D+Jm4mniIdBe1Mf^OP`+Q-1VmNb9hGWvBk7LrRdF+b{ zkt^?mU$D2NRBgIG6#nzyqpWZk>A(1Uq(43nHK+C<;)gFF{pU}@P_`3RCR3(9x&gj? zIklD`L{3eUu1S?V2g&n%QIS`H%>VcsCO@;kkSRwc_<(@3y zDTf=8X99+v6ckR`45O#38>1esblb=<)ZYay;mtBncX&^a;B06BO_#f9%9B9aHp<*B zu2T-7t7{Nrgxf1QF>vif- zUA@QC+ZK^OHy}Y^nKLWi*D{OAoLanjmMiE zhLK?w8P&j<$50VI?&PYLg2+(;aR?;R&V>VyO5s8%xhGVFcq>Nfso=||AWYg~7PdE$ zW#NG+C_9F!nKN*qAQwK-aYP;}IGFokQYf#V%|=+W3u8QLDs>F>;KGrMQok+k9`GA! z#DPn_RE!}|v43Iyv4l>GSdbm1hmN6VgauX=de-CP8!t@#Q5||adtg+k;o@OKe^(cV z=vGqFi()VsU^0y`7*1vldO+MgSgG7S2nmGwJJCvX;qg^EUMGF7F3wJf35r7yVc%v3 z&j*-Sr|-5RD{~pY*E6?^9v0yxp@LJ=Dt4iaoGByes@V^dahULJLbY9J?{Q%7t0_S- z^Q+WM$1qq-OlvT}%mGSC#bdRQS5=g4;{8@Dy=YY_pyquwo6Yd@3u0bi4b)WH;_^C~ z^Hs@-kIIGca^6Sb?@&yQKwyX)I*!#~#OlIHqZ?clp77!<-kFFzeRDMm^XdteSHLi8 zV7~}sznW_# zZICd*I?+m=2;%#vpfJfA@eo@8|30yc5_0IZxo_^ym>G?T*N)Fj#42f z;fFu}2fVO;1{$mDq++-ttwToZy|05QBrQ55rmlo+s1sT}3*3tOgOuGB=AOl;FT+zC zGCBFlgOSg_jqjJMD{~NiBQZ5&Dr%2!htVYpVXPvrCW zQzv-PudLlvfr(2~g#<(6KZ2oF3R>TVzWNplimt+sU4BAvOeUqNI@rWnk54pRf@*{= zT!%S-`!n?H-G#w^NT{3c+~48sE4w&bq(FJ>anZ>TM`bg7=0o(5M^SW!g>~z3;gPZ$Gk)+i;l(3F<0+B-Z+}2kRup1?`YU9tnG5IO2)+#C zvxhMb9$H#gsY_;~<;XEG4GF`YWrPApARsdq#-2hBuzb)-H8V_CnXi`)%}4mKuDHjE*4&$o*0v712K`_g z9>k#oClNV68a+rt@28O}I*tPwMo z%|OcZXizONi8K!BvBYb$xdq1}CD=%})hPtdnns0Ghth5*OrH@CT}K^`oGwGg(kvwK zJ}1tajhQLl=q3Y5NSGH!x=PW=+@5KxCrQWhVM48^tr5j^3(j1SiR5XK(lhEA84Pz{ z&N3OKcT>9{o=LQs%ar(<4b1`=k?LsmEwj;ZARr8EW^VrQnKor*qTMHpNJ*Qmk`iPIu*n%AGTd>*DO z&)_8SFg((yA!h;KPY)Rx3+hZ-GqtYvtl_AyEDZg2GiE8KqLk^ zXvqAl^!G%3hA-l?;}D%r7c2AqgpVd+P9m)u-s9;BNSmLA_V%+ddIvCJ zI6~^H8?PshiSl0I;fPKOLqc{0&YUVn+Om0=ci&2Q47Ni?i#Q@V1~KvD@j->VAJTI? zab$lfa>R2ygV!Qm0_!Xe_23ZQ*eT1iF^k?F&mpF#(4viEqP^Q_J<901ojyGtL+yN) z&wTPMC-GUHk?e(Dvfcy)iTI@q$%)RWt7~C$eF0eXwAvU@RE(p5Cw*4egp*v z@V#1$)VLTdeqW%0$$}i9jVN65Oj18h7xAH3={?~Dc^esRT*6!Jjl3y&xK=?YW{NYSA7jhP9&4u%< z=b^~|4G#R{o06+f%xUAl|0c2~wP5GV{{|N(f$E2yaW8$#HNPM`K`vb=+=i)^aPjqK zG9o$8UfT~Z>q)pxUXJq*u0RK8f0;ko2A}>vqRo9i5~ecIa1xmb-hKsUCSG=xHe<%m zAHl8_k7McXO=vrP8PTy$IQd#T7Cjw{qCGk!FD9pB_7(-77h8^QFE@IrZU}> zRL*>zkon5%2p&0&-T(3t?mxN%Wv{-1Nsn*D(1;7h&b|p-&U2it4MWp^8kcI4kr7pa z%JZBFg~pSj#~)|6lwjH-XB__NyHLesV##k_z=?ZTp|^uPc)Z51v<1=x{_&47%9*T~ zaeehLdJC%0w;*BW`0V*^uib89EaFlFrp?L%$JCoPyOHj?(qSs0u$yl47hPd9pr%2@ z+CrcwosXCIEtpIGq8<6}9DJywmbqC@n3WOr-MA>L0hO0}kUZno*K^y?vdxUTrWVA+ z#NGDzGD<7l%4BCZS25lA;>~WeFw|ori-zzF+-|2d>B;!OL)O{hIvdD{=y z?ce^}*zzlkf!(+_3Q{TgNcaE7>u+zVj4qrgT0~-od8;O)<>OB(w6CqnoZ#!DA@E1W zvX1X(001BWNkld5C8n@x$S3}W2TSyoxNj9 zC0*i-Q+`=Z#y$u)=$*D(#lQp!vT#e@ic0F17MSRa@Mk-by+EO`z{EhFoE=s2#Z(BI z4>Re7=r47mpV@9P(zkA*FI-?R>1O1~<*X$pv(xoM%SLMS{R(CXQBO>`9c_#i$QbvK zsBnZ&@oJOYmmGM-G0j)0XVh+Pt8WpuL$bfgoL;$&76ee8m2hBuPiN=(n}mz@2S)14qA6^n_- zQSo}M4CacfkQDqVkvaS>SE?D`9HU#3ZdCprzXS&U8B;Nf7z3B87&9>&#uYdheD&>X zx4=Gq$({LEFzgjh#)olN;HTGq`j>H_9aUX6WDp_uIeP2UJKpRUDXGryYryoiH-T=G z$vpo^BdL4r61+MpbUc=Ev%}qJdDDernEj)W5a&rAz#_WUT`*#FBT;VnjW++%m-SpJ zgH{oMq{#uK=xRq%!602tE(l2A@AHovj|?ct8L682Jvee(Oe%pNqG*bQE}X;8Ht{` zwi&6s#v6|zb#7c;h-IJN)=oBS!_{r6mn@@#h~krWb+^%Lu0dSy$Bjx=!ZKd7lZnb} zqM50@CYlJGPVD-LyvW-nDKD`Vzf*aAolVBTv6xbPC5^6(D|-*&M0F+RuXqGw-Ip2H zD1atqB_5s|kHecc;dD_y?s@DbDlkx4u$)G1H3Qt75RG)fC;I{1li^AB@2wb(nTrQj zPR2mtUUU8OC@9c zjy*Wn)QsgDpGUC0g!Svr6Uyw5ybsIJYgmUVi_@SjsDvNmnx*^qpi*zf+BM72T;4_= zL?v^-I$=>{K;NlFVp=NEcO}?;U@!ElG(7dhGPLJ@fL&)tu>J=R!(MU$`wGjDGG_$_ zKG=-rh}HPJA5X;|(muK6%!aP51P3n#5>56Jl+`D&^JpvPd~YLM+pgeD5fPMhji`zC za!Fi??=6`M8_{d$j&>t!zAsC948ba^#>LB(h?>3;Ybi&WQH!11-bY=J467f12!=B? zh+Uq7>Z3JqQ+49K10NtHXBIZhh(IF=lWij!Xkt8Zk&NV5EFp-Kxs%ti4K~+wSbGN% z95)HxxAMz=B@d6|Bn}DOxdg6LU?L~WHz|g$Hc^H76D4uyhj#4owM&3zi-p;monKW) zXkPn8hqBa1HyO^$2^a3i@&}(m;YU|c$b2B*%zN;N{}t#(AfL*;>1-<&JhKs}|F|DZ zUw#s2cQDVXts5^RL9vD+pu3YLBPuc0 zWx%>8p2CUE#V}HV(RM~4`TGL2Jt#R|j0ROVHvH&i!kU}lJ`f0J!vF?ImfKg?0Tm(n zQE5!=I8uu8!VbEvS%I9H|7wq5G+io#%HNmyEd)wdx6l>33R9K6g!UIhM}pR;pUWW! zULk@FCc2V?NL0*Rr<_HIjELv;xnk;qFs@({rr~t z@Yr)1$Uj&FbEh6*)_A(eyAYP*gt@CXB3RymimEQS5Ovqn(hGau2*yI@;;A_?DA;xu zY645zE>}T8(%M+{ErN<))wAO`k3#}?A%W`@n3V}+DUYs3c1j>D6Ry9zIIv@vuU`U! zjlOTdgl$wNGgy& zYvlgYaa@RKlk8`GFY=FFg3O1Bn*`^0sjV2HMX#o!GZD<<%LL$IEn)W~dU&vYSVM6g zg3FINdjF4i{>|{?j8C{rv=0kNx)_J3iu4@)rBwRj>kbb+qmHl>QnUg?hh}0AP z7ph%Oi%f1EAu_iQL!3~$DOh4=h7h2J z4j4yxHUm=voaud_Tc0j-1+UpcuY;L+apnO7yfi^Dv|q$Xzy>I|jg8Fq<8qd|?)c-7 zz}GK<+pwQ*IQ6nqaq-=QjY)NP`%mmIN*~Am_R!>2lm!H6b{)C6D$JQgn%>iSgeoDiDur93!({mpR#HhqLn(B zn2V!P45O)@%l(+kz;Yq8=Y?VCTU#*XO4jfwU-ZaSNSfk>7_tVqaDRbxq#h!YJOJKN zKIkE5eZn+9CMBn`@a4N`VmXlTWR`829D&RE`&mCK9I^4StS!QXYQn-}Q#}z&$b96a zXx1g7LJ3SETlhHD5?R?$ap3^U^-jnl96mWsfjv8mkh5wU?1QA}sqaAid_wSZf-y4O zEr~pOx-ZoTK}pH}tTh&lC{_|){on#7tTw7 zPuAf`UKP>^QMc-K*tc^J{N`qnwL*xFiKSiD*n8wMVcb)Zy)+1i4j-hv1zbE4dNL$5 z+5(B#OhH^)IHBlKgm6!Vr=gMzBn1e~PL}Fssr-|X7UPEIB9{1I{+gpXB=C)q0F{@W zd8PCN-m**AfjDGDQ7v0CA885x#5LUI;Ky^y2yl=SZ8K(O{7fJ>9PN%IAfrhjKq6yI zO1)e8iPAVH&zGaHxJClBeB0RQjf0(NA__K{1t`DjHqz6GGv&ir&XOkL>Fui~bBH{E z3h&Nf!e6}KHk2K!KrEH8%hlItY($IFOM}RmA9L4-AJw+v_?13hU#7$Ix@##qcKo6e zxG9K3Z>0CYMqnU;bOhkt3`T#Q3sH1PWY^mbOj@QZMGS&A0yF4^kX$Ka%(}lG5+y)a7<%MJ6sSOMXBEf?hfcf2y%#PY56E1+VbL{FR4nGm z%y^}cvG|X26w2uHWGIlHg6~aa{!74=Tb%KmxXOj~l9;pkwKTVYXsj4#f|Abfml(^$ zjjyB0k-9kbQzurq`A~U{C(C|n#U1=m`-EfV!tguT!?CGD0^d9dT&KWfw3bYkF`T)~ z*>6<|N^2Ss9G!*)x>CAnOhuA%NrId6S_EUTP)GtQ-`dXVyUbR1WguJdS9$wdSeevB zrqHXic9)nY#_Z$ zS!FG$kw`tm{E~7Gs&YBWOG|1o4P%aK=9!JIBnOd)MfQ^{p?lCLW@YX(`JNjxev++Rr( z69ZpgQWe?USSF#5NHP~RvW!LDXdtPCYSs=+FCS`E#2K)12ehBfGrhaqY&VFFuI6BOjvIi4~Uhq>fshMIzN39q;Ngy8%VJi=l}RWw{nJIy&sg zStL-8j^>cSU!Mf7Q(!^_awZomSUP-ib_xT@1#o4l@jxPVl7j)F-J+Ohqacy16KDKNl~N+u1_m&h zc@*Vk_3)jfL9ccUu|Ce|ZmC2`$1oy1EyyQ}`?^Khq>B!pcic6PE z5goRO3E8)h-RDV-v^OPs6<+x94{-F&cc7h>1`?Uyu-V8pXf-9^`JXI1hc0% zzl;4v9i$LjgmBLx6du_QefSK_O;18^e*q^g1#nMZj_=J+#Nl^0q1@tub@yyw`3oNm zHRa*G?Z?qjslrd@CE=sD-awN&6Hk6`4w_Ew#ECK)?s;wvs}7vSp^|D$nzs%~P8~RO z@-WM_r()xhMAV;Vu32k1{&VIt=q^2ty~pdYXw?i9vb>8WegSJUMdQ?_w^2Ky#N1hn zVdyd;b8!fYj<=DVb_@mrNj^As8d*zMkfizu8s&+2=%EGhc2+`LS;8_gN8lYl4YSgH zap1sC^bryH_*2gy#8r+CF}X`h;RI|9wFQk>{(sg%(V~JrIvcZ-M)9jRbJ6?w5SlBy zFzW6PZI2Fdt3FX+cB>H=K6)P)Timh!xqIMTcLwhsx=4ojP%L+MhPFN*J5P=xC`OB2 zZyhHo^~1>aY{Q;IL^mbIhsQP-(?A0r@$0Mg_XbhDvTE|B9yEe8wa}3|3)4B z$e8R!fQOUWfJ|b&vSnjX9j-zM`Ls}*hdKR&aPMZ)BxjEz;-V!B$1rL5r#Ci0d!m#B2dnx)eTB-jdd!Zi5YM0ts0%gD~s(Rc=b{CyqER3zh`^dJmt za`5uQCKOeZUB1PPNpqG%N$7WXV;2M%Vb#OWqhRM{6e=&nH)}0cb+R-C^O{nkypemT z0jr;U0VP`xpzdr5{3owP{8$?V8Sx#b}VFEm&@s;ATew^39?nrEb+qk%SeJ@$rXI{ zMwvS6S<|W&VQKz2cZ!MF-6lNw(u+9#?lE-JL*gDX39DBrP=B-?Yk%|{%J-Z>Ip52; zN%I}b>#iPl$4=ii30$YZMEqp9u@SPSCh1xPnGQkBu=R`7OzM%Vzxg437v2t=mPE?p zH|y_AIQj$!hxjK5|D|=KOr&fdk-oE%0Q|XJYRp*?&88b5`!xqaJ4tm}LyF*LsoA-F zjQ?)goM`5WQT#jFghl4z9|CK6GcK06k_2=vyzPCsRCt-Q|4hWY=rCaSfE!sBoI?Dm zJi1Wd*@u|a7`poyU;ILHF|!ch@6l+D#J%^YNhKY~s!3|G>*Z~yf(?$Gg?pc0Dk%(e zcP%01edr&Qu|xxvD(h?6Z7hLd9F-<5O1U@OnE&O>JTXD{WiSjf!Po#BOV5brq+qgf zUmpgCE%0GBv0u~TJ4!L=wW`FT|UhGvQTJP{K}au8m6m|bh#oN&wl@2#D|Pw z+du4+=*I+onjlpca&RR`r{VH>mKTYX%Daq`VO*;nU_Cot8*5();EuDaQYuRm5gd-T z&V2OsYoTK8vEA%X9J1g=wH z;+kZF8&GP*zqz>3{b!P@CQm3Q@hLz7A{H{S?6ZU9#PBATU%O6xmow)@06)g~l3m-b z1sdFmEoGo5+0v3yaPkRGaO(13nhD-IkvirEPnEM*cPS; zIyoqv@$gemAl7XMj#b&QWa@M#*ec*1IEX^hNySf%W$i2@lYB)USS(_v2V&3fe~*(b zGQ60zf=88M?%L_BQoJ9E;51|`n1bBRe@3-)1|DVZRj88|`!CcXYwk)6wiKbFp$oGX z-G|_@Ar^aNCD*J3CQ&Ql;~56$>T(DIuz;i}*5PtRH0!z5{qbFxTtktNoB_kWZ8%O# zCv({&2%Xl2!)J>zJ!d|=sTh>3Bj!Uc!yuOCn8qTmH6{}Rq!JuJI7?NWIeHGUOM(y* z5(X8kU%MJvv{56bd|>_?<65rbO<=hWmWvTNUI8q(;pOWF1sO6X(`{-Ui-f1Y8{aQl z(DpiP|MOcUq>jXs58Vf!;CQT9kcgAzU6{J`9>jTRv1#vN=6X#>LVzdSSpP~t!Wi?M zRP2A}020u@8Ad*Nu`O$l6=2d2KJoC@dDShn>&wEg;7 z6zA7pEq6l2MVCkD^hxMEl`APSF?0&Ip=d%0iSHANO)L}Ya6%yo1(x~GTM*E`6UYDb z;m7-l?e3FJi- zkKg1xFk?qOw(dH@>dcu~zb1!_6BARQySwf?-AmWljP6l)#3u=VfulJj;E=#qA%VY0 z9@r-xmqYFC#o2TevVVNPREI@Q($y|gB9{N{5*%3mEUVkjg>R?=<$rz?&QsPSG0T^V ztsP!7Luh5Ol52e~N{_Z6^V$0#DA$^HzDA~ZPr6OMoSC6emZHjRy>NTd+7N^PO`8}L z?_j-v_zP7$aYX6Y#E+YvdP5_F#H1%gpD(RXni zv!G(4h5AizF0?R3eCO+GnrOQ5zOIuy&g+nXLjrdtfeByXO?MW)dOKZHNsl~^s(*SJ zasTjtVcvfnLp8-vEPfbM*9W2c$}krE%g@nj%YeV(5DIJLnDsv^ar$R}!1TZWA$luc zWid=vNzI;%0A~Xl8TXnPXm5JrJ6IuHZMp$1Of0A-6r+*}ykg82b!0?rOhFW%aJ!9; zm4HzSwK9ts%k6R5Iik6RG?cbs zc!<^=3sn{sHDR!yb-l<`-cjGc{RmNE9Ivmt1(@&xh<+o7Or<-A7IKnGgt8c|hO2Q35qeQg!k_2D__ zM%gXt3HY)k?KqA@0uBi{B=FTp;C6_f-^3{+Sf_tpg`NXd|32D=sa^CUFVA6xp*<$JlfD#*aSTh zU%dmZw^FQkBq1B&6T-}OCEf@$x`)AZa|rdPj3ez###L1iqsZxTOM9u%6RJx&Vcl z*7S?h(r5Qie=3Qh@%%H=Z`783uDoEz67IoHALi1upBF$ ziP9SyMt{Er-dZKu!P5}s(~3?e<62aan40X0nyOCl(C}bs4Gmp-BedQI+sUS$mJLH? zDTZ}SEDoLo9|hsxBX)$w1Q5R7#^Q`*n2@Fqj!xGfzb z5QJiI6iw_P{s{-5P(%}-6U!$KD3)KlkN7>Y-^8|D^o5(~!|?DB)EXDERj@|VsE9w+ z;#__MR3YJH|Ii`tR33ER%#Wh0P;^>O3#_}j6FQ44+`TOD@KK|)>LT)M$UEr4q|(t^ zoTV}z8fE;9!8E0M41K-*L|8h(FUASgdAVpDbAd*q=D9=-Cmxh=^LEn!*(Y3KqI;1# z@=I&N(vlQEk7;L6Zj4qL17YwCOvL=zbC5{I-CdrKar3J=PdWc>B07-h~R6Z6|eeeNBh8PFBdUo+SVNqTCDOQsV3E?X@ zKvsJmt;|UgO>950kF?+hzbB4!?RM9G|9C%gb_UApBPD{sE`s=RT>|bxwo^_3PC2^)=3kHq;wUmPA>4IWoc&8aBNNj z z(h4n=t`>qqT;b~NK_$V#nW#S%E7lITw^27K;TaW-0KNdC% z^MAG$=YH^G=(Mb~%Vb!0mVSqo)Jaz*70fRJT_{whe_*hLLbMCF-h@`+_W&|JOehMO zuP?Wx8;<+PWWEUEda+J4@gaExrSF1hmpmd|DAr4dT791?Iyz#)O}ngnjC zz&IkZ1U%zQ?Tu*ZIfks?J&lxSe}%9NLe>3(QMq|LQl40gyk8M6|93w?!=7qH%n1g~ z9aR1Mzms`QP=yBL($D{dsek$nOod0`l|C6Y#~KislZ6s;{S68QMr31XFwgrP zOk@rV3;RNe%$=QG%#&jv&(Rzba7e%*f$x|EK1YFxs}%@5Cc~=fj-pE{`ul64ys#5P z23jKSBj{{v8ADRl-LtI)<;St7P3a;1uji$S^xDQS1Ys=C>|nt-(n_nffMgiaxLON@&C0= zz}SUlBP=_qnCG=C|3cqI|9xpu3FTE-SV)pu=c^XpxP>VCB&@M9rZR{&aXq4sQhpsd z@g$3o$5AK+aqL87Qrg_{#~}fS1RN6hPDtQ$M>d(-1Hto_W7^aAqy2*qQUA_4SjtFFChNDIcV9s6CL{tF*?dvOh-3b@+u)CYgD}hcP7BHwmrebwr$(CZR3fJ ziEZ1qZQHh;Ol&*f?0wF8*ZTfJcXfBI!c~2DRQ1AL1s|n*UfbniUWskK>6Hl+#orx0 z)Tt#UjLwKzQYFMNvCE9;P?2u?7wL#&$C}{&3CJ(O!Y!^AL3bo@QIgIzp1x|jCqhWT zpg6;hzc?x)0pz$_@PZoEMPVGOQjIeqL-t$xp!bSOBK2Dl6kPou3jj7lqwl=*e6K^N z(1;=_?GBEd|0IKh=2b)D{I`CH&+@npws~pq@ourqxE#7(4(F!wm3%9N$WUw839I8g z&hr>pD~!k4@aN;-XEdskoE>4`42;@rQU>FkI%T#*AT>}O*HAhf`hIvIhUB@Kc4p$r z7KAal+#%4xS)g^Wf1U>o-n}4ta)u?v$vFm!ckD*lzVTe^ie2p9Ox5QUkgp7cNoR@7XfTz zN9Z&_#-I-Qix!sSV*z)Xih<7pASyZVY4T@pW zaz;v6c6#g|Vhs_;bRrGU_coZa3ZGntxCQ9xXrPH)#|NA(`kiwzBTs1#R{V*h6Co9( z!E(b2nUi*#Ke;B$+`i;{Y5%#rPTbPn-RAiKBwj{mSK&(2RkV<3XRD%c0|lIR zyTY7L{aR#r>e+<{m6alrs83HgX(R+@ey}=u$-MD8$$IIk<&ycQ{^*VA&Cq=O@QyHF zVW2q28IMVV0F@9gJb173YsaL6#FC!0oRPF8Ua?O(lCX&-wASQdEFqELB+b08V^`5&*0tzRyG9>4^c*>SCgb1-S z0B(&%vIV4Qkk>Qt%iLNE89IbSxss6gN*bdlMG1$sIoXt~zt zy!Jknh(aFSpKCXG<{F!CuxXq2DQu3HM)o%aNZSdz&h1WcxT&jvfwsb431^(gM zf(pL0ainzQde2%Y^ZV1P>@D*~q4KnX*9&mi`4sSrvdh&J1w=PdApv(6 zpfIqw7_OL$wE3^p-+nY=e?l>F-YQUkx<4dWBfK9EagKq7A?WbLc66#XzqaD@ORIg4x&OLWCF25j&Pn=5(7E}gu)>y_n74&O*~{L|9F((|b*>R#X25%^ z8rp1Vl#c!=Wn*rEIr_lnkBY9TN0PTy%q2#WC9=*^uuy{e6f`j@e;>S}tdXzu8v@vG`<9T8f$7tVFnR`gte61s@S zepYjj7)~aLh>8vLB3n(Qmiuix`vMV;rbb`D!-8)%#M3|Y}eSRuaS2ujai(A#DJU}{nPq*`Vo{)ru=s;-TF7j19D?X|_&M|J_5c=HR zoAdd2vIxQ~8Fpx0m2`~8UgARoJ+*65oi?l1pb4Eq649c9+0p)|hv)2_$a#V(8g54C zos7v&;!R~lzIfBMQBRC;N&&QFOKMBM&x*jq8P=k`A9K?AwfpDM*C@PPHJUGwCqiqe z0avDxNtj5HKA(Q_? zxF4kfV~7 zb)WxpmsNs2gFDWFu^36s{_;t`B+C=eLHb;l7XsTnB zssC_l)on<#J#ScApF(~f6d=rqhP*&mF!09?wpc9`=DSF20{FkztP!oP1_aqC&cP9G zMB{X|u2dpJ2r>f!x!fMqDB&n;JmdE;ALtnkxjqmB0+*`P@dxPZfeTE0Pb8u>q5+n) z1%pDFqRfg2_5CO4IRl{|gtbddTqPBTR2;ryFWZ^2rRbb+_zs;Ss*W%Jc2(kz{OtxP zX06UIj(@*3)-UefBCsXZq@Iu|h1Ab6jgX=5(@+U;aZ-kABuX={#~s!!>_CzsAlt`A z6A>)tG4O-uv>Q?;ry5QM2c8ZsNoW$7_$U45i$q(S^M^dCW8e&K-6c%Q>D_%9qciU~ zHrP}Q@d`ylp00Mgu4Zd!pNv!Q!Hius*$4l*g#)yMi41t~JS~GO#FzKb%F$qwXJtJl z{`D7}Lg-CXSAxh?1bSJb`Hbh74|4z=L&(jvAafUOMiXLa%XRxN_=D|!EfkwR2kh$fin0dsrpzI+1Uha1MDu4Lj9oCrm!{T6MnjZ?X zA$P-cF1Q5 zYoFj$z$19|&F)Ub5%CIjg>ICTdy0a+vyhU7j364?GY*GqXWts>nGuHHLXkT>lOyV$ z=IRLrb?Za>^o*3*IIux98>b7!InYceZm}_iNMuBa3>uHAgfRRgA~gr(-BH1HOqY2F z4rb;OCgvaNjI3nYJYt@Oe&)!IDv(ZXZg0IXtna7&;;hWPXRHH;Hw?Z0WZ`N)i2t0LYvhM6yMTZW4~p zC)F|HZ$lZm7D9S|@cD;cW<73SLEc2>b>T<6jav{$r4>M=<4eRvH94~)Fa}h#T-NR} zRR1z%t3_F>b_7i!2PDrxxvVNhGck3_gm{r-TO>kED;_aYVH_1|q^lys$=OB&!el2c z+Z-q2WDx=c?jYyJc$wX{rAm-QyQwFds^riJZB&q_{%Yq%&*aq?qZ$^7mTF^5j^sve zby+X@UQ^<<*+HkEhaz^`wr=w}6_+DR{_ky#|IKD^07=m-#zBLJ!^a+A%jDSQSP;&d z%AsiEgpsKkhh-T&cPR0Kz%?j6W}mL8*@*u0RQrtr&!INY*FmzJ&Nq+gJryb{TbBK$ z!zi~0WddUZYsM&ti3Ux$dsJ;gD8r$|B?YAh1t*xS1lMYY1q6%>kVIAcgib>i35C3; zX|N?%N5Imf8w@5MtfpjIM3*nHafBS~ z#+AT`xEm9OC*oR`rl4R+ZgeHoZT=dYFFl%1Lr3d(W%eIDE=*;h`7kP4K_Zb0Ng%xZO&=a>~j}WLD6}s7TyQntsT9-FNKc8FXi5G zLY$V<-GukPwMbL?ZJ2Iq7~Kv$#s|HI2k~N*(hRTIegg!|-q!Px>eq<|i03 z1Lug8a6fLLC_Of`Y1jtLwNQ-8#2uFPmmH@6xV2~b{pRAwXR9U%3BPDdBfaT;#1- zNS0!P`8O)U`|`4O^1Q)Bti2a)vHU`!W%;oS@yV^lPn5aAiaASEL7Ce0aNl%{fxW7w zP22jF@@6qj+k*T z4hv#(;KtevXYwWh$o^f@7zyE^wy{;AMur&1m_25nRr4&!d6-Ats z8K|Yqy&H+88|Vq1uK(J`kkL@Eksq9I#oj{?>s?koJuON(=DDSxK3EGURF@Gqgh< z*Qd;M%(sIwH39v3{lN>a7z<8s@p1bSq?rPRBt*}O_E>3MG0zdnkcH5W2-g;MM`5(^ z&G3D!nogG?qoJWQa4$fYy#fi-ww`4@FD zfaT!ehIZycP6PNtpKmlcMM!)UhUdEt&n;W4fT#Dp5q(9WJ8G|iorIrxIat5(h3EHv z){R4(ous17bg?XdYyMDi+ISFkBooPXUU8tMNj@6VAv2l z_V)cTckA7p)xZ`dG^`e{;8(pxqIbL-K*J%zH}-^LWj`Ff$j=M@(PG4~8~yXN`va7| z%pE)i-Hw~Al+H5p5J9SWl7&4SuOE}=?1Xm39e%dX!8CSxQ(6^+z^{uxUnWrQ=pbq< z!5H9=Fl$3wjIC?Z3EWH1n9n-85>r`wcV149r(JTrp@}g;$>n76V~8Y0-lmXg*B#b~ z-bHcHjl7ESm-D$x+MA^%EGUi5j`J0{%l(sOCc7i7p(9(#YWSVADnz|_*pNdYoggO_ zpqaxgU8<3dHPG36D(U^iYl z8pHWveR_U=rGK&oZIuwiR7{@D$UrN^`Z=Mc>l;YTIem;_f^OUF*)|6|gmN}QgoA`v z+9^e7QmO^wsaYof27nAKM#X`# zfN&tBJucdYG5!iQ!=@9ooE#})e#J-Y;+){+f%A3pv5tRn{3$B8A|n{qXBHnhVee-1 zL0zk^^FoEn0O)EFo%s_j3vGWqpOR`#Lwi6BXS8~W_=9uupVz%b+!D0&+K|8ay0nXu-gw|Mp275^g%)LW~*WyVK-qR#=U-+}8= znDuhD%GTw4j{VKdz#(B2B3M*fs;n8PQ)LZ_^q?nl;Gj!9j4*_O#0hrt=oYoh544c^ zRL{~70E?>;pdYk<4e{*j4o<~^_$N1QctQz3gqIN}X4Yu^f>1&z`1x7TS?`o|Og;v$ z72l&b>PtoOQBjL{0OjDo5ds~~m5^9m9+#S*40|IUFnD(sNIOQ=kl#Ex8}1HFTgW#> zLvxqe8ub8cdn)nG^_Tb$N-TTg%uX%y3Bz8_eo+rpbynCw5&TuPEXL6wzy;91xEd7M zJ$PG154c7qLLiWPL!wx^p9}#+Uwb)@3{F59`_$3m+5Jr>YiR5MagZS@y_gT}cyU zHxy#`b3s1;zA?$M^v=h13@Edwx*LJ_4NCl?rl6QKJ8XxcwQC*d;Y2Rgd&Se^XAB3n z<#vDn{dxMv9Maed-4q_K9dzfWe1Iv zZFeZ%>y}FM>A>@N#3qx?6Q+*~ZDgeiYWIDK3*&T`oP9l7>vKyp10&uhpj^;99=Y)W zUB|)@G`>#pK8riDNj_sFcqZcBf?1iP`T2^UJ6Qfqs4*e6Z}&y&b9+fxRi{fh=MG$p z&lM0j8k5&~h%ysRuIPS-CGYezK_aRi=$Q4nE)M}WAt|@AJI%4+9mV)>b%=D~~={?tSAMA+n5e#v3WGAv=X; zCtiC-)ARa^lJW?bg!Bg|>uQkyYa4zH##r>ivvzMTSQCKG&FFF@nt+2ddP>52j#Uz` zXD)UKeS#PUS~sDFA-`#{af2&%2?vw&!5KT5GjH=(!}@AKXDRGJ2^vhUiFoMurDrYw zcb(A{7u!Qs}@+9TTxtW17L(5{*O8=juK>o3e8ZF#%{$+knT-_b%gThVN3S8CqL^S*Oh*xiiG#>ShI?=NRbqrVV`2v0< zMa%O2<_VbpWn>L~@B9hH?{fh%MT=4QvQHIM3U*tV+e3y+9(#03JgPS`yKCNGK@1)Y zqov0C;C8Z}YJd4C3iyk1a73@yACDJsHzgOOHEK}KqJVtMiPOOWPTtyTZsc}l_l?;2 zDfh~yHyCO6+^3@kQ|kZl02{^qPkH6hWg9(J!QGdzS3~(!53phH2>g|l$&QrVRz49E z(&#-#?VNWw^h?ptQe#gUK%ItDH0jUzds9ImSYRPKxiEqWx3QF0wUo@gP? zfoQj^f8hY?laRM%61^rV`d044a6)MiSA~FG*uS{^SNb!qj%-8hB^ps3j2w<;xN3txAg?a& zo)$ZbLN&iri??iBJE(`**zJAx2ZOp)4B-|g-+`mA)<1dE5i&l96W!i+a( zD?O&=7?B1p{dW52g7LA(JtvCFyR8ky2>01)E@DrnC|VWI*_&Yy4TyOCS^93uxY_!g z%<#?{$@kW-$NzQ@DqN{@2{l`Yn2$DCyMLMP6#mh(>h#sK+jaf`klKu z+EUxiWNg9T(OM(YRiN2djwT?|=JgyQO7%O!Y+UygBH(JrvOBTI>gjQcaX-7yGv-rw z<6p}!sEH^BaMR!?hOL$Pjo1A>Ud&`|yGAv0htd{VBsOzJs|RP^s2JwyVv~vo@sk*T z;b-!5e$_yn1aj&Vo16qoVy;jTmxzO`>8VGA&4#w~ zu`juBahnE!osmdcR>nzd7dD>>Nu@{yMNt)aNojO*g!735vu*Igl9Pd-j{8~ao zF-_batr1!V(HHuLl0@i=I#-jvU9Lqbyb?k8LOG?~z82xn4KGHeKkxm71<1x2lIHt0 z9ue|rB!t&naH?WlYU~mDHl#XTWTiTaiD-l#J5-p!iDkn}8uLZ8OWZoucN{_YCCG+O zaMJSr2yUG)896UO&&C1me!_puzf~^gne#xo92p)x{<^9M0u=-ONXA zdu#a`pNp0UlQ#Ip$2$aBgH6rK^wkX8)HdD0c1#Nnf78GgxLGVwCZ`}E;+k)tIio5 zqZZ!IC9X&ph8qD=^@-s=IMF9u^)zUV6GWG#U|Lqvv8M}zN5PHe7k|;yMP8|8a4U`g zGW#O5@@4so?GE|%kRUps;h|bfsvv@d$->2!=cUPu7F?73QAyq9_Q?&R*;_>pnAW0VJt;8} zmr#7rR5|dAe+bF6+-cwo$5`q7Ri~z>7cmhqr&Mw?UK%c59inKc3|YVtA)NZhJ1hfU zL|i1rC`X!3sxmFGFs*i`ii(DlX%NGVH5HPz>6*vLUvZBDA%64T=*s^e3qYENLpSjW zI4T?(PD(Tao}Ru+(C*^C^D#xR<6*bL= z^KLX_V3-T0oaV8XW4|&2I*-?vLg*3i~OHVnGi*<;D00gE4dQBX}Dvtfy)h*IQvzuFI2 zDfeq#4{U`qPT)DzAYYb}=qNbaDqxMw+1G&k(8*2d%st<>5$~9kY`FP&>7!u^2rF}s zq{XC2s*B0=YoKc;kK{M4?@=ucPEARgxIn%@a}CjD8Ai-oFA`zgIr-oZ218%nGFFox zGUv5m?2Rql^Pv~SEr=TpX;^9*>aihRkk${RCFv&av_b#0n?f;;#>YT5Xk?vT^&bSF z6Y||62ZER%PFUrfk4g)|YjKMq{7r3b>_$I?_GuWVH#Xggwy5Fi^cdYco*)r`D!c0^ ze3WN^GFCauP8;IbwKJpOLoP8VT8zD(!|4Fu+PYyv1LlKqNM>NOY8?w>OmrkLYFtsYVgnhj6`pF)U&V#a>a;4-%o;1$^~EWP z^w4Npg?R3uV8!mE49F%yJ_giG(~>N$Gy8q1aD9T?bqUj`Mc{=_42{)(h+{)jBvD;8 z8yQSB@0UC=kYb%6%gby!*2M^CEw~g@lK@^(NZwup?d!@RfEm6utLj=qAk-}MAp{of zT1Rt6%-j$QjTNMbr6M3cr9&bsi5KsE z#iNY{Lq|a0fN1b?vrlv;WewNw-kqT8Olo)9-xQT}A%mJx8xuU^a07T?e3hbA;xG=1 z3A4l7DO~e|=s|@9*e)%RZs45=1;lHr>iw66sG7fBdPccq_2Af+JLYz|1MagoG15)$ zajGabRs6^V@kIz&t_}8oFahz;)sm4YAyE z8`|QShPv!W0cE|lc=oP`B8B#0YNjNp0}tv#E)b!qSxW-8kf17<5y5OaJ-}&{JCHM`w%DW zySdO3B%bRI`u1jFevLWQg4?O6bA2>GhA*n=r~^1QJ(;@hX zb}#ldnAr3L$M;}q&Rli-x+TF;7S&S?OqYon*yzLaxfEEJ$U)?*4a-!fMSuO!@-EwD zMuV=23_+cqT|Yd>Up;gvZv##Z%FbfT3Y_@0dgH^No}E2?aP(1k*Dr5uV_}yKtvzXj zY#F{=+(TTW#ea#n0^OX-hJatRioRKYIzwcTMa`{f-nA0q66r&L?P^;=ik7D zJ(7}iu#qASxot!Xpg$$?T{U98shK37D8H#~;c!3$LJJDTD1h2weum%|ov-ZO_`gE> z-i#JO$n(qYsD^;Q?#D}i$iqNc%_Q?yV4`l|7=8698dvU8 z+XnDWk1Ikb9B$C!{!u_DsEJAQ*ddV|U<0&(b4r4F%33v2a@Omp-)uTq^`enu<;)`aGQ>GK(Y1Vv!yRhB606jc@YaU7 zfGF|VxfOboXOw0SAM=p%0&>bAkEK{ z;S?^Vk9ulx7EU1K^bxJPCu_qVdYFK;jHu=!H zU^6ciG@HOM!s~Q}lhH=z(YYLc@V7^`kS}L#={6SOjo=h!ta-srlwICSt&9k zbj64^_SYFnZzT#P>g&)Nz^c@xB$DVLXD%tHpoGjY&!!%!KEV;+@X*gI?;M@O`b#lO z|04Qss;aLKxLfJ+Rf(6fu4!zb8Pj7xC%CNC*CD;?Q>)yCpey$u6m=X&CQlhG^-%|I zVnH|H5$XR699WhE#L0D`J$zjGF=9+21;@l+UFRm5pWRB%;j@!9K}4bZGg05j(ge-o z(pcN1`_jMmhZ_Ljx))s%S+!r^(uCmG`+?GrfoMJ6yth`1Ww`Oh(er5!nVt*7$ORpyzW1JXK{=UQ$M}hdluOb77`2z8+f3s~6p>=LRWFMcwlXt`Euu zw|}+RSmt>w%>a|w>m(6u=k-xJR6~b2@H2}ckz{JPHul_Ua=zs7AH>2Bt&J>X#fFeV;i&kV>+D1I}XTLPYCqPXXHs`#;(=$M!j1w!SP=5(U+>FQWqkQwsqrlcX$Y zC!mbBmM$^;)=gP(@lp3gVX;teZUG#2$5+sK6Z9CG!$|#3UUr8` z=D9T}!c_jrBUP3hyr)FQT{HhX9NqT~dVP`!`H(9_GWSJ1-b37*3D)q@PSs9hx(iv? z8@i3#IsFgn(~Js+1!;k8JZ$erZ&<({1dl@j4mq!gGUXa}YM^V+3-u}WRT`dyFe~|J z%PhZSIWFp!tc`V8_24%aDOmXRL!%-4kk0$uo!lz~%xx5`u(Twu)ioS2P=kgYV5!B@ zUyknn)^Ny#l%sCkzpew1o5@+EgKmFF8@5jMbnO@H<+`TdO1VQ4DjIWeHr9VBmqN5Q zMTF3xilcy^!RRS$uidok2ypxNPXs*gOT#5Iaz@GmEGGCcuoDbrW;pVH9f(UoBjtuL zj_V}^0$BaI*s~l_qN_3v8L?0cHku2!t#W_EAc()oqJbC}e?i5?KF8-x007Qn)b7wP zRAg&57Gzqs1@-_)qOv?DlNR<80TLjefKS4Lt92TMy+rr1-&p@)#;D(1J z)F)O@E5#|HCuMB9F z3hHIfz^th@hGvnS2gND+QFLj}M;8)u$)``#r$>dic`-UU1lu?X*Wox##ke3)$v|@y z8!G6)&w~*{*0_!7i8?0J!e!r3LG`GMAvAQ_R|@=h7elY-f3K|iYO?SLs%1;fGwcP{6Wg0D@CZtmVrId5Kf9EA&y5GH~@e(K!?l%xJ$^@t%m;L4u_6LMnfEtm^FgeP6|V>7lL<} z{39HKP@IgS4JM{sfId1(Hi5w7gKs7Z?#NEMF2fOV`^aRX^;iT!#HC;~r(kR-hk!qN z1`+-%s<@DXAKt+g%Ol-Vg>oHS2t=77*k!TqEwPF)o{^@pbVzC(rTM6vj+5AdSmPv} zd}vihqb=YgGgH@Z#=u{%Qx0Fa*l*aqgkaH-E&gBDwcRBb>pRDZ6l3HiWJuul7vin6O*X4jQa-P9jl)4gS z6Kfm780cZvD0rm(lhW< zrsJIzQAKPT#gou~(GxLf>%BezlKQ%a#t2_BR87nwl1U=L;&1IIfT2r-c4OVR*hYIh zX5K$738OP_aWK!2H5IOImj2VQ482Rzi88pogF9u06a*O|u;8>1%L#uxozt|CK`k&@ zuaG1qsx_TU;&GhebYt|mMhj$T6fczX87?QT&UZ{g_w}stZ!&QoFfIBVfA#|6L5PoN zw7@XLnsR26a;olt;9wF{Uc}R^DwE)pap5%Clqg%bvCUM$BGV2=zkNt1pgISo!6p4U zU%2W(s-q*7{(>w5n-#@p!=pyBR+!)XyN-7_OHANrCTooHp~>mFkyCGMA_*SP`C(vt ztlA~Tq>S6!A$O<^F>O$aB(Vu6HemZrzc1I+#zW>=K#$EBSvUlNW?8H^w4mSa31aZ@ zMg#Rd{EX5PR8DZ)squHpWo!%qlk<~s8*VWE$CV%Ry2)lB=5Bb|a zk;ZB@TcXDZj`}p)o*Nca{OEl<_f~WF?cjaC;OTz8juw5r-dvAV4ljI_zAk#{f5=8x z$aDJNF^_E49nWxSd+dkrij`4s7?5`FZv7{BolEx%NJ(3h<6{`e}u+#r(QK)0m6l=$2%HK;p zTOgK7RHQbC$ratSTy^HoqjQ3ad_};fdS;1iTAZdGWVN-|W)%n(tV=+7S}Y(dE~fB$ zQWEy@(Q~mlWGrOLtj<(t)O)MLb;Q65cpE^sAXYh6WGCqm`5m@fFjLI5i;f=8=13c5 zSri=>fV2l%=sLKR6Vecf<6YSOZ&11myy|RlpdwPME>TqAGbk)`tbN{+kk+D80V^qY ziZ)|`dry}YBEenLe|h$AL;^c>%@@ncJ0bU=e)wca0V34NJq&{q7OUEHnsPz2SdmaG zYH~Aj_l^I~H@rLZS!Z|k-;f`$IbjTajPuh|I4=Z!>k0~;78q!HlrZM#fCxAp5}~GQ zD~MW;EgFPuMBMS;)V}TI_xvw=^#55PCA3!vOkx0Kd**JpFRD(N_#y;t2CdEzpxC5%}ynyDzh^t^>;;Gzn zb;SIgErgs{XPJA^`%hXSVWIWnGeep9mdLEeB1EduZzM&#OtD24?xi;e$ai^(9*&#; zhgMCZwe^4)bIGt2LxmEK$(uNX6}(8jLhbXgq+&@FTGK_}iNY=dl+>aSMbn1zTFvle z4=%^)9Cs8;tKvkT?tG%?l?n<=eo-?cr=@3-e(<o%NGNf=paPQ2#PzdMLA2A&v9y{2~D9NS|8__b&ejv<=siBSIROca=8?h}w8ngO(22i zZL7;`oUmrmofOlAOSh^TQsDEc1W^1s zkjZGir=ar6@&#-YSvfk_0>7#mfLD-~q+w5%b;gEz z%V4NXm9yvt)*plLmgzb4uX5zX6h(Y9Y5r+vg}ALEBNQZmEEp{Xg|iUqEwY(msZbfF zRs^;dGmA!!nKE^u6fyDKFG(pI_u#Ub*#Z?%&DG!7;K>HYgtq!g!&mBU-LRbP?n^I* z6%R_556C)q%lO5}$QEO);1oXSh_}nv3U&Tf+${AD6Yjb;155hkUkDtH9Ay$` zEEf00{TPZ);I5}VH)|_~tR$z-qWyUz!^!!fsCtjTa~ z5oJi8kuHaZ92T<+grwCj!*#SQj~>ctDjU*%hE{$CEw`jkf4t8zlej(5LmG^IfCZP z(CLKcp(EIhe-bfYPf|M#^3+m8+8Z(6Ani;bn)IJ)EH%(2A*8>Bm8ap_#?}bVZJuoa zK6%2ln>nMV22vq)`|U9vB1CIA?dqY;l8E7DRO(k7~Mt>j49sHPIMGM%J}vN~pa77>MX66Eh{Zo{(8*zfDIBBace|(_7c-o67ms z{}_Ca-3o~D268KS&nLNYH>E!Q(GClJzu@WY5bb_73sW?Rm6J16T@%DOJhYh(Gb1(& z@v6Uyy1u6IK-da@e~Uyqy78MyqG0nIkE!AzFWYyu!38)RQw9!Zk2)qaPWovtGc=JI z;~<9AoNNCs_leN9s7+J-d+U?c_xbA2LyM$M`hUtmFCo80#AIRFE$)xkGf>Q)C8q*` zlgKPT23#TV^OQm)9OXU-iydUa$=K`>cwg*#zM@p_k>(dOLX((6FE)4QdW|}@9rTD& z*%=ufG~unUcvi?v?>cWY4(RVXLDkU{dvA+U^^nnf_=;v9VxLx5e$Z}ed&zvzYxUn+ z-DD+l>?sN0T;I|To|?TOz&pP`M!V_x+>M1VXDyqhEQY?n{i&OpL0k0`D5QnX+=ne! z-i8n=6FC-3CDEXhFI^?>MMM@9c|fI#--%ZVZJgiuA)T|iVr*ZKm>Me;qzxiua{P8j z%Tg=0{_ohg+@TTZ^O*9=iZJ|9dr^WZ$Ny5Dc#)yqBfWvj2hjJQ=yrK=VWX)J@!%3= z*u{MMPab_1y5O)=sc(=CP(@Lmy|1cW2@*;X`}yKNOo1NI--NMESrJZqRQTe52pvEZeRfOdZ&dE5@%1Ji_^>tjG z7~0fMZY9o-_}xtxT|)FY@crFoBRSnqr`-JE>o6g!N8GKQGS)=u4bcR!%7u7o(yjf+ z`8<uJ3=-1VdWpM=Sp~QTS))Y&3)>pNk@R2Srfhg-FJQ;#^k1OY-QZy?YJ`Z=%#$ zUt;X`Xbu^(Q=)Vlj^2pE180}_Ez5WBk2eG;h1C2^GI#fOZzMDVic-3D((??Bak_^l z+5?$2eP!SMDU7N5l$-evAHb{(AzyFt{*x%-mq7t`2D`W)v=gM7sPm)~pmOjd9%($SUg%ckR1J_&lnZl(Z=^ z&+2((3f`>&NU|_N_Iz%^Iy$l1v%(ikE1LMfxBpr4AD54u7fzt+g01DjI2*1xgEdE$ z>Ba4V`Z~d$JMyI_l`v!*ZE`3ELqMW~CMLF)CO zR9?veR2jwu>CV|7+kpt9WYO*oD%Bl+)?%O>MErj&0K#I3;JNp>0V!?rcwD$lpkh*U z-B8#>H;FL>HSuI9U{~pnJE}f!W^#23SKrz1+okw5aFamZXl5~!N z)d1TBG-T2*z}DJY6j;<`-S5E=YhzlfImdYdG2-@b?3lDgP7VqRa(TXVf+otj=(W(2 z&HjO}?S^ums?^jg3;9OSJUPzeQ!a)n+0;l`AZ3A+1%A^O*f0+yR^sV;3o0uL;0kFd z*eJ&m$z}6%C>?*M3GI{Q4J2`{pfI|VLqt6`7WWL^Zm6@U-DS>Tn5p7K8iz824a*cv z92lQNX>~CLDCJO-qfnm~#iT!h5+}tgV|t9u`cPEsq^hnQ!MGYWqXLsl0a&a$0wChB z78hY@cob<43jq`c=DgR8 zKSQBSGxD+xST@99qT`Bn4M1x*LB$m48sq&Zw^D*C!Fg3BbjI_js49Ray391;C>5p) zVKbQ}hbnXBBH#}rm~KN>hMJNpakefLK&@lq@_JrOX228w`r*qp&8^QoaOou1Kq=q) zx7(qhYO#_J!=HbvoQ>N$qEb^1?33Tg)D|fVq%3f|EpSZ-CTjmn!6bazS-kk;VPx3z zu+5bI~lM!h3<4bCa{E)Kx`CX+_gZ*fQk#RRY2WEDb(YiLVrmT*`=b^Ue{9}A5# z0SwtN*yXmr9^!li0#f?nK2=5=wrq8-G3F~RsH?YK-mmyfl1?tSY7=BUUvchiL8msE zaPmA^u?o4)xDsu7cSQd!`kNA^h$L(e_jLDzN3PDxZ%RUsI;1Yy5dtak^`LrbQ7lZmNIvV90d z;?0iH(J{=-OyBJ0sqIo0NLe6dfqT{h*K}Z_dCX|g<5BV-3XLn_&?2N>5-|2F*Ywe- z(9t50gLNvA>bo;ThK`Po%Y9%UK8Bd!rReJx4=?RUieNr`guDBG8lLM7Nm< znjm~T!5%CTk*Qhu_YFM9U+bUSY5t?QqwI_z0?<-_6>U|9| z^;QB4b+qD4{W0-JenWPG(=m!ZG?5pKeiBl{k6y+Nzap;p%AXtFF!jNd1yUABS>U(C z0vkFo5V6;HA&5QS-hueU5Po^E4}bQhT)g?x1z5Li!`^BG8VM z1ZQ+&ayE$E(oM+FhS1hINXUFCiVLiCP;rcQUtq757h}_Y>?ZWRli&<%RxwQR1vK}% zvGx8s%nbA+P3uB+b&gbPx)axUJNGF%*JX_4QX^%7lm${2_^euBLu5f3Q*$dTlX#0! z*z+fcu%+IG#<$PG%jl-1u^A2Ly08#4VpFjNQTd&nEai-l+Sq^QRhi%)YDL$CA9Lf) zXzm|n3zP|cr_R7jcztWjSeV(zT62W;lj=%Q-V#z4ZlFcH- z*OsSx(LC&dn$YvrIK?T0%cNsUqOrLJ9{)088Z`z_pT-<}t-9OK!0nF_NOENo_1=3l z2 zp<{T4TwC)<5JV9UhTzQ0Ls%S-&fJklMtoJ;N5mxW)K%a7ev|Mn%)sqgmUt0wem|)# zQx-^BAZ3Aj*8&?lFu~*Jr1EiQRxbYZ_iE8}q6IaNZASVsnJ&~C)YKPZsq++GYMLNN zm4-EtzYT_HkYbUfJklF@jwRSqSB=QB2bqp6WM~MJOvuR| zQU&em0*0p-kZ!XfH#eV9{Bi`m9=M!NQf0;ABHTVU-;c)r8Gb$s+9Y`o)66K($%jS} zXPPpE%KEKH_`Rfg)ui3h9loB9nmxCg~mYA;}{uKtX$xH zXap7*>8jLR_sALDQ<(HN4$ssA)K&|0nhjbIk}=FpF2kOi@yU-Ik6>xRhYZIWV}EFA z2>~|9XWG`TV}5uJHu7SMk&K2gJ2A@!dlxLEJG*)$u{7a@F~`Cz#+C1g*BAJ@O?rKG zd4-f^YI1UZbo)6T%a~{9g6pasT)DHCM|GH2eu}sVj=qiY9Xc|ac<|NF zKLU6EEL`OdGm;Z_u2|9xdx8f?SiQ%#7k6ytZl zQ;lQqG@#`Ehf(a%N>{Zw+=er)UOfE82jCg$z{GqSYKjdw+1QQZ>ROT+`*Em!84o&# z(KHr8R$>*4X$9D~Lx#gA&SAbyg~$GE8^#8_$aDf{-|gVBlE{Cs9*^wZ1m9=}PPKTj z_dq57`QQIfJoNwkI~e9WFd0+hp@;TL0N5DYt8OGh@U=&_a|-m{cmm}tymwj z^PLzcnRNYw2XN-6C$R0`{togiH{WjYp<9{yGi8BKg$1tZz}C*5PwNv%x@*Uj z{^mJd?PJAz*KoYQ-obT#yR`q0>|2mr2o{X1k9g(IKJNXGd+qWz+~2x;_W67i6rH5Q z-Z;y9dE0CJ5@G6fZ2@wP58TF=Wqejb;Io1l-aFETjI3;=XR@7v&&84F-$V9}a=iQ6 zS$y@Wtw>uXYrZxHWoVWQpfI|c+VJzY-ocli`5kn2w-7v}L-*n5kpI{pBR1KHgk=l# zqsP!~xewd)UQ``;noeo}=bDwMFX#5dY^NA#K+eu096Z#F3V#qrMFeA={m|x>pz+j6 z_!!Xy;z68K)7i8(A)Q>F(?fYaxwj8Pk?q7=KRb@kf58rmPDupp7<7e27#<74X7l6B;bw}wTH)9F(fs;*kXJqg z{cI<4i!5mCSis_VKh8A)qaVDBgtGt#&&6QPrdk2PLq2Z=?(QLUn9EULXD1Q2hfFBh zICqrSlWv03n83lGyn~`$xp@BB!+3CC5ssedfl;sG_u@9*$keV<7WkA{U;_sxq@81E ze&Yi)P$AQwG~su@vJ*K5HMs*B2~ox)yc)zt)I)4+lt>s z^dx%Bgf^Mv?zt~Peyrd&lHjJ~6oms^+ovGm4TZu?jVj52ujRS$E$K7s=lRKiKL zU!!zAckn-g;mcv)i3he9;m}Wdpvf+Woy;vOemT5x1s;83KMsEP2()Cq_fL(I7}$<+ zK0^;wnQ`Qelc+DK#qop9_`;W;MEBdT!ddVTMo*kT?SaojJ#ZL(u}WA*J29MHkNs*H z7HJ@%hbE_^5-N4p^sRW{{u&(or)EU0G6a^Ep>piNF?7KVZ$T0!O6l-XL4ulY5q}lF_(UZRzH*)mw9TlgaNt;DHopAm!$=!? z9i5AE6sGGjZLPy2`!}KY&0`n|EMp~7fUiEj8<=_<(O?m_R620JV-{8HQPkGepu{nY zP9DF%eGYbVOlD`~LYGqlM}`8U<5L(Joj^`_ZBZnb=VH$T`_c96aj2ap6td2|6fzeIP>0Ny!PffoF1H};9?_w^2$Lpj0Yq(_FKAqPU2xk z5(>(S5N-&sm;8&YZ;8LXoX`#*J%fR+W}Im3kzVr?q!DEVINjeyM>ZkZyhP+t zB$82rkK2bycq>wKq2LOZ{Q*vb6o%yWdc9ssp-~Bxkq`Y0dK%B7fj>>n15lFIDd_W( z4L*jInLZpl+eD#HidG7?3pyw17(xt_jxMykfFp-gXlQ?#+8FPyso)23X*bcDDh?lL~2nPa;Lh0PNfARSn{kdDtOS-?b zuSUNXrK>4Sr!l%QGCzy)seVjMHQ>L0_wNyVxEf16R0`-Dg^O}D8QKK$D+;k3i(vCZ zRgB*vD6PncT%SPhjvCeh{cu%Ni!GCsT1138S#q*eWMR5vn36dTOb)$?7Y{c;P1YC< zdCf%XTW!=pMZr;Lc`;;@@8Ey@m*)`4bzrRF2YB|R8&&t!!5TY@zy8}FVLD{S!@sv3 zYI1ry$;$5=m|$y&ndsA2eD}Zn9Oj*yVWON4cZ%9FAO7KQ|0hoN&LUmrC%JMdDw^lT45QHqd< zy@|O6&>E-F+SrGSJ&41=u`XxfLJ#ulg`Q z6+-Q{LX2Hx12Jn4A&nJP1x73mgkceN4i@WY<`ek(cXpuvcq7`z^{CAWp=%)>pL;S- z5_!B?8wnDOzx+?nL1uKpGdzHBA`G3g8oTRDFx7Gr7pG*{R;ED%qruvO42-)yh)|W; zqEACWVM9i24jx8B36&ky+3C30(MeH8HTLf;#<_FtFp!bHqIw%iMa$!%p(KE-+Gg$_zauqyB+Hf_2T@O776E({ebjXdz--Jh7jD6cGFwuIR z0+}JieZ` zD^W_=D5=kulyum*UtU8R_a6^Eq%@W%wbXK;5aAA`a%q+@zv2Sh7fc2d7a8l3vyerXaS^h@ z&J&e%e4>Fc@9|OAhs4YTdBl=J;d`0xTLBXtk`N>nO5&n{Kf&vvG#!Fmz^GIjM(}Ib zDD0dN^lkjVxK=4*zy4iHeIjLnd&UCqzIPCZ4jqKkVMkrvF4XVb&F{L9$)XxP8I$CE z{;yoDi&E0m_+=*F4CLy}^}zf~c>4u0T5{=Alq4F-iH7 zC?^b|Sr+om;K*AI$gixy*kCVK5=?LU7cuW&C2DaQZ3EP?;-s{=I7KJxg@FKo1QCc) zItLxw0pgTd_RdeCePo6cg$lC^(`;(yWSmf7=aZj@Vxb@Jy?-9Pj6Sn!_u#2V55UAG zGP@%OwZ++(92r2{@T8b=FgG`Z-oYumOiBmMBP` z<3eDSHd;fX?f#ED~nnaSL_bLZYy=FXe>=DqvA?|pOcOfsqC#Ia+?-IgU= zvYKU8s#o^j3rG+IL39uxfVchwQj#4>w&OCEgKbj;aSl%Tan9NQ-h1t}L`qtia9+ZM z^AaYUmoS;g!}2Zh&=&8gs8lMV4xQeFWFwJ(ywGF&jva%DV8wb0tzL3oVjGE+pApVW zn2hMhv=o!%gv8$|W}^5+R8K{3rPzm3APR-TfcRQ@to(1`-4EjL|MBl}_uA4+pHr|l zES#f=bfvG66Na?Z6wlnT6RA-#mfWrwQxa?In6ebx74OZBvsg!3E>1RX@e%kl8-Z&&Ffn_a^78?bFoQQ< z*^VQF9*mCh0k6qrGxI1+89A_Zb-|&gK2>-Uy<;Qrgag>I=LAOOYwwY7}JgA;wx)Nl6iOY9W*vMtfHa zGP&ObR#~#M(=pQBjKe2SVv@6Z;drEn3FTx8vbhiO*|I7W=BA*%xgO)3aqBt5ciV?y zwU0@v$}&Ej^7Hbj6rG6d(o(?QgOklYd{~J{DT;jY`AjqND2Um9?kwC26S8<7VRA4E zk;<>LMVa267;#-XMCTZx-yXs`2u=_{j*pw)VW*B6>#J^FXkV~7NA2(hK4H9=_O*{P zW&9~ke7{DcUic#F^l;L~TJM|%n3i_fFQ12f=<>2?&<`i0vM&D-TkHBXg0r`eoH~o{5 zv%XPFpVW*j;|#JO%Ybb5vj{cgad!}vtWo6ifhu6~dXs@vO9@C%m+L6p0vSgV{eb!j((!oQqt4dQ>2o%Jw*l*E$d+-PZng#NdP61 zDIPgIY+-akv?c)>na%2!enF_fXX%x^*gPIHU zNvTLpHgd+UKt@hB!US{_R8=FFg&z}V^@*aG_Zdw@Ljs^8>4b4C)~{Rp8MpB1SC6`_ zc=eyRVKjk#NmO)x{r~(aj$S;2^A|kGEtKK>nR@6m^ANI5Aj}Bsz_HWt_$P6)z6}+n ztg&{FQ3+awhPDRQg_7Z9L@eq*U45-!EDaVb;SI>(VA?Q3VO52nY%4YbWyr8HHO1QK zBvT8gPqP0j2OidB6ZoCEx-a1PMFJyAbI^O@2--#|36x_ZjJ*}Rcke^zc|WQb8*yY$ z9TNDtWG%lSnq#09M~-(Pr!0>krFL}mOfc%6#*t%$5b`>bhsLq@;uz9{W8D4#e7ytc z8kRG)?8g56`*40|Kg{#>Xm1?g^=Uz?EsTWWR$T0Lqo5!K_4_|00#c966ghg@`F>j$ zW_%VjbdDg0T6BY54XnHNAfu2`x66t{`wt_eOQujOxjZj4!aCrAF3p6&jx#vZFv5oX zTqJl$ao~ef(B~8|-)P6hbB8fJ6_Kv7E5AkGcpnZNI1k=1*zxRcOv)$8GE;(xeFz5* z)^b*CwxDPlUf-rys-y|8ZRKoiJteuF+BfjD~hX$ zw7hVJSsEXj`Ms;z`q2350Rp@Vk(TuF{P80U65F=Ck{QrXRf`!(#coXV1GtnumI7Tfv!{b4fXW~IYIG^Cnr z993yqd>|8H$jHo)Vy4sZ(NRTFRg%ma38ShS9y5Q7_rz?O;5gKpa~KK6P>GAp6sY7f zp>bw1Q3#UDXZTvC$wyjFp|ou-mQ1UyKz6>UHHe5Uit8_N(f z)Ut>#j!V>a7AzD^tULy;mzFAC$ABE-w|K9*RvcrP>CAK(40_4I7))v0wph+1X8Nt9 zs*3z<(J7LcN|uMP=cRX%PIc>@+fEY6 z$1$hlk|h$D6By+rz>Ag(gwenEJ|2Ad0bFQcggd1|>)sboboW#22de{!_S5$tL|e*g zEY?nSe^ zVFx2&KPE05N7SH&QyE0vyYFDor$zIg1NgzWH$fYm!ts5F5H#gs|Dg-;9N&iwA|X%g z+>HPy8(UvIfcpufHxe{*>Ub~Yyk@#=UZ#{iIJWN`LV6>n)IpqoXD1@Xw?G-{VYa}G zMy8f$GG#b%U_VpMPQv<6BWl;-#EAizQ=B;0m;^Ja%0vpWe#ZyMT~dk<4z*x~E`aG7 zKTf`S8WUx1bh>m@NS9-PNX(`qEzne_q0{DMuh>3#6e-xZ_aw4C1kT9SoQR!5Zb1oh z`8`NB7PmJJ$6J1ymo#4Id#_`wAAS-PM7DW=$($WwZ>c$zu z`?XbO^h{P_J}0*k*(7E-0XxrLx{4GnQj?wwgsxBpjD0N_$XbkB6Js!X6>C)r)?fuebE+-|Y2Wkg zc?3DD@JviW#pBs@PZc`fKL}OXT~r(B!o~h!_|!Fc`2Hg7+kO`9r$^u{&H!GZq!P z(LQBHPG|r_!yaUsS7Gy}O6+;D9pRO7W&#G$*_(`_f_yAov=B3mXQ4>Vz=Fk@IMdbv zlq|w{Uk2{^-|xhc-))6Il!;aMtj6ejhsf#4RO74zi%t{NGF^&q-F+L}9gW!4mx|kJ zv^aX&1=+j+raDH@I~XNGluG2QR$yZ4Byxzv)Nx|c*wqazSPPQg@M_J#DmGj@_8%v2 zr~wsabe4k#tXa1L{);-SU$X#vpQ}gEFnc|J&92q>;e0bj;F>kCuhZ!X=hWIeBBcq1 zxTZ&-$w)3d)_ajq_KR#;g_Xeo03ZNKL_t(=7AUT$1c{%V6ioDCO!L9$CM4d?G$>sF zTuuj^OhHXEJ|h-fb0_rb;Ocu8O^oJ+_% zfum%%?`p5dzN4q$VErZ-@SwA606{*%r&!lk&o z7Utsv&&6X33WQyBMuPVXzz1EK1aO$)Ik-qjES%m9kJCdsp^#`k`??y_l}a^JxpcfL zGKr|PRt!v7F+AFfVarMU+fSc`e_aKf-NWeV>}EZa>0L%)g;j+Z_dBs@T@@w>x+$$L zB4X5w%w-GsJ&q%zx)=r%wb-(AkYVyeTb==HJApY#X|VL|!`6dmkU->~nvM1$_Wr4K z!l@}>E-3&;_u$w6`Z~PqJsZ66d%S#N3}wp~A}LgdfBEIh81(X?`yiq6{O)qtQ0(rv zU^0@7wA}Of$-le{ZOuFw)Dc8g22__!;FTCXQC)%r>pndDv)9np?}5Rb zjr^1@{PbtfqQ%ZMGkd>0lVc#lAC-%WFm~=0{Dw>=+WE;i@z%d#7tynM#RPIt{UFRQ zT`uQ-m=;fDgY-bxPW7e+6dZk0s*k@#IQ!OO?&*VT>Dfi!y+Ug1ly zpTE&e*%TQ@TQ8t<*vVO+8rk|NPW3vGrk+O8yqlmHA4J>q*tthYI0o4)2A{*m>F*7!+{FO=6oz)vJg=^s8e-kSr?l@dR_(k`x^*r zP9Y#8#2NA32wNNR($*7La#IzW`X-R6ixSY12R~~KB}@+q{V-EXB5H5G6{$)ew(fWz zYBKiwXJlAiS%RjPCe{_BSiPbW7n(Yd7`7v1sz4#rY<3pIp~=K8s}^BqY6K@wG$F|2 z$SIqLv8FRnWRx>CS;6)ImE=r6%`ktpF!~5pyLrtp4K_pgyG#~fza68-;3W1x-++bR zUWOt9R77nrLS(6m>v2vXq3vb_ql=ozOx73GM0kc-_)p++u{|~U3?mYNh3|7>AW(N9 zP68CHHF{k(P5{(MrI!ft;*|DH)Pabg<&20!Yy+`-!^p}^ftQq8fdryr#5ysnbi&lTeJ zC)5=LA17mb1RWN<|4J)XalEoKQt2oHu#8PIU2cRXf#^#CcjP1?flk`(7-jQxB64_s z93)r?UP&XMh#rk;Xl5o@w{AYX3kO?zrOPEXrxuStcr)x)2U7W6$aubjF(*vND3kdy z#?)pKk5A42#P->Tz{wpaC3Kels2*8FX8PR$>AMo#pkn*td-8H3rch~lkCHExeUeIk zmop?h5KK5?J&~D+TYLmQJ_4T?Mt_|YB5y`^rR;cN7rNO)WFQ21%jR22pEG+g@@kUD~blpy9RC3I4da-%>LDmBYQEj_Ry6ZhYehPQT~C0;uL^A^sB<--H;@FAOONJVxQ z8){8DSiOl@lo7`1?op^@CPp0TY=$0X)DVjV#3VLKsQ=9?SK-{Qo!mE*RGKu%rz}zg zXGmXy#byVNHd}DP?nFUx4j)tmphRk5?{CL+aw*oAgt46uO;du3eRvCzsuuA6FK3c) zz3<>tEn@_x5*jr$X7*?Vw20chPK(WdlTAkzTPCN9_s2~*2w`eYQiRF*02C&imoU-i zB>g6wT$q~R4q--44(4nQCLp4~Ia9G8ij-d}eM`g0@{)1;!VF2VmILux zG?5Ft@_Ufpi2oBGfiHLjuIs=eA?CzK4S4iFt%S4bJa(QQ!lN}xyz$y;q%OZ18;X@I zyw_n`pNo6f6mu5qMRwi*-g$@Ib?G@+MH-#+XV1bGHR7=c??eV4zJF?fCO{KW8Ph^U zKlZfNV@MT&hEQhC9htIG1xJ@$^92QS+Mjl$G0KZ6c5oWF=8;EAs5ng@UO!*E5_I^TE!DDKV9~{M=lr88wA7>zv#|I2T!TJ|@lz&E^dDXwj+k zcVgT{M)9SqFhAGGlwJbi%tcZ<&d0RXf`v6wbFzXFnK_x1QBfThFymQ zJH=k6Nt|x%KzT_%Z2dM#ex;?W4H~vXxQ8bo*Ce8Es0(7M!V3WYAf(8B>6E z_9cF>mpqIutR)sIP*-;niexkCuXqg)_u|!`?Se<^CF6(;zx?apK)<*WE=vbB^2XsF z?;_g^Q@4!zj~?TFz9{RnTw3vU<0J67N8n3?(a#-Oh#Z81(R`wZ4yil^c`Q6f8HJQk zBO*DU>9n95eHSQSuQV`4!E_-r8^TEmrz2yjJ0-~kqnm(=&)Li~xAZB52Hj>}IFgjJ6BK2WfTPkJZTQRE3;?0o($BvllkbNfj= zxV{QeI<5%&s^kGD0Wxm1UTnl$+jru@$F|_~xx*xdmZ5d`3n_DT=6`_}w73+;1i`h7ujzJA%14qu9{R zF<>^Ly$}BMVw^ZU0877>yo*lEjO$Q$s0+0V)6m%OLxmxobXQ8W_8%unfEI0}M_ZiE z6uF&h;m#1|vuCTp!pIf9(2|v-|M)4m2)PKdhC0&NPax1Z4*vcmzV+YkAlM^FhMZCE zi~aJ>D5FIKdJgTSGC7^wXfw1Wm8{+NV`X(I`8z*D#P_wm0^hC`V|ZA5(lF&#=k&)cGbj)q0rBiBvsi?^1O-4s6?r!~Ijx zkjzw_NGC!19ujX$59Mp@>QlWfoT6|P5#hXu#tShOCm{pLbl@W}V1|Y3Si>%z2~lMN zaxVT>u>rKCtW09dh%lum9D;B#qEaUy>Y_d;9ERAsFwuJ@J|74W^(EHhLa8@P+J9`h z_*;Bd{77iS0P~VOHt|~2{)7qg;PiB}r2H(vgWMbU#bf0DWTX$uD=9&7L7phHN!u64 ze+fp<&kKh+$G#z6f1RC|IA6ibmzBL5_iVTo$%E6#DyhNBB{vbhmxpxCLOlG)7Nqw~ zLYI}w?`n#5Ei;Dw>4eeOpyBX&EXb|I;obFEv*I2&PacLjcNKb$979IYMr2#tF;4im zhE2`G_H<;kRwl+n$zq$51sstwPSGyGri~ks+UJ$hxh^Yp$8y%<;VpL{doqaZs?E5! zHUqZqet6VN@%W>gQIax)mSaOiK@#n0cT03tLVY{ntifZCuSEi{b-AJj%WCpqcje*1 zEe~N?ngT60)|+IBkP+^_W%Hd_l3^h0h=bcH#X}E2j0HJr(wG&Iud^6KJV%|EV4rz+ ztV0o*ZK|r)AjhnM&%q|mgvEI55!QN{-E2KEh%s_H zMhFg>@td$>^%ks5&cy_UEM*z1@!bdSLXLqoYh#Ec(PQZ9os=qtQ8xS+mEM87maTx= zMoqnW3y?)xuSGR$aZAZ6tX_2wYLzLZV)I|R_Qm%YxA+L$C?jx92PUu?R!XCIN!^s0 znoO=XA9lR^0k$4!h1{G5-_#Ix9cpG;%fyGsB=#OXhpx#sZ2O>vDGWk!Ga{&G+U^|t zRgQLcvvISJH_0`3cm44a(Hzlu9zx1Rls7=Vs3yYd2L~;f7;eW~Z@h)G7uzvOAcjoT zCb*u65~JcX9uH@$QKqL_aiXCMBLjnQk+(6zx`fB;i$T=s)ckx+&=ey_0tlF=8*Dm@ z{cJd`J6=y7MHQju~_Xguc6p zf)ot$0&*;lMZn}G;{#VXGT}(S?vCmDU(OXvITj=(Vcm~uDGgJ6iDT%ujggJMhfw-c z_}R~&g?CLEoE)oeiZZ6Le56ebqPVIM!|rj4T~@(D6lf`7^PvPg%u5%*N91T4BLqWI z0KUvzWExzMmu6tRlM+70RE+czMt_J6!Gww{SsxTgSpf(UB%o|c2avT*Uatay$RHhhHr?kLTk-3Ee+ezt z1gv^sA;_vp@K7Eh`Gm*wT8gkvno9NXFxmG1<@xQf`GA&Fo$#ob6)AF}uXB`9SBUo} zTR(V>so1j?3J;*);^x>e!so3hu1TV>B(6unT^YCd2;68Ra9tSv3}@6D!qr7OPDC1? zwtgiZ$U^Vx%BEWpm0ZclA>hSQBk`vgG0{izkN?jf(7*=NG(y{*tw&)`Wv>fwK9kac zldWD<^P!emTte0c&eTcNn_01lG(S$9W!gw(DnfR+52p#ds9G%o3NWIv1ZwPgy^g<)RP6D<1l|-IqFZGMKYUlNBw%N zW9p}sGx}-v4$Utzpsl$FA@<1BESQJh#um8f#7gEb!(_)hc?GfOiDyVEy#64tcNK{$>k!9d^((n^kgHWRW_5;c?pqK z0pC{e+6_(FVReUDb2P(c9fd!^fQ)o9pHN0;WYUccrgzosTN>#bfPv{^4MXLKV0@n; z>oox$`2`u6CgHM@&ZznQxA6AyCe*Hb44c@`rsDBUJ11dvg$UCZj);A5MD7laO^}^F zU6R#FU}~6i73mz^<703!eV3C-r0no8GZX0~?^Q^x0}9a#Mz11dc}Rti(>Y*ZZs^~8Ea-u+ZJR9tkA?m;h;$M11 zL5MuVMzctm+?3Nw=vmK>N?8EH;5n{hUMV2_>RBY{S8-j&_YoffF#=yAj9zR$g5mx_ z*jxe5fKymBHePaOqS%$dhlF@&#OUs0H6y7PhCMG*4T!Zcp}EDUHUDPpK}fw2mlTnQ z*GXvz0zU)?pxBSt&b4fYkxqXg6C3X!7155P1X1LpyeJzJ9sNiu%tl_mA9{5Nw&6j_ zq!^jzxtkBTDYTv<>2Pv7nd_%eUY3uNBm*?AF${M%5jk0k+iPXmeyE9cFa@Pb7Gw8; zIzDiD%sk7Q+wMZ$fe*<-A3&adin>t=NG0t~=P>#C)D#uGV$~7y{UeiGc(^3LQn1Yi4VOj~p&8V18OW0hb zAUDRgVM@IWFDC<&WP-_k&eX}N$e+c38-)XyT_D#Q$fUvi+^ppk70tbj{bo%!pWmY} zH5+n;6|cMvf3=MLeat}2BHY>ImxBDu2y(8KNR6*tY5kA?V=!l8ZjY%1Ak7(jk|m3c zh4?pu#dke`s=Jg-LC27c*@c&nPZ}XY;f2YKY;c}CDQ>-J_LwijC8gD<$tQj%3;apU zm{pK$cARJ5jsJ>|zzsD5*U1}D4r9iP_kMenM7kr`Nu}H#8yg+j@Hs}EDhKEUN#tp3r^7Ok$Iz&WVv2oJY~_?vdUK9I$A^hJ;zCQq1vK>x zVsK)BZ19v!;WS^t^pck%l72S1n#{RS`mE^epFlSIe*`jJQb^_lSg^v=|Dva_1G$uE zkW^|wnr_YnhNR>olUIUDL zXqDt6^!gY2PJD*8}xgbQk->O zSDr-BLlpqlE(6r|`l8JzRw#!|({z^Q+i2 z)74%^V{wa*z@N(qd?Jj#;gki%%kt@b{4fwkynE{@WE7;L;q-a3TX+!S-CVc*2u2AX z?{iRC(BCJqbGHl!pr=6J!9#?vGx9Jotub`61D%6Ia7+*!!jw@0Jg7U`1uN@O$yu35 zWfQDOw|v~>bbgIZZMe`fNMh1lMs*Y$w7Q^8(n<9y;ov0wDNg$hBx>#IBfSo5b18Im zBV%@?kikHtlf0yHN)T-ElsJ+3Cop6WGPRT@q5A}aP^d6Rc`Od9H+!5mGLR1=g|qfl zlMw+s(RFmVde(LXiZH+)8y{0ka?XTh0?0vNNHQ7io$S{d_k|^fd1Zi++k}gCLIZ+C zLJpBlA&*YbOf;B|$EW@Z>JDEyjQ)S^giGgUgRv2B{Qa+Ry6FPWU-Y7|R89DIJJ~L> z5SkzYk&*bJqbEqK4Dpzn~(G}C4V>(QTRt{1rfk{EgNDC&YIbB38 zM%XJQryPjWNhXL0Ymy$;7~NxNY^;|EpQqXe$S$9Xz(@zhK&{AP3URpMJo-rSlxa3H zV(!P00|(K3Vv5AdsW?}6fh_Eq(9bqbix!7-7YC48kclblAo>R#y#B*{uSIHthJOru z&kiF~?jn;s*)Te~Nhc*kekP&z$By9iJDtc}oQghj3%WfP96r)T-Le#>@i^IQYJi%M zeVr=I`{)$KJ_%S^x)7dTDx8l|AT^n_Te4ZWsInlWgY5Meu>GCmn9-5^nbJi+`@5~k zyQv)G1MSqjBV)(_Q`HeIrq0!)d4RNtWo+SyTYLm=fD!moVe|r^5T^67QWI$2l5&*l zrqP$N7`fzzvn4Ob?Tg6deP)z0A=TLOXgNN7t^pk*a@_UkCiK307~!OBl$cc*phHlw z?Qt0+l$wtsGVH^6L%+2ewl1^7O2Kt zI?*t<&mfHmN{Uso*;uSQ%{OvND|mFVlxZ6KZv>i=M02Fpp&%x=oyod}*hYTkeAY2U zy^jsOIh2u*_QARk8>Hv6Iawea&D^(0rGDC)q8OPQ!32!n;qJpgZxG!U4x(u8W($T= zHihlKeHB`!eVYeo@W84vmTO3%MGCM4!ss2OdunAb)LUe4fB5k&IClB~su$jg*7sjP zDbeYJK1m22)pkOHTN$wt3~Z1ipYGZ^YV25oT~8b;-)p7J0` z6G88pWAGaD2?}vxg8P_=q%&Gxfbmlw!pb_FS7yY?UGJb{T!yow9z6NT?a+|1y>8bI z*kqZkizdK*bO#J8?}GK>epuOmcKBd79^6drIKt?U?>|SNQ!XN|FhLfnIJxH_hQm}R zmnm`jt+(OJScdZSK1OW@j8HP=K+_TEOVdzq(P2a8C_0DS=%+)rk=L`S?gadLHm#!s zBl}OopHWR>U?L$Cd{l29#Kp62OyriZ_6GKuZG}&3L|@}YlrF8r_!%44@EYW9;}#!* zKbsMV6&9{}x`ajNl;WOyS2MdFVJ}#Zq#SE5%S7nhL2Ru{#p0y}u(Tb<>pLcqO4jNn z1`9rXcR&2vY}}${>LgVQ180TPe4t!7ZABW3;&L|ls$E+6n4+9wTFo#(84jjMWP~SQ z%ZdrmFr@eyB?%{YN2j`!KrQgui>s@vR@M#QqoFBO z{7n$dT$3|uEL!#e=B3!tHa3I#ixv~T=|T3|mB<=R#KJpo#f9G04(bn$5$%^q6kwBJP*BXEg2B;# z{_gA^gfTCQbEk&LL@~%nC>04EVK#SqFw|lvYlVq7C50uKg6Zoc9GaxNdG=nAk(Wn1 zm+SxNfrpsdo1PBb@DA*wXZ20{OK|N)Ny)|ZFwq+_#Sr?eI(S*LagKH17r*L(dDS|& z`Yh9Zn~apw$I<{p}ri;L&^W{2K>QIDMTmt!=`pee+fP{@=d_wLM4&hh) z+wVxhLZ&L+wqd9Y5hM}iI>mZmf+8dxV^pC-S+x)EJoig5>x@T!um+25LkOv|Aa`^@ zTd|zAFV>GQGW$TXUx_k}(YuN~l4Ao6R6J*^3K5F}4llAKggi2x&H&XwD!+D(8+?NI zO}iuF=kw)`z%^m?wUvY&GrvAOYGc}t{V6;SiCu#MkVt)rJ}0?AA#&EO-~)qs83}19 z))N|8f`^ccX32hIC_{0B39v-0(Kp66A>I?HD{W#TQ!r^)O{|3SA@3n7(_Z#NhXkK`xq=!VU(8Sz(JI%SDwUFF;%@8W%Uzi zk&}^4q@xV|9X*_M0XI)`)VFzfWQ_l`3{HsdZ{{{ z#=2Y*RgZ^Axt2f$W!7k!stnB#;KE6yRxlzn-Kk(oRX)tiC@kh5c``4A}j=6ElEh@RRt}%-U+e?2jJ<2GJ z0oNayN+lG&W2RtFmoUxj@7TNXf8!(Y=P?3T-cx^c#=@zHdQIHoBk-w4fGj8;7m=E? zjO+oz$`$0v5?WL0Ip=l7hGvLdjmX6%C}S$`a_`m^tNh6?y$&My^tw+#dPb#wL|szM z34GGdjOjwPdDaNj36Q-dk;0wAW|&S7MiiI&*1Qfcbd=nYjPzpD(>_etS(8(nVPJ$R z7&k<-xA9Xkz*B8u%1fT=D;$4p%U{aB0oODVjdK%*xm~bM%~Y_CT57_ih>w#BCR;vg zOlx|krls|6>}vH#Pb>b{*K-7}1EbenHJ$e#aT+3p*hV&RFC{6Yey#tAgSf%>83T?0 z>({OQ(#|BpCh<4^bvOK`0Fo#j^5#E0i*v0FxIh?vak&PaZQal@VhK_0TEOTJA2|*u zVf5#l`y>Sc7h5BgR0!@L?uS~dM}RE|aymB4_%LDgbaQ0b5X2E45+O(AYNq)FRTp9O z(GXLYGi33YKwDcY64|_NZ|R4OF#4di7cJdXc*{=1Xj>D896)-i9)8xQP98am#$$HE z=+n_~rjhb1W@u-%#C#LOXlP~wdQLif+eR@oGDR4D6phUtOl@jOMobv}nLz?M0^I&M zTx}g_>5Ec@fVJN<$8qYdRyMU0y5Bnnuh)W?|Lr+^c%+dE2~?jxUym`ip9LlZ(4@%F z)m9HbSzwaMEHXldm_ZT;B+>Z_q-xB>C~Xp4H;AK?xAk9 zTI?|LGb)J~AoeLQxk~$cEzr|Jx1ViqkQvI7;oFlwucpj(bu6nWffHgCQxz9 zJ<#>Ed;~^6*j)!DrE<;=&7gXc8dusVdQKj~B-<&x5fbfQI0tK(2-Ok$rZ{xOQIkQ)dj69#iU`rcD*wRwrrxRIH3-|Fe zNLo>hzB5NjicH=$)`Zo$rM?XFZY`NxR(LaJ9S9Miul_)>Pen z&3N_fC~4J#cyCIMOx7;#{!lNy*(5frbFY$nMx7;Pcb?v_RNfp;mikZsN30&zMgRmQ!h+384Dgn5j~0Z zX82loxwv1u%CO(SZ;1&@cJ6vScJF;K^afBce>Lt{b1Q1e{g|#=j3>YU1kzf@s2@kw z;E0>iKsqClG{WeYp!wiMlw}m*@UBLzTYfK`$B!W;vj**lPa>z_4rGq@V#1e;Xiqz3 z@5yRH{zAdPq97%bV51k*WhV6!Jo3=PNa>=&Hm^$u!4%5eJMjJQ-jA$tKk^nmjz@0F zhNYzoF7?fL`l-iJo)*T1{XLi9#p|>dt8XfS)t-kZ zp7Cem!`0lsw$MWnX_!;qxy36t8lTV_yfDP~dLabjiAHz;FRhdDC#?6v9^VnzDbEsr%zG^>rRAbEg#l9Up-&U<9svrOBAj9wkKH zK|L?$BuPU#gBxcW=#>|DV%vKS=xgu5Z-4h1e)5N17$&nu{l2~U#cTV~IP4&Gj+<;5 zPS`9Hc<1%^@XP04!+Z5(aB~{@((kw9r_X-?D~Vef;Kl75Gy|9O$i?AgxUI0b4xXPs8U@rzmz?KeMloe zrE|O;N!68PVV{6KEe~00lJ^#7P)fvtC}naiJqPgakuzk3QAimA(P|-M>P=i$ru=M# zhWFs5XSc&i-p&4tf52-eEXb#*W1{yke*N1w(CtuT#oZM!(Fqpi7gGds98;`x8O>+$ z>tDPNc~u!SGD_gcwJ6CO$E&Zth`N>`Ho%Xgw6Yj8mVJ2nxou3tO+sTL{gbX0zj^Kj z)Q=DyNRCa{_z>h|(9p96C|KcRNM26fIGGbaLR}%qRA`tp!h))FMtNKDyIsc-h+bKj zQ*qMQkC%S)655TFU8ywS;GWlUicB%7Mfs51crLH+Bpc3^9*neZytx8IfiAwYg3gEn zuGthu)p)RH>o2igP@vsJLgK{3_|of0%n{f!5$!ThVL=2D`VS2kQ}E1RV>acZt)TLDn{U%F#4Jb&XNfw{`o(= z1%HVN3GOLg-t+NSKP$m^%3Y*HVx&acu7kgCK-q(fFkhhk+~oeFi_wz6S7?eRQa#vX_d-J@Y$qi^Qc^Ss z5VW8m646a~eNw89)MI`!*ee+A3%Qg;%(y&I5zS~D?I8!J4tXTl4KlJ9&~%@h{Z@q0 z3z&VtI)p)9msM4Tu=g1)=}l zWXY(UUkpFfk%=jKwC;KnuN*vwnl+E(zFVsZZ`Z(U9hOv$i%2;ox`;_whW367vZy?* z7QI=51CrObfYFDzZ2_Yfi3{;hL=adr5>p!zsXrEAq~pK~zj_WM@_cMrHxF$+os4?~ znQ$&{y@iSf4pL$j@EA$y)=3UggFc&V`f_ah;O-RQ4nMzRl_m(Ajo(dDGSSMc=TRwJr62 z;7fzii=7G@rHsr4xc{%$K{+~rZCfp9J=Q>HMS)5^3(2I+(NfYu=^~7my(r$$5V{6P z7e%g7qqu3sER(lxqEagnLrHu zbUGAq2C3Ncw}nLP%_7^#Ejbro@Hr`&o=!?w3e$7K5|d+pn`YlnU{6;J6cGDYof^Xf zX6Kbj>x+L>{7;yktQT{p&&&fwnk7psDn;7t0u_NC^Y}AoT& zB`mjg6@D~tC9?DKnEs5drlX^(=3MWx8BtvoJGRU3#a>+x)S##12>YYh^u&{NlG6HcFOHXw~ZF;k(O3geQ6gSdIiW4I|X85t%uhMCHgl8-VKa`H@)SSkx} zD4RXM)H_z9jQpKKBtn>mZ3YwxmrNXkFcbMIg(aJ27w|R9TbE3465pPN+rLc1KPx5> z2X0&%rTB}lVgxSV=^xvh$O8DtU#MXnxxJ~A$R{^cX>6n2!A2}9FJqq#VZsyw1W`|Fa|8n;lTh(S*YPI&@PotXvZ=8qL{BHuXXBiIoDFPb11eL1mJ>IYQ(5HOqcX}bG zf`E$qzqXN-nT^s{JGQHR#*~$NsgF$5euGr(Rxw%=7G~NsL}Ud;KoBNoC`4IZ2F4EhI7ugejLYEekRt zBa;A&P>66&4&_?IC35O<82zGysL~O1I1y!i=Ey9JzP_~|rA4{$*?mk8 zCSZ7sY65f&L5Gi&R7#99&Bf{w5=g4dG7G#xKfxAC%Kh;AV`@vNbqnFk>FFtScXc9> zvN{ul(S!0QVY|o*Od{QEf{iJ;QCF1LoEFoQR-8L=3>OdEP*t0Ow)%F$=u??3h&j9f z({*i~V@Ribj)&>S(J>d8WI%f-nKO875$_oGof<$6>swv@c1*Rjp}ChZ`WzV=FP_Hn z*PD^EG>a*{ad_RM*!uh)_`~T;SpuzW8!+-7P{_jQZfHh;G*vqJG@6^Jc5X~&di@Z_ z6lq9R63t1ep>#pgd+BSA;OKL|!d8-KFDOe#XICFlfEiE(-RS7-A-JASQm~PX_T!CT z97KYdy=HnjUi?3P5A}jdk|g!RRCG zIZ0y?_q&hY%^QtSdj1{a)8mVZmBbAxn92ouENCOS#}Rv-+K|2 zgwc<*?1DPyCL|9WM=xRYr5YQ`S8js7w*^NU6sRo?P}(Pqp`Ig%n3)Fa^Akqz2K^Me zkCQ=OkxljO35=aNfze1V*5AGaW5;%(i_R~aFc0VUzk~W7BJS90_}vGn$W1loqwl?j zUQZe4`H+}H*^49sYd_QP^Gncq@I1Qg1LP%5gvN0K?Nd%zI`#N3|MC=> zLS|qYtw-R*7&=F4=;&Q&{%{wLx~P)v>SHz}n+{(?sD2HzD5BC9xA+L$cq4F~{0dzR zXSVex&*7c-kKn-RR?d9Ggu@3BASr2(q^W@b;q>I!3(*mY_ax>HIypZD3P0(`$8`k! zK5pNf5s2{n%*nqMPdu;%`W`=u7p=pl4I8n10c%f+#rWaV-$!br1;)ZGMonHM5=K8R z!RVKgytf_&L>V65)r9p+H({#oB$CtTqvh~vYN*|g49fuQ9`pT!L>u_BfI|rx@)-FgZ9%82v^(^VCDgw0e+8yF%`gwJ!AouHEC_|cCyA>7u^`=AEvR+nRRA`d_K!Bbe4ET^-P zBZ~|p(ahWM)RPZkc`jk}t_h4d%klKnPh&};hMbRuxOKx~SY4?oO-p7c_E`h(_mxhrE$uIvKb42;6uha9sx`3wcrZF4+^(jA*TEC1V294+C!24Lq<|e3hz4od@c)m5Zl zvcQ^>k1WLy-0UN>_p@h9XN0BqFy5~_ivS<`;yEnA=$SDP+HlD^nFtQ=!)wp)#1wfF z2O3_(n-plx;r3OYBY5ujThVP-VaXk(NKvU!Qc#Kj)8$Tz2N}}N;kjq`KvrHtWFa#J z2^th-S@G6eui|*?5K(tlvWpZUWZ925UfhA^Ry#H8(vhlZ#S1U~0T(IgDoCzf#i^^%;~47=36l>88lSKE+1p6f-tHJ_BD!PXdVyKCH>Z zn54!X-(}l}obdEy1M*W7$tV%VqQzyD@kzmyJPnnlW|XHsO8O-SiYXA8oJ>sJ`6i^5 zRzgcaQADG|E%!cxv_2OWE~$X8I3F5f#m5QXKfC`l7Oi;i-47?MY^FROTI>5giTKtQ~6tt^_w}b2p7QVRuaj`dRmC+M#|kpb8lf?nhgIlA90Ug z^<@*^Uwj1qxLBn+J(#JC8P zb*EwNrToeY-f3dXUsS>DPd>f)2fxY@ka4D;lpaG98YKj_1~CA-84vz#3AD4!@<>f0 z)Zn9*L8hwjq`$pCzwn?>Xlp=`L=PU&|I*56WuV}o_rd5QvpIW?$A?!~LGypQoQJyP8)*sJ-# z3h*hy$Sv-@Zm=uii#S}7J`6+%+K63NA(HP3x}!*xP0Mr6>x%tEf`p5c)j^nIt}*F~ z<)7zefLeBPModbfk#$X@_$CRWRn#5(WRoE+zwlBYnP~k8@%WXbbP^U0k*$O3k}A=- zObb${OT`9l$(ZsJX*;FzvSW=c_;mj!sP#;PBk*K}YkDPU+UfFXq&u8Vd;bM=^b-vW=1JabdzJoJzt zlxdm?a-}&uavVECHV*ctsP#q+_9P>1VFf$#rIyMYXEfqR`ng6RLY}^Netrsz9<3(Z zMIN^Qk5`zcB5Q`c6kEPE596am*cF!$B;h8#k{ZVkABQpBNTJdYHf~sfX{s|PCQ+%I zB(fgb1Co-8p?1f6!YG&W$cO@+-*uRu>*AI!z2WVwiyg@fE@ zKLstzD)Zs@I50UCLMB^F`Unik$jK&C#{>?Xw_*dsyAcQbtp*23ikpoM>(bFdM)~Hw zHr)O<8{i&yAsV!kJ28PO&RTfGV*gYmw~Zmh9!MiaKZosMl$9}*3i;60#WZ4R1vDWC zdIp_TeJ^-qWlo{|9mG*ca)*3tOOlzzXywHA@00A zA7fSgq@Uz-uQ=A|qUf+=K7c=~%=7*X+f zIpgI2mw3+jmlR~l$fhAwA7)s~kkCwADUlKwad`aK<~#n%4n*+bjf|Ydn;vCS=9p$^s>g<-mb@1^7%c?>uv9W9awVn z{b=3(BB~$w0R|f1hbHf4mC~G~^+?>24VMno!rEM2&#a4+bN}1=v zJWi&PskGcxw+BPfETSDtFnat5h9d>I^X_FBJxbt(=z~%&LjA#aaJH4wBwaQgK z^Cm8gkvr6v0_~eGVO%*63yYbZAQJGEqkXIy=i~M}Ye=p2CYF;J*WR!XJyT38-nkA& z@;aUyBH)8PlS#cNG2l%`AA2kli3Dz?(sNSz3~nOr&Ca?;s0#}5z-FQ|wFHVdTgkdV zfU|8w$RD#}$kv3HI}Si;3Zs{k(A-oNidNiBlw(X;{VTg5;ya3uz?VD%*FhnYM1x^i zGWq6`S*%V@GQh;5xb!#QGtK>N)RB`-7h5*Fo|+C!)X(Df=QRQnjK1JDeE;D`q3LAw zQhOUV-*FFaUQ~uu*<$?YFP}!r#bG2B=MdCDfkrm#+B_*_qhE^F{SC-AW#RDqO<1>t zF#02>S+glekQ*sg2rk zjQ%J3N1({P8$bThqcB_C$glk#zOynL0~g!iP_Dv%{;MZZVWy1A`|WU$u-Da1c6LtI z!p;e}Y|HUi|M@26IWRMTYkAe%>WVG*0BIca26 zsFG%u5wd?&;X6-0gQC$W(#n@$IeWxXl?(9rmMxfPSck_q-i=VJ4H1G$;uar)Z_)@{ z*MW%>6^`h${(O@LD1I)VWdxYUqf?pY!&XMeG83_&pD_BN;Q@@<&*P<+UxTAI58e?H z>5`#CW1yr6*;&d-B->zV#gf(4XddZ63DeI`KgAzwNMJj34vAIsVbBnYZ=!sMtQV8H z8JHRzCyd^JvHoM&bK*P&A!7{m0!A;A1Hzdmv3YoU zg}V+fzWg4#NP@d~eG%dB8k856BS_|T7h&|el=FCziV4w@LZ&Kb2%}F#e#RKKZGRgl z+XmSaX+=?4A%d2J*!J2Uw6sh>MdXS}-HMlAeFF`{ticiNW^ z4U(FqdaX;NN^vUHR^n{kVe zz&B|Gu9-rdJIO1h5#mwR+^EEVUu^^u3>moV2T3rdsd3x4*`LG+!sRDS+iSy-m#2|e zR)wWCM6EiV$Sq%sN}}avLJ`(;boiUU`mdx{(&N8pSMb5Dz~=A%odknlT=4fuPp5|5 z`e#r|w)b#oA%!Fjh)lVl%__sKTm10M7*Lv=x(N#_&7@q*Bcj)cwRdhrmzC`BjLcA#3fcJ%6xS|?VY+~=D!r(v zEo8J6!G-WBN;fP+mY%w0Y**3Ll%b*^2@a|{Z+LnGbj*INqpp`GiCSGlP9%}2IElrs zJHMR+0|hj1VYnC#k>V>Jgk9~@jlXw;j=*)~RMMro)-(xMJrYt&!+;}7KCCaHV z&mQ&QwV%EVceWlf%9!8z@O?-mtGtegrbMvQpRjqE-%Isd71G&+8uaoSqY25xyMt~rJP%uhpd2E^=CiPeXVeA4%e>LY7B@=ptsXt+&-ugva&=(;4 zJ7q)u2u}Xdy@V*nsN{s~lTC(<;xb%TPKip;dHJj!j6mE*2%{J3$@_|}5heV7M(ArXa*|UVGl653@CoN5G{*P|?mtZM%q)!m)9&!&>oF(k z_eU-<)rWabGLkFLF;7LwS0%t(Vd}6cwZw>iTHkz?>qOE``=kAn@t+a8isv4;_y}BW z1g^;{%6>4)@DPj;61D+E{TLXsz>s3%edfpL$RKI8*ebyDA0F((|KHwwN4Is|>7pM%kOTpc z1lW5Q#U@dORPW7AZn0eA64zA6li0a4lbOkS>%E!#$6If`HTO>5O|Fy4ByrqjTaqP9 zR;5H$N+KzWz4u-~fCPvRyl)?nDwaekvE@kd*;*pXIcJ}Je&=BS_Wtef_kB}NcG{y| zII^#U8e1-Ol$|0?+Z46N4CwCUni#{EUbhXy!zQXKtI*rg1qJ0}YChbJiq^{UK z=`qyN2~Us?YR(uuSZZ-u3-goOL+{rL7RVAF3A&gM`GdzqTUb_WdWa1BtU=ldx zU)npm8MzVdAPEAQ@IU#FV+cwKgpPS>AOGt+@TO*vfn^HA#tA4qlNdEos)nKG-EY++ zZ&@nuv0VNZEpXe|=r0+IPmX}Zt2J6^Crq#gyAfKN6# zH85nY!o8FM2@Y3cL`kJ%+ZdX^<};maKe~F#10s|IruGUbUNa zOUn__eHL92%aNicjDE>|2-Xz`?BX>2H}yPFs>VSd_BC%S~*wTWsn zF+JG*@p(Ao7h=;~VDG^b@R0g#)3%qeI9afZh~h)j(T{PwX_O)Q0Ic9FQ`U*(ZW=Kxt&!g-(LcgJ{xNmCv#oRiH_&JK#EY5GRAvaEE$2E1ie1j|?6uc7&qkrY8r=f1NVs7z0cs^2sUw9F^I|oLPCCh1j$q7d`!n_~DO!h{ZYun)?+5<8}QwypM|=Kv&v=bkxRsAR{91!wqi4i z3!lK&)Eta=k2CZt&%G|)D*4Sd7Pz4UBQh5z8!)LI#g6U!alVHih6suFnbBh!g>kBr zp+hqql#nQEYT~G{7Z#5ldx+8+RN1KJ+y|GPVuSMYca72imcNi-^aTEpBZ~TQ1LztY zKyM#KQH@o2|AUV)UP$3eGIF#uSCg=os=*X;oSUDF%ARTzt;|PNcRex-a~N8zfPTRe z=5m!GC~rO`?OV{JPer1)8ABxQogft7r_o`ks|<(EUZ6YlgNdAk@RQR?lIjVKjfA8B z7~Lc!`(M3ZSICp`zQVIwSL$Oti9zqel`MIc<&fDgBSf{T4N zIs!k8-l`_?wO)z#_6|5{7bgdWhd!w!Pa~01+7#DfqCtxnMtc=_2H@b|FrwPfo{!8Dcc-;ix$l zYC@U$49evjVgaQt7F(VVBaB{+4Nt{#20zL{PypOq%Q*Rt1<~xxmM&QcrOAZ&^i`M> zPF8uYT?J}F@!Ahw=Q?UQ{vj?K;RFgi_{={_F!=e&|48^b>sbF?WKh_|<19cB*U`L2 zGju6)2zNJQ(iM)J)MPk_mJJQlV8hd)Jhu;;=m;bcLSE0DsfBA6Af}Q~c#2ytnwN|@ z5h_%4j$mU(0b-(-BH;L0#O7yly@`ElupX=LzaJI#W-MQ`5R+-i2qTO>l1^a9-V@Z; z+J?{JBVHPAC$xAw)=&_(ih#!g=Q*iy{PjDjhbd2Q^(HB9}AWN0!e zelg0=S7T05I<)f=5fq_C!V8Zu2M1C$%2n~tMQ9%BCeCThg#~@Xlv+@cMHqDuMH(rlztRL0QT?EFE z$Ar0P@nOLf-JC#jW*%bnesbcw@w((T-+dOijWBwmzI=8ZK2(kL1qIMqJ5kr;!;<1O zqK=3pB09s#HGp8kXU9AGVRVQ!GxE>{jNl>@Ky$LPk(3fDNw0XQ-s~l6EQkrJ9yb@I z>xK~$5y<0JjD?3u4o|?21*AGqu#yu#?BHxKm@s6CNq|six!eU7;B;GJLgxTR6and0 zFm&f5s_nYYiy@~O7`;-&tiQtIvN@sTOzv7%_Nz}K*3krG#?6ZY33Ky7%H2yvK# z@xescyqgRC9)SX)Q=GI?1>8mGJe`7Yigpf&Tq0Rsthq2;EgXr9kpY*0qxbi~$8 z-~K=B+1(&L*Zn<%((K2>eaA+|cs*{e4GqA`T+87Bsy)*Iv4!X(|D$=5BSTTVllbgE z_MwsAiSr+Ob30B|3~(LEih-eFf-lC&K0i#v2chTxi=@W>qvXG`1^%WjFv}Vke?pX~ zNQsMviMbhplL3fhu2_Z=Rb!6M&H(Q4Bem9ASQb?Mw+WIG(cFp&Vq?w9l@j`2vKBp-;!oP zFlmnZL4sY|C~7-~kdzQYPQkr|(LaLS2XTjW8=i3sDzU9I$=u%g}(0v}g5zCOM z9zsUZy$J8F!70M%3k8h6hfb^GD9nLggyn8V?vNQyLom)B`xH&K7%baVfZmb===Npd zp+}Zu;MgZP+izi#?h@3U+KH3rMi9)kqNndICikHY$9Mjgz>-ibdSDaA55EUz##*HN zT5!I5f&ir?JiavoR<3WAl5xJ#5rN3yFv92!sM!B5PPC3;YCImn+kcN}FKvNY zW?-z_$1q3;m2dmo(eBegt8~LUu0&F55@HBDo-n(hHc*~DF;YTADYzD<(K265D87m; zen$vWGgFWk7Q{qIN^6Wyl8VR0MQj}t7z4Qu#*yq~2r@F`q2=h==QALS^6l|VHVul7 z!kh)vO{(jKxsMn#34i;guUD?%Hd;V}(Wh;~_nv+Rf%O*TP{QN!t&d?%Q4Ydg1$gzR zKSXF*I}F+60VHlPG$4YrEd$o(kd6Le4Z<|x5{!OL;TDV?t3;4C5tTjvm1qwp9ZO4 z;z4+15x)1z_n>dFA+2~FismLEHhc-5x&J}rCvC+O%P9TQFhqg08;1{XHyAtIR0?rXP=e8NB10vz@;AD5)M0y(E(68j)}hX&Et-$w?B8tmAy z2d4Z4*a%f`YpEve9Iy~ZpIeZO^PQDgvb+H0)cDF=kVg^AGcYVzhLN@tP~{eK22zjC zuyiI9H=r*r7M4LHd?6Z)_Eg|lc{MCNw}PlyC*kOfKT0`bx+pyygD0_nM=4C4lk~Oh z#pf4?5XC_iSpUbn4x^3ex7=kMkcH_PNyvj|l*#%EGGc^RT7uNu`e_FzYVlf2d znuBB!=7w37A1%Gih`v@;k(DPt+_r zIyb-P&skvZMJ23PAP*&(b~@3y8Dt~~N*2H`rSu5si@QlGBiw3oj4Yw zo&5-jiNFvgLz3ns!bO#4amz}_{DhVqHK{t0bqO5Hg1=$M_ALGS|!>18nNVazZBfO-P zQkYwDw#J0j_bkO^$1uXvW6^Qs6a041apWv~6p!AY&%CQ>3^!gtb*~$R`J_z?))GcP zMAnKnWTxgKoD@$%p`^rOo|IPOMN_kp=_Mg3J97cK%hy0lzQ*8aJtq6c5uU8)%+gG9 zfG~<*PC;v!#K}{&NSa%W?3iGfxL)kz+E@f>os7MtwFPl>Ue}SH1OramAN2j_8W7ZoJP-oineO z_mtn=@fP6Bn$L@vS&Jg&`tiM(SYOw9@!^_DQx$`hud=uWb2_60H=D7G+0m^*_!USl zSb*d!8Y$S~70izm#V`7L`Pv1{T{#V@m$vgfioYB~FP-DcKjM6|*-S9Siyy8q>s4(L zH{%AjzG}ZKPbR;YEpUfg;Koq~;kE4J_~^}3Fng2)Za3~2!FSH_lMiEqMDtydqwl4{@yL*$Gf>oP zCX2f`-w0vvE}qYB9>C$F7bqcQk?QX{c@`%GjNaqIU{?b^|6d2CFsYfpn<0`KpRR0y zd3=OGCO?c{!2W%_MmJCD_RuzCqokP<4deHGvGDUGe{ZC9mqP1;mr#7~FJ6@XCsC9& zqf7^|^86FiUwbgh>k!pcY(Ij!Rx{tZarjsJQPWDDFS7P#RIOpNZFlM}dD(~j)cXf&Rz##l%So_MSnv1B2T)~oK4 ziF4d=uw7v{?GcJunhRZ%bZD-4 zq+;9s5in~AqksRuP;1pAn*4-`iF#BWcn2j7!>}1i^Yqd0(Pd9VVa@~{YXm+xatN;2 zWNcoOkA}~Ou=bHSoGqo}vYkf#m;+1heF}2|$I(p0Zhu1;refz~S%ID4kZg<&jbZ7s zC8TN+_tJ%yit`9GBx9ob3@-G9VfB*_A-eAn_M99drPL-QTLl82^G7R@8nYasog)|- zrtVckGXWUE5*xi+Bs3F|r({^nZncrYJs+>U{0f4rhF~JA`d~{Zyz%$pzrFq)7&=Fh zwCF`VyF3=nXD?zHOY!qJzKiTw7fQERVIq*4Sd|w*+CI2VD{`Ch001BWNkl%d6P2=VHsId~|k2Ip4fz-MR;cv@EWoHr1aM+mCZA`-pFTDg;ZxdPvMqp|h zK*Km^NUfD{2c)C3yn-nOk<-pgm^~Qt=%n%@$!z0WkJo>=0mifEQC}8;SAYIvL^juB z+%+S9DcEwd@zVERLsGYkIh;$eazQ4vu55hgsV9)3T7l;udI*yj23YM4$FtYmYxxV= z0(XK1W_3j(hHsnV4=$dg<)$iJF!~S?rIpq+?u5q6ZMefMAV%+QLFO!&)d{C}4pB^U zm<$oj;WF1_-`;~T<;1~GsCqluDwKrLPbi(p%TGdC`*{gQf3CF(Sqt(BGCU4_;R=i} zF*+b`Az9upqAe@~Db5;n#l#YdPhh+{gpP*E%vH6Ry;#4B$xjFL?6j9m;I+dX^ zlL?gV%D;O_3OgKL1G!QI_qF3)|}_uccq z*XeVrS69`pU9|%^!+r*u7P^@+P^KMDhKX}n8N6YzUiT)HLc~-G%x>CM zgccGlahVRBXvYn6vM4N`?TCaig$neaBWPC>{*dFM^`Shoc)++Or|)69wZhwicCi~O z9WZ37ek=2!mjQJbkus?8z`RsmSi|E96nBEJ>%M1`I9Zp^B@!cC)qTfyQgLRP+(ax! zw<$)M%Tq3#^-^nI5M%eDXrx#c3HhKHjL^)~Jiz1nO$~L*=}C=LF%2~>;e*W!5s#^V zI?0Q`pY4&1wr4t8@qwlaYpzOB@t&$j(V+Oo0WvQPS)r!LkuLQP=_vgTYp6T&}%1<-=oa z6=lDy^D(pl^a+RnMe)VKAYkXyk?%zM0~YVpv6UE&)IX_cPRo=s;3|LjFSWii+!@nloXi7x7vg7J z=)p&Okg_`ptq@Y{K20zarV-b^hVRWtcjWyf6<2fSk|?9^I-g}EG={0=$?Qym>#j}z z54>H}+Wg=Qf!jC-z`JCet1j zW}dzHAI?_EEJF~^e?ve(Bkwj)x1s47o-*r;w(>a+|Ge*rJGmAam+EE|fNw2f%sT&=m%osPF55K{>bm+dt-8*gzQP()>d9^}niI(rezCfk1%?B~cT+rWi@(^!-W}mcFR_rcC6|qmZ9HDyKzgjtf5cn1z`~9J-EU zefw(}#O_SPfmi3V24eETw`tKTF1$&1M<>r-X_C8h%Ml4plJ*^;1b#Y_SKXSkUE4ZB$|Fq zWZZ;-mV0LmEAm9q!8ug7lRPZw;e#Iuc^+)ffoPS%98JTWq){(P;xbH&I#n}qGc^>y zHmB`2;S_Ns%hf-8Q+QTI*EJOeu)cB^o$Pv$u4@iB6SFMhuU@YAP$c9+QskH$Zb(y* z3nYDKYA@iJ+2e=|K7x4L26z}=Ywt}68Y*f5niQg(>jJ4#xokFZ#3N(9F%G_urysmE z0C^p)DZ>2juw5gMh~wW_+F?b0qO3hA56%08%yhn%#%g`SwwAN(DrVCV=&dz75ui zzB34MmVq1(ZEly;fZ2j!H-XSeq-FjIKg}Yhw3D)d5<7>V)ulwoPLgCFrG;AP)eXTYj1~<3!YGv7 zsF^Y{yX}E*6@a9KsPZ$@Vg`kcMV$~#QNe&QZJdN18%tM4PDghJS8}`UhO*6@n$V^< zr_P245W?`nW%`)1qbuC+89<}!-8RUolxGVX)ci)1d1Qb6JInoH(xBj0m!+S(fm8j3 z>HYHF2(4l#@4R$~Li8Cenw}1OUZhcjw;(8n%2ppu(fbm=kCB%a?0I=!^Ztw7gio%C zM%iE^2F{Uh>QX;e&7gOf;#~6U9id9XXZypd4I?|c#hZRo&~u5KL**PsU^#`?dn4kV z>JQ1ps@t;-pI`DA(urk5ofmu;xsAnuFgo`kF;5^&o9pRYP-n6pQsKY~WRwUb^agTx z28oC|$1&krDDh+e(yHHDm7tE7*Jf=S!B3lnVXLaL{JC?XS|a7`jh(Y$YDLNL?9C~c zaES1v?~MS;St>7poFpd_b8+0#+Mif|UE`^Umz&hB%R8x&THqJfAoL`wR z@;j@g6e@DScvPG(e5+3*p_zQBOkB{B>(*e!W775Nx><1igKjF~L*x5={UNZ*Ytr{@ z<9;=I;4m#Of2v@@I}|>=)*E@&>q-DNeNejv0+bxGyCra=H))oL9q^_^p73hB7&Nq;IA>3z`rNXlL`C z39Dl}OaD;oTgY&aHv!e8kF5T)US}&ahD!+x=cZ18-`i8gNQBGwWrwq=k^dpcEyX)B zb1NFtsI&wN@)|j8M5{8xoBbg{Y!LR>Rrvk=KoqPi!L%|`leS%N!t9CjzIU)O(CMDV z!}9a=TYt~%_C*~d4dGuA*k<3Ku-5yAg)IF_t*3y}4jm=oZ8K&uI_(kCoTN)aeLq{A zXH0#uf8T{aP&@+}*{^s)#IV~$F_?7Ab)k#f$PxX*n6^@4!=U|t55(ltngv(he13j9 zwP#yi$_CofzJp;_`<@Ud05(P7gb8HC`yhunIGiZ$MW?S zR~qT}Q5gsw5syKIN5C?jqPUpQ68mHhVI?o)z00dpTnlpf)19^97nvL_G%y43LwP69 zt|v-Diagu<$Rf*F{HBq;l2p?-YFeA<;L$Fx8K+om%*f?9w-YGeejOe zX~%_Oq|S|lSXgGu$0Z}WP;8XzB&ig82}oh)#9*fuc#Q+5iE`v6`bJ02v4Ea@JkLrX zX=aDx84uTTaSa3Luma*BoyKS=&%E1dC`nXdtv= zlh&vvV&YjJ<1e+#0LbSWmw4p`Xh|ZeqK%zd37MF^v9u!$Rw0wmG-HVsj2VKKhXQ!o zksJ*HZ-)At@;;Q#9O((ed5%N&uH6z88qGBin3B|ZDM5V6v?GBa*IL{HXZ=J02DF=c zLpF;3QY-o2!ry?R=m@zTTZ~h#I=PWZbZvD6Kc-wW2X>GmzjPh*{}fURupL_%{3BP< z=nqu=b~^8m5@L9ESS}o+`ocj;%Y-sI3($(=r^q&3VHd^gBV}yli#GIDgu`w^Xq4VGImLjhf~Q34sQOO>bBQkZ-!qxZOe~}%D0Y9Xd1B#SQ#tTIKc{$0yE7wrbP$5+(bNniIm@pd? zQ&JPMHbEo9mdllO6A(I6+0h%1J{4Z~G=Syl=~l)_>#2tI~`Nw8*GUr%nQx9wTv<)=>$d^yy;8 zIF3*?2`dkr6aWRw@MR9!Ebh%Fg$i zsw>f|!r~2hh)<~kgAYuW11xV#mgEFK1yBkMKK|m&6#XZWje$R<&;7SX1~W02J4ZLd zBQlk`-{LdQXxN3vD?sfGLYkPTO>gN(GVFRDn6hGgbcN8Uu1Vvp&KZ$nns=;AvvP~P z8@Pa1P6>~ zm8cn*TW!9)NhOI6Upk1PsY0_*9Mz5T+k(AX44K7L@eyQadFHTw%d$_ywAnK|By=-= z|ARM=SzvjR%F2EM7e$X}e3aX*z=`f^w1gL;mW5u#!1CH=j6#-DV-U%R;`iTC&HCZL zicmn{p4!Bym_PSr)+`D+zIp~=wd-HglVvLJh zpc^w$aUS4)Y2gc}Y13MS>AwOT{895yy|zCxWV-g*pksJpDsV=fu!b% z7LJ3+R{fv(Fug!z&D7(fZt!ccHMEg`h6tFvUgH~Ar7^>an_;eKjdbp3+Muw<_;AQv z4tz_-C<2V0S@&Yt^q9URJVAuZ zMW4(dYpi1sT7QG?OY;>oC{tH8dFrFqDW+IfY~3vOvC6Fz;}j- z;6=)NCoWcPZEY!DH@~+oIIm3Rvy^_!{Vhe(_enq;5aphUWXMz7{@J_1xf3@V>+%`7 zhb>6&l$UENG044tqPgLkDjyk92HDJlgl#U)RYT$B>kNiaz$s~w%#?hd#DOVhOg3Gn z!H-S|imvKwSHui$WCk;oV#p;K28$|^JGw0i@%Re77al)(mG0s-#ZDe!S@N*ncT(Q* zqBGl)=+np4t@o7l2cg~}HE4i0KuT%)D}e3PsXn@B&oD^qznC}!-uyePs>EKy_BTj3 zYOxl2QsL5a{TbEna2cmUIQAgwVJ`k5w7I89Y8=3 zK;A2_`p8GCO%{5$$v?%f>Oh}WZBHTd)wl?hS)3kjz+C5Q1QrOJVwn4}-s)ZdD@ z9BDPf9?Z9{B83w|@#o(qabMG_7_>tpU@3B~L1>sFUF21Q8=oWdp*B2h$k>Qmv=P?~_N@}(@WIHX0uI?z zH6(a0uDGIgcvJOyht3Q%%KX8<?f_-tsTv?1q+;2*sna%G*tyzl<`P?PTu;#gUOeY%? z>0cmo9jiuIUNAUL3CM;f1Vb32jcKwjzR&fOmQMJXjn( z-3SYaV@5YAeHj=)_nS+*q zfRP3H?y*gh$q{kVBl=6b%;xRa54pWa1-cm=JSz#Y8sZcEC6rG$gA?+Y+i4%fWMBFY zvK`@B_jeg^tNS4gee1?fjc{}y?4*6dFsBGT`c*uYGuN9|Cr^$m1NNNpko{*&n_Z*q zzd#x)0Y-Wihl{_YXc{gwK>1*PCb`4XQ!3SW+G`3Q6sCQ1=X(W-5`!48eTLksfzZ=a zq{evFy3P25_&3{hZ5l;ZacvATK1w za1|3;rX&@*bl+ zbSWqWX^NLD$F7%A(H7GWn3YR`%b1-%aXAQRMN&F%&mY}bk~BLY%YJS3B|s9%MCDQ0e`GZ7CuAuQ_s31J%A32>psR^r>CjqkK=rWzp_ zxun8*B04_hdg$#H_t)}^%%d#gq9q3GBaoJ*_Zw3)(cFs5MvqItAft3D{H%>I-0uXz zVJwGRlNt*{o9=4n-}TGQr$4U#{lqx)N9cN-z%AW-QsdmfSniVCG)XP#;XJu9X>+P& zqs&pQ)YLB#bcli`!YMX-lzoQ-bK8KT`Z#`Lvs$bVNE0& zl-zAtITr!}gHmz|#@Rs}LNMdJxcR$lpmRF7f212<5KBI5gg`@H2FPT`)&iQ^K9Vyz z=zW(R(x#ylq1FIJ8O$urXdesWy8UwRF`a!BnAmL(`n%#}UGHZ!!3mPQ4Y zA9k&qpgjO@o_(istn^oQjM5oOe6~apU(z6)Pug_tkMn-Xd^)Dc0ioJ$@Up!U@^j1T zgQ4x#j@FeSbS1@E2)!VASsehELO8T^n;O@Y#lf)#k^g7H`E`l5?R%EBKS}=~!QNoM zLU*Ivdu`;*784<%w3c3`Khq9So>`lT&Zw6(1i{m*L>6{i!lneUobKR$-8YF#uO=Tk zYp@VJ4t(aY8|`6_TK^EDF`~UnZ}*CfjlyS`F?KfIiue?EzHPNYR;H5M$T5t$_QED{*WGqo5s(aU7c}U?x$@FfkLD_o0vS-(=jp_}M z?lFCmFE(i-de@*1%N577xZLi7h|-D~eRD&c%C?j8GZ2;Aw^PC`T(*z*r}Ucj-o^gT z7^VWxSw^iD>a~c+`IHUg^O_^fmlOtsPf%4UYT}@?Fq0V44RKuSt=$-@Au8^u$VzRs zLYes9jNo+M_)$g|L_r*CV)dW7bL=h775&Y`=WGa5U4c2bMJ`aG!)A;;DEBe;|HY*O zKk*@vjZ#Of`Ij|x{4AZArcamf$oOP8bFk7Q-c~&venD|@aM<2>ZZ643*RTrJ7o&sz z>W|v-2!7oEUDkWn_-l1f9Bnbe#F#o=Q}zy#b1(k{TTJ3g-~Q6o&CO}m`43gg)N!w^ zg~?vK+5cNdhdQH-T-7r>D@VUBD3`K@$m~(PI0%#O#ze243LC~}wyh)v4(2(6Y8O}E zybBjh5>oDsLYj5{Iq2{n+`{tBt*q>tWErL&{(pP1kNyx{4!!&ac|JHIM5hKGxb0lam2&G51CKbz0&wqi!= z(z1f=LlQ5D+u{U}*a3rC6E@g~d7oc67WP$#w|{mn>`w}`wU%la=KD_$#|wkN4_*kU zzK4{cEU(e_c zv_JlpebQ=hMQxLX=j?5wPY3%yxoMQCB}ldz-eaI>oFw{J|@2U zq^YSi#)d~Z?8;SEW%ed4NPS33bN13scPkQ{`&q(+p*nJ-es8nd;vI_$A{HzJ$_fBK zGSNq7R!Z}mMX!;bi1s~!{|xl#$x7KDq*y|h!7ECeHDh})aT2Lob5uOBE$pp?P)-D0 znA9;Up8bgiMkRphJNw^`5owA+Amz8+?OP@#Jh+E>xMOCWEkny$3DTZ`HlzHoc zyqmB4nhcg{zG3OPz8Es$fDN8m{1bE?!aGkcf|z)7jX>~uM3X?Ib&jFSzWD=zwP|&) zS42^NdFc2UIo7Ow*??ERKzN2d4s`1m+B`-AUd zAa-$Ws$LQpQ7SdcK}fpfK9SOJGFuN1EY92~PR}l(fW1C>bPeISh*;5eIT`#2hL);f zu$y3=+k??An?Y>Rm)oU>K5^2zANG)Pv|Aknp!8Fyhe!YS@0^Aj)GYs?P}2p}#QS8^ zaH5~2pqJ`yfWPIC+Jh7?rL*tGq$3`n-)yoL}s%g462M0jF} z^GcpCFMJ{R&;R-!N9R^AOJYSNRHVsuO|nYqJ`XfZC$2NmlkU)bbw7E-+?p@m1k3Pl z#TMc+r^%2H#Ar7vd*8lrsF?Bd5EkXUVxN^|#M$y}bE}}+_`Wj1#p?CGASxO^3CC{v z=X+doA(}2)nCjY5^ao`gxN`$YqaYAMQ zv0ToWvY=QVjj5mWy*2mq3t}1~eI_nh z>@UXb8p}Aw{51(NrCZm0Anu{x#RXKbRuOGEUxS{b>bp-#Y@9&cmyEY2-5X6%K8FN# z&GJzM$Kd;7TQSRh+{StYykx*8K_tZJDpGRlqmD5gIsm`^1%j(TF$4C^zc|Rc>51^_ ze-MF3WbfPx*p?C^F;=3EQNPr(@)I#o5nlU7Jab9tAX;SehpAAWW06B~iaMLBj2&Wr z^!_qE&1)YRYjeFwg<+VroqH52+4<1Y=Ldv5ulk(rMHcM-*8#Am!8Azw54=o#;@52Z z7cw!wS)=KFElS0`v2l1eZ5Qg!4z4l1zdmR-xnDWYuFCI8Pfwb7gf&7{Hb2k19lKD2 zW**i2YJXXd!72Nq5Q^n9GBF|M=*U{BrkYjjNc)9d(#R#bA2v&xHtvePmR@;zBAh)- z>=g7S?yU63)t4^9J$>2WS>m1M|9WbF(Q%mki>uljY~{S8n7xqUNFQ+Sm(GZ6`};Sr z#`$Q^BBqX>6LGeI|S z>o9mhz<@14^<0C3AdoU`MgI8`*ch!q6{RgH5}Zm!!%#k^6DKGWO6RmwL|V-feQ02M zvpNFla&E7X;Mp$JB;VQ4d1v|G=5(5%n!3pfW@H8p6B531)7+nsRc*3vSn-M1U>+Fi zo;oZO>Du`LY*Y{ha+QcSsUJ_x!8^njgaY{Z8ooEKga82GC2k{Y<=6e$-Gl@TbAyDV7bj+j12agW+upR?huTkFWrvTJ>)TWJ9z#!Lzzz`hUU#R6L{=U z4fao^(D?<1cbZ+~8@vnq(lJfS(epoNzuBzw>)*@QeU;P<%6nYcBONwAw}{lA*k`Q^ z)B-wX3N=R)o}>?WE|Ge{2pW^YzOO$=5g$w94f6H_hd&gD5HIa|dGqFb?182!yhySORu{OYs=ar;L3dL3>2IEq@uN~S}#4nv-YEg?I4+bo+Hlx z4Gc&cdZV~olgAV8@%(J_2CzHiUN-u>x7Yr3Z%_AybN`2*xdvf>xvElf{cA!A zBEOlFm=WcI?qVnG@`+ZWW$&w3!n;pRHhN#FBCL4Eefu5!_&$fJ0=}9my2m-mp$TL| zLPsxx?b&T+uklA7)LMv3tl$4(%4OXu#6c`g#a@i!zicawwNtN20Lg0O8QYY$@^o7u z%UG8ob>EB8)TH%G_+NaC&PFM{ZhJ2ZlndLb zsR$&}91%Z5d*H_E*4&=aYP;p1yYID@|5^ZKzzE?${6Sis+1VZGs}L8$R;`d|%nyx} zYbTI>EpeY!JP?C0KCOi)vK|E>n4o5G71X zyX^A4q?X?u&O$l~q_-G`+eE+#h@4#%35OEF-41y)nSFO*zcQ4=^2+WNwd#58mEHK3 zBeiy#v2mGBKU(v@_`LNG4E4sm=<$7RL63gS%*48JnO@K+T-rbnK95%k>t8K3amnwf zi2aZTJmo~o(8B|8_ads*B&p~eMn6^2l%{vL13(MfzgD%cPekKLJwF$S^S2m6k~SbW zn2u=pE=6U$BVBuc=Yq|V3&p^zsnJ*dMa)n=-B)w3$K%>Jb?f zu@E$M?Lge$Xvlx4_&5NcCsq~4z63OPgz&2~0NggD1sp^hCZkuM?(CF-1oJ}cpPLyt z7T-bkm)gr=<3mZ=C=MpLx|!aN-vuyIU8rhXFi;9m!^4?M+4y6co5^?S9SS9i4G$(1 zq8_wK8T>_yYsN212i=Uv_ozkm-zN8Lt_A;>w@lbVixMjQX5*Z7q1U|f97dAig#Cdv zh{$*1K`S%ZHQ4?BR-;(~5gZ*2Bj$&7Y#`H=U-i3UoQ+9;pZV5%2^Ow?t)#pRvN5w@ zyXMI%w9p}LK@nwngB3a52$nmO+8s9EPS*4dun+9Zshu83-EhKOqoqV*sDn$LRKgk) zb?Q&MqzHlv#oKXpoRpTP4#LpxF%*GebZE+T2i%n58|M09`3tb+r&f!Vj!MjgMUFT@ zcy`B9-kR1?3FuBwuRvJ&(UdPCDZ2!!Ktc&l;F?R>_tb!J7<}TLtp1cWtoi50IT~!y zASZAq)F9ZR-;~#YxM)I%wx3&XCzIXhV1t^!mIKuEg)MI5e_52F1}c(l8zKf5&yqDC zH0g|!`|=V0GSzDFY31GT^`mlb52D}L6Q5n{XF*vF71NRIte`LjATQ!~%Ownnb~~*l z42lz10V%;^kWR-|_L>;t5N`+Ez(i8?RJ?Az(5B!w)`38s`XZuC4T32rC;nj}hqC;* zTHsNa7;6MPd3L8NQ;h!Wr|D0691I?&f5VeWgC@mYQB{VQZH&#G zKFEIk)51DUZYo*hxl~^<6_DQ|K0TJh1S>%9ac<(8h5q(*^z-90p0rC6<#q#N@;Q3Yk-!E(%!*1wef~ Na#D(t)e?pQ{|6@CVCDb- literal 0 HcmV?d00001 From 4344afc09427fd8f069f5e9078a2d07de259396f Mon Sep 17 00:00:00 2001 From: Chris Pyle Date: Thu, 4 Jul 2024 12:59:55 -0400 Subject: [PATCH 2/3] CLDR-17566 text diffs and minor changes --- ...support-intercalary-months-year-cycles.txt | 28 +++++---- .../TEMP-TEXT-FILES/consistent-casing.txt | 16 +++--- .../TEMP-TEXT-FILES/coverage-revision.txt | 8 +-- ...-support-intercalary-months-year-cycles.md | 57 +++++++++++-------- .../design-proposals/coverage-revision.md | 1 + .../currency-code-fallback.md | 2 +- 6 files changed, 62 insertions(+), 50 deletions(-) diff --git a/docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt b/docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt index fae7c96487a..96ae9b55261 100644 --- a/docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt +++ b/docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt @@ -1,4 +1,9 @@ Chinese (and other) calendar support, intercalary months, year cycles +Author Peter Edberg, with info and ideas from many others +Date 2011-11-20 through 2011-11-30, more 2012-01-10 +Status Proposal +Feedback to pedberg (at) apple (dot) com +Bugs See list of tickets at the end of this document Currently the ICU Calendar object has basic support for the Chinese calendar (can determine era, year number, month, etc.). However, real date formatting using this calendar is blocked until CLDR adds necessary support for formatting Chinese calendar dates. In doing this, we need to take into account other calendars that may have similar issues, which we should support in a unified way. The intent here is to provide the minimum change necessary to support the Chinese calendar (and other luni-solar calendars) at the same level as other calendars are currently supported; support for additional special calendar features requiring significant enhancements to the ICU Calendar object (see below) is for future enhancements. A. Relevant calendar features Salient features of the Chinese calendar, and related features of other calendars: @@ -12,7 +17,7 @@ Earthly branches: 子 zǐ, 丑 chǒu, 寅 yín, 卯 mǎo, … Zodiac animals: 鼠 Rat, 牛 Ox, 虎 Tiger, 兔 Rabbit, … First years of 60-year cycle: 甲子 jiǎ-zǐ, 乙丑 yǐ-chǒu, 丙寅 bǐng-yín, 丁卯 dīng-mǎo, … In principle each cycle can be treated as a separate era. However, such eras are not normally ever used in formatted dates, leading to potential ambiguity about which date is being represented. Traditionally this ambiguity could be resolved by also displaying a regnal period or regnal year along with the Chinese calendar date. In modern times this ambiguity is normally resolved by always displaying a Chinese calendar date in conjunction with a date (or at least a year) in at least one other calendar. In Taiwan this other calendar is typically the Minguo/ROC calendar; in Japan it is typically the Japanese calendar; in mainland China and elsewhere it is typically the Gregorian calendar (for a format like “y年U年MMMd日” where y is the Gregorian year and U is the stem-branch name). Note that the year transitions of the associated calendar do not occur at the same time as the year transitions of the Chinese calendar. -There are at least two standard conventions for the epoch of the Chinese calendar — i.e. when was year 1 of era 1. Both are associated with the legendary emperor Huangdi 黃帝, hence the "Huangdi era" 黃帝紀元. The most common convention is to use the beginning of Huangdi's reign, commonly specified as 2697 BCE; a somewhat less common convention (and the one used by ICU) is to use the year when he supposedly invented the Chinese calendar, 2637 BCE. Since the latter is 60 years later, the stem-branch names associated with years do not change, but the cycle number is different. For some usages among calendar specialists Chinese calendar years may be numbered continuously from the beginning of the epoch, in which case Gregorian 2012 Jan. 23 is the beginning of Chinese calendar year 4650 or 4710 depending on which convention is used. However this kind of year numbering is not widely known. +There are at least two standard conventions for the epoch of the Chinese calendar — i.e. when was year 1 of era 1. Both are associated with the legendary emperor Huangdi 黃帝, hence the "Huangdi era" 黃帝紀元. The most common convention is to use the beginning of Huangdi's reign, commonly specified as 2697 BCE; a somewhat less common convention (and the one used by ICU) is to use the year when he supposedly invented the Chinese calendar, 2637 BCE. Since the latter is 60 years later, the stem-branch names associated with years do not change, but the cycle number is different. For some usages among calendar specialists Chinese calendar years may be numbered continuously from the beginning of the epoch, in which case Gregorian 2012 Jan. 23 is the beginning of Chinese calendar year 4650 or 4710 depending on which convention is used. However this kind of year numbering is not widely known. In Chinese the days of the month have special numbering. Days 1-10 use 初一, 初二, … 初十. For days 21-29 the number is formed using 廿 instead of 二十 to indicate 20. The first month is designated 正月 instead of 一月. 2. Other calendars related to the Chinese calendar (Japanese, Korean, Vietnamese) Similar luni-solar calendars are used in Japanese, Korean, and Vietnamese, with the computations based respectively on meridians near Tokyo, Seoul, and Hanoi. For the Japanese version, the date typically used for disambiguation would be a Japanese calendar date, not a Gregorian date. The Vietnamese calendar uses a different set of animals for the branch names in years, and the marker for intercalary month is inserted *after* the month name, not before. @@ -54,7 +59,7 @@ E. Current CLDR support CLDR currently provides the following: 1. yeartype attribute The yeartype attribute for month name elements allows an alternate month name to be selected for leap years (current legal values are just “standard”—the default—and “leap”). It is only used for the Hebrew calendar, as follows: -Shevat Adar I Adar Adar II +Shevat Adar I Adar Adar II This works with the normal MMM+/LLL+ pattern characters for months; the choice of which name to use is managed by ICU date formatting code. Note that this yeartype month is currently mapped into ICU month name data as the 14th element in the array of Hebrew month names, which seems a bit hacky. 2. special pattern character ‘l’ @@ -68,7 +73,7 @@ F. Proposal Items 1-2 and 5-8 below are probably do-able for CLDR 21 and ICU 49. The others may come later. 1. ICU behavior for months The Hebrew model of explicitly numbering all month names and skipping leap months in non-leap years does not work well for calendars like Chinese and Hindu that may insert leap months anywhere (and may combine months, etc.). The use of the UCAL_IS_LEAP_MONTH field is better suited to this. -For choosing the correct month name variant, I had proposed the idea of enhancing the UCAL_IS_LEAP_MONTH field to have 4 values, and adding an enum for these values: +For choosing the correct month name variant, I had proposed the idea of enhancing the UCAL_IS_LEAP_MONTH field to have 4 values, and adding an enum for these values: normal month, this is currently value 0 for UCAL_IS_LEAP_MONTH leap month (for Chinese, this has the same month number as the month before; for Hindu & TIbetan, it has the same number as the month after), this is currently value 1 for UCAL_IS_LEAP_MONTH normal month after leap month (needed for Hindu & Tibetan); this could be value -1 for UCAL_IS_LEAP_MONTH (it is not a leap month, but does need a special name) @@ -85,16 +90,15 @@ Current idea Alongside the element, permit an optional parallel element (only present for calendars that need it). The structure under this is similar to that for , except that: The element's type attribute that takes one of three values: "format", "stand-alone", or the added "numeric" (pattern to use with numeric months). The element's type attribute can take an additional value "all" for use with the "numeric" context (since there is no width distinction for numeric months). -The elements can have type "leap", "standardAfterLeap", or "combined"; the value is the pattern used for modifying the month name(s) to indicate that month type. -A Chinese calendar example (marker before the month name) in root: - (default alias to format/wide) (default alias to stand-alone/narrow) {0}bis (default alias to format/abbreviated) {0}bis (default alias to format/wide) {0}bis +The elements can have type "leap", "standardAfterLeap", or "combined"; the value is the pattern used for modifying the month name(s) to indicate that month type. A Chinese calendar example (marker before the month name) in root: + (default alias to format/wide) (default alias to stand-alone/narrow) {0}bis (default alias to format/abbreviated) {0}bis (default alias to format/wide) {0}bis And in the Chinese locale: - 闰{0} 闰{0} 闰{0} + 闰{0} 闰{0} 闰{0} For other calendars, the elements above could be replaced by others such as the following: For the Hebrew calendar, in the Hebrew locale, one could have (for Adar I and II): -{0} א׳ {0} ב׳ +{0} א׳ {0} ב׳ For the Hindu calendar, in root (for a combined month, the name will be an affix plus a combination of two month names): -adhik {0} nija {0} kshay {0}-{1} +adhik {0} nija {0} kshay {0}-{1} For the time being, at least, I don't think that we need to present this in the Survey Tool, and that may prove too complex and confusing anyway. 3. Month name styles (mostly about data, some ideas for future structure requirements): @@ -116,14 +120,14 @@ If it occurs in a pattern it should be ignored. Option 1, element (The following was originally agreed in CLDR 2011-11-16; however, it has been superseded by option 2, which was approved on 2011-11-30). Add a element and sub-elements parallel to the current structure for , , and , as follows (with similar structure in ICU): - Jia-Zi Yi-Chou … Gui-Hai (defaults to abbreviated) (defaults to abbreviated) + Jia-Zi Yi-Chou … Gui-Hai (defaults to abbreviated) (defaults to abbreviated) Only the “format” context would be supported initially; other contexts could be added if needed. Option 2, element (approved in CLDR meeting 2011-11-30) As noted above, the cycle of 60 stem-branch names is used for months and days as well as years. Years as are also known according to the cycle of 12 zodiac animals associated with the branch portion of the stem-branch name. A cycle of 12 branch names is also used for subdivisions of a day. Thus, it would be beneficial to have a more general representation of such name cycles, even though cyclic names for months, days, and day subdivisions are not part of the current proposal. In one of his comments on #1507, Philippe Verdy mentions that the cycle of 60 names is also used for some non-calendrical enumerations in Chinese such as measurement of angles, and suggests that data for this should be independent of the calendar structure. These notions are specific to the Chinese locale, and are not notions that CLDR would support across multiple locales (unlike the Chinese calendar, which is supported across multiple locales), so it probably does not make sense to add CLDR structure for them. The following proposes a ways to support cyclic names for years, zodiac mappings, months, days, and dayParts (not really the same as dayPeriods), with the currently-known cycles of length 60 or 12 (for the Chinese, Hindu, and related calendars); this structure would be just below the element: - jia-zi yi-chou … gui-hai < cyclicNameWidth type=”narrow”> (defaults to abbreviated) < cyclicNameWidth type=”wide”> (defaults to abbreviated) (root aliases to years) (root aliases to dayParts) …data for branch names... (root aliases to dayParts, some locales will supply separate data) + jia-zi yi-chou … gui-hai < cyclicNameWidth type=”narrow”> (defaults to abbreviated) < cyclicNameWidth type=”wide”> (defaults to abbreviated) (root aliases to years) (root aliases to dayParts) …data for branch names... (root aliases to dayParts, some locales will supply separate data) As with the leap month data, this may not be appropriate for the Survey Tool. 7. New pattern character(s) We would need to add a pattern character to indicate year name. A natural choice is ‘U’ since it is currently unused and ‘u’ is already used for a different year type. @@ -133,7 +137,7 @@ Parsing (month names, year names)... (to be supplied) ICU4J ChineseDateFormat class, move relevant behaviors into SimpleDateFormat, leaving this as mostly a shell. Remove ChineseDateFormatSymbols use of "isLeapMonth" resource; instead derive the necessary data (needed only for backwards compatibility) from the monthPatterns data. 9. ICU API enhancements Add a calendar field IS_EXTRA_HOUR or IS_REPEATED_HOUR to disambiguate the hour added/repeated during DST transitions that set the clock back. -Work out how and whether to map the modified month names (for leap month types) onto APIs that get date format symbols — use additional options to specify month symbol types? What about symbols for year names? +Work out how and whether to map the modified month names (for leap month types) onto APIs that get date format symbols — use additional options to specify month symbol types? What about symbols for year names? Add Calendar API to answer the following questions for a given year and era: Is it a leap year? And if so… Of what type - does it adjust days or months? diff --git a/docs/site/TEMP-TEXT-FILES/consistent-casing.txt b/docs/site/TEMP-TEXT-FILES/consistent-casing.txt index eae1e17a52c..48bb22f35dc 100644 --- a/docs/site/TEMP-TEXT-FILES/consistent-casing.txt +++ b/docs/site/TEMP-TEXT-FILES/consistent-casing.txt @@ -48,15 +48,15 @@ In certain circumstances, one or more elements do not follow the rule of the maj The example below indicates that variant names are normally lower case with one exception. lowercase-words -ortografia tradizionale tedesca -ortografia tedesca del 1996 -dialetto del Natisone + ortografia tradizionale tedesca + ortografia tedesca del 1996 + dialetto del Natisone Improved Testing As a part of bug http://www.unicode.org/cldr/bugs-private/locale-bugs-private/data?id=2227, I added a consistency test for casing. It just generates warnings for now, and the test is very simple: given a bucket of translations (eg language names), verify that everything have the same first-letter casing as the first item. Although simple (and not bulletproof!), it is revealing... -cs [Czech] warning names|language|lb 〈Luxembourgish〉 【】 〈Lucemburština〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). -cs [Czech] warning names|language|om 〈Oromo〉 【】 〈Oromo (Afan)〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). -cs [Czech] warning names|language|ps 〈Pashto〉 【】 〈Pashto (Pushto)〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). +cs [Czech] warning names|language|lb 〈Luxembourgish〉 【】 〈Lucemburština〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). +cs [Czech] warning names|language|om 〈Oromo〉 【】 〈Oromo (Afan)〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). +cs [Czech] warning names|language|ps 〈Pashto〉 【】 〈Pashto (Pushto)〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). I didn't use the inText or inList data, because I don't think we have enough data, nor that it has been vetted enough, to be reliable. Moreover, I don't think the buckes it uses are fine-grained enough.. I put the test output in 3 different files in http://www.unicode.org/cldr/data/dropbox/casing/ The code is at http://www.unicode.org/cldr/data/tools/java/org/unicode/cldr/test/CheckConsistentCasing.java. Note that the buckets I used are defined in the code in typesICareAbout in the code. Feedback and Open Issues @@ -71,8 +71,8 @@ Determining whether current structure is sufficient The attached "CasingContexts.pdf" is a first draft of a doc providing examples of various contexts for usage of date formats and date elements, language names, region names, and names of various other CLDR keys. This document is somewhat oriented to Mac OS X (since those were the examples at hand), so I would like to solicit other type of examples that may cover situations not depicted here. Suggestions welcome! What I hope to do with this (and very soon) is to send it out to localizers to solicit either sample translations for each item in context (so I can infer the various grammatical cases and capitalization cases that CLDR may need to support), or better yet, have the localizers let me know about all of the cases that are necessary. With that information I hope to: -1. Determine what additional types (beyond form,at and standalone) may be necessary for date formatting, and -2. See whether inText/inList are adequate to cover the capitalization cases, and if not, try to come up with something better. +Determine what additional types (beyond form,at and standalone) may be necessary for date formatting, and +See whether inText/inList are adequate to cover the capitalization cases, and if not, try to come up with something better. (from Peter E., 2009 Nov 22) I have attached "CasingContextsV2.pdf" which fixes the calendar menu example (thanks Kent!) and adds examples of currencies in text and various examples of units in text. I still need to add an example of currency in a dialog, along with overall instructions. (from Peter E., 2009 Nov 25) diff --git a/docs/site/TEMP-TEXT-FILES/coverage-revision.txt b/docs/site/TEMP-TEXT-FILES/coverage-revision.txt index 65503167567..e5d06534ee5 100644 --- a/docs/site/TEMP-TEXT-FILES/coverage-revision.txt +++ b/docs/site/TEMP-TEXT-FILES/coverage-revision.txt @@ -1,5 +1,5 @@ Coverage Revision -1. Propose changing CoverageLevel to be data driven. Rough thoughts. +Propose changing CoverageLevel to be data driven. Rough thoughts. Have a list of paths - ​/​/ldml​/identity​/version => NONE - ... @@ -11,7 +11,7 @@ this language this language's countries this language's territories ... -2. Current coverage: needs review +Current coverage: needs review I put the tentative results in http://spreadsheets.google.com/pub?key=t5UzIpaSqcYBksSMtZp-f7Q&output=html The more detailed files are in http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/. In particular: http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/summary.txt @@ -27,8 +27,8 @@ I've been doing some more thinking about how to deal with coverage in CLDR. It s 2). Allow individual users to set the filtering in the survey tool based on one of the predefinedcoverage levels as we already have in the spec, or actually any other numeric coverage level that they desire. So with this in mind, I would like to propose the following structure to be added to the supplemental metadata: - - +  +  .... Finding the appropriate coverage level value would then be a matter of searching the coverageLevel entries in numeric order by value looking for a match of the path vs. "//ldml/" + "regular expression". In other words, we would not specifically include "//ldml" in the expressions, since they would all start with that. Once a given xpath's coverage level value was determined, it shouldn't be too hard for us to simply filter out fields whose coverage level was higher then the requested. I suppose that we will need some wildcards similar to what Mark has started working on in his path filtering proposal. \ No newline at end of file diff --git a/docs/site/development/development-process/design-proposals/chinese-and-other-calendar-support-intercalary-months-year-cycles.md b/docs/site/development/development-process/design-proposals/chinese-and-other-calendar-support-intercalary-months-year-cycles.md index e1872269992..f99b75f25a8 100644 --- a/docs/site/development/development-process/design-proposals/chinese-and-other-calendar-support-intercalary-months-year-cycles.md +++ b/docs/site/development/development-process/design-proposals/chinese-and-other-calendar-support-intercalary-months-year-cycles.md @@ -74,7 +74,9 @@ Months are numbered 0-11 (the zero-based value of UCAL\_MONTH). When an intercal For purposes of add and set operations, month is treated as a tuple represented by UCAL\_MONTH and UCAL\_IS\_LEAP\_MONTH. If UCAL\_IS\_LEAP\_MONTH is 0 for a month that has a leap month following, then adding 1 month, or setting UCAL\_IS\_LEAP\_MONTH to 1, sets the calendar to the leap month (which has the same value for UCAL\_MONTH). If a month does not have a leap month following, then a set of UCAL\_IS\_LEAP\_MONTH to 1 is ignored. -Years are numbered 1-60 (the value of UCAL\_YEAR) for each 60-year cycle. The era is incremented for each 60-year cycle, so we are currently in era 78. Current ICU4C formatting for the Chinese calendar is completely broken. For example, the short date format in root and zh is currently “y'x'G-Ml-d”; the result this produces for Chinese era 78, year 29, month 4 (non-leap or leap), day 2 is “29x-4-”: There is no era value or leap month indicator, and non-literal fields after the ‘l’ pattern character are skipped. +Years are numbered 1-60 (the value of UCAL\_YEAR) for each 60-year cycle. The era is incremented for each 60-year cycle, so we are currently in era 78. + +Current ICU4C formatting for the Chinese calendar is completely broken. For example, the short date format in root and zh is currently “y'x'G-Ml-d”; the result this produces for Chinese era 78, year 29, month 4 (non-leap or leap), day 2 is “29x-4-”: There is no era value or leap month indicator, and non-literal fields after the ‘l’ pattern character are skipped. In ICU4J the existing situation is bit better. Via data in data/xml/main/root.xml, ICU inserts its own "isLeapMonth" resource into the calendar bundle for "chinese"; this provides a leapMonthMarker of "\*". There is a public ChineseDateFormatSymbols subclass of DateFormatSymbols which uses the "isLeapMonth" resource, and a public ChineseDateFormat of SimpleDateFormat; using ChineseDateFormat, Chinese calendar date formats using 'G' and 'l' can be formatted and parsed successfully. @@ -84,7 +86,9 @@ In a non-leap year, months run 0-4 (for months Tishri-Shevat), skip 5 (“Adar I ### 3. Coptic and Ethiopic calendars -Months are numbered 0-12. ### 4. Other calendars listed above +Months are numbered 0-12. + +### 4. Other calendars listed above ICU does not currently support the Hindu, Vietnamese, or Tibetan calendars (it does support the quite different Indian Civil calendar). @@ -117,6 +121,7 @@ The special pattern character ‘l’ (small L) is described as: “Special symb - There is currently no structure in CLDR to provide the value for ‘l’. But assuming we added it… - It is not clear how a client who wants month symbol names can get the name for a leap month - do they need to assemble it from two pieces? How would they know what order to use? - It is not clear why this mechanism needs to be different than the mechanism used for the Hebrew calendar. + It seems unnecessary; the month naming could just be handled via the MMM+/LLL+ pattern, and CLDR data could provide complete month names both with and without the marker (distinguished using the something like the yeartype attribute). This would fit more smoothly into existing mechanisms. ## F. Proposal @@ -168,9 +173,11 @@ And in the Chinese locale: For other calendars, the \ elements above could be replaced by others such as the following: - For the Hebrew calendar, in the Hebrew locale, one could have (for Adar I and II): + \{0} א׳\ \{0} ב׳\ - For the Hindu calendar, in root (for a combined month, the name will be an affix plus a combination of two month names): + \adhik {0}\ \nija {0}\ \kshay {0}-{1}\ For the time being, at least, I don't think that we need to present this in the Survey Tool, and that may prove too complex and confusing anyway. @@ -206,7 +213,7 @@ Option 1, \ element Add a \ element and sub-elements parallel to the current structure for \, \, and \, as follows (with similar structure in ICU): - \ \ \ \Jia-Zi\ \Yi-Chou\ … \Gui-Hai\ \ \ (defaults to abbreviated) \ \ (defaults to abbreviated) \ \ \ +\ \ \ \Jia-Zi\ \Yi-Chou\ … \Gui-Hai\ \ \ (defaults to abbreviated) \ \ (defaults to abbreviated) \ \ \ Only the “format” context would be supported initially; other contexts could be added if needed. @@ -268,32 +275,32 @@ Note that the convention of using a secondary calendar associated with a traditi The old CLDR and ICU tickets related to this are: -- CLDR[#1507](http://unicode.org/cldr/trac/ticket/1507): intercalary marker missing from chinese calendar (refile) [includes detailed comments from Philippe Verdy, some anticipating ideas above] -- CLDR[#2430](http://unicode.org/cldr/trac/ticket/2430): Illegal date-time field "l". -- CLDR[#2558](http://unicode.org/cldr/trac/ticket/2558): Chinese calendar formatting does not look right -- CLDR[#3672](http://unicode.org/cldr/trac/ticket/3672): Value inherited from "root" is in error -- ICU[#6049](http://bugs.icu-project.org/trac/ticket/6049): Intercalary markers +- CLDR [#1507](http://unicode.org/cldr/trac/ticket/1507): intercalary marker missing from chinese calendar (refile) [includes detailed comments from Philippe Verdy, some anticipating ideas above] +- CLDR [#2430](http://unicode.org/cldr/trac/ticket/2430): Illegal date-time field "l". +- CLDR [#2558](http://unicode.org/cldr/trac/ticket/2558): Chinese calendar formatting does not look right +- CLDR [#3672](http://unicode.org/cldr/trac/ticket/3672): Value inherited from "root" is in error +- ICU [#6049](http://bugs.icu-project.org/trac/ticket/6049): Intercalary markers New tickets related to this, which supersede the above, are: -- CLDR[#4230](http://unicode.org/cldr/trac/ticket/4230): Add \ element for Chinese calendar support +- CLDR [#4230](http://unicode.org/cldr/trac/ticket/4230): Add \ element for Chinese calendar support - CLDR [#4231](http://unicode.org/cldr/trac/ticket/4231): Add cyclic year name support for Chinese calendar -- CLDR[#4232](http://unicode.org/cldr/trac/ticket/4232): Deprecate pattern character 'l', add pattern character 'U' -- CLDR[#](http://goog_1707162891)[4237](http://unicode.org/cldr/trac/ticket/4237): Change Chinese calendar formats to use 'U' pattern char [must wait for ICU format/parse support] -- CLDR[#4259](http://unicode.org/cldr/trac/ticket/4259): Chinese calendar data updates +- CLDR [#4232](http://unicode.org/cldr/trac/ticket/4232): Deprecate pattern character 'l', add pattern character 'U' +- CLDR [#](http://goog_1707162891)[4237](http://unicode.org/cldr/trac/ticket/4237): Change Chinese calendar formats to use 'U' pattern char [must wait for ICU format/parse support] +- CLDR [#4259](http://unicode.org/cldr/trac/ticket/4259): Chinese calendar data updates - CLDR [#4277](http://unicode.org/cldr/trac/ticket/4277): Remove \ processing from LDML2ICUConverter -- CLDR[#4282](http://unicode.org/cldr/trac/ticket/4282): Chinese calendar formats need era, Gregorian year, or ? -- CLDR[#4302](http://unicode.org/cldr/trac/ticket/4302): Fix spurious errors with chinese calendar (monthPatterns narrow, prettyPaths) -- CLDR[#4321](http://unicode.org/cldr/trac/ticket/4321): Skip some date pattern tests for Chinese calendar ('U' and other differences from std) -- CLDR[#4322](http://unicode.org/cldr/trac/ticket/4322): Fix test errors for monthPatterns -- CLDR[#4325](http://unicode.org/cldr/trac/ticket/4325): Fix test errors for date patterns using U (availableFormats...) -- ICU[#8958](http://bugs.icu-project.org/trac/ticket/8958): Use CLDR \ data to format/parse Chinese cal dates -- ICU[#8977](http://bugs.icu-project.org/trac/ticket/8977): Use CLDR \ data to format/parse Chinese cal dates (J) -- ICU[#8959](http://bugs.icu-project.org/trac/ticket/8959): Support new 'U' pattern char for formatting/parsing Chinese cal dates -- ICU[#9034](http://bugs.icu-project.org/trac/ticket/9034): Delete obsolete \ in data/xml/main/root.xml -- ICU[#9035](http://bugs.icu-project.org/trac/ticket/9035): More ICU4C chinese calendar format/parse fixes -- ICU[#9043](http://bugs.icu-project.org/trac/ticket/9043): Chinese cal dates can't always be parsed - design 2-cal solution -- ICU[#9044](http://bugs.icu-project.org/trac/ticket/9044): Chinese cal dates can't always be parsed - document & fix tests -- ICU[#9055](http://bugs.icu-project.org/trac/ticket/9055): Integrate Chinese cal pattern updates (cldrbug 4237), update tests +- CLDR [#4282](http://unicode.org/cldr/trac/ticket/4282): Chinese calendar formats need era, Gregorian year, or ? +- CLDR [#4302](http://unicode.org/cldr/trac/ticket/4302): Fix spurious errors with chinese calendar (monthPatterns narrow, prettyPaths) +- CLDR [#4321](http://unicode.org/cldr/trac/ticket/4321): Skip some date pattern tests for Chinese calendar ('U' and other differences from std) +- CLDR [#4322](http://unicode.org/cldr/trac/ticket/4322): Fix test errors for monthPatterns +- CLDR [#4325](http://unicode.org/cldr/trac/ticket/4325): Fix test errors for date patterns using U (availableFormats...) +- ICU [#8958](http://bugs.icu-project.org/trac/ticket/8958): Use CLDR \ data to format/parse Chinese cal dates +- ICU [#8977](http://bugs.icu-project.org/trac/ticket/8977): Use CLDR \ data to format/parse Chinese cal dates (J) +- ICU [#8959](http://bugs.icu-project.org/trac/ticket/8959): Support new 'U' pattern char for formatting/parsing Chinese cal dates +- ICU [#9034](http://bugs.icu-project.org/trac/ticket/9034): Delete obsolete \ in data/xml/main/root.xml +- ICU [#9035](http://bugs.icu-project.org/trac/ticket/9035): More ICU4C chinese calendar format/parse fixes +- ICU [#9043](http://bugs.icu-project.org/trac/ticket/9043): Chinese cal dates can't always be parsed - design 2-cal solution +- ICU [#9044](http://bugs.icu-project.org/trac/ticket/9044): Chinese cal dates can't always be parsed - document & fix tests +- ICU [#9055](http://bugs.icu-project.org/trac/ticket/9055): Integrate Chinese cal pattern updates (cldrbug 4237), update tests ![Unicode copyright](https://www.unicode.org/img/hb_notice.gif) \ No newline at end of file diff --git a/docs/site/development/development-process/design-proposals/coverage-revision.md b/docs/site/development/development-process/design-proposals/coverage-revision.md index 2c1efcbb132..8a3a4233ad1 100644 --- a/docs/site/development/development-process/design-proposals/coverage-revision.md +++ b/docs/site/development/development-process/design-proposals/coverage-revision.md @@ -47,6 +47,7 @@ I've been doing some more thinking about how to deal with coverage in CLDR. It s 1). Filter out fields from the ST that we don't really need, since everything we do would be filtered based on a desired coverage level. 2). Allow individual users to set the filtering in the survey tool based on one of the predefinedcoverage levels as we already have in the spec, or actually any other numeric coverage level that they desire. + So with this in mind, I would like to propose the following structure to be added to the supplemental metadata: \ diff --git a/docs/site/development/development-process/design-proposals/currency-code-fallback.md b/docs/site/development/development-process/design-proposals/currency-code-fallback.md index 77e7bb3c7c8..b240c511125 100644 --- a/docs/site/development/development-process/design-proposals/currency-code-fallback.md +++ b/docs/site/development/development-process/design-proposals/currency-code-fallback.md @@ -19,7 +19,7 @@ Here are some recommendations. 1. We don't have the character fallback element for any currency symbol that is used for different currency codes. That is, it is ok to have EUR for €, but not ok to use KRW for ₩, since ₩ is also used for KPW, and not to have JAY for ¥, since ¥ is also used for CNY. 2. Even with this, we don't really want to use character fallback elements for currency substitution in general, since it is too coarse. -3. We should try to remove all the currency symbols that use Unicode symbol characters from the locales, except where they have special plurals, or where we have symbol reversals (eg in the US, $ for USD and C$ for CAD, while in CA, $ for CAD and US$ for USD). +3. We should try to remove all the currency symbols that use Unicode symbol characters from the locales, except where they have special plurals, or where we have symbol reversals (eg in the US, \$ for USD and C\$ for CAD, while in CA, \$ for CAD and US\$ for USD). Options From 50d1c44cbb30ef0ed6dc32696b6e20a86ca58bef Mon Sep 17 00:00:00 2001 From: Chris Pyle Date: Thu, 4 Jul 2024 13:00:31 -0400 Subject: [PATCH 3/3] CLDR-17566 removing text diffs --- docs/site/TEMP-TEXT-FILES/change-to-sites.txt | 38 ---- ...support-intercalary-months-year-cycles.txt | 183 ------------------ .../TEMP-TEXT-FILES/consistent-casing.txt | 79 -------- .../TEMP-TEXT-FILES/coverage-revision.txt | 34 ---- .../currency-code-fallback.txt | 17 -- 5 files changed, 351 deletions(-) delete mode 100644 docs/site/TEMP-TEXT-FILES/change-to-sites.txt delete mode 100644 docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt delete mode 100644 docs/site/TEMP-TEXT-FILES/consistent-casing.txt delete mode 100644 docs/site/TEMP-TEXT-FILES/coverage-revision.txt delete mode 100644 docs/site/TEMP-TEXT-FILES/currency-code-fallback.txt diff --git a/docs/site/TEMP-TEXT-FILES/change-to-sites.txt b/docs/site/TEMP-TEXT-FILES/change-to-sites.txt deleted file mode 100644 index a44dffd5759..00000000000 --- a/docs/site/TEMP-TEXT-FILES/change-to-sites.txt +++ /dev/null @@ -1,38 +0,0 @@ -Change to Sites? -We are using Sites (http://cldr.unicode.org/) to host all of the CLDR development web pages. I took a look at the cldr pages, and the following are not in Sites. The question is, should we move them (or some of them) to Sites? -Advantages -Removing a bottleneck. Even though we have them in CVS (so the project people can edit the repository copies of them), we have a bottleneck in that only a small number of people (Rick, Steven, and me) can actually post them up publicly. -Editing doesn't require an HTML editor. -Disadvantages -The look and feel is somewhat different than the regular Unicode site (although we should be able to make it closer over time). -Files -http://www.unicode.org/cldr/beta.html -http://www.unicode.org/cldr/comparison_charts.html -http://www.unicode.org/cldr/corrigenda.html -http://www.unicode.org/cldr/index.html -http://www.unicode.org/cldr/filing_bug_reports.html -http://www.unicode.org/cldr/locale_faq.html -http://www.unicode.org/cldr/process.html -http://www.unicode.org/cldr/transliteration_guidelines.html -http://www.unicode.org/cldr/terms.html -http://www.unicode.org/cldr/survey_tool.html -http://www.unicode.org/cldr/repository_access.html -http://www.unicode.org/cldr/version/ (version pages) -Here are the other files: -Special purpose, for redirecting. -http://www.unicode.org/cldr/header.html -Old or temporary page: -http://www.unicode.org/cldr/readme.txt -http://www.unicode.org/cldr/press.html -Already redirect, some to Docs pages -http://www.unicode.org/cldr/big_red_switch.html -http://www.unicode.org/cldr/charts.html -http://www.unicode.org/cldr/data_formats.html -http://www.unicode.org/cldr/errata.html -http://www.unicode.org/cldr/procedures.html -http://www.unicode.org/cldr/tr35.html -http://www.unicode.org/cldr/timezone_ids.html -http://www.unicode.org/cldr/survey_tool_known_bugs.html -http://www.unicode.org/cldr/vetting.html -http://www.unicode.org/cldr/xmlGuide.html -Possible Bug - needs investigation. \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt b/docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt deleted file mode 100644 index 96ae9b55261..00000000000 --- a/docs/site/TEMP-TEXT-FILES/chinese-and-other-calendar-support-intercalary-months-year-cycles.txt +++ /dev/null @@ -1,183 +0,0 @@ -Chinese (and other) calendar support, intercalary months, year cycles -Author Peter Edberg, with info and ideas from many others -Date 2011-11-20 through 2011-11-30, more 2012-01-10 -Status Proposal -Feedback to pedberg (at) apple (dot) com -Bugs See list of tickets at the end of this document -Currently the ICU Calendar object has basic support for the Chinese calendar (can determine era, year number, month, etc.). However, real date formatting using this calendar is blocked until CLDR adds necessary support for formatting Chinese calendar dates. In doing this, we need to take into account other calendars that may have similar issues, which we should support in a unified way. The intent here is to provide the minimum change necessary to support the Chinese calendar (and other luni-solar calendars) at the same level as other calendars are currently supported; support for additional special calendar features requiring significant enhancements to the ICU Calendar object (see below) is for future enhancements. -A. Relevant calendar features -Salient features of the Chinese calendar, and related features of other calendars: -1. Chinese luni-solar calendar -Months begin at a new moon and are 29 or 30 days long. -A year consists of 12 or 13 months (determined by the number of new moons between winter solstices). Months are numbered 1-12. When an extra intercalary month is needed, it might be inserted after any of the standard months 2-11 (after 11 is unusual); it repeats the numbering of the preceding month, with an extra marker to indicate that it is a leap month (in Chinese this marker ‘闰’ precedes the month number). An astronomical rule determines whether and where it gets inserted in a given year. The winter solstice always occurs during month 11, so the new year (and month 1) usually begins on the second new moon after that (Unless month 11 has a leap month added). -Astronomical calculations are based on a meridian of 120° (near Beijing). -Years are named using a 60-year cycle. The year name is formed by combining a celestial stem from a 10-year cycle and an earthly branch from a 12-year cycle. The 12 earthly branches correspond to, but do not have the same names as, the 12 zodiac animals associated with them. For example: -Celestial stems: 甲 jiǎ, 乙 yǐ, 丙 bǐng, 丁 dīng, … -Earthly branches: 子 zǐ, 丑 chǒu, 寅 yín, 卯 mǎo, … -Zodiac animals: 鼠 Rat, 牛 Ox, 虎 Tiger, 兔 Rabbit, … -First years of 60-year cycle: 甲子 jiǎ-zǐ, 乙丑 yǐ-chǒu, 丙寅 bǐng-yín, 丁卯 dīng-mǎo, … -In principle each cycle can be treated as a separate era. However, such eras are not normally ever used in formatted dates, leading to potential ambiguity about which date is being represented. Traditionally this ambiguity could be resolved by also displaying a regnal period or regnal year along with the Chinese calendar date. In modern times this ambiguity is normally resolved by always displaying a Chinese calendar date in conjunction with a date (or at least a year) in at least one other calendar. In Taiwan this other calendar is typically the Minguo/ROC calendar; in Japan it is typically the Japanese calendar; in mainland China and elsewhere it is typically the Gregorian calendar (for a format like “y年U年MMMd日” where y is the Gregorian year and U is the stem-branch name). Note that the year transitions of the associated calendar do not occur at the same time as the year transitions of the Chinese calendar. -There are at least two standard conventions for the epoch of the Chinese calendar — i.e. when was year 1 of era 1. Both are associated with the legendary emperor Huangdi 黃帝, hence the "Huangdi era" 黃帝紀元. The most common convention is to use the beginning of Huangdi's reign, commonly specified as 2697 BCE; a somewhat less common convention (and the one used by ICU) is to use the year when he supposedly invented the Chinese calendar, 2637 BCE. Since the latter is 60 years later, the stem-branch names associated with years do not change, but the cycle number is different. For some usages among calendar specialists Chinese calendar years may be numbered continuously from the beginning of the epoch, in which case Gregorian 2012 Jan. 23 is the beginning of Chinese calendar year 4650 or 4710 depending on which convention is used. However this kind of year numbering is not widely known. -In Chinese the days of the month have special numbering. Days 1-10 use 初一, 初二, … 初十. For days 21-29 the number is formed using 廿 instead of 二十 to indicate 20. The first month is designated 正月 instead of 一月. -2. Other calendars related to the Chinese calendar (Japanese, Korean, Vietnamese) -Similar luni-solar calendars are used in Japanese, Korean, and Vietnamese, with the computations based respectively on meridians near Tokyo, Seoul, and Hanoi. For the Japanese version, the date typically used for disambiguation would be a Japanese calendar date, not a Gregorian date. The Vietnamese calendar uses a different set of animals for the branch names in years, and the marker for intercalary month is inserted *after* the month name, not before. -3. Hebrew calendar -The Hebrew calendar is another luni-solar calendar, with months of 29 or 30 days beginning at a new moon. Intercalary months are inserted during specific years of a 19-year cycle, always by doubling the month of Adar: A leap year has months Adar I and Adar II (Adar I is considered to be the extra inserted month). -Month numbering is interesting. Traditionally, the month of Nisan was numbered 1, and Adar was 12 (thus Adar I and II were 12 and 13). However, this puts the month of Tishri, which begins with the new year (Rosh HaShanah), as month 7. A more modern numbering has Tishri as month 1 (to coincide with the new year) which leads to different schemes for numbering Adar and the subsequent months (see discussion below on what ICU does). -4. Coptic and Ethiopic solar calendars -These always have 13 months; 12 months of 30 days each and a 13th month of 5 days (6 in a leap year). There is no leap month per se. -5. Hindu luni-solar calendar (old or new, with several variants): -Months are 29 or 30 days, beginning at new moon (south India) or full moon (north India). Months are named based on which zodiac sign the sun transits into during the course of the lunar month. An intercalary month occurs when the sun does not transit into a zodiac sign during the lunar month, and it takes the name for the zodiac transit of the following month with a marker to indicate “extra”/“added”; the following month *also* takes a marker to indicate “original”/”regular”/”clean” (a bit like Adar I and Adar II, except that it can apply to any month). If the sun transits into two zodiac signs during a lunar month, then two months are collapsed into one; the resulting month takes the name associated with both zodiac signs, with a marker indicating “lost”. A year when this occurs must also have at least one added month, since the year must have 12 or 13 lunar months. Occasionally an added month with no transits is immediately followed by a collapsed month with two; in this case the first month takes the name of the first transit in the second month plus the marker “extra”/“added”, while the second month takes the names of both transits plus the marker “lost”. -This calendar also uses a 60-year cycle of year names, but they are not derived as combinations of sub-cycle names (as with the Chinese calendar). -6. The Tibetan luni-solar calendar -The Tibetan luni-solar calendar handles months like the Hindu calendar. Two different 60-year naming cycles are in use, one derived from the Chinese calendar and one derived from the Hindu calendar. In addition, three different cardinal year numbering schemes are used, with three different epochs (like the distinction between ethiopic and ethiopic-amete-alem calendars). -B. Other features of the Chinese calendar, not for this proposal -The Chinese calendar divides the solar year into 24 solar terms— 12 major terms and 12 minor terms—each associated with divisions along the sun’s course through the zodiac. These are usually shown on printed calendars, and are used for agriculture and astrological purposes. The data could be derived from existing calendar fields, or a new field could be added. -Months and days are also named in cycles of 60 using the stem-branch names, and days are subdivided into 12 two-hour periods named according to the earthly branches. The combination of year name, month, day name and day period name (年月日時) is important for many purposes, including picking children’s names and arranging weddings, moves, travel, and funerals. This data could also be derived from existing calendar fields, or a new field added. -Festivals and holidays are shown on printed Chinese calendars, as well as on many other calendars. ICU4J has a preliminary framework for holiday support. ICU4C does not, and there is currently no commitment in ICU to move this along. Support for marking festivals and holidays is thus beyond the scope of this proposal. -Nothing in this proposal prevents or makes more difficult adding any of these other features later on; this proposal just focuses on features that can be implemented in the near term. -C. ICU behavior -Here is how ICU currently handles the calendar behaviors above: -1. Chinese calendar -Months are numbered 0-11 (the zero-based value of UCAL_MONTH). When an intercalary month is added, it has the same number as the preceding month, but the value of UCAL_IS_LEAP_MONTH is 1 instead of 0 (this seems to be the only supported calendar that ever sets UCAL_IS_LEAP_MONTH to anything other than 0). -For purposes of add and set operations, month is treated as a tuple represented by UCAL_MONTH and UCAL_IS_LEAP_MONTH. If UCAL_IS_LEAP_MONTH is 0 for a month that has a leap month following, then adding 1 month, or setting UCAL_IS_LEAP_MONTH to 1, sets the calendar to the leap month (which has the same value for UCAL_MONTH). If a month does not have a leap month following, then a set of UCAL_IS_LEAP_MONTH to 1 is ignored. -Years are numbered 1-60 (the value of UCAL_YEAR) for each 60-year cycle. The era is incremented for each 60-year cycle, so we are currently in era 78. -Current ICU4C formatting for the Chinese calendar is completely broken. For example, the short date format in root and zh is currently “y'x'G-Ml-d”; the result this produces for Chinese era 78, year 29, month 4 (non-leap or leap), day 2 is “29x-4-”: There is no era value or leap month indicator, and non-literal fields after the ‘l’ pattern character are skipped. -In ICU4J the existing situation is bit better. Via data in data/xml/main/root.xml, ICU inserts its own "isLeapMonth" resource into the calendar bundle for "chinese"; this provides a leapMonthMarker of "*". There is a public ChineseDateFormatSymbols subclass of DateFormatSymbols which uses the "isLeapMonth" resource, and a public ChineseDateFormat of SimpleDateFormat; using ChineseDateFormat, Chinese calendar date formats using 'G' and 'l' can be formatted and parsed successfully. -2. Hebrew calendar -In a non-leap year, months run 0-4 (for months Tishri-Shevat), skip 5 (“Adar I”), then continue 6-12 (Adar-Elul). In a leap year, 5 is not skipped (“Adar I”), and CLDR data provides an alternate “leap” name for month 6 as “Adar II”. -3. Coptic and Ethiopic calendars -Months are numbered 0-12. -4. Other calendars listed above -ICU does not currently support the Hindu, Vietnamese, or Tibetan calendars (it does support the quite different Indian Civil calendar). -D. Problems with the current ICU behavior: -For the Chinese and Hebrew calendars, there is no a priori way to know for a given year whether it is a leap year. You have to run through the dates in the year to check the behavior (and the way you have to do this depends on the calendar). -The current model for UCAL_IS_LEAP_MONTH (ICU4J) IS_LEAP_MONTH) as a boolean cannot directly indicate the "normal-month-after-leap-month" and "compressed-month" used in Hindu and Tibetan calendars. However, those special months can be inferred from looking at month data before and after the month of interest. Another alternative might be to re-interpret the IS_LEAP_MONTH field to take more than two values. -It is a bit too bad that completely different models are used for leap months in the Hebrew and Chinese calendars. It would have been nice to have a more unified model that could also support the usage in Hindu and Tibetan calendars. -Calendar::add (ucal_add) for UCAL_MONTH gives different strange results for the Hebrew and Chinese calendars. For the Hebrew calendar, in a non-leap year, adding 1 month to month 4 produces month 6. For the Chinese calendar, in a leap year, adding 1 month to month n (before a leap month) produces month n (but with IS_LEAP_MONTH set). This is similar to what happens to hours around daylight savings time transitions, except in that case there is no IS_EXTRA_HOUR field to provide disambuguation (we should add one, see below). -E. Current CLDR support -CLDR currently provides the following: -1. yeartype attribute -The yeartype attribute for month name elements allows an alternate month name to be selected for leap years (current legal values are just “standard”—the default—and “leap”). It is only used for the Hebrew calendar, as follows: -Shevat Adar I Adar Adar II -This works with the normal MMM+/LLL+ pattern characters for months; the choice of which name to use is managed by ICU date formatting code. -Note that this yeartype month is currently mapped into ICU month name data as the 14th element in the array of Hebrew month names, which seems a bit hacky. -2. special pattern character ‘l’ -The special pattern character ‘l’ (small L) is described as: “Special symbol for Chinese leap month, used in combination with M. Only used with the Chinese calendar.” It is intended to indicate where the leap month marker (when needed) should go in a date format. This is a bit odd: -It is not clear how (or whether) this is supposed to work with availableFormats items and DateTImePatternGenerator. -There is currently no structure in CLDR to provide the value for ‘l’. But assuming we added it… -It is not clear how a client who wants month symbol names can get the name for a leap month - do they need to assemble it from two pieces? How would they know what order to use? -It is not clear why this mechanism needs to be different than the mechanism used for the Hebrew calendar. -It seems unnecessary; the month naming could just be handled via the MMM+/LLL+ pattern, and CLDR data could provide complete month names both with and without the marker (distinguished using the something like the yeartype attribute). This would fit more smoothly into existing mechanisms. -F. Proposal -Items 1-2 and 5-8 below are probably do-able for CLDR 21 and ICU 49. The others may come later. -1. ICU behavior for months -The Hebrew model of explicitly numbering all month names and skipping leap months in non-leap years does not work well for calendars like Chinese and Hindu that may insert leap months anywhere (and may combine months, etc.). The use of the UCAL_IS_LEAP_MONTH field is better suited to this. -For choosing the correct month name variant, I had proposed the idea of enhancing the UCAL_IS_LEAP_MONTH field to have 4 values, and adding an enum for these values: -normal month, this is currently value 0 for UCAL_IS_LEAP_MONTH -leap month (for Chinese, this has the same month number as the month before; for Hindu & TIbetan, it has the same number as the month after), this is currently value 1 for UCAL_IS_LEAP_MONTH -normal month after leap month (needed for Hindu & Tibetan); this could be value -1 for UCAL_IS_LEAP_MONTH (it is not a leap month, but does need a special name) -compressed month (needed for Hindu & Tibetan); this could be value 2 for UCAL_IS_LEAP_MONTH -While this was agreed in ICU PMC on 2011-11-09, I now think this idea should be withdrawn (agreed in PMC). For purposes of determining the variant month names, there are other approaches, e.g. for relevant calendars we can see whether subtracting a month gives the same month number (in which case we have a normal month after leap), or adding a month skips a month number (in which case we have a combined month). For calendrical calculations, however, the current UCAL_IS_LEAP_MONTH values of 0 and 1 are adequate (since that is all that is needed to disambiguate month numbering); and in fact the extra values would complicate the calendrical calculations: if we set a month to be compressed, what does that mean? -For a unified model we could also change the Hebrew calendar to use this approach (since in a leap year it inserts Adar I before Adar, whose name then changes to Adar II - the form for normal after leap), but that might be a compatibility issue. We can at least set UCAL_IS_LEAP_MONTH appropriately, even if we do not change the month numbering. -2. CLDR data for leap months -The yeartype attribute for month names cannot support different month name types for each month in a year, or for different months in a year. -Old ideas -The first version of this proposal suggested defining for the month name element a new attribute “monthtype” which could have the values “standard”, “leap”, “standardAfterLeap”, or “combined”, and then supplying explicit names for each needed type for each month (rather than a mechanism to combing markers). The thought was that this would permit handling of special forms for e.g. the first month of the year. However, it is only the first month of the lunar year that may have a special form in the Chinese calendar, and that can never have a leap month anyway. -The second idea was to permit inside each element (i.e at the same level as the elements) zero or more elements, which could have a type attribute of "leap", "standardAfterLeap", or "combined", and whose value would be a a pattern showing how to combine a marker with a month name {0} (and possibly {1} for combined months) - e.g. "闰{0}" or "kshay {0}-{1}". This was approved in CLDR 2011-11-16. However, it does not address the problem of specifying a month type marker with numeric months as well. For this we need a separate structure that parallels monthContext… -Current idea -(approved in CLDR meeting 2011-11-30) -Alongside the element, permit an optional parallel element (only present for calendars that need it). The structure under this is similar to that for , except that: -The element's type attribute that takes one of three values: "format", "stand-alone", or the added "numeric" (pattern to use with numeric months). -The element's type attribute can take an additional value "all" for use with the "numeric" context (since there is no width distinction for numeric months). -The elements can have type "leap", "standardAfterLeap", or "combined"; the value is the pattern used for modifying the month name(s) to indicate that month type. A Chinese calendar example (marker before the month name) in root: - (default alias to format/wide) (default alias to stand-alone/narrow) {0}bis (default alias to format/abbreviated) {0}bis (default alias to format/wide) {0}bis -And in the Chinese locale: - 闰{0} 闰{0} 闰{0} -For other calendars, the elements above could be replaced by others such as the following: -For the Hebrew calendar, in the Hebrew locale, one could have (for Adar I and II): -{0} א׳ {0} ב׳ -For the Hindu calendar, in root (for a combined month, the name will be an affix plus a combination of two month names): -adhik {0} nija {0} kshay {0}-{1} -For the time being, at least, I don't think that we need to present this in the Survey Tool, and that may prove too complex and confusing anyway. -3. Month name styles -(mostly about data, some ideas for future structure requirements): -Japanese locale month name styles, all for either Gregorian or lunar calendar (except as noted). The distinction among them is not just format vs standalone. -The style 1月, 2月, 3月... is almost always used for horizontal text and for yMd formats. This is by far the most common. -The style 一月, 二月, 三月... can be used for vertical text, as a special style e.g. on New Year cards, and rarely for government documents. -The traditional naming, which is still used sometimes for titles on calendar pages: 睦月, 如月, 弥生, 卯月, 皐月, 水無月, 文月, 葉月, 長月, ... -The name 正月 is formally an alternate name for Gregorian January, but in common usage means just the New Year holidays (first few days of Jan.). -Chinese locale month names and alternates (applies to both traditional/simplified, mainland/Taiwan unless noted): -Gregorian calendar: The style 1月, 2月, 3月 is preferred for complete yMd dates (all of whose components should use 0-9 digits), especially when Gregorian dates are shown together with Chinese calendar dates. The style 一月, 二月, 三月 can also be used for month names by themselves, either in running text or as an isolated element on a calendar page. -Lunar calendar: The first month is always designated 正月. For the remaining months, the style 二月, 三月, 四月 is preferred (especially when Chinese calendar dates are shown together with Gregorian dates), except that 冬月 and 腊月 are sometimes used for months 11 and 12. Chinese numerals should be used for the other portions of complete dates as well. -The “monthType” attribute in the first version of this proposal might have also provided a means to address variants such as some of the above, as well as the following: -For parsing, it would be useful to have multiple forms for month names—e.g. “Sep.” and “Sept.” -4. Day names -Will need some way to specify the special day numbering forms used in Chinese for the Chinese calendar - TBD, can be a future enhancement. -5. Deprecate the pattern character ‘l’ (small L). -If it occurs in a pattern it should be ignored. -6. CLDR data for year names -Option 1, element -(The following was originally agreed in CLDR 2011-11-16; however, it has been superseded by option 2, which was approved on 2011-11-30). -Add a element and sub-elements parallel to the current structure for , , and , as follows (with similar structure in ICU): - Jia-Zi Yi-Chou … Gui-Hai (defaults to abbreviated) (defaults to abbreviated) -Only the “format” context would be supported initially; other contexts could be added if needed. -Option 2, element -(approved in CLDR meeting 2011-11-30) -As noted above, the cycle of 60 stem-branch names is used for months and days as well as years. Years as are also known according to the cycle of 12 zodiac animals associated with the branch portion of the stem-branch name. A cycle of 12 branch names is also used for subdivisions of a day. Thus, it would be beneficial to have a more general representation of such name cycles, even though cyclic names for months, days, and day subdivisions are not part of the current proposal. -In one of his comments on #1507, Philippe Verdy mentions that the cycle of 60 names is also used for some non-calendrical enumerations in Chinese such as measurement of angles, and suggests that data for this should be independent of the calendar structure. These notions are specific to the Chinese locale, and are not notions that CLDR would support across multiple locales (unlike the Chinese calendar, which is supported across multiple locales), so it probably does not make sense to add CLDR structure for them. -The following proposes a ways to support cyclic names for years, zodiac mappings, months, days, and dayParts (not really the same as dayPeriods), with the currently-known cycles of length 60 or 12 (for the Chinese, Hindu, and related calendars); this structure would be just below the element: - jia-zi yi-chou … gui-hai < cyclicNameWidth type=”narrow”> (defaults to abbreviated) < cyclicNameWidth type=”wide”> (defaults to abbreviated) (root aliases to years) (root aliases to dayParts) …data for branch names... (root aliases to dayParts, some locales will supply separate data) -As with the leap month data, this may not be appropriate for the Survey Tool. -7. New pattern character(s) -We would need to add a pattern character to indicate year name. A natural choice is ‘U’ since it is currently unused and ‘u’ is already used for a different year type. -8. ICU implementation changes -Formatting... (to be supplied) -Parsing (month names, year names)... (to be supplied) -ICU4J ChineseDateFormat class, move relevant behaviors into SimpleDateFormat, leaving this as mostly a shell. Remove ChineseDateFormatSymbols use of "isLeapMonth" resource; instead derive the necessary data (needed only for backwards compatibility) from the monthPatterns data. -9. ICU API enhancements -Add a calendar field IS_EXTRA_HOUR or IS_REPEATED_HOUR to disambiguate the hour added/repeated during DST transitions that set the clock back. -Work out how and whether to map the modified month names (for leap month types) onto APIs that get date format symbols — use additional options to specify month symbol types? What about symbols for year names? -Add Calendar API to answer the following questions for a given year and era: -Is it a leap year? And if so… -Of what type - does it adjust days or months? -When are the beginnings and ends (perhaps expressed as UDates) of the portions of the year that are affected by the adjustments? Note that calendars like Hindu could have in a single year up to two nonadjacent added months plus one combined month. -10. Supporting the Vietnamese / Korean / Japanese variants of the Chinese lunar calendar -These variants behave in a similar way, using different ways of designating leap months and different names for the stem-branch cycle, the branch cycle, and the zodiac cycle, and using a different meridian as the basis for astronomical calculations. We could support these in several ways: -Treat them as separate calendars with different names, and potentially support all of them in each locale. -Treat them each as the locale-specific variant of the Chinese lunar calendar. In that case the meridian for calculation needs to be supplied as part of the locale data. Need to clarify that the "Chinese" calendar means the locale-adapted version, not the historic imported one. -An in-between approach in which there is just one locale-specific set of data for the Chinese-style lunar calendar, but the meridian for computation is specified independently—perhaps as another locale tag value. -A combination of the above two approaches: Have locale data specify the default median, but also allow specification of meridian in the locale name to override this. This is the recommended approach. -11. Chinese calendar ambiguous dates, and handling of 'y' pattern character -For the Chinese calendar, the value within a Calendar object's YEAR file is the year number within a 60-year cycle. However, this year is never displayed numerically in a Chinese calendar date format; it is always displayed using the cyclic name, i.e. using pattern character 'U'. The Calendar object's ERA field is the cycle number, but this also is never used is a formatted date. Hence formatted dates that use only elements from the Chinese calendar itself are ambiguous as to which era/cycle they are associated with. For real-world usage, that is not a problem; the Chinese calendar is not intended to unambiguously represent a date, and is normally displayed in association with a date (at least a year) in one or more additional calendars that do provide that disambiguation. -As noted above, in Taiwan this other calendar is typically the Minguo/ROC calendar; in Japan it is typically the Japanese calendar; in mainland China and elsewhere it is typically the Gregorian calendar, often with additional calendars such as Islamic. -In the long run, CLDR calendar data for the Chinese calendar should specify which other calendar should be used as the associated calendar. Then it may be that for formatting and parsing Chinese calendar dates, the 'y' and 'G' pattern characters would be interpreted according to this associated calendar, rather than the Chinese calendar. -In the short term, ICU should specify that parse methods that do not take an associated Calendar object may not produce the expected results for the Chinese calendar. Such methods create a work Calendar object and then clear() it, which for the Chinese calendar will set it to era 1; since there is no era in the format, the parsed result will have era 1, producing a date in the range of Gregorian 2600 BCE (probably not what is expected). -Note that the convention of using a secondary calendar associated with a traditional calendar is not unique to the Chinese calendar. Real-world Japanese conventions for formatting dates often use both a Gregorian and Japanese Emperor year, e.g. "2012(平成24)年1月". -G. Tickets -The old CLDR and ICU tickets related to this are: -CLDR #1507: intercalary marker missing from chinese calendar (refile) [includes detailed comments from Philippe Verdy, some anticipating ideas above] -CLDR #2430: Illegal date-time field "l". -CLDR #2558: Chinese calendar formatting does not look right -CLDR #3672: Value inherited from "root" is in error -ICU #6049: Intercalary markers -New tickets related to this, which supersede the above, are: -CLDR #4230: Add element for Chinese calendar support -CLDR #4231: Add cyclic year name support for Chinese calendar -CLDR #4232: Deprecate pattern character 'l', add pattern character 'U' -CLDR #4237: Change Chinese calendar formats to use 'U' pattern char [must wait for ICU format/parse support] -CLDR #4259: Chinese calendar data updates -CLDR #4277: Remove processing from LDML2ICUConverter -CLDR #4282: Chinese calendar formats need era, Gregorian year, or ? -CLDR #4302: Fix spurious errors with chinese calendar (monthPatterns narrow, prettyPaths) -CLDR #4321: Skip some date pattern tests for Chinese calendar ('U' and other differences from std) -CLDR #4322: Fix test errors for monthPatterns -CLDR #4325: Fix test errors for date patterns using U (availableFormats...) -ICU #8958: Use CLDR data to format/parse Chinese cal dates -ICU #8977: Use CLDR data to format/parse Chinese cal dates (J) -ICU #8959: Support new 'U' pattern char for formatting/parsing Chinese cal dates -ICU #9034: Delete obsolete in data/xml/main/root.xml -ICU #9035: More ICU4C chinese calendar format/parse fixes -ICU #9043: Chinese cal dates can't always be parsed - design 2-cal solution -ICU #9044: Chinese cal dates can't always be parsed - document & fix tests -ICU #9055: Integrate Chinese cal pattern updates (cldrbug 4237), update tests \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/consistent-casing.txt b/docs/site/TEMP-TEXT-FILES/consistent-casing.txt deleted file mode 100644 index 48bb22f35dc..00000000000 --- a/docs/site/TEMP-TEXT-FILES/consistent-casing.txt +++ /dev/null @@ -1,79 +0,0 @@ -Consistent Casing -Rough Draft -We know that we need to improve the way we do casing in CLDR. We want the casing to be consistent, so that we don't see, for example, some language names with titlecase and some with lowercase. -Current Status -We have the inText and inList items, but they are not consistently applied - and we haven't had tests for problems. Here is some text from http://unicode.org/reports/tr35 (I added notes in italic): - -The following element controls whether display names (language, territory, etc) are title cased in GUI menu lists and the like. It is only used in languages where the normal display is lower case, but title case is used in lists. There are two options: - - -In both cases, the title case operation is the default title case function defined by Chapter 3 of [Unicode]. In the second case, only the first word (using the word boundaries for that locale) will be title cased. The results can be fine-tuned by using alt="list" on any element where titlecasing as defined by the Unicode Standard will produce the wrong value. For example, suppose that "turc de Crimée" is a value, and the title case should be "Turc de Crimée". Then that can be expressed using the alt="list" value. -Note: we have inList items currently for: -cs.xml -da.xml -es.xml -hr.xml -hu.xml -nl.xml -ro.xml -root.xml -ru.xml -sk.xml -uk.xml - -This element indicates the casing of the data in the category identified by the inText type attribute, when that data is written in text or how it would appear in a dictionary. For example : -lowercase-words -indicates that language names embedded in text are normally written in lower case. The possible values and their meanings are : -titlecase-words : all words in the phrase should be title case -titlecase-firstword : the first word should be title case -lowercase-words : all words in the phrase should be lower case -mixed : a mixture of upper and lower case is permitted. generally used when the correct value is unknown. -Note: we have inText items currently in: -cs.xml -da.xml (20 matches) -es.xml (9 matches) -hr.xml (11 matches) -hu.xml (7 matches) -nl.xml (8 matches) -ro.xml (4 matches) -root.xml (13 matches) -uk.xml (6 matches) -For example, for Dutch we have (excluding draft items): -1,043: lowercase-words -1,045: titlecase-firstword -1,047: titlecase-firstword -1,049: titlecase-firstword -... -In certain circumstances, one or more elements do not follow the rule of the majority. as indicated by the inText element. In this case, the allow attribute is used: -The example below indicates that variant names are normally lower case with one exception. -lowercase-words - - ortografia tradizionale tedesca - ortografia tedesca del 1996 - dialetto del Natisone - -Improved Testing -As a part of bug http://www.unicode.org/cldr/bugs-private/locale-bugs-private/data?id=2227, I added a consistency test for casing. It just generates warnings for now, and the test is very simple: given a bucket of translations (eg language names), verify that everything have the same first-letter casing as the first item. Although simple (and not bulletproof!), it is revealing... -cs [Czech] warning names|language|lb 〈Luxembourgish〉 【】 〈Lucemburština〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). -cs [Czech] warning names|language|om 〈Oromo〉 【】 〈Oromo (Afan)〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). -cs [Czech] warning names|language|ps 〈Pashto〉 【】 〈Pashto (Pushto)〉 «=» 【】 Warning: First letter case of =upper doesn't match that of =lower (names|language|aa). -I didn't use the inText or inList data, because I don't think we have enough data, nor that it has been vetted enough, to be reliable. Moreover, I don't think the buckes it uses are fine-grained enough.. I put the test output in 3 different files in http://www.unicode.org/cldr/data/dropbox/casing/ -The code is at http://www.unicode.org/cldr/data/tools/java/org/unicode/cldr/test/CheckConsistentCasing.java. Note that the buckets I used are defined in the code in typesICareAbout in the code. -Feedback and Open Issues -It would be useful to get people's feedback on how the tests can be improved. -In particular, whether the "buckets" should be done differently. For example, it would reduce the warnings if we put the abbreviated format months in a different bucket than the wide format months. But I don't know whether it is right to suppress this warning, or whether it indicates a true problem. -az [Azerbaijani] warning calendar-gregorian|day|sunday:format-wide 〈Sunday〉 【】 〈bazar〉 «=» 【】 Warning: First letter case of =lower doesn't match that of =upper (calendar-buddhist|day|sunday:format-abbreviated). -A second issue is how to pick the "paradigm" casing for each bucket. The algorithm I use now is to just use the first item in each bucket. -A third issue is how to "turn off" the warning; some way for the user to add data that says "it is ok for this item to have different case" (This is a more general issue regarding errors/warnings.) -A broader issue is what we should do with inText and inList in order to deal with casing, and how to deal with the fact that sometimes items in a bucket should undergo a case transformation in a particular environment (eg should be titlecased in menus but otherwise lowercased). -Determining whether current structure is sufficient -(from Peter E, 2009 Nov 18) -The attached "CasingContexts.pdf" is a first draft of a doc providing examples of various contexts for usage of date formats and date elements, language names, region names, and names of various other CLDR keys. This document is somewhat oriented to Mac OS X (since those were the examples at hand), so I would like to solicit other type of examples that may cover situations not depicted here. Suggestions welcome! -What I hope to do with this (and very soon) is to send it out to localizers to solicit either sample translations for each item in context (so I can infer the various grammatical cases and capitalization cases that CLDR may need to support), or better yet, have the localizers let me know about all of the cases that are necessary. -With that information I hope to: -Determine what additional types (beyond form,at and standalone) may be necessary for date formatting, and -See whether inText/inList are adequate to cover the capitalization cases, and if not, try to come up with something better. -(from Peter E., 2009 Nov 22) -I have attached "CasingContextsV2.pdf" which fixes the calendar menu example (thanks Kent!) and adds examples of currencies in text and various examples of units in text. I still need to add an example of currency in a dialog, along with overall instructions. -(from Peter E., 2009 Nov 25) -Updated to "CasingContextsV3.pdf" which adds an overall explanation of the purpose of this document as well as instructions for localizers to provide feedback. \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/coverage-revision.txt b/docs/site/TEMP-TEXT-FILES/coverage-revision.txt deleted file mode 100644 index e5d06534ee5..00000000000 --- a/docs/site/TEMP-TEXT-FILES/coverage-revision.txt +++ /dev/null @@ -1,34 +0,0 @@ -Coverage Revision -Propose changing CoverageLevel to be data driven. Rough thoughts. -Have a list of paths -- ​/​/ldml​/identity​/version => NONE -- ... -+ /​/ldml​/localeDisplayNames​/languages​/language[@type="*"] language:​type=​[en, und] => Minimal -+ ... -- ... -Have special variables for -this language -this language's countries -this language's territories -... -Current coverage: needs review -I put the tentative results in http://spreadsheets.google.com/pub?key=t5UzIpaSqcYBksSMtZp-f7Q&output=html -The more detailed files are in http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/. In particular: -http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/summary.txt -http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/samples.txt -http://unicode.org/repos/cldr-tmp/trunk/dropbox/mark/coverage/fullpaths.txt -There is more to do, but I wanted to give a snapshot -- tune the weighting -- weight by draft level -- add collations, rbnf, plural rules, transforms (if non-Latin), etc. -From John -I've been doing some more thinking about how to deal with coverage in CLDR. It seems to me that we already have the notion that every XPath in CLDR should have some predefined number associated with it between 0 and 100 that denotes it's relative importance in terms ofcoverage, with 0 being absolutely critical, and 100 being not critical at all. See Appendix M of TR35 for a brief description of the levels. I think that if we could accurately quantify this using metadata, then it would be relatively easy for us to accomplish two things: -1). Filter out fields from the ST that we don't really need, since everything we do would be filtered based on a desired coverage level. -2). Allow individual users to set the filtering in the survey tool based on one of the predefinedcoverage levels as we already have in the spec, or actually any other numeric coverage level that they desire. -So with this in mind, I would like to propose the following structure to be added to the supplemental metadata: - -  -  -.... - -Finding the appropriate coverage level value would then be a matter of searching the coverageLevel entries in numeric order by value looking for a match of the path vs. "//ldml/" + "regular expression". In other words, we would not specifically include "//ldml" in the expressions, since they would all start with that. Once a given xpath's coverage level value was determined, it shouldn't be too hard for us to simply filter out fields whose coverage level was higher then the requested. I suppose that we will need some wildcards similar to what Mark has started working on in his path filtering proposal. \ No newline at end of file diff --git a/docs/site/TEMP-TEXT-FILES/currency-code-fallback.txt b/docs/site/TEMP-TEXT-FILES/currency-code-fallback.txt deleted file mode 100644 index fab2b6c6485..00000000000 --- a/docs/site/TEMP-TEXT-FILES/currency-code-fallback.txt +++ /dev/null @@ -1,17 +0,0 @@ -Currency Code Fallback -The basic problem is that we can't use currency codes that our users won't have fonts for. It was fine to have, say, the shekel sign in Hebrew, as in CLDR 1.6, because we could presume that anyone using the Hebrew locale would have a Hebrew font, and that Hebrew fonts would have a shekel sign. But by putting it into root, we are presuming that *everybody* would have that character, which is not true. Our users/customers think there is something wrong when they scan a list of currencies, and some of them are black boxes. -Here are some examples of behavior I think we'd like to support. -We show ￡ if the font is available, otherwise £, otherwise currency code. -We show ₧ if the font is available, otherwise Pts, otherwise currency code. -For reference, here are the currency signs in Unicode: http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%3Asc%3A]. Also see http://en.wikipedia.org/wiki/Currency_sign and http://www.unicode.org/cldr/data/charts/by_type/names.currency.html. -For more details on the problem, see the email thread titled "Problems with currency codes". -Here are some recommendations. -We don't have the character fallback element for any currency symbol that is used for different currency codes. That is, it is ok to have EUR for €, but not ok to use KRW for ₩, since ₩ is also used for KPW, and not to have JAY for ¥, since ¥ is also used for CNY. -Even with this, we don't really want to use character fallback elements for currency substitution in general, since it is too coarse. -We should try to remove all the currency symbols that use Unicode symbol characters from the locales, except where they have special plurals, or where we have symbol reversals (eg in the US, $ for USD and C$ for CAD, while in CA, $ for CAD and US$ for USD). -Options -We then just make sure that all currency symbols in root are widely understood and in common fonts (eg in Windows Arial), or -We enhance the currency symbols so that we have a fallback list. We put the symbols that are in typical fonts in each locale in the currencySymbols exemplar list for that locale. When formatting, we walk through the fallback list until we hit one that works. If we don't get any, we use the currency code. If a smart client has font information, then he could also walk the fallback list using the font information instead of the currencySymbol exemplars. -We have something like "commonly used" that lets the application provider choose to force the symbol; otherwise only the commonly used symbols appear. So in root, commonly used would be on EUR, etc. Could be turned on in locales, or by application. -I'm leaning towards #1, just for simplicity. -However, see also: http://www.unicode.org/cldr/bugs/locale-bugs?findid=2244 \ No newline at end of file