publ-a11y icon indicating copy to clipboard operation
publ-a11y copied to clipboard

Localization questions

Open rickj opened this issue 1 year ago • 5 comments
trafficstars

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 https://github.com/w3c/publ-a11y/issues/190#issuecomment-1889274542 . 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?

rickj avatar Sep 04 '24 15:09 rickj

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.

gautierchomel avatar Sep 04 '24 16:09 gautierchomel

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:

  • understand if the English phrase resulting from #4 above is a compact one or a descriptive one (see issue https://github.com/w3c/publ-a11y/issues/381)
  • knowing the desired language to display the phrase for the user, look up the corresponding phrase in that language (how? do a text search? count down the same number of lines? what do I use to correlate the two together)
  • select the desired compact or descriptive phrase in the desired language to display

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

rickj avatar Sep 05 '24 03:09 rickj

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.

mattgarrish avatar Sep 05 '24 11:09 mattgarrish

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.

gautierchomel avatar Sep 05 '24 11:09 gautierchomel

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.

GeorgeKerscher avatar Sep 05 '24 13:09 GeorgeKerscher

@rickj please reopen if this is still an issue.

clapierre avatar Feb 27 '25 16:02 clapierre