Sentence construction for translations

[rickj]

https://github.com/w3c/publ-a11y/blob/main/a11y-meta-display-guide/2.0/draft/localizations/en-US/display_guide_vocabulary_w3c_en-US.json provides clear sentences for the different conditions for translation, except for the "detailed-Conformance" section.

It appears this is constructed to break out different variables that can be assembled to create a sentence that reflects the claim, however, this is only true for English. It is impossible to construct an accurate set of logic to construct translations of the various parts that would make sense when assembled together in a similar way for every language.

I would like to recommend that instead we construct all possible sentences, so translations can be possible, and logic to select the right one remains predictable.

[GeorgeKerscher]

I can see how the suggested approach would make it possible to do the translations.

It looks like this change would need to be made quickly to get into the canonicle JSON file.

[GeorgeKerscher]

In determing the number of strings we will need if we eliminate the concatanated array , I have calculated it as:
the formulae is n(n+1)/2 +1 and then one more for not known)

So the numberof variables are listed below for the sections:

Navigation: 4= 11 strings plus not known
hazards 3=7 strings plus not known and not present
Additional information 5 = 16 strings + not present.
Clarity 7=29 strings + not known.

Any thoughts on how to approach this?

[jonaslil]

At Celia, we are concerned about the difficulties of localization for phrases or sentences generated through concatenation. For example, the compact explanation logic for navigation (Example 12) would not work in Finnish, where "Navigation by " would require separate strings for the start and end of the explanation. We could give many other examples.

This issue also affects the descriptive explanations. For Navigation, one concatenated string corresponds to four separate descriptive explanations, while for Hazards, a single compact explanation corresponds to one descriptive explanation, but with differing structures (noted in #390). In both cases, compact and descriptive explanations can't be displayed using the same logic.

Proposed solutions:

• Navigation: Replace the compact explanation with four short explanations, one for each navigation aid. This eliminates concatenation, resolves localization issues, and aligns compact and descriptive explanations for consistent display logic.
• Hazards: Split both compact and descriptive explanations into three short ones, one for each hazard. This resolves localization and display logic issues.

Additional accessibility information (Adaptation and Clarity subsections): Concatenation is also used here, but only for listing phrases or sentences separated by commas and "and." While this may not cause localization issues in familiar languages, clarity suffers. For example, the logic could produce results like "Aria and text-to-speech hinting provided" or "High contrast between foreground and background audio and page breaks," which combine unrelated concepts into a single phrase and may even be misleading.

To improve readability and localization:

• Treat each phrase or sentence as a separate explanation instead of concatenating them into one string.
• Adjust strings for standalone use, such as capitalizing the first letter.

Conformance section: The Conformance section clearly creates localization issues, but we do not yet have a proposal to address them.

[jonaslil]

I'm adding some thoughts on the Conformance section.

I don't see an issue with concatenating strings like " EPUB Accessibility 1.1 ", " WCAG 2.1 ", " Level AA".

The problem arises because the instructions try to present all information as full sentences, which doesn't seem necessary.

Steps 19-23 (ONIX) and 18-22 (EPUB) are especially problematic. These steps construct a sententence by concatenating small pieces: "The publication was certified " + " on " + certification_date + " by " + certifier + " with a credential of " + certifier_credentials. (The instructions don't explicitly say that these should be concatenated; the reader must infer it.)

Instead, we could present the information as a list or group of separate, simple explanations:

• Certified by: [certifier]
• Credential: [certifier_credentials]
• Certification date: [certification_date]

This avoids concatenation of strings that need localization.

Another way to handle localization of sentences or phrases with differing structures in different languages would be to use placeholder variables within the phrases that are localized. But explaining how this would work is beyond my competence.

Side note:
The intended display outcome of this last step is not quite clear to me:
"For more information refer to the certifier's report" with certifier_report as a link.