Charts (rough cut)

Mark Davis ☕️ via CLDR-Users cldr-users at unicode.org
Wed Aug 22 01:36:59 CDT 2018


Thanks for your message.

Briefly,

I think it is a good idea to add the non-breaking variants of included
characters. That is something we can do automatically (there is a processor
that can modify display of data in the survey tool, and modify data that is
typed into the survey tool). Can you file a ticket for that?

We have to strike a balance here, because often the typographically more
desired form is not present in fonts. We typically delay, for example,
using new currency symbols until widespread fonts have caught up. We stay
away from extensive use of the super or subscript Latin characters. Those
are not uniformly supported in fonts, and tend to have a ransom-note
appearance. So for English we don't use 13ᵗʰ, for example, even though that
form would be in theory preferred to 13th. However, the Latin-1 characters
are well supported:
ª U+00AA FEMININE ORDINAL INDICATOR
º U+00BA MASCULINE ORDINAL INDICATOR

We don't include ' and " in the regular punctuation, because they are
rarely the preferred form for display. (There is a mechanism
called parseLenients that we could consider extended for cases where it
could be useful to indicate that various input forms might be
equivalent...).

As for more documentation, we'd welcome that. Some thoughts (not complete):

   - We need to think about the best forum for it. The LDML spec is
   heavy-weight and slow to modify, while the
   http://cldr.unicode.org/translation pages have a very fast turn-around.
   The connections between the Survey Tool info panel for a path (or set of
   paths) and a particular http://cldr.unicode.org/translation page do
   require rebuilding and deploying the tool, which is not as light-weight,
   but fairly straightforward.
   - Best is to pick out obvious fixes or enhancements to the documentation
   with suggested rewording or additions for clearly identified places.
   - Suggestions for policy changes or enhancements should be kept
   separate, so that they can be reviewed and discussed first before specific
   text is considered.

Mark


On Wed, Aug 22, 2018 at 1:30 AM Marcel Schneider via CLDR-Users <
cldr-users at unicode.org> wrote:

>
> Philippe,
>
> I’m sorry not to have joined in your proposal of pushing
> [!-#\&(-*,-/\:;?@\[\]§«»‐–—’“”†‡…] as a punctuation set,
> Clearly that made it difficult for TC to do anything for French here, the
> more as their attempt to make a compromise
> to be pushed through was not welcomed. In reality it was (better than
> nothing), just I didn’t acknowledge while responding.
>
> Now I’m suggesting to discuss that here so TC can see why there is a
> latent “dispute” (OK, I see there are many
> “disputed items”, given a huge part of corrections I proposed weren’t
> accepted by fellow vetters).
>
> There was a more complete punctuation set that was gaining traction:
> [!-#\&-*,-/\:;?@\[\]_§«»‐-―‘’“”†‡…‹›].
> In comparison with that set, you are excluding the following characters:
>
> ― U+0027 APOSTROPHE. This is not preferred, but neither is U+0022
> QUOTATION MARK that you keep
>     including. And you yourself are using the ASCII apostrophe when
> typing, due to its exclusive presence on
>     widespread keyboard layouts.
>
> ― U+005F LOW LINE. This is not more typically French than the NUMBER SIGN
> and the AT SIGN, both of
>     which you include. And you do have an underscore in your own e-mail
> address.
>
> ― U+2011 NON-BREAKING HYPHEN. See below.
>
> ― U+2012 FIGURE DASH
>
> ― U+2015 HORIZONTAL BAR
>
> [I’ve lost comments and references on U+2012 and U+2015 by inadvertently
> hitting the shortcut closing the browser.
> No doubt I was too detailed. Now I’ll post further information on request
> only.]
>
> ― U+2018 LEFT SINGLE QUOTATION MARK
>
> ― U+2039 SINGLE LEFT-POINTING ANGLE QUOTATION MARK
>
> ― U+203A SINGLE RIGHT-POINTING ANGLE QUOTATION MARK
>
>
> Can anybody tell us why U+2011 NON-BREAKING HYPHEN is not default in every
> Latin-script using locale?
>
> Obviously contributors and vetters are lacking guidance, because CLDR
> documentation is still a stub compared
> to what it could and should be.
>
> I don’t actually have time to rewrite more parts of it, not even knowing
> whether TC will use suggested updates,
> or not.
>
> In my belief, the engineering effort ought to be done basically by those
> who are in charge of maintaining the data.
> I’m ready to contribute if there is a demand that I may cater for.
>
>
> Regards,
>
> Marcel
>
> _______________________________________________
> CLDR-Users mailing list
> CLDR-Users at unicode.org
> http://unicode.org/mailman/listinfo/cldr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/cldr-users/attachments/20180822/97fcceed/attachment-0001.html>


More information about the CLDR-Users mailing list