CLDR-17899 site: drop legal footer (#4030)

docs/site/covered-by-other-projects.md

@@ -10,4 +10,3 @@ CLDR covers many different types of data, but not everything. Here are some info
 |---|---|---|---|
 | libphonenumber | https://opensource.google.com/projects/libphonenumber | https://unicode-org.atlassian.net/browse/CLDR-188 | Phone Number database |
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/ddl.md

@@ -14,4 +14,3 @@ Contributors for Digitally Disadvantaged Languages (DDL) face unique challenges.
 
 The DDL Subcommittee has started to meet every other week as of June, 2023.
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development.md

@@ -4,4 +4,4 @@ title: Internal Development
 
 # Internal Development
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)
+

docs/site/development/adding-locales.md

@@ -40,4 +40,3 @@ Here is an example: https://github.com/unicode-org/cldr/pull/59/files
 - Commit your work to a branch and create a Pull Request.
 - The new locale will be included in Smoketest when the PR is merged, and will be in production once a push to production occurs.
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/cldr-big-red-switch.md

@@ -28,4 +28,4 @@ However, names are not automatically entered there, since some people may not wi
 2. e\-mail that list **on BCC:** the above message with a subject line of "\[CLDR X.Y Contributor Message]", and a request to please keep the subject line intact.
 3. Then, the subject line can be used to filter/locate the contributor requests.
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)
+

docs/site/development/cldr-big-red-switch/generating-charts.md

@@ -64,4 +64,3 @@ The messages that they use are in a file util/data/chart\_messages.html. The rig
 
 The key will be zone\_tzid, in this case.
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/cldr-development-site.md

@@ -8,14 +8,14 @@ Some of the key pages for developers are:
 
 1. [New CLDR Developers](https://cldr.unicode.org/development/new-cldr-developers)
     1. [Maven Setup](https://cldr.unicode.org/development/maven) (for command line & Eclipse)
-        1. Obsolete (but may still contain useful nuggets): [Eclipse Setup](https://cldr.unicode.org/development/eclipse-setup)      
-    2. [Eclipse](https://cldr.unicode.org/development/running-survey-tool/building-and-running-the-survey-tool-on-eclipse) (survey tool)       
+        1. Obsolete (but may still contain useful nuggets): [Eclipse Setup](https://cldr.unicode.org/development/eclipse-setup)
+    2. [Eclipse](https://cldr.unicode.org/development/running-survey-tool/building-and-running-the-survey-tool-on-eclipse) (survey tool)
 2. [Handling Tickets (bugs/enhancements)](https://cldr.unicode.org/development/development-process)
 3. [Updating DTDs](https://cldr.unicode.org/development/updating-dtds)
 4. [Editing CLDR Spec](https://cldr.unicode.org/development/editing-cldr-spec)
     1. [CLDR: Big Red Switch](https://cldr.unicode.org/development/cldr-big-red-switch) (checklist for release)
 5. [Adding a new locale to CLDR](https://cldr.unicode.org/development/adding-locales)
-    
+
 
 The subpages listed give more information on internal CLDR development. See also: [Sitemap](https://sites.google.com/site/cldr/system/app/pages/sitemap/hierarchy).
 
@@ -27,4 +27,3 @@ style="\[^"\]\*"
 
 Also see the [Google Docs to Markdown extension, by edbacher](https://workspace.google.com/marketplace/app/docs_to_markdown/700168918607)
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/cldr-development-site/running-cldr-tools.md

@@ -20,7 +20,7 @@ You will need to include some options to run various programs. Here are some sam
 
 \-Dregistry\=language\-subtag\-registry
 
-\-DSHOW\_FILES 
+\-DSHOW\_FILES
 
 The xmx is to increase memory so that you don't blow up. If you only do a few dozen locales, you don't need to set it that high.
 
@@ -31,4 +31,3 @@ The xmx is to increase memory so that you don't blow up. If you only do a few do
 \-DSHOW\_FILES // shows files being opened and created
 
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/cldr-development-site/updating-englishroot.md

@@ -22,11 +22,11 @@ The tool is in tools/java/org/unicode/cldr/tool/GenerateBirth.java. It requires
 2. The archive directory should have the latest version of every major and minor version (where versions before 21\.0 have the major version split across the top two fields).
 3. You will probably need to modify both CldrVersion.java and ToolConstants.java to bring them up to date.
 
-**log (set with \-l \<log\>, default\=CldrUtility.UTIL\_DATA\_DIR, set with CLDR\_DIR** 
+**log (set with \-l \<log\>, default\=CldrUtility.UTIL\_DATA\_DIR, set with CLDR\_DIR**
 
 Pass an argument for \-t to specify the output directory. Takes a few minutes to run (and make sure you have set Java with enough memory)!
 
-The tool generates (among other things) the following two binary files (among others) in the output directory specified with \-t: 
+The tool generates (among other things) the following two binary files (among others) in the output directory specified with \-t:
 
 - **outdated.data**
 - **outdatedEnglish.data**
@@ -60,7 +60,7 @@ Make sure TestOutdatedPaths.java passes. It may take some modifications, since i
 
 Run TestCheckCLDR and TestBasic with the option **\-prop:logKnownIssue\=false** (that option is important!). This checks that the Limited Submission is set up properly and that SubmissionLocales are correct.
 
- 
+
 
 If you run into any problems, look below at debugging.
 
@@ -72,7 +72,7 @@ Eg https://github.com/unicode-org/cldr/pull/243
 
 It also generates readable log files for double checking. These will be in {workspace}/cldr\-aux/births/\<version\>/, that is: CLDRPaths.AUX\_DIRECTORY \+ "births/" \+ trunkVersion. Examples: https://unicode.org/repos/cldr-aux/births/35.0/en.txt, https://unicode.org/repos/cldr-aux/births/35.0/fr.txt.
 
-Their format is the following (TSV \= tab\-delimited\-values) — to view, it is probably easier to copy the files into a spreadsheet. 
+Their format is the following (TSV \= tab\-delimited\-values) — to view, it is probably easier to copy the files into a spreadsheet.
 
 - English doesn't have the E... values, but is a complete record.
 - Other languages only have lines where the English value is more recently changed (younger) than the native’s.
@@ -94,4 +94,3 @@ Their format is the following (TSV \= tab\-delimited\-values) — to view, it is
 
 A value of � indicates that there is no value for that version.
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/coding-cldr-tools/documenting-cldr-tools.md

@@ -43,4 +43,3 @@ Additional parameters:
 
 Assuming your tools’s alias is *myalias,* create a new subpage with the URL http://cldr.unicode.org/tools/myalias (a subpage of [CLDR Tools](https://cldr.unicode.org/development/cldr-tools)). Fill this page out with information about how to use your tool.
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/creating-the-archive.md

@@ -43,10 +43,10 @@ A number of the tools in CLDR depend on access to older versions. These tools in
 4. Now, run the tool **org.unicode.cldr.tool.CheckoutArchive**
 	- Or from the command line:<br>
 	**mvn \-DCLDR\_DIR\=** *path\_to/cldr* **\-\-file\=tools/pom.xml \-pl cldr\-code compile \-DskipTests\=true exec:java \-Dexec.mainClass\=org.unicode.cldr.tool.CheckoutArchive  \-Dexec.args\=""**
-	- Note other options for this tool:  
-	  *\-\-help* will give help  
-	  *\-\-prune* will run a 'git workspace prune' before proceeding  
-	  *\-\-echo* will just show the commands that would be run, without running anything  
+	- Note other options for this tool:
+	  *\-\-help* will give help
+	  *\-\-prune* will run a 'git workspace prune' before proceeding
+	  *\-\-echo* will just show the commands that would be run, without running anything
 	(For example,  **\-Dexec.args\="\-\-prune"** in the above command line)
 
 The end result (where you need all of the releases) looks something like the following:
@@ -58,4 +58,3 @@ The end result (where you need all of the releases) looks something like the fol
 - You can set the property  **\-DCLDR\_ARCHIVE** to point to a different parent directory for the archive
 - You can set **\-DCLDR\_HAS\_ARCHIVE\=false** to tell unit tests and tools not to look for the archive
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process.md

@@ -166,4 +166,4 @@ If there is a test failure that is due to a bug that cannot be fixed right now (
 1. The future folder tickets are moved to the discuss folder
 2. Unscheduled tickets (with no release number) are re\-evaluated.
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)
+

docs/site/development/development-process/design-proposals.md

@@ -114,4 +114,3 @@ In each proposal, please add a header and a TOC if it is longer than a page. You
 
 [XMB](https://cldr.unicode.org/development/development-process/design-proposals/xmb)
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/alternate-time-formats.md

@@ -9,7 +9,7 @@ This design proposal is intended to solve the problem that sometimes the desired
 \<!ATTLIST pattern numbers CDATA #IMPLIED >
 
 The numbers attribute is used to indicate that numeric quantities in the pattern are to be rendered using a numbering system other than then default numbering system defined for the given locale. The attribute can be in one of two forms. If the alternate numbering system is intended to apply to ALL numeric quantities in the pattern, then simply use the numbering system ID as found in Section C.13 [Numbering Systems](http://www.unicode.org/reports/tr35/#Numbering_Systems). To apply the alternate numbering system only to a single field, the syntax "\<letter>=\<numberingSystem>" can be used one or more times, separated by semicolons.
- 
+
 Examples:
 
 \<pattern numbers="hebr">dd/mm/yyyy\</pattern>
@@ -28,4 +28,3 @@ Examples:
 
 In addition to the syntax, allow symbol or string replacements of the form "\<string>=\<numberingSystem>=\<replacementString>"
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/bcp-47-changes-draft.md

@@ -72,7 +72,7 @@ Macrolanguage Table
 | Kurdish 'ku' | Northern Kurdish 'kmr'? | We probably want to change the default content locale to ku-Latn |
 | Akan ' ak ' | Twi ' tw ' and Fanti ' fat' | This appears to be a mistake in ISO 639. See: ISO 636 Deprecation Requests . |
 | Persian  fas (fa) | Western Farsi pes and prs Dari | This appears to be a mistake in ISO 639. See: ISO 636 Deprecation Requests . |
- 
+
 These would also go into the \<alias> element of the supplemental metadata. We may add more such aliases over time, as we find new predominant forms. Note that we still need to offer both aliases for translation in many cases. For example, we want to show both 'no' and 'nb'.
 
 ## Lenient Parsing
@@ -90,7 +90,7 @@ There are many circumstances where we get less than perfect language identifiers
 	2. Remove the base language
 	3. This avoids having to store which languages are also extlangs, and what their prefixes are.
 
-People have to do #1. We should recommend #2, and make it easy to support #3. 
+People have to do #1. We should recommend #2, and make it easy to support #3.
 
 See demo at [http://unicode.org/cldr/utility/languageid.jsp](http://unicode.org/cldr/utility/languageid.jsp)
 
@@ -211,4 +211,3 @@ The languages are listed in the format Abkhazian [ab]-OR, where [xx] is the code
 - Yao [yao]-U, Yiddish [yi]-U, Yupik Language [ypk]-U
 - Zande [znd]-U, Zapotec [zap]-U, Zaza [zza]-U, Zenaga [zen]-U, Zuni [zun]-U
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/bcp47-syntax-mapping.md

@@ -215,4 +215,3 @@ The current CVS snapshot implementation uses CSS3 names. This proposal changes a
 
 CLDR uses Olson tzids. These IDs are usually made from \<continent>+"/"+\<exemplar city> and relatively long. To satisfy the syntax requirement discussed in this document, we need to map these IDs to relatively short IDs uniquely. The UN LOCODE is designed to assign unique location code and it satisfies most of the requirement. A LOCODE consists from 2 letter ISO country code and 3 letter location code. This proproposal suggest that a 5 letter LOCODE is used as a short time zone ID if examplar city has a exact match in LOCODE repertoire. Some Olson tzids do not have direct mapping in LOCODE. In this case, we assign our own codes to them, but using 3-4/6-8 letter code to distinguish them from LOCODE. For Olson tzid Etc/GMT\*, this proposal suggest "UTC" + ["E" | "W"] + nn (hour offset), for example, UTCE01 means 1 hour east from UTC (Etc/GMT-1). The proposed short ID list is attached in this [document](https://drive.google.com/file/d/1O9B_hO6uD4m7dtb-hU9euBkgP8nQxJ9X/view?usp=sharing).
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/bidi-handling-of-structured-text.md

@@ -357,4 +357,3 @@ The following rules in ar.xml ( Arabic ):
 \</sttDisplay>
 
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/change-to-sites.md

@@ -79,4 +79,3 @@ Possible Bug - needs investigation.
 
 ![image](../../../images/design-proposals/site_bug.png)
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/chinese-and-other-calendar-support-intercalary-months-year-cycles.md

@@ -74,7 +74,7 @@ Months are numbered 0-11 (the zero-based value of UCAL\_MONTH). When an intercal
 
 For purposes of add and set operations, month is treated as a tuple represented by UCAL\_MONTH and UCAL\_IS\_LEAP\_MONTH. If UCAL\_IS\_LEAP\_MONTH is 0 for a month that has a leap month following, then adding 1 month, or setting UCAL\_IS\_LEAP\_MONTH to 1, sets the calendar to the leap month (which has the same value for UCAL\_MONTH). If a month does not have a leap month following, then a set of UCAL\_IS\_LEAP\_MONTH to 1 is ignored.
 
-Years are numbered 1-60 (the value of UCAL\_YEAR) for each 60-year cycle. The era is incremented for each 60-year cycle, so we are currently in era 78. 
+Years are numbered 1-60 (the value of UCAL\_YEAR) for each 60-year cycle. The era is incremented for each 60-year cycle, so we are currently in era 78.
 
 Current ICU4C formatting for the Chinese calendar is completely broken. For example, the short date format in root and zh is currently “y'x'G-Ml-d”; the result this produces for Chinese era 78, year 29, month 4 (non-leap or leap), day 2 is “29x-4-”: There is no era value or leap month indicator, and non-literal fields after the ‘l’ pattern character are skipped.
 
@@ -86,7 +86,7 @@ In a non-leap year, months run 0-4 (for months Tishri-Shevat), skip 5 (“Adar I
 
 ### 3. Coptic and Ethiopic calendars
 
-Months are numbered 0-12. 
+Months are numbered 0-12.
 
 ### 4. Other calendars listed above
 
@@ -303,4 +303,3 @@ New tickets related to this, which supersede the above, are:
 - ICU [#9044](http://bugs.icu-project.org/trac/ticket/9044): Chinese cal dates can't always be parsed - document & fix tests
 - ICU [#9055](http://bugs.icu-project.org/trac/ticket/9055): Integrate Chinese cal pattern updates (cldrbug 4237), update tests
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/consistent-casing.md

@@ -154,4 +154,3 @@ I have attached "CasingContextsV2.pdf" which fixes the calendar menu example (th
 Updated to "[CasingContextsV3.pdf](https://drive.google.com/file/d/1mvXlCSPhU87nl9owW_ZeCYHy_pJ-RqHL/view?usp=sharing)" which adds an overall explanation of the purpose of this document as well as instructions for localizers to provide feedback.
 
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/coverage-revision.md

@@ -62,4 +62,3 @@ So with this in mind, I would like to propose the following structure to be adde
 
 Finding the appropriate coverage level value would then be a matter of searching the coverageLevel entries in numeric order by value looking for a match of the path vs. "//ldml/" + "regular expression". In other words, we would not specifically include "//ldml" in the expressions, since they would all start with that. Once a given xpath's coverage level value was determined, it shouldn't be too hard for us to simply filter out fields whose coverage level was higher then the requested. I suppose that we will need some wildcards similar to what Mark has started working on in his path filtering proposal.
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/currency-code-fallback.md

@@ -31,4 +31,3 @@ I'm leaning towards #1, just for simplicity.
 
 However, see also: http://www.unicode.org/cldr/bugs/locale-bugs?findid=2244
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/day-period-design.md

@@ -238,4 +238,3 @@ Code changes
 - We need to have a chart for the dayPeriodRules, like we do for plurals.
 - Add invariant testing in CheckAttributes.
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/delimiter-quotation-mark-proposal.md

@@ -10,7 +10,7 @@ The following is a proposal for how to handle the delimiter issues in CLDR, rais
 
 There are qute a number of problems in our delimiter data. Most of these are in the ‘lesser vetted’ languages, but some are in major languages. Problems include use of ASCII quotes, and obvious inconsistencies in data.
 
-The goal for the v49 release is to at least have consistent data, then have the translators look at the changes in the data submission phase for v50. 
+The goal for the v49 release is to at least have consistent data, then have the translators look at the changes in the data submission phase for v50.
 
 **Data Cleanup.** I went through the data, and cleaned up obvious problems (such as a generic ASCII quote on one side, and a curly quote on the other). I then compared it to the Wikipedia data where available; if there was a difference between CLDR and Wikipedia, I looked for original sources on the web. It is often a bit tricky, since there are be variant practices in many languages. The goal is to have it to be the most customary usage, but often it may not be clear which variant predominates.
 
@@ -21,7 +21,7 @@ Note that for a great many locales (especially African ones), there isn’t much
 1. Use the ASCII ugly quotes
 2. Reverse the two, which would be correct with all BIDI or with correct markup.
 
-Personally, I lean towards #2. 
+Personally, I lean towards #2.
 
 The first sheet has recommendations for changing; the others are just scratch sheets.
 
@@ -32,4 +32,3 @@ The first sheet has recommendations for changing; the others are just scratch sh
 
 [**Quotation (Delimiter) Proposal**](https://docs.google.com/spreadsheets/d/1_7vjBSmjlmevIQfpM4xX1yMGYQdibd6h8PTrQEPzzkQ/edit?gid=2#gid=2)
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)

docs/site/development/development-process/design-proposals/english-inheritance.md

@@ -36,7 +36,7 @@ A few releases back, we created the en\_001 locale in CLDR, that was intended to
 - Use en\_001 as the basis for translation in the CLDR Survey Tool instead of en.
 - Make en\_CA (English - Canada) inherit from en\_001 instead of en. The en\_CA locale should be reviewed to make sure that items that previously were correctly inherited from "en" (such as well understood time zone abbreviations ) are copied into the en\_CA locale.
 - Make sure that proper time formats are in place for en\_XX locales, where XX is any country where 12 hour clock is customary according to CLDR's supplemental data.
-- Review the inheritance table (below), making any necessary adjustments. It has been suggested that en\_ZA and en\_ZW should inherit from en\_GB instead of en\_001. 
+- Review the inheritance table (below), making any necessary adjustments. It has been suggested that en\_ZA and en\_ZW should inherit from en\_GB instead of en\_001.
 
 ### Reference: English locales and inheritance:
 
@@ -134,4 +134,3 @@ A few releases back, we created the en\_001 locale in CLDR, that was intended to
 |  en_ZM |  Zambia |  en_001 |
 |  en_ZW |  Zimbabwe |  en_001 |
 
-![Unicode copyright](https://www.unicode.org/img/hb_notice.gif)