-
Notifications
You must be signed in to change notification settings - Fork 1
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
How should we handle long strings in the translation utility? #349
Comments
We looked at this together today. I think there is a larger discussion around validating the html tags that seem to be present in several of these. For now, I'd opt for a textarea for handling these. |
For #349. The original mission for this commit was to make the inputs for long English strings be text areas, but I think making them all text areas is a more elegant solution. I also aligned the copy value button and the text area using Flexbox since it looked even weirder with the old styling and the textareas.
In beb2136, I made all inputs textareas with a default height similar to that of an input. This seemed like a more elegant solution to me. I also aligned the copy value button and the text areas. I think it looks much nicer and feels much nicer from a UX perspective. |
For #349. The original mission for this commit was to make the inputs for long English strings be text areas, but I think making them all text areas is a more elegant solution. I also aligned the copy value button and the text area using Flexbox since it looked even weirder with the old styling and the textareas.
@oliver-phet, @jbphet and I noticed a long non-a11y-description string in pH Scale:
John and I were thinking that if we want to keep super long strings like this translatable, we should probably provide a textarea rather than an input. Thoughts?
EDIT: For context, the above screenshot was taken from ph-scale/sw (Swahili).
The text was updated successfully, but these errors were encountered: