English hardcoded string capitalization

milupo · November 8, 2024, 3:18pm

Hi,

there are a lot of new strings on Potoon for the Common Voice website now. I noticed that English capitalization is used now for every language on the website. Every language should use their own capitalization rules. Please change that.

Thanks.

bozden · November 9, 2024, 9:44am

This might be caused by using CSS text-transform:uppercase rule AND not setting the HTML language ID in the HTML tag. It is <html lang="en"> for everyone.

There can be three approaches:

Fix the html tag (permanent solution)
Do not use text-transform rules in CSS and write uppercase as uppercase in language strings (not very flexible)
Per language where there is a problem, re-edit the translations in Pontoon and make them uppercase in that language (worst scenario, but can be a temporary fix)

I already have a related issue posted in the not-yet-public Spontaneous Speech repo for that. What you encountered might be related to latest merges in the release.

On the other hand, I don’t see a problem here for Turkish, where we have problem with i->İ and ı->I conversions. Curious…

What is the language you are dealing with? Can you share a screenshot?

milupo · November 9, 2024, 2:23pm

Hi Bülent,

I am translator for Upper Sorbian (hsb) and Lower Sorbian (dsb) but the same issue is e.g. for German as well. I found for existing menu items the classes .contribute-menu, .menu, a.contribute-link which use text-transform: capitalize; Menu items which will come soon use the class .coming-soon-text that doesn’t have text-transform but it is under .menu which has text-transform.

Here is a screenshot for Upper Sorbian:

bozden · November 9, 2024, 4:53pm

Ah, this is why I don’t see any problem. We don’t have first letter ı/i there…

Actually it seems that capitalize has been introduced in 2023, but you hit the problem with latest translations.

milupo · November 9, 2024, 5:13pm

Well, not for a long time have I visited the Common Voice website because there were no new strings on Pontoon. But yesterday (or the day before?) many new strings came. Maybe this is why I did not notice this change.

bozden · November 9, 2024, 5:26pm

I referenced this post in the related issue here:

milupo · November 9, 2024, 5:33pm

Thank you for opening the bug report.

bozden · November 9, 2024, 5:43pm

It was already open, even there is another from 2018 opened by Turkish translation manager.

But the solution is not straightforward (e.g. document.documentElement.lang = newLang;). The codes in Pontoon/CV does not conform to ISO always, we need to implement a mapping and fallback.

milupo · November 10, 2024, 8:41pm

Doesn’t it suffice to remove the text-transform property or set its value to none?

bozden · November 11, 2024, 9:52am

Yes it does - and that way you get rid of part of the CSS definitions. In fact that mapping I’m taking about is not only for this purpose, but for greater good - moving “languages” into variants.

Also, html-lang attribute has other uses, e.g. it is important for SEO or accessibility (screen readers).

I always hated CSS manipulation of texts. If I want something to be shown in CAPITALS, I write it like that, I don’t want it decided by a template/web designer.

Actually, IANA/ISO/etc - thus CSS - does not cover all 7000+ languages, not all languages have lower/upper case, and CV is dealing with non-institutional languages.

IMHO, CV should not use text-transform at-all.

milupo · November 11, 2024, 10:03pm

Well, CSS is fine for individual customization. I help in a German Firefox forum and there are many users who customize by CSS. However, most of them do it for the Firefox GUI and less for web sites. And neutral CSS properties can be used but text-transform is not such a neutral CSS property.

Exactly what I thought!