TR 35-7

[Marcel Schneider via CLDR-Users]

On Sat Mar 17 06:10:47 CDT 2018, Mark Davis ☕️ wrote:
> 
> I'm sorry that the process of providing feedback has been so onerous.

No worries. I’m ready to invest the needed time provided that it will be of 
some use at some point. Hence my related concerns are essentially about 
making that sure.

> We have only a few people working on this project, and they are also fully
> booked with other projects.

That’s what I ended up suspecting, and I must confess that I’m committed to 
several keyboarding projects where the evaluated needs are calling for new 
but still easily implementable solutions. Hence I’ve used this opportunity 
to join in trying to get CLDR support them, while there is still a lot of work
here, that I’m expected to complete these days.

> So the first priority has been to get the
> content in, recognizing that there is a lot to work on in formatting.

I think it’s a good idea to dispatch the changes over several versions if 
there is always only one intermediate revision (actually revision 50), so 
that the changes can be tracked by sets, actually the new features presented
in 
http://www.unicode.org/review/pri367/pri367-Unicode-LDML-Keyboard-Enhancements.pdf

> (Aside from other issues, the keyboard part of the CLDR spec doesn't really
> follow the format of the rest of the document either.).

Following the template is indeed a more appropriate approach. While editing 
a copy of the TR stylesheet, I didn’t much look up HTML usage, because I’m
desperately lacking so much time.

> 
> 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.

Stability is useful indeed, at least as long as it doesn’t compromise usability.
We need then to find out a way of accommodating the existing scheme, e.g. by 
adding the transform="yes" value. One way I suggested is to add an attribute 
in the settings so that one can use a new scheme while the existing one 
remains valid.

> 
> 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.

Hereby that’s done for now.

> 
> 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.

Got it, thanks.

> 
> 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 see several points that can be fixed in nearly no time but that do not 
heavily impact readability. The reader is still able to infer and mentally 
correct, My concern in this field is primarily about the question marks 
rising out of his or her head, as I’ll have to link to TR #35-7 (rather than
to translate it — which we’ve seen on Unicode Public is not a working solution
any longer) and add a disclaimer if things are not fixed by then.

> 
> 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.

I’d like for now that we’ll both save our time, looking forward to version 34.
Thanks however.

Best regards,

Marcel