From 0a5ff9ec08560a5ec068cbb571eeb3b9d06a04e5 Mon Sep 17 00:00:00 2001 From: btangmu Date: Tue, 15 Oct 2024 13:49:31 -0400 Subject: [PATCH] CLDR-8038 Fix links in several files in docs/site -Even with these changes, some of these files still have some broken links per lychee --- .../index/cldr-spec/collation-guidelines.md | 18 ++++---- docs/site/index/cldr-spec/plural-rules.md | 6 +-- docs/site/index/draft-schedule.md | 2 +- docs/site/index/locale-coverage.md | 2 +- docs/site/index/process.md | 46 +++++++++---------- .../translation/date-time/date-time-names.md | 12 ++--- 6 files changed, 42 insertions(+), 44 deletions(-) diff --git a/docs/site/index/cldr-spec/collation-guidelines.md b/docs/site/index/cldr-spec/collation-guidelines.md index 8a89f202e63..68a1bb730d5 100644 --- a/docs/site/index/cldr-spec/collation-guidelines.md +++ b/docs/site/index/cldr-spec/collation-guidelines.md @@ -6,15 +6,15 @@ title: Collation Guidelines Collation sequences can be quite tricky to specify. -The locale\-based collation rules in Unicode CLDR specify customizations of the standard data for [UTS \#10: Unicode Collation Algorithm](http://www.unicode.org/reports/tr10/#Introduction) (UCA). Requests to change the collation order for a given locale, or to supply additional variants, need to follow the guidelines in this document. +The locale\-based collation rules in Unicode CLDR specify customizations of the standard data for [UTS \#10: Unicode Collation Algorithm](https://www.unicode.org/reports/tr10/#Introduction) (UCA). Requests to change the collation order for a given locale, or to supply additional variants, need to follow the guidelines in this document. ## Filing a Request -Requests to change the collation order for a given locale, or to supply additional variants should be filed as CLDR bug tickets. See [CLDR Change Requests](/index/bug-reports) +Requests to change the collation order for a given locale, or to supply additional variants should be reported by [requesting changes](/requesting_changes). ### Rules -The request should present the precise change expressed as rules. The rules must be supplied in the syntax as specified in [http://www.unicode.org/reports/tr35/tr35\-collation.html\#Rules](http://www.unicode.org/reports/tr35/tr35-collation.html#Rules). (This used to be called the "basic syntax".) The rules must also be [Minimal Rules](/index/cldr-spec/collation-guidelines) as described below: *only* differences from [http://unicode.org/charts/uca/](http://unicode.org/charts/uca/) should be specified. +The request should present the precise change expressed as rules. The rules must be supplied in the syntax as specified in [https://www.unicode.org/reports/tr35/tr35\-collation.html\#Rules](https://www.unicode.org/reports/tr35/tr35-collation.html#Rules). (This used to be called the "basic syntax".) The rules must also be [Minimal Rules](#minimal-rules) as described below: *only* differences from [https://unicode.org/charts/uca/](https://unicode.org/charts/uca/) should be specified. *\& c \< cs* @@ -52,7 +52,7 @@ Provide justification for your change. Citations should be to authoritative page Please test out any suggested rules before filing a bug. -1. Go to the [ICU Collation Demo](http://demo.icu-project.org/icu-bin/collation.html). +1. Go to the [ICU Collation Demo](https://demo.icu-project.org/icu-bin/collation.html). 2. Pick the language for which you want to change the rules, or keep it on "und" (root) if you want to start from the Unicode/CLDR default sort order. 3. Put your rules into the "Append rules" box. 4. Put an interesting list of strings into the Input box. @@ -60,7 +60,7 @@ Please test out any suggested rules before filing a bug. Or -1. Go to the [ICU Locale Explorer](http://demo.icu-project.org/icu-bin/locexp). +1. Go to the [ICU Locale Explorer](https://demo.icu-project.org/icu-bin/locexp). 2. Pick the appropriate locale. 3. Follow the instructions at the bottom to use your suggested rules on your suggested test data. 4. Verify that the proper order results. @@ -71,7 +71,7 @@ The exact collation sequence for a given language may be difficult to determine. Most standards that specify collation, such as DIN or CS, are not targeted at algorithmic sorting, and are not complete algorithmic specifications. For example, CSN 97 6030 requires transliteration of foreign scripts, but there are many choices as to how to transliterate, and the exact mechanism is not specified. It also specifies that geometric shapes are sorted by the number of vertices and edges, which is, at a minimum, difficult to determine; and are subject to variation in glyphs. -The CLDR goals are to match the sorting of exemplar letters and common punctuation and leave everything else to the standard UCA ordering. For more information, see [UTS \#10: Unicode Collation Algorithm](http://www.unicode.org/reports/tr10/#Introduction) (UCA). +The CLDR goals are to match the sorting of exemplar letters and common punctuation and leave everything else to the standard UCA ordering. For more information, see [UTS \#10: Unicode Collation Algorithm](https://www.unicode.org/reports/tr10/#Introduction) (UCA). ### Determining Level Differences @@ -192,7 +192,7 @@ It would be possible instead to have rules that list every letter used by Slovak 1. Every time a character is tailored, the data for that character takes up more room in typical implementations. That means that the data for collation is larger, downloads of collation libraries with that data are slower, sort keys are longer, and performance is slower; sometimes very much so. 2. Related characters in the same script are in a peculiar order. For example, if the Slovak tailoring omits ƀ, then it would show up as after z. -You can see what the UCA currently does with a given script by looking at the charts at [Unicode Collation Charts](http://www.unicode.org/charts/collation/), or at the [UCA in ICU\-style rules](http://unicode.org/cldr/data/diff/collation/UCA.txt). For example, suppose that U\+0D89 SINHALA LETTER IYANNA and U\+0D8A SINHALA LETTER IIYANNA needed to come after U\+0D96 SINHALA LETTER AUYANNA, in primary order, and that otherwise DUCET was ok. Then you would give the following rules: +You can see what the UCA currently does with a given script by looking at the charts at [Unicode Collation Charts](https://www.unicode.org/charts/collation/), or at the [UCA in ICU\-style rules](https://unicode.org/cldr/data/diff/collation/UCA.txt). For example, suppose that U\+0D89 SINHALA LETTER IYANNA and U\+0D8A SINHALA LETTER IIYANNA needed to come after U\+0D96 SINHALA LETTER AUYANNA, in primary order, and that otherwise DUCET was ok. Then you would give the following rules: \& ඖ \# U\+0D96 SINHALA LETTER AUYANNA @@ -242,6 +242,6 @@ There are a number of pitfalls with collation, so be careful. In some cases, suc 6. The correct rules should be the minimal ones. 7. \& \[before 1] c \< ċ \<\<\< Ċ 8. This finds the highest primary (that's what the 1 is for) character less than c, and uses that as the reset point. For Maltese, the same technique needs to be used for ġ and ż. -2. **Blocking Contractions.** Contractions can be blocked with CGJ, as described in the Unicode Standard and in the [Characters and Combining Marks FAQ](http://www.unicode.org/faq/char_combmark.html). -3. **Case Combinations.** The lowercase, titlecase, and uppercase variants of contractions need to be supplied, with tertiary differences in that order (regardless of the caseFirst setting). That is, if *ch* is a contraction, then you would have the rules `... ch <<< Ch <<< CH`. Other case variants such as *cH* are excluded because they are unlikely to represent the contraction, for example in *McHugh*. (Therefore, *mchugh* and *McHugh* will be primary different if *ch* adds a primary difference.) \[[\#8248](http://unicode.org/cldr/trac/ticket/8248)] +2. **Blocking Contractions.** Contractions can be blocked with CGJ, as described in the Unicode Standard and in the [Characters and Combining Marks FAQ](https://www.unicode.org/faq/char_combmark.html). +3. **Case Combinations.** The lowercase, titlecase, and uppercase variants of contractions need to be supplied, with tertiary differences in that order (regardless of the caseFirst setting). That is, if *ch* is a contraction, then you would have the rules `... ch <<< Ch <<< CH`. Other case variants such as *cH* are excluded because they are unlikely to represent the contraction, for example in *McHugh*. (Therefore, *mchugh* and *McHugh* will be primary different if *ch* adds a primary difference.) \[[\#8248](https://unicode.org/cldr/trac/ticket/8248)] diff --git a/docs/site/index/cldr-spec/plural-rules.md b/docs/site/index/cldr-spec/plural-rules.md index a1405feff93..d26437e16dd 100644 --- a/docs/site/index/cldr-spec/plural-rules.md +++ b/docs/site/index/cldr-spec/plural-rules.md @@ -19,7 +19,7 @@ These categories are used to provide localized units, with a more natural ways o ## Reporting Defects -When you find errors or omissions in this data, please report the information with a [bug report](/index/bug-reports#TOC-Filing-a-Ticket). Please give examples of how the forms may differ. You don't have to give the exact rules, but it is extremely helpful! Here's an example:   +When you find errors or omissions in this data, please report the information by [filing a ticket](/requesting_changes#how-to-file-a-ticket). Please give examples of how the forms may differ. You don't have to give the exact rules, but it is extremely helpful! Here's an example:   **Sample Bug Report** @@ -172,7 +172,7 @@ In some sense, the names for the categories are somewhat arbitrary. Yet for cons - If there needs to be a category for items only have fractional values, use '**many**' 8. If there are more categories needed for the language, describe what those categories need to cover in the bug report. -See [*Language Plural Rules*](http://www.unicode.org/cldr/data/charts/supplemental/language_plural_rules.html) for examples of rules, such as for [Czech](https://www.unicode.org/cldr/charts/45/supplemental/language_plural_rules.html#cs), and for [comparisons of values](https://www.unicode.org/cldr/charts/45/supplemental/language_plural_rules.html#cs-comp). Note that in the integer comparison chart, most languages have 'x' (other—gray) for most integers. There are some exceptions (Russian and Arabic, for example), where the categories of 'many' and 'other' should have been swapped when they were defined, but are too late now to change. +See [*Language Plural Rules*](https://www.unicode.org/cldr/data/charts/supplemental/language_plural_rules.html) for examples of rules, such as for [Czech](https://www.unicode.org/cldr/charts/45/supplemental/language_plural_rules.html#cs), and for [comparisons of values](https://www.unicode.org/cldr/charts/45/supplemental/language_plural_rules.html#cs-comp). Note that in the integer comparison chart, most languages have 'x' (other—gray) for most integers. There are some exceptions (Russian and Arabic, for example), where the categories of 'many' and 'other' should have been swapped when they were defined, but are too late now to change. ## Important Notes @@ -188,7 +188,7 @@ If you were to substitute a different number for "1" in a sentence or phrase, wo ## Plural Rule Syntax -See [LDML Language Plural Rules](http://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules). +See [LDML Language Plural Rules](https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules). ## Plural Message Migration diff --git a/docs/site/index/draft-schedule.md b/docs/site/index/draft-schedule.md index 02571ad4576..059d6d62ce2 100644 --- a/docs/site/index/draft-schedule.md +++ b/docs/site/index/draft-schedule.md @@ -8,4 +8,4 @@ Two releases are regularly scheduled each year, currently one in mid-October, an The March release is intended to be less data-intensive, and sometimes involves little or no vetting. The current release is found at [Current CLDR Dev Version](https://docs.google.com/spreadsheets/d/1N6inI5R84UoYlRwuCNPBOAP7ri4q2CmJmh8DC5g-S6c/edit?gid=1680747936#gid=1680747936). -For more information about the various phases of the release, see [Survey Tool stages](../translation/getting-started/survey-tool-phases) +For more information about the various phases of the release, see [Survey Tool stages](/translation/getting-started/survey-tool-phases) diff --git a/docs/site/index/locale-coverage.md b/docs/site/index/locale-coverage.md index ef44ec67a51..5938ba05876 100644 --- a/docs/site/index/locale-coverage.md +++ b/docs/site/index/locale-coverage.md @@ -6,7 +6,7 @@ title: Locale Coverage Special Data ## Missing Features -The following may be listed as Missing features in a Locale Coverage chart, such as [v43 Locale Coverage](https://unicode-org.github.io/cldr-staging/charts/43/supplemental/locale_coverage.html). +The following may be listed as Missing features in a Locale Coverage chart, such as [v45 Locale Coverage](https://www.unicode.org/cldr/charts/45/supplemental/locale_coverage.html). ### Core diff --git a/docs/site/index/process.md b/docs/site/index/process.md index c96ebf4156c..e2caffc0a58 100644 --- a/docs/site/index/process.md +++ b/docs/site/index/process.md @@ -8,21 +8,21 @@ title: CLDR Process This document describes the Unicode CLDR Technical Committee's process for data collection, resolution, public feedback and release. -- The process is designed to be light-weight; in particular, the meetings are frequent, short, and informal. Most of the work is by email or phone, with a database recording requested changes (See [change request](/index/bug-reports)). +- The process is designed to be light-weight; in particular, the meetings are frequent, short, and informal. Most of the work is by email or phone, with a database recording requested changes (See [Requesting Changes](/requesting_changes)). - When gathering data for a region and language, it is important to have multiple sources for that data to produce the most commonly used data. The initial versions of the data were based on best available sources, and updates with new and improvements are released twice a year with work by contributors inside and outside of the Unicode Consortium. - It is important to note that CLDR is a Repository, not a Registration. That is, contributors should NOT expect that their suggestions will simply be adopted into the repository; instead, it will be vetted by other contributors. -- The [CLDR Survey Tool](http://www.unicode.org/cldr/survey_tool.html) is the main channel for collecting data, and bug/feature request are tracked in a database ([CLDR Bug Reports](http://www.unicode.org/cldr/filing_bug_reports.html)). +- The [CLDR Survey Tool](https://st.unicode.org) is the main channel for collecting data, and bug/feature requests are tracked in a database ([file a ticket](/requesting_changes#how-to-file-a-ticket)). - The final approval of the release of any version of CLDR is up to the decision of the CLDR Technical Committee. ## Formal Technical Committee Procedures -For more information on the formal procedures for the Unicode CLDR Technical Committee, see the [Technical Committee Procedures for the Unicode Consortium](http://www.unicode.org/consortium/tc-procedures.html). +For more information on the formal procedures for the Unicode CLDR Technical Committee, see the [Technical Committee Procedures for the Unicode Consortium](https://www.unicode.org/consortium/tc-procedures.html). ## Specification Changes -The [UTS #35: Locale Data Markup Language (LDML)](http://www.unicode.org/reports/tr35/) specification are kept up to date with each release with change/added structure for new data types or other features. +The [UTS #35: Locale Data Markup Language (LDML)](https://www.unicode.org/reports/tr35/) specification are kept up to date with each release with change/added structure for new data types or other features. -- Requests for changes are entered in the bug/feature request database ([CLDR Bug Reports](http://www.unicode.org/cldr/filing_bug_reports.html)). +- Requests for changes are entered in the bug/feature request database ([file a ticket](/requesting_changes#how-to-file-a-ticket)). - Structural changes are always backwards-compatible. That is, previous files will continue to work. Deprecated elements remain, although their usage is strongly discouraged. - There is a standing policy for structural changes that require non-trivial code for proper implementation, such as time zone fallback or alias mechanisms. These require design discussions in the Technical Committee that demonstrates correct function according to the proposed specification. @@ -32,9 +32,8 @@ The contributors of locale data are expected to be language speakers residing in There are two types of data in the repository: -- **Core data** (See [Core data for new locales](/index/cldr-spec/minimaldata)): The content is collected from language experts typically with a CLDR Technical Committee member involvement, and is reviewed by the committee. This is required for a new language to be added in CLDR. See also [Exemplar Character Sources](http://www.unicode.org/cldr/filing_bug_reports.html#Exemplar_Characters). -- **Common locale data**: This is the bulk of the CLDR data and data collection occurs twice a year using the Survey tool. (See [How to Contribute](/#TOC-How-to-Contribute-).) - +- **Core data** (See [Core data for new locales](/index/cldr-spec/core-data-for-new-locales)): The content is collected from language experts typically with a CLDR Technical Committee member involvement, and is reviewed by the committee. This is required for a new language to be added in CLDR. +- **Common locale data**: This is the bulk of the CLDR data and data collection occurs twice a year using the Survey tool. (See [Getting Started](/translation/getting-started).) The following 4 states are used to differentiate the data contribution levels. The initial data contributions are normally marked as draft; this may be changed once the data is vetted. @@ -65,7 +64,7 @@ These levels are decided by the technical committee and the TC representative fo - TC Organizations that are fully engaged in the CLDR Technical Committee are given a higher vote level of 6 votes to reflect their level of expertise and coordination in the working of CLDR and the survey tool as compared to the normal organization vote level of 4 votes - Liaison or associate members can assign to Guest, or to other levels with approval of the TC. - The liaison/associate member him/herself gets TC status in order to manage users, but gets a Guest status in terms of voting, unless the committee approves a higher level. -- Users assigned to "[unicode.org](http://unicode.org/)" are normally assigned as Guest, but the committee can assign a different level. +- Users assigned to "[unicode.org](https://unicode.org/)" are normally assigned as Guest, but the committee can assign a different level. ### Voting Process @@ -99,11 +98,11 @@ For each release, there is one optimal field value determined by the following: 1. *Established* locales are currently found in [coverageLevels.xml](https://github.com/unicode-org/cldr/blob/master/common/supplemental/coverageLevels.xml), with approvalRequirement\[@votes="8"\] - - Some specific items have an even higher threshold. See approvalRequirement elements in [coverageLevels.xml](http://unicode.org/repos/cldr/trunk/common/supplemental/coverageLevels.xml) for details. + - Some specific items have an even higher threshold. See approvalRequirement elements in [coverageLevels.xml](https://unicode.org/repos/cldr/trunk/common/supplemental/coverageLevels.xml) for details. 2. If the oldStatus is better than the new draft status, then no change is made. Otherwise, the optimal value and its draft status are made part of the new release. - For example, if the new optimal value does not have the status of **approved**, and the previous release had an **approved** value (one that does not have an error and is not a fallback), then that previously-released value stays **approved** and replaces the optimal value in the following steps. -It is difficult to develop a formulation that provides for stability, yet allows people to make needed changes. The CLDR committee welcomes suggestions for tuning this mechanism. Such suggestions can be made by filing a [new ticket](/index/bug-reports#TOC-Filing-a-Ticket). +It is difficult to develop a formulation that provides for stability, yet allows people to make needed changes. The CLDR committee welcomes suggestions for tuning this mechanism. Such suggestions can be made by [filing a ticket](/requesting_changes#how-to-file-a-ticket). ## Data- Resolution @@ -121,7 +120,7 @@ If a locale does not have minimal data (at least at a provisional level), then i This process can be fine-tuned by the Technical Committee as needed, to resolve any problems that turn up. A committee decision can also override any of the above process for any specific values. -For more information see the key links in [CLDR Survey Tool](http://www.unicode.org/cldr/survey_tool.html) (especially the Vetting Phase). +For more information see the key links in [CLDR Survey Tool](https://st.unicode.org) (especially the Vetting Phase). **Notes:** - If data has a formal problem, it can be fixed directly (in CVS) without going through the above process. Examples include: @@ -132,12 +131,11 @@ For more information see the key links in [CLDR Survey Tool](http://www.unicode. - The TC committee can authorize bulk submissions of new data directly (CVS), with all new data marked draft="unconfirmed" (or other status decided by the committee), but only where the data passes the CheckCLDR console tests. - The survey tool does not currently handle all CLDR data. For data it doesn't cover, the regular bug system is used to submit new data or ask for revisions of this data. In particular: - Collation, transforms, or text segmentation, which are more complex. - - For collation data, see the comparison charts at [http://www.unicode.org/cldr/comparison\_charts.html](http://www.unicode.org/cldr/comparison_charts.html) or the XML data at [http://unicode.org/cldr/data/common/collation/](http://unicode.org/cldr/data/common/collation/) - - For transforms, see the XML data at [http://unicode.org/cldr/data/common/transforms/](http://unicode.org/cldr/data/common/transforms/) + - For collation data, see the comparison charts at [https://www.unicode.org/cldr/comparison\_charts.html](https://www.unicode.org/cldr/comparison_charts.html) or the XML data at [https://unicode.org/cldr/data/common/collation/](https://unicode.org/cldr/data/common/collation/) + - For transforms, see the XML data at [https://unicode.org/cldr/data/common/transforms/](https://unicode.org/cldr/data/common/transforms/) - Non-linguistic locale data: - - XML data: [http://unicode.org/cldr/data/common/supplemental/](http://unicode.org/cldr/data/common/supplemental/) - - HTML view: [http://www.unicode.org/cldr/data/diff/supplemental/supplemental.html](http://www.unicode.org/cldr/data/diff/supplemental/supplemental.html) - + - XML data: [https://unicode.org/cldr/data/common/supplemental/](https://unicode.org/cldr/data/common/supplemental/) + - HTML view: [https://www.unicode.org/cldr/data/diff/supplemental/supplemental.html](https://www.unicode.org/cldr/data/diff/supplemental/supplemental.html) ### Prioritization @@ -159,13 +157,13 @@ The structure and DTD may change, but except for additions or for small bug fixe ## Public Feedback Process -The public can supply formal feedback into CLDR via the [Survey Tool](http://unicode.org/cldr/apps/survey/) or by filing a [Bug Report or Feature Request](http://www.unicode.org/cldr/filing_bug_reports.html). There is also a public forum for questions at [CLDRMailing List](https://www.unicode.org/consortium/distlist.html#cldr_list) (details on archives are found there). +The public can supply formal feedback into CLDR via the [Survey Tool](https://st.unicode.org) or by [filing a ticket](/requesting_changes#how-to-file-a-ticket). There is also a public forum for questions at [CLDR Mailing List](https://www.unicode.org/consortium/distlist.html#cldr_list) (details on archives are found there). -There is also a members-only [CLDRmailing list](https://www.unicode.org/members/index.html#cldr) for members of the CLDR Technical Committee. +There is also a members-only [CLDR mailing list](https://www.unicode.org/members/index.html#cldr) for members of the CLDR Technical Committee. -[Public Review Issues](http://www.unicode.org/review/) may be posted in cases where broader public feedback is desired on a particular issue. +[Public Review Issues](https://www.unicode.org/review/) may be posted in cases where broader public feedback is desired on a particular issue. -Be aware that changes and updates to CLDR will only be taken in response to information entered in the [Survey Tool](http://unicode.org/cldr/apps/survey/) or by filing a [Bug Report or Feature Request](http://www.unicode.org/cldr/filing_bug_reports.html). Discussion on public mailing lists is not monitored; no actions will be taken in response to such discussion -- only in response to filed bugs. The process of checking and entering data takes time and effort; so even when bugs/feature requests are accepted, it may take some time before they are in a release of CLDR. +Be aware that changes and updates to CLDR will only be taken in response to information entered in the [Survey Tool](https://st.unicode.org) or by [filing a ticket](/requesting_changes#how-to-file-a-ticket). Discussion on public mailing lists is not monitored; no actions will be taken in response to such discussion -- only in response to filed bugs. The process of checking and entering data takes time and effort; so even when bugs/feature requests are accepted, it may take some time before they are in a release of CLDR. ## Data Release Process @@ -175,7 +173,7 @@ The locale data is frozen per version. Once a version is released, it is never m ### Release Schedule -Early releases of a version of the common locale data will be issued as either alpha or beta releases, available for public feedback. The dates for the next scheduled release will be on [CLDR Project](http://www.unicode.org/cldr/index.html). +Early releases of a version of the common locale data will be issued as either alpha or beta releases, available for public feedback. The dates for the next scheduled release will be on [CLDR Project](https://www.unicode.org/cldr/index.html). The schedule milestones are listed below. @@ -192,9 +190,9 @@ Labels in the **Jira** column correspond to the **phase** field in Jira. Phase f ## Meetings and Communication -The currently-scheduled meetings are listed on the [Unicode Calendar](http://www.unicode.org/timesens/calendar.html). Meetings are held by phone, every week at 8:00 AM Pacific Time (-08:00 GMT in winter, -07:00 GMT in summer). Additional meeting is scheduled every other Mondays depending on the need and people's availability. +The currently-scheduled meetings are listed on the [Unicode Calendar](https://www.unicode.org/timesens/calendar.html). Meetings are held by phone, every week at 8:00 AM Pacific Time (-08:00 GMT in winter, -07:00 GMT in summer). Additional meeting is scheduled every other Mondays depending on the need and people's availability. -There is an internal email list for the Unicode CLDR Technical Committee, open to Unicode members and invited experts. All national standards bodies who are interested in locale data are also invited to become involved by establishing a [Liaison membership](http://www.unicode.org/consortium/join.html) in the Unicode Consortium, to gain access to this list. +There is an internal email list for the Unicode CLDR Technical Committee, open to Unicode members and invited experts. All national standards bodies who are interested in locale data are also invited to become involved by establishing a [Liaison membership](https://www.unicode.org/consortium/join.html) in the Unicode Consortium, to gain access to this list. ## Officers diff --git a/docs/site/translation/date-time/date-time-names.md b/docs/site/translation/date-time/date-time-names.md index 69adb831b16..2d713bf5679 100644 --- a/docs/site/translation/date-time/date-time-names.md +++ b/docs/site/translation/date-time/date-time-names.md @@ -14,7 +14,7 @@ Certain calendar fields can have both numeric and textual forms. **Textual forms - Wide (e.g. Sunday) - Abbreviated (e.g Sun) - Narrow (e.g. S) - - There are two styles. For more information, see [When to use standalone vs. formatting](/translation/date-time-1/date-time-patterns#TOC-When-to-use-Standalone-vs.-Formatting) in Date/Time patterns. + - There are two styles. For more information, see [When to use standalone vs. formatting](/translation/date-time/date-time-patterns#when-to-use-standalone-vs-formatting) in Date/Time patterns. - Formatting - Standalone - Capitalization should follow the middle of a sentence rule. For more information, see [Capitalization](/translation/translation-guide-general/capitalization).   @@ -60,7 +60,7 @@ Era names are in Gregorian Calendar and other calendars: - There are only two values for an era in a Gregorian calendar. - The common use of these era names in English are more for religious forms. "BC" (Before Christ) and AD (Anno Domini)" - from the Latin for "The year of our Lord". - The secular equivalents of these two era names are "BCE" (Before Common Era) and "CE" (Common Era). -- Other calendars (see [Different calendars in Date/Time patterns](/translation/date-time-1/date-time-patterns#TOC-Different-Calendars-)) have a different numbers of eras. +- Other calendars (see [Different calendars in Date/Time patterns](/translation/date-time/date-time-patterns#different-calendars)) have a different numbers of eras. - The names for eras are often specific to the given calendar, such as the Japanese era names. - If other calendars are in common use in one of the countries/regions that use your language, other calendars will show under the modern coverage level. @@ -86,7 +86,7 @@ This field is one of the months of the year, such as January or February.  - Used in patterns with a day number. (e.g. Finnish, and many Slavic languages distinguish between nominative and genitive/related) - Use the type such as the nominative case for **Standalone** month names. - Used in pattern without a day number. -- The specific values that are used in the format and stand-alone names need to be closely co-ordinated with the date patterns that will use them. See [When to use standalone vs. format names](/translation/date-time-1/date-time-patterns#TOC-When-to-use-Standalone-vs.-Formatting) in Date/Time patterns. +- The specific values that are used in the format and stand-alone names need to be closely co-ordinated with the date patterns that will use them. See [When to use standalone vs. format names](/translation/date-time/date-time-patterns#when-to-use-standalone-vs-formatting) in Date/Time patterns. - Some languages (for example, Catalan) use a preposition to combine the month and day number like in the format “11 de setembre” (11 of September). If the month name begins with a vowel, the preposition is contracted, for example, “12 d’octubre - Include the preposition in its correct form (contracted or not) for formatting month names - DO NOT include the preposition for standalone month names and in patterns that use standalone month names @@ -95,7 +95,7 @@ This field is one of the months of the year, such as January or February.  This field is one of the days of the week: Monday, Tuesday, Wednesday, etc... -Same as month names, you need to use different symbols to coordinate use of standalone (e.g. cccc) and format names (e.g. EEEE) in patterns. See [When to use standalone vs. format names](/translation/date-time-1/date-time-patterns#TOC-When-to-use-Standalone-vs.-Formatting) in Date/Time patterns. +Same as month names, you need to use different symbols to coordinate use of standalone (e.g. cccc) and format names (e.g. EEEE) in patterns. See [When to use standalone vs. format names](/translation/date-time/date-time-patterns#when-to-use-standalone-vs-formatting) in Date/Time patterns. 💡 **Translation Tips** @@ -107,7 +107,7 @@ Same as month names, you need to use different symbols to coordinate use of stan AM/PM (special handling for locales using 24 hrs) -Also see [Additional Date/time formats](/translation/date-time-1/date-time-patterns#TOC-Additional-Date-Time-Formats).  +Also see [Additional Date/time formats](/translation/date-time/date-time-patterns#additional-date-time-formats).  💡 **Translation Tips** @@ -169,7 +169,7 @@ In formatting, where your language has a term for midnight, it is used instead o These mark approximate periods in the day, _and those periods differ between languages_. The codes are arbitrary, and don't have to match the English meaning for your language: the important feature is the time span. The spans are approximate; in reality they may vary with the time of year (they might be dependent on sunrise), or context (someone might say they went to bed at 2 at night, and later one say that they woke up at 2 in the morning).  -**For a list of the day period IDs defined in CLDR for your language, see [Day Periods](https://www.unicode.org/cldr/charts/45/supplemental/day_periods.html)**. If you think the rules are wrong (or missing) for your language, please [file a ticket](/index/bug-reports#TOC-Filing-a-Ticket) and supply the missing information. Here are examples for English and Chinese. +**For a list of the day period IDs defined in CLDR for your language, see [Day Periods](https://www.unicode.org/cldr/charts/45/supplemental/day_periods.html)**. If you think the rules are wrong (or missing) for your language, please [file a ticket](/requesting_changes#how-to-file-a-ticket) and supply the missing information. Here are examples for English and Chinese. | Code | English | Span | Chinese | Span | |---|---|---|---|---|