Language and dir rewrite

[iherman]

This is the version is agreed on the Telco 2018-08-23.

Fix #220

---

Preview | Diff

[iherman]

@TzviyaSiegman could you also have a look at appendix C, please, to see if it is o.k.?

[llemeurfr]

In 4.4.5 I would rather define the language as the "natural language of the publication", and in the infoset requirement add that it also specifies the natural language of the textual values; not the reverse.

I would also explain in 4.4.5 that the base direction is the "base direction of the publication", and move the first note of 4.4.5.1 there (it's functional).

In 4.4.5.1 I would remove "(i.e., if the base direction is set) ".

In the definition of inLanguage and inDirection I would put the emphasis on its use at the level of the publication ("Default language for the Web Publication as well as for textual values").

In the note 4.4.5.2.1 the is a typo: it is RECOMMENDED to use set these properties
and IMO an error: the containing link element in case of embedding

Note that I'm still not convinced at all about the practical use of the base direction (for UI needs + as indication for text directionality). And as I said yesterday I don't support the difference of processing between embedded and detached manifests. But I'll move these rants elsewhere.

[iherman]

@llemeurfr thanks. I have made those changes; can you check and, if you are o.k. with merging, give your thumbs up?

(I have made the issue on inheritance explicit in the text)

[llemeurfr]

In the note in 4.4.5.1, I would argue that there should be no notion of override in "it is possible to set, e.g., the language for that resource individually, which will override the global setting for the publication as a whole." and make it required or recommended. -> ""it is recommended to set the language and base direction for each resource individually."

Apart from that, thumbs up for me.

[mattgarrish]

I think we could just make the note about placement into a parenthetical. There are also some normative keywords in lower case. Do you want me to make some small adjustments to fix these?

[iherman]

@mattgarrish please do; I have some other stuff to worry about.

@llemeurfr is fine with the PR and unless @TzviyaSiegman has objections, I guess you should merge this (and the other two PR-s actually)

[TzviyaSiegman]

@iherman in App C, the third example "displayed as" - Hebrew is correct, but the english is displaying as RTL.

[TzviyaSiegman]

minor rendering issue in Appendix C (third example

[iherman]

@TzviyaSiegman do you think it is possible to merge the whole thing and you can then edit the example? It is less error prone than me doing it...

[TzviyaSiegman]

@iherman I can try!

[r12a]

Do you want me to look at the Hebrew example ?

[iherman]

@r12a yes please, if you can also have a look!

[iherman]

@TzviyaSiegman it seems that @mattgarrish wants to do a small editorial change; I would leave to him to merge this PR

[r12a]

is it the lines from 3100 onwards?

[iherman]

@r12a Appendix C

[iherman]

@r12a https://pr-preview.s3.amazonaws.com/w3c/wpub/pull/275.html#bidi-examples

[r12a]

@iherman what should the column "Displayed as" show? Is it what you would expect to see if some link in the chain correctly interpreted the presence of the RLM/LRM as meaning "put something around this string in the target location to make it have the correct base direction"?

[iherman]

@r12a Well... I originally expected the "value" to show the string the way it is stored in a program. But then I realized that even a usual screen editor (I use SublimeText) probably shows the hebrew characters in the display mode when in HTML and not as it is stored inside.... I am not sure how to achieve that. The right hand column is the way one would expect to see it.

[r12a]

Welcome to the crazy world of bidi examples ;-). It's quite hard to make it do what you want. I'm in the process of rewriting that whole table for you. First column will show the characters in memory in order of storage. Last column will show expected outcome, if there's an interpreter in place to build the context around the string in the target location that sets the right base direction.

[iherman]

Wow. @r12a, I will owe you a beer or equivalent in Tokyo!

[r12a]

Bidi code sent by email, btw.

[mattgarrish]

I've done some minor cleanup on this: removing normative keywords where we aren't really say anything normative, and also from notes, which by definition are informative.

One thing I found concerning (and I see this elsewhere in the spec), is that there are times where we indicate to see another specification, without being specific what we're referring people to (e.g., "(see [html])"). It would be good to root these out and be more specific about what section we're referring to so that readers don't have to hunt down the information for themselves.

[iherman]

@mattgarrish, on #275 (comment): actually, the links to the handling of lang and dir were linked from the document itself, but it was not really clear. I did make some minor editorial change to make it clearer. That being said, a review of the document as whole for this would be indeed useful.

[mattgarrish]

Thanks, that was my issue: does the reference simply refer to previous links or does it mean there is something else the user has to look up. Clearer now.