CLDR-17462 update ST status icons for clarity
CLDR-17462
- [X] This PR completes the ticket.
ALLOW_MANY_COMMITS=true
Has this been pushed to staging for UI review?
Has this been pushed to staging for UI review?
Yes and you reviewed it, i'm preparing another push incorporating your feedback (such as the word 'inherited')
how's this for inherited+provisional?
@macchiati i've now updated staging to e39d2b80a8aa128491e26ef6ea340535d6b4951c
how's this for inherited+provisional?
I think that is ok, if you have a narrow space between them. That will allow for narrower columns
how's this for inherited+provisional?
I think that is ok, if you have a narrow space between them. That will allow for narrower columns
maybe a NNBSP
how's this for inherited+provisional?
I think that is ok, if you have a narrow space between them. That will allow for narrower columns
maybe a NNBSP
Chrome, right-aligned, nnbsp
I didn't mean NBSP. That will force all columns on the page to be wide if one of them is. I was thinking the reverse; adding a narrow space (aka thin space) to allow the two icons to be on different lines. Not a non-break one, a breaking one.
I didn't mean NBSP. That will force all columns on the page to be wide if one of them is. I was thinking the reverse; adding a narrow space (aka thin space) to allow the two icons to be on different lines. Not a non-break one, a breaking one.
different lines could be hard to scan, it'll look like alternating content. Here's the result with ZWSP:
Hmmm. Ok, let's try with them on the same line, and we'll ask the TC about it. Note: that only happens when the item being inherited is provisional or worse, right? If it is Contributes or Accepted, we see just a regular ⬆️, right?
I didn't mean NBSP. That will force all columns on the page to be wide if one of them is. I was thinking the reverse; adding a narrow space (aka thin space) to allow the two icons to be on different lines. Not a non-break one, a breaking one.
different lines could be hard to scan, it'll look like alternating content. Here's the result with ZWSP:
This looks OK to me, FWIW. I agree it's better than causing change in column width.
Hmmm. Ok, let's try with them on the same line, and we'll ask the TC about it. Note: that only happens when the item being inherited is provisional or worse, right? If it is Contributes or Accepted, we see just a regular ⬆️, right?
If I'm reading the logic correctly… only unconfirmed or provisional adds the "inherited" ⬆️. Otherwise it will only show the approved, contributed, missing symbols.
I don't see a code path where it shows only the uparrow.
If that is the case, we don't need the ⬆️ at all, just the X.
People will be able to see in the winning cell (from the color) that it is inherited, and the X tells them that it isn't approved/contributed
On Thu, May 30, 2024 at 10:59 AM Steven R. Loomis @.***> wrote:
Hmmm. Ok, let's try with them on the same line, and we'll ask the TC about it. Note: that only happens when the item being inherited is provisional or worse, right? If it is Contributes or Accepted, we see just a regular ⬆️, right?
If I'm reading the logic correctly… only unconfirmed or provisional adds the "inherited" ⬆️. Otherwise it will only show the approved, contributed, missing symbols.
I don't see a code path where it shows only the uparrow.
— Reply to this email directly, view it on GitHub https://github.com/unicode-org/cldr/pull/3763#issuecomment-2140484452, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMAYFZ2C4NLL5VDED63ZE5SHFAVCNFSM6AAAAABIPY5NRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBQGQ4DINBVGI . You are receiving this because you were mentioned.Message ID: @.***>
If that is the case, we don't need the ⬆️ at all, just the X. People will be able to see in the winning cell (from the color) that it is inherited, and the X tells them that it isn't approved/contributed
That's fine, we can drop the inheritance marker symbol then. (Reference to its discussion: CLDR-11103 )
So, thoughts? drop the inheritance icon?
Let's leave it in for now, so we don't delay.
@macchiati just to be really clear, you are approving
A: NNBSP e0a503e - this is the current code in the PR
(updated image)
B: https://github.com/unicode-org/cldr/commit/e39d2b80a8aa128491e26ef6ea340535d6b4951c what is currently on cldr-staging
C: (not committed) using a ZWSP instead of NNBSP
Let's leave it in for now, so we don't delay.
let me know A B or C and i'll accept the ticket and get ready to merge
Ok, if C: (not committed) using a ZWSP instead of NNBSP is ready to go, let's do that.
@macchiati it's option C now
Looks nice!


