You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An important decision for i18n is when/whether to reuse UI strings for description.
Different developers/designers have been taking different approaches:
In MSaB, the goals was to have 100% of description strings under MeanShareAndBalanceStrings.a11y, therefore duplicating strings that appear in the UI.
In Density/Buoyancy, the developers reused UI strings were possible. Strings were added under a11y only when they were unique to description.
The MOTHA team consensus was to use the same approach as Density/Buoyancy. But that was only after I has already implemented using the MSaB approach. And I have not changed anything because there is not PhET-wide consensus.
My feeling is that is appropriate to reuse UI strings for description when the contexts are the same. For example, if the an accessibleName is intended to match the label on a button, then use the same string Property for both.
The text was updated successfully, but these errors were encountered:
Related to phetsims/models-of-the-hydrogen-atom#67 and https://github.com/phetsims/scenery-phet/issues/876 ...
An important decision for i18n is when/whether to reuse UI strings for description.
Different developers/designers have been taking different approaches:
MeanShareAndBalanceStrings.a11y
, therefore duplicating strings that appear in the UI.a11y
only when they were unique to description.My feeling is that is appropriate to reuse UI strings for description when the contexts are the same. For example, if the an
accessibleName
is intended to match the label on a button, then use the same string Property for both.The text was updated successfully, but these errors were encountered: