From verdy_p@wanadoo.fr Fri Jun  1 02:54:17 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 01 Jun 2007 02:54:17 -0500 (CDT)
Received: from smtp19.orange.fr (smtp19.orange.fr [80.12.242.19])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l517sGOC012624
	for <cldr-users@unicode.org>; Fri, 1 Jun 2007 02:54:17 -0500
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf1924.orange.fr (SMTP Server) with ESMTP id 623351C00092
	for <cldr-users@unicode.org>; Fri,  1 Jun 2007 09:54:11 +0200 (CEST)
Received: from HARNON (APoitiers-156-1-48-17.w86-213.abo.wanadoo.fr [86.213.95.17])
	by mwinf1924.orange.fr (SMTP Server) with ESMTP id 2F81F1C0008C
	for <cldr-users@unicode.org>; Fri,  1 Jun 2007 09:54:11 +0200 (CEST)
X-ME-UUID: 20070601075411194.2F81F1C0008C@mwinf1924.orange.fr
From: "Philippe Verdy" <verdy_p@wanadoo.fr>
To: <cldr-users@unicode.org>
Subject: TR: CLDR 1.5 beta/Unicode 5.0: character fallback substitutions
Date: Fri, 1 Jun 2007 09:54:08 +0200
Organization: Ordinateur Personnel
Message-ID: <018f01c7a422$08ea3ac0$0a01a8c0@rodage.dyndns.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcecpJkRf5eFtr9gSxWmz6+aPguNMgHIn3bQAAPUtIAABL+DIAAN/VYw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-archive-position: 143
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: verdy_p@wanadoo.fr
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users


[Note: this message was already sent to the general Unicode mailing list,
and is still not reaching the CLDR list, this is a second attempt to deliver
it to CLDR users and vetters. Sending it to the general Unicode list was
rejected by its moderator, because it was considered "out of topic", despite
I do think that this message also concerns the general Unicode list as it
speaks about general conformance problem.]
[Please, moderators of the CLDR list don't discard this message, as it has
still reached NOBODY! Is the CLDR list only open?]
----------------------------------------------------------------------

I see a strange sentence in the specification of the new "explicit"
character fallback substitutions, specified in CLDR 1.5 beta
"characters.xml" supplementary file. It says:

"The recommended usage is that when a character value is not in the desired
repertoire, the explicit substitutes from characters.xml are tested one by
one against the repertoire, with the first substitute wholly in the
repertoire being substituted for the value in the output. If no explicit
substitute is found, then toNFC(value) is tried; if that fails then
toNFKC(value) is tried."

This definition seems to violate the current Unicode 5.0 rules, because
explicit fallbacks (not canonically equivalent) would take precedence over
NFC equivalents...

Such definition would mean that renderers need to be changed to try
fallbacks BEFORE converting the string to NFC, and this complicates
significantly the implementation.

I've looked at the current list of fallbacks, and in fact there is currently
NO case where an explicit fallback comes along with a NFC fallback.

The only significant change in those fallbacks is that there are now better
fallbacks than NFKC compatibility equivalents (for example numerical
fractions have an explicit fallback with a SPACE prior to the NFKC
equivalent, making a better work for texts like "3<ONE HALF FRACTION>" which
would fallback to "31/2" using NFKC, instead of the better "3 1/2" with the
explicit fallback.

So shouldn't this definition read as:

"The recommended usage is that when a character value is not in the desired
repertoire, then toNFC(value) is tried. If no NFC substitute is found, then
the explicit substitutes from characters.xml are tested one by one against
the repertoire, with the first substitute wholly in the repertoire being
substituted for the value in the output; if that fails then toNFKC(value) is
tried."

Are you making this new definition for possible future fallbacks where it
would be better to use another newer fallback than the current NFC
substitutes (that can't be changed due to NFC stability)? If so, there's a
need to change some of the requirements for Unicode 5.0 conformance (because
this affects the character identity and the semantics), or the proposed new
order should be just optional.

For now, I see no justification (after looking at the proposed list) to
change the order of resolution in a way that prefers breaking the canonical
equivalence...

---

I also see that the data currently proposes the string "PHP" (ISO currency
code for the Philippan Peso) as an explicit fallback for the PESO SIGN, but
I'm not sure that the PESO SIGN is restricted to the Philippines. I think
that the "Ps" fallback would be more appropriate.

Same thing for the WON SYMBOL that uses the explicit fallback "KRW" and
assumes the South Korean currency, when the WON SYMBOL is also used for the
North Korean Won (KRP)... Here also, I think that the "W/" fallback would be
more appropriate...

For such currency symbol substitutes, which are locale-dependant, may be
these would be localizable using CLDR locale data if they must be kept.

Philippe.




From verdy_p@wanadoo.fr Fri Jun  1 04:43:46 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 01 Jun 2007 04:43:46 -0500 (CDT)
Received: from smtp19.orange.fr (smtp19.orange.fr [80.12.242.19])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l519hj5G009299
	for <cldr-users@unicode.org>; Fri, 1 Jun 2007 04:43:45 -0500
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf1919.orange.fr (SMTP Server) with ESMTP id D9A8D1C00044;
	Fri,  1 Jun 2007 11:43:39 +0200 (CEST)
Received: from HARNON (APoitiers-156-1-48-17.w86-213.abo.wanadoo.fr [86.213.95.17])
	by mwinf1919.orange.fr (SMTP Server) with ESMTP id 41B321C0009B;
	Fri,  1 Jun 2007 11:43:39 +0200 (CEST)
X-ME-UUID: 20070601094339269.41B321C0009B@mwinf1919.orange.fr
From: "Philippe Verdy" <verdy_p@wanadoo.fr>
To: "'Steven R. Loomis'" <srl@icu-project.org>
Cc: <cldr-users@unicode.org>
References: <018f01c7a422$08ea3ac0$0a01a8c0@rodage.dyndns.org> <3A96D8C9-AF2A-4FEF-8AEE-8B29C3154EDE@icu-project.org>
Subject: RE: TR: CLDR 1.5 beta/Unicode 5.0: character fallback substitutions
Date: Fri, 1 Jun 2007 11:43:36 +0200
Organization: Ordinateur Personnel
Message-ID: <019701c7a431$53d29190$0a01a8c0@rodage.dyndns.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <3A96D8C9-AF2A-4FEF-8AEE-8B29C3154EDE@icu-project.org>
Thread-Index: AcekJvY57U321q2tRcm+cE6l/w5NfwAAV3Tg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-archive-position: 144
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: verdy_p@wanadoo.fr
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

"Steven R. Loomis" <srl AT ICU-Project.org> :
> 
> On Jun 1, 2007, at 12:54 AM, Philippe Verdy wrote:
> 
> > [Note: this message was already sent to the general Unicode mailing
> > list,
> > and is still not reaching the CLDR list, this is a second attempt
> > to deliver
> > it to CLDR users and vetters. Sending it to the general Unicode
> > list was
> > rejected by its moderator, because it was considered "out of
> > topic", despite
> > I do think that this message also concerns the general Unicode list
> > as it
> > speaks about general conformance problem.]
> > [Please, moderators of the CLDR list don't discard this message, as
> > it has
> > still reached NOBODY! Is the CLDR list only open?]
> > ----------------------------------------------------------------------
> 
> received OK on cldr-users .
> this does NOT go to vetters, though.  I am setting up the vetters list.

Sorry for this long message. I have lots of comments to say about how the
CLDR project is currently running. So I will subtitles below.

==== About the CLDR discussions, bug reports and collaboration ====

Given this situation, where messages sent to the CLDR lists do not reach the
intended audience, and discussing any issue that is more or lesslinked to
the CLDR projet are currently rejected by moderators of the general Unicode
list (even if the issue is more general than just what CLDR is just starting
to document), I think I must send a copy of my message to the CLDR bug
report, so that it is not lost.

It's quite bad that such issues are rejected from the general Unicode list
(I got a warning from Kenneth Whistler that moderated my message), where
there are lots of other futile discussions, and many out-of-topic
discussions that go through it, before making sure that the CLDR list is
fully functional and effectively monitored...

That's not the first time that I try to send messages to the CLDR list, and
nobody detects that it is not working as expected. And it's bad to receive
messages from the Unicode list moderators that don't even know if the CLDR
list is effectively working (I had to use the Unicode list several times in
the past to signal bugs, including in the CLDR bug report form that was not
working too, and so my messages were discarded by the same Unicode list
moderators!)

==== About the CLDR online forums ====

And apparently, the messages in the CLDR online forums are not read (not
even by CLDR TC members), or too few vetters notice this message area: I
have posted many messages or comments there for the specific locale I was
providing data (French), and nobody replied there.

==== About the CLDR data format changes and announcements ====

I also note that the proposals submission phase for CLDR 1.5 was terminated
without ANY announcement sent to the CLDR list, and not even in the general
Unicode list (that's why I have sent a notice to the general Unicode list to
inform people that have recently joined the CLDR process and proposed to
submit new localization data, just a few days before this phase was ended).

==== About the CLDR work cycle and releases ====

Given the very long working cycle for CLDR data, this is extremely damaging
for the credibility of the CLDR project, because bogous data is released for
many months and can't be corrected before more than one year.

With the current state of the CLDR database, which is still a beta and will
still remain a poor beta in version 1.5 with not enough submissions and
vetters to submit changes that will be accepted, Ido think that the working
cycle needs to be shortened, with more frequent patch subversioning (even if
a yearly release is still published separately).

Since the CLDR project is in Unicode, its evolution is dramatically slow and
much more complicated than before. And this working cycle does not match
with the frequent additions and new datatypes added to the project (for
example I noted the addition of the characters.xml data only by visiting the
site and following links: changes and additions are NOT announced anywhere,
and new datatype is added to the project and made part of the release
candidate without informing any vetters)

Things would be much better if there was a permanent workshop, even if there
are frozen input for a future release candidate.

==== About the CLDR project reactivity ====

The CLDR project was much more reactive when it was part of the IBM's ICU
project. But now, even IBM does not seem to follow the ongoing work (I only
see Apple...), so my feeling is that the CLDR TC is nearly inexistent or not
functional, with a precise working schedule, and meetings: its members seem
to be mostly busy working on the Unicode standard itself (and in fact, I do
think that all active CLDR TC members are part of the Unicode TC andhave
forgotten their work for the CLDR project)

Really, something must be done to improve the project so that new CLDR TC
members (that are not part of the Unicode TC) accept to work on the project,
otherwise they will leave it, and will continue their current work outside
of this very slow project, which also now depends on tools that are still in
beta with many bugs and limitations.

My feeling is that CLDR 1.5 beta should only be restarted very soon and not
released for more than one year: there are too many errors that the current
freeze will NOT allow to correct due to not enough vetters.

==== About speeding up the modern coverage in CLDR vetting ====

One thing to improve the CLDR work: the list of localization data is really
big. The CLDR data submission forms should really avoid list everything when
we select the "modern" coverage. This would really speed up the completion
vetting on the most important data.

==== About usability of CLDR tools ====

And the tools really need to be much faster: it takes many hours or days
just to review all this data, because it requires often minutes just to
submit a single entry or just get the existing data formatted for review. I
fear that it performs too much work trying to reformat complete XML files,
instead of working on smaller rows using a relational database modelling
(internally, IBM, Oracle, Sybase or Microsoft could provide and licence to
the project a fast, stable and secure RDBMS SQL engine for the data
submission and vetting process).

The regeneration of complete XML and HTML files is not necessary during the
proposal and vetting phase as it can be completely automated by a database
query, or the current XML engine is really running on a very slow machine
that may need to be changed with more memory, faster disks, and faster
processor core(s).

==== About the presentation of very long CLDR input forms ====

Finally, the HTML pages in online CLDR forms have a minor but important bug:
it is presented as a table, but the various options are presented in lists,
without clear separation of rows, with this layout, the absence of
horizontal borders creates confusion.

Although it's good to be able to submit bulk modifications directly from the
long list, it freqeuently happens that a currently selected radio button
gets changed by error when scrolling the long page. I think that when
submitting modifications from the long list, the differences should be
computed and confirmed before being accepted as a new vote. The confirmation
screen would be identical, but would only show the list of items that were
modified during manual selection when browsing the long list. This would
avoid submitting things by error and correcting them again.

Another possible presentation: the long list would not allow making any
change directly, but would just allow selecting items (with just a checkbox)
for which we want to submit changes. When clicking the submit button from
this page, the effective input form would appear, displaying only those
selected items, in a much smaller input form, that would be also much faster
to process on the server most of the time for actual vote submissions. By
default the long list would only display the status of votes. This would
also avoid the difference between items that were individually selected,
modified and submitted in a separate frame, and the currently displayed long
list of items (that is not refreshed to reflect the changes).

Philippe.




From srl@icu-project.org Fri Jun  1 05:09:45 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 01 Jun 2007 05:09:46 -0500 (CDT)
Received: from v.icu-project.org (v.icu-project.org [161.58.210.87])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l51A9jSh030935
	for <cldr-users@unicode.org>; Fri, 1 Jun 2007 05:09:45 -0500
Received: from monkey.sbay.org ([216.27.178.44] helo=[10.0.0.102])
	by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD))
	(envelope-from <srl@icu-project.org>)
	id 1Hu44l-000Df7-NL; Fri, 01 Jun 2007 10:09:44 +0000
In-Reply-To: <019701c7a431$53d29190$0a01a8c0@rodage.dyndns.org>
References: <018f01c7a422$08ea3ac0$0a01a8c0@rodage.dyndns.org> <3A96D8C9-AF2A-4FEF-8AEE-8B29C3154EDE@icu-project.org> <019701c7a431$53d29190$0a01a8c0@rodage.dyndns.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3D052493-9BEC-4F3F-AA5F-258F409B40DF@icu-project.org>
Cc: <cldr-users@unicode.org>
Content-Transfer-Encoding: 7bit
From: "Steven R. Loomis" <srl@icu-project.org>
Subject: Re: TR: CLDR 1.5 beta/Unicode 5.0: character fallback substitutions
Date: Fri, 1 Jun 2007 03:09:35 -0700
To: <verdy_p@wanadoo.fr>
X-Mailer: Apple Mail (2.752.3)
X-archive-position: 145
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: srl@icu-project.org
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users


On Jun 1, 2007, at 2:43 AM, Philippe Verdy wrote:

> "Steven R. Loomis" <srl AT ICU-Project.org> :
>>
>> received OK on cldr-users .
>> this does NOT go to vetters, though.  I am setting up the vetters  
>> list.
>
> Sorry for this long message. I have lots of comments to say about  
> how the
> CLDR project is currently running. So I will subtitles below.
>
> ==== About the CLDR discussions, bug reports and collaboration ====
>
> Given this situation, where messages sent to the CLDR lists do not  
> reach the
> intended audience,

  I'm not sure what didn't reach the intended audience.  cldr-users  
probably reaches everyone you want to reach.. the vetters list will  
be for announcement only.

> and discussing any issue that is more or lesslinked to
> the CLDR projet are currently rejected by moderators of the general  
> Unicode
> list (even if the issue is more general than just what CLDR is just  
> starting
> to document), I think I must send a copy of my message to the CLDR bug
> report, so that it is not lost.

  A bug report is a better place for most of this sort of feedback,  
and as you say, then it won't be lost.

> It's quite bad that such issues are rejected from the general  
> Unicode list
> (I got a warning from Kenneth Whistler that moderated my message),  
> where
> there are lots of other futile discussions, and many out-of-topic
> discussions that go through it, before making sure that the CLDR  
> list is
> fully functional and effectively monitored...

  The general unicode list is not the appropriate place

> That's not the first time that I try to send messages to the CLDR  
> list, and
> nobody detects that it is not working as expected.

  I have never seen the cldr list not working as expected

> And it's bad to receive
> messages from the Unicode list moderators that don't even know if  
> the CLDR
> list is effectively working (I had to use the Unicode list several  
> times in
> the past to signal bugs, including in the CLDR bug report form that  
> was not
> working too, and so my messages were discarded by the same Unicode  
> list
> moderators!)

  We already discussed the spam blocking issue, which was preventing  
my receiving your direct mail before.  It appeared that the bug  
report form wasn't working in that you had >500 characters in the  
subject field.  If it is still otherwise not working, please let me  
know.

  What I am saying is, you are referring to different issues  
involving different people-- there is no concerted effort to reject  
feedback.

> ==== About the CLDR online forums ====
>
> And apparently, the messages in the CLDR online forums are not read  
> (not
> even by CLDR TC members), or too few vetters notice this message  
> area: I
> have posted many messages or comments there for the specific locale  
> I was
> providing data (French), and nobody replied there.

  They are read, and as of today, they also send email notifications  
when a change occurs. We will be sending out instructions for the RSS  
readers to be able to view the forums, as well.

> ==== About the CLDR data format changes and announcements ====
>
> I also note that the proposals submission phase for CLDR 1.5 was  
> terminated
> without ANY announcement sent to the CLDR list, and not even in the  
> general
> Unicode list (that's why I have sent a notice to the general  
> Unicode list to
> inform people that have recently joined the CLDR process and  
> proposed to
> submit new localization data, just a few days before this phase was  
> ended).

  An announcement was made on the schedule earlier, and the  
submission phase was terminated quite some time after the  
announcement was made that submission would be closing.    We have to  
close the door sometime or it will never finish.  By a very rough  
calculation there have been already over 37,000 new items in 113  
locales submitted by 128 different humans through this process.     
That includes conflicting items which will eventually be resolved,  
but that is a tremendous amount of new data.

> ==== About the CLDR work cycle and releases ====
>
> Given the very long working cycle for CLDR data, this is extremely  
> damaging
> for the credibility of the CLDR project, because bogous data is  
> released for
> many months and can't be corrected before more than one year.

  The data is as more or less bogus as the input and the process.   
The vetting phase will be telling as to the quality of the data. I  
think CLDR would have damaged credibilty if the data became worse  
from release to release, but as it is, it is serving user needs, and  
is improving between releases, both in coverage and in quality.

> With the current state of the CLDR database, which is still a beta  
> and will
> still remain a poor beta in version 1.5 with not enough submissions  
> and
> vetters to submit changes that will be accepted, Ido think that the  
> working
> cycle needs to be shortened, with more frequent patch subversioning  
> (even if
> a yearly release is still published separately).

  we are shortening the cycle as much as possible.  once again we  
have had major issues that had to be resolved which prevented the  
entirety of the time from being spent on accepting incoming data.

  I would appreciate specifics on how you perceive cldr as being poor  
or worse quality than before.

> Since the CLDR project is in Unicode, its evolution is dramatically  
> slow and
> much more complicated than before. And this working cycle does not  
> match
> with the frequent additions and new datatypes added to the project  
> (for
> example I noted the addition of the characters.xml data only by  
> visiting the
> site and following links: changes and additions are NOT announced  
> anywhere,
> and new datatype is added to the project and made part of the release
> candidate without informing any vetters)

   a full changeset of the data format is in the repository history  
for ldml.dtd and other dtds, and in the TR35 working history.

> Things would be much better if there was a permanent workshop, even  
> if there
> are frozen input for a future release candidate.

  what do you mean by a workshop?

> ==== About the CLDR project reactivity ====
>
> The CLDR project was much more reactive when it was part of the  
> IBM's ICU
> project. But now, even IBM does not seem to follow the ongoing work  
> (I only
> see Apple...), so my feeling is that the CLDR TC is nearly  
> inexistent or not
> functional, with a precise working schedule, and meetings: its  
> members seem
> to be mostly busy working on the Unicode standard itself (and in  
> fact, I do
> think that all active CLDR TC members are part of the Unicode TC  
> andhave
> forgotten their work for the CLDR project)

  I am an IBM employee and follow CLDR extremely closely, and there  
are others.  The CLDR TC is extremely active and conducts lengthy  
meetings with half a dozen people or more weekly.  Again, I don't  
know by what metric you see the TC as being non-existent or non- 
functional.

  what is CLDR not reacting to?

  perhaps CLDR does not put out the perception that much work by many  
people is going on, but it is indeed the case, I can assure you.

> Really, something must be done to improve the project so that new  
> CLDR TC
> members (that are not part of the Unicode TC) accept to work on the  
> project,
> otherwise they will leave it, and will continue their current work  
> outside
> of this very slow project, which also now depends on tools that are  
> still in
> beta with many bugs and limitations.

  bugs remain until they are worked on.

> My feeling is that CLDR 1.5 beta should only be restarted very soon  
> and not
> released for more than one year: there are too many errors that the  
> current
> freeze will NOT allow to correct due to not enough vetters.

  please give some specifics on why you think it should be restarted  
or where you see errors cropping up.

> ==== About speeding up the modern coverage in CLDR vetting ====
>
> One thing to improve the CLDR work: the list of localization data  
> is really
> big. The CLDR data submission forms should really avoid list  
> everything when
> we select the "modern" coverage. This would really speed up the  
> completion
> vetting on the most important data.

  that is a very good suggestion, and i think it is noted in the bug  
database.

> ==== About usability of CLDR tools ====
>
> And the tools really need to be much faster: it takes many hours or  
> days
> just to review all this data, because it requires often minutes  
> just to
> submit a single entry or just get the existing data formatted for  
> review. I
> fear that it performs too much work trying to reformat complete XML  
> files,
> instead of working on smaller rows using a relational database  
> modelling
> (internally, IBM, Oracle, Sybase or Microsoft could provide and  
> licence to
> the project a fast, stable and secure RDBMS SQL engine for the data
> submission and vetting process).

  internally it uses databases and not XML.  XML is only written to  
when needed.  I agree that it must be much faster, however I have not  
had much progress with performance improvements when compared to  
increased data set size and increasing complexity of runtime  
requirements.

> The regeneration of complete XML and HTML files is not necessary  
> during the
> proposal and vetting phase as it can be completely automated by a  
> database
> query, or the current XML engine is really running on a very slow  
> machine
> that may need to be changed with more memory, faster disks, and faster
> processor core(s).

  No XML files are regenerated during normal operation.  I can  
request them on demand to test things, or they are automatically  
updated daily into the repository.

> ==== About the presentation of very long CLDR input forms ====
>
> Finally, the HTML pages in online CLDR forms have a minor but  
> important bug:
> it is presented as a table, but the various options are presented  
> in lists,
> without clear separation of rows, with this layout, the absence of
> horizontal borders creates confusion.

  Perhaps they could be lighter horizontal lines?

> Although it's good to be able to submit bulk modifications directly  
> from the
> long list, it freqeuently happens that a currently selected radio  
> button
> gets changed by error when scrolling the long page. I think that when
> submitting modifications from the long list, the differences should be
> computed and confirmed before being accepted as a new vote. The  
> confirmation
> screen would be identical, but would only show the list of items  
> that were
> modified during manual selection when browsing the long list. This  
> would
> avoid submitting things by error and correcting them again.

  do you mean by erroneous clicks? that was considered, but was  
thought to slow the process down too much.

> Another possible presentation: the long list would not allow making  
> any
> change directly, but would just allow selecting items (with just a  
> checkbox)
> for which we want to submit changes. When clicking the submit  
> button from
> this page, the effective input form would appear, displaying only  
> those
> selected items, in a much smaller input form, that would be also  
> much faster
> to process on the server most of the time for actual vote  
> submissions. By
> default the long list would only display the status of votes. This  
> would
> also avoid the difference between items that were individually  
> selected,
> modified and submitted in a separate frame, and the currently  
> displayed long
> list of items (that is not refreshed to reflect the changes).

  that might also be useful for comparing a small set of items.  it's  
a good thought, probably not to be done for 1.5 however.

> Philippe.

steven


From srl@icu-project.org Fri Jun  1 05:15:21 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 01 Jun 2007 05:15:21 -0500 (CDT)
Received: from v.icu-project.org (v.icu-project.org [161.58.210.87])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l51AFLx8003091
	for <cldr-users@unicode.org>; Fri, 1 Jun 2007 05:15:21 -0500
Received: from monkey.sbay.org ([216.27.178.44] helo=[10.0.0.102])
	by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD))
	(envelope-from <srl@icu-project.org>)
	id 1Hu4AC-000DlW-Do
	for cldr-users@unicode.org; Fri, 01 Jun 2007 10:15:20 +0000
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <018f01c7a422$08ea3ac0$0a01a8c0@rodage.dyndns.org>
References: <018f01c7a422$08ea3ac0$0a01a8c0@rodage.dyndns.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-39-522248898
Message-Id: <049003D9-E17B-4168-87DE-14D741876ED4@icu-project.org>
From: "Steven R. Loomis" <srl@icu-project.org>
Subject: Re: TR: CLDR 1.5 beta/Unicode 5.0: character fallback substitutions
Date: Fri, 1 Jun 2007 03:15:11 -0700
To: cldr-users@unicode.org
X-Mailer: Apple Mail (2.752.3)
X-archive-position: 146
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: srl@icu-project.org
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users


--Apple-Mail-39-522248898
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

the code fallbacks simply mean there is no localized data.  "W/" or  
"Ps" won't always make sense.  Imagine a user in [pick your favorite  
language]  in [pick your favorite territory or country].    Will "4W"  
or "9Ps" make sense to them?  If they guess that Ps is Peso,  whose  
peso or peseta?

If KRW and KRP fall back to W/ then they aren't distinguished.


Unless a cultural preference (i.e. common use) actually uses a symbol  
and makes sense of it, it is far better to simply fall back to the  
code - it is at least unambiguous.   They may not know KRP or PHP  
(especially if they do not use latin letters primarily), but at least  
the letters might make sense to someone.

so in other words, they are localizable, but they shouldn't be  
localized where they won't be intelligible to the user community.

-s

On Jun 1, 2007, at 12:54 AM, Philippe Verdy wrote:

> I also see that the data currently proposes the string "PHP" (ISO  
> currency
> code for the Philippan Peso) as an explicit fallback for the PESO  
> SIGN, but
> I'm not sure that the PESO SIGN is restricted to the Philippines. I  
> think
> that the "Ps" fallback would be more appropriate.
>
> Same thing for the WON SYMBOL that uses the explicit fallback "KRW"  
> and
> assumes the South Korean currency, when the WON SYMBOL is also used  
> for the
> North Korean Won (KRP)... Here also, I think that the "W/" fallback  
> would be
> more appropriate...
>
> For such currency symbol substitutes, which are locale-dependant,  
> may be
> these would be localizable using CLDR locale data if they must be  
> kept.
>
> Philippe.


--Apple-Mail-39-522248898
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV>the code fallbacks simply =
mean there is no localized data.=A0 "W/" or "Ps" won't always make =
sense.=A0 Imagine a user in [pick your favorite language]=A0 in [pick =
your favorite territory or country]. =A0 =A0Will "4W" or "9Ps" make =
sense to them?=A0 If they guess that Ps is Peso,=A0 whose peso or =
peseta?=A0=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>If KRW and KRP fall back to =
W/ then they aren't distinguished.=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Unless a cultural =
preference (i.e. common use) actually uses a symbol and makes sense of =
it, it is far better to simply fall back to the code - it is at least =
unambiguous.=A0 =A0They may not know KRP or PHP (especially if they do =
not use latin letters primarily), but at least the letters might make =
sense to someone.=A0=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>so in other words, they are =
localizable, but they shouldn't be localized where they won't be =
intelligible to the user community.=A0=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>-s</DIV><BR><DIV><DIV>On =
Jun 1, 2007, at 12:54 AM, Philippe Verdy wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">I also see that the data =
currently proposes the string "PHP" (ISO currency</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">code for the Philippan Peso) =
as an explicit fallback for the PESO SIGN, but</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">I'm not sure that the PESO =
SIGN is restricted to the Philippines. I think</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">that the "Ps" fallback would =
be more appropriate.</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Same thing for the WON =
SYMBOL that uses the explicit fallback "KRW" and</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">assumes the South Korean =
currency, when the WON SYMBOL is also used for the</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">North Korean Won (KRP)... =
Here also, I think that the "W/" fallback would be</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">more =
appropriate...</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px; =
font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">For such currency symbol substitutes, =
which are locale-dependant, may be</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">these would be localizable using CLDR locale data if =
they must be kept.</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Philippe.</FONT></P> =
</BLOCKQUOTE></DIV><BR></BODY></HTML>=

--Apple-Mail-39-522248898--

From verdy_p@wanadoo.fr Fri Jun  1 08:41:14 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 01 Jun 2007 08:41:14 -0500 (CDT)
Received: from smtp19.orange.fr (smtp19.orange.fr [80.12.242.1])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l51DfD8g006176
	for <cldr-users@unicode.org>; Fri, 1 Jun 2007 08:41:14 -0500
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf1928.orange.fr (SMTP Server) with ESMTP id 0D16F1C000AC
	for <cldr-users@unicode.org>; Fri,  1 Jun 2007 15:41:08 +0200 (CEST)
Received: from HARNON (APoitiers-156-1-48-17.w86-213.abo.wanadoo.fr [86.213.95.17])
	by mwinf1928.orange.fr (SMTP Server) with ESMTP id D50041C000A1
	for <cldr-users@unicode.org>; Fri,  1 Jun 2007 15:41:07 +0200 (CEST)
X-ME-UUID: 20070601134107872.D50041C000A1@mwinf1928.orange.fr
From: "Philippe Verdy" <verdy_p@wanadoo.fr>
To: <cldr-users@unicode.org>
References: <018f01c7a422$08ea3ac0$0a01a8c0@rodage.dyndns.org> <049003D9-E17B-4168-87DE-14D741876ED4@icu-project.org>
Subject: RE: TR: CLDR 1.5 beta/Unicode 5.0: character fallback substitutions
Date: Fri, 1 Jun 2007 15:41:04 +0200
Organization: Ordinateur Personnel
Message-ID: <01a901c7a452$8070fb30$0a01a8c0@rodage.dyndns.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <049003D9-E17B-4168-87DE-14D741876ED4@icu-project.org>
Thread-Index: AcekOjZVVirez1ZYQu6V6n1ejl1q7AAFbwVw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-archive-position: 147
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: verdy_p@wanadoo.fr
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

Steven R. Loomis wrote:
> the code fallbacks simply mean there is no localized data. "W/" or "Ps"
> won't always make sense. Imagine a user in [pick your favorite language]
in
> [pick your favorite territory or country]. Will "4W" or "9Ps" make sense
> to them? If they guess that Ps is Peso, whose peso or peseta?

But this fallback is already using an arbitrary territory, despite the
symbol is just a symbol for the Peso sign, and does NOT designate the
Philippins Peso, just a Peso (so making a fallback to PHP is NON-SENSE).

> If KRW and KRP fall back to W/ then they aren't distinguished. 

The Won symbol does NOT make this distinction; if the won symbol is used in
a North Korean document, why would it fallback to KRW instead of KPW? "W/"
says nothing more than what the original won symbol indicates. If an author
really wants to make the distinction in the original text, he will use KPW
or KRW or a complete name where appropriate but will not use the symbol.

Now imagine what would happen to a commercial North-Korean billing or
contract that displays now KRW instead of the expected symbol: this billing
would indicate that it must be paid in South-Korean Won, i.e. would require
making currency changes. Such thing is NOT expected.

The won symbol is not indicating the precise country, it's just a W with a
stroke that means a currency unit (whose meaning is context dependant), and
"W/" is a W with a stroke (whose meaning is also context-dependant).

> Unless a cultural preference (i.e. common use) actually uses a symbol
> and makes sense of it, it is far better to simply fall back to the code
> - it is at least unambiguous.

The original symbols ARE ambiguous, a display fallback mechanism CANNOT
infer things from just the character.

> They may not know KRP or PHP (especially
> if they do not use latin letters primarily), but at least the letters
> might make sense to someone. 

If they can read PHP or KRW and make sense with it, then they can make sense
with "Ps" or "W/" which uses the same Latin letters and looks very similar
to the original symbol.

> so in other words, they are localizable, but they shouldn't be localized
where they won't be intelligible to the user community.

I see absolutely NO way to resolve the meaning of the local generic symbol
into a precise currency code! The same texts in the same locale can still
read "peso" or "won" but will not even indicate if this is a Philippan Peso
or a North-Korean Won as this does NOT depend on the locale of the user
reading it, but on the locale of the person composing the text. Fallback
characters are intended for reading, i.e. for rendering only, not for
conversion and transmission.

We are not defining here locale data for a precise country, just generic
fallbacks for isolated characters, and it's impossible to disambiguate it
without introducing an interpretation error with an added precision that is
NOT part of the original text that just contains the symbols.




From mark.edward.davis@gmail.com Fri Jun  1 10:41:40 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 01 Jun 2007 10:41:40 -0500 (CDT)
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.229])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l51Ffdxv030426
	for <cldr-users@unicode.org>; Fri, 1 Jun 2007 10:41:39 -0500
Received: by nz-out-0506.google.com with SMTP id q3so529713nzb
        for <cldr-users@unicode.org>; Fri, 01 Jun 2007 08:41:36 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=ju3oBS6+1768xSrX+Q+G8vl1RSsaB3EZ5KaUFYBVuV47bGClDr1boVtS9oPz722/MdXLNxkq1fdpGLOG57JnTywidm60ds9av/Soq8tjtCuEgEZkpkR5s7Mx3dy4O+ozOpdUOgeljGcsIC3wlznPVADnxwGablIzSq1LrVs3aj8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=jn5zZGxZdOdp0CKQgDwpuVmrF1Hjj1tkMWzW95ckq5oyehSTmJNMY4/VqoKv1eQ85/8eB4lDzciUIfq+toVjHZoGtgN3Ba2coApyL3L9oi8f5o/5O8tV/bf0aT6rVsU6idkpvWD4aTWCPZo5eo21309plAbhoEjNl7Ag4ixHWHA=
Received: by 10.114.52.1 with SMTP id z1mr1873019waz.1180712496161;
        Fri, 01 Jun 2007 08:41:36 -0700 (PDT)
Received: by 10.114.192.10 with HTTP; Fri, 1 Jun 2007 08:41:36 -0700 (PDT)
Message-ID: <30b660a20706010841v3827a043ped6a3bec8c014835@mail.gmail.com>
Date: Fri, 1 Jun 2007 08:41:36 -0700
From: "Mark Davis" <mark.davis@icu-project.org>
To: cldr-users@unicode.org
Subject: Re: TR: CLDR 1.5 beta/Unicode 5.0: character fallback substitutions
Cc: verdy_p@wanadoo.fr
In-Reply-To: <3D052493-9BEC-4F3F-AA5F-258F409B40DF@icu-project.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_9919_24044873.1180712496112"
References: <018f01c7a422$08ea3ac0$0a01a8c0@rodage.dyndns.org>
	 <3A96D8C9-AF2A-4FEF-8AEE-8B29C3154EDE@icu-project.org>
	 <019701c7a431$53d29190$0a01a8c0@rodage.dyndns.org>
	 <3D052493-9BEC-4F3F-AA5F-258F409B40DF@icu-project.org>
X-Google-Sender-Auth: 15c80ad237dcffda
X-archive-position: 148
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: mark.davis@icu-project.org
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

------=_Part_9919_24044873.1180712496112
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Some additions below.

On 6/1/07, Steven R. Loomis <srl@icu-project.org> wrote:
[snip]

> ==== About the CLDR online forums ====
> >
> > And apparently, the messages in the CLDR online forums are not read
> > (not
> > even by CLDR TC members), or too few vetters notice this message
> > area: I
> > have posted many messages or comments there for the specific locale
> > I was
> > providing data (French), and nobody replied there.
>
>   They are read, and as of today, they also send email notifications
> when a change occurs. We will be sending out instructions for the RSS
> readers to be able to view the forums, as well.


One additional note: the forums are directed at vetters in the particular
languages. We have been trying various methods to help the communication
between those people, but it is up to those language vetters to take
advantage of it.

There are multiple channels for communication:

   1.  The TC mailing list
   2.  This user list
   3.  Sending to translators through the survey tool.
   4.  The forums.

We try not to overload 2-4, since we don't want people to feel like they are
getting spammed with unnecessary mail. We just recently got the RSS feeds up
-- and the email notification on the forums is due to go online for the
vetting phase. We're also going to make it easier to send announcements to
the translators.

[snip]


> >
> > The CLDR project was much more reactive when it was part of the
> > IBM's ICU
> > project. But now, even IBM does not seem to follow the ongoing work
> > (I only
> > see Apple...), so my feeling is that the CLDR TC is nearly
> > inexistent or not
> > functional, with a precise working schedule, and meetings: its
> > members seem
> > to be mostly busy working on the Unicode standard itself (and in
> > fact, I do
> > think that all active CLDR TC members are part of the Unicode TC
> > andhave
> > forgotten their work for the CLDR project)
>
>   I am an IBM employee and follow CLDR extremely closely, and there
> are others.  The CLDR TC is extremely active and conducts lengthy
> meetings with half a dozen people or more weekly.  Again, I don't
> know by what metric you see the TC as being non-existent or non-
> functional.
>
>   what is CLDR not reacting to?
>
>   perhaps CLDR does not put out the perception that much work by many
> people is going on, but it is indeed the case, I can assure you.


I can as well. The technical committee meets every week, almost without
exception, and a good number of people spend quite a bit of time on this
project. It is a sizable project, and the management of the data and
development of the tools takes quite a bit of time. It doesn't not always
function as well as we'd like, but the tool is not intended to be a
commercial product. We try to make it as good as we can, but must always ask
for the translators indulgence when problems arise. Part of the reason we
have long data submission phases is to allow for tool outages and load
balancing.


>
> > My feeling is that CLDR 1.5 beta should only be restarted very soon
> > and not
> > released for more than one year: there are too many errors that the
> > current
> > freeze will NOT allow to correct due to not enough vetters.
>
>   please give some specifics on why you think it should be restarted
> or where you see errors cropping up.


It would be very useful for you to list the kinds of items where you have
having problems. However, let's be clear that until the vetting period
starts, I wouldn't expect all the French vetters to have looked over the
disputed items -- that's exactly what the vetting phase is for. We have also
recently put into place the resolution process that we are planning to use
for this release, on
http://unicode.org/cldr/process.html#data_vetting_process. It was announced,
but some small further changes were made, and some more may be made as we go
through this vetting period. Note that you (or others) will still be able to
add proposals wherever there are multiple proposed items.

-- 
Mark

------=_Part_9919_24044873.1180712496112
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Some additions below.<br><br><div><span class="gmail_quote">On 6/1/07, <b class="gmail_sendername">Steven R. Loomis</b> &lt;<a href="mailto:srl@icu-project.org">srl@icu-project.org</a>&gt; wrote:</span><div><br>[snip] <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; ==== About the CLDR online forums ====<br>&gt;<br>&gt; And apparently, the messages in the CLDR online forums are not read
<br>&gt; (not<br>&gt; even by CLDR TC members), or too few vetters notice this message<br>&gt; area: I<br>&gt; have posted many messages or comments there for the specific locale<br>&gt; I was<br>&gt; providing data (French), and nobody replied there.
<br><br>&nbsp;&nbsp;They are read, and as of today, they also send email notifications<br>when a change occurs. We will be sending out instructions for the RSS<br>readers to be able to view the forums, as well.</blockquote><div><br>
One additional note: the forums are directed at vetters in the particular languages. We have been trying various methods to help the communication between those people, but it is up to those language vetters to take advantage of it.
<br><br>There are multiple channels for communication: <br><ol><li>&nbsp;The TC mailing list</li><li>&nbsp;This user list</li><li>&nbsp;Sending to translators through the survey tool.</li><li>&nbsp;The forums.</li></ol>We try not to overload 2-4, since we don&#39;t want people to feel like they are getting spammed with unnecessary mail. We just recently got the RSS feeds up -- and the email notification on the forums is due to go online for the vetting phase. We&#39;re also going to make it easier to send announcements to the translators.
<br><br>[snip]<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>&gt;<br>&gt; The CLDR project was much more reactive when it was part of the
<br>&gt; IBM&#39;s ICU<br>&gt; project. But now, even IBM does not seem to follow the ongoing work<br>&gt; (I only<br>&gt; see Apple...), so my feeling is that the CLDR TC is nearly<br>&gt; inexistent or not<br>&gt; functional, with a precise working schedule, and meetings: its
<br>&gt; members seem<br>&gt; to be mostly busy working on the Unicode standard itself (and in<br>&gt; fact, I do<br>&gt; think that all active CLDR TC members are part of the Unicode TC<br>&gt; andhave<br>&gt; forgotten their work for the CLDR project)
<br><br>&nbsp;&nbsp;I am an IBM employee and follow CLDR extremely closely, and there<br>are others.&nbsp;&nbsp;The CLDR TC is extremely active and conducts lengthy<br>meetings with half a dozen people or more weekly.&nbsp;&nbsp;Again, I don&#39;t<br>
know by what metric you see the TC as being non-existent or non-<br>functional.<br><br>&nbsp;&nbsp;what is CLDR not reacting to?<br><br>&nbsp;&nbsp;perhaps CLDR does not put out the perception that much work by many<br>people is going on, but it is indeed the case, I can assure you.
</blockquote><div><br>I can as well. The technical committee meets every week, almost without exception, and a good number of people spend quite a bit of time on this project. It is a sizable project, and the management of the data and development of the tools takes quite a bit of time. It doesn&#39;t not always function as well as we&#39;d like, but the tool is not intended to be a commercial product. We try to make it as good as we can, but must always ask for the translators indulgence when problems arise. Part of the reason we have long data submission phases is to allow for tool outages and load balancing.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>&gt; My feeling is that CLDR 1.5 beta should only be restarted very soon
<br>&gt; and not<br>&gt; released for more than one year: there are too many errors that the<br>&gt; current<br>&gt; freeze will NOT allow to correct due to not enough vetters.<br><br>&nbsp;&nbsp;please give some specifics on why you think it should be restarted
<br>or where you see errors cropping up.</blockquote><div><br>It would be very useful for you to list the kinds of items where you have having problems. However, let&#39;s be clear that until the vetting period starts, I wouldn&#39;t expect all the French vetters to have looked over the disputed items -- that&#39;s exactly what the vetting phase is for. We have also recently put into place the resolution process that we are planning to use for this release, on  
<a href="http://unicode.org/cldr/process.html#data_vetting_process" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://unicode.org/cldr/process.html#data_vetting_process</a>. It was announced, but some small further changes were made, and some more may be made as we go through this vetting period. Note that you (or others) will still be able to add proposals wherever there are multiple proposed items.
<br clear="all"></div></div><br>-- <br>Mark

------=_Part_9919_24044873.1180712496112--

From mark.edward.davis@gmail.com Fri Jun  1 11:01:07 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 01 Jun 2007 11:01:07 -0500 (CDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l51G157Z013094
	for <cldr-users@unicode.org>; Fri, 1 Jun 2007 11:01:06 -0500
Received: by wa-out-1112.google.com with SMTP id j4so536078wah
        for <cldr-users@unicode.org>; Fri, 01 Jun 2007 09:01:05 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=dE0QTwhLlqOz36MhGBD37jmv6VchlpAWoL4mJWWKLUo0aLiVZZJ2LNRlwCxkIp1HVIZQMElvXzM7gSMJifTN/ret169PTNBrnGm+QbIcHxWwCx2h543l3Iv6idCBHtjizVqGaBgHBgMluvdZ7abLDwCy2SLFpo8hL1e6e6kEQLA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=cgT1lhikisHMAhbPtfBQuyvD4kG982L1r60UUVdUW1HPfISLngdI+ITJlImwEPa1FTTA7EKbd99DtTYTClBArBJQIfMjkQQLOofRcZoaBPnlWBLdWjSWGWTeq9YpvYL/JGoRxYO2zcdA4MJ4EHz5L3NmKxnd6wNHQZyjOyeqlzg=
Received: by 10.114.27.20 with SMTP id a20mr1906830waa.1180713665251;
        Fri, 01 Jun 2007 09:01:05 -0700 (PDT)
Received: by 10.114.192.10 with HTTP; Fri, 1 Jun 2007 09:01:05 -0700 (PDT)
Message-ID: <30b660a20706010901k4c429ba4kcd7fc2f092e501ec@mail.gmail.com>
Date: Fri, 1 Jun 2007 09:01:05 -0700
From: "Mark Davis" <mark.davis@icu-project.org>
To: cldr-users@unicode.org
Subject: Re: Resolution process
Cc: Unicode <unicode@unicode.org>, "CLDR list" <cldr@unicode.org>
In-Reply-To: <012201c7a2dd$8609a680$0a01a8c0@rodage.dyndns.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_10403_25051488.1180713665216"
References: <30b660a20705290936v4e249b58x7f2064a87d77e35b@mail.gmail.com>
	 <012201c7a2dd$8609a680$0a01a8c0@rodage.dyndns.org>
X-Google-Sender-Auth: 7db1c93ed1a034dc
X-archive-position: 149
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: mark.davis@icu-project.org
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

------=_Part_10403_25051488.1180713665216
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Actually, I will answer a few items here, just to prevent any
misunderstandings, but any responses should go to the cldr-users list.

On 5/30/07, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
>
>  There are disputed entries that were part of CLDR 1.4 by error : it was
> not even possible to avoid them to be released, because the proposal period
> for CLDR 1.4 was extremely short (about one month), it was not announced
> clearly in advanced (a single message posted to the Unicode list, that was
> not delivered to every one), and then inaccessible for a part of that period
> (lots of technical problems of performance on the server, even during that
> period).
>
>
>
> The result was that the CLDR 1.4 contained many entries fro which it was
> later impossible to vote AGAINST their addition.
>

This is not the case. Previous values can be overridden; see the process
documentation.


> I have made several comments on the CLDR forum about the other problems
> that the system does: lack of consistency between multiple entries is
> another problem, notably for naming conventions:
>
> * how to insert less-significant words for language names in lists (words
> like "languages" used for the names of language families or groups, using
> commas)?
>
> * how to consistantly use singular or plural, use of neutral or feminine
>
> * how to differentiate names for use in isolation within text, or in short
> form (like in data tables), or in long lists for input forms (like
> combo-boxes, where languages should be sorted)
>
> * how to indicate language qualifiers (using parentheses, which may be
> optionally removed, like dates)?
>
> * how to indicate acceptable language name variants (there are multiple
> names even in reference documents like ISO standards, and the Unicode
> standard itself), and a "preferred" name that does not exclude the other
> names as incorrect?
>
> * how to identify special names (such as [mis]="miscellaneous languages",
> or [root]="Root"): should they be made easily distinctable in lists?
>

These are good issues to bring up. Where you have general questions on
overall policies, those should be addressed to the cldr-users list, not to
the forums.

The forums are new to this release, and are intended to provide another
channel of communication. However, until the start of the vetting phase,
they have not had RSS feeds or email notification, so the translators for
particular languages may not be seeing the postings that have been made.


> Note that unfortunately, if some alternate proposals were made, they were
> DELETED recently from the CLDR if they currently had no vote for them when
> the proposal phase was ended.
>
We had changed the process for 1.5 so that if anyone votes on an item, it
will be retained for the next release.


> Really, if there remains disputed entries, there should be a review at end
> by the CLDR comity, that will read the posted comments in the forum, will
> consider not only the votes but what was the nature of the different
> proposals and why they were made (a simple automatic voting system can't
> track that).
>

The forums are provided for the translators. The committee can make
decisions on the items, but will not be reading each and every forum entry.
If near the end of the vetting period you still believe that there are
significant problems in the data, you should file one bug listing those key
items, and the committee will consider them.

The committee has a weekly meeting, and does review all of the bugs that are
submitted. However, if the bug is long and convoluted, it is too difficult
for the committee to assess correctly and give it the proper consideration.
So I cannot stress too much to make each communication as short and to the
point as possible.

-- 
Mark

------=_Part_10403_25051488.1180713665216
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Actually, I will answer a few items here, just to prevent any misunderstandings, but any responses should go to the cldr-users list.<br><br><div><span class="gmail_quote">On 5/30/07, <b class="gmail_sendername">Philippe Verdy
</b> &lt;<a href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">










<div link="blue" vlink="blue" lang="FR">

<div>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">There are disputed
entries that were part of CLDR 1.4 by error&nbsp;: it was not even possible to
avoid them to be released, because the proposal period for CLDR 1.4 was
extremely short (about one month), it was not announced clearly in advanced (a
single message posted to the Unicode list, that was not delivered to every
one), and then inaccessible for a part of that period (lots of technical problems
of performance on the server, even during that period).</span></font></p>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">&nbsp;</span></font></p>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">The result was that the
CLDR 1.4 contained many entries fro which it was later impossible to vote
AGAINST their addition.</span></font></p></div></div></blockquote><div><br>This is not the case. Previous values can be overridden; see the process documentation.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="blue" lang="FR"><div><br><p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">I have made several
comments on the CLDR forum about the other problems that the system does: lack
of consistency between multiple entries is another problem, notably for naming conventions:</span></font></p>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">* how to insert less-significant
words for language names in lists (words like "languages" used for the names of
language families or groups, using commas)?</span></font></p>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">* how to consistantly use
singular or plural, use of neutral or feminine</span></font></p>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">* how to differentiate
names for use in isolation within text, or in short form (like in data tables),
or in long lists for input forms (like combo-boxes, where languages should be
sorted)</span></font></p>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">* how to indicate language
qualifiers (using parentheses, which may be optionally removed, like dates)?</span></font></p>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">* how to indicate acceptable
language name variants (there are multiple names even in reference documents
like ISO standards, and the Unicode standard itself), and a "preferred" name
that does not exclude the other names as incorrect?</span></font></p>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">* how to identify special
names (such as [mis]="miscellaneous languages", or [root]="Root"): should they
be made easily distinctable in lists?</span></font></p></div></div></blockquote><div><br>These are good issues to bring up. Where you have general questions on overall policies, those should be addressed to the cldr-users list, not to the forums.
<br><br>The forums are new to this release, and are intended to provide another channel of communication. However, until the start of the vetting phase, they have not had RSS feeds or email notification, so the translators for particular languages may not be seeing the postings that have been made.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="blue" lang="FR"><div><br><p><font color="navy" face="Arial" size="2">
<span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">Note that unfortunately,
if some alternate proposals were made, they were DELETED recently from the CLDR
if they currently had no vote for them when the proposal phase was ended. </span></font></p></div></div></blockquote><div>We had changed the process for 1.5 so that if anyone votes on an item, it will be retained for the next release. 
<br>&nbsp;</div><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB"></span></font><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="blue" lang="FR"><div>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">Really, if there remains
disputed entries, there should be a review at end by the CLDR comity, that will
read the posted comments in the forum, will consider not only the votes but
what was the nature of the different proposals and why they were made (a simple
automatic voting system can't track that).</span></font></p></div></div></blockquote><div><br>The forums are provided for the translators. The committee can make decisions on the items, <span style="font-weight: bold;">but will 
</span><span style="font-style: italic; font-weight: bold;">not </span><span style="font-weight: bold;">be reading each and every forum entry</span>. If near the end of the vetting period you still believe that there are significant problems in the data, you should file one bug listing those key items, and the committee will consider them.
<br><br>The committee has a weekly meeting, and does review all of the bugs that are submitted. However, if the bug is long and convoluted, it is too difficult for the committee to assess correctly and give it the proper consideration. So I cannot stress too much to make each communication as short and to the point as possible.
<br></div></div><br>-- <br>Mark

------=_Part_10403_25051488.1180713665216--

From rick@unicode.org Fri Jun  1 12:08:48 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 01 Jun 2007 12:08:48 -0500 (CDT)
Received: from izanami (c-67-188-204-169.hsd1.ca.comcast.net [67.188.204.169])
	by unicode.org (8.13.4/8.12.11) with SMTP id l51H8mao032141
	for <cldr-users@unicode.org>; Fri, 1 Jun 2007 12:08:48 -0500
Message-Id: <200706011708.l51H8mao032141@unicode.org>
To: cldr-users@unicode.org
Subject: RE: TR: CLDR 1.5 beta/Unicode 5.0: character fallback substitutions
In-Reply-To: <3A96D8C9-AF2A-4FEF-8AEE-8B29C3154EDE@icu-project.org>
Date: Fri, 1 Jun 2007 10:08:48 -0700
From: Rick McGowan <rick@unicode.org>
received: by Apple.Mailer (2.95.2)
X-archive-position: 150
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: rick@unicode.org
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

Philippe --

> It's quite bad that such issues are rejected from the general
> Unicode list

They aren't "rejected". The issues you raised are more appropriate here.

> (I got a warning from Kenneth Whistler that moderated my
> message),

He did not "moderate your message". Your message went to the list, he  
simply replied and pointed you here.

> That's not the first time that I try to send messages to the
> CLDR list, and nobody detects that it is not working as expected.

All of our mail lists are working as expected. You are not on the  
cldr@unicode.org list, so nothing you try to send there will go to that  
list. You have to be a subscriber to a list before you can send mail to it.

	Rick

From verdy_p@wanadoo.fr Fri Jun  1 12:55:44 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 01 Jun 2007 12:55:44 -0500 (CDT)
Received: from smtp2e.orange.fr (smtp2e.orange.fr [80.12.242.112])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l51HthZd031244;
	Fri, 1 Jun 2007 12:55:43 -0500
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf2e13.orange.fr (SMTP Server) with ESMTP id CBD3D700008F;
	Fri,  1 Jun 2007 19:55:37 +0200 (CEST)
Received: from HARNON (APoitiers-156-1-51-76.w86-217.abo.wanadoo.fr [86.217.146.76])
	by mwinf2e13.orange.fr (SMTP Server) with ESMTP id 80FD47000082;
	Fri,  1 Jun 2007 19:55:37 +0200 (CEST)
X-ME-UUID: 20070601175537528.80FD47000082@mwinf2e13.orange.fr
From: "Philippe Verdy" <verdy_p@wanadoo.fr>
To: "'Mark Davis'" <mark.davis@icu-project.org>, <cldr-users@unicode.org>
Cc: "'Unicode'" <unicode@unicode.org>, "'CLDR list'" <cldr@unicode.org>
References: <30b660a20705290936v4e249b58x7f2064a87d77e35b@mail.gmail.com> <012201c7a2dd$8609a680$0a01a8c0@rodage.dyndns.org> <30b660a20706010901k4c429ba4kcd7fc2f092e501ec@mail.gmail.com>
Subject: RE: Resolution process
Date: Fri, 1 Jun 2007 19:55:34 +0200
Organization: Ordinateur Personnel
Message-ID: <001701c7a476$0dd3f7c0$0a01a8c0@rodage.dyndns.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <30b660a20706010901k4c429ba4kcd7fc2f092e501ec@mail.gmail.com>
Thread-Index: AcekbPxRV8++YWQPRtaPoMOqmY/92QAA/d+Q
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l51HthZd031244
X-archive-position: 151
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: verdy_p@wanadoo.fr
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

Mark Davis wrote:

> On 5/30/07, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
>> There are disputed entries that were part of CLDR 1.4 by error :
>> it was not even possible to avoid them to be released, because
>> the proposal period for CLDR 1.4 was extremely short (about one month),
>> it was not announced clearly in advanced (a single message posted 
>> to the Unicode list, that was not delivered to every one), and then
>> inaccessible for a part of that period (lots of technical problems
>> of performance on the server, even during that period).
>> The result was that the CLDR 1.4 contained many entries fro which it was
later impossible to vote AGAINST their addition.
>
> This is not the case. Previous values can be overridden;
> see the process documentation.

Actually I know that I can *propose* an override and vote for it, but with
the current automated minimum ratios needed to perform a change, it will be
difficult to change something with just two votes in favour of the change,
even if the previous data was an error, and this is explained in a bug
report (or in the online CLDR forum, now viewable also in the RSS feed).

So I fear that a lot of English terms that were standardized in CLDR 1.4
(for which I vote against before the CLDR 1.4 release, because I could not
even make an alternative proposal, as the submission phase was so much
unusable before it was closed), will still persist in CLDR 1.5, because
there won't be enough votes to overturn the current value. Many entries in
CLDR 1.4 did not even reach any minimum consensus: all we could do was to
vote against them, but it was too late and a single vote from the initial
proposer was accepted and put into the release because of absence of an
alternative

This was a major problem last year, and this past release received very
negative opinions, or it has been used now in several projects as if they
were effectively right. We can still see today, people trying to change
correct data by replacing it with the incorrect data because it was part of
the CLDR 1.4 release.

I had lot of works to do (and needed lot of patience, with submission times
in the tool that took sometimes 12 minutes to complete for a single change
since the end of April... any change was overloading the server for several
minutes, so I had to wait and perform most of the work in the middle of the
night when the server was finally accessible) trying to catch all those
errors and completing many new entries for French, and proposing several
alternatives that vetters could also support (this means that some of my
submissions were acceptable for me, but I voted for another one that I still
prefer).

There remains proposals that could not be deleted (they keep one vote on
them, because apparently my own account used a different numeric vetter id
that has changed over time, or because of possible past SQL bugs in the CLDR
tool). The addition of a DELETE option (for entries we were alone to
propose) came very late (but it was really needed to avoid creating
confusion among vetters, as nobody would really want to vote for these
bogous inputs.

(Note that blank votes are still not counted as votes against all existing
proposals, it is considered like "no opinion, every other vote is
acceptable, vetters should still have the possibility to cast their vote
explicitly for a "vote against all these proposals" option, counted like
other explicit proposals: if this option gets the majority, then no proposal
will be accepted in the release before a final consensus is asked directly
to vetters within the forum; for now, all we can do is to discuss the
problematic item in the forum/RSS feed).





From lafriks@gmail.com Sat Jun  2 01:46:23 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Sat, 02 Jun 2007 01:46:24 -0500 (CDT)
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l526kNms003909
	for <cldr-users@unicode.org>; Sat, 2 Jun 2007 01:46:23 -0500
Received: by py-out-1112.google.com with SMTP id d32so1505776pye
        for <cldr-users@unicode.org>; Fri, 01 Jun 2007 23:46:20 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=hFzb5zwdDuK5A2TnUJGV251qUcaoKcJ/ojh6gBE4jvIB+764TP9g4tbBuINt/ji0q5y1TICPPGjWbd9bF+1SkVRh14BDHbHEu0qb5AaFa+otGOi2VRshOFBLiz/45LsJfgJPbj3mRauGupoLnKeBAg+4ZNJOmnDs4sC9WIjidY4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=hWPOwYI6PidSTUQJSkOyZaK4VODypL6dY1CiELVDw8PLN4Pjx+QSuoTeg9V6HtXhbTVqlRL/eE/4AJnYocx+oKt7oktkc6UFNpb/KVDj/zbqHIE+NS6nJSqOZ3DqfQplGI7A7JlvDEUEFx2cDejzsQaWBm7U9Ze8XsFzs+/5DKk=
Received: by 10.115.72.1 with SMTP id z1mr2654748wak.1180766779278;
        Fri, 01 Jun 2007 23:46:19 -0700 (PDT)
Received: by 10.114.57.17 with HTTP; Fri, 1 Jun 2007 23:46:19 -0700 (PDT)
Message-ID: <890f9ce10706012346y3d37e16k1618a4f151c322e7@mail.gmail.com>
Date: Sat, 2 Jun 2007 09:46:19 +0300
From: "=?WINDOWS-1252?Q?Lauris_Buk=9Ais-Haberkorns?=" <lafriks@gmail.com>
To: cldr-users <cldr-users@unicode.org>
Subject: Votes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by unicode.org id l526kNms003909
X-archive-position: 152
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: lafriks@gmail.com
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

There is one thing I can not understand. For many Latvian locale
territories the green one is the wrong one with one vote while correct
one with two votes is not.
There are official translations of territories:
http:​/​/www.latvijasvestnesis.lv​/index.php?menu_body=DOC​&id=140081

How this can be?

-- 
Lafriks =)


From verdy_p@wanadoo.fr Sat Jun  2 07:49:18 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Sat, 02 Jun 2007 07:49:18 -0500 (CDT)
Received: from smtp2e.orange.fr (smtp2e.orange.fr [80.12.242.112])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l52CnHPb028392
	for <cldr-users@unicode.org>; Sat, 2 Jun 2007 07:49:18 -0500
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf2e06.orange.fr (SMTP Server) with ESMTP id 3C05A700008D
	for <cldr-users@unicode.org>; Sat,  2 Jun 2007 14:49:12 +0200 (CEST)
Received: from HARNON (APoitiers-156-1-51-76.w86-217.abo.wanadoo.fr [86.217.146.76])
	by mwinf2e06.orange.fr (SMTP Server) with ESMTP id F0B1E700008C
	for <cldr-users@unicode.org>; Sat,  2 Jun 2007 14:49:11 +0200 (CEST)
X-ME-UUID: 20070602124911985.F0B1E700008C@mwinf2e06.orange.fr
From: "Philippe Verdy" <verdy_p@wanadoo.fr>
To: <cldr-users@unicode.org>
References: <890f9ce10706012346y3d37e16k1618a4f151c322e7@mail.gmail.com>
Subject: RE: Votes
Date: Sat, 2 Jun 2007 14:49:07 +0200
Organization: Ordinateur Personnel
Message-ID: <005701c7a514$68fc90a0$0a01a8c0@rodage.dyndns.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <890f9ce10706012346y3d37e16k1618a4f151c322e7@mail.gmail.com>
Thread-Index: Acek4xT8pTo9xDEFRbGzho7bYjUODwAML8cw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l52CnHPb028392
X-archive-position: 153
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: verdy_p@wanadoo.fr
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

You must also consider the votes of CLDR TC organisation members (weight apparently doubled), shown below the other votes, and the fact that locales that were already part os CLDR 1.4 need a higher number of votes for overriding it. Read the rules about the needed quorums.

If there's really problems, add comments into the online CLDR forum (also readable through RSS feed) justifying the change, sothat CLDR TC members will take special attention to that entry when approving the final release.
In fact, with this comment, you may initiate further votes from CLDR TC members, and manual updates before release will not be necessary.

> -----Message d'origine-----
> De : cldr-users-bounce@unicode.org [mailto:cldr-users-bounce@unicode.org]
> De la part de Lauris Bukšis-Haberkorns
> Envoyé : samedi 2 juin 2007 08:46
> À : cldr-users
> Objet : Votes
> 
> There is one thing I can not understand. For many Latvian locale
> territories the green one is the wrong one with one vote while correct
> one with two votes is not.
> There are official translations of territories:
> http:​/​/www.latvijasvestnesis.lv​/index.php?menu_body=DOC​&id=140081





From lafriks@gmail.com Sat Jun  2 07:53:17 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Sat, 02 Jun 2007 07:53:17 -0500 (CDT)
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l52CrH8J029769
	for <cldr-users@unicode.org>; Sat, 2 Jun 2007 07:53:17 -0500
Received: by py-out-1112.google.com with SMTP id d32so1635347pye
        for <cldr-users@unicode.org>; Sat, 02 Jun 2007 05:53:17 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=eEE0HP757Lr7HFnF374eYxU+NEQ+P39fhW9lW/Lww74gj++G3VUoAOE5Gav17T0JABtvlJbO047n/9xTD0OEQ8/5sAPxqQRzI87OMDabzUUPgfD/ceTCfMMPW4RH4U7wVuZ5Q9cc7LohcZk3WLRhhuu3zhlDl5R9nSvAhX52ZSw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=mOJyvf4tWWdoBoqOQSoC35D/dB6Hi7Xx8T8ZSX0aEX2VwhSEP8gTot9PgbPNRPczZZHI5b53PHRv7HnYS+EK1sqY/9RvcGJD4xqW931KKSFcfB9rLUce/dWU69rmvMH9D+LOYT6UUZHGLXR3GsbA2OK6/yIf/lMobVz3GHXq2jQ=
Received: by 10.114.109.1 with SMTP id h1mr2871955wac.1180788793155;
        Sat, 02 Jun 2007 05:53:13 -0700 (PDT)
Received: by 10.114.57.17 with HTTP; Sat, 2 Jun 2007 05:53:13 -0700 (PDT)
Message-ID: <890f9ce10706020553n7684340aj64b06d122dbb2585@mail.gmail.com>
Date: Sat, 2 Jun 2007 15:53:13 +0300
From: "=?WINDOWS-1252?Q?Lauris_Buk=9Ais-Haberkorns?=" <lafriks@gmail.com>
To: cldr-users@unicode.org
Subject: Re: Votes
In-Reply-To: <005701c7a514$68fc90a0$0a01a8c0@rodage.dyndns.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Disposition: inline
References: <890f9ce10706012346y3d37e16k1618a4f151c322e7@mail.gmail.com>
	 <005701c7a514$68fc90a0$0a01a8c0@rodage.dyndns.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by unicode.org id l52CrH8J029769
X-archive-position: 154
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: lafriks@gmail.com
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

ok, lets hope so.

On 6/2/07, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
> You must also consider the votes of CLDR TC organisation members (weight apparently doubled), shown below the other votes, and the fact that locales that were already part os CLDR 1.4 need a higher number of votes for overriding it. Read the rules about the needed quorums.
>
> If there's really problems, add comments into the online CLDR forum (also readable through RSS feed) justifying the change, sothat CLDR TC members will take special attention to that entry when approving the final release.
> In fact, with this comment, you may initiate further votes from CLDR TC members, and manual updates before release will not be necessary.
>
> > -----Message d'origine-----
> > De : cldr-users-bounce@unicode.org [mailto:cldr-users-bounce@unicode.org]
> > De la part de Lauris Bukšis-Haberkorns
> > Envoyé : samedi 2 juin 2007 08:46
> > À : cldr-users
> > Objet : Votes
> >
> > There is one thing I can not understand. For many Latvian locale
> > territories the green one is the wrong one with one vote while correct
> > one with two votes is not.
> > There are official translations of territories:
> > http:​/​/www.latvijasvestnesis.lv​/index.php?menu_body=DOC​&id=140081
>
>
>
>
>
>


-- 
Lafriks =)


From dzo@bisharat.net Sun Jun  3 16:02:22 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Sun, 03 Jun 2007 16:02:22 -0500 (CDT)
Received: from kabissa.org (113166.kabissa.org [72.32.199.201])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l53L2Mr4008129
	for <cldr-users@unicode.org>; Sun, 3 Jun 2007 16:02:22 -0500
Received: (qmail 32247 invoked from network); 3 Jun 2007 16:02:22 -0500
Received: from 67.sui208.atln.attga31ur.dsl.att.net (HELO IBM92AA25595C4) (12.134.208.67)
  by 72.32.229.137 with SMTP; 3 Jun 2007 16:02:21 -0500
From: "Don Osborn" <dzo@bisharat.net>
To: <verdy_p@wanadoo.fr>
Cc: <cldr-users@unicode.org>
References: <E1Htm4H-0006YL-Nh@zendro.geez.org> <017101c7a3be$c63738d0$0a01a8c0@rodage.dyndns.org> <023901c7a3c6$fabeaa40$f03bfec0$@net> <017701c7a3e4$c1988e20$0a01a8c0@rodage.dyndns.org>
In-Reply-To: <017701c7a3e4$c1988e20$0a01a8c0@rodage.dyndns.org>
Subject: CLDR and diversity of locales (not) filed
Date: Sun, 3 Jun 2007 17:02:17 -0400
Message-ID: <003f01c7a622$7845aec0$68d10c40$@net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcejnimDs7SDoazeQ7K155taR6E4bgAH7hOQAAEIZNAABot54ACMS+Eg
Content-Language: en-us
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l53L2Mr4008129
X-archive-position: 155
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: dzo@bisharat.net
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

Philippe posted this on Unicode@unicode.org and I hope it's okay with him
and all to repost it here with a few comments (including a couple in the
text).

This message calls to mind several issues. First, I think that it is not the
general rule to develop locales for any international language spoken
anywhere, but only for languages (1) indigenous to particular countries or
(2) present there with a particular character in that country. 

Second, while agreeing on the general point that there are many locales that
need to be written, I am cautious about listing "missing locales" without a
clear idea of the need and situation of each. This is especially the case
where people doing the listing have some info but neither an expertise nor
significant first-hand familiarity with the language situations in question.
Part of the reason is the potential errors. Another part is that,
particularly for many languages with complex dialect situations (such as
quite a few in Africa), the existing language tags (in ISO-639) are not
necessarily ideal for locales and localization. The latter cases need
attention by experts - and that is not to slow things down, but to appeal
for bringing such experts into the process more proactively.

And third, a "meta" observation. This discussion began on the Unicode list,
and I repost here, but it also has to do with language tagging issues dealt
with on ietf-langauges and ltru lists. I will refrain from crossposting
there, but for me it's another illusration of how these issues cross
boundaries and issues that seem to relate specifically to one domain (such
as locales) quickly link to other issues. Again, that's not to slow work
down, but to appeal for awareness.

Don



> -----Original Message-----
> From: Philippe Verdy [mailto:verdy_p@wanadoo.fr]
> Sent: Thursday, May 31, 2007 8:35 PM
> To: 'Don Osborn'; 'Daniel Yacob'; unicode@unicode.org;
> wjposer@ldc.upenn.edu
> Subject: RE: [OT]non-terrestrial writing systems
> 
> If I just consider the current data found in the CLDR language-
> territory
> map, we currently have a total of 443 languages spoken by 5,972,581,880
> persons.
> 
> So there are still lots of people speaking uncovered modern languages
> (rough
> estimate, about 1.5 billion) possibly more because those CLDR estimates
> are
> only for the primary language:
> 
> if I look for example at France, the CLDR data says that French is
> spoken
> only by 51 millions people out of more than 71 millions residents, and
> an
> incredibly large 16 millions people (but most probably only as a
> secondary
> language; and it forgets more common primary language spoken in France
> by
> French natives: Arabic, Berber, Rom/Tzigane, Armenian, and lots of
> other
> languages spoken by more recent immigrants with a legal residence: the
> same
> languages as well as Romanian, Polish, Chinese, Vietnamese, Persian,
> Turkish, and many African languages...). (Note that the CLDR data
> includes
> statistics for migrants, but minors the statistics for French-speaking
> US
> natives).
> 
> This just confirms that the CLDR data just concentrates on the primary
> language, or at a official lingua franca for languages spoken by a
> community
> spread in very small minorities over a territory, and that are not
> directly
> identifiable. But the same data contains statistics for old regional
> languages, even though most of them are only spoken as a secondary
> language.
> The case of English in France is very significant.
> 
> I'm sure that those statistics are tweaked in favour of more important
> languages, but even in this case, they are missing lots of people in
> the
> world; notably: there's data missing for the languages in:
> * [MX] Mexico, [BO] Bolivia and [PE] Peru: lots of Amerindian languages
> missing
> * [MQ] Martinique (France): French is given very low statistics,
> probably
> French Creole is missing (but in Guadeloupe, the statistics indicate
> standard French spoken by everyone, without any creole?)
> * [DZ] Algeria and [TU] Tunisia: missing Berber, Fulah (Peul)...

Fula/Peul is not in Algeria or Tunisia

> * [CG] Congo-Brazzaville, [CM] Cameroon: missing lots of African
> languages
> * [CI] Côte d'Ivoire: missing lots of African languages, or statistics
> are
> most probably about 100 times too low if considering only the lingua-
> franca
> languages (only French and Koro?), possibly a input bug! Missing
> English
> too.

There was a misattribution of a locale for a language in Nigeria that is
also known under a similar name. Not sure if that has been corrected, though
will look at it again.

> * [GM] Gambia: lots of African languages
> * [ZA] South-Africa: only the official languages are listed, plus
> Swati,
> Swahili, South-Ndebele, Hindi being the only non African language
> listed
> (where is also Chinese?)
> * [RE] Reunion (France): Reunion French Creole is listed along with
> Tamil,
> but Chinese is missing* [SC] Seychelles: where are Indian languages?
> * [JE] Jersey and [GG] Guernsey: where are English, Normand, Jersiais
> and
> French?
> * [GI] Gibraltar: most probably, Spanish is missing there.
> * [RU] Russia: many Asian languages (including Chinese and Mongolian)
> and
> German, Yiddish, Hebrew...
> * [CN] China (Dem. Rep.), [MO] Macau SAR, [HK] Hong Kong SAR: missing
> Southern Chinese dialects, plus Hmong and Turkic languages.
> * [MS] Malaysia: lots of native languages
> * [PH] Philippines, [TH] Thailand: their native languages are spread
> all
> around the world through navigation
> * [ID] Indonesia: certainly lots of native languages missing
> * [CK] Cook Islands: missing Cook Islands Maori (only English listed)
> * [NC] New-Caledonia (France): missing native polynesian languages
> * [WF] Wallis-and-Futuna (France): missing native polynesian languages
> 
> Most missing languages are in South-East Asian archipelagos, India,
> China,
> all over Africa, Central America, and North-West of South America. Only
> European languages and large Asian languages are "well" covered at
> least
> with the primary language plus some regional languages.
> 
> And anyway, we still lack resources for important historic languages in
> the
> Middle-East.
> 
...





From v-magdad@microsoft.com Mon Jun  4 14:33:48 2007
Received: with ECARTIS (v1.0.0; list cldr-users); Mon, 04 Jun 2007 14:34:34 -0500 (CDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215])
	by unicode.org (8.13.4/8.12.11) with ESMTP id l54JXl8I008509;
	Mon, 4 Jun 2007 14:33:48 -0500
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by
 TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft
 SMTP Server (TLS) id 8.0.700.0; Mon, 4 Jun 2007 12:32:45 -0700
Received: from NA-EXMSG-C134.redmond.corp.microsoft.com ([157.54.62.177]) by
 tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Mon,
 4 Jun 2007 12:33:41 -0700
From: "Magda Danish (Unicode)" <v-magdad@microsoft.com>
To: "unicode@unicode.org" <unicode@unicode.org>
Date: Mon, 4 Jun 2007 12:33:40 -0700
Subject: 31st Internationalization & Unicode Conference to Feature New
 Content on New Technologies, Academic Topics, Web Mail and Hot Topics in
 Internationalization
Thread-Topic: 31st Internationalization & Unicode Conference to Feature New
 Content on New Technologies, Academic Topics, Web Mail and Hot Topics in
 Internationalization
Thread-Index: Acem30FaBQKEZ/mHTnSxfdSl1xne/Q==
Message-ID: <8DBD16074283AE41A3A54A5926704DC91064C33E9F@NA-EXMSG-C134.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_8DBD16074283AE41A3A54A5926704DC91064C33E9FNAEXMSGC134re_"
MIME-Version: 1.0
X-archive-position: 156
X-ecartis-version: Ecartis v1.0.0
Sender: cldr-users-bounce@unicode.org
Errors-to: cldr-users-bounce@unicode.org
X-original-sender: v-magdad@microsoft.com
Precedence: bulk
Reply-to: cldr-users@unicode.org
X-list: cldr-users

--_000_8DBD16074283AE41A3A54A5926704DC91064C33E9FNAEXMSGC134re_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Rk9SIElNTUVESUFURSBSRUxFQVNFDQoNCg0KDQoNCg0KQ29udGFjdDoNCg0KU3RlcGhhbmllIENv
dmVydA0KT2JqZWN0IE1hbmFnZW1lbnQgR3JvdXANCisxLTg0My03MzcgMDYzNw0KaW5mb0B1bmlj
b2RlY29uZmVyZW5jZS5vcmcNCg0KDQozMXN0IEludGVybmF0aW9uYWxpemF0aW9uICYgVW5pY29k
ZSBDb25mZXJlbmNlIHRvIEZlYXR1cmUgTmV3IENvbnRlbnQgb24gTmV3IFRlY2hub2xvZ2llcywg
QWNhZGVtaWMgVG9waWNzLCBXZWIgTWFpbCBhbmQgSG90IFRvcGljcyBpbiBJbnRlcm5hdGlvbmFs
aXphdGlvbg0KDQpGdWxsIFByb2dyYW0gQWdlbmRhIEF2YWlsYWJsZSBmb3IgQ29uZmVyZW5jZQ0K
T2N0b2JlciAxNS0xNywgMjAwNywgU2FuIEpvc2UsIENhbGlmLiwgVVNBDQoNCg0KDQpNb3VudGFp
biBWaWV3LCBDQSwgVVNBIOKAkyBKdW5lIDQsIDIwMDcg4oCTIFRoZSBVbmljb2Rlwq4gQ29uc29y
dGl1bSB0b2RheSBhbm5vdW5jZWQgdGhlIHByb2dyYW0gZm9yIHRoZSAzMXN0IEludGVybmF0aW9u
YWxpemF0aW9uICYgVW5pY29kZcKuIENvbmZlcmVuY2UgKElVQykuIFRoZSBjb25mZXJlbmNlLCBz
cG9uc29yZWQgYnkgR29sZCBTcG9uc29yIEFkb2JlLCBJbmMuLCB3aWxsIHRha2UgcGxhY2UgT2N0
b2JlciAxNS0xNywgMjAwNywgaW4gU2FuIEpvc2UsIENhbGlmLiwgVVNBLiBUaGUgZnVsbCBjb25m
ZXJlbmNlIHByb2dyYW0gaXMgYXZhaWxhYmxlIG9ubGluZSBhdCBodHRwOi8vd3d3LnVuaWNvZGVj
b25mZXJlbmNlLm9yZy9wcm9ncmFtLXByLg0KDQoNCg0KVGhlIHByb2dyYW0gY29tbWl0dGVlIGhh
cyBjcmVhdGVkIGFuIGV4Y2l0aW5nIHByb2dyYW0gZnVsbCBvZiBuZXcgYW5kIGN1dHRpbmctZWRn
ZSB0b3BpY3MgdGhhdCBpcyByZWxldmFudCBhbmQgZW5nYWdpbmcgZm9yIHRoZSBpbnRlcm5hdGlv
bmFsaXphdGlvbiBjb21tdW5pdHkuIFRoZSB0aHJlZS1kYXkgY29uZmVyZW5jZSB3aWxsIGZlYXR1
cmUgYSBrZXlub3RlIHByZXNlbnRhdGlvbiBieSBSb2JlcnQgQnJpbmdodXJzdCwgYSBub3RlZCBw
b2V0LCBib29rIGRlc2lnbmVyLCB0eXBvZ3JhcGhlciwgaGlzdG9yaWFuIGFuZCBsaW5ndWlzdC4g
VGhlIGNvbmZlcmVuY2UgaW5jbHVkZXMgYSBmdWxsIGRheSBvZiB0dXRvcmlhbHMgZm9sbG93ZWQg
YnkgdHdvIGRheXMgb2YgcHJlc2VudGF0aW9ucywgcGFuZWxzIGFuZCBkaXNjdXNzaW9ucy4gVGhl
cmUgd2lsbCBhbHNvIGJlIHRlY2hub2xvZ3kgZXhoaWJpdHMgYW5kIGRlbW9uc3RyYXRpb25zLg0K
DQoNCg0KSGlnaGxpZ2h0cyBvZiB0aGUgQ29uZmVyZW5jZToNCg0KDQoNCsK3ICAgICAgICAgS2V5
bm90ZSBQcmVzZW50ZXI6DQoNCm8gICAgICAgIFJvYmVydCBCcmluZ2h1cnN0LCBub3RlZCBwb2V0
LCBib29rIGRlc2lnbmVyLCB0eXBvZ3JhcGhlciwgaGlzdG9yaWFuIGFuZCBsaW5ndWlzdA0KDQoN
CsK3ICAgICAgICAgVHV0b3JpYWxzIGluIFRocmVlIFRyYWNrczoNCg0KbyAgICAgICAgVW5pY29k
ZSA1LjA6IEFuIEludHJvZHVjdGlvbiB0byBXcml0aW5nIFN5c3RlbXMgJiBVbmljb2RlOw0KDQpv
ICAgICAgICBGdW5kYW1lbnRhbCBTcGVjaWZpY2F0aW9ucyBhbmQgVW5pY29kZSBBbGdvcml0aG1z
Ow0KDQpvICAgICAgICAgSW50ZXJuYXRpb25hbGl6YXRpb246IEFuIEludHJvZHVjdGlvbjsNCg0K
byAgICAgICAgQSB0d28tcGFydCB0dXRvcmlhbCBvbiBPcmFjbGUvU1FMIFNlcnZlciwgTWFraW5n
IFNlbnNlIG9mIE9yYWNsZSBDaGFyYWN0ZXIgU2V0cyBhbmQgTGVuZ3RoIFNlbWFudGljczsNCg0K
byAgICAgICAgSUNVLCBpbiBib3RoIEMgYW5kIEphdmENCg0KbyAgICAgICAgQmVzdCBQcmFjdGlj
ZXMgaW4gU29mdHdhcmUgTG9jYWxpemF0aW9uIFByb2Nlc3MgYW5kIFRlY2hub2xvZ3k7DQoNCm8g
ICAgICAgIFdlYiBJbnRlcm5hdGlvbmFsaXphdGlvbiDigJMgU3RhbmRhcmRzIGFuZCBCZXN0IFBy
YWN0aWNlczsNCg0KbyAgICAgICAgV3JpdGluZyBXaW4zMiBNdWx0aWxpbmd1YWwgQXBwbGljYXRp
b25zIFVzaW5nIHRoZSBXaW5kb3dzIFZpc3RhIE1VSSBUZWNobm9sb2d5Ow0KDQpvICAgICAgICBF
eHRlbmRpbmcgTWFjIE9TIFjigJlzIEludGVybmF0aW9uYWwgU3VwcG9ydC4NCg0KbyAgICAgICAg
UHJlc2VudGVycyBjb21lIGZyb20gc3VjaCBvcmdhbml6YXRpb25zIGFzIEFwcGxlIENvbXB1dGVy
LCBBU01VUywgSW5jLiwgR29vZ2xlLCBJQk0gQ29ycG9yYXRpb24sIGkxOE4gSW5jLiwgTWljcm9z
b2Z0LCBXM0MsIGFuZCBZYWhvbyENCg0KDQoNCg0KDQrCtyAgICAgICAgIFNlc3Npb25zIGluIEZv
dXIgVHJhY2tzOg0KDQpvICAgICAgICBTZXNzaW9ucyBvbiBUdWVzZGF5IGFyZSBpbiBmb3VyIHRy
YWNrczsgc2Vzc2lvbnMgb24gV2VkbmVzZGF5IGFyZSBpbiB0aHJlZSB0cmFja3MgcGx1cywgZm9y
IHRoZSBmaXJzdCB0aW1lLCBhIGZvdXJ0aCB0cmFjayBjb21wcmlzaW5nIHRoZSBVbmljb2RlIFRl
Y2huaWNhbCBDb21taXR0ZWUgTWVldGluZy4NCg0KbyAgICAgICAgVGhlIGZvbGxvd2luZyBpcyBq
dXN0IGEgc21hbGwgc2FtcGxlIG9mIHNvbWUgb2YgdGhlIGN1dHRpbmctZWRnZSBwcmVzZW50YXRp
b25zIHRoYXQgd2lsbCBiZSBnaXZlbiBhdCBJVUMgMzEuIEZvciB0aGUgZnVsbCBwcm9ncmFtLCB2
aXNpdCB0aGUgSVVDIDMxIFdlYiBzaXRlLg0KDQrCtyAgICAgICAgIENsaW1iaW5nIHRoZSBUb3dl
ciBvZiBCYWJlbCB3aXRoIFBIUCwgcHJlc2VudGVkIGJ5IEFuZHJlaSBabWlldnNraSwgWWFob28h
DQoNCsK3ICAgICAgICAgV2hlbiBBamF4IE1lZXRzIEdsb2JhbGl6YXRpb27igKYsIHByZXNlbnRl
ZCBieSBKdXN0aW4gWWluLCBJQk0NCg0KwrcgICAgICAgICBVbmljb2RlIElzc3VlcyBpbiBNYXJz
OiBBbiBYTUwgUmVwcmVzZW50YXRpb24gb2YgUERGLCBwcmVzZW50ZWQgYnkgTWF0dGhldyBIYXJk
eSwgQWRvYmUgU3lzdGVtcw0KDQrCtyAgICAgICAgIEludGVybmF0aW9uYWxpemF0aW9uIFRhZyBT
ZXQgMS4wIOKAkyBBIE5ldyBTdGFuZGFyZCBmb3IgSW50ZXJuYXRpb25hbGl6YXRpb24gYW5kIExv
Y2FsaXphdGlvbiBvZiBYTUwsIHByZXNlbnRlZCBieSBGZWxpeCBTYXNha2ksIFczQw0KDQrCtyAg
ICAgICAgIFdoYXTigJlzIE5ldyBpbiBDTERSIDEuNSwgcHJlc2VudGVkIGJ5IEpvaG4gRW1tb25z
LCBJQk0NCg0KwrcgICAgICAgICBMYW5ndWFnZSBUYWdzOiB0aGUgTmV4dCBHZW5lcmF0aW9uLCBw
cmVzZW50ZWQgYnkgQWRkaXNvbiBQaGlsbGlwcywgWWFob28hICYgTWFyayBEYXZpcywgR29vZ2xl
DQoNCsK3ICAgICAgICAgTmV3IEludGVybmF0aW9uYWxpemF0aW9uIEZlYXR1cmVzIG9mIHRoZSBK
YXZhIFBsYXRmb3JtLCBwcmVzZW50ZWQgYnkgTmFvdG8gU2F0bywgU3VuIE1pY3Jvc3lzdGVtcyAm
IENyYWlnIEN1bW1pbmdzLCBPcmFjbGUNCg0KbyAgICAgICAgU2Vzc2lvbiBQcmVzZW50ZXJzIGNv
bWUgZnJvbSBzdWNoIG9yZ2FuaXphdGlvbnMgYXMgQWRvYmUgU3lzdGVtcywgQW95YW1hIEdha3Vp
biBVbml2ZXJzaXR5LCBBcHBsZSBDb21wdXRlciwgRGl3YW4gU29mdHdhcmUgTGltaXRlZCwgRWFy
dGggVHJlYXN1cnksIEdvb2dsZSwgaTE4TiwgSUJNLCBJbnRlbCwgSmltIERlTGFIdW50ICYgQXNz
b2NpYXRlcywgTWljcm9zb2Z0LCBNTE0gQXNzb2NpYXRlcywgTW90b3JvbGEg4oCTIEdURywgT3Jh
Y2xlLCBQREZsaWIgR21iSCwgUGVubiBTdGF0ZSwgVGF2dWx0ZXNvZnQsIFVDIEJlcmtlbGV5LCBX
M0MsIFdlYnN0ZXIgVW5pdmVyc2l0eSwgYW5kIFlhaG9vIQ0KDQoNCsK3ICAgICAgICAgSG9zdGVk
IHNwZWNpYWwgaW50ZXJlc3QgZ2F0aGVyaW5ncyB3aWxsIGJlIGhlbGQgdGhyb3VnaG91dCB0aGUg
Y29uZmVyZW5jZS4gVG9waWNzIHdpbGwgYmUgYW5ub3VuY2VkIGF0IHRoZSBjb25mZXJlbmNlLg0K
DQoNCg0KVGhlIEludGVybmF0aW9uYWxpemF0aW9uICYgVW5pY29kZSBDb25mZXJlbmNlIGlzIHRo
ZSBwcmVtaWVyIHRlY2huaWNhbCBjb25mZXJlbmNlIGZvciBib3RoIHNvZnR3YXJlIGFuZCBXZWIg
aW50ZXJuYXRpb25hbGl6YXRpb24uIFVuaWNvZGUgYW5kIGludGVybmF0aW9uYWxpemF0aW9uIGV4
cGVydHMsIGltcGxlbWVudGVycywgY2xpZW50cyBhbmQgdmVuZG9ycyBhcmUgaW52aXRlZCB0byBh
dHRlbmQgdGhpcyB1bmlxdWUgY29uZmVyZW5jZS4gVGhlIGludGVyYWN0aXZlIGZvcm1hdCBtYWtl
cyB0aGUgSW50ZXJuYXRpb25hbGl6YXRpb24gJiBVbmljb2RlIENvbmZlcmVuY2UgYSBncmVhdCBw
bGFjZSB0byBtZWV0IGFuZCBleGNoYW5nZSBpZGVhcyB3aXRoIGxlYWRpbmcgZXhwZXJ0cywgZmlu
ZCBvdXQgYWJvdXQgdGhlIG5lZWRzIG9mIHBvdGVudGlhbCBjbGllbnRzLCBvciBnZXQgaW5mb3Jt
YXRpb24gYWJvdXQgbmV3IGFuZCBleGlzdGluZyBVbmljb2RlIGFuZCBpbnRlcm5hdGlvbmFsaXph
dGlvbi1lbmFibGVkIHByb2R1Y3RzLg0KDQoNCg0KVGhlIDMxc3QgSW50ZXJuYXRpb25hbGl6YXRp
b24gJiBVbmljb2RlIENvbmZlcmVuY2UgaXMgc3BvbnNvcmVkIGJ5IEdvbGQgU3BvbnNvciBBZG9i
ZTsgTWVkaWEgU3BvbnNvciBNdWx0aUxpbmd1YWwgQ29tcHV0aW5nIEluYy4gKHd3dy5tdWx0aWxp
bmd1YWwuY29tPGh0dHA6Ly93d3cubXVsdGlsaW5ndWFsLmNvbS8+KSwgYW5kIE9yZ2FuaXphdGlv
bmFsIFNwb25zb3IgTG9jYWxpemF0aW9uIEluZHVzdHJ5IFN0YW5kYXJkcyBBc3NvY2lhdGlvbiAo
TElTQSkgKHd3dy5saXNhLm9yZzxodHRwOi8vd3d3Lmxpc2Eub3JnLz4pLg0KDQoNCg0KVGhlIGVh
cmx5LWJpcmQgcmVnaXN0cmF0aW9uIGRlYWRsaW5lIGlzIFNlcHRlbWJlciA1LCAyMDA3OyB0aGUg
aG90ZWwgcmVnaXN0cmF0aW9uIGRlYWRsaW5lIGlzIFNlcHRlbWJlciAyMSwgMjAwNy4gRm9yIGZ1
bGwgY29uZmVyZW5jZSBkZXRhaWxzIGFuZCB0byByZWdpc3RlciwgdmlzaXQgaHR0cDovL3d3dy51
bmljb2RlY29uZmVyZW5jZS5vcmcvcHJvZ3JhbS1wci4gU3BvbnNvcnNoaXBzIGFuZCBleGhpYml0
IHNwYWNlIGFyZSBhdmFpbGFibGU7IGZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHNwb25zb3Jpbmcs
IG9yIGV4aGliaXRpbmcgY29udGFjdCBKb24gUm91c3NlbCBhdCBqcm91c3NlbEBvbWcub3JnPG1h
aWx0bzpqcm91c3NlbEBvbWcub3JnPiwgKzEtNzgxLTQ0NCAwNDA0LCBleHQuIDEwNi4gRm9yIGFs
bCBvdGhlciBxdWVzdGlvbnMgZW1haWwgaW5mb0B1bmljb2RlY29uZmVyZW5jZS5vcmc8bWFpbHRv
OmluZm9AdW5pY29kZWNvbmZlcmVuY2Uub3JnPi4NCg0KDQojIyMNCg0KDQoNCg0KQWJvdXQgdGhl
IFVuaWNvZGUgQ29uc29ydGl1bQ0KDQpUaGUgVW5pY29kZSBDb25zb3J0aXVtIGlzIGEgbm9uLXBy
b2ZpdCBvcmdhbml6YXRpb24gZm91bmRlZCB0byBkZXZlbG9wLCBleHRlbmQgYW5kIHByb21vdGUg
dXNlIG9mIHRoZSBVbmljb2RlIFN0YW5kYXJkIGFuZCByZWxhdGVkIGdsb2JhbGl6YXRpb24gc3Rh
bmRhcmRzLg0KDQoNCg0KVGhlIG1lbWJlcnNoaXAgb2YgdGhlIGNvbnNvcnRpdW0gcmVwcmVzZW50
cyBhIGJyb2FkIHNwZWN0cnVtIG9mIGNvcnBvcmF0aW9ucyBhbmQgb3JnYW5pemF0aW9ucyBpbiB0
aGUgY29tcHV0ZXIgYW5kIGluZm9ybWF0aW9uIHByb2Nlc3NpbmcgaW5kdXN0cnkuDQoNCk1lbWJl
cnMgYXJlOiBBZG9iZSBTeXN0ZW1zLCBBcHBsZSwgQmFzaXMgVGVjaG5vbG9neSwgRGVuaWMgZS4g
Ry4sIEdvb2dsZSwgR292ZXJubWVudCBvZiBJbmRpYSAtIE1pbmlzdHJ5IG9mIEluZm9ybWF0aW9u
IFRlY2hub2xvZ3ksIEdvdmVybm1lbnQgb2YgUGFraXN0YW4gLSBOYXRpb25hbCBMYW5ndWFnZSBB
dXRob3JpdHksIEdvdmVybm1lbnQgb2YgVGFtaWwgTmFkdSAtIFRhbWlsIFZpcnR1YWwgVW5pdmVy
c2l0eSwgSFAsIElCTSwgSnVzdHN5c3RlbSwgTWljcm9zb2Z0LCBNb25vdHlwZSBJbWFnaW5nLCBP
cmFjbGUsIFNBUCwgU3VuIE1pY3Jvc3lzdGVtcywgU3liYXNlLCBUaGUgVW5pdmVyc2l0eSBvZiBD
YWxpZm9ybmlhIGF0IEJlcmtlbGV5LCBZYWhvbywgYW5kIG92ZXIgMTAwIEFzc29jaWF0ZSwgTGlh
aXNvbiwgYW5kIEluZGl2aWR1YWwgbWVtYmVycy4NCg0KDQoNCkZvciBtb3JlIGluZm9ybWF0aW9u
LCBwbGVhc2UgY29udGFjdCB0aGUgVW5pY29kZSBDb25zb3J0aXVtIGh0dHA6Ly93d3cudW5pY29k
ZS5vcmcvY29udGFjdHMuaHRtbC4NCg0KDQoNCkFib3V0IHRoZSBFdmVudCBQcm9kdWNlcg0KDQpU
aGUgT2JqZWN0IE1hbmFnZW1lbnQgR3JvdXDihKIgKE9NR+KEoikgaXMgdGhlIEV2ZW50IFByb2R1
Y2VyIGZvciB0aGUgSW50ZXJuYXRpb25hbGl6YXRpb24gJiBVbmljb2Rlwq4gQ29uZmVyZW5jZXMu
IFRoZSBPTUcgaXMgYW4gb3BlbiBtZW1iZXJzaGlwLCBub3QtZm9yLXByb2ZpdCBjb25zb3J0aXVt
IHRoYXQgcHJvZHVjZXMgYW5kIG1haW50YWlucyBjb21wdXRlciBpbmR1c3RyeSBzcGVjaWZpY2F0
aW9ucyBmb3IgaW50ZXJvcGVyYWJsZSBlbnRlcnByaXNlIGFwcGxpY2F0aW9ucy4gT3VyIHNwZWNp
ZmljYXRpb25zIGluY2x1ZGUgTURBwq4sIFVNTMKuLCBDT1JCQcKuLCBNT0bihKIsIFhNScKuIGFu
ZCBDV03ihKIuIE9NR+KAmXMgc3BlY2lmaWNhdGlvbnMgYXJlIGFsbCBhdmFpbGFibGUgZm9yIGRv
d25sb2FkIGJ5IGV2ZXJ5b25lIHdpdGhvdXQgY2hhcmdlLg0KDQoNCg0KRm9yIG1vcmUgaW5mb3Jt
YXRpb24gYWJvdXQgT01HLCB2aXNpdCB1cyBvbmxpbmUgYXQgaHR0cDovL3d3dy5vbWcub3JnPGh0
dHA6Ly93d3cub21nLm9yZy8+Lg0KDQoNCg0KTm90ZSB0byBlZGl0b3JzOiBVbmljb2RlIFN0YW5k
YXJkLCBVbmljb2RlIGFuZCB0aGUgVW5pY29kZSBMb2dvIGFyZSB0cmFkZW1hcmtzIG9mIFVuaWNv
ZGUsIEluYy4gVW5pY29kZSBDb25zb3J0aXVtIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Yg
VW5pY29kZSwgSW5jLiBNREEsIE1vZGVsIERyaXZlbiBBcmNoaXRlY3R1cmUsIE9NRyBMb2dvLCBV
TUwgYW5kIENPUkJBIGFyZSByZWdpc3RlcmVkIHRyYWRlbWFya3MsIGFuZCBPTUcsIE9iamVjdCBN
YW5hZ2VtZW50IEdyb3VwLCBNT0YsIE1EQSBMb2dvcywgVW5pZmllZCBNb2RlbGluZyBMYW5ndWFn
ZSBhbmQgVU1MIGxvZ28gYXJlIHRyYWRlbWFya3MsIG9mIE9iamVjdCBNYW5hZ2VtZW50IEdyb3Vw
LiBBbGwgb3RoZXIgdHJhZGVtYXJrcyBhcmUgdGhlIHByb3BlcnR5IG9mIHRoZWlyIHJlc3BlY3Rp
dmUgb3duZXJzLg0K

--_000_8DBD16074283AE41A3A54A5926704DC91064C33E9FNAEXMSGC134re_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u
dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2
LjAwLjYwMDAuMTY0NDEiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9O
VCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9O
VC1TVFlMRTogbm9ybWFsOyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5
OiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPg0KPFAgY2xhc3M9TXNvVGl0bGUg
c3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IFRFWFQtQUxJR046IGp1c3RpZnkiPjxTUEFOIA0K
c3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULUZBTUlMWTog
QXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAx
MC4wcHQiPkZPUiANCklNTUVESUFURSBSRUxFQVNFPFNQQU4gDQpzdHlsZT0ibXNvLXRhYi1jb3Vu
dDogMSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjw/eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5zID0g
InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgDQovPjxvOnA+PC9vOnA+
PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1RpdGxlIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0
OyBURVhULUFMSUdOOiBqdXN0aWZ5Ij48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZP
TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWls
eTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48U1BBTiANCnN0eWxlPSJtc28t
c3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0Kc3R5bGU9Im1zby10YWItY291bnQ6
IDMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvU1BBTj48bzpwPjwvbzpw
PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29UaXRsZSBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBw
dDsgVEVYVC1BTElHTjoganVzdGlmeSI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBG
T05ULVNUWUxFOiBub3JtYWw7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1p
bHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvVGl0bGUgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7
IFRFWFQtQUxJR046IGxlZnQiIA0KYWxpZ249bGVmdD48VT48U1BBTiANCnN0eWxlPSJGT05ULVNJ
WkU6IDExcHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IEFyaWFsOyBtc28tYmlk
aS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij5Db250YWN0
OjxvOnA+PC9vOnA+PC9TUEFOPjwvVT48L1A+DQo8UCBjbGFzcz1Nc29TdWJ0aXRsZSBzdHlsZT0i
TUFSR0lOOiAwaW4gMGluIDBwdCI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05U
LUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9u
dC1zaXplOiAxMC4wcHQiPlN0ZXBoYW5pZSANCkNvdmVydDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N
CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgVEVYVC1BTElH
TjoganVzdGlmeSI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTog
QXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAx
MC4wcHQiPk9iamVjdCANCk1hbmFnZW1lbnQgR3JvdXA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8
UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IFRFWFQtQUxJR046
IGp1c3RpZnkiPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6IGJsYWNrOyBG
T05ULUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGkt
Zm9udC1zaXplOiAxMC4wcHQiPisxLTg0My03MzcgDQowNjM3PG86cD48L286cD48L1NQQU4+PC9Q
Pg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBURVhULUFM
SUdOOiBqdXN0aWZ5Ij48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiBibGFj
azsgRk9OVC1GQU1JTFk6IEFyaWFsOyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1i
aWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij5pbmZvQHVuaWNvZGVjb25mZXJlbmNlLm9yZzwvU1BBTj48
U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLWJp
ZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PG86cD48
L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAw
aW4gMHB0OyBURVhULUFMSUdOOiBqdXN0aWZ5Ij48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEx
cHQ7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28t
YmlkaS1mb250LXNpemU6IDEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAg
Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBURVhULUFMSUdOOiBq
dXN0aWZ5Ij48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZPTlQtRkFNSUxZOiBBcmlh
bDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBw
dCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl
PSJNQVJHSU46IDBpbiAwaW4gMHB0OyBURVhULUFMSUdOOiBjZW50ZXIiIA0KYWxpZ249Y2VudGVy
PjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6IEFyaWFsOyBtc28t
YmlkaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28t
YmlkaS1mb250LXN0eWxlOiBpdGFsaWMiPjMxPFNVUD5zdDwvU1VQPiANCkludGVybmF0aW9uYWxp
emF0aW9uICZhbXA7IFVuaWNvZGUgQ29uZmVyZW5jZSB0byBGZWF0dXJlIE5ldyBDb250ZW50IG9u
IE5ldyANClRlY2hub2xvZ2llcywgQWNhZGVtaWMgVG9waWNzLCBXZWIgTWFpbCBhbmQgSG90IFRv
cGljcyBpbiANCkludGVybmF0aW9uYWxpemF0aW9uPC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05v
cm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgVEVYVC1BTElHTjogY2VudGVyIiANCmFs
aWduPWNlbnRlcj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZPTlQtRkFNSUxZOiBB
cmlhbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEw
LjBwdDsgbXNvLWJpZGktZm9udC1zdHlsZTogaXRhbGljIj48bzpwPjwvbzpwPjwvU1BBTj4mbmJz
cDs8L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IFRF
WFQtQUxJR046IGNlbnRlciIgDQphbGlnbj1jZW50ZXI+PEk+PFNQQU4gDQpzdHlsZT0iRk9OVC1T
SVpFOiAxMXB0OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlh
bDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPkZ1bGwgDQpQcm9ncmFtIEFnZW5kYSBBdmFp
bGFibGUgZm9yIENvbmZlcmVuY2UgPEJSPk9jdG9iZXIgMTUtMTcsIDIwMDcsIDw/eG1sOm5hbWVz
cGFjZSANCnByZWZpeCA9IHN0MSBucyA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmlj
ZTpzbWFydHRhZ3MiIC8+PHN0MTpwbGFjZSANCnc6c3Q9Im9uIj48c3QxOkNpdHkgdzpzdD0ib24i
PlNhbiBKb3NlPC9zdDE6Q2l0eT4sIDxzdDE6U3RhdGUgDQp3OnN0PSJvbiI+Q2FsaWYuPC9zdDE6
U3RhdGU+LCA8c3QxOmNvdW50cnktcmVnaW9uIA0KdzpzdD0ib24iPlVTQTwvc3QxOmNvdW50cnkt
cmVnaW9uPjwvc3QxOnBsYWNlPjxvOnA+PC9vOnA+PC9TUEFOPjwvST48L1A+DQo8UCBjbGFzcz1N
c29UaXRsZSBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PFU+PFNQQU4gDQpzdHlsZT0iRk9O
VC1TSVpFOiAxMXB0OyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNv
LWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PG86
cD48U1BBTiANCnN0eWxlPSJURVhULURFQ09SQVRJT046IG5vbmUiPiZuYnNwOzwvU1BBTj48L286
cD48L1NQQU4+PC9VPjwvUD4NCjxQIGNsYXNzPU1zb0JvZHlUZXh0IHN0eWxlPSJNQVJHSU46IDBp
biAwaW4gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj48c3QxOkNpdHkgDQp3OnN0PSJvbiI+PFNQ
QU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWw7
IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij5Nb3VudGFpbiANClZpZXc8L1NQQU4+PC9zdDE6
Q2l0eT48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5
OiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPiwgDQpDQSwgPHN0MTpjb3VudHJ5
LXJlZ2lvbiB3OnN0PSJvbiI+PHN0MTpwbGFjZSANCnc6c3Q9Im9uIj5VU0E8L3N0MTpwbGFjZT48
L3N0MTpjb3VudHJ5LXJlZ2lvbj4g4oCTIEp1bmUgNCwgMjAwNyDigJMgVGhlIFVuaWNvZGXCriAN
CkNvbnNvcnRpdW0gdG9kYXkgYW5ub3VuY2VkIHRoZSBwcm9ncmFtIGZvciB0aGUgMzE8U1VQPnN0
PC9TVVA+IA0KSW50ZXJuYXRpb25hbGl6YXRpb24gJmFtcDsgVW5pY29kZcKuIENvbmZlcmVuY2Ug
KElVQykuIFRoZSBjb25mZXJlbmNlLCBzcG9uc29yZWQgDQpieSBHb2xkIFNwb25zb3IgQWRvYmUs
IEluYy4sIHdpbGwgdGFrZSBwbGFjZSBPY3RvYmVyIDE1LTE3LCAyMDA3LCBpbiA8c3QxOnBsYWNl
IA0KdzpzdD0ib24iPjxzdDE6Q2l0eSB3OnN0PSJvbiI+U2FuIEpvc2U8L3N0MTpDaXR5PiwgPHN0
MTpTdGF0ZSANCnc6c3Q9Im9uIj5DYWxpZi48L3N0MTpTdGF0ZT4sIDxzdDE6Y291bnRyeS1yZWdp
b24gDQp3OnN0PSJvbiI+VVNBPC9zdDE6Y291bnRyeS1yZWdpb24+PC9zdDE6cGxhY2U+LiBUaGUg
ZnVsbCBjb25mZXJlbmNlIHByb2dyYW0gaXMgDQphdmFpbGFibGUgb25saW5lIGF0IDxBIA0KaHJl
Zj0iaHR0cDovL3d3dy51bmljb2RlY29uZmVyZW5jZS5vcmcvcHJvZ3JhbS1wciI+aHR0cDovL3d3
dy51bmljb2RlY29uZmVyZW5jZS5vcmcvcHJvZ3JhbS1wcjwvQT4uIA0KPG86cD48L286cD48L1NQ
QU4+PC9QPg0KPFAgY2xhc3M9TXNvQm9keVRleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7
IExJTkUtSEVJR0hUOiBub3JtYWwiPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgbXNv
LWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PG86
cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvQm9keVRleHQgc3R5bGU9Ik1B
UkdJTjogMGluIDBpbiAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPjxTUEFOIA0Kc3R5bGU9IkZP
TlQtU0laRTogMTFwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250
LXNpemU6IDEwLjBwdCI+VGhlIA0KcHJvZ3JhbSBjb21taXR0ZWUgaGFzIGNyZWF0ZWQgYW4gZXhj
aXRpbmcgcHJvZ3JhbSBmdWxsIG9mIG5ldyBhbmQgY3V0dGluZy1lZGdlIA0KdG9waWNzIHRoYXQg
aXMgcmVsZXZhbnQgYW5kIGVuZ2FnaW5nIGZvciB0aGUgaW50ZXJuYXRpb25hbGl6YXRpb24gY29t
bXVuaXR5LiBUaGUgDQp0aHJlZS1kYXkgY29uZmVyZW5jZSB3aWxsIGZlYXR1cmUgYSBrZXlub3Rl
IHByZXNlbnRhdGlvbiBieSBSb2JlcnQgQnJpbmdodXJzdCwgYSANCm5vdGVkIHBvZXQsIGJvb2sg
ZGVzaWduZXIsIHR5cG9ncmFwaGVyLCBoaXN0b3JpYW4gYW5kIGxpbmd1aXN0LiBUaGUgY29uZmVy
ZW5jZSANCmluY2x1ZGVzIGEgZnVsbCBkYXkgb2YgdHV0b3JpYWxzIGZvbGxvd2VkIGJ5IHR3byBk
YXlzIG9mIHByZXNlbnRhdGlvbnMsIHBhbmVscyANCmFuZCBkaXNjdXNzaW9ucy4gVGhlcmUgd2ls
bCBhbHNvIGJlIHRlY2hub2xvZ3kgZXhoaWJpdHMgYW5kIGRlbW9uc3RyYXRpb25zLiANCjxvOnA+
PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0JvZHlUZXh0IHN0eWxlPSJNQVJHSU46IDBp
biAwaW4gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6
IDExcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAx
MC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0JvZHlUZXh0
IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj48U1BBTiAN
CnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNv
LWJpZGktZm9udC1zaXplOiAxMC4wcHQiPkhpZ2hsaWdodHMgDQpvZiB0aGUgQ29uZmVyZW5jZTog
PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvQm9keVRleHQgc3R5bGU9Ik1BUkdJ
TjogMGluIDBpbiAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPjxTUEFOIA0Kc3R5bGU9IkZPTlQt
U0laRTogMTFwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNp
emU6IDEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvQm9k
eVRleHQgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjVpbjsgVEVYVC1JTkRFTlQ6IC0w
LjI1aW47IExJTkUtSEVJR0hUOiBub3JtYWw7IG1zby1saXN0OiBsMSBsZXZlbDEgbGZvMTsgdGFi
LXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1G
QU1JTFk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5bWJvbDsgbXNvLWJpZGkt
Zm9udC1mYW1pbHk6IFN5bWJvbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxTUEFOIA0K
c3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPsK3PFNQQU4gDQpzdHlsZT0iRk9OVDogN3B0ICdUaW1l
cyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgDQo8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEx
cHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4w
cHQiPktleW5vdGUgDQpQcmVzZW50ZXI6PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9
TXNvQm9keVRleHQgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxaW47IFRFWFQtSU5ERU5U
OiAtMC4yNWluOyBMSU5FLUhFSUdIVDogbm9ybWFsOyBtc28tbGlzdDogbDEgbGV2ZWwyIGxmbzE7
IHRhYi1zdG9wczogbGlzdCAxLjBpbiI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBG
T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdDb3Vy
aWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBtc28tYmlkaS1m
b250LXNpemU6IDEwLjBwdCI+PFNQQU4gDQpzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+bzxTUEFO
IA0Kc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gDQpz
dHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1i
aWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij5Sb2JlcnQgDQpCcmluZ2h1cnN0LCBub3RlZCBwb2V0LCBi
b29rIGRlc2lnbmVyLCB0eXBvZ3JhcGhlciwgaGlzdG9yaWFuIGFuZCBsaW5ndWlzdDxCUiANCnN0
eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPjxCUiANCnN0eWxlPSJtc28t
c3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQ
IGNsYXNzPU1zb0JvZHlUZXh0IA0Kc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC41aW47IFRF
WFQtSU5ERU5UOiAtMC4yNWluOyBMSU5FLUhFSUdIVDogbm9ybWFsOyBtc28tbGlzdDogbDEgbGV2
ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6
IDExcHQ7IEZPTlQtRkFNSUxZOiBTeW1ib2w7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeW1i
b2w7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBTeW1ib2w7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAu
MHB0Ij48U1BBTiANCnN0eWxlPSJtc28tbGlzdDogSWdub3JlIj7CtzxTUEFOIA0Kc3R5bGU9IkZP
TlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gDQpzdHlsZT0i
Rk9OVC1TSVpFOiAxMXB0OyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZv
bnQtc2l6ZTogMTAuMHB0Ij5UdXRvcmlhbHMgDQppbiBUaHJlZSBUcmFja3M6PG86cD48L286cD48
L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvQm9keVRleHQgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGlu
IDBwdCAxaW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBMSU5FLUhFSUdIVDogbm9ybWFsOyBtc28t
bGlzdDogbDEgbGV2ZWwyIGxmbzE7IHRhYi1zdG9wczogbGlzdCAxLjBpbiI+PFNQQU4gDQpzdHls
ZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVh
c3QtZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnQ291
cmllciBOZXcnOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PFNQQU4gDQpzdHlsZT0ibXNv
LWxpc3Q6IElnbm9yZSI+bzxTUEFOIA0Kc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFu
JyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjwv
U1BBTj48L1NQQU4+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBtc28tYmlkaS1mb250
LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij5Vbmljb2RlIA0KNS4w
OiBBbiBJbnRyb2R1Y3Rpb24gdG8gV3JpdGluZyBTeXN0ZW1zICZhbXA7IFVuaWNvZGU7IDxvOnA+
PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0JvZHlUZXh0IA0Kc3R5bGU9Ik1BUkdJTjog
MGluIDBpbiAwcHQgMWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgTElORS1IRUlHSFQ6IG5vcm1h
bDsgbXNvLWxpc3Q6IGwxIGxldmVsMiBsZm8xOyB0YWItc3RvcHM6IGxpc3QgMS4waW4iPjxTUEFO
IA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1z
by1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBtc28tYmlkaS1mb250LWZhbWls
eTogJ0NvdXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxTUEFOIA0Kc3R5
bGU9Im1zby1saXN0OiBJZ25vcmUiPm88U1BBTiANCnN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5l
dyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwv
U1BBTj48L1NQQU4+PC9TUEFOPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgbXNvLWJp
ZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+RnVuZGFt
ZW50YWwgDQpTcGVjaWZpY2F0aW9ucyBhbmQgVW5pY29kZSBBbGdvcml0aG1zOzxvOnA+PC9vOnA+
PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0JvZHlUZXh0IA0Kc3R5bGU9Ik1BUkdJTjogMGluIDBp
biAwcHQgMWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgTElORS1IRUlHSFQ6IG5vcm1hbDsgbXNv
LWxpc3Q6IGwxIGxldmVsMiBsZm8xOyB0YWItc3RvcHM6IGxpc3QgMS4waW4iPjxTUEFOIA0Kc3R5
bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJl
YXN0LWZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBtc28tYmlkaS1mb250LWZhbWlseTogJ0Nv
dXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxTUEFOIA0Kc3R5bGU9Im1z
by1saXN0OiBJZ25vcmUiPm88U1BBTiANCnN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21h
biciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvU1BBTj48
L1NQQU4+PC9TUEFOPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgbXNvLWJpZGktZm9u
dC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PFNQQU4gDQpzdHls
ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BBTj5JbnRlcm5hdGlvbmFsaXphdGlvbjog
QW4gSW50cm9kdWN0aW9uOyANCjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0Jv
ZHlUZXh0IA0Kc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMWluOyBURVhULUlOREVOVDogLTAu
MjVpbjsgTElORS1IRUlHSFQ6IG5vcm1hbDsgbXNvLWxpc3Q6IGwxIGxldmVsMiBsZm8xOyB0YWIt
c3RvcHM6IGxpc3QgMS4waW4iPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1G
QU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnQ291cmllciBO
ZXcnOyBtc28tYmlkaS1mb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1z
aXplOiAxMC4wcHQiPjxTUEFOIA0Kc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPm88U1BBTiANCnN0
eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvU1BBTj48L1NQQU4+PC9TUEFOPjxTUEFOIA0Kc3R5bGU9
IkZPTlQtU0laRTogMTFwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1m
b250LXNpemU6IDEwLjBwdCI+QSANCnR3by1wYXJ0IHR1dG9yaWFsIG9uIE9yYWNsZS9TUUwgU2Vy
dmVyLCBNYWtpbmcgU2Vuc2Ugb2YgT3JhY2xlIENoYXJhY3RlciBTZXRzIA0KYW5kIExlbmd0aCBT
ZW1hbnRpY3M7IDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0JvZHlUZXh0IA0K
c3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgTElO
RS1IRUlHSFQ6IG5vcm1hbDsgbXNvLWxpc3Q6IGwxIGxldmVsMiBsZm8xOyB0YWItc3RvcHM6IGxp
c3QgMS4waW4iPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6ICdD
b3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBtc28t
YmlkaS1mb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4w
cHQiPjxTUEFOIA0Kc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPm88U1BBTiANCnN0eWxlPSJGT05U
OiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyANCjwvU1BBTj48L1NQQU4+PC9TUEFOPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0la
RTogMTFwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6
IDEwLjBwdCI+SUNVLCANCmluIGJvdGggQyBhbmQgSmF2YTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N
CjxQIGNsYXNzPU1zb0JvZHlUZXh0IA0Kc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMWluOyBU
RVhULUlOREVOVDogLTAuMjVpbjsgTElORS1IRUlHSFQ6IG5vcm1hbDsgbXNvLWxpc3Q6IGwxIGxl
dmVsMiBsZm8xOyB0YWItc3RvcHM6IGxpc3QgMS4waW4iPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0la
RTogMTFwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWZvbnQtZmFt
aWx5OiAnQ291cmllciBOZXcnOyBtc28tYmlkaS1mb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsg
bXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxTUEFOIA0Kc3R5bGU9Im1zby1saXN0OiBJZ25v
cmUiPm88U1BBTiANCnN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvU1BBTj48L1NQQU4+PC9TUEFO
PjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFy
aWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+QmVzdCANClByYWN0aWNlcyBpbiBTb2Z0
d2FyZSBMb2NhbGl6YXRpb24gUHJvY2VzcyBhbmQgVGVjaG5vbG9neTsgDQo8bzpwPjwvbzpwPjwv
U1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Cb2R5VGV4dCANCnN0eWxlPSJNQVJHSU46IDBpbiAwaW4g
MHB0IDFpbjsgVEVYVC1JTkRFTlQ6IC0wLjI1aW47IExJTkUtSEVJR0hUOiBub3JtYWw7IG1zby1s
aXN0OiBsMSBsZXZlbDIgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IDEuMGluIj48U1BBTiANCnN0eWxl
PSJGT05ULVNJWkU6IDExcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFz
dC1mb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdDb3Vy
aWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48U1BBTiANCnN0eWxlPSJtc28t
bGlzdDogSWdub3JlIj5vPFNQQU4gDQpzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4n
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L1NQQU4+PC9T
UEFOPjwvU1BBTj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IG1zby1iaWRpLWZvbnQt
ZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPldlYiANCkludGVybmF0
aW9uYWxpemF0aW9uIOKAkyBTdGFuZGFyZHMgYW5kIEJlc3QgUHJhY3RpY2VzOyA8bzpwPjwvbzpw
PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Cb2R5VGV4dCANCnN0eWxlPSJNQVJHSU46IDBpbiAw
aW4gMHB0IDFpbjsgVEVYVC1JTkRFTlQ6IC0wLjI1aW47IExJTkUtSEVJR0hUOiBub3JtYWw7IG1z
by1saXN0OiBsMSBsZXZlbDIgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IDEuMGluIj48U1BBTiANCnN0
eWxlPSJGT05ULVNJWkU6IDExcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFy
ZWFzdC1mb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdD
b3VyaWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48U1BBTiANCnN0eWxlPSJt
c28tbGlzdDogSWdub3JlIj5vPFNQQU4gDQpzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9t
YW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L1NQQU4+
PC9TUEFOPjwvU1BBTj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IG1zby1iaWRpLWZv
bnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPldyaXRpbmcgDQpX
aW4zMiBNdWx0aWxpbmd1YWwgQXBwbGljYXRpb25zIFVzaW5nIHRoZSBXaW5kb3dzIDxzdDE6cGxh
Y2UgDQp3OnN0PSJvbiI+VmlzdGE8L3N0MTpwbGFjZT4gTVVJIFRlY2hub2xvZ3k7IDxvOnA+PC9v
OnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0JvZHlUZXh0IA0Kc3R5bGU9Ik1BUkdJTjogMGlu
IDBpbiAwcHQgMWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgTElORS1IRUlHSFQ6IG5vcm1hbDsg
bXNvLWxpc3Q6IGwxIGxldmVsMiBsZm8xOyB0YWItc3RvcHM6IGxpc3QgMS4waW4iPjxTUEFOIA0K
c3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1m
YXJlYXN0LWZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBtc28tYmlkaS1mb250LWZhbWlseTog
J0NvdXJpZXIgTmV3JzsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxTUEFOIA0Kc3R5bGU9
Im1zby1saXN0OiBJZ25vcmUiPm88U1BBTiANCnN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBS
b21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvU1BB
Tj48L1NQQU4+PC9TUEFOPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgbXNvLWJpZGkt
Zm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+RXh0ZW5kaW5n
IA0KTWFjIE9TIFjigJlzIEludGVybmF0aW9uYWwgU3VwcG9ydC4gPG86cD48L286cD48L1NQQU4+
PC9QPg0KPFAgY2xhc3M9TXNvQm9keVRleHQgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAx
aW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBMSU5FLUhFSUdIVDogbm9ybWFsOyBtc28tbGlzdDog
bDEgbGV2ZWwyIGxmbzE7IHRhYi1zdG9wczogbGlzdCAxLjBpbiI+PFNQQU4gDQpzdHlsZT0iRk9O
VC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtZm9u
dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnQ291cmllciBO
ZXcnOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PFNQQU4gDQpzdHlsZT0ibXNvLWxpc3Q6
IElnbm9yZSI+bzxTUEFOIA0Kc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjwvU1BBTj48
L1NQQU4+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBtc28tYmlkaS1mb250LWZhbWls
eTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij5QcmVzZW50ZXJzIA0KY29tZSBm
cm9tIHN1Y2ggb3JnYW5pemF0aW9ucyBhcyBBcHBsZSBDb21wdXRlciwgQVNNVVMsIEluYy4sIEdv
b2dsZSwgSUJNIA0KQ29ycG9yYXRpb24sIGkxOE4gSW5jLiwgTWljcm9zb2Z0LCBXM0MsIGFuZCBZ
YWhvbyE8QlIgDQpzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj48QlIg
DQpzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj48bzpwPjwvbzpwPjwv
U1BBTj48L1A+DQo8UCBjbGFzcz1Nc29UaXRsZSBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsg
VEVYVC1BTElHTjoganVzdGlmeSI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBGT05U
LUZBTUlMWTogQXJpYWw7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu
JzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0E7
IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1z
by1mYXJlYXN0LWxhbmd1YWdlOiBFTi1VUyI+PEJSIA0Kc3R5bGU9IlBBR0UtQlJFQUstQkVGT1JF
OiBhbHdheXM7IG1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayIgDQpjbGVhcj1hbGw+
PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0JvZHlUZXh0IA0Kc3R5bGU9Ik1BUkdJTjogMGluIDBp
biAwcHQgMC41aW47IExJTkUtSEVJR0hUOiBub3JtYWwiPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0la
RTogMTFwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6
IDEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvQm9keVRl
eHQgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjVpbjsgVEVYVC1JTkRFTlQ6IC0wLjI1
aW47IExJTkUtSEVJR0hUOiBub3JtYWw7IG1zby1saXN0OiBsMSBsZXZlbDEgbGZvMTsgdGFiLXN0
b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1J
TFk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5bWJvbDsgbXNvLWJpZGktZm9u
dC1mYW1pbHk6IFN5bWJvbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxTUEFOIA0Kc3R5
bGU9Im1zby1saXN0OiBJZ25vcmUiPsK3PFNQQU4gDQpzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBO
ZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgDQo8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7
IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQi
PlNlc3Npb25zIA0KaW4gRm91ciBUcmFja3M6PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xh
c3M9TXNvQm9keVRleHQgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxaW47IFRFWFQtSU5E
RU5UOiAtMC4yNWluOyBMSU5FLUhFSUdIVDogbm9ybWFsOyBtc28tbGlzdDogbDEgbGV2ZWwyIGxm
bzE7IHRhYi1zdG9wczogbGlzdCAxLjBpbiI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0
OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdD
b3VyaWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBtc28tYmlk
aS1mb250LXNpemU6IDEwLjBwdCI+PFNQQU4gDQpzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+bzxT
UEFOIA0Kc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4g
DQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWw7IG1z
by1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij5TZXNzaW9ucyANCm9uIFR1ZXNkYXkgYXJlIGluIGZv
dXIgdHJhY2tzOyBzZXNzaW9ucyBvbiBXZWRuZXNkYXkgYXJlIGluIHRocmVlIHRyYWNrcyBwbHVz
LCANCmZvciB0aGUgZmlyc3QgdGltZSwgYSBmb3VydGggdHJhY2sgY29tcHJpc2luZyB0aGUgVW5p
Y29kZSBUZWNobmljYWwgQ29tbWl0dGVlIA0KTWVldGluZy4gPG86cD48L286cD48L1NQQU4+PC9Q
Pg0KPFAgY2xhc3M9TXNvQm9keVRleHQgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxaW47
IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBMSU5FLUhFSUdIVDogbm9ybWFsOyBtc28tbGlzdDogbDEg
bGV2ZWwyIGxmbzE7IHRhYi1zdG9wczogbGlzdCAxLjBpbiI+PFNQQU4gDQpzdHlsZT0iRk9OVC1T
SVpFOiAxMXB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtZm9udC1m
YW1pbHk6ICdDb3VyaWVyIE5ldyc7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcn
OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PFNQQU4gDQpzdHlsZT0ibXNvLWxpc3Q6IEln
bm9yZSI+bzxTUEFOIA0Kc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjwvU1BBTj48L1NQ
QU4+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBtc28tYmlkaS1mb250LWZhbWlseTog
QXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij5UaGUgDQpmb2xsb3dpbmcgaXMganVz
dCBhIHNtYWxsIHNhbXBsZSBvZiBzb21lIG9mIHRoZSBjdXR0aW5nLWVkZ2UgcHJlc2VudGF0aW9u
cyB0aGF0IA0Kd2lsbCBiZSBnaXZlbiBhdCBJVUMgMzEuIEZvciB0aGUgZnVsbCBwcm9ncmFtLCB2
aXNpdCB0aGUgSVVDIDMxIFdlYiANCnNpdGUuPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xh
c3M9TXNvQm9keVRleHQgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAxLjVpbjsgVEVYVC1J
TkRFTlQ6IC0wLjI1aW47IExJTkUtSEVJR0hUOiBub3JtYWw7IG1zby1saXN0OiBsMCBsZXZlbDEg
bGZvMjsgdGFiLXN0b3BzOiBsaXN0IDEuMjVpbiI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAx
MXB0OyBGT05ULUZBTUlMWTogU3ltYm9sOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3ltYm9s
OyBtc28tYmlkaS1mb250LWZhbWlseTogU3ltYm9sOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBw
dCI+PFNQQU4gDQpzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+wrc8U1BBTiANCnN0eWxlPSJGT05U
OiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyANCjwvU1BBTj48L1NQQU4+PC9TUEFOPjxTUEFOIA0Kc3R5bGU9IkZP
TlQtU0laRTogMTFwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tYmlkaS1mb250
LXNpemU6IDEwLjBwdCI+Q2xpbWJpbmcgDQp0aGUgPHN0MTpwbGFjZSB3OnN0PSJvbiI+PHN0MTpQ
bGFjZVR5cGUgdzpzdD0ib24iPlRvd2VyPC9zdDE6UGxhY2VUeXBlPiBvZiANCjxzdDE6UGxhY2VO
YW1lIHc6c3Q9Im9uIj5CYWJlbDwvc3QxOlBsYWNlTmFtZT48L3N0MTpwbGFjZT4gd2l0aCBQSFAs
IHByZXNlbnRlZCANCmJ5IEFuZHJlaSBabWlldnNraSwgWWFob28hPG86cD48L286cD48L1NQQU4+
PC9QPg0KPFAgY2xhc3M9TXNvQm9keVRleHQgDQpzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAx
LjVpbjsgVEVYVC1JTkRFTlQ6IC0wLjI1aW47IExJTkUtSEVJR0hUOiBub3JtYWw7IG1zby1saXN0
OiBsMCBsZXZlbDEgbGZvMjsgdGFiLXN0b3BzOiBsaXN0IDEuMjVpbiI+PFNQQU4gDQpzdHlsZT0i
Rk9OVC1TSVpFOiAxMXB0OyBGT05ULUZBTUlMWTogU3ltYm9sOyBtc28tZmFyZWFzdC1mb250LWZh
bWlseTogU3ltYm9sOyBtc28tYmlkaS1mb250LWZhbWlseTogU3ltYm9sOyBtc28tYmlkaS1mb250
LXNpemU6IDEwLjBwdCI+PFNQQU4gDQpzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+wrc8U1BBTiAN
CnN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvU1BBTj48L1NQQU4+PC9TUEFOPjxTUEFO
IA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IEFyaWFsOyBt
c28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+V2hlbiANCjxzdDE6Q2l0eSB3OnN0PSJvbiI+PHN0
MTpwbGFjZSB3OnN0PSJvbiI+QWpheDwvc3QxOnBsYWNlPjwvc3QxOkNpdHk+IE1lZXRzIA0KR2xv
YmFsaXphdGlvbuKApiwgcHJlc2VudGVkIGJ5IEp1c3RpbiBZaW4sIElCTTxvOnA+PC9vOnA+PC9T
UEFOPjwvUD4NCjxQIGNsYXNzPU1zb0JvZHlUZXh0IA0Kc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAw
cHQgMS41aW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBMSU5FLUhFSUdIVDogbm9ybWFsOyBtc28t
bGlzdDogbDAgbGV2ZWwxIGxmbzI7IHRhYi1zdG9wczogbGlzdCAxLjI1aW4iPjxTUEFOIA0Kc3R5
bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1GQU1JTFk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtZm9u
dC1mYW1pbHk6IFN5bWJvbDsgbXNvLWJpZGktZm9udC1mYW1pbHk6IFN5bWJvbDsgbXNvLWJpZGkt
Zm9udC1zaXplOiAxMC4wcHQiPjxTUEFOIA0Kc3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPsK3PFNQ
QU4gDQpzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L1NQQU4+PC9TUEFOPjwvU1BBTj48
U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlh
bDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPlVuaWNvZGUgDQpJc3N1ZXMgaW4gTWFyczog
QW4gWE1MIFJlcHJlc2VudGF0aW9uIG9mIFBERiwgcHJlc2VudGVkIGJ5IE1hdHRoZXcgSGFyZHks
IEFkb2JlIA0KU3lzdGVtczxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb0JvZHlU
ZXh0IA0Kc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMS41aW47IFRFWFQtSU5ERU5UOiAtMC4y
NWluOyBMSU5FLUhFSUdIVDogbm9ybWFsOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzI7IHRhYi1z
dG9wczogbGlzdCAxLjI1aW4iPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgRk9OVC1G
QU1JTFk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5bWJvbDsgbXNvLWJpZGkt
Zm9udC1mYW1pbHk6IFN5bWJvbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxTUEFOIA0K
c3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPsK3PFNQQU4gDQpzdHlsZT0iRk9OVDogN3B0ICdUaW1l
cyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgDQo8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEx
cHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4w
cHQiPkludGVybmF0aW9uYWxpemF0aW9uIA0KVGFnIFNldCAxLjAg4oCTIEEgTmV3IFN0YW5kYXJk
IGZvciBJbnRlcm5hdGlvbmFsaXphdGlvbiBhbmQgTG9jYWxpemF0aW9uIG9mIFhNTCwgDQpwcmVz
ZW50ZWQgYnkgRmVsaXggU2FzYWtpLCBXM0M8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFz
cz1Nc29Cb2R5VGV4dCANCnN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDEuNWluOyBURVhULUlO
REVOVDogLTAuMjVpbjsgTElORS1IRUlHSFQ6IG5vcm1hbDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBs
Zm8yOyB0YWItc3RvcHM6IGxpc3QgMS4yNWluIj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEx
cHQ7IEZPTlQtRkFNSUxZOiBTeW1ib2w7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeW1ib2w7
IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBTeW1ib2w7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0
Ij48U1BBTiANCnN0eWxlPSJtc28tbGlzdDogSWdub3JlIj7CtzxTUEFOIA0Kc3R5bGU9IkZPTlQ6
IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gDQpzdHlsZT0iRk9O
VC1TSVpFOiAxMXB0OyBtc28tYmlkaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQt
c2l6ZTogMTAuMHB0Ij5XaGF04oCZcyANCk5ldyBpbiBDTERSIDEuNSwgcHJlc2VudGVkIGJ5IEpv
aG4gRW1tb25zLCBJQk08bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Cb2R5VGV4
dCANCnN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDEuNWluOyBURVhULUlOREVOVD