search

w3c / dxwg

Data Catalog Vocabulary (DCAT)
https://w3c.github.io/dxwg/dcat/
Other
139 stars 55 forks source link

Short i18n review checklist #1504

Closed riccardoAlbertoni closed 1 year ago

riccardoAlbertoni commented 2 years ago

Look at Short i18n review checklist for more context on the questions.

    1. [ ] If the spec (or its implementation) contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc),

None of the specific features added in DCAT 3 introduces variations on how the text is managed. This aspect hasn’t changed since DCAT 2.

DCAT encodes text using language-tagged string as defined by RDF and JSON-LD, coherently with BCP 47. Language codes are associated with text and are shown in the examples of the DCAT 3 specification.

For declaring language at the resource level, DCAT 2 uses dcterms:language - See issue https://github.com/w3c/dxwg/issues/959

The specification of text direction depends on the syntax in which DCAT is serialized. DCAT is likely to inherit the solutions that will be made available by RDF. See a discussion of alternatives https://w3c.github.io/rdf-dir-literal and issue https://github.com/w3c/dxwg/issues/958. Text direction for JSON-LD is discussed in https://www.w3.org/TR/json-ld11-api/#dom-jsonldoptions-rdfdirection

    1. [ ] If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics.

N/A

    1. [ ] If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc.

N/A

    1. [ ] If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers

N/A - DCAT inherits solutions from serializations and models defined in other specifications.

    1. [ ] If the spec (or its implementation) sorts text

N/A

    1. [ ] If the spec (or its implementation) captures user input

N/A

    1. [ ] _If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries

None of the specific features added in DCAT 3 introduces a variation on how the time /date-related terms are managed.

Moreover, legacy terms from DCAT 2 ( e.g., dcat:startDate) encode as rdfs:Literal using the relevant ISO 8601 Date and Time.

    1. [ ] If the spec (or its implementation) allows any character encoding other than UTF-8.

N/A - DCAT inherits solutions from serializations and models defined in other specifications.

    1. [ ] If the spec (or its implementation) defines markup.

N/A - DCAT inherits solutions from serializations and models defined in other specifications.

    1. [ ] If the spec (or its implementation) deals with names, addresses, time & date formats, etc

N/A - DCAT inherits solutions from serializations and models defined in other specifications.

    1. [ ] If the spec (or its implementation) describes a format or data that is likely to need localization.

N/A - DCAT inherits solutions from serializations and models defined in other specifications.

    1. [ ] If the spec (or its implementation) makes any reference to or relies on any cultural norms

N/A

riccardoAlbertoni commented 1 year ago

This Github issue was to make available the review checklist for I18n review. As the i18n group concluded the review, I don't see a reason to keep this issue open.