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
Comments
I would defer the |
It makes sense to have multiple strings in different languages. We also need to ensure that it is in sync with schema.org definition. |
Thanks @avneeshsingh, I was wondering about the same thing. B.t.w., 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:
and it worked without further ado. Ie, we may be o.k. |
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:
|
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. |
This issue was discussed in a meeting.
View the transcriptsingle localizable string #115Matt 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 |
I noticed for
accessibilitySummary
andLinkedResource/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.
The text was updated successfully, but these errors were encountered: