B=) STOP QMAILAs it is written in the program documentation one has to be very careful when cleaning the mail queue. Be sure to stop qmail with qmailctl or whatever script is used to shutdown any mail sever in progress operations, otherwise there is big chance the queue to mess up badly .

I have a bunch of old html files all encoded in the historically obsolete Windows-cp1251. Windows-CP1251 used to be common used 7 years ago and therefore still big portions of the web content in Bulgarian / Russian Cyrillic is still transferred to the end users in this encoding.

This was just before the "UTF-8 revolution", where massively people started using UTF-8,
Well it was clear the specific national country text encoding standards will quickly be moved by to UTF-8 – Universal Encoding format which abbreviation stands for (Unicode Transformation Format).

Though UTF-8 was clear to be "the future", many web developers mostly because of their incompetency or using an old sources of learning how to writen in HTML continued to use windows-cp1251 in HTMLs. I'm even convinced, there are still developers out there who are writting websites for Bulgarian / Russian / Macedonian customers using obsolete encodings …

The smarter developers of those accustomed to windows-cp1251, KOI-8R etc. etc., were using the meta tag to specify the type of charset of the web page content with:

Anyhow, still many devs even didn't placed the windows-cp1251 in the head of the HTML …

The result for the system administrator is always a mess – a lot of webpages that are showing like unreadable signs and tons of unhappy customers.
As always the system administrator is considered responsible, for the programmer mistakes :). So instead of programmers fix their bad cooking, the admin has to fix it all!

One quick work around me as admin has applied to failing to display pages in Cyrillic using the Windows-cp1251 character encoding was to force windows-cp1251 as a default encoding for the whole virtualhost or Apache directory with Apache directives like:

Though this mostly would, work there are some occasions, where only a particular html files from all the content served by Apache is encoded in windows-cp1251, if most of the content is already written in UTF-8, this could be a big issues as you cannot just change the UTF-8 globally to windows-cp1251, just because few pages are written in archaic encoding….
Since most of the content is displayed to the client by Apache (as prior explained) just fine, only particular htmls lets's ay single.html, single2.html etc. etc. are displayed with some question marks or some non-human readable "hieroglyphs".

Below is a screenshot from two pages returned to my browser in wrongly set htmls charset:

Improper Windows CP1251 delivered page in UTF-8 browser view

Improperly served encoding CP1251 delivered by Apache in non-utf-8 encoding

When this kind of issues occur, the only solution is to simply login to the server and use iconv command to convert all files returning unreadable content from whatever the non UTF-8 encoding is lets say in my case Bulgarian typeset of cp1251 to UTF-8

Here is how the iconv command to convert between windows-cp1251 to utf-8 the two sample files named single1.html and single2.html

Debian has a package language-env. I haven't used my Linux console for a long time. So I couldn't exactly remember how I used to be making the Linux console to support cyrillic language (CP1251, bg_BG.UTF-8) etc.

I've figured out for the language-env existence in Debian Book on hosted on OpenFMI – Bulgarian Faculty of Mathematics and Informatics website.
The package info with apt-cache show displays like that:

hipo@noah:~/Desktop$ apt-cache show language-env|grep -i -A 3 description
Description: simple configuration tool for native language environment
This tool adds basic settings for natural language environment such as
LANG variable, font specifications, input methods, and so on into
user's several dot-files such as .bashrc and .emacs.

What is really strange, is the package maintainer is not Bulgarian, Russian or Ukrainian but Japanese.
As you see the developer is weirdly not Bulgarian but Japanese Kenshi Muto. What is even more interesting is that it is another japanese that has actually written the script set-language-env contained within the package. Checking the script in the header one can see him, Tomohiro KUBOTA

Before I've found about the language-env existence, I knew I needed to have the respective locales installed on the system with:

# dpkg-reconfigure locales

So I run dpkg-reconfigure to check I have existing the locales for adding the Bulgarian language support.
Checking if the bulgarian locale is installed is also possible with /bin/ls:

The language-env contains a perl script called set-language-env which is doing the actual Debian Bulgarization / cyrillization. The set-language-env author is another Japanese and again not Slavonic person.

Actually set-language-env script is not doing the Bulgariazation but is a wrapper script that uses a number of "hacks" to make the console support cyrillic.

There are many questions in cyrillic list necessery to be answered to exactly define if you need cyrillic language support for GNOME, pine, mutt, console etcetera.
The script will create or append commands to a number of files on the system like ~/.bash_profile
The script uses the cyr command part of the Debian console-cyrillic package for the actual Bulgarian Linux localization.

As said it was supposed to also do a localization in the past of many Graphical environment programs, as well as include Bulgarian support for GNOME desktop environment. Since GNOME nowdays is already almost completely translated through its native language files, its preferrable that localization to be done on Linux install time by selecting a country language instead of later doing it with set-language-env. If you failed to set the GNOME language during Linux install, then using set-language-env will still work. I've tested it and even though a lot of time passed since set-language-env was heavily used for bulgarization still the GUI env bulgarization works.

If set-language-env is run in gnome-terminal the result, the whole set of question dialogs will pop-up in new xterm and due to a bug, questions imposed will be unreadable as you can see in below screenshot:

If you want to remove the bulgarization, later at certain point, lets you don't want to have the cyrillic console or programs support use:

# set-language-env -r
Setting up users native language environment'

For anyone who wish to know more in depth, how set-language-env works check the README files in /usr/share/doc/language-env/ one readme written by the author of the Bulgarian localization part of the package Anton Zinoviev is /usr/share/doc/language-env/README.be-bg-mk-sr-uk

Acid3 Test is a group of browser compitability tests. Acid3 test is a good indicator on how Web ready is your browser.

Acidtest is part of the web standards project. Latest Firefox 9.0.1 passes the test on 100% (100/100).
I've tried it with Epiphany and it scored only 67/100, still I'm using Epiphany on daily basis and I'm quite happy with it.
The tests involved are testing browser for:

DOM

DOM2

Checks on HTML tables and forms browser rendering

SVG compitability testing

DOM1 and DOM2 compitability

Various ECMA Script Javascript compitability tests

Unicode (UTF-16 and UTF-8) browser compitability

XHML, SMIL, CSS, HTML compitability

Content-type image/png, text plain etc.

The Acid3 test is written itself in Javascript. It consists of 6 testing "stages" (buckets) upon which the browser tested is evaluated.
Each of the test is represented visually by a rectangle. If the a test stage is passed you see a new rectangle appearing in the tested browser.
In wikipedia, there is a thorough list with web browsers by type and engine and the level of support for the Acid3 test.
The test is of great use if you're web developer.

I've not played audio CD for ages. Anyways I had to set up one computer with Linux just recently and one of the requirements was to be able to play audiocds.
I was surprised that actually a was having issue with such as simple tasks.
Here is how i come with this article.

If you encounter errors playing Audio CDs on any Linux distro in VLC or other players, you might need to apply the following fix.

I'm not sure if this packages are required, anyways having them installed is a good idea especially on computers which will have to support as much multimedia as possible.

Trying to play a CD with VLC the result was not nice, you see in the picture above the error that poped up while trying it with VLC:

Due to wrong configuration of the play device VLC will be looking to read the audio cd from.

To succesfully play the audiocd invoke VLC command with a cdda///dev/sr0 argument like so:

hipo@xubuntu-desktop:~$ vlc cdda:///dev/sr0
...

To permanently fix the error you will have to edit ~/.config/vlc/vlcrc :

Inside ~/.config/vlc/vlcrc find the lines:

dvd=/dev/cdrom

Substitute the above line with:

dvd=/dev/sr0

Next find the line:

vcd=/dev/cdrom

Change the above line with:

vcd=/dev/sr0Due to a bug in generating vlcrc , the dvd= might be set also to other messy unreadable characters (different from /dev/cdrom). This can also be the reason why it fails to properly read the disc.

If dvd= and vcd is set to a different unreadable characters delete them and substitute with /dev/sr0 .I've experienced this on Xubuntu Linux with a Bulgarian localization (probably the bug can be seen in other Linuxes when GNOME is installed in Russian, Chineese and other UTF-8 languages.

The strange error can be observed also in other players when the localization is set to someone's native language …
Alternative solution is to install and use rhythmbox instead of VLC.
Other program to play audio CDs called workman , you will have to get used to the interface which uses gtk1 and therefore obsolete. Putting aside the ugly interface it works 😉

I needed to convert a file which had a Bulgarian text written in UTF-8 encoding to Windows CP1251 in order to fix a website encoding problems after a move of the website from one physical server to another.

I tried first with enca – ( detects and convert encoding of text files from one encoding to another).

The exact way I tried to convert was:

linux:~# enca -L bg /home/site/www/includes/utf8_encoded_file.php
... Unfortunately this attempt to conver was unsucesfully, and the second logical guess was to use iconv – Convert encoding of given files from one encoding to another to do the utf8 to cp1251 conversion.
I reached for some help in irc.freenode.net, #varnalab channel and Alex Kuklin helped me, giving me an example command line to do the conversion.iconv winedows to cp1251 conversion line, he pointed to me was:

linux:~# iconv -f utf8 -t cp1251 < in > out

Further on I adapted Alex’s example to convert my utf8_encoded_file.php encoded Bulgarian characted to CP1251 and used the following commands to convert and create backups of my original UTF8 file:

Lately, I have to deal with some wordpress based installs in big part of my working time. One of the wordpress sites needed to have added a multi language support.

My first research in Google pointed me to WPML Multilingual CMSThe WordPress Multilingual PluginWPML Multilingual CMS looks nice and easy to use but unfortunately its paid, the company couldn’t afford to pay for the plugin so I looked forward online for a free alternative and stumbled upon QTranslate

QTranslate is free and very easy to install. Its installed the wordpress classic way and the installation went smoothly, e.g.:

After activating the plugin, there is a Settings button from which qTranslate‘s various plugin parameteres can be tuned.

In my case my site had to support both English and Arabic, so from the settings I added support for Arabic translation to the wordpress install.

Adding Arabic is done in the following way:

a. From the Language Management (qTranslate Configuration) from the Languages menu and the Languages (Add Languages) I had to choose a language code (in my case a language code of ar – for Arabic). Next I had to choose the Arabic flag from the follow up flag list.

In next text box Name , again I had to fill Arabic, for Locale en_US.UTF-8
The following Date Format and Time Format text boxes are optional so I left them blank.
To complete the process of adding the Arabic as a new language wordpress should support I pressed the Add Language button and the Arabic got added as a second language.

Afterwards the Arabic was added as second language, on the bottom of the left wordpress menu pane a button allowing a switch between English, Arabic appeared (see below screenshot):

Finally to make Arabic appear as a second language of choice on the website I added it as a Widget in the Widgets menu from the AWidgets menu:

Appearance -> Widgets

In widgets I added qTranslate Language Chooser to the Sidebar without putting any kind of Title for qtranslate widget .
I found it most helpful to choose the Text and Image as an option on how to display the Language switching in the wp.