- From: Addison Phillips via GitHub <sysbot+gh@w3.org>
- Date: Mon, 29 Jan 2024 14:44:23 +0000
- To: public-i18n-archive@w3.org
aphillips has just created a new issue for https://github.com/w3c/i18n-activity: == `credentialSubject.statusMessage` localizable == ## Proposed comment 2.2 BitstringStatusListCredential https://w3c.github.io/vc-bitstring-status-list/#bitstringstatuslistcredential > The statusMessage property MUST be an array. If present, the length of the array must equal the number of possible status > states indicated by statusSize. statusMessages MAY be present if statusSize is 1. statusMessages MUST be present if statusSize > is greater than 1. If not present, the message value associated with the bit value of 0 is "unset" and the bit value of 1 is "set". If > present, elements in the statusMessage array MUST contain at minimum two properties: > > - status, being a string of the hex value of the status > - message, being a string containing the associated message > > Implementers MAY add additional values to objects in the statusMessage array. Implementers MAY use the string value of > undefined in the value to indicate that a corresponding status is not defined for the associated status value, but that it may be > defined in the future. Rules for how to handle various status messages are outside the scope of normative requirements in this > document, but it is assumed that implementers will document rules for processing various status codes. The above later has an example like this: ```json "statusMessage": [ {"status":"0x0", "message":"valid"}, {"status":"0x1", "message":"invalid"}, {"status":"0x2", "message":"pending_review"}, ... ], ``` The example of a `statusMessage` suggests that the `message` string is a machine-readable non-language string. But the use of a `status` code (hex code number) suggests that the `message` is intended to make the string available for human consumption e.g. debugging. If the string is for human consumption, that actually suggests that language and direction metadata are needed and/or that localization should be possible. If the intention is to make the values only machine readable, there should probably be a prominent note explaining this intention. Or there should be some way to tag the strings or document with language so that expectations are clear. ## Instructions: This follows the process at https://w3c.github.io/i18n-activity/guidelines/review-instructions.html 1. Create the review comment you want to propose by replacing the prompts above these instructions, but **LEAVE ALL THE INSTRUCTIONS INTACT** 2. **Add one or more t:... labels. These should use ids from specdev establish a link to that doc.** 2. Set a label to identify the spec: this starts with s: followed by the spec's short name. If you are unable to do that, ask a W3C staff contact to help. 3. Ask the i18n WG to review your comment. 4. After discussion with the i18n WG, raise an issue in the repository of the WG that owns the spec. Use the text above these instructions as the starting point for that comment, but add any suggestions that arose from the i18n WG. In the other WG's repo, add an 'i18n-needs-resolution' label to the new issue. If you think any of the participants in layout requirements task force groups would be interested in following the discussion, add also the appropriate i18n-\*lreq label(s). 5. Delete the text below that says 'url_for_the_issue_raised', then add in its place the URL for the issue you raised in the other WG's repository. Do NOT remove the initial '§ '. Do NOT use \[...](...) notation – you need to delete the placeholder, then paste the URL. 6. Remove the 'pending' label, and add a 'needs-resolution' tag to this tracker issue. 7. If you added an \*lreq label, add the label 'spec-type-issue', add the corresponding language label, and a label to indicate the relevant typographic feature(s), eg. 'i:line_breaking'. The latter represent categories related to the Language Enablement Index, and all start with i:. 8. Edit this issue to **REMOVE ALL THE INSTRUCTIONS & THE PROPOSED COMMENT**, ie. the line below that is '---' and all the text before it to the very start of the issue. --- **This is a tracker issue.** Only discuss things here if they are i18n WG internal meta-discussions about the issue. **Contribute to the actual discussion at the following link:** § url_for_the_issue_raised Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/1821 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 29 January 2024 14:44:26 UTC