This is default featured slide 1 title

This is default featured slide 1 title

You can completely customize the featured slides from the theme theme options page. You can also easily hide the slider from certain part of your site like: categories, tags, archives etc. More »

This is default featured slide 2 title

This is default featured slide 2 title

You can completely customize the featured slides from the theme theme options page. You can also easily hide the slider from certain part of your site like: categories, tags, archives etc. More »

This is default featured slide 3 title

This is default featured slide 3 title

You can completely customize the featured slides from the theme theme options page. You can also easily hide the slider from certain part of your site like: categories, tags, archives etc. More »

This is default featured slide 4 title

This is default featured slide 4 title

You can completely customize the featured slides from the theme theme options page. You can also easily hide the slider from certain part of your site like: categories, tags, archives etc. More »

This is default featured slide 5 title

This is default featured slide 5 title

You can completely customize the featured slides from the theme theme options page. You can also easily hide the slider from certain part of your site like: categories, tags, archives etc. More »


Welcome to our website. Neque porro quisquam est qui dolorem ipsum dolor.

Lorem ipsum eu usu assum liberavisse, ut munere praesent complectitur mea. Sit an option maiorum principes. Ne per probo magna idque, est veniam exerci appareat no. Sit at amet propriae intellegebat, natum iusto forensibus duo ut. Pro hinc aperiri fabulas ut, probo tractatos euripidis an vis, ignota oblique.

Ad ius munere soluta deterruisset, quot veri id vim, te vel bonorum ornatus persequeris. Maecenas ornare tortor. Donec sed tellus eget sapien fringilla nonummy. Mauris a ante. Suspendisse quam sem, consequat at, commodo vitae, feugiat in, nunc. Morbi imperdiet augue quis tellus.

New Japanese era

On 1 May 2019 a new era of the Japanese calendar will begin. Fedora is ready for this change.

What This Is All About

1 December 2017 the Emperor of Japan Akihito officially announced that he would abdicate on 30 April 2019. From 1 May his successor Naruhito will rule which will also begin a new era in the Japanese calendar. This is rather unusual event because so far emperors ruled until their death. Obviously, this made the moment of the era change difficult to predict. The emperor’s decision will help the country prepare for the change.

Although the Gregorian calendar (the same as in many countries around the world) is known and used in Japan, the traditional Japanese calendar is also used with the years counted from the enthronement of an emperor. Each period of an emperor’s rule is called an era and has its own proper name. For example, the current era is named Heisei (平成), at the time of writing we have 31 year of Heisei era.

On 1 April, one month before the beginning of the new era its name was announced. It will be named Reiwa (令和). As we know it we can adapt computers and other devices displaying dates automatically.

How To Test

In Unix systems dates are formatted by strftime() function, the easiest way to test it is to use the date command. Launched from the command line it displays the current date and time in our own language and using the default format:

The change applies to the Japanese calendar which is available only in Japanese locales:

There is still nothing interesting because the default date format in Japanese locale displays the Gregorian calendar. A custom date format must be used:

So here we have something interesting: 31 year of Heisei era has been displayed.

So far we are in April, in the old Japanese era. How to display a date from the new era? Let’s use the commands which will display a date one month ahead:

If we still can see the 31 year of Heisei era then this is a bug. An updated system should display:

Why the command LC_ALL=ja_JP.utf8 date +%EY -d "1 month" has not displayed any number? The first year of an era usually is not written with a number 1 but described with a word gannen (元年) which means “the initial year”.

More Explanations

Let’s explain what those magical symbols like +%Ec mean. The character "+" means that the following string is a date format which has to be used. The character "%" marks the beginning of the format, the character "E" means that the alternative calendar should be used. Here is a summary of the format specifiers which have been used for tests:

%EC   the name of an era (e.g., Heisei, Reiwa)
%EY   year number including the era name
%Ey   year number in the Japanese calendar without an era name
%Ec   full date and time in the Japanese calendar
%Ex   full date (without the time) in the Japanese calendar

Compare this with:

%C   century number minus 1, or the initial digits of the year (currently 20—yes, not 21)
%Y   year number in the Gregorian calendar (2019)
%y   year number abbreviated to 2 digits (19)
%c   full date and time
%x   full date (without the time)

Please note that the "E" character in English locales will cause no effect, it will be ignored.

The -d switch means that date command should display a different date than the current one, for example -d "1 month" means one month ahead from now.

How To Update

In order that the calendar support the new Japanese era the glibc library must be updated to the version at least:

Fedora 28   glibc-2.27-38
Fedora 29   glibc-2.28-27
Fedora 30   glibc-2.29-9
Fedora Rawhide   glibc-2.29.9000-10
RHEL 7/CentOS 7   glibc-2.17-260.el7_6.4

Fedora Rawhide is a base for the future Fedora 31 release (November 2019) but before this happens a new version glibc 2.30 will be released which will support the new Japanese era from the beginning.

Fedora 29 Release Party at Linux Autumn: Event Report

Release Party attendees: Making the group photo. This photo credits: Julita Inca Chiroque.

During this year’s Linux Autumn we organized Fedora 29 Release Party. These kind of events are organized around the world after the new version of Fedora is released. It’s likely that it was the world’s first Fedora 29 Release Party (for this version) because the official poster design was not yet ready and nobody had asked for it before.

Again, being an organizer, I must warn you that my perception of the event may be different than the one of an attendee. But on the other hand I saw more behind the scene events.

The party was attended by the Linux Autumn attendees. Its organizers included two Fedora ambassadors: Julita Inca Chiroque from Peru and Dominik “Rathann” Mierzejewski from Poland. Julita, as always, brought lots of balloons with Fedora and GNOME logos, and Matej Marušák from Red Hat Brno brought Fedora stickers and other swag.

We allocated little time for this event, only 25 minutes. That’s short but initially we had thought it would be enough. For a longer while we had been discussing what should we do during the party. We did not have to tell the attendees what Fedora was because those people knew it well. It was worth to mention what’s new in this release compared to the previous ones but none of us was able to mention any new feature except modularity.

Of course, the core point of the event was the cake with Fedora logo. However, we did not want it to be the only point so we decided to talk about Fedora Accounts System: how to create an account and to become a contributor of Fedora. We also planned to talk about Fedora badges and mention that a badge will be awarded to the attendees of the Fedora Release Party. We decided that Julita would talk about it because she had been the most experienced of us all. But during the party Matej who had his laptop already connected to the projector and was near the microphone talked about everything and showed examples on the screen. He talked so perfectly that there was nothing more to add.

25 minutes turned out to be much too little. The following talks had to wait. But I think that nobody complained. Even if one was not convinced to use Fedora (instead of other distros) then at least liked the cake.

Linux Autumn 2018: Event Report

Linux Autumn, the 16th annual conference of Linux and free software enthusiasts, organized by PLUG, was held from 9 to 11 November. This year, same as last year, we met in Ustroń, southern Poland, but we changed the venue: this time it was Hotel Gwarek.

I must say that my report may be little biased because I was included into the organizing team and I took it seriously. 🙂

But honestly speaking I think that this year Linux Autumn was very successful. We had as many as three foreign guests including some from outside Europe, plus of course many great people from Poland. Slowly our conference becomes more international. If you have not been there – you have good reasons to regret.

Day #1: 9 November

I managed to attend two talks, both very interesting. First Dominik ‘Rathann’ Mierzejewski was talking about common bugs in the development of packages for Fedora and similar operating systems. Dominik is a long time Fedora contributor and ambassador, maintainer of multiple packages, so he knew well what he was talking about. The second talk was given by Maja Kędras, a student from Wrocław University of Science and Technology. She summarized the graphics editors available in Linux: GIMP, Inkscape, Blender, and Krita. Those applications make great alternative for popular commercial packages. Sadly, they are not commonly appreciated.

The day ended with a dinner which extended into late night socializing talks, board and old video games traditionally delivered by DKiG Foundation (Old Computers and Games).

Day #2: 10 November

Marcin Zajączkowski talks about fish

On the second day there were much more events than on the first one. At 9 AM Marcin Zajączkowski gave a talk about Fish shell, an interesting alternative to bash. The second speaker was Julita Inca Chiroque, long time Fedora ambassador from Peru and GNOME Project contributor, currently studying High Performance Computing at the University of Edinburgh. She talked about parallel computing libraries for C and Fortran: OpenMP and MPI. Next we had a little change in the agenda: instead of Maciej Lasyk who arrived only the next day Błażej Święcicki gave his talk about log analysis.

Unfortunately, as an organizer I was unable to attend all talks so I don’t mention them here. The full list can be found at the organizer’s website. The next point for me was the lunch followed by two hours long workshop about parallel programming with OpenMP hosted by Julita Inca Chiroque and her fellow student from the University of Edinburgh Ana Maria Garcia (from Columbia). I really regret that so few people attended it because it was really interesting.

Then there was the real centerpiece of the event: we organized Fedora 29 Release Party. I will describe it in a separate article.

The next talk Securing your daemons using systemd was given by Zbigniew Jędrzejewski-Szmek, one of the main contributors of the project. Big shout to Zbyszek who was probably the first Polish speaker brave enough to give his talk in English thus making it accessible for the foreign guests.

The last speaker of the day was Matej Marušák from Red Hat. Matej works in ABRT project and that’s how I had a chance to have met him before. He talked about that project.

The day ended with an open air barbecue party, slightly delayed because of the tight timetable.

Day #3: 11 November

Unfortunately, due to my organizer’s duties I was unable to attend any talk that day. It’s a pity because from the agenda I know that Dariusz Puchalak talked about Ansible (fortunately, I attended his talk a year before) and there were two workshops: about development of RPM packages for Fedora and about Ansible for beginners. During that time I took care of the foreign guests. We went to the Krakow Balice airport but before we managed to sightsee Krakow for few hours and even some parts of Lesser Poland. It was funny as well.


Last year Linux Autumn saw a little decline but this year it was much better. If we keep this trend, next year we will have a really great conference. Schedule it in your calendar already, see you next year!

glibc 2.28: New and Updated Locales

See also:

New version 2.28 of glibc library has been released according to the schedule, that means on August 1, 2018. This time the changes in locale support are not revolutionary. Most of them just continue the works started and partially completed in the previous versions.

Alphabetic Collation

Shortly after the previous release the work on polishing the alphabetic sorting has been finished. This applies to all languages because the collation algorithm must support not just the current locale but also must be able to handle the foreign characters. The collation rules according to ISO 14654:2016 standard have been fully imported. The standard itself also evolves although the changes are little relevant from the end users’ point of view. For example, they apply to the punctuation marks or some rare letters used in little known languages.

Internally in glibc automatic collation tests for over 50 languages have been added. In future they will detect any upstream errors immediately.

Regular Expressions

Here are some problems being a consequence of corrected sort order. It turns out that the range regular expressions take the collation rules of the current locale into account. As a result:

  • The [a-z] expression matches not only the lowercase letters but also uppercase because they are interlaced between the lowercase in the collation order (e.g., a, A, b, B, …), but does not match Z because it is collated after z.
  • Source code manipulation systems which so far assumed that all source file names start with the lowercase letter, that means the regular expression [a-z]* matches them all except Makefile, have stopped working correctly.
  • The [0-9] expression now matches not just the digits from 0 to 9 but also all mathematical symbols which can be interpreted as numbers, that means, for example, fractions, superscript and subscript digits, digits from other numeral systems (Eastern Arabic, Indian, etc.)

There are many good reasons why ranges in regular expressions should be based on Unicode codepoint order rather than locale dependent collation order.

Since the error has been spotted late in the development cycle, in the beginning of July, a quick workaround has been introduced which deinterlaced the collation order of the lowercase and uppercase letters of the Latin alphabet. However, this workaround is temporary and will be reverted as soon as the correct implementation of the regular expressions is available.

Unicode 11

Full support of Unicode 11 standard has been introduced. This means that the rules of assignment of the new characters and alphabets to their proper categories (like letters, digits, punctuation marks etc.) and the new transliteration rules have been added. Also new emoji characters have been added. Of course, those changes usually apply to other alphabets than those commonly used in Europe. For example, single characters have been added to Armenian, Hebrew, Arabic and some Indian scripts. Whole Mtavruli block in Georgian script, Hanifi Rohingya, Sogdian and Old Sogdian, Dogri, Gondi, and Makasar scripts, Maya and Siyaq numerals, etc. Many of these characters and scripts are just historic.

New Locales

This time only two new locales have been added: Lower Sorbian and Yakut. Lower Sorbian is a Slavic language, closely related with Polish, used in Lower Lusatia which is part of Germany, near Cottbus (Lower Sorbian: Chóśebuz). Sadly, this language is heavily endangered: it is used by only 6–7 thousand people. Yakut language (also known as Sakha) belongs to the Turkic family, it is used by approx. 450 thousand people in Sakha Republic (Yakutia) which is part of the Russian Federation. They make nearly half of the population of the region.

It’s worth mentioning that both of these languages are inflected and require a genitive case of a month name when formatting a date.

Correct Date Formats in Inflected Languages

While talking about this, 2.28 is the second release of glibc, after 2.27, supporting two grammatical forms of month names. The previous work can be called successful and subsequent changes just include the support of more languages which have not been supported in the previous release due to lack of time.

Two grammar forms (usually nominative and genitive) of month names are now supported in the languages: ArmenianAsturian, Catalan, Czech, Kashubian, OccitanOssetianScottish Gaelic, Upper Sorbian, and Walloon. Together with those two newly added they make total of 19 languages using grammatically correct forms in dates.

It turned out that the difference between nominative and genitive case in abbreviated month names are visible not just in Russian and Belarusian, whose word for May is short enough so it cannot be abbreviated (nominative: май – pronounce: may, genitive: мая – pronounce: maya) but also in Greek in multiple month names (e.g., July, nominative: Ιούλιος, genitive: Ιουλίου, abbreviated forms: Ιούλ and Ιουλ, respectively).

In Kashubian language the difference between the nominative and genitive case in the month May turned out to be viisble also in the abbreviated form (nominative: môj, genitive: maja, abbreviated: môj and maj, respectively), and translators of Catalan languages asked to add, according to CLDR as well, the prefixes de and d’ to the abbreviated forms as well. As a reminder, a request to introduce the support of two grammatical cases of the abbreviated month names to the POSIX standard has been filed more than one year ago.

Minor Changes

Names of the week days and months in Aragonese language have been corrected. Abbreviated month names in Lithuanian language have been corrected, according to the current implementation in Glib library (part of the GNOME project) and CLDR, which by the way soon caused the automatic Glib tests to fail with older versions of glibc. Minor typos have been fixed in Kashubian language and Scottish Gaelic.

Announcing Linux Autumn 2018


If you have ever wondered, like I have, whether there will be an autumn (the Linux Autumn) this year then the answer is: yes.

Linux Autumn is an annual meeting of Free Software and Linux enthusiast from Poland organized since 2003 which means this year it will be its 16th time. This year it will be organized in Ustroń in the southern Poland from 9 to 11 November. The town is the same as the last year but in a different hotel.

As the place is located near the Czech and Slovak border we would like to invite more people, both speakers and attendees, from other countries. We are aware of strong presence of Fedora contributors in Brno and other nearby cities just across the border.

This conference has always been mostly Polish (in terms of the language) but there was always at least one foreign speaker who gave a talk in English. It has always been a chicken and egg problem: there are not many English talks because there are not many foreign attendees; on the other hand there are not many foreign attendees because there are not many English talks. I think we all will be happy to change this. We have already one foreign speaker confirmed, others are in progress.

Currently the registration is open but the organizers are still accepting talk proposals, the CfP deadline has been extended to 19 October. Please hurry with your talk proposal!

If you don’t know what is Linux Autumn about please see my articles about the event in 2017 and in 2016 or see the organizers’ website.

ffmpeg-compat Still Alive

For those interested: ffmpeg-compat package for Fedora is still alive.

The package is a very old version of ffmpeg whose most recent release is 4.0.2 (as of September 2018). It was maintained by RPM Fusion but it has been retired since the release for Fedora 27 (the last supported Fedora version was 26). If you need this binary for Fedora 28, for example because you use old applications which need it, you can download it from our Downloads section. The .spec file (the source used to build the RPM package) can be downloaded from the GitHub repository.

Oh, by the way, this means that now we have our Downloads section.

glibc 2.27: New and Updated Locales

See also: glibc 2.26: New and Updated Locales.

The new version glibc 2.27 has been released on February 1, 2018 (or February 2, depending on your time zone). This is the much belated report of the new changes in locale support.


Major rework has been started on the correct alphabetic sorting using ISO 14651:2016 standard (click here to download a publicly available version). It has been finished only after the glibc 2.27 release but the work in progress had fixed collation rules in many languages including Mandarin Chinese (Taiwan), Croatian, Czech, Estonian, Canadian French, Icelandic, Latvian, Lithuanian, Polish, Turkish, and Upper Sorbian. Much of this work has been completed or at least started during the Internationalization FAD and therefore it has been sponsored by Fedora Project. Big thanks to Mike Fabian for his great contribution!

Correct Date Formats

Another major change which must be mentioned here is the introduction of date formats using the correct grammar forms in inflected languages. This feature needs a separate article which will be written later. Shortly: from now the glibc functions nl_langinfo() and strftime() from now can support not only two forms of month names (full and abbreviated) but four (for months as used in dates, which often means a genitive grammar case in inflected languages, and for months as used standalone, which often means a nominative case). For example, in Polish language the month May is maj but in order to express a date it is obligatory to use a genitive case: 29 maja. The feature is optional which means that the languages which don’t need it will not see any change.

Introduction of a software feature does not cause any changes until the locale data using it is provided. First Polish locale data has been updated, shortly followed by Ukrainian, and then Russian, Greek, Belarusian, Lithuanian, and finally Croatian. Ukrainian locale data has been using alternative digits feature to provide month names in a genitive case for last 11 years. This solution has been recognized as a dirty hack and removed, also it seems it was not widely known and therefore not widely used by actual users.

The change has appeared in the upstream repository only 10 days before the final release, there was not enough time to add more languages. The next release will include the updated locale data for Catalan, Czech, and few other languages.

New Locales

As every release, this adds new locales. There are 6 new languages: Kabyle, Karbi, Mauritian Creole (Morisyen), Miskito, Shan, and Yau (also called Uruwa), also 3 new variants: Bhojpuri for Nepal, English for the Seychelles, and Valencian (dialect of Catalan).

Kabyle is a language spoken by about 5 million people in Algeria, this makes it the third most spoken language of the country. Karbi is a minority language spoken by about 400,000 people in north-eastern India and north-eastern Bangladesh. Morisyen is the most spoken language of Mauritius (about 1 million speakers). Miskito is a native language spoken by about 150,000 people in Nicaragua and Honduras. Shan is a language spoken by more than 3 million people in Myanmar, this is the second most spoken language of the country. Yau is the smallest language added in this release, spoken by about 1,700 people in Papua New Guinea.

Bhojpuri is the third most spoken language of Nepal (6% of total population). It is also spoken in India and as such has been supported by glibc previously. Valencian Catalan language (ca_ES@valencia) is spoken by about 2.3 million people in Valencia, a community in Spain. It has been supported by some Linux distributions as a downstream patch for many years. From now it is officially in glibc. English does not need its introduction: of course, it has been present in computer industry since forever. It is also an official language of Seychelles along with French and Seychellois Creole.

Lots of Minor Fixes

There are also many other minor bug fixes in this release. The localized messages for yes and no and single-letter answers have been updated in many locales. Chinese, Japanese, and Korean accept full-width Y and N characters as valid answers. Some redundant data have been removed, for example all monetary data for all locales of India are now dynamically copied from Hindi. If there are bugs detected or changes are introduced in future it will be easy to change only one file. More updates include monetary and numerical formats, also less used data like phone number formats, address data, or ISBN numbers have been updated in many locales.

Finally, most of the Unicode sequences (like: <Uxxxx> where each x means a hexadecimal digit) in a source code of locale data have been replaced with ASCII characters, wherever possible. Nowadays nobody remembers why these sequences were required but plain ASCII turned out to be working perfectly. Of course, the characters from outside the basic ASCII range still remain encoded as the Unicode sequences.

Fedora 28: Updates for Czech, Catalan, Greek, and Lithuanian Users

Continuing my previous article I’d like to write about the more recent updates in date formats in glibc. These updates will be included in Fedora 28 final release. On March 29 a new version of glibc 2.27-8 has been released in f28 branch. Together with the unreleased version 2.27-7 it features the correct date formats in Czech, Catalan, Greek, and Lithuanian.

Unfortunately, these updates have not been included in the recently released Fedora 28 Beta ISO image so all Fedora 28 users must update their systems first.


Bugzilla link:

These changes are the most controversial. While talking to my Czech friends I had various answers to my question whether a genitive form of a month name in a date is obligatory in Czech language or not. Is April 10 in Czech 10. dubna or 10. duben? Because of these doubts the changes for Czech language were not included in glibc 2.27 initial release (February 1). But since the Czech translator has added the genitive forms of the months names to glib2 (whose aim is to provide the same features for the systems which do not support genitive forms of months names) I decided that there is no reason to wait any more.

So, this is a short message for Czech users: if you can see a date formatted incorrectly in Czech language because a month name should be nominative rather than genitive, then you must change the date format specifier from "%B" to "%OB" in the translation of an application as soon as possible. I am sorry about the confusion but other inflected languages require a genitive case here. The "%OB" format specifier has been introduced in order to support the cases where a nominative form is required.

By the way: probably the same problem will be in Serbian and Slovak but so far no changes have been introduced in these languages. It would be good to make some decisions before glibc 2.28 is released which is planned on August 1 this year, and better not in the last minute – one month or more before would be recommended.


Bugzilla link:

We are in April which is a good time to discuss the Catalan language because April in Catalan is abril and the date April 10 is 10 d’abril. The next month will be May (Catalan: maig) and the date May 10 will be 10 de maig.

As I wrote in the previous article, this update had already landed in Fedora Rawhide but now it has been also included in Fedora 28 repository. However, this is not the only change. It turns out that in Catalan the de preposition (or d’ if the following noun begins with a vowel) obligatorily must be added before the abbreviated months names, so there is not only d’abril but also d’abr.

This causes some problem: the ls command line utility which displays file modification timestamp (ls -l) limits abbreviated months names to 5 letters. Let’s see how it looks in Catalan if we use the correct genitive case:

$ LANG=ca_ES.utf8 ls -l
total 0
-rw-rw-r--. 1 rl rl 0  1 de ge 00:00 20180101.test
-rw-rw-r--. 1 rl rl 0  2 de fe 00:00 20180202.test
-rw-rw-r--. 1 rl rl 0  3 de ma 00:00 20180303.test
-rw-rw-r--. 1 rl rl 0 14 d’abr  2018 20180414.test
-rw-rw-r--. 1 rl rl 0  5 de ma  2018 20180505.test
-rw-rw-r--. 1 rl rl 0  6 de ju  2018 20180606.test
-rw-rw-r--. 1 rl rl 0  7 de ju  2018 20180707.test
-rw-rw-r--. 1 rl rl 0  8 d’ag.  2018 20180808.test
-rw-rw-r--. 1 rl rl 0  9 de se  2018 20180909.test
-rw-rw-r--. 1 rl rl 0 10 d’oct  2018 20181010.test
-rw-rw-r--. 1 rl rl 0 11 de no  2018 20181111.test
-rw-rw-r--. 1 rl rl 0 12 de de  2018 20181212.test

March and May are both displayed as de ma and June and July as de ju. I have already filed the request for enhancement against the coreutils project and it has been added upstream – we are waiting for the coreutils 8.30 release which I suspect will be in a month. Will it make it to Fedora 28 before the final release?


Bugzilla link:

These changes are not revolutionary but still interesting. Greek is an inflected language (same as Slavic languages and Latin) and the differences between the genitive and nominative cases are visible even in abbreviated forms of some months names. For example, the month May in Greek is Μάιος in the nominative case and the genitive case is Μαΐου; the abbreviated forms are Μάι and Μαΐ, respectively. From now this difference is correctly supported in Linux.

The change is also visible in an output of ls -l command:

$ LANG=el_GR.utf8 ls -l
σύνολο 0
-rw-rw-r--. 1 rl rl 0 Ιαν   1 00:00 20180101.test
-rw-rw-r--. 1 rl rl 0 Φεβ   2 00:00 20180202.test
-rw-rw-r--. 1 rl rl 0 Μαρ   3 00:00 20180303.test
-rw-rw-r--. 1 rl rl 0 Απρ  14  2018 20180414.test
-rw-rw-r--. 1 rl rl 0 Μαΐ   5  2018 20180505.test
-rw-rw-r--. 1 rl rl 0 Ιουν  6  2018 20180606.test
-rw-rw-r--. 1 rl rl 0 Ιουλ  7  2018 20180707.test
-rw-rw-r--. 1 rl rl 0 Αυγ   8  2018 20180808.test
-rw-rw-r--. 1 rl rl 0 Σεπ   9  2018 20180909.test
-rw-rw-r--. 1 rl rl 0 Οκτ  10  2018 20181010.test
-rw-rw-r--. 1 rl rl 0 Νοε  11  2018 20181111.test
-rw-rw-r--. 1 rl rl 0 Δεκ  12  2018 20181212.test


Bugzilla link:

These changes are minor. The Lithuanian translator had just asked to use in glibc the same abbreviated months names as he used in glib2 and which are also provided by CLDR – so for example the abbreviated name of April will be displayed as bal. rather than Bal now.

This change could be already visible in the ls -l output – unfortunately, for now only the numerical date formats are used:

$ LANG=lt_LT.utf8 ls -l
viso 0
-rw-rw-r--. 1 rl rl 0 2018-01-01 00:00 20180101.test
-rw-rw-r--. 1 rl rl 0 2018-02-02 00:00 20180202.test
-rw-rw-r--. 1 rl rl 0 2018-03-03 00:00 20180303.test
-rw-rw-r--. 1 rl rl 0 2018-04-14 20180414.test
-rw-rw-r--. 1 rl rl 0 2018-05-05 20180505.test
-rw-rw-r--. 1 rl rl 0 2018-06-06 20180606.test
-rw-rw-r--. 1 rl rl 0 2018-07-07 20180707.test
-rw-rw-r--. 1 rl rl 0 2018-08-08 20180808.test
-rw-rw-r--. 1 rl rl 0 2018-09-09 20180909.test
-rw-rw-r--. 1 rl rl 0 2018-10-10 20181010.test
-rw-rw-r--. 1 rl rl 0 2018-11-11 20181111.test
-rw-rw-r--. 1 rl rl 0 2018-12-12 20181212.test

Is this only because the Lithuanian translators did not like the abbreviated months names and they decided that the ls command line utility should display only numbers? If this was the reason then you can restore the text format now. I can’t speak Lithuanian but I would suggest this form:

$ LANG=lt_LT.utf8 ls -l --time-style +"%b %e"
viso 0
-rw-rw-r--. 1 rl rl 0 saus.  1 20180101.test
-rw-rw-r--. 1 rl rl 0 vas.   2 20180202.test
-rw-rw-r--. 1 rl rl 0 kov.   3 20180303.test
-rw-rw-r--. 1 rl rl 0 bal.  14 20180414.test
-rw-rw-r--. 1 rl rl 0 geg.   5 20180505.test
-rw-rw-r--. 1 rl rl 0 birž.  6 20180606.test
-rw-rw-r--. 1 rl rl 0 liep.  7 20180707.test
-rw-rw-r--. 1 rl rl 0 rugp.  8 20180808.test
-rw-rw-r--. 1 rl rl 0 rugs.  9 20180909.test
-rw-rw-r--. 1 rl rl 0 spal. 10 20181010.test
-rw-rw-r--. 1 rl rl 0 lapkr 11 20181111.test
-rw-rw-r--. 1 rl rl 0 gruod 12 20181212.test

For now the dots after lapkr and gruod do not fit but, as I wrote above while discussing the Catalan language, the problem has been already fixed upstream and sooner or later the update will land in Fedora.


After adding Catalan and Czech support now we have 9 languages which display the dates correctly using the required genitive case (with previously supported Belarusian, Croatian, Greek, Lithuanian, Polish, Russian, and Ukrainian). Belarusian and Russian are not the only which require the different genitive and nominative forms of abbreviated months names, the same is required in Catalan (because of the de or d’ preposition) and in Greek.

Same as previously, if you see in the screenshots in this article any errors in date formats which can be fixed by translators, like missing punctuation marks or incorrect day/month order then please contact the translators of the respective applications.

Fedora 28 and GNOME 3.28: New Features for Eastern Europe

This time this is not fake, edited, patched, nor a custom build from COPR but the real screenshots of the unmodified downstream Fedora 28 planned to be released on May 1 this year. Here is how the default calendar widget in GNOME Shell looks in Greek, Polish, and Ukrainian:

For those who can’t speak those languages: the major change here is that the month names are displayed in a correct grammatical form, both in dates and standalone. This is a new feature, or rather a new bugfix, in GNOME 3.28 which has been released on March 14 and pushed to Fedora 28 (prerelease) stable updates today. The series of bugfixes in GNOME was preceded by the similar bugfix in glibc 2.27 released earlier this year.

What Is Eastern Europe

This term must be explained because it is ambiguous. Usually when we say eastern Europe we mean the eastern end of our continent (as opposed to western, northern, southern, and, last but not least, central). But in this context I mean the eastern half of Europe (as opposed to western, and nothing else). I often strongly emphasize that this feature is not just for Slavic languages but also for other language groups of our region: Baltic, Greek, partially also Finnish, and even some western languages like Catalan or Scottish Gaelic.

More Applications

Of course, dates are now displayed correctly in all applications, not just GNOME Shell. In most of them this happened automagically. Few of them, however, needed some minor updates to make sure that the month names are displayed in a genitive case only where needed, not just everywhere. Here is an example of a correct month names display in GNOME Calendar, this time in Croatian:

Please note the difference between the nominative name for March (ožujak) and its correct genitive case as used in date (ožujka; literally: of March).

Western European Languages

English does not have any unsupported features but, while at this, I have examined the date displays in some other western European languages and few features were not supported. For example, some Romance languages (Spanish, Portuguese, etc.) also use the genitive case of both the month name and the year number but they construct it just adding the de preposition before. This feature although so simple was not yet supported so far but now it has been added to GNOME 3.28. Here is a screenshot of the same calendar widget in Spanish:

Please note the correct header saying diciembre de 2017 as opposed by the incorrect diciembre 2017 which is displayed by the older versions.

More Languages

The genitive case of month names is currently supported in Fedora 28 prerelease in only 7 languages: Belarusian, Croatian, Greek, Lithuanian, Polish, Russian, and Ukrainian. But the support of more languages is on the way: Catalan and Czech have been added to GLib and they are already used if the latest GNOME is ran on older systems. The support of these languages has been also pushed to glibc upstream and eventually will reach Fedora 28 but has not yet as of today. However, it has already reached Fedora Rawhide. If we have this chance, let’s take a look at the screenshot of GNOME in Fedora Rawhide in Catalan:

Please note the correct Catalan preposition of genitive case: de març (of March) vs. d’abril (of April).


I’d like to thank all the people from Fedora and GNOME communities and from the outer world who supported me in this challenge: Piotr Drąg, Mike Fabian, Zack Weinberg, Carlos O’Donell, Masha Leonova, Ihar Hrachyshka, Dmitry Levin, Igor Gnatenko, Charalampos Stratakis, Robert Buj, Philip Withnall, and more.

PS. If some date formats in these screenshots are incorrect please approach the respective translation teams.

Some Bugs Are Really Funny

People learn from errors. Therefore bugs should be made public, not hidden.

GLib is a utility library originally developed for GNOME but also used by other projects. One of many functions it provides is g_date_set_parse(). It is really smart and simple. It accepts a string to parse but other than many date parsing functions it does not require a date format to be passed. Instead it tries to find numbers and month names in the parsed string and figure out what date they can represent. Of course, month names are recognized according to the current locale.

Let’s see how it works for Polish. Here is the list of month names:

Month # Full name Abbreviated name
1. Styczeń Sty
2. Luty Lut
3. Marzec Mar
4. Kwiecień Kwi
5. Maj Maj
6. Czerwiec Cze
7. Lipiec Lip
8. Sierpień Sie
9. Wrzesień Wrz
10. Październik Paź
11. Listopad Lis
12. Grudzień Gru

The loop implementing the algorithm iterates over all months and checks if the string being parsed contains a full or abbreviated month name as a substring. The first month which is found as a substring of the parsed string is recognized as a result. Let’s see what happens when a string containing the 9th month, September, which in Polish is wrzesień, is parsed by this algorithm:

Iteration # Full name Abbreviated name Does the string wrzesień contain it?
1. Styczeń Sty No
2. Luty Lut No
3. Marzec Mar No
4. Kwiecień Kwi No
5. Maj Maj No
6. Czerwiec Cze No
7. Lipiec Lip No
8. Sierpień Sie Yes: wrzesień!

So, as a result, the string wrzesień (September) is recognized as sierpień (August).

Is this severe at all?

To be honest, not really. The bug seems to have been around for 20 years now and nobody has complained so far. Parsing dates is not really useful. There are many good reasons why it may not work in localized texts, like incomplete or incorrect translations, varying orthographic rules, Unicode characters updates, etc. Probably no real applications actually use this.

Nevertheless, the problem has been reported to GNOME Bugzilla and will be worked on.