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?


  1. You are definitely correct, and there is one other part to add.

    Software can continue development after a string freeze. The developers just cannot change any strings. If they must, such as for a bugfix or some other unavoidable reason, they can announce to the l10n team that there are a few strings changed. Bumping a translation back from 98% to 100% is much more easily done. Thus the order helps make it possible to introduce new code right up to the other engineering freezes.

  2. Absolutely, thanks for adding this!


Post a Comment

Popular posts from this blog

PVR is so wierd!

Yesterday we went second time to a mall bit far from office to complete the earlier failed mission of watching this 3D movie, Clash of the Titans. On ticket counter, we were first told that evening show was house full. Then we asked for a night show, and were told there isn't any show then and the gentleman handed us the pamphlet of all movie schedules. We checked on the nearby digital kiosk and also on the printed schedule to be sure of the show timings. Then went to second counter, and asked the lady for the night show tickets, and without any problem got the tickets for back seats. In fact this show was hardly 20% full, wonder how the evening show became houseful.

But the biggest wonder/blunder is yet to come. On the entrance we were stopped for having a laptop bag along with (we had went straight after the office). In spite of having checked the bag, we were not allowed, because laptops were not allowed inside! Then we asked for keeping it at the baggage counter. But then, the…

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,…

अग्निपथ से धूलपथ तक!

अक्सर दिल्ली की धूप में 'दोपहर' के १० बजे घरसे निकलो, तो अपनी ही दशा को देखकर सबसे बड़े बच्चनजी की पंक्तियाँ याद आती हैं।

यह महान दृश्य है, चल रहा मनुष्य है,
अश्रु-स्वेद-रक्त से लथपथ लथपथ लथपथ।
अग्निपथ अग्निपथ अग्निपथ...

किंतु आज तापमान में गिरावट और धूल-वायू की लहरों के चलते, दिल्ली की सड़कों को अग्निपथ से 'धूलपथ' में परिवर्तित होते पाया गया है। फिरभी देखा जाए, तो इसे उष्मा से मुक्ती का एक तात्कालिक ही सही लेकिन सुखद अनुभव कहा जा सकता है।