Preparations for LDML 48 release #1096
Conversation
|
Some of this is done by the LDML build process? Did you talk to @srl295 about making these changes? I can walk you through the LDML tooling (which is pretty slick) |
|
Really? I didn't know, so just put together a script with which I got the spec from the I'd thought that the CLDR scripts would take care of things from there onwards; if there's some part that's unnecessary, good! |
|
Ah, so you found the steps I was going to point to, which I automated on my desktop Linux box, but didn't check in 😛. The changes to make unique IDs in this PR are totally necessary. I wouldn't pre-generate the TOC the way your readme (and my notes) suggests. The tool is fine--if you've fixed it so the IDs are unique. Some of the |
| _This is a draft document which may be updated, replaced, or superseded by other documents at any time. | ||
| Publication does not imply endorsement by the Unicode Consortium. | ||
| This is not a stable document; it is inappropriate to cite this document as other than a work in progress._ | ||
|
|
||
| <!-- _This document has been reviewed by Unicode members and other interested parties, and has been approved for publication by the Unicode Consortium. | ||
| This is a stable document and may be used as reference material or cited as a normative reference by other specifications._ --> |
There was a problem hiding this comment.
Is the draft text exposed because this is the editor's copy? Each release after LDML47 should be stable, no??
There was a problem hiding this comment.
The release, yes, but I think what's in CLDR's main branch still counts as a draft. This is copied from there.
Didn't find it until now, at: https://github.com/unicode-org/cldr/tree/main/tools/scripts/tr-archive The I'm rather tempted to set up a GitHub action to keep a rendered copy of our spec version continuously available via GitHub Pages; it should be pretty easy with the |
That was (perpetually) on my to-do list. Having the HTML render makes all the linkify formatting stuff rewarding in real time! |
|
I complicated it. The scripts are now Node.js rather than zshell, and there's a And there's a GitHub Action that'll re-build the spec when it changes, and deploy it to https://unicode-org.github.io/message-format-wg/ |
| numberFunctions: "../spec/functions/number.md", | ||
| datetimeFunctions: "../spec/functions/datetime.md", |
There was a problem hiding this comment.
This... feels brittle? The list of function specs are the part of the spec that will evolve/change over time and probably should be self-describing somehow? Just a thought.
There was a problem hiding this comment.
Feels like a thing to fix if/when it breaks? We need to enumerate the sections in order to set their order in the spec, and that's currently done here.
| ## Parts | ||
|
|
||
| The LDML specification is divided into the following parts: | ||
|
|
||
| * Part 1: [Core](tr35.md#Contents) (languages, locales, basic structure) | ||
| * Part 2: [General](tr35-general.md#Contents) (display names & transforms, etc.) | ||
| * Part 3: [Numbers](tr35-numbers.md#Contents) (number & currency formatting) | ||
| * Part 4: [Dates](tr35-dates.md#Contents) (date, time, time zone formatting) | ||
| * Part 5: [Collation](tr35-collation.md#Contents) (sorting, searching, grouping) | ||
| * Part 6: [Supplemental](tr35-info.md#Contents) (supplemental data) | ||
| * Part 7: [Keyboards](tr35-keyboards.md#Contents) (keyboard mappings) | ||
| * Part 8: [Person Names](tr35-personNames.md#Contents) (person names) | ||
| * Part 9: [MessageFormat](tr35-messageFormat.md#Contents) (message format) | ||
| * Appendix A: [Modifications](tr35-modifications.md#modifications) | ||
| * Appendix B: [Acknowledgments](tr35-acknowledgments.md#acknowledgments) |
There was a problem hiding this comment.
I obsoleted this a bit recently, where the Parts part is updated automatically. It would be fine to keep this minimal for MFWG (just link to Part 1).
There was a problem hiding this comment.
At least for now, the publish/update-header-footer.mjs script lets us extract the header from the tr35-messageFormat.md file in the CLDR repo, so that we can apply any necessary modifications to it. This way you should be able to continue to maintain that part in the CLDR repo, while we also can update it when proposing changes. In other words, the source of truth for the header is the CLDR repo, not this file.
So as merged, I don't see any major structural issues. This is now better documented and supported by tools than the tr-archiver has been! Congrats I think. Anyway, I don't see any problem with pushing on here and we'll deal with any issues once we actually merge back into CLDR… |
publish/with an instructional readme & publication script.