TR 35-7

Sat Mar 17 04:11:05 CDT 2018

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