On Mon, 11 Jun 2018 16:32:45 +0100 (BST), William_J_G Overington via Unicode wrote: […] > Asmus Freytag wrote: > > > If you tried to standardize all error messages even in one language you > > would never arrive at something that would be universally useful. > > Well that is a big "If". One cannot standardize all pictures as emoji, but > emoji still get encoded, some every year now. > > I first learned to program back in the 1960s using the Algol 60 language on > an Elliott 803 mainframe computer, five track paper tape, > teleprinters to prepare a program on white tape, results out on coloured > tape, colours changed when the rolls changed. If I remember > correctly, error messages, either at compile time or at run time came out as > messages of a line number and an error number for compile > time errors and a number for a run time error. One then looked up the number > in the manual or on the enlarged version of the numbers > and the corresponding error messages that was mounted on the wall. > > > While some simple applications may find that all their needs for > > communicating with their users are covered, most would wish they had > > some other messages available. > > Yes, but more messages could be added to the list much more often than emoji > are added to The Unicode Standard, maybe every month > or every fortnight or every week if needed. > > > To adopt your scheme, they would need to have a bifurcated approach, where > > some messages follow the standard, while others do not (cannot). > > Not necessarily. A developer would just need to send in a request to Unicode > Inc. to add the needed extra sentences to the list and get a code number. > > > It's pushing this kind of impractical scheme that gives standardizers a bad > > name. > > It is not an impractical scheme.
I don’t fully disagree with Asmus, as I suggested to make available localizable (and effectively localized) libraries of message components, rather than of entire messages. The challenge as I see it is to get them translated to all locales. For this I'm hoping that the advantage of improving user support upstream instead of spending more time on support fora would be obvious. By contrast I do disagree with the idea that industrial standards (as opposed to governmental procurement) are a safeguard against impractical schemes. Devising impractical specifications on industrial procurement hasn't even been a privilege of the French NB (referring to the examples in my e-mail: https://unicode.org/mail-arch/unicode-ml/y2018-m06/0082.html ), as demonstrated with the example of the hyphen conundrum where Unicode pushes the use of keyboard layouts featuring two distinct hyphens with same general category and same behavior, but different glyphs in some fonts whose designers didn’t think further than the original point of overly disambiguating hyphen semantics—while getting around similar traps with other punctuations. And in this thread I wanted to demonstrate that by focusing on the wrong priorities, i.e. legacy character names instead of the practicability of on-going encoding and the accurateness of specified decompositions—so that in some instances cedilla was used instead of comma below, Michael pointed out—, ISO/IEC JTC1 SC2/WG2 failed to do its part and missed its mission—and thus didn’t inspire a desire of extensive cooperation (and damaged the reputation of the whole ISO/IEC). Best regards, Marcel
