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?
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?
You are definitely correct, and there is one other part to add.
ReplyDeleteSoftware 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.
Absolutely, thanks for adding this!
ReplyDelete