fre 2005-04-01 klockan 03:18 +0800 skrev Davyd Madeley: > > > The priority of this string is very > > > low (ie. you should never see it), it was added because in the > > > current tree it would simply fail silently. We were also in a rush > > > to get it backported and to try and get some testing before next > > > week's release. > > > > What I don't understand is why this fix (the added error message) is > > considered important enough to be in the same patch as the memory leak > > and location name i18n fixes. > > If this error message is not at all important, then why is it in the > > same patch with a lot of crucial fixes? It appears that this situation > > would have been more manageable if the fixes were seperated into several > > patches that could have been prioritized differently. To me, it seems > > like the only reason this added error message was backported at all was > > because it happened to be in the same patch. > > It shouldn't have been backported. I should have noticed it when I > approved the backport. However I didn't, basically because I suck.
Ok, don't worry. We all make mistakes. I'm more concerned with people who commit unapproved stuff although they already know at that time that they will be breaking freezes. That's what really worrying me. > > > If this is unacceptable, then we will remove the string. However, I > > > hope that you can see why we think this patch is in fact quite > > > important, and that you have pity on us for only being mortal. > > > > I'm sorry, but I haven't been convinced that this added error message is > > essential to have in the gnome-2-10 branch. I certainly understand and > > share your opinion about the other fixes in the patch; the memory leak > > fixes and the translated names fixes. Those do indeed fix important bugs > > and can be classified as essential. > > Without wanting to tell the translators how to do their job. I don't > see how having the string marked for translation is necessarily a > bad thing. The string is not likely to ever be user visible, but if > translators want they can translate it. Hence, the only thing it > will affect is people's 100% ratings. Without being in on the > culture, is this an issue? The problem is that translators don't have any reliable way to prioritize messages or otherwise classify them, other than prioritizing on a module level. Either a message is marked for translation and in the pool, or it is not. There's no inbetween. All messages end up in the pool that is "the messages for module foo" or the superset "the messages for GNOME 2.x". Translators deal with these (large) pools by counting the messages in them, and keeping track of this status. Counting is the only way to know. There's simply no good way to know how "important" any message is or how visible it will be to end users, without actually having to examine the message, carefully inspecting the code using it, or asking the developers who produced the message. But even then, the best you can do is only to make a mental note about it -- the tools cannot prioritize the messages for you. Either the message is there, or it's not. As a consequence of this, the only way to be sure you have translated all important messages, is to have translated *all* messages. If you know you're at 100%, you can sleep well; otherwise, you don't really know what important messages are there in the remaining percentage that you haven't had the time to translate yet. That's why we have string freeze. It's not because developers and maintainers in the past always did add big and important translateable messages that would get shown in big capital letters on the desktops of all users on the day before release day. No, most developers, even back in those days, realized that that would be a bad� thing to do. It was because every now and then in the weeks and days before and after the actual release, dozens of developers and maintainers would think that adding one or two or maybe ten harmless messages, that would only get shown to the user every other Sunday that had a full moon, would be no big thing. So they did that. As a consequence, translators were continuosly swamped with a never-ending stream of "harmless" messages even at release times. The problem was that, every now and then, some few developers would add even important messages at those times. Those message additions would naturally go undetected among the "not harmless" ones. If I as a translator would know (and be able to remember) that I had 146 untranslated messages yesterday, how would I know that if today's count is 147, that this added message is important or not important? The answer is "I don't", that is, without taking the time to inspect the message, but then I have to spend almost as much time as I would have in order to translate the message in the first place. Heck, the count of untranslated messages can even *remain the same*, and there be still danger. If a developer removes a message, but he (or another developer) adds another, important, message, then the count remains the same, and translators with untranslated messages wouldn't know. Only the translator who previously had 100.00% translated messages would be able to reliably detect such a thing. The only way to resolve this and make it manageable for translators is to restrict *all* message additions or message changes that affect the message counts, even additions that may in themselves seem harmless enough. By doing that, the translators who are luckily enough to be at 100.00 percent can rest assured that they are actually on top of things, and that things aren't going out of control. I hope this clarifies the situation a bit -- translators usually aren't the number-fixated, statistics-obsessed, unreasonable string-freeze- shouting anal retentive bastards they appear to be -- they simply just want control over their situation, a situation that has been shown to quickly get out of control otherwise. Christian _______________________________________________ gnome-i18n mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-i18n
