RFC: Drop languages from all repositories under theforeman which have poor translation rate

While maintaining translations of Foreman and components I can see translations for most of the languages are poor. If I check the the state of translations posts historically then I don’t see any improvements in percentage of translations available. Below chart shows this trend for last 10 Foreman versions(1.22 - 3.0), and created using the data available from ‘State of the translations’ posts,

I propose to drop languages which are below 70 percent of completion from Foreman, Katello and all plugins. In future if translations improve for any of these languages then we can re-add those if required. Like to know if anyone has concerns about this?

Proposing to delete languages:

Language Current status as per Transifex
English(United Kingdom)(en_GB)(not available in chart) 10%
Galician(gl) 11%
Dutch(Netherlands)(nl_NL) 13%
Swedish(Sweden)(sv_SE) 14%
Polish(pl) 24%
Catalan(ca) 30 %
Italian(it) 42%
Czech(Czech Republic)(cs_CZ) 48%
Korean(ko) 49%
Chinese(Taiwan)(zh_TW) 51%
Russian(ru) 52%

Proposing to keep languages:

Language Current status as per Transifex
German(de) 70%
Portuguese(Brazil)(pt_BR) 88%
Spanish(es) 88%
Japanese(ja) 96%
Chinese(China)(zh_CN) 96%
French(fr) 97%
2 Likes

While I have no experience in translation — American to British English should be able to be automated. A quick google search, of course suggested the Google Translate API and this StackOverflow Question showed a GitHub project that had the data in JSON format. I wonder how Red Hat and IBM internally handle this particular “simpler” translation.

As an Australian and a Programmer there exists a tension between wanting to spell words the way we are taught and the accepted norm that code should be written in American English.

So given the audience of Foreman, which I assume to be principally System Administrators, Programmer and other IT industry people, we have lived with American English as the default in UNIX and Linux for a long, long time. So losing the translation for this audience is hardly going to raise an eyebrow.

The problem that effort could be spent on, is not using the default Date/Time format like in “Generated at Sep 03, 1:12 PM” from the “Monitor → Overview” page. While in my opinion all computer based applications should just use the numerical YYYY-MM-DD(Space|T)HH:MM format (the T variant being ISO 8601) - that is a different battle - but related to localisation.

I blocked one of my teammates for beginning of October to improve the German translation again.
Let’s see how much can be done in a week, last time I did this can be seen with the big jump from 1.22 to 1.23, so I have some hope. :wink:

1 Like

Thanks all are willing to contribute! I agree with the language proposed to drop (below 70%). To me it feels that semi-translated project is worse than full English version of it.

I agree with removing some of the lower-percentage languages, but I would suggest setting the bar a bit lower than 70%, perhaps 50% or 40%.
Getting to (and maintaining) over 70% without dedicated translators working on the project is quite difficult - if I’m not mistaken, the 6 languages above 70% all have translations contributed by Red Hat’s localization team. If we don’t take any languages with a lower translation rate, volunteer translators will have no motivation to contribute translations since the chances of getting their translations in actual use is slim.

Regarding en_GB, I think the percentage is misleading - since most strings do not require any changes and thus have no translation. I would suggest keeping it even if it remains at a very low percentage.

1 Like