First-strong heuristics are ineffective when a default direction has been set for all strings, since metadata overrides (intentionally) the value of the first-strong character, therefore it is necessary to use explicitly provided field data to override the default. Even if an RLM character has been prepended to a string, the default metadata overrides it.
The use of metadata for indicating base direction is also preferred, because it avoids requiring the consumer to interpolate the direction using methods such as first strong or which require modification of the data itself (such as the insertion of RLM/LRM markers or bidirectional controls).
Schema languages, such as the RDF suite of specifications, have no in-built mechanism for associating base direction metadata with natural language string values.
-There is no built-in attribute for base direction in [[JSON-LD]]. There needs to be a corresponding built-in attribute (e.g. an
) or de facto convention for indicating document-level base direction.@dir
There is no built-in attribute for base direction in [[JSON-LD]]. There needs to be a corresponding built-in attribute (e.g. an
) or de facto convention for indicating document-level base direction.@direction
For the case where the resource-wide setting is not available, specify that consumers should use first-strong heuristics to identify the base direction of strings.
For the case where the resource-wide setting is available but not used, specify that consumers should fall back to first-strong heuristics to identify the base direction of strings.
If metadata is not available, consumers of strings should use heuristics, preferably based on the Unicode Standard's first-strong detection algorithm, to detect the base direction of a string.
@@ -384,46 +384,85 @@Not all resources make use of the available metadata mechanisms. The script subtag of a language tag (or the "likely" script subtag based on [[BCP47]] and [[LDML]]) can sometimes be used to provide a base direction when other data is not available. Note that using language information is a "last resort" and specifications SHOULD NOT use it as the primary way of indicating direction: make the effort to provide for metadata.
- -For [[WebIDL]]-defined data structures, define each natural language text field as a Localizable
.
This combines both language and direction metadata and, if consistently adopted, makes interchange between different formats easier. Consistency between different specifications and document formats allows for the easy interchange of string data. By naming field attributes in the same way and adopting the same semantics, different specifications can more easily extract values from or add values into resources from other data sources.
-Specifications MUST NOT require the production or use of paired bidi controls.
- -Another way to say this is: do not require implementations to modify data passing through them. Unicode bidi control characters might be found in a particular piece of string content, where the producer or data source has used them to make the text display properly. That is, they might already be part of the data. Implementations should not disturb any controls that they find—but they shouldn't be required to produce additional controls on their own.
+Producers sometimes need to supply multiple language values (see Localization Considerations) for the same content item or data record, often across multiple different syntaxes. This can occur during language negotiation by the consumer.
-Specifications SHOULD recommend the use of language indexing when Localizable strings can be supplied in multiple languages for the same value.
+[[JSON-LD]] language indexing should be modified to support the use of Localizable values in language indexing.
-Producers sometimes need to supply multiple language values (see Localization Considerations) for the same content item or data record. One use for this language negotiation by the consumer.
+ -[[JSON-LD]] language indexing should be modified to support the use of Localizable values in language indexing.
+The approach shown above is useful when expressing data using [[JSON-LD]], but often challenges developers that only want to utilize [[?JSON]] or CBOR [[?RFC7049]] while supporting language and base direction. While [[?JSON]] and CBOR [[?RFC7049]] have no formal mechanisms for expressing language and base direction, it is possible to utilize a small subset of [[JSON-LD]] that does not require the use of a [[JSON-LD]] library to achieve excellent cross-syntax language and base direction expression.
+In order to implement this design pattern in a specification, designers can:
+https://example.com/myapp/v1.@language to lang, @direction to dir, and @value to value. It is possible to do this globally, or locally fine tune it to a specific [[JSON-LD]] term using Scoped Contexts.@context property and include the [[JSON-LD]] Context from step #1. For example: "@context": "https://example.com/myapp/v1".@context property in a way that does not require the use of a [[JSON-LD]] library. See Section 5.3.1: Semantic Interoperability of the Verifiable Credentials specification for an example.Use of the design pattern above results in a common way to express language and base direction across [[JSON-LD]], [[JSON]], and CBOR [[?RFC7049]]] that developers find intuitive, palatable, and easy to deploy and consume.
For [[WebIDL]]-defined data structures, define each natural language text field as a Localizable
.
This combines both language and direction metadata and, if consistently adopted, makes interchange between different formats easier. Consistency between different specifications and document formats allows for the easy interchange of string data. By naming field attributes in the same way and adopting the same semantics, different specifications can more easily extract values from or add values into resources from other data sources.
+Specifications MUST NOT require the production or use of paired bidi controls.
+ +Another way to say this is: do not require implementations to modify data passing through them. Unicode bidi control characters might be found in a particular piece of string content, where the producer or data source has used them to make the text display properly. That is, they might already be part of the data. Implementations should not disturb any controls that they find—but they shouldn't be required to produce additional controls on their own.
+ +Specifications SHOULD recommend the use of language indexing when Localizable strings can be supplied in multiple languages for the same value.
+By 'metadata' we mean field-based information associated with a specific string or a set of strings in a data format, or information built into a string datatype (see also [[[#dir-approach-new-datatype]]]).
An example would be:
-{
- "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
- "language": "ar",
+"title": {
+ "value": "HTML و CSS: تصميم و إنشاء مواقع الويب",
+ "lang": "ar",
+ "dir": "rtl"
},
@@ -1255,7 +1295,7 @@