CLDR-17839 Further fixes for Hebrew units

[macchiati]

CLDR-17839

Working off of https://docs.google.com/spreadsheets/d/1dRVt9xb4Ffsf86DrxbPIaj26qVz0GB7DL7yyE9N5pfI/edit?gid=2136703940#gid=2136703940 , which has units that contained {, but didn’t start with {0}.

In particular:

• fixed patterns have {0} uniformly at the start, if it wasn't already. 
  • there were 2 exceptions, with a medial {0} that I left alone.
• fixed a few places where the unit started or ended with a neutral (by protecting with LRM or LRM)
• fixed some others that had excess LRM/RLM
  • the remaining LRMs — for clarity in review — are all in xml format (‎), which will be converted back to the regular character during cldr modify passes.
• fixed places where apostrophe was used instead of  ‎׳‎ U+05F3 HEBREW PUNCTUATION GERESH

For the future, I think we should provide warnings for problems for vetters.

Important for review!

• The text in an XML editor will often show up in a way hides the internal structure. In particular, the {0} may appear to be at the start, but actually be at the end. To make it more confusion, both the form at the start and the form at the end will appear identical!
• If you want to check, there are two ways.
  • Go to https://util.unicode.org/UnicodeJsps/bidi.jsp and pasted in the values into Sample. Hit Show Bidi button, and look at the memory positions.
  • Use CLDR Staging to look at some of the changed items, including the examples.

For example the first changed line shows (old/new):

<unitPattern count="one">דקת קשת {0}</unitPattern>
<unitPattern count="one">{0} דקת קשת</unitPattern>

These look identical when using an English browser to see the Files Changed, but when you paste them into the following and compare the two Memory Position rows, you'll see that the first Memory Position has {0} at the end (pos 33-35) and the second Memory Position has it at the start (pos 25-26)
https://util.unicode.org/UnicodeJsps/bidi.jsp?a=%3CunitPattern+count%3D%22one%22%3E%D7%93%D7%A7%D7%AA+%D7%A7%D7%A9%D7%AA+%7B0%7D%3C%2FunitPattern%3E%0D%0A%3CunitPattern+count%3D%22one%22%3E%7B0%7D+%D7%93%D7%A7%D7%AA+%D7%A7%D7%A9%D7%AA%3C%2FunitPattern%3E&p=Auto

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[AEApple]

Interesting that fixing the directionality has led to a collision failure.

[macchiati]

Yes, the error was hidden before. A "point" (a typographic measure) and "dot" (completely different measure, for screen resolution) are given the same name. Dot can have the same name as pixel, so I propose changing it to that to resolve the issue.

[AEApple]

Yes, the error was hidden before. A "point" (a typographic measure) and "dot" (completely different measure, for screen resolution) are given the same name. Dot can have the same name as pixel, so I propose changing it to that to resolve the issue.

SGTM!

[AEApple]

I'm actually just going to put it on staging for review.

[AEApple]

I'm actually just going to put it on staging for review.

Nevermind I couldn't figure out how to stage from another fork. I will stage my commit for now.

[srl295]

I'm actually just going to put it on staging for review.

Nevermind I couldn't figure out how to stage from another fork. I will stage my commit for now.

You change unicode-org/cldr to yourfork/cldr in the workflow run. (Assuming your forks name is cldr). The hash has to be present in that fork.

[macchiati]

Ping for review