Localization of WCAG and EPUB versions

[mickael-menu]

The EPUB and WCAG versions and level are currently localized individually in the JSON files:

{
        "conformance-details-epub-accessibility-1-0": {
            "compact": " EPUB Accessibility 1.0",
            "descriptive": " EPUB Accessibility 1.0"
        },
        "conformance-details-epub-accessibility-1-1": {
            "compact": " EPUB Accessibility 1.1",
            "descriptive": " EPUB Accessibility 1.1"
        },
        "conformance-details-level-a": {
            "compact": " Level A",
            "descriptive": " Level A"
        },
        "conformance-details-level-aa": {
            "compact": " Level AA",
            "descriptive": " Level AA"
        },
        "conformance-details-level-aaa": {
            "compact": " Level AAA",
            "descriptive": " Level AAA"
        },
        "conformance-details-wcag-2-0": {
            "compact": " WCAG 2.0",
            "descriptive": " Web Content Accessibility Guidelines (WCAG) 2.0"
        },
        "conformance-details-wcag-2-1": {
            "compact": " WCAG 2.1",
            "descriptive": " Web Content Accessibility Guidelines (WCAG) 2.1"
        },
        "conformance-details-wcag-2-2": {
            "compact": " WCAG 2.2",
            "descriptive": " Web Content Accessibility Guidelines (WCAG) 2.2"
        }
}

Does localizing "EPUB Accessibility" and "WCAG" even make sense? Do we expect a different translation in other languages even though these are English acronyms and "trademarks"?

My second suggestion is related to the maintenance. I suggest removing the version and level numbers/letters from the strings, and let the implementers interpolate it themselves. Having the versions hard-coded in the strings poses several issues:

• What should a reading system do if it encounters a file with a more recent WCAG or EPUB version than what is supported by its embedded translation files?
• Every time a new EPUB Accessibility or WCAG version is released, all the translations will need to be updated, and then all the reading systems to be able to present the latest conformance profiles.

{
        "conformance-details-epub-accessibility": {
            "compact": " EPUB Accessibility {version}",
            "descriptive": " EPUB Accessibility {version}"
        },
        "conformance-details-level": {
            "compact": " Level {level}",
            "descriptive": " Level {level}"
        },
        "conformance-details-wcag": {
            "compact": " WCAG {version}",
            "descriptive": " Web Content Accessibility Guidelines (WCAG) {version}"
        }
}

[mattgarrish]

Does localizing "EPUB Accessibility" and "WCAG" even make sense?

The acronym WCAG doesn't change so the compact versions wouldn't localize, but official translations of the guidelines do localize the expansion "Web Content Accessibility Guidelines" so the descriptive statements would. See the page of authorized translations: https://www.w3.org/WAI/standards-guidelines/wcag/translations/

The same would go with "EPUB" not translating but "EPUB Accessibility" being localizable.

I suggest removing the version and level numbers/letters from the strings, and let the implementers interpolate it themselves.

I had proposed using placeholder variables for the EPUB metadata in an earlier iteration but it never made it in a published draft. Decomposing the conformance string only to rebuild it is unnecessary work, but in the end we abandoned it because it broke string compatibility between the techniques and it was too late to do a rewrite of the onix processing. It's also messy to do with only xpath 1.0. It might be worth reconsidering in the next version, though.

[mickael-menu]

The acronym WCAG doesn't change so the compact versions wouldn't localize, but official translations of the guidelines do localize the expansion "Web Content Accessibility Guidelines" so the descriptive statements would. See the page of authorized translations: https://www.w3.org/WAI/standards-guidelines/wcag/translations/

Thank you Matt, I was not aware of the official translations for the full name.

I had proposed using placeholder variables for the EPUB metadata in an earlier iteration but it never made it in a published draft. Decomposing the conformance string only to rebuild it is unnecessary work, but in the end we abandoned it because it broke string compatibility between the techniques and it was too late to do a rewrite of the onix processing. It's also messy to do with only xpath 1.0. It might be worth reconsidering in the next version, though.

I understand that this change might be too large at this point. While it might increase the maintenance burden on the Reading Systems and localization, it is not a critical issue. Feel free to close this issue if you think it's not relevant at the moment.

The lack of placeholder variables might be more critical though, as I shared in this other issue.