Skip to main content

Why translations are freezed before development?

Some time back somebody talked to me about how illogical the schedule of fedora is, why do you have the translations deadline before the final development freeze. There is no point in freezing the translations when your development is still going on. Why don't you do it gnome's way? they don't freeze their translations before development!

Having received this unusual query all of a sudden and being far from internet connectivity to check the facts, I had no clear answer by then. But the logic had to be given.

To go by facts, the example about gnome was wrong! Check the gnome's schedule, they have string freeze (the term they use for translations) a lot before the code (development) freeze.

Having worked on both fedora and gnome l10n projects, I had an idea about the logic behind this, but I think it turned blur with the time. The logic is..

Development (or coding) and translations are two different tasks. In all the projects that need translations, have a set of language guys (generally more than the number of languages supported) who do the translations and set of developers who do the coding and packaging of their products. But to actually make the translations available in the software, the developers need to build(or compile) their packages including the translations done by the translators. Obviously you do not want translators from all the various languages to take care of building the package every time each one of them does some work. So to synchronize with the translations, whenever the developer needs to build his package, the translations at that moment of time are also built with it. Now imagine how difficult it would be for a translator to determine whether his translations actually made it to the final product or not, since he might do some work even after the developer has built his package for a particular freeze. Given the number of packages and loads involved with fedora or such products, it is impossible to expect all of the developers to build their packages all at once. So how do the translators get the deadline? Just keep some buffer period between translations and development freeze!

So translators know they have a particular deadline. All the work done till then should be available in the final product. Any work on translations done after that deadline cannot be expected in the current final product, but it will come in the next version of the product.

On the other hand developers can independently compile and build their packages for the final product, and without being worried about the translations done any time during the buffer period, be assured that whatever has been translated before the translation freeze is going into their package.

Otherwise how chaotic it would be for everyone, if developer has compiled the package and translator does some work after that and comes back to the developer asking for recompiling and so on.. The only solution to that would be to freeze everything, all the packages, all the coding and all the translations all at once! But that kind of coincident is far from possible even for products involving limited number of packages with developers spread all around the geography and working independently. Thus you can see why even gnome does it the way fedora does.

Oh, Ubuntu has something interesting too! Their LanguagePackTranslation deadline is same as the Release Candidate. But worth noting is that their 'NonLanguagePack'Translation freeze is preceding the final freeze. Now you guess why?

Popular posts from this blog

Designing for scalability – a startup perspective

What is scale? Is it the number of customers a company has? Is it the number of products that are sold? Is it the amount of revenue the company makes? Is it the amount of infrastructure one has? Or is it the number of features the product has? Well, it can be all of this or none of this. When an organization talks about scale it is not just a number. When an economist talks about it, again it’s not just a number. For an economist, the scale is about doing more with less. Scale is about perspective, about relationship between two or more variables that ultimately help you generate optimum value for your efforts.
Consider this, let’s say you are into making a lollipop. Selling 10 lollipops you earn $100 revenue of which $10 is you profit and $90 is the cost. When you increase you production you start selling 100 lollypops and earn $1000 revenue with $100 as your profit and $900 as cost. Did you really benefit from the scale here? In absolute terms, of course. In terms of ratios though,…

Featured in the 'Startup of the Week!' from SBC

We have recently been featured as the startup of the week on the StartupBootCamp Fintech Mumbai website. Just sharing the link to the original post by SBC here:

Will write more about the startup, what we do, how you may benefit from it and how has been our experience in separate posts. Till then, do check out our platform at

Asking for a slate that already is written into!

If I give you a slate or a notebook and a chalk or pencil, would you respond by complaining that it does not have anything written on it? Well that is how most educationist view technology as and that is what the problem with technology providers is.  We are so habituated to fast food instant noodle, that we want even our slates to be pre-written by someone else. The marketeers have lost the vision of utility of slate so much that they are still busy in selling slates with pre-written alphabets on them, and they are not giving you any chalk for your own writing as well.

Sounds absurd? Then remove slate and notebook, and put in its place the modern technology, computers, laptops, tablets and online learning solutions. In place of chalk and pencil, consider your ability to create and modify your own digital knowledge.  Of the hundreds of e-learning, online tutorials, online courses, are there any that focus on giving their learners the experience of creating knowledge on their own, put…