Probably not lb=AL.
L2/25-159 proposes PO but the Saudi Riyal has PR.
@eggrobin @Ken-Whistler PO or PR?
John see

• https://www.unicode.org/reports/tr14/#PO
• https://www.unicode.org/reports/tr14/#PR
• [:Uβ:gc=Sc:] grouped by lb

Hmm, I think I had written something about PO vs. PR in discussion of the Riyal, let me see if I can find that…

Ah yes, in https://github.com/unicode-org/sah/issues/619, published in L2/25-087:

In particular, Line_Break=PR, not PO. Note that the difference between PR and PO is nowadays only relevant in an East Asian context; see Section 3 of document L2/05-292, adopted by decision 105-C37, has useful background here. The point of picking lb=PR or lb=PO is to allow a break, as in お白湯は÷¥500頂戴しております。 or 上記税込価格にサービス料として10％÷を頂戴いたします. Since the currency sign is meant to be prefix in LTR text, it would likely be prefix in CJK text as currency signs usually are (with exceptions such as ¢), so that we would expect お白湯は÷SAR sign13頂戴しております。 and the character should be lb=PR like ¥.

So the question is whether it would be prefix in a CJK context.

Comparing Saudi (PR) and UAE websites, it looks like PR is the appropriate value.

@Ken-Whistler usually adds things into the Index late in a release. Ken, do you want this here in the pending-for-18 pull request?

Ken generates the NamesList from other sources, and likes to add change comments at the top. I assume that he would prefer not to add this in this kind of PR.

Yes, NamesList should not be touched by these PRs.

I agree with Robin. Don't touch NamesList.txt directly. (And don't deal with Index.txt, either -- updating that is outside the context of establishing the properties.)

please revert files that only have time stamp changes

DerivedAge (like the Derived files generally) is never hand-edited, only regenerated as described in https://github.com/unicode-org/unicodetools/blob/main/docs/pipeline.md#regenerate-ucd.

This means that it will falsely say that this file is targeted for 17.0 (because we don’t have an 18.0 yet). That is OK, it will get regenerated to 18 once we have an 18 and the merge/regenerate commands get run on that PR.

The CI is supposed to put up a warning saying that this does not actually target 17 (otherwise some people in the public get false hopes looking at the diffs), but it does not know about 18, only about provisional assignment. I will fix the CI.