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

Localization questions #395

Open
rickj opened this issue Sep 4, 2024 · 5 comments
Open

Localization questions #395

rickj opened this issue Sep 4, 2024 · 5 comments
Labels
a11y-display-guide Issue with the UX Guide principles or techniques

Comments

@rickj
Copy link
Collaborator

rickj commented Sep 4, 2024

Per the directions at https://github.com/w3c/publ-a11y/tree/main/UX-Guide-Metadata/draft/localizations, VitalSource requests a translator role for Gitlocalize.

In looking at the new source file (https://github.com/w3c/publ-a11y/blob/main/UX-Guide-Metadata/draft/localizations/en-US/display_guide_vocabulary_w3c_en-US.json) there are significant changes from the original proposal shared in #190 (comment) . These changes bring up several questions and concerns, primarily the removal of a structure that maps to the principles and techniques documents. The only way to find what you are looking for now is to do a text search. This adds complexity in deploying a localized interface.

An example from "Supports nonvisual reading":

  • In the principle and techniques documents there are a section 4.2 in each
  • In both technique documents there are three variables used: "all_necessary_content_textual", "non_textual_content_images", "textual_alternative_images"
  • In the current localization example there is no mapping to the section 4.2, but rather three different variables used: "nonvisual-reading-readable", "nonvisual-reading-may-not-fully", "nonvisual-reading-not-fully"

We were working under the assumption that, as in the original localization example, there would have been a secion 4.2 in the localization file, matching (assuming a renumbering to match the final docs) with the descriptive and compact sections in the principles and techniques documents. While that changed (for I assume good reasons), I would then expect that the localization file would use the same variables from the techniques documents... but it does not.

Is there a reason for unique variable names in the localization file, and not to have a shared vocabulary?

@gautierchomel
Copy link
Collaborator

Thank you @rickj . The almost final JSON file is still in PR #384

I should probably clarify the Read Me as contributors able to provide direct JSON don't need to use Gitlocalize.

@rickj
Copy link
Collaborator Author

rickj commented Sep 5, 2024

Perhaps this can simplify my question:

Considering an implementation of this:

  1. A title arrives with it's metadata
  2. I receive the metadata
  3. Using the techniques document I setup my variables
  4. Using the instructions for the specific metadata I process the variables and receive an English phrase

Before I can display this to the user, I now need to:

We can make this easier, can't we? Provide some mapping between the key accessibility categories in the principles, which map to the techniques, but do not map to the phrases, and do not provide a way to distinguish compact vs. descriptive

@mattgarrish
Copy link
Member

4. Using the instructions for the specific metadata I process the variables and receive an English phrase

An English phrase shouldn't always be the result of processing the algorithms, unless I've misunderstood how the algorithms work. You get the phrase in the language and form that you prefer using the IDs associated with each step. It's the same key no matter the language file. The English phrase is only shown as an example.

So step 4 is more like:

  • process the algorithm and determine the json key for the text to display
  • look up the key in the needed language file
  • select the compact or descriptive text as preferred

Assuming I have this right, I don't know that it is well explained in the techniques or principles. I was trying to find an explanation of this, but haven't been able to locate one. But maybe someone else can chime in.

@gautierchomel
Copy link
Collaborator

gautierchomel commented Sep 5, 2024

PR #384 aims at aligning ID's on the 4 documents, so once the variable is settled up it's easy to retrieve it in the different JSON with an additional postfix for -compact or -descriptive.

@GeorgeKerscher
Copy link
Collaborator

Can all of the IDs be checked programatically? When I check the strings in the spreadsheet with the Principles, do I need to check the IDs? I hope not to touch any IDs, but we need to make sure all are correct before doing translations.

@mattgarrish mattgarrish added the a11y-display-guide Issue with the UX Guide principles or techniques label Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y-display-guide Issue with the UX Guide principles or techniques
Projects
None yet
Development

No branches or pull requests

4 participants