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
