Steven R. Loomis wrote: >Marcel, > The idea is not necessarily without merit. However, CLDR does not usually > expand scope just because of a suggestion. I usually recommend creating a new project first - gathering data, looking at and talking to projects to ascertain the usefulness of common messages.. one of the barriers to adding new content for CLDR is not just the design, but collecting initial data. When emoji or sub-territory names were added, many languages were included before it was added to CLDR.
Well, maybe usually, but perhaps not this time? I opine that if it is going to be done it needs to be done under the umbrella of Unicode Inc. and have lots of people contribute a bit: that way businesses may well use it because being part of Unicode Inc. they will have provenance over there being no possibility of later claims for payment. Not that any such claim would necessarily be made, but they need to know that. Also having lots of people can help get the translations done as there are a number of people who are bilingual who might like to pitch in. So, give the idea a sound chance of being implemented please. 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. It can be implemented straightforwardly using the star space system that I have devised. http://www.users.globalnet.co.uk/~ngo/An_encoding_space_designed_for_application_in_encoding_localizable_sentences.pdf http://www.users.globalnet.co.uk/~ngo/localizable_sentences_the_novel_chapter_019.pdf Start off with space for 9999 error messages and number them from 4840001 through to 484999 and allocate meanings as needed. Then a side view of a 4-8-4 locomotive facing to the left could be a logo for the project. Big 4-8-4 locomotives were built years ago. If people could do that then surely people can implement this project successfully now if they want to do so. For example, one error message could be as follows: Data entry for the currency field must be either a whole positive number or a positive number to exactly two decimal places. Another could be as follows: Division by zero was attempted. Yet another could be as follows: The number of opening parentheses in the expression does not match the number of closing parentheses. If some day more than 9999 error messages are needed, these can be provided within star space as it is vast. http://www.users.globalnet.co.uk/~ngo/a_completed_publication_about_localizable_sentences_research.pdf William Overington Monday 11 June 2018
