Text base direction again — but now with a solution:-) #75
Comments
iherman
added
enhancement
|
For the RDF inclined among you the question may be what RDF statements are generated for this feature. The JSON-LD WG Meeting minutes' section may provide the necessary answers for now (before the publication of the new ed draft). |
|
It would be nice to have a real-life example in the document. Have anybody such an example that I could use? Ie, a title that has possible directional issues and that should have an explicit base direction assigned. @BigBlueHat you referred to scientific articles in Hebrew or Arabic that mix their script with latin scientific terms... @r12a any idea? |
|
In our string-meta doc we use the following example, which i believe is a real book found by Addison. Strip the markup and you should have something useful. When displayed, this should look like this (read it right-to-left) (i couldn't figure out how to right-align it). Note that the 4 directional runs are in reversed order in the example vs expected display. To help with cut & paste and to see the sequence of characters, follow this link to UniView. Does that work? |
|
@r12a thanks! I have not yet started the PR, but that should work. Just to use it as a common example with multilingual title, what would be the title in English (or French)? Thanks! |
|
@aphillips may be able to locate an 'official' translation, but it's something along the lines of "HTML and CSS: Web design and creation". |
|
From the string-meta source: |
r12a
added
i18n-needs-resolution
|
This issue was discussed in a meeting.
View the transcriptDirectionalityWendy Reid: #75 Wendy Reid: first issue is about directionality Ivan Herman: See Pull request for directionality Ivan Herman: I have already reported that this whole direction issue now has a clear solution … I’ve made a PR … you can do direction much like you can do language … with the same syntax, either globally or for a given member … so the PR fixes all the bits … there is one issue which I put into the document … having direction in the system means that we have a dependency on JSON LD 1.1 … which is running in parallel with our spec; they plan CR at the same time, they have implementations. … so they may be ahead of us … but if you want to run a manifest through a JSON-LD processor that only supports 1.0 you will get errors … so I created a separate context file that doesn’t have direction … and made an appendix in the doc … so you can use this context if you don’t need direction, and need to use a JSON-LD 1.0 processor … so the question to the group is that it’s OK to keep this as an appendix in the document … or put it somewhere else, or not do it at all and depend on JSON-LD 1.1 … so I want help from the group in deciding what to do Wendy Reid: any questions? Brady Duga: I don’t have strong feelings, but it does feel strange to put in the spec itself … most things that process this won’t be JSON-LD processors … but I’m not against it … I think it should be in a read me or impl guide Matt Garrish: I’m concerned about how this might be interpreted … changing our context which is required seems weird … it could add confusion to have an alternate context Ivan Herman: I put it there without being convinced it’s a good idea … I’m fine removing it … so where would this information go? … we could give it to the testing people and have this added to information about testing Matt Garrish: I would put in our wiki for implementation details, so it’s discoverable Wendy Reid: a wiki is good Dave Cramer: This seems like it would be a helpful note in the spec itself, if this language property is used, mention that JSON-LD 1.1 is required … it’s a good use of non-normative text Ivan Herman: any other comments? … one comment… for those of you who have been looking at this … if you look at this example … it is a good example there for real cases where base direction is necessary … some people were wondering if this stuff was necessary … We found a book with a title in arabic and english Ivan Herman: so it’s good to have a real-world example Matt Garrish: I think it’s useful to have direction; we have it in EPUB. Ivan Herman: is there a consensus to merge? Matt Garrish: +1 Wendy Reid: +1 Brady Duga: +1 Dave Cramer: +1 Gregorio Pellegrino: +1 Ivan Herman: we should also pledge to never talk about direction again :) Resolution #2: ivan to merge direction PR |
The issue of base direction has been plagued us for a while (see also issue 354 on wpub), but we may have a proper solution for it now. There has been discussions elsewhere to look for a solution, a (failed) attempt to revive the discussion in RDF land and, finally, a breakout session at TPAC. This led the JSON-LD WG to re-open the issue of adding base direction to JSON-LD 1.1. On its F2F meeting at TPAC, the JSON-LD WG has accepted a series of resolutions, see the minutes of Thursday and Friday for the details.
The essence is: JSON-LD 1.1 will introduce a new keyword
@directionthat can be used, essentially, the same way as@language: can be part of the context to denote a global (ie, default) value, and can also be used as part of an individual literal. In our terminology, aLocalizableStringin our manifest can have a directional value, if needed, just the same way as we handle language tags.What I propose is to make changes on the manifest specification to adopt this feature. What it would mean for the manifest is:
directionterm disappears and is replaced by a@directionkeyword usage alongside@language(see 2.5.1)@directionLocalizableStringwill be updatedThe result, I believe, would be a much cleaner format for our manifest, and we can but this issue at rest at last.
There is one caveat, though. This is a JSON-LD 1.1 feature, i.e., we become dependent on JSON-LD 1.1. This, by itself, is not a problem, JSON-LD 1.1 is slightly ahead of use in its advance towards a Rec. However, we have to be careful to use this feature in a way that it does not upset JSON-LD 1.0 processors that are supposed to simply ignore an unknown keyword. Without going into details what this means that we should not create the
directionalias for@direction, as we do for, e.g.,@languageand@value. As a consequence, I would propose that we remove the usage of these aliases, and we use@langaugeand@value; otherwise it looks very inconsistent.As soon as the JSON-LD 1.1 editor's draft includes the new feature, I will put in a PR to adopt these changes in the manifest document. We can decide, through the PR, whether we agree with these changes.
(This should supersede, ie, close, issue #39, and also make the discussions in w3c/wpub#354 moot. Finally, it should close the gap in the i18n review in #38.)
Cc: @r12a @aphillips @mattgarrish @wareid @BigBlueHat @laudrain @llemeurfr @GarthConboy @rdeltour @dauwhe
The text was updated successfully, but these errors were encountered: