TR 35-7

Sat Mar 17 06:10:47 CDT 2018

Marcel,

I'm sorry that the process of providing feedback has been so onerous. We
have only a few people working on this project, and they are also fully
booked with other projects. So the first priority has been to get the
content in, recognizing that there is a lot to work on in formatting.
(Aside from other issues, the keyboard part of the CLDR spec doesn't really
follow the format of the rest of the document either.).

For this release, we focused on content that reflected features that
corresponded to what was in some major platforms, but that does not close
off extensions in the future. In addition, a primary goal for the content
is stability: keeping everything that was valid in v32 still valid in v33.
So renaming elements, attributes, attribute values, etc. for clarity was
not on the table.

So I'm sure that we have not been able to give your feedback the attention
that it deserves, or recognize the effort that has gone into it.

I agree that it is probably better to split off one or more separate
tickets. If the tickets are either too many or too long, they are difficult
to handle, so we need some balance between them. We like tickets that are
all on one topic, and whose resolution can all be done as a part of one
task.

We release every 6 months, if we don't get everything in any particular
release, there are always future releases. Because we are so close to the
deadline for this release, I'd suggest — just for now — splitting off one
or maybe two tickets that are:

   1. formatting not content
   2. high priority: where the formatting strongly interferes with the
   reader's ability to understand the content
   3. require a relatively small amount of work to the spec

I will carve out some time on my Monday (Zürich time) to review those in
detail, and we can see what can be done.

Mark

On Sat, Mar 17, 2018 at 10:11 AM, Marcel Schneider via CLDR-Users <
cldr-users at unicode.org> wrote:

> On Fri Mar 16 18:00:04 CDT 2018, Steven R. Loomis wrote:
> >
> > El El vie, mar. 16, 2018 a las 3:13 p. m., Marcel Schneider <
> > charupdate at orange.fr> escribió:
> >
> > > On 16/03/18 17:16, Steven R. Loomis wrote:
> > > > I think the bug tracking tool is best for tracking issues. You are
> > > > already interacting with the editor there (I am not the editor).
> >
> >
> > I meant the owner of the ticket, not the editor of the document. What I
> > meant is that you have left feedback on
> > https://unicode.org/cldr/trac/ticket/10901#comment:20 - so I think
> > discussion of that feedback is best kept on that ticket.
>
> Given that there, the editorial feedback is buried under the more
> substantial
> concerns, the owner interacted so far as he replicated the comment he left
> on all other PRI #367 tickets:
> https://unicode.org/cldr/trac/ticket/10901#comment:17
> |
> | There was a lot of feedback on this PRI. The keyboard group has made
> | some modifications based on feedback, but decided to leave other features
> | for consideration for a future version.
>
> That is not much of an interaction.
>
> It didn’t help, neither, that when I tried to attach revised HTML source
> code,
> the tool rejected it because it contained more than 4 external links. Then
> I’ve disabled all external links, but ended up simply making it available
> on the internet, rather than messing around with the file.
>
> However, inferring from Mark’s comment and the actual state of TR #35-7,
> the keyboard group decided not to consider fixing all the small issues
> that are parseable in:
> http://charupdate.info/unicode/revision/tr35/33-50/tr35-keyboards.html
>
> >
> > >
> > > Then I’d suggest that you request your name to be replaced with the
> > > real editor’s name(s).
> > >
> > > In turn I apologize for invoking your responsibility.
> >
> >
> > No need for any replacement or apology.
>
> That raises a question about how much liberty you actually have in editing
> TR #35-7, and about whether your tasks at IBM (your employer) leave any
> time to actually care for the documents that you are committed to put
> your name on, given that, again:
> http://unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#Acknowledgments
> does not acknowledge you for anything related to keyboards, but only
> “for development of the survey tool and database management.”
>
> >
> > >
> > >
> > > That now brings the need to file a whole bunch of tickets on a
> per‐issue
> > > basis. I think it’s unresponsive to get other people wast so much time,
> > > for things that would have been fixed long ago if only the initial
> writers
> > > had been a bit careful.
> >
> >
> > I don’t see how there is a need to file more tickets, if your comments
> are
> > already captured. What am I missing?
>
> You might not, but I am. (See below.)
>
> Actually, CLDR would be better served by a bunch of 20 or 40 specific
> tickets,
> rather than half a dozen composite ones that people might be
> unable/unwilling
> to parse and process exhaustively.
>
> >
> > > The actual system of change logging doesn’t facilitate corrections, as
> > > you’re likely to put “added plus signs in part of the modifier combos”
> > > and “permutated suffix Ls and Rs to prefix Ls and Rs” and the like in
> > > the change log.
> > >
> > > No need to record “added cell padding” and “added sample code
> formatting”
> > > however.
> >
> >
> > Which changes are you referring to?
>
> In
> http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-
> keyboards.html#Element_keyMap
> modifier combinations are concatenated using the plus sign, in other parts
> without '+'; while on the other hand, 'L' and 'R' are used as prefixes in
> http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-
> keyboards.html#Invariants
> but as suffixes in other parts as explicitly specified, while I argue that
> they should be prefixes throughout, for consistency with English language,
> with OS usage (Windows: LSHIFT, RMENU, LCONTROL and so on; macOS:
> rightShift,
> rightOption, rightControl), and with political neutrality (“Alt Right” is
> a political organization). I’ve even filed this in a ticket:
>
> https://unicode.org/cldr/trac/ticket/10906
> | The modifier labels should be titlecased, and the left/right should be
> | a prefix, not a suffix. The right Alt (AltGr) key can be labeled RAlt,
> | but it CANNOT (seriously) be labeled “altR”!
>
> However, I filed it as part of “/charts/keyboards/layouts/: Editorial
> feedback”
> that started with:
> | The tables representing the keyboard layout charts should have a table
> header row
> | containing the ISO column numbers. This will also make for an equal cell
> width.
>
> Mark accepted it (
> https://unicode.org/cldr/trac/ticket/10906#comment:4
> ), after I’d yet added a comment about quite another design suggestion:
> https://unicode.org/cldr/trac/ticket/10906#comment:1
>
> This is a flagrant example of how useful it is to restrict every ticket to
> one single atomic issue. That’s what I was missing, believing that it was a
> good idea to post “consolidated” feedback, which I misunderstood as
> covering
> *composite* feedback as well.
>
> Now back to your question. The plus sign should be used throughout for
> modifier concatenations because:
> 1) The inconsistent suffix/prefix use of L and R is otherwise confusing;
> 2) The space stands for AND on macOS, so that LDML which uses it for OR,
> should use plus for AND, rather than nothing.
>
> Hence I’ve added all missing plus signs and highlighted them correctly as
> changes, so that they are unoverseeable in
> http://charupdate.info/unicode/revision/tr35/33-50/tr35-keyboards.html
>
> Did yourself and/or other people of the keyboard group actually pay
> attention
> or at least take a glance?
>
> Further I’ve added cellpadding and removed the nested p elements in td, in
> an attempt to apply some layout conventions that are in current use in our
> civilisation.
>
> The last point noted above is consistent formatting of all XML blocks.
>
> >
> > > Why not a default 4px cellpadding to all table th/td elements?
> > >
> > > Just wondering while I was on it.
> > >
> >
> > It might be a good suggestion, but that would be a separate ticket.
>
> So that’s one more :)
>
> However, by now, since HTML cellpadding is overridden by CSS, I’d
> suggest adding “padding-left: 10px;” to the “th, td” rules. But the core
> part of TR #35 uses a 4px cellpadding specified in a HTML attribute —
> the same that you left at "0" until v32 before removing it for v33…
> Anyway, leaving tables without left cellpadding, while using nested p
> elements in td to get top and bottom padding — I can’t tell you…
>
> Best 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/20180317/d4617dc1/attachment-0001.html>