German sharp S uppercase mapping

[Asmus Freytag]

On 12/1/2024 5:48 PM, Dominikus Dittes Scherkl via Unicode wrote:
> Am 30.11.24 um 18:16 schrieb Asmus Freytag via Unicode:
>> On 11/27/2024 12:15 PM, Dominikus Dittes Scherkl via Unicode wrote:
>> However, speaking of this as a "default" is confusing to readers who
>> think in terms of text processing or authoring environments where a
>> different set of requirements rule. Here, the proper "default" is the
>> best implementation of a culturally appropriate case transform.
>
> NO. I really mean "default" in a technical sense, not something someone
> tailors to local needs.
> The ẞ was introduced to have an invertible casing, just like
> compatibility codepoints were assigned to make preservation of old
> formating information available if a translation back to some obsolete
> charset is necessary.
>
> _This new letter was invented to allow for 1:1 roundtrip conversion._

The letter was not *invented*. It was discovered (= identified as 
occurring in actual writing) and encoded.

It was encoded to match a character with a unique shape and properties. 
One of them of *being* a capital letter and the other one of ß being its 
lowercase equivalent.

>
> toUpper() shall change "ß" to "ẞ" instead of "SS", just to allow
> toLower() producing back "ß" instead of a wrong spelling with "ss"
> (which at the moment can only be avoided using a german dictionary - a
> really heavy constraint to a small function like toLower - and for
> family names simply not possible at all - the information is lost).

Your problem is that you assume an implementation of toUpper that takes 
no argument. For purposes like text design, publication etc. you want an 
implementation that selects which locale should set the rules. (Or one, 
where that setting is done behind the scenes, which is logically 
equivalent). Without specifiying the locale, your beautiful toUpper() 
does not now that in Turkish, 'i' is not mapped to 'I' but to CAPITAL I 
WITH DOT.

Because your beautiful toUpper does not handle at least one language 
means that it should not need to handle any languages. Instead it should 
be stable.

What you are describing is a change to the toUpper() that is invoked 
with the german locale as parameter (or selected behind the scenes).

There's not the same requirement for that one to be stable, although 
sometimes transitions are implemented by creating a separate locale for 
"old" and "new" orthographies and the like.

When it comes to case conversion, purpose matters.

This doesn't detract from the need to have implementations that do the 
"right" thing (as currently defined) for a given language. And from the 
need to enable these by default for ordinary text manipulation.

But it's not the same thing as overriding an "identifier-safe" or 
"filesystem-safe" implementation, just because that's incorrectly viewed 
as a "default" that should be applicable to text manipulation.

A./

>
> This is a really bad situation, which should be fixed as soon as
> possible, not a matter of taste.
> And it should be fixed explicitly in automatic text processing - because
> this is were today errors are produced, that can now be avoided.
> In private letters it doesn't matter what form is used - the people
> write whatever they want anyway. But automatic processing shall not drop
> information that can not be brought back (expcept with re-introducing
> this knowledge back manually).
>
>> And what is "best"  can change over time.
> No. Fixing this round-trip bug is in the best interest of unicode and
> that won't change over time. Using "SS" in all uppercase text was always
> a bad workaround that became a source of spelling errors by automatic
> text processing and for which a fix was invented some ten years ago. So
> lets use it everywhere - at least now that it is officially allowed
> (since 2017) and even preferred (since this year).
>
>