View Issue Details

IDProjectCategoryView StatusLast Update
0000900Main CAcert Websitepublic2013-01-15 15:21
ReporterUli60 Assigned ToNEOatNHNG  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionduplicate 
Fixed in Version2012 Q1 
Summary0000900: CAcert Site translation
Descriptionplease check russian translation for this site. I've tried all
encodings, 3 browsers (IE8, Firefox 3.6.12, Opera 10.63), but still
can't read any russian text, including navigation and buttons. Probably
incorrect encoding.

possible solution can be
to remove the russian translingo, and builtup from scratch

(reported by INOPIAE, 2010-11-07)
TagsNo tags attached.
Reviewed by
Test Instructions


duplicate of 0000985 closedTed Main CAcert Website Move from translingo to pootle 
has duplicate 0000816 closedNEOatNHNG Main CAcert Website language encoding not correct for non-english pages 
related to 0000869 new Wiki Wrong characters while creating the pdf for COAP 



2010-12-13 14:25

updater   ~0001819

comment by edgarwahn (2010-11-08)
hebräisch scheint auch kaputt zu sein, Uli, Du erinnerst Dich eventuell?
Kam irgendwann mal in einer der Software Assessment Telcos zur Sprache.
Dabei hatten wir ja gesehen dass das Encoding von Sonderzeichen in den
Textdateien kaputt war, das läßt sich meiner Meinung nach per Script
wieder geradebiegen.

Eventuell ist der Aufwand kleiner als das komplett neu Übersetzen zu lassen?

Ich habe nur leider im Moment keine Zeit um zu prüfen ob es der selbe
Fehler ist und ob man das mit vertretbarem Aufwand automatisiert
korrigieren kann.


2010-12-13 14:26

updater   ~0001820

comment by joost (2010-11-08)
Ich hab Meldungen bekommen das die Russische Übersetzung in mindestens 3
verschiedene charactersets ist.

Ohne 2/3 zu löschen oder jemand die sich mal die zeit nehmt und jeder
Linie gerade zieht bleibt das Problem. Ich befürchte aber das letzte
passiert nicht bis es abgezwungen ist.

(Dem Kerl mit dem ich geredet habe schlag vor 100% zu löschen.)


2010-12-13 14:27

updater   ~0001821

comment by edgarwahn (2010-11-08)
in unserem speziellen Fall war nicht das Encoding an sich kaputt sondern
die Darstellung in den gettext Files. Da wurde irgendwo mal was doppelt
encodiert, beim hebräischen wäre das meiner Meinung nach maschinell zu

Ich kann natürlich nicht sagen in wie weit das auf das russische zutrifft.


2010-12-13 14:32

updater   ~0001822

comment by joost (2010-11-08)
Hi ..., as I recall you spoke/wrote/read Russian near-fluently.

Lately the subject once again came around to the russian translation of
the CAcert website.

I have a request for you.
Could you please take a look at the translated strings on, and provide us with an analysis of the
problems with those.
As I recall last year you stated there were 3 or more charsets/encodings

If the problem lies indeed with the translated strings, scouring the
code provides little progress.


2010-12-13 14:33

updater   ~0001823

comment by a user (2010-11-08)
I have the same problem with the Polish language.
Solution was to encode the page in utf-8 just as it does


2011-01-22 21:12

updater   ~0001843

(21:04:11) mivael: Hi!
(21:05:07) mivael: It seems something's wrong with encoding on this page (should be Russian))
(21:05:12) mivael: Where to report?
(21:25:46) u60: hi mivael, we had a report about wrong encoding on lang=ru_RU before, give me a few minutes for some investigation on this ...
(21:26:31) mivael: ok, thanks
(21:27:39) u60: reported here:
(21:28:02) u60: first reported 2010-11-07
(21:29:31) u60: I have a request for you.
(21:29:31) u60: Could you please take a look at the translated strings on
(21:29:31) u60:, [^] and provide us with an analysis of the
(21:29:31) u60: problems with those.
(21:34:19) u60: mivael ? can you help on this ?
(21:35:14) mivael: just a minute

(22:00:05) mivael:
(22:00:22) mivael: partly translations are okay, partly not
(22:07:03) mivael: I'm lucky :)
(22:07:24) mivael: Unseen messages automatically decoded by this great thing:
(22:08:10) mivael: so, now I can try to correct mistakes (wrong msgs are in CP1252 for some reason)


2011-01-23 00:52

updater   ~0001844

It took about 3 hours, and I hope it'll be of use for and community.

1. What I've done, in short:

1.1. Converted all the wrong (CP-1252) messages to make them visible.
Approximately 70-80 translations (ru_RU) converted.

This was done by accurate copy/pasting. In case someone will need it
in future, exact steps that worked for me quite fast and reliable
(mouse moves minimized):

a) visually look for the next unreadable message
b) when found press "Edit" link for it
c) press <Tab> (to select the text field)
d) press <Ctrl+A> (to select all text edited)
e) press <Shift+Del> (copy the unreadable text to clipboard and
delete from the text field)
f) press <Alt+Tab> (switch to another browser window with decoder
open:, text field already
selected and empty)
g) press <Shift+Insert> (paste from clipboard)
h) press <Tab> (select the "decode" buttoh -- "????????????")
i) press <Space> (press the button)
j) press <Shift+Tab> (return to the text field)
k) press <Ctrl+A> (to select all decoded text)
l) press <Shift+Del> (copy the text to clipboard and delete from the
text field)
m) press <Alt+Tab> (return to the browser window with, cursor is in the empty text field as
we left it in (e))
n) press <Shift+Insert> (paste from clipboard)
o) press <Tab> (select the "Update" buttoh)
p) press <Space> (press the button)
q) repeat from (a)... :-)

1.2. Checked some "fuzzy" translations. When I was sure, I corrected
them. When I was sure the translation is misleading, I replaced the
translation with its English variant.

1.3. Selectively translated several messages that hadn't been translated.
Unfortunately, my time is limited, and I don't have good knowledge
about the site to know well the context for messages to translate.
But some selected obvious (it seemed to me) messages I've done.

I doubt I could contribute more time, but please, feel free to email
me in case you have questions concerning the work done.
I want to be sure my contribution will serve good.

2. While doing the work I discovered that Russian translations need
serious proof reading. Probably, you know that, but to be sure you
IMO the proof reader should have:
 - sound experience with the site (I do not qualify)
 - good English, understanding of IT topics
 - native Russian
 - time to contribute:) (there're more than a thousand messages to
proof read or/and translate)


2011-01-23 00:53

updater   ~0001845

critical sysadmins + software-assessment team triggered to start the manual transfer script


2011-01-23 00:56

updater   ~0001846

translation corrections done by mivael
needs further check if pages are online


2011-01-26 16:44

developer   ~0001848

New Russian translations have been pulled into the production server and have been enabled, but Russian proofreader reports:
  I just checked on the site -- it doesn't seem to be fixed yet.
  (looked as KOI-8, the result looks the same as earlier)


2011-01-26 16:45

developer   ~0001849

Thanks for checking -- I didn't quite know how to do it -- but you are
right I'm afraid on concluding that it doesn't work. I have double-checked
our procedures for uploading and enabling the translations, and there is
nothing wrong there as far as I can tell.

BUT ... when viewing the page
with Firefox's View/Character Encoding set to "Cyrillic (ISO-8859-5)" it looks
exactly right (as far as I can judge of course, not being a native Russian
speaker :-)). However, the current application code always seems to deliver
webpages with "Content-Type: text/html; charset=iso-8859-1". Apparently this
works for part of the cyrillic character set, but not for the full set.

I would like to refer this problem to the application developers / maintainers
(cc'ed on this message), as it's not a simple sysadmin problem, but really
requires some application adjustments. I think that the application should
generate an appropriate charset=iso-something setting based on the language
it has elected to display, which it currently doesn't. It would have been
nice if it had been tested first on our test system;
unsurprisingly exactly the same problem shows up there.


2011-02-02 22:17

updater   ~0001853

To fix this problem entirely, an UTF-8 migration needs to be made
over the whole system (code, database)
so we've discussed this on our last Software-Assessment project meeting
Summary: Russian code page / UTF-8 project
# Dirk: UTF-8 migration probably doesn't work with the old php
    * also some troubles under Apache 2, php 5
    * needs also Database migration
    * UTF-8 migration, yes, but only if there is a straight forward concept
# Privacy Problems: NDA for admins ? Can be handled thru a simple Arbitration case

This seems to be a longer process .. so therefor in the meanwhile,
support can answer requests with a workaround:

> can you confirm, that switching to codepage "Cyrillic (ISO-8859-5)"
> do solve the problem ?!?

Yes, I confirm. Checked once more, and

the exact steps to reproduce both the problem and the workaround:

1. / Translations / ???????
( )

Now the text is garbled ("Western ISO-8859-1" autodetected).

2. Switching to ISO-8859-5.

In my browser (Firefox 3.6.13) it's exactly the following:

   View / Character Encoding / More Encodings
   / East European / Cyrillic (ISO-8859-5)

Now all Russian text is okay.
The workaround works for me.

> so if we receive reports from users about garbled ru_RU language page
> we can offer this as a workaround regarding this problem ?

Yes, I think this should work for other users, as well.


2011-02-03 02:58

administrator   ~0001855

OK, I did a small fix that send the proper charset to the browser (already on the test system This is for time being when we don't have UTF-8 support yet.

This doesn't only affect the Russian but all locales that use non ISO-8859-1 charsets, that means:

- Chinese
- Polish
- Hungarian
- Japanese
- Russian
- Lithuanian

The following things need extensive testing:

a) Does the fix work for you?
Please test with as many browsers as you have on your system and probably disable auto-detection of the character set (in Firefox: View->Character Encoding->Auto-Detect->(Off))

b) Does it break anything that was working before?
Especially submitting text values like the Assurance location, names and so on. Also try to add some special characters and foreign letters in there (especially from the language you're testing, you don't need to be able to understand what you put in there just copy and paste from somewhere else and check whether it comes out the same way it goes in). Also try whether you can submit data in one language and retrieve it with another one.

Fix is available in branch bug-900 (commit ID 19d2883e7a8f480d82e9684f6bd619cb1dda4d8f)

Happy Testing ;-)


2011-02-03 03:05

administrator   ~0001856

First thing I noted:

German umlauts (entered when using English translation) are displayed as Russian characters when choosing Russian translation. But that's also the case when manually forcing the Cyrillic encoding.


2011-02-08 08:57

updater   ~0001860

Last edited: 2011-02-08 09:19

Create new user with many special characters in the last name new on test server with German as default language.
When I switch the default language of the user to Polish and Russian the characters get mixed up. Both in IE 8.0 and Firefox 3.6.13
see for the characters


2011-02-16 12:28

administrator   ~0001869

When using Russian as language on Join, and then typing in a Russian name, the name is not properly displayed when using another account using English translation (e.g. Assure Someone).

This means there is crap in the database => this is a non-fix no need to test any further.


2012-01-30 14:53

administrator   ~0002802

This should be fixed by the transition to pootle. Please test and if successful close or if not reopen the bug.

Werner Dworak

2012-12-21 05:10

updater   ~0003512

More than 3 month fixed and no complaints

Issue History

Date Modified Username Field Change
2010-12-13 14:21 Uli60 New Issue
2010-12-13 14:25 Uli60 Note Added: 0001819
2010-12-13 14:26 Uli60 Note Added: 0001820
2010-12-13 14:27 Uli60 Note Added: 0001821
2010-12-13 14:32 Uli60 Note Added: 0001822
2010-12-13 14:33 Uli60 Note Added: 0001823
2011-01-22 21:12 Uli60 Note Added: 0001843
2011-01-23 00:52 Uli60 Note Added: 0001844
2011-01-23 00:53 Uli60 Note Added: 0001845
2011-01-23 00:56 Uli60 Note Added: 0001846
2011-01-23 00:56 Uli60 Status new => needs review & testing
2011-01-26 16:44 wytze Note Added: 0001848
2011-01-26 16:45 wytze Note Added: 0001849
2011-02-02 22:17 Uli60 Note Added: 0001853
2011-02-03 02:58 NEOatNHNG Note Added: 0001855
2011-02-03 03:05 NEOatNHNG Note Added: 0001856
2011-02-08 08:57 INOPIAE Note Added: 0001860
2011-02-08 09:19 INOPIAE Note Edited: 0001860
2011-02-16 12:28 NEOatNHNG Note Added: 0001869
2011-02-16 12:38 NEOatNHNG Project Translingo => Main CAcert Website
2011-04-30 11:19 NEOatNHNG Status needs review & testing => confirmed
2011-04-30 11:20 NEOatNHNG Relationship added has duplicate 0000816
2011-06-19 16:53 NEOatNHNG Source_changeset_attached => cacert-devel master 50f4d415
2011-06-19 16:53 NEOatNHNG Source_changeset_attached => cacert-devel master 19d2883e
2011-06-21 20:08 INOPIAE Relationship added related to 0000869
2011-06-21 23:57 NEOatNHNG Source_changeset_attached => cacert-devel master 50f4d415
2011-06-21 23:57 NEOatNHNG Source_changeset_attached => cacert-devel master 19d2883e
2011-06-22 00:09 NEOatNHNG Source_changeset_attached => cacert-devel master 50f4d415
2011-06-22 00:09 NEOatNHNG Source_changeset_attached => cacert-devel master 19d2883e
2011-09-28 02:19 Uli60 Relationship added related to 0000985
2012-01-30 14:53 NEOatNHNG Note Added: 0002802
2012-01-30 14:53 NEOatNHNG Relationship replaced duplicate of 0000985
2012-01-30 14:53 NEOatNHNG Status confirmed => solved?
2012-01-30 14:53 NEOatNHNG Resolution open => duplicate
2012-01-30 14:53 NEOatNHNG Assigned To => NEOatNHNG
2012-12-21 05:10 Werner Dworak Note Added: 0003512
2012-12-21 05:10 Werner Dworak Status solved? => closed
2013-01-15 15:21 Werner Dworak Fixed in Version => 2012 Q1