CLDR-17470 Fix day period order in Tamil time format patterns

[echeran]

CLDR-17470

• This PR completes the ticket.

This PR reorders the day period in time formats to follow minutes and seconds and before the time zone, as is standard for Tamil, and which is similar to many other locales.

ALLOW_MANY_COMMITS=true

[markusicu]

@macchiati @AEApple @srl295 is it correct to target main at this time for 45?

[AEApple]

We haven't branched yet. We need to also fix 'PM', currently 'AM' & 'PM' are treated differently.

[srl295]

@macchiati @AEApple @srl295 is it correct to target main at this time for 45?

yes, if it is merged soon.

[AEApple]

Please fix AM/PM inconsistency

[markusicu]

Please fix AM/PM inconsistency

Wouldn't that be better in a separate PR, so that each PR makes sense on its own, and you need not explain to @echeran what exactly you want him to change?

[echeran]

Please fix AM/PM inconsistency

Wouldn't that be better in a separate PR, so that each PR makes sense on its own, ...

I think separate PRs is cleaner for the codebase (the commit messages remain specific enough to be accurate & useful).

If it's acceptable, any followup PR for resolving the AM/PM inconsistency can reuse the same CLDR ticket number, which can reduce overhead on process with tickets.

[srl295]

Please fix AM/PM inconsistency

Wouldn't that be better in a separate PR, so that each PR makes sense on its own, ...

I think separate PRs is cleaner for the codebase (the commit messages remain specific enough to be accurate & useful).

If it's acceptable, any followup PR for resolving the AM/PM inconsistency can reuse the same CLDR ticket number, which can reduce overhead on process with tickets.

To expand on this, in the CLDR process, each approved PR becomes a separate commit. So, having two PRs will produce independent commits in the final release. Reusing the commit number is fine if the change is relevant.

[markusicu]

@macchiati @AEApple I propose that we let Elango merge this PR as is, and make more changes in another PR.

From the ticket:

We will be accepting feedback until Friday March 29th, otherwise the change will be made in 45.

Does this mean we need to wait until Friday before merging?
Or can Elango merge now, and if someone disagrees it gets reverted or otherwise modified again?

[macchiati]

We could do the merge now if it makes things easier, on the condition that it be backed out if necessary. But to make the book-keeping easier we should address the PM translation also in this PR, so there is only one thing to back out.

…

On Wed, Mar 27, 2024 at 2:10 PM Markus Scherer ***@***.***> wrote: @macchiati <https://github.com/macchiati> @AEApple <https://github.com/AEApple> I propose that we let Elango merge this PR as is, and make more changes in another PR. From the ticket: We will be accepting feedback until Friday March 29th, otherwise the change will be made in 45. Does this mean we need to wait until Friday before merging? Or can Elango merge now, and if someone disagrees it gets reverted or otherwise modified again? — Reply to this email directly, view it on GitHub <#3577 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMGOLPBJP4VVKOV2RSTY2MYURAVCNFSM6AAAAABFJ4PJZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRTHE4TKOJXGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[markusicu]

We could do the merge now if it makes things easier, on the condition that it be backed out if necessary.

IMO: In that case I would wait until the light is truly green.
When do you plan to branch?

But to make the book-keeping easier we should address the PM translation also in this PR, so there is only one thing to back out.

The two problems are not really connected, and thus cleaner as separate PRs; and if one needs to be reverted, the other one is likely not affected, so separate PRs make that easier, too.

[macchiati]

We would like to branch at the end of the week. While in theory the changes are disconnected, in practice they are joined at the hip.

…

On Wed, Mar 27, 2024 at 2:20 PM Markus Scherer ***@***.***> wrote: We could do the merge now if it makes things easier, on the condition that it be backed out if necessary. IMO: In that case I would wait until the light is truly green. When do you plan to branch? But to make the book-keeping easier we should address the PM translation also in this PR, so there is only one thing to back out. The two problems are not really connected, and thus cleaner as separate PRs; and if one needs to be reverted, the other one is likely not affected, so separate PRs make that easier, too. — Reply to this email directly, view it on GitHub <#3577 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMHQXBVSMRFZBMEQA63Y2MZZ3AVCNFSM6AAAAABFJ4PJZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRUGAYDSOBUHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[echeran]

@AEApple @macchiati PTAL. The change for AM/PM consistency was made to follow CLDR-TC recommendations from this morning.

[macchiati]

LGTM, but don't merge unit we have the go-ahead.

[markusicu]

@echeran so far has fixed <dayPeriodWidth type="abbreviated"> / <dayPeriod type="pm">
but he found that other widths of am and/or pm are also inconsistent, and some use Tamil strings.
It's a real ransom-note effect. Should they all be fixed together?
In particular, if abbreviated uses ASCII "AM" & "PM", then narrow should use those, too, right?
I guess that wide strings could be different.

With the fix, so far:

• <dayPeriodContext type="format">
  • <dayPeriodWidth type="abbreviated">
    • <dayPeriod type="am">↑↑↑</dayPeriod>
    • <dayPeriod type="pm">↑↑↑</dayPeriod>
  • <dayPeriodWidth type="narrow">
    • <dayPeriod type="am">மு.ப</dayPeriod>
    • <dayPeriod type="pm">பி.ப</dayPeriod>
  • <dayPeriodWidth type="wide">
    • <dayPeriod type="am">↑↑↑</dayPeriod>
    • <dayPeriod type="pm">↑↑↑</dayPeriod>
• <dayPeriodContext type="stand-alone">
  • <dayPeriodWidth type="abbreviated">
    • <dayPeriod type="am">முற்பகல்</dayPeriod>
    • <dayPeriod type="pm">↑↑↑</dayPeriod>
  • <dayPeriodWidth type="narrow">
    • <dayPeriod type="am">மு.ப</dayPeriod>
    • <dayPeriod type="pm">பி.ப</dayPeriod>
  • <dayPeriodWidth type="wide">
    • <dayPeriod type="am">முற்பகல்</dayPeriod>
    • <dayPeriod type="pm">↑↑↑</dayPeriod>

[AEApple]

I would strongly prefer we fix for consistency if we're able to.

[macchiati]

Yes, I agree.

…

On Wed, Mar 27, 2024 at 8:39 PM Annemarie Apple ***@***.***> wrote: I would strongly prefer we fix for consistency if we're able to. — Reply to this email directly, view it on GitHub <#3577 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMEZYNQW4ROK2T4J2DLY2OGH3AVCNFSM6AAAAABFJ4PJZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRUGMZTSNBXGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[markusicu]

I would strongly prefer we fix for consistency if we're able to.

So ASCII "AM" & "PM" (="↑↑↑") all the way for CLDR 45?

[echeran]

I would strongly prefer we fix for consistency if we're able to.

So ASCII "AM" & "PM" (="↑↑↑") all the way for CLDR 45?

I changed am and pm to ASCII "AM" and "PM" for all contexts & widths. I also reverted an unwitting mistake regarding the order of B (flexible day periods) in timeFormat/dateFormat/etc. patterns so that the only changes in this PR should only be about AM/PM (ordering + locale display string).

[markusicu]

LGTM, but don't merge unit we have the go-ahead.

I assume that we are still waiting until tomorrow morning?

[AEApple]

We should merge tomorrow if there are no concerns raised.

[markusicu]

On the ticket, @AydaTolaymat responded

• checked internally with Tamil speaking colleague at Apple and they approve of the suggested change.
• Our Tamil vetter agrees with the suggested change.

... so I am going to merge this PR.