Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

single localizable string? #115

Closed
mattgarrish opened this issue Oct 15, 2019 · 6 comments
Closed

single localizable string? #115

mattgarrish opened this issue Oct 15, 2019 · 6 comments

Comments

@mattgarrish
Copy link
Member

I noticed for accessibilitySummary and LinkedResource/description that the expected value category is "LocalizableString" and not "Array of LocalizableStrings".

I have to believe this is a mistake, as why couldn't you provide these in more than one language?

I can't envision a case of a property with a localizable string that wouldn't take an array of them.

@iherman
Copy link
Member

iherman commented Oct 16, 2019

I would defer the accessibilitySummary to @avneeshsingh and/or @clapierre. I agree on the description piece.

@avneeshsingh
Copy link

It makes sense to have multiple strings in different languages. We also need to ensure that it is in sync with schema.org definition.
When we worked with schema.org people in 2016, AccessModeSufficient was the only accessibility metadata that was identified for array representation.
So, just a caution, we are near CR, so the changes that we make should be in sync with schema.org.

@iherman
Copy link
Member

iherman commented Oct 16, 2019

Thanks @avneeshsingh, I was wondering about the same thing. B.t.w., description is also defined similarly.

However... I believe all properties can use several text values out of the box with schema.org, as long as the order is irrelevant. The json-ld context file for schema.org does not preclude that, and the google structure date testing tool does not complain either. I tried the following test:

<script type='application/ld+json'>
{
"@context":"http://schema.org",
"type":"CreativeWork",
"name": "somebody",
"description": ["one","two"],
"accessibilitySummary": ["this", "and that"]
}
</script>

and it worked without further ado. Ie, we may be o.k.

@mattgarrish
Copy link
Member Author

Right, this appears to be a case of our being more limiting than schema.org.

We've just thought of the summary in terms of a single language because most publications are not multilingual, but even in epub there's nothing to prevent you from adding it multiple times to the package document for different languages:

<meta property="schema:accessibilitySummary" xml:lang="en">...</meta>
<meta property="schema:accessibilitySummary" xml:lang="fr">...</meta>

@mattgarrish
Copy link
Member Author

The summary is the only field this applies to out of the accessibility metadata, just to be clear. The rest all expect predefined tokens (literals).

AccessModeSufficient is another unique case in that each individual entry is a list, but that's a different case than being able to represent strings in multiple languages.

@iherman
Copy link
Member

iherman commented Oct 21, 2019

This issue was discussed in a meeting.

  • RESOLVED: the accessibilitySummary and description properties accept arrays of strings
View the transcript single localizable string #115
Matt Garrish: #115
Matt Garrish: moving on to real topics of the day … first issue re publication manifest, issue 115, localizable strings… some minor issues have come up… just want to make sure the solutions make sense to the group
… a question of two properties… removing requirement for single values, allowing multiple languages in an array
Deborah Kaplan: the solution to make it an array makes perfect sense
Matt Garrish: the use of localizable strings works with schema.org, provides for multiple languages
Ivan Herman: correct, these have several values out of the box in schema.org… we don’t have to do anything
Matt Garrish: it’s not something that in EPUB we’ve gone into doing (multiple language a11y summaries, for example)
… we’re not breaking anything or deviating
… seems like we can resolve this
Proposed resolution: the accessibilitySummary and description properties accept arrays of strings (Ivan Herman)
Deborah Kaplan: +1
Ivan Herman: +1
Geoff Jukes: +1
Matt Garrish: +1
Mateus Teixeira: +1
George Kerscher: +1
Marisa DeMeglio: +1
Avneesh Singh: +1
Dave Cramer: +.9
Ben Schroeter: +1
Ric Wright: +1
Dave Cramer: i wonder about implicitly endorsing a design choice that every given language of a work should be in the same publication
Matt Garrish: but i don’t think we should exclude this from the possibilities
David Stroup: +1
Matt Garrish: if you need it, it’s there
Dave Cramer: yep, that’s fine
Resolution #2: the accessibilitySummary and description properties accept arrays of strings

@iherman iherman closed this as completed Oct 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants