On Fri, 8 Jun 2018 00:43:04 +0200, Philippe Verdy via Unicode wrote: [cited mail] > > The "normative names" are in fact normative only as a forward reference > to the ISO/IEC repertoire becaus it insists that these names are essential > part > of the stable encoding policy which was then integrated in the Unicode > stability rules, > so that the normative reference remains stable as well). Beside this, Unicode > has other > more useful properties. People don't care at all about these names.
Effectively we have learned to live even with those that are uselessly misleading and had been pushed through against better proposals made on Unicode side, particularly the wrong left/right attributes. Unicode have worked hard to palliate these misnomers by introducing the bidi_bracket (yes, no) and bidi_bracket_type (open, close) properties, and specifying in TUS that beside a few exceptions, LEFT and RIGHT in names of paired punctuation is to be read as OPENING and CLOSING, respectively. > The character properties and the related algorithms that use them (and even > the representative glyph even if it's not stabilized) are much more important > (and the ISO/IEC 101646 does not do anything to solve the real encoding > issues, > and needed properties for correct processing). Unicode is more based on > commonly > used practices and allows experimetnation and progressive enhancing without > having > to break the agreed ISO/EIC normative properties. The position of Unicode is > more > pragmatic, and is much more open to lot of contibutors than the small ISO/IEC > subcomities > with in fact very few active members, but it's still an interesting > counter-power that allows > governments to choose where it is more useful to contribute and have > influence when > the industry may have different needs and practices not foàllowing the > government > recommendations adopted at ISO. Now it becomes clear to me that this opportunity of governmental action is exactly what could be useful when it’s up to fix the textual appearance of national user interfaces, and that is exactly why not federating communities around CLDR, and not attempting to get efforts converge, is so counter‐productive. Thanks for getting this point out. Best regards, Marcel
