NNBSP

[Marcel Schneider via Unicode]

On 19/01/2019 01:21, Shawn Steele wrote:
>
> *>> *If they are obsolete apps, they don’t use CLDR / ICU, as these are designed for up-to-date and fully localized apps. So one hassle is off the table.
>
> Windows uses CLDR/ICU.  Obsolete apps run on Windows.  That statement is a little narrowminded.
>
> >> I didn’t look into these date interchanges but I suspect they won’t use any thousands separator at all to interchange data.
>
> Nope
>
> >> The group separator is only for display and print
>
> Yup, and people do the wrong thing so often that I even blogged about it. https://blogs.msdn.microsoft.com/shawnste/2005/04/05/culture-data-shouldnt-be-considered-stable-except-for-invariant/
>
Thanks for sharing. As it happens, I like most the first reason you provide:

  * “The most obvious reason is that there is a bug in the data and we had to make a change. (Believe it or not we make mistakes ;-))  In this case our users (and yours too) want culturally correct data, so we have to fix the bug even if it breaks existing applications.”


No comment :)

> >> Sorry you did skip this one:
>
> Oops, I did mean to respond to that one and accidentally skipped it.
>
No problem.
>
> >> What are all these expected to do while localized with scripts outside Windows code pages?
>
> (We call those “unicode-only” locales FWIW)
>
Noted.
>
> The users that are not supported by legacy apps can’t use those apps (obviously).  And folks are strongly encouraged to write apps (and protocols) that Use Unicode (I’ve blogged about that too).
>

Like here:
https://blogs.msdn.microsoft.com/shawnste/2009/06/01/writing-fields-of-data-to-an-encoded-file/

You’re showcasing that despite “The moral here is ‘Use Unicode’ ” some people are still not using it. The stuff gets even weirder as you state that code pages and Unicode are not 1:1, contradicting the Unicode design principle of roundtrip compatibility.

The point in not using Unicode, and likewise in not using verbose formats, is limited hardware resources. Often new implementations are built on top of old machines and programs, for example in the energy and shipping industies. This poses a security threat, ending up in power outages and logistic breakdowns. That is making our democracies vulnerable. Hence maintaining obsolete systems does not pay back. We’re all better off when recycling all the old hardware and investing in latest technologies, implementing Unicode by the way.

What you are advocating in this thread seems like a non-starter.

> However, the fact that an app may run very poorly in Cherokee or whatever doesn’t mean that there aren’t a bunch of French enterprises that depend on that app for their day-to-day business.
>
They’re ill-advised in doing so (see above).
>
> In order for the “unicode-only” locale users to use those apps, the app would need to be updated, or another app with the appropriate functionality would need to be selected.
>
To be “selected”, not developed and built. The job is already done. What are people waiting for?
>
> However, that still doesn’t impact the current French users that are “ok” with their current non-Unicode app.  Yes, I would encourage them to move to Unicode, however they tend to not want to invest in migration when they don’t see an urgent need.
>
They may not see it because they’re lacking appropriate training in cyber security. You seem to be backing that unresponsive behavior. I can’t see that you may be doing any good by doing so, and I’d strongly advise you to reach out to your customers, or check the issue with your managers. We’re in a time where companies are still making huge benefits, and it is unclear where all that money goes once paid out to shareholders. The money is there, you only need to market the security. That job would better use your time than tampering with legacy apps.
>
> Since Windows depends on CLDR and ICU data, updates to that data means that those customers can experience pain when trying to upgrade to newer versions of Windows.  We get those support calls, they don’t tend to pester CLDR.
>
Am I pestering CLDR…

Keeping CLDR in synch is just the right way to go.

Since we’re on it: Do you have any hints about why some powerful UTC members seem to hate NNBSP in French?
I’m mainly talking about French punctuation spacing here.
>
> Which is why I suggested an “opt-in” alt form that apps wanting “civilized” behavior could opt-into (at least for long enough that enough badly behaved apps would be updated to warrant moving that to the default.)
>

Asmus Freytag’s proposal seems better:

                “having information on "common fallbacks" would be useful. If formatting numbers, I may be free to pick the "best",
                but when parsing for numbers I may want to know what deviations from "best" practice I can expect.”


Because if you let your customers “opt in” instead of urging them to update, some will never opt in, given they’re not even ready to care about cyber security.
>
> The data for locales like French tends to have been very stable for decades.  Changes to data for major locales like that are more disruptive than to newer emerging markets where the data is undergoing more churn.
>

Happy for them. Ironically the old wealthy markets are digging the trap they’ll be caught in, instead of investing in cybersecurity.

Best wishes,

Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20190119/96ba393a/attachment.html>