Liste des Groupes | Revenir à co vms |
On 8/24/2024 10:12 PM, Stephen Hoffman wrote:+1On 2024-08-23 23:34:18 +0000, Arne Vajhøj said:>On 8/23/2024 11:32 AM, Stephen Hoffman wrote:>OpenVMS has ~no concept of languages, either. Yeah, the C abd C++ I18N>
giblets, Java and its own little world, maybe using the existing and older
ICU or maybe you ported a newer ICU, and the deprecated Terminal Fallback
Facility (TFF) and National (Replacement) Character Set (NCS) giblets,
sure. All of which make things more interesting for apps that want or need
to deal with the UTF-8 and post-ASCII world.
Regarding UTF-8 support, then my take is that:
>
UTF-8 in file names, in usernames, in logicals, in identifiers and in
programs/scripts: not really needed.
UTF-8 filenames — poorly documented — already exists and was necessary for a
key app or two, though the rendering is ugly.
>
Working on a system that supports UTF-8 ~everywhere including within the shell
and within various languages and apps makes things easier.
>
Systems that don't provide that support mean more work. It's feasible, but
it's work. Or it gets ignored, or implemented elsewhere.
I fully get the need for UTF-8 support in anything data related.
For console/HTML/XML/JSON/YAML input/output then there is a functional
need for UTF-8 support.
>
But for all the implementation then I believe in keeping things
English and ASCII.
>
Filenames, database tablenames and fieldnames, program/script
identifiers, VMS logicals etc.. Even comments should be
in English (even though they may to use a little UTF-8 to
reference various things).
>
That is the safe choice for it being displayed correctly
everywhere and being understandable by all future maintenance
programmers.
>
Arne
>
Les messages affichés proviennent d'usenet.