Forced capitalisation caps with text-transform
Categories
(Firefox :: Theme, defect, P3)
Tracking
()
People
(Reporter: henry-x, Unassigned)
References
(Blocks 1 open bug)
Details
This was noticed in Tor Browser development.
I'm not sure if "General" was the best component, but this is meant to cover firefox desktop localisation
A few components force all-caps or title cases using text-transformation
.
Forcing capitalisation can have bad effects in some locales, like gaelic and greek. See https://mozilla-l10n.github.io/documentation/localization/dev_best_practices.html#css-issues.
In these cases where all caps is desirable, the en-US
string itself should be capitalised, but the localisers should determine the capitalisation of the translation.
I'm hoping this could be a meta-issue to remove the forced-capitalisation.
Reporter | ||
Comment 1•2 months ago
|
||
Related android issue: bug 1935387.
Comment 2•2 months ago
|
||
The severity field is not set for this bug.
:kpatenio, could you have a look please?
For more information, please visit BugBot documentation.
Updated•1 month ago
|
Comment 3•25 days ago
|
||
Not quite sure what our guidelines about capitalization is or should be. I know they was brought up every now and then, but then we still do it in some cases. If we want to be more strict about this, we should add a linting rule.
flod, do you have thoughts on this?
Updated•25 days ago
|
Comment 4•25 days ago
|
||
From a localization perspective, it would be ideal to have the text uppercase in the strings instead of transformed through CSS. That gives locales the liberty of using a different approach if they want.
The topic was brought up recently with the accessibility team, because I was concerned that using uppercase text directly would present an issue. Turns out that, from an accessibility perspective, they're identical (the text is uppercase).
Quoting from that conversation with jteh
Several speech synthesisers will read upper case text as abbreviations if the word seems like it might be an abbreviation (where "seems like" is an inaccurate heuristic that varies wildly between synthesisers). For example, with eSpeak, "EXAMPLE" is read as "example", "I WILL BAN YOU FOREVER" is read as "I will ban you forever", "I will BAN you forever" is read as "I will b a n you forever".
(…) text-transform: uppercase is handled identically to just using upper case character (…)
I'm not sure I have a strong opinion about enforcing this through linting. Is there a sense of how frequently we would need exceptions if we do it?
Comment 5•25 days ago
|
||
(In reply to Francesco Lodolo [:flod] from comment #4)
I'm not sure I have a strong opinion about enforcing this through linting. Is there a sense of how frequently we would need exceptions if we do it?
Not many. I see 14 examples in our .css files, and of those its not clear without digging a little deeper but even if most were unavoidable uses, I think the lint rule would still provide value for future changes - in making people stop and consider. Its an easy mistake to make and an easy one to miss as l10n review won't necessarily be triggered for a .css change.
Description
•