A file linked from a certain version of LDML specification might match the description. For example, LDML specification v38 may link to CLDR v39 data when "latest" is changed to CLDR v39, and the content might not match the older LDML specification.
"Note: Some links may lead to in-development or older versions of the data files. See https://cldr.unicode.org for up-to-date CLDR release data."
Steven R. Loomis February 3, 2022 at 11:35 PM
Edited
at f2f:
links should go to main
add a warning at the top of every spec page (which could have a link to a more-info page)
Peter Edberg October 28, 2021 at 9:28 PM
Edited
I filed a separate ticket for broken links from LDML spec into sites pages (since that needs a PR): . Many of the other problems above do not need a PR.
Mark Davis October 21, 2021 at 7:23 PM
Steven, as per the discussion in the meeting, I think we should broaden this ticket out to cover:
A. Three kinds of problems:
Bad links to the old repo, or
to the old Sites, or
with http instead of https
B. In four locations
In the LDML spec documents
In any Charts
In the new Sites
In the Survey Tool
Steven R. Loomis February 12, 2021 at 6:25 PM
Need to delete the ‘latest’ tag, it does not make sense in git.
LDML specification contains many links to CLDR data files.
I found a few patterns of links.
1. Stale link
In the table: http://unicode.org/reports/tr35/#Key_And_Type_Definitions_
The valid values are those name attribute values in the type elements of key name="ca" in bcp47/calendar.xml.
Above one is linked to https://github.com/unicode-org/cldr/tree/latest/common/bcp47/calendar.xml
There are a couple of issues with this link.
"latest" tag is still at CLDR 36.1 level - https://github.com/unicode-org/cldr/releases/tag/latest (Mar 10, 2020)
A file linked from a certain version of LDML specification might match the description. For example, LDML specification v38 may link to CLDR v39 data when "latest" is changed to CLDR v39, and the content might not match the older LDML specification.
2. Broken Link
In http://unicode.org/reports/tr35/#Unicode_Locale_Extension_Data_Files
The 't' extension data is stored in common/bcp47/transform.xml.
This one is linked to https://github.com/unicode-org/cldr/releases/tag/latest/common/bcp47/transform.xml which is not reachable.