-
Notifications
You must be signed in to change notification settings - Fork 0
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
Update A11yStrings conventions and practices to make it easier to convert to i18n later #65
Comments
@jessegreenberg messaged me on slack with this question:
I say: You are close. Your declaration line aligns with what I was thinking. I do not recommend changing to var OhmsLawA11yStrings = {
resistanceUnitsPatternString: {
value: '{{value}} Ohms'
},
voltageUnitsPatternString: {
value: '{{value}} Volts'
},
resistanceSliderLabelString: {
value: 'R, Resistance'
}, |
Thanks @zepumph, this sounds good. +1 for leaving as .js files. I agree that this will reduce our work load later on. Removing my assignment, but if you would like to split up the work please reassign to me. |
I'm going to convert scenery-phet strings now because I broke xss fuzzing yesterday when I added a few new object keys into that file. |
Another things we can do to help ourselves is name keys in the string files without the "String" suffix, but include those suffixes in the variable names in the js files. This is enforced with the string! plugin by eslint. Tagging @jessegreenberg so he is aware. |
Roger roger. |
@zepumph did a search and found that these are the repos that need to be updated.
EDIT: We decided to create separate issues for this. |
We have created new issues in each repo for this. Closing this issue. |
Reopening to make sure that all a11y strings are loaded at the top of the files (like the string plugin). @zepumph volunteered to do this. |
The repos mentioned above (with separate issues) will cover those sims, but I will look at:
in this issue because they all already have the right structure for their string files. |
Working through phetsims/gravity-force-lab-basics#63, and I just wanted to confirm that we're NOT going the json and |
Correct, we are just setting ourselves up to make that easiest in the future. Thanks for checking. |
We know that we will be offering a11y strings to translators at some point, we just don't know when. The more that we can do now to sync up our practices of a11y strings to the way we use normal strings, the easier that conversion will be. Right now a11y strings are not in the same format as their json counterpart:
a11y:
normal:
I think that there are a few things that we can do to make it easier on us later.
Make sure that all a11y strings for a file are declared as vars at the top of the page. This is already being done for the most part, but every now and then we find one inline. Since i18n strings will need to be required, a block at the top, with variable declaration, will bridge the transition quite well. Example of bad practice (we've all done it):
accessibleLabel: BASEA11yStrings.wallLabelString,
Convert from an object schema
{{key}}: {{string}}
to{{key}}: { "value": {{string}} }
. This one would require a fair bit of work, going through each a11y string so far, but we will need to do that eventually, so I say lets bite the bullet now. This will require visiting all the call sites and adding ".value" to the end of the variable declarations. Kinda sloppy, and I would like @jessegreenberg's opinion before proceeding.Then when it is time to do the transfer, all we will need to do is:
require
and thestring!
plugin (removing the ".value" from the end of the line.I'm happy to do this grunt work now, especially since it will save so much time later. I'll just wait for @jessegreenberg to comment/give the go ahead. Especially since it would involve touching sims that he is actively working on like BASE.
The text was updated successfully, but these errors were encountered: