Unnecessary direction attribute?

[iherman]

In Example 8 all text values with Arabic texts have the @direction value set. I do not think it is necessary (except maybe for the case where the value starts with "2015") because all the values are purely with Arabic characters, meaning that the right-to-left nature is in the UTF encoding. Just like it is not necessary to set the left-to-right value for the English or French texts.

cc @aphillips

[iherman]

#1446 has been raised; this issue may be closed if that PR is merged.

[aphillips]

I disagree. When the Arabic string is inserted in another context, it wants to be bidi isolated. Doing that means setting the base direction for the string. If there is no base direction stored in the record, the consumer has to figure out (by inspecting the string or from the language tag) which string direction to use--or depend on auto, if that is an option in the target context. auto is an option in HTML, but many UI APIs (Windows, MacOS, Java, etc.) require a specific direction.

LTR is the default for most applications and most languages, so omitting the @direction from left-to-right en and fr texts isn't a serious disadvantage to those strings. But it's a good idea to always transmit RTL text with an RTL direction. It is the case that purely Arabic strings will work appropriately with auto, so I don't disagree with @iherman's observation. But most applications don't have humans evaluating each string for whether the direction is needed or not.

[iherman]

I see what you mean, @aphillips. To be honest, my observation comes from the fact that, by keeping what is there, we might be accused of a bias, i.e., by being unnecessarily discriminating for a particular language. In this day and age, this is not an impossible reaction.

(Note that a VC is not really meant for human inspection, it is mostly for machine processing. Ie, inspecting the string for unicode characteristics or a language tag is really an issue if that counts.)

[TallTed]

Omitting these direction attributes may be technically fine, but doing so removes the demonstration meant to be conveyed by these examples. I would be fine with a comment in the text that says something like, "These direction attributes are not technically required for these single-language strings; they are included here for clarity of demonstration, and to make copy+paste+edit deliver functional results."

[iherman]

Omitting these direction attributes may be technically fine, but doing so removes the demonstration meant to be conveyed by these examples. I would be fine with a comment in the text that says something like, "These direction attributes are not technically required for these single-language strings; they are included here for clarity of demonstration, and to make copy+paste+edit deliver functional results."

I like this proposal. Under the motto "no good deed goes unpunished", could you submit a separate PR, @TallTed ? We could then close #1446

[TallTed]

See #1448

[r12a]

IMO, the string fields don't need to be individually marked with
direction where two cases apply:

1. resource-wide metadata has been set (eg. at the top of the file) indicating the default direction for all strings AND that direction applies to the individual string's content (if not, eg. if the resource-wide direction is set to RTL but a particular string has an overall direction of LTR, then it needs to be labelled).
2. no resource-wide metadata is set AND the specification requires that a receiving application must apply strong-first analysis to a string AND the string doesn't start with the wrong type of strong character.

If the specification doesn't require the use of strong-first analysis by the receiving application, and there is no resource-wide default to fall back on, then each string would need to be individually labelled.

[r12a]

@TallTed i think your edit should say that the direction is not required for this particular case because... (presumably the application is expected to do first-strong analysis and get it right). It's not that these are just optional in all cases. Or better still, you could include some strings that are ambiguous (ie. don't resolve correctly via first-strong analysis) – the i18n WG may be able to provide you with examples.

Also, you moved a period to the left of some Arabic text. This is one of the problems with trying to create RTL examples. It now looks as if the RTL base direction has been applied to the text for that string in the example, although in fact it hasn't - which will become clear if someone tries to copy the Arabic text in that example to use someplace else (the period will end up in the wrong place if direction is applied to the string, either explicitly or by the surrounding context). There's no easy answer here (see https://www.w3.org/International/questions/qa-bidi-source.en.html).

Personally, i'd be inclined to leave the period where it was, and perhaps indicate that the Arabic examples show the in-memory order. (Fwiw, if you had a string containing <arabic-text><latin-text><arabic-text> this problem would be significantly increased, because directional runs would look out of order (making it difficult to read).

[TallTed]

@r12a —

If the specification doesn't require the use of strong-first analysis by the receiving application, and there is no resource-wide default to fall back on, then each string would need to be individually labelled.

So far as I know, our specs don't require the use of strong-first analysis by the receiving application. Also, there is no resource-wide default to fall back on. So, as you say, and as I've done, each string needs to be individually labelled.

Although, the advice we've received from @aphillips is that any string that is entirely composed of characters that include their own directionality, and which are all the same direction, does not require the individual labelling ... hence the text I inserted.

Note also that we've also received advice about "string[s] containing <arabic-text><latin-text><arabic-text>" or other mixes of ltr and rtl characters in other areas of this current work.

It's incredibly frustrating and time consuming for us non-I18N experts to be receiving, and using trial-and-error to apply, contrasting advice from different people in the I18N group(s). It seems that maybe the I18N people who are now scrutinizing the work of the VCWG should get together, get on the same page about the advice to be issued to us, and issue it as explicit change requests/suggestions, so we're not re-re-re-composing our text based on periodically differing advisories.

The net effect of this and related threads on me, is that I want to remove any hint of the rtl text — which we added at I18N prompting! — from our documents, because I can see no relatively easy, relatively simple way to incorporate it, and have it do the right thing. Even the article you cited tells me, "Go read a bunch more, and try a bunch of tools, and see what you can (eventually) achieve (or not)!"

[msporny]

PR #1448 has been raised to address this issue. This issue will be closed once PR #1448 has been merged.

[msporny]

PR #1448 has been merged, closing.

[iherman]

The issue was discussed in a meeting on 2024-03-06

• no resolutions were taken

View the transcript

2.9. Unnecessary direction attribute? (issue vc-data-model#1424)

See github issue vc-data-model#1424.

Brent Zundel: 1424 unnecessary direction attribute.

Ivan Herman: there's a PR for that one.
… and it's been merged. So lets close it.